Nach meinem Verständnis sind Product Owner, Scrum Master und Entwicklungsteam die Hauptrollen in einem Scrum-Team. Ich muss ein .Net Scrum Team mit 5-8 Mitgliedern aufbauen. Ich habe nicht genug Wissen über Scrum. Kann jemand bitte eine Lösung für diese Probleme geben?
Was sind die Schlüsselrollen, die in einem Scrum-Team sein sollten?
Scrum definiert nur drei Kernrollen für das Framework.
Ein Product Owner, dessen Rolle so etwas wie eine Verschmelzung eines traditionellen Produktmanagers und eines Projektsponsors ist, aber viel mehr Interaktion mit dem Entwicklungsteam hat, als eine traditionellere Rolle erfordern würde.
Ein Scrum Master, der als Prozessreferent sicherstellt, dass die Methodik befolgt wird. Ein Scrum Master ist auch dafür verantwortlich, das Team und die Organisation darin zu coachen, wie man das Beste aus den Prozessen und Artefakten von Scrum macht.
Der Scrum Master fungiert als Coach und führt das Team zu immer höheren Ebenen von Zusammenhalt, Selbstorganisation und Leistung. Während das Ergebnis eines Teams das Produkt ist, ist das Ergebnis eines Scrum Masters das sich selbst organisierende Team.
Sims, Chris; Johnson, Hillary Louise (2011-02-15). Die Elemente von Scrum (S. 74). Dymaxikon. Kindle-Edition.
Ein Entwicklungsteam, das eine kohärente, selbstorganisierende, funktionsübergreifende Gruppe ist, die alle erforderlichen Fähigkeiten enthält, um die Projektziele zu erreichen.
Scrum-Teams sind sehr kooperativ; sie organisieren sich auch selbst. Die Teammitglieder haben die volle Autorität darüber, wie die Arbeit erledigt wird. Das Team entscheidet allein, welche Tools und Techniken zum Einsatz kommen und welche Teammitglieder an welchen Aufgaben arbeiten.
Sims, Chris; Johnson, Hillary Louise (2011-02-15). Die Elemente von Scrum (Kindle-Standorte 976-978). Dymaxikon. Kindle-Edition.
Wer führt die Code-Reviews in einem Scrum-Team durch?
Code-Reviews sind eine Praxis, keine Rahmenanforderung und keine allgemein anerkannte. Siehe beispielsweise Code-Reviews gelten als verletzend .
Dennoch führen einige Scrum-Teams Code-Reviews ein, entweder weil sie während einer Sprint-Retrospektive als hilfreich identifiziert werden oder weil sie von der übergeordneten Organisation verlangt werden. Sofern die übergeordnete Organisation kein Mandat erteilt, ist die Handhabung von Code-Reviews eine Angelegenheit, die ein selbstorganisiertes Entwicklungsteam für sich selbst ausarbeiten muss.
Letztendlich ist das Ziel qualitativ hochwertiger, wartbarer Code. Wenn das Entwicklungsteam Code-Reviews hilfreich findet, um seine akzeptierte „Definition of Done“ zu erfüllen, ist das großartig. Wenn nicht, funktionieren testgetriebene Entwicklung oder andere Praktiken für ein bestimmtes Team vielleicht genauso gut (oder besser!).
Ihre Aufgabe ist es nicht, jemanden mit Code-Reviews zu beauftragen; Ihre Aufgabe ist es, den Prozess zu leiten, um sicherzustellen, dass das Team seine Praktiken kontinuierlich überprüft und anpasst.
Haben Scrum Teams eine Rolle namens Team Lead und Tech Lead?
Das Scrum-Framework fördert den kollektiven Besitz von Code, und das Team ist als Gruppe erfolgreich oder scheitert. Infolgedessen stehen Titel, die Teammitglieder unterscheiden, im Widerspruch zu den Grundsätzen von Scrum, obwohl sie dennoch von der Mutterorganisation in Stellenbeschreibungen und Personalakten verwendet werden.
Betrachten Sie es so: Wenn Sie Bob zum Teamleiter ernennen, übertragen Sie Bob die Verantwortung für bestimmte Leistungen. Warum sollte Alice Bobs Aufgaben übernehmen?
Wenn Sie Alice offiziell zur „QA-Person“ machen, warum sollte Alice dann die kollektive Verantwortung für den Code übernehmen oder an Architekturgeschichten arbeiten? Zweifellos wurde sie ins Team geholt, um sicherzustellen, dass dem Team einige spezialisierte QA-Kenntnisse zur Verfügung standen, aber „funktionsübergreifend“ bedeutet nicht isolierte Verantwortlichkeiten innerhalb des Projekts.
Teammitglieder haben Titel innerhalb der Organisation, die gelegentlich die Fähigkeiten widerspiegeln, die sie in ein Projektteam einbringen. Es ist jedoch Sache des Teams , sich selbst zu organisieren und die Verantwortung innerhalb des Teams zu verteilen. Als Scrum Master sollten Sie nur dann eingreifen, wenn es offensichtlich ist, dass das Team bei der Selbstorganisation versagt – was Sie daran messen, ob das Team seine Sprint-Ziele und die „Definition of Done“ erreicht oder nicht.
Die Zuweisung von Führungsrollen innerhalb des Teams ist keine agile Praxis und schon gar nicht Scrum. Wenn Sie sich in einer Situation befinden, in der dies erforderlich ist, sollten Sie auf jeden Fall Ihren Gesamtprozess überprüfen und versuchen, herauszufinden, was die Selbstorganisation des Entwicklungsteams behindert.
Um den Scrum-Leitfaden zu zitieren : „Scrum erkennt keine anderen Titel für Mitglieder des Entwicklungsteams als Entwickler an, unabhängig von der Arbeit, die von der Person ausgeführt wird; es gibt keine Ausnahmen von dieser Regel;“ Insofern wäre es kontraproduktiv, Entwickler auf bestimmte Pflichten zu beschränken. Die Idee ist, dass sich das Entwicklungsteam selbst organisiert, um Aufgaben zu erfüllen und Hindernisse zu überwinden, wenn Bedarf entsteht (und wenn Ressourcen verfügbar werden).
Was Code-Reviews betrifft, so gibt es viele Methoden zur Durchführung von Code-Reviews (siehe Kapitel 3 von Best Kept Secrets of Peer Code Reviews). Es liegt an Ihnen und Ihrem Team, die Code-Review-Methode(n) durchzuführen und zu bewerten, die die Kultur Ihres Teams am besten ergänzen (obwohl eine separate Qualitätssicherungsabteilung Metriken sammeln und analysieren kann, die bei der Bewertung der Effektivität einer Code-Review-Methode hilfreich sein können). . Wenn Sie Entwickler haben, die besser mit Clientcode umgehen können, kann es für sie von Vorteil sein, den Clientcode auf eine bessere Fehlererkennung hin zu überprüfen. Es kann auch für Entwickler, die mit dem Client-Code nicht vertraut sind, von Vorteil sein, ihn zu überprüfen, damit sie mit der Client-Seite vertrauter werden, falls sie in Zukunft eingreifen und Client-Programmierung durchführen müssen. Ein Vorteil von Agile und Scrum besteht darin, dass sich das Entwicklungsteam selbst organisieren kann, um verschiedene Code-Review-Methoden auf ihre Wirksamkeit zu testen. Trotzdem, Das Entwicklungsteam sollte für die Überprüfung des vom Entwicklungsteam erstellten Codes verantwortlich sein. Es kann auch ein externes Qualitätssicherungsteam geben, das den Code weiter überprüft, aber das ist für eine grundlegende Implementierung von Code-Reviews oder Scrum überhaupt nicht notwendig.
Was sind die Schlüsselrollen, die in einem Scrum-Team sein sollten?
Produkteigentümer, Entwickler und Mitarbeiter der Qualitätssicherung sind der Schlüssel zum Erfolg von .NET-Stack-basierten Projekten. Beachten Sie, dass ich die Rolle des Scrum Masters nicht erwähnt habe. Ich werde es später erklären.
Wenn das Team eine Web-API, eine ASP.NET MVC-Website, eine Desktop- oder eine .NET Xamarin Mobile-Anwendung entwickelt, sind Product Owner, Entwickler und Mitarbeiter der Qualitätssicherung alles, was Sie brauchen. Wenn Sie jedoch eine Cloud-basierte .NET-Lösung entwickeln, benötigen Sie auch die Rolle eines DevOps-Ingenieurs, der die Cloud verwaltet. Wenn Sie CICD verwenden, ist der DevOps-Ingenieur noch wichtiger, um CICD-Pipelines einzurichten.
Entwickler könnten eine Person mit Architekt-Rolle haben (mindestens 7 Jahre .NET-Erfahrung). Der Architekt wird eine Person sein, die Product Ownern hilft, das Feature richtig zu entwerfen, ihnen bei Story Points hilft und Entwickler bei Designentscheidungen unterstützt.
In ähnlicher Weise könnten Qualitätssicherungen Mitarbeiter haben, die für automatisiertes Testen wie xUnit, Selenium und JUnit qualifiziert sind.
Die Rolle des Scrum Masters ist wirklich nicht nützlich, es sei denn, die Person ist ein versierter Software-Produktmanager. Anstatt einen Scrum Master einzustellen, stellen Sie einen Agile Coach ein, der das Team unterstützt. Wenn alle Scrum Master Personen zu bestimmten Zeiten auf Zoom, Skype oder an einem Ort in einem Büro versammeln, sollten sie besser durch Google Kalender-Benachrichtigungen ersetzt werden. Software-Teams schaden am meisten, wenn der Top-Mann kein versierter Software-Profi ist. Jemand muss JIRA oder ein ähnliches Ticketsystem verwalten. Scrum Master könnte als Nachverfolgungsrolle für Tickets, Roadmaps, Releases, Meilensteine und Ergebnisse verwendet werden.
Wer führt die Code-Reviews in einem Scrum-Team durch?
Der Architekt oder normalerweise 2 andere Teammitglieder überprüfen den Code.
Haben Scrum Teams eine Rolle namens Team Lead und Tech Lead?
Entwickler sollten eine Kombination aus Praktikanten, Junior-Entwicklern, Senior-Entwicklern, technischen Leitern und Architekten sein.
Normalerweise gibt es kleine Teams von 1 Praktikanten, 1 Junior Developer, 2 Senior Developers und 1 Tech Lead. Wenn Sie 2 solcher Teams haben, dann 1 Architekt, um die Diskussion zwischen diesen beiden Teams zu vermitteln.
Jedes Team sollte 1 Product Owner haben. Wenn es mehr als einen Product Owner gibt, wird einer der Lead Product Owner. Der Product Owner ist die wichtigste Einzelrolle. Er erstellt Stories und priorisiert Backlogs. Wenn Entwickler keine Storys erhalten, können sie sie nicht entwickeln und die QA kann sie nicht richtig testen. Es ist besser, 2 Produktpraktikanten bei jedem Product Owner zu haben, um das genaue Schreiben der Geschichte zu erleichtern.
Wenn die Arbeit intensiv ist, sollte jedes 5-Entwicklerteam 1 QA-Mitarbeiter und 1 Site Reliability Engineer oder DevOps-Ingenieur haben.
Mike Robinson