Kommentar: "Wir lieben PHP."
Kommentare

PHP geht uns alle an – das gilt auch für den PHP Release-Prozess. Ein Kommentar unseres Chefredakteurs Björn Schotte zu diesem Thema.

Björn Schotte Chefredakteur

Wir lieben PHP. Die halbe Welt

PHP geht uns alle an – das gilt auch für den PHP Release-Prozess. Ein Kommentar unseres Chefredakteurs Björn Schotte zu diesem Thema.

Björn Schotte, Chefredakteur Björn Schotte Chefredakteur

Wir lieben PHP. Die halbe Welt liebt PHP. Irgendwie kommen wir sogar mit den eher unregelmäßigen Releases zurecht, getreu dem Motto: „It’s done when it’s done.“

Feste Releasetermine sind in einer weltweit verstreuten Gruppe von Freiwilligen nicht ganz unproblematisch. Einige könnten Druck empfinden oder haben vielleicht Bedenken, zum Release-Termin nicht ganz fertig zu werden. Wie wird die halbe Welt reagieren, wenn ein kommunizierter Releasetermin nicht stattfindet oder eine in der Außensicht besonders wichtige Funktionalität nicht rechtzeitig implementiert wurde?

Doch auch in fest abgesteckten Grenzen, in der agilen Welt mit dem Begriff „time boxed“ umschrieben, lässt es sich flexibel arbeiten. Hierbei wird die Rolle des Release Managers gestärkt, der nun auch mit der „Außenwelt“ intensiver kommunizieren muss und über Änderungen am Releaseplan proaktiv und sehr frühzeitig informiert.

Nicht dass ein Release komplett verschoben werden müsste. Vielleicht schaffen es dann auch nur weniger Features & Bugfixes in diese Veröffentlichung, der Rest verschiebt sich auf das nächste Release.

Alles in allem hilft ein periodischer Release-Cycle allen im Prozess beteiligten Stakeholdern:

  • Releases werden für alle planbarer
  • Releases werden zuverlässiger
  • die Qualität innerhalb eines Releases kann steigen – „weniger ist manchmal mehr“
  • Releases können stabiler werden, wenn gleichzeitig eine sinnvolle QA-/QS-Definition und ein stärkeres Peer Review existiert, sodass nicht „unfertige“ Dinge auf den letzten Drücker ins Release einfließen
  • man lernt, in einem gewissen Takt zu arbeiten

Ich kann mir gut vorstellen, dass es sinnvoll sein kann, solch einen time-boxed-Prozess über einen gewissen Zeitraum – 1 Jahr? – einmal auszuprobieren und ganz wie in der agilen Welt danach ein Review und eine Retrospektive durchzuführen.

Was lief gut? Was lief schlecht? Was könnte noch verbessert werden? Mit großen Plänen verbaut man sich möglicherweise gute Wege und blockiert. Daher eine iterative Vorgehensweise.

Letztlich gewinnen damit alle.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -