Hallo Habr! Mein Name ist Maxim Lutzau, bei der Promsvyazbank arbeite ich als Product Owner. Seit fast einem Jahr wird die neue My Business Internet Bank mit dem Scrum-Framework weiterentwickelt, und in dieser Hinsicht habe ich es bereits geschafft, die Probleme zu beheben. In diesem Beitrag möchte ich über die schmerzhaftesten von ihnen sprechen sowie darüber, welche Tools uns letztendlich geholfen haben. Damit Sie solche Probleme vermeiden können.
Einige Mitarbeiter sind grundsätzlich gegen Veränderungen
In unserer Bank wurde ein Scrum-Framework eingeführt, um die Entwicklung zu beschleunigen und TTM zu reduzieren. Als die Implementierung begann, stellte sich heraus, dass einige Mitarbeiter dafür nicht bereit waren. Sie verstanden nicht, warum dies notwendig war und was es geben würde.
"Früher haben wir gut gearbeitet, warum brauchen wir das?", "Warum machen wir das nicht anders?", "Wer hat mir das beigebracht, woher weiß er, dass das besser ist?" - Ähnliche Fragen regneten ihrerseits ständig. Und selbst als diese Mitarbeiter Antworten erhielten, wiederholte sich nach einer Weile alles noch einmal.
Die vernünftigste Lösung in diesem Fall besteht darin, Personen auf andere Projekte zu übertragen. Dies muss unbedingt geschehen, da eine Person, die ein Negativ ausstrahlt, jeden beeinflussen kann. In unserer Geschichte ist genau dies unser Kollektiv geheilt - die allgemeine Spannung ist verschwunden und jeder ist auf die Wahrnehmung neuer Informationen eingestellt.
Eine negative Reaktion auf Veränderungen hängt nicht vom Alter ab. Die Entwickler, über die wir oben gesprochen haben, waren etwas mehr als 30 Jahre alt. Gleichzeitig arbeitet eine Person, die bereits über 50 Jahre alt ist, perfekt in unserem Team - er hatte keine Probleme mit Scrum.
Es ist schwer, mit Menschen zu interagieren, die nicht von Scrum leben.
Jede Organisation muss mit Leuten zusammenarbeiten, die einfach nicht an Scrum arbeiten. In unserem Fall sind dies Teams aus anderen Projekten und Abteilungen. Sie haben normalerweise viel längere Phasen der Projektumsetzung. Ehrlich gesagt arbeiten bisher nur RBS-Entwickler für uns an Scrum.
Wir haben uns entschlossen, nichts mit diesem Problem zu tun - nicht mit unserem Scrum in die Arbeit anderer Leute einzusteigen. Wir bitten sie nur, das zu tun, was wir brauchen. Wenn sie mit einer Lösung zurückkehren, beginnen wir, ihre Aufgaben zu verknüpfen. Komplizieren Sie die Interaktion nicht, wenn die Unternehmenskultur noch nicht von selbst reif ist. Natürlich besteht nach Scrum-Trainings der Wunsch, absolut alles zu ändern, aber es ist besser, rechtzeitig anzuhalten.
Obwohl wir andere Einheiten nicht überstürzen, beginnen sie in Zusammenarbeit mit uns schneller zu arbeiten. Wir laden Sicherheitspersonal zu unseren Besprechungen und Demos ein. Die Einigung auf eine vollständig abgeschlossene Version dauert nur noch einen Tag. Davor dauerte es eine Woche bis zwei.
"Wir werden nicht rechtzeitig zum Sprint sein!"
Nach der Implementierung von Scrum haben wir von monatlichen Berichtsperioden auf zweiwöchige Sprints umgestellt. Aufgrund des Umfangs der Aufgaben wollten sie die Fristen zunächst nicht komprimieren. Es ist jedoch ein großer Fehler, die Größe des Sprints an das anzupassen, was getan werden muss. Im Gegenteil, Sie müssen die Pläne für die Dauer des Sprints anpassen. Dies ist ganz einfach - zerlegen Sie einfach die Aufgaben. Wenn sie kleiner werden, lassen sie sich leichter nach Plan anordnen, um ihnen Priorität einzuräumen. Kleinere Codestapel lassen sich schneller testen, überprüfen und mit Sicherheitspersonal verhandeln. Im Allgemeinen würde ich sogar empfehlen, die Sprintdauer nach Möglichkeit von zwei Wochen auf eine zu reduzieren.
Wenn jemand aus dem Team bis zum Ende des Sprints nicht die Zeit hat, alles zu erledigen, besteht der natürliche Wunsch, die Demo zu verschieben - voll bewaffnet dorthin zu kommen. In diesem Fall müssen Sie sich jedoch immer noch an den Zeitplan halten. In jedem Fall lohnt es sich, über die Ergebnisse der Arbeit zu sprechen: Was sie getan haben, was und warum sie nicht getan haben, was sie getan haben, um rechtzeitig zu sein. Wir laufen also nicht vor Problemen davon, sondern begegnen ihnen von Angesicht zu Angesicht, und dann können wir gemeinsam Lösungen finden.
Dieser Ansatz erhöht die Motivation, nach erfolglosen geplanten Demos wächst die Verantwortung für die Arbeit. Wenn die Entwickler zuvor den Stand in fünf Minuten für die Demo vorbereitet haben, tun sie dies jetzt am Tag vor der Demo und polieren dann die verbleibenden Unebenheiten, um alles super zu machen.
"Warum brauchen wir tägliche Stand-Ups?"
Anfangs waren die Kollegen skeptisch, jeden Tag bei Stand-up-Meetings von ihrer üblichen Arbeit abgelenkt zu werden. Auch wenn sie online gehalten werden und nur 10 Minuten benötigen.
Bei der Lösung dieses Problems hilft die symbolische Ermutigung einer Person, die mit dem Team eine gemeinsame Sprache findet. Einmal sagte ich aus Spaß, ich würde diejenigen, die zu Stand-Ups kommen, auf den Kalender setzen und begann, Pluspunkte zu setzen. Das Ergebnis war unerwartet und der Effekt war nach einem Sprint spürbar. Die Entwickler wollten nicht bombardiert werden und kamen selbst zu Stand-Ups. Es ist sogar zu unserem gemeinsamen Witz geworden: Jetzt drohen sie mir ein Minus zu geben, wenn ich an keinem Meeting teilnehmen kann.
Viele Leute denken, dass Scrum-Meetings viel Zeit in Anspruch nehmen. Es reicht aus, hier zu berechnen, ob dies tatsächlich so ist. Wir haben zwei von 40 Stunden pro Woche. Dies ist nicht so sehr, um die Arbeit zu organisieren und über alle Dinge auf dem Laufenden zu bleiben.
Wenn das gesamte Team nicht zu Stand-up-Meetings gehen möchte und die Meetings selbst nicht sehr aktiv sind, ist dies ein Signal dafür, dass die Arbeit schief läuft. Als ob sich die Besprechung um mehr als 15-20 Minuten verzögert. Eine Geschichte über seine Aktivitäten und Pläne in einer Person sollte nicht länger als ein oder zwei Minuten dauern.
Eine weitere Regel ist mit dem Zeitmanagement verbunden. Wenn die Diskussion der Aufgabe länger als 30 Minuten dauert, beenden wir sie. Dies bedeutet, dass wir keine Zeit hatten, die Aufgabe zu entwickeln, dass sie schlecht zerlegt ist und immer noch Zeit benötigt. Dies ist es wert, beachtet zu werden. Wir setzen uns ein Limit von 30 Minuten - jedes Unternehmen muss seine eigene Barriere aufbauen.
Unverständlicher Rückstand
Der Erfolg von Scrum hängt in erster Linie von einer klaren Planung ab. Es muss festgelegt werden, wie viele Aufgaben bewertet und beschrieben werden sollen und welche vorerst einfach verschoben werden können. Versuchen Sie nicht, alles auf einmal abzudecken. Der Entwickler muss verstehen, was er in den nächsten beiden Sprints tun wird. Für längere Zeiträume reicht eine grobe Idee aus - je später, desto weniger Details.
Unangemessenes Mikromanagement
Was machen Entwickler heute? Was wird morgen passieren? Es kommt vor, dass Manager solche Fragen regelmäßig stellen. Wir konnten unserem Management erklären, dass alle Punkte von Interesse auf unserem Scrum Board oder durch das tägliche Aufstehen zu finden sind. Keine speziellen Berichte mit Tabellen und Überwachung von Aufgaben in Jira. Wir haben es geschafft, dieses Mikromanagement auf wöchentliche Besprechungen mit dem Management zu beschränken, in denen ich über die spezifischen Aufgaben des Teams berichte.
Etwas, über das fast nie geschrieben wurde
Schließlich gibt es ein klares Problem, dessen Erwähnung ich fast nie gefunden habe. Sie müssen nicht versuchen, den Scrum Master und den Product Owner zu kombinieren. Letzterer baut eine Geschäftseinheit auf, arbeitet an einem Rückstand und führt KPI durch. Er interessiert sich für den Erfolg des Produkts und versucht, sich mit allem auseinanderzusetzen. Deshalb beginnt er, Termine zu vereinbaren und einige Details zu besprechen. Im Allgemeinen lädt es sich selbst mit einer Reihe von Funktionen, wodurch einfach keine Zeit mehr für den Rückstand bleibt.
Das ist mir passiert. Ich organisierte Meetings, Stand-Ups und löste die Probleme der Teammitglieder. Aus diesem Grund wurde der Rückstand nicht ausgearbeitet, dh es war einfach keine Zeit für die Hauptaktivität. Jetzt haben wir einen Entwicklungsmanager gefunden, der die Autorität über das Team hat und auch die Funktionen eines Scrum Masters ausführt, da er mehr Erfahrung in der Arbeit an diesem Framework hat. Jetzt konnte ich mich von Scrum entfernen und mich voll und ganz auf die Aufgaben des Produktbesitzers konzentrieren, der seinerseits über die Anforderungen nachdenken sollte. Ohne gute Anforderungen wird es kein gutes Produkt geben. Infolgedessen begann sich der Rückstand zu verbessern, und die Kollegen verstanden, wie wir weitermachen werden.
Auf den ersten Blick scheint Scrum sehr einfach zu sein, hat aber immer noch viele Fallstricke. Wir arbeiten seit fast einem Jahr an diesem Rahmen, aber erst jetzt haben wir begonnen, unsere Fähigkeiten mehr oder weniger klar einzuschätzen und die Entwicklungsgeschwindigkeit zu erhöhen.