Freitag, 6. Juni 2014

Wir gründen eine virtuelle Firma.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Im letzten Post habe ich beschrieben, warum ein starres Rollenkonzept effizienter Softwareentwicklung im Wege steht. Arbeitsteilung, die die Kommunikation im Team aufhebt und kleine Entscheidungsgötter schafft, ist zu vermeiden. Am Ende des Posts übernahm ich von [TOTH14] den Begriff des Owners. Ein Owner spezialisiert sich in bestimmte fachliche Richtungen, sammelt Erfahrungen, bildet sich weiter, berät das Team, ist Ansprechpartner für das Thema. Diese Zuordnung ist nicht als starrer Posten zu verstehen, den es zu halten gilt, komme was da wolle. Am Ende gilt die Arbeitsleistung des Teams, welches sich aus Individuen zusammensetzt, die sich über die Zeit weiterentwickeln und verändern.

Mithilfe dieses Ownerkonzeptes möchte ich einen kleinen virtuellen Betrieb konstruieren. Dieses Gedankenexperiment soll einer anschaulicheren Darstellung der Prozesse in der Softwareentwicklung dienen. Es besteht die Möglichkeit, mit konkreten Spielfiguren bestimmte Situationen nachzustellen. Am Anfang werden wir nur Teile der Firma aufbauen. Mit der Zeit werden mehr und mehr notwendige Stellen hinzukommen. Initial hat sich eine Gruppe zusammengefunden, die sich als Ziel gesetzt hat, gemeinsam mit Hilfe von Scrum Software zu entwickeln. Sie haben das große Glück eines Auftraggebers, für den sie über mehrere Jahre eine Produktpalette aufbauen sollen. (Das Ganze ist natürlich entstanden, weil ein Mitglied der Gruppe und ein hohes Tier des Auftraggebers Freunde sind. :-))

Die Gruppe besteht aus sechs Personen. Am Anfang durchlaufen sie eine Teambildung als bewussten Prozess. Während dieses Prozesses stellen sie fest, dass einzelne Mitglieder des Teams sich in spezifische fachliche Richtungen entwickeln wollen und dabei auch schon ein erhebliches Vorwissen angesammelt haben. Bei dem zu erstellenden Produkt handelt es sich um eine Webanwendung. Folgende Spezialisierungen werden im Team ermittelt: Requirements Engineering, Softwarearchitektur, Useability Engineering, Datenbank, Testen und Continuous Integration. Alle anderen Aufgaben unterliegen erst einmal keiner Spezialisierung.

In Scrum selbst gibt es drei klassische Rollen, den Product Owner, den Scrum Master und das Team. Als Scrum Master wird ein Freelancer angeheuert, der in anderen Projekten schon bewiesen hat, dass seine Erfahrungen mit Scrum exzellent sind. Dieser hat das Team solange zu begleiten und zu beraten bis es selber läuft. Es ist also eine Rolle auf Zeit, die sich, wenn es gut geht, selbst beseitigt. Eine dauerhafte Rolle ist der Product Owner. In Scrum ist das eine Art Superrolle, die kaum ein Mensch ausfüllen kann. Er müsste Produktmanager, Requirements Engineer und Softwarearchitekt in Einem sein. "Der Product Owner ist für das Erfassen der Kundenbedürfnisse und die Beschreibung der Anforderungen verantwortlich." [S.10, PICH08] "Der Product Owner ist in Scrum für das Erreichen der Projektziele und damit für den Erfolg des Projekts (return on investmen, ROI) verantwortlich." [S.10, PICH08] Außerdem muss er eng mit dem Team zusammenarbeiten, das Stakeholder-Management erledigen und Chef Engineer sein. Eine solche Konzentration ist in einer Person kaum möglich.



In meiner Organisation sitzt der Product Owner einem Gremium vor, in dem auch die Teammitglieder sitzen, die sich für das Requirements Engineering und für die Softwarearchitektur entschieden haben. Dieses Gremium bildet also auch ein Team und es bildet das Gegenüber des Entwicklungsteams. Hauptsächlich ist der Product Owner der Interessenvertreter der Ansprüche des Kunden, die er gegenüber dem Entwicklerteam zu vertreten hat. Durch die Doppelmitgliedschaft des Requirements Owners und des Architecture Owners ist eine durchgängige direkte Kommunikation gewährleistet. Theoretisch kann ein solches Gremium zwei Entwicklerteams betreuen. Es hätte dann zwei Product Owner, zwei Requirements Owner und zwei Architecture Owner. In der Produktion können wir also bis zu 14 Personen organisieren, ohne eine Hierarchie aufzubauen. Bei größeren Zahlen müssen wir einfache Verknüpfungen der Gremien finden, um die steigende Komplexität im Griff zu behalten. Darum machen wir uns jedoch später Gedanken.

Falls das Gremium nur 3 Mitglieder hat, können bis zu drei Teammitglieder oder Kundenvertreter zu entsprechenden Meetings hinzugezogen werden. Ein Meeting mit mehr als 6 Personen würde ich vermeiden, damit wirkliche Diskussionen entstehen und nicht Frontalunterricht und schlafende Mitarbeiter das Bild beherrschen. Ganz wichtig ist auch eine Arbeitsumgebung, die eine kreative Arbeitsweise fördert. In unserer Firma gibt es zwei Räume, in denen in Ruhe gearbeitet werden kann und es gibt einen Raum für die gemeinsame Entwicklung. In einem speziellen Raum können Telefongespräche durchgestellt und geführt werden. Somit werden die Entwickler nicht aus ihren Gedanken gerissen. Für das gemeinsame Arbeiten sind Verhaltensweisen vereinbart, die auf den Einzelnen Rücksicht nehmen und nicht an die Belastbarkeit appellieren. Außerdem gibt es natürlich eine Sanitäreinheit und ganz wichtig, die Küche als sozialen Treffpunkt mit funktionierender Kaffeemaschine und wahlweise Teeautomat. Im weiteren Verlauf wird unsere kleine virtuelle Firma weiteres Personal benötigen. In diesen Fällen werde ich den Raumplan weiter ausbauen.



Ein wichtiger weiterer Posten ist die Reinigung unserer Räume. Zwar haben auch wir externe Reinigungskräfte beauftragt, trotzdem möchte ich hier die Bedeutung dieses Jobs hervorheben. Eine saubere, helle und freundliche Atmosphäre steigert die Arbeitsleistung emotional empfindender Menschen. Auch hier wird deutlich, dass es viele Aufgaben gibt, deren Bedeutung wir oft mindern, ohne uns bewusst zu sein, welchen Schaden wir damit anrichten. Ein kleines Dankeschön an die Reinigungskräfte haben wir in unserer virtuellen Firma also eingeplant. Ist ein zwischenmenschliches Band entstanden, sollten wir sie auch zu unseren Firmenfeierlichkeiten einladen.

Im nächsten Post beginnen wir mit der Vision zu einem Produkt. Die oben erwähnten Freunde haben ein Netzwerk geknüpft, welches eine solide Geschäftsbasis darstellt. In lockerer Atmosphäre entstehen erste Gedanken und ein großes Ziel. Doch dazu später mehr.

  • [PICH08] Roman Pichler: "Scrum - Agiles Projektmanagement erfolgreich einsetzen", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2008
  • [TOTH14] Stefan Toth: "Vorgehensmuster für Softwarearchitektur", Carl Hanser Verlag, München, 2014


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen