Was agile Entwicklung NICHT ist
Inhaltsverzeichnis
Autor Patrick Becka –> Übersetzung Thomas Arends
Bei verschiedenen Gelegenheiten war ich in Meetings mit Geschäftsleuten und Softwareexperten involviert und stellte fest, dass beide Parteien ein grundlegendes Missverständnis darüber haben, was agil bedeutet und was nicht.
Beginnen wir also im Hinblick auf das Agile Manifest mit dem, was Agile nicht sagt:
Einzelpersonen und Interaktionen über Prozesse und Werkzeuge
Was das NICHT bedeutet:
Prozesse und Tools spielen keine Rolle.
Prozesse ermöglichen es Unternehmen, im Laufe der Zeit zu lernen und sich zu verbessern, und die Einhaltung von Verfahren führt zu reproduzierbaren Ergebnissen. Werkzeuge können die Art und Weise, wie ein Team Probleme erkennt und auf sie reagiert, grundlegend ändern.
Wie das alte Sprichwort besagt: Wenn das einzige Werkzeug, das Sie haben, ein Hammer ist, sieht jedes Problem wie ein Nagel aus.
Arbeitssoftware über umfassende Dokumentation
Was das NICHT bedeutet:
Dokumentation ist altmodisch / überbewertet.
Beachten Sie zunächst das Qualifikationsmerkmal „umfassend“:
Jedes Detail jeder Zeile Quellcode muss nicht kommentiert / dokumentiert werden, und es muss nicht jede Anforderung auf Mikroebene formuliert werden.
Ohne ausreichende Dokumentation werden Ihre Anforderungen jedoch nicht ausreichen, und dies führt zu Zeitverschwendung bei der Erfüllung der Anforderungen oder sogar zu noch schlimmeren, dies kann zu noch zeitaufwendigeren und teureren Revisionen Ihrer Software führen.
Wenn Sie nicht wissen, wo Sie sich befinden, ist es sehr schwer herauszufinden, wie Sie dorthin gelangen, wo Sie hin möchten.
Und vergessen Sie nicht, dass die Menschen krank werden, aufhören und in den Ruhestand gehen:
Nehmen Sie genau das Produkt- und institutionelle Wissen mit, das für den Rest des Teams erforderlich ist, um ihre Arbeit ununterbrochen fortzusetzen.
Zusammenarbeit des Kunden bei Vertragsverhandlungen
Was das NICHT bedeutet:
Vertragsbedingungen sind nicht wichtig.
Sie sind. Sie können jedoch breit genug sein, um zu erkennen, dass die genauen Ergebnisse nicht im Voraus festgelegt wurden (weil sie nicht vollständig bekannt sind, wenn die Arbeit beginnt).
Und wenn beide Seiten wirklich zusammenarbeiten und vernünftig sind, sollten beide am Ende zufrieden sein.
Machen Sie keine Geschäfte mit Menschen, die nicht verstehen, wie Software geliefert wird.
Nach einem Plan auf die Umstellung reagieren
Was das NICHT bedeutet:
Planung ist nicht erforderlich.
Pläne sind wichtig, sollten aber normalerweise nicht in Stein gemeißelt werden.
Die Pläne für einen bestimmten Zeitraum müssen dokumentiert werden, um zu wissen, wer an was arbeitet, um Abhängigkeiten usw. zu erkennen.
Aber auch kurzfristige Pläne können geändert werden, wenn das Unternehmen Änderungen verlangt.
Schließlich wird das Produkt des Teams nicht um seiner selbst willen hergestellt – es wird so gebaut, dass es den Anforderungen des Unternehmens gerecht wird.