Programmierungsteam

A Programmierungsteam ist ein Mannschaft von Menschen, die sich entwickeln oder pflegen Computer Software.[1] Sie können auf zahlreiche Arten organisiert werden, aber die Egoless -Programmierung Team und Chefprogrammierteam waren gemeinsame Strukturen.[2]

Beschreibung

Ein Programmeam umfasst Menschen, die sich entwickeln oder pflegen Computer Software.[3]

Programmierteamstrukturen

Programmteams können auf zahlreiche Arten organisiert werden, aber die Egoless -Programmierung Team und Chefprogrammierteam werden zwei übliche Strukturen normalerweise verwendet.[2] Zu den Hauptdeterminanten bei der Auswahl der Programmierungsteamstruktur gehören in der Regel: Schwierigkeit, Größe, Dauer, Modularität, Zuverlässigkeit, Zeit und Geselligkeit.[2]

Egoless -Programmierung

Laut Marilyn Mantei berichten Personen, die Teil eines dezentralen Programmierteams sind, eine höhere Arbeitszufriedenheit.[2] Aber ein egolesses Programmierungsteam enthält Gruppen von zehn oder weniger Programmierern. Der Code wird ausgetauscht und Ziele sind unter den Gruppenmitgliedern festgelegt. Die Führung wird innerhalb der Gruppe entsprechend den Bedürfnissen und Fähigkeiten gedreht, die während einer bestimmten Zeit erforderlich sind. Das mangelnde Struktur im egolenen Team kann zu einer Schwäche der Effizienz, Effektivität und Fehlererkennung für großflächige Projekte führen. Egoless -Programmierteams eignen sich am besten für sehr komplexe Aufgaben.

Chefprogrammierteam

Ein Chefprogrammierteam wird normalerweise drei Personen Teams enthalten, die aus einem Chefprogrammierer, einem hochrangigen Programmierer und einem Programmbibliothekar bestehen. Bei Bedarf werden dem Team zusätzliche Programmierer und Analysten hinzugefügt. Die Schwächen dieser Struktur umfassen einen Mangel an Kommunikation zwischen Teammitgliedern, Aufgabenkooperation und komplexer Aufgabenabschluss. Das Chief Programmer Team arbeitet am besten für Aufgaben, die einfacher und unkompliziert sind, da der Informationsfluss im Team begrenzt ist. Personen, die in dieser Teamstruktur arbeiten, berichten normalerweise über eine geringere Arbeitsmoral.[2]

Gemeinsame Workstationsteams

Paar-Programmierung

Eine Entwicklungstechnik, bei der zwei Programmierer auf einer Workstation zusammenarbeiten.

Mob -Programmierung

Ein Softwareentwicklungsansatz, bei dem das gesamte Team gleichzeitig im selben Raum und auf demselben Computer an derselben Sache arbeitet.

Programmiermodelle

Mit Programmiermodellen können Softwareentwicklungsteams Projekte mithilfe dieser verschiedenen Methoden entwickeln, bereitstellen und testen.

Wasserfall-Modell

Das Wasserfallmodell, das als traditionellere bezeichnet wird[4] Ansatz ist ein lineares Produktionsmodell. Die Abfolge der Ereignisse dieser Methodik folgt:

  1. Anforderungen sammeln und dokumentieren
  2. Entwurf
  3. Code- und Unit -Test
  4. Systemtests durchführen
  5. Ausführen User Acceptance Testing (UAT)
  6. Probleme beheben
  7. Liefern Sie das fertige Produkt

Jede Phase ist während des Softwareentwicklungsprozesses unterschiedlich, und jede Phase endet im Allgemeinen, bevor die nächste beginnen kann.

Programme -Teams, die dieses Modell verwenden, können das Projekt frühzeitig im Entwicklungsprozess entwerfen, sodass Teams sich auf das Codieren und Testen während des Großteils der Arbeit konzentrieren können, anstatt das Design ständig wiederzuerlösen. Dies ermöglicht es den Teams auch, vollständig und sorgfältiger zu entwerfen, damit Teams ein vollständiges Verständnis für alle Software haben können Leistungen.

Agiles Modell

Das agile Entwicklungsmodell ist ein eher teambasierter Entwicklungsansatz[4] als das vorherige Wasserfallmodell. Teams arbeiten in schneller Lieferung/Bereitstellung, die die Arbeit in Phasen "Sprints" aufteilt. Sprints werden normalerweise als zwei Wochen geplante Software -Leistungen definiert, die jedem Team/Teammitglied gegeben wurden.

Nach jedem Sprint wird die Arbeit wiederholt und die Informationen, die aus dem vorherigen Sprint gelernt werden, werden für die zukünftige Sprintplanung verwendet. Nach Abschluss der Sprintarbeit kann sie vom Programmeam überprüft und bewertet werden und für eine andere Iteration (d. H. Nächster Sprint) zurückgesandt oder geschlossen werden, wenn sie fertiggestellt werden.

Die allgemeinen Grundsätze[5] des Agiles Manifest[6] sind wie folgt:

  • Befriedigen Sie den Kunden und entwickeln Sie die Software kontinuierlich.
  • Die Änderung der Anforderungen wird für den Wettbewerbsvorteil des Kunden angenommen.
  • Konzentrieren Sie sich darauf, Arbeitssoftware häufig zu liefern. Die Lieferpräferenz wird auf kürzester Zeitspanne platziert.
  • Entwickler und Geschäftsleute müssen während des gesamten Projekts zusammenarbeiten.
  • Projekte müssen auf Menschen basieren, die motiviert sind. Geben Sie ihnen die richtige Umgebung und die Unterstützung, die sie benötigen. Sie sollten vertraut werden, um ihre Arbeit zu erledigen.
  • Die persönliche Kommunikation ist der beste Weg, um Informationen an und von einem Team zu übertragen.
  • Arbeitssoftware ist die primäre Messung des Fortschritts.
  • Agile Prozesse fördern die nachhaltige Entwicklung. Sponsoren, Entwickler und Benutzer sollten in der Lage sein, ein unbestimmtes, konstantes Tempo aufrechtzuerhalten.
  • Die ständige Aufmerksamkeit für technische Exzellenz und gutes Design verbessert die Beweglichkeit.
  • Einfachheit wird als Kunst der Maximierung der nicht geleisteten Arbeit angesehen und ist unerlässlich.
  • Selbstorganisierte Teams schaffen normalerweise die besten Designs.
  • In regelmäßigen Abständen wird das Team darüber nachdenken, wie wir effektiver werden können, und es wird ihr Verhalten entsprechend einstellen und anpassen.

Siehe auch

Verweise

  1. ^ Jack Belzer, Albert George Holzman, Allen Kent (1. Oktober 1979), Enzyklopädie der Informatik und Technologie, vol. 13, ISBN 9780824722630{{}}: Cs1 montiert: Mehrfachnamen: Autorenliste (Link)
  2. ^ a b c d e Marilyn Mantei (März 1981). "Die Auswirkung von Programmierteamstrukturen auf Programmieraufgaben" (PDF). Kommunikation der ACM. Vol. 24, nein. 3. p. 106–113. Abgerufen 2019-03-26.
  3. ^ Jack Belzer, Albert George Holzman, Allen Kent (Oktober 1979), Enzyklopädie der Informatik und Technologie, vol. 13, ISBN 9780824722630{{}}: Cs1 montiert: Mehrfachnamen: Autorenliste (Link)
  4. ^ a b Mary Lotz (5. Juli 2018), Waterfall vs. Agile: Welches ist die richtige Entwicklungsmethode für Ihr Projekt?
  5. ^ Linchpin SEO -Team (26. März 2019), Ein Anfängerleitfaden für die Agile -Methode & Scrums
  6. ^ "Prinzipien hinter dem agilen Manifest". 2019-06-11.