Wenn Sie sich zumindest für einige nützliche Dinge interessieren:
a. Grunddisziplin
b. die Bildung vereinbarter Interaktionsprozesse untereinander und mit Verbündeten
c. eine Erklärung, was und wie Subunternehmer tun
d. Flexibilität im Prozessmanagement
rechtzeitige Reaktion auf neu auftretende Probleme
dann werden sie das Arbeitsklima im Entwicklungsteam verbessern.
Wenn Sie sich ruhig entwickeln möchten, müssen Sie sich zusammensetzen, zustimmen und transparente Regeln für die Interaktion miteinander aufschreiben. Zumindest das grundlegendste.
Alle Prozesse und Vereinbarungen sollten unter Beteiligung aller interessierten Parteien erstellt werden, und negative Auswirkungen auf Prozesse sollten zerstört werden.
Ich möchte am Beispiel des Workflows eines Sprints malen, welche Vorteile seine Elemente bringen: Welche Aktionen werden ausgeführt, welche Artefakte sind vorhanden und warum wird jeder von ihnen benötigt. Sie sollten sich zunächst mit den Definitionen von Ereignissen und Scrum-Artefakten vertraut machen.
Sprint N-1 : Vorbereitend. Welches ist nicht gerade ein Sprint.
Vor dem Start von Sprint N der Entwicklung selbst ist ein Teil des Teams mit Vorbereitungsarbeiten beschäftigt: Testen, Genehmigen, Entwickeln, Visualisieren usw.
Bedeutung : Damit Entwickler die Aufgabe qualitativ ausführen, die erforderlichen Parameter erreichen oder das Problem einer Person lösen können, bevor die Entwicklung selbst beginnt:
a. alle Vorbereitungsarbeiten gründlich durchführen,
b. Diskrepanzen reduzieren,
c. Testen Sie Benutzer oder lassen Sie sich von Stakeholdern genehmigen.
d. Erstellen Sie eine detaillierte Visualisierung.
Ausgabe : Eine Reihe von Artefakten und Daten, die die Checkliste Definition Of Ready erfüllen.
Wenn Sie die Interaktion zwischen Programmierern und allen anderen direkten Teilnehmern am Entwicklungsprozess verbessern möchten, ist es hilfreich, die grundlegenden Funktionen und Prozesse aller Teilnehmer kennenzulernen und zu erläutern. Unter den Programmierern gibt es genug Introvertierte, die es nicht mögen, wenn sie ihren Prozess stören, aber sie müssen auch verstehen, wie der Rest funktioniert, damit der gegenteilige Effekt nicht funktioniert. Wir fangen an:
Sprint N-1 Start :
OKR, KPI, Stakeholder-Anforderungen usw. - Eine Reihe eingehender externer Bedingungen, die die Entwicklung leiten.
Sprintziel N.Abhängig von den eingehenden Bedingungen, wo sich die Entwicklung bewegen soll, welche Parameter erreicht werden müssen, wem und warum zu helfen ist, wird das Ziel des bevorstehenden Entwicklungssprints gebildet.
Bedeutung : Das Ziel des Sprints dient als Motivation für das Team, als Erklärung der Bedeutung ihrer Aktivitäten und als Indikator.
In Abwesenheit : Unmotivierte Codierer werden hauptsächlich mit Peitsche, Matte und Geldstrafen gesteuert.
Jedes Team braucht Motivation, damit die Entwicklung nicht zu einer endlosen Reihe bedeutungsloser Aufgaben wird, bei denen unklar ist, ob jemand sie braucht. Insbesondere in Unternehmen, in denen die Entwicklung nicht die Grundlage des Geschäfts ist, tritt häufig ein Problem auf, wenn die Abteilung nicht geschätzt wird, weshalb ihr Selbstwertgefühl und ihre Motivation sinken. Wir brauchen ein transparentes und verständliches Ziel - jemandem zu helfen, das Problem zu lösen, einige Parameter des Geschäfts zu verbessern und das Leben eines Menschen zu verbessern. Selbst in der elendesten Gesellschaft ist es gut, sich der Bedeutung ihrer Aktivitäten bewusst zu sein.
Rückstandspflege - Rallye oder kontinuierliche Aktivität. Management des Rückstands eines begrenzten Teils des Teams.
Bedeutung : Jeder Sprint wird mit einer begrenzten Zusammensetzung für Reinigung, Grundstudie, anfängliche Bewertung der Komplexität und Durchführbarkeit, Zerlegung und Priorisierung von Aufgaben im Rückstand abgehalten.
Beenden : Eine Liste relevanter und realisierbarer Aufgaben.
Wenn nicht : Eine riesige Liste von Wunschliste im Backlog, die niemand liest, wo die Aufgaben jahrelang vergessen liegen.
Sprintplanung N-1 - eine Rallye, bei der ein Teil des Trainingsteams, basierend auf dem Zweck und dem Umfang des bevorstehenden Sprints N, Aufgaben auswählt, vorab bewertet und priorisiert.
Sinn : Die Vorbereitung auf den Sprint erfordert auch etwas Ordnung. Das Ressourcenmanagement wird vereinfacht.
Ausgabe : Sprint N. Rückstand
TestentwicklungHängt vom Entwicklungsstil und der Anwesenheit von Testern im Team ab.
Das heißt : Es lohnt sich, vorgefertigte Pläne zur Überprüfung des Zustands des Codes zu haben.
Ich schlage vor, 2 Optionen in Betracht zu ziehen:
In Abwesenheit von Testern besteht die Möglichkeit, die Testerstellung an das Entwicklungsteam zu übertragen. In diesem Fall wird diese Aktivität im Rahmen der Entwicklung von Aufgaben im Sprint N ausgeführt. Nach einigen Überprüfungen verbessert dieser Ansatz die Qualität des von den Entwicklern geschriebenen Codes.
Wenn Sie Tester haben, können Sie den Ansatz verwenden, wenn Tests vor dem Code geschrieben werden. Ein Vorteil ist, dass die Aufgabenentwicklung beim Entwickler endet und die Wahrscheinlichkeit verringert wird, dass die fertige Aufgabe von Testern zurückgegeben wird, wenn der Entwickler bereits zu einer anderen Aufgabe gewechselt ist.
Use Use Case 's - detaillierte Untersuchung von Interaktionsszenarien und Ergebnissen innerhalb der Aufgabe.
Bedeutung : Eine Beschreibung der Szenarien der Aufgabeninteraktion mit Text oder Diagrammen verbessert das Verständnis des Problems für alle interessierten Parteien. Mit der kostengünstigen Lösung können Testfälle und Prototypen erstellt werden.
In Abwesenheit : Geringe Ausarbeitung führt zu einer Divergenz des Verständnisses dessen, was wirklich für die Aufgabe erforderlich ist, der Verlust alternativer Anwendungsfälle ist möglich.
Wireframing, Mockuping und Prototyping sind im Großen und Ganzen ein iterativer Prozess zur Entwicklung der Visualisierung der Benutzeroberfläche mit stetig zunehmenden Details. Beginnend mit der einfachsten und billigsten Option werden Benutzer / Stakeholder getestet, um festzustellen, ob die vorgeschlagene Option den Erwartungen zur Lösung des Problems entspricht. Visuelle Tests sind so nützlich, um die Inkonsistenz von Textbeschreibungen zu verringern, und im Vergleich zur Codierung sehr billig, dass Unternehmen mit einer starken Design- und Produktlobby damit begannen, sie mit ihren Prozessen, Artefakten und ihrem Zeitplan in eine separate Methodik zu unterteilen.
Wireframing - grobe Skizze der Schnittstellenelemente. Ein Stift auf einem Blatt Papier oder in einer Software ohne Schnickschnack.
Sinn : Schnelle und kostengünstige Prüfung / Genehmigung durch die Stakeholder der Aufgabe. Eine zusätzliche Demonstration der Visualisierung verbessert die Wahrnehmung erheblich als nur beschreibender Text.
In Abwesenheit : eine Divergenz des Verständnisses dessen, was tatsächlich geschaffen wird. Erhöhte Entwicklungskosten.
In Ermangelung einer Genehmigung : Bei der Entwicklung für einen Stakeholder eine dokumentarische Genehmigung einholen, um die Wahrscheinlichkeit zu minimieren, dass "ich nicht darum gebeten habe".
Ausgabe : Zugelassenes / geprüftes Drahtmodell.
Mockuping ist der zweite Schritt bei der Visualisierung Ihrer Benutzeroberfläche. Die Zunahme im Detail.
Bedeutung und Abwesenheit : ähnlich wie bei Wireframing. Vorbereitung des Inhalts für das Layout.
Beenden : genehmigtes / getestetes Modell und Layout.
Prototyping ist der dritte Schritt bei der Entwicklung der Visualisierung Ihrer Benutzeroberfläche. Zur detailgetreuen Visualisierung wird eine Demonstration der Nachahmung der Benutzerinteraktion mit dem Produkt hinzugefügt.
Bedeutung und Abwesenheit : Ähnlich wie bei Wireframing und Mockuping.
Ausgabe : Wir haben einen detaillierten Prototyp des Produkts und eine Visualisierung der Interaktion. Plus dokumentarische Genehmigung durch Stakeholder oder das Ergebnis von Tests an Benutzern.
DoReady =
Definition of Ready - Die Checkliste der vom Entwicklungs- und Vorbereitungsteam vereinbarten Bedingungen, anhand derer sie überprüft wird: Hat das Studium der Aufgaben ein ausreichendes Niveau, das Vorhandensein aller erforderlichen Artefakte, damit die Aufgabe in die Entwicklung aufgenommen werden kann?
Das heißt : Eine von allen interessierten Parteien vereinbarte formelle Checkliste verbessert das Verständnis und die Interaktion innerhalb des Teams. Jeder weiß was und wie man geht. Sie können Ihre Nase in die Checkliste stecken und senden, um die fahrlässigen Arbeiter zu erledigen.
In Abwesenheit : "Oh, ich habe es fast geschafft, es ist zu 95% fertig." und ... es wird niemals abgeschlossen sein.
IMHO ist dies das wichtigste Artefakt, um grundlegende Konflikte zwischen Encodern und allen anderen zu lösen. Es ist sofort klar, wer und wie ihre Arbeit nicht beendet hat, was sie verletzt haben und wie sich dies auf andere auswirkt. Es ist viel schwieriger, mit den festgelegten Regeln zu argumentieren, als wenn es einen Streit gibt, der auf Meinungen oder Druck durch Autorität / Position beruht. Obwohl der PM-Moderator, der das gewünschte Element anstößt, immer noch nützlich ist.
Alles weiter bestanden:
Sprint N. Wir beginnen mit der Entwicklung.
Sprint Start N :
Definition von Bereit, Sprintziel, Liste der zunächst bewerteten Aufgaben - die Bedingungen (und Artefakte), die zum Starten des Sprints erforderlich sind.
Sprint N-Planung - eine Rallye, bei der das Entwicklungsteam basierend auf dem Ziel und dem Umfang von Sprint N Aufgaben auswählt, bewertet, priorisiert und zerlegt. Abhängig von der Durchschnittsgeschwindigkeit des Teams wird eine bestimmte Anzahl von Aufgaben gewonnen.
Sinn : Das Haupttreffen, bei dem das Team prüft, ob die Aufgaben zufriedenstellend erledigt wurden. Verstehen sie die gestellten Aufgaben und Akzeptanzkriterien richtig? Entwickler bewerten schließlich die Kosten für Aufgaben.
In Abwesenheit von : Chaos werden Aufgaben jederzeit von unverständlichen Personen festgelegt, selbst während andere Aufgaben ausgeführt werden.
Ausgabe : Sprint N. Rückstand
Hinweis: Abhängig von der Geschwindigkeit des Teams übernehmen Sprints häufig 70-80% der Aufgaben für das Sprintziel und 20-30% der Aufgaben für Fehler, technische Schulden oder plötzliche kritische Aufgaben.
Die Zerlegung und Zuweisung von Aufgaben ist oft ein Mini-Meeting für ein Entwicklungsteam ohne zusätzliche Personen.
Das heißt : Ein Team mit einem Teamleiter zerlegt die Sprintaufgaben für einen Zeitraum von nicht mehr als 1 Tag in Unteraufgaben (Rand 2). Unteraufgaben werden von Entwicklern abhängig von ihrer Spezialisierung oder ihren Vorlieben zugewiesen.
In Abwesenheit : Es hängt von der Beteiligung des Teams am Prozess ab, ob die Entwickler interessante Aufgaben erhalten, die zu ihrer Entwicklung beitragen.
Beenden : Detaillierung des Sprint-Backlogs N auf 1-Tages-Unteraufgaben.
Tägliches Treffen - tägliches kurzes Treffen des Entwicklungsteams.
Das heißt : Entwickler müssen sich jeden Tag miteinander synchronisieren: Wer hat was am Vortag getan, was planen sie am aktuellen Tag und welche Probleme hindern sie daran, die Aufgabe zu erledigen.
In Abwesenheit : Niemand weiß, woran andere arbeiten, ihre Implementierungsprobleme. Entwicklungsfristen werden gestört.
Ausgabe : Der Fortschritt wird im Burndown-Diagramm aufgezeichnet - dem Zeitplan der Aufgaben.
Meiner Meinung nach ist die Einführung von Disziplin eine der Hauptbedeutungen bei der Existenz täglicher Kundgebungen. Codierer haben viele Introvertierte, die nicht kommunizieren wollen, nicht wissen wollen, was andere tun, keine Zeit für Rallyes verbringen wollen. Daher die Regeln, um kurz das Stehen durchzuführen.
Wenn das Team gut zusammengearbeitet hat, in einem Chat gut kommuniziert und Probleme sofort teilt, kann die Anzahl der Besprechungen reduziert werden, indem die Besprechungen in einen fortlaufenden Prozess umstrukturiert werden. Aber Sie sollten es nicht vollständig abschneiden.
Die Diskussion und Lösung von Störungen ist eine direkte Fortsetzung des täglichen Treffens.
Das heißt : Nachdem die Entwickler Probleme mit der Implementierung der Aufgaben geäußert haben, wird eine Diskussion über die Aufgaben geführt, die das Team intern lösen kann. Anschließend geht es an die Teilnehmer, und die Störung der externen Lösung geht an PM.
Wenn nicht : Implementierungsprobleme sollten so schnell wie möglich gemeinsam gelöst werden, damit niemand den Fortschritt künstlich in die Länge zieht.
Als die Introvertierten in ihre Ecken flohen, können Sie hier bereits die Probleme und ihre Lösungen diskutieren.
Commits / Code Review - Codeüberprüfung durch andere Teammitglieder.
Das heißt : 1-2 andere Teammitglieder sollten sich den neuen Code ansehen und die Qualität, den Stil usw. genehmigen.
Wenn nicht : Erhöhen Sie die Anzahl der Fehler im Code, die geringe Qualität und den Stil.
Sie bieten an, Code Review 2 von anderen Entwicklern mit unterschiedlichen Levels durchzuführen, auch für Junioren ist dies eine gute Möglichkeit, dies zu lernen. Auf die eine oder andere Weise erhält das Team einen akzeptablen Stil, der weiß, wann und wer zum Arbeitscode zurückkehren muss.
Auf Entwicklungsserver / Vordemonstration bereitstellen - Code in die Entwicklungsumgebung / den Entwicklungsserver hochladen.
Das heißt : Jede Implementierung der Aufgabe kann in die Entwicklungsumgebung hochgeladen werden und interessierte Personen zum Testen und zur vorläufigen Genehmigung der durchgeführten Arbeiten einladen.
Wenn nicht : Beim letzten Demo-Sprint können Sie in eine unbequeme Position geraten, indem Sie eine fehlerhafte oder falsche Implementierung demonstrieren.
Beenden : informelle Genehmigung der Aufgabe.
Wie auch immer, falsche Interpretationen der Aufgabe oder die Schrägkriterien der Aufgabe schräg kommen manchmal zu diesem Stadium. Je früher die Aufgabe verifiziert und getestet wird, desto seltener muss darauf zurückgegriffen werden.
Definition of Done - Ähnlich wie Definition of Ready ist dies eine Checkliste der Prinzipien, nach denen PM / PO erledigte Aufgaben akzeptiert.
Sinn : Erstellt vom Entwicklungsteam in Zusammenarbeit mit PM / PO zur Vorhersagbarkeit der Jobakzeptanzparameter. Jeder weiß, was das Kriterium der Aufgabe ist und was nicht.
In Abwesenheit : Ohne klare Kriterien erscheint die „Verfeinerung“ von Aufgaben nach Versuchen, sie zu bestehen. Oder die Aufgaben bleiben bis zu den endgültigen Anforderungen unvollendet.
Eine von beiden Parteien genehmigte Dokumentationsvereinbarung, mit der der PM / PO die Aufgabe und ihre Kriterien akzeptiert. Gut reduziert die Anzahl der kontroversen Punkte.
Verhindert, dass PM / PO den Pfosten unverschämt zerquetscht. Reduziert "erledigte" Aufgaben um 95%. Entwickler sollten die abgeschlossenen Aufgaben nach dem Sprint nicht beenden. Wenn die Aufgabe eindeutig nicht der Checkliste entspricht, sollte sie nicht als akzeptiert betrachtet werden und zum zukünftigen Sprint übergehen.
Überprüfung und Demonstration des Produktinkrements - eine Kundgebung, bei der Entwickler interessierten Parteien die Umsetzung des Sprintziels demonstrieren.
Das heißt : Entwickler selbst demonstrieren ein funktionsfähiges neues Produktinkrement. PM / PO überprüft formell die Aufgabenleistungskriterien und die DoD-Konformität. Die Stakeholder entscheiden, ob das neue Inkrement des Produkts den Sprint-Zielen entspricht.
In Abwesenheit : Das Fehlen einer formellen Demonstration und Akzeptanz der geleisteten Arbeit verringert den Wert der Akzeptanzkriterien und die Qualität der geleisteten Arbeit.
Beenden : Die Arbeit des Teams ist abgeschlossen. Die Stakeholder entscheiden, ob der nächste Sprint überhaupt stattfindet.
Die Demonstration der abgeschlossenen Aufgabe durch den Entwickler ist nützlicher und verständlicher als die unpersönliche Bereitstellung neuer Funktionen für einen Stakeholder zur Selbstanalyse. Und der Stakeholder sieht, wer die Arbeit für ihn erledigt hat, und die Entwickler sehen, für wen sie das Problem gelöst haben.
Sammlung von Bewertungen - Fortsetzung Überprüfung der Rallye.
Das heißt : Die Präsenz aller interessierten Parteien, des Teams und des Produkts an einem Ort ermöglicht eine informelle Kommunikation, um Ideen, Vorschläge usw. zu sammeln. Erhalten Sie Feedback zur Qualität des Teams.
In Abwesenheit : Die zugewiesene formelle Zeit reduziert unnötige Kontakte zwischen dem Team und den Stakeholdern während anderer Arbeitszeiten.
Ausgabe : neue Daten, Feedback.
Feedback ist im Allgemeinen eine nützliche Sache, auch Feedback von Stakeholdern zu ihren Erfahrungen mit Entwicklern. Grund für die Änderung der Interaktionsprozesse mit externen Akteuren. Die Verbesserung der Beziehungen zu aktuellen und zukünftigen Stakeholdern kann jederzeit genutzt werden - Aufträge, Budget, Konzessionen usw.
Sprint Retrospective N - Eine Rallye für das Entwicklungsteam und PM / PO.
Das heißt : Diskussion der Prozesse und Probleme des Teams während des letzten Sprints, ein Versuch, die Arbeitsprozesse zu ändern, um das Team zu verbessern. Welche Prozesse waren erfolgreich, welche haben keine Vorteile gebracht oder beschädigt, welche neuen Probleme sind aufgetreten und wie können sie behoben werden?
Ausgabe : Der Plan des Prozessexperiments. Prozesse werden beim nächsten Sprint geändert, um zu bewerten, welche Änderungen nützlich sind und welche verworfen werden sollten.
In Abwesenheit : Das Einpflanzen oder
Fehlen von Teamentwicklungsprozessen von oben verringert die Benutzerfreundlichkeit des Teams, die Produktivität und die Vorhersehbarkeit der Entwicklung.
Neben der banalen Diskussion über Probleme und wie sie gelöst werden sollten, möchte ich auf den „Plan des Prozessexperiments“ achten. Behandeln Sie die aufgezeichneten Prozesse nicht als in Stein gemeißelt - unveränderlich und konstant. Add new - test, mochte es nicht - schneide es ab.
Sprintende N.
Sprint N + 1 . Gießen Sie ein neues Inkrement in die Produktion
Das heißt : Aufgrund des häufigen Abschlusses des Sprints am Ende der Arbeitswoche erfolgt die Bereitstellung auf dem Produktionsserver und der Zugriff auf Benutzer bereits im nächsten Sprint, sodass am Wochenende keine potenziellen Probleme auftreten.
Das Inkrement wurde zur Überwachung der Parameter verwendet.