Teil 5: Der Senior Software Engineer
In Scrum ist es am besten, wenn in jedem Sprint alle Teammitglieder vertreten sind, die für die Umsetzung der User Stories in diesem Sprint benötigt werden. Die meisten Mitglieder werden entweder Entwickler oder Tester sein. Einige von ihnen werden eine größere Rolle bei der Bereitstellung eines potenziell auslieferungsfähigen Produkts spielen. Ein Grund dafür ist, dass sie vom ersten Sprint an in den Prozess eingebunden sind. Dies hat zur Folge, dass diese Teammitglieder gegenüber anderen Teammitgliedern einen höheren Stellenwert einnehmen, da sie über tiefere Kenntnisse des zu entwickelnden Systems verfügen. Sie werden mehr als andere vom Product Owner und dem Scrummaster konsultiert. In unserem Prozess vom "Konzept zum Geld" nennen wir sie Senior Software Engineers (SSE). Wie verhält sich ein SSE zum Technical Product Owner (TPO)?

Der technische Product Owner
Wie wir in einem früheren Beitrag gesehen haben, ist der TPO das technische Gegenstück zum Product Owner. Einerseits richtet sich seine Aufmerksamkeit auf die Zukunft: welche Projekte auf der Portfoliowand stehen und welche Epen umgesetzt werden müssen. Andererseits achtet er darauf, woran die Teams jetzt arbeiten und wie er die Teams dazu anleiten kann, die richtigen Dinge FERTIG zu machen. Wie ergänzt die SSE den TPO?
Sparringspartner der TPO
Während der TPO nur mit einem Bein im Team ist, spielt der SSE die Rolle des Vorarbeiters des Teams. Als solcher hat er beide Beine im Team. Im Allgemeinen ist er ein erfahrener Entwickler, der nicht nur über ausgezeichnete technische Fähigkeiten verfügt. Er kennt sich auch mit dem spezifischen Geschäftsfeld aus. Er kann der Sparringspartner des TPO und des PO sein und ist es oft auch, um die User Stories READY zu machen. Normalerweise organisiert der PO eine READY-Sitzung, um die Teammitglieder über die anstehenden User Stories zu informieren und sie die Stories einschätzen zu lassen. Vor dieser Sitzung wird der SSE oft vom PO und TPO konsultiert, um die Stories zu besprechen.
Vermittler für die Teams
Während eines Sprints muss das Team manchmal wichtige Designentscheidungen treffen. Für das Team und insbesondere seine weniger erfahrenen Mitglieder ist es verlockend, dies der SSE zu überlassen. Eine bewährte Praxis in Scrum ist jedoch, dass jedes Teammitglied gleichberechtigt ist. Wie kann der SSE also seine Erfahrung nutzen, um das Team als Ganzes die Entscheidung treffen zu lassen? Die Antwort liegt darin, den Prozess zu erleichtern, anstatt vorzuschreiben, wie die Technologie implementiert werden sollte. Eine Möglichkeit, dies zu tun, ist das Coaching oder Mentoring der einzelnen Teammitglieder in ihren technischen Fähigkeiten. Auf diese Weise wird das Wissen unter allen Teammitgliedern geteilt und alle (oder zumindest die meisten) Teammitglieder werden die gewählte Designentscheidung unterstützen. Ein interessanter Nebeneffekt ist, dass der SSE auf diese Weise die jüngeren Teammitglieder dazu anregt, zu wachsen und mehr Selbstvertrauen zu gewinnen.
Kommunikation mit anderen Teams
Sind die Entwicklung von Software und die Betreuung von Nachwuchsentwicklern die einzigen Aufgaben eines SSE? Zum Glück nicht. Es gibt noch viele weitere Aufgaben, von denen ich eine erwähnen möchte: die Kommunikation mit anderen Teams. In einer Organisation, in der es mehrere Teams gibt, ist die Kommunikation über technische Aspekte der Arbeit erforderlich. Denken Sie an die in einem Team gewählten Frameworks und die vom Team getroffenen Designentscheidungen. Diese müssen kommuniziert werden, damit andere Teams davon profitieren können. Aufgrund seiner Seniorität kann der SSE die Führung übernehmen, um dies zu arrangieren.
Der Senior Operations Engineer
Beim nächsten Mal werden wir uns mit dem Senior Operations Engineer und seiner Beziehung zum Technical Product Owner und dem Senior Software Engineer befassen. Bleiben Sie dran...
Mehr aus dieser Serie
- How to Kill the Architecture Department - Part 1
- How to Kill the Architecture Department - Part 2
- How to Kill the Architecture Department - Part 3
- How to Kill the Architecture Department - Part 4
- How to Kill the Architecture Department - Part 5
- How to Kill the Architecture Department - Part 6
- How to Kill the Architecture Department - Part 7
Verfasst von
Herbert Schuurmans
Unsere Ideen
Weitere Blogs
Contact



