Noch ein paar Worte zu Scrum und dem Agilen Manifest / Sudo Null IT News

Menschen neigen dazu, mit der Zeit zu vergessen, woher alles kam, also müssen Sie sich daran erinnern. Die Veröffentlichung wurde inspiriert durch den Artikel „Warum Scrum nicht verwendet werden sollte, wo es nicht notwendig ist – die Einschränkungen und Annahmen des Frameworks“.

Das ist natürlich meine Interpretation, aber sie basiert auf einem enormen Maß an Studienzeit, Selbststudium und Erfahrung in der Branche.

Es ist klar, dass es hier nur um Softwareentwicklung geht. Und die Entwicklung ist lang (bei kurzen Projekten gibt es viele Möglichkeiten, irgendwo Abstriche zu machen).

Die ideologische Grundlage des Agilen Manifests (auch bekannt als ein ehrliches und verständliches Agiles Manifest):

  1. PMBoK und andere klassische Projektmanagementmethoden liefern keine ausreichenden Ergebnisse. In ihrem Ofen.

  2. Bisher hat die Menschheit keine Möglichkeit, Projekte erfolgreich abzuschließen. Daher erwarten wir, dass wir dies nicht tun werden (wir müssen etwas in der Pyramide von Zeit, Funktionalität, Kosten und Qualität bewegen).

  3. Wir halten es für sinnvoll, nur das Funktionale in der Pyramide zu verschieben. Mit anderen Worten, wir garantieren nicht, wofür wir Zeit haben, aber wir garantieren alles andere.

  4. Wir erledigen zuerst die kritischsten Funktionen, dann die weniger kritischen. Wir machen die Funktionalität so, dass alle optionalen Dinge auf später verschoben werden, damit wir schnell zu der Situation eines minimal funktionierenden Produkts kommen (und von dieser Phase aus mit der Verbesserung beginnen können). Somit wird zu jedem Zeitpunkt der Maximalwert für die Kosten ausgegeben.

  5. Wir garantieren, dass wir so aktiv wie möglich arbeiten werden. Dafür schaffen wir maximale Transparenz für den Kunden.

  6. Wir garantieren, dass wir uns bemühen, unsere Arbeitsweise ständig zu analysieren und zu verbessern.

  7. Wir garantieren, dass wir in kleinen Iterationen liefern, um uns schnell anpassen zu können.

  8. Wir unterstützen nachdrücklich die Änderung des TOR, um genau das zu tun, was erforderlich ist, und nicht das, was vor Beginn des Projekts klar war.

  9. Wir erwarten eine starke Kundeneinbindung in den Entwicklungsprozess, as dies ist eines der gemeinsamen Merkmale erfolgreicher Projekte.

Warum haben sie nicht einfach so etwas geschrieben? Offensichtlich war es kein Ziel, es einfach und verständlich zu machen. Oder sie haben einfach geschrieben, was und wie sie es geschafft haben. Trotzdem ist es sehr schwierig, sich unter 17 Personen auf etwas zu einigen (und alle haben große Erfahrung).

Mit anderen Worten: Es gibt keine Möglichkeiten -> und es wird keine von uns geben -> dass wir Zeit für Funktionalität haben -> Kompensation für ein solches Vorgehen.

Diese 9 Punkte entsprechen den 4 Punkten des Manifests. 12 Grundprinzipien stimmen in einem Punkt nicht überein („Die besten Anforderungen, architektonischen und technischen Lösungen entstehen aus sich selbst organisierenden Teams.“). Genauer gesagt wird dieser Punkt aus Klammern gesetzt: Es könnte Zehnter werden, aber ich habe starke Zweifel daran – ich kenne die Daten für unser Land nicht (und ich möchte es nicht ohne Beweis sagen) und ich Ich habe in der Praxis nicht gesehen, wie man solche Teams effektiv aufbaut (ich wollte keine unrealisierbaren Anforderungen stellen – wie Code ohne Fehler schreiben und es wird keine Probleme geben).

Normalerweise sind die umstrittensten Punkte 2 und 3. Schauen wir sie uns genauer an.

Erfahrene Kunden wissen, dass Projekte meistens scheitern. Das bedeutet aber nicht, dass alle für den agilen Ansatz bereit sind. Es ist auch ein sehr häufiger Ansatz, wenn die Entwicklung selbst für den Auftragnehmer letztendlich unrentabel ist und der Gewinn aufgrund des überhöhten Preises der Unterstützung erzielt wird. Es kommt vor, dass der Auftraggeber den Auftragnehmer ganz bewusst ruiniert, nur weil er ein unerfahrener Anfänger ist. Hier gibt es kein bestimmtes Rezept, aber die meisten internen Projekte enden entweder bei einem agilen Ansatz oder übersehen einfach das ständige Scheitern von Projekten („So ist das Leben“, und ohne Ausgleichspunkte von Agile). Bei kundenspezifischen Projekten gibt es einen anderen Ansatz: Tiefe Spezialisierung des Performers, dann macht er im nächsten Projekt nichts Neues für sich und kann das Projekt angemessen bewerten.

Eine andere Frage: Warum nur Funktionalität und nicht 3 andere Eigenschaften? Betrachten wir:

  1. Preis. Normalerweise gibt es ein gewisses Budget, und es ist äußerst unangenehm, es zu überschreiten. Wenn Sie beispielsweise das Team mitten im Projekt um das Zweifache vergrößern, ist dies nicht so effektiv.

  2. Zeit. Normalerweise hängt die Zeit ziemlich stark von den Kosten ab. Und oft gibt es Verbindungen zu anderen Abteilungen, die das Produkt bis zu einem bestimmten Termin erwarten. Daher ist es ziemlich selten, die Zeit zu verschieben.

  3. Qualität. Komplexe Materie. Sie lässt sich in 2 Aspekte unterteilen: Qualität für den Anwender und Qualität für die Weiterentwicklung. Wenn wir lange spielen, dann versuchen wir, die notwendige Qualitätsmesslatte anzulegen und auch weiterhin einzuhalten. Die Verschlechterung der Qualität, um mit dem Projekt Schritt zu halten, führt zu weiteren Problemen.

  4. Funktionell. Funktionalität ist eine äußerst flexible Sache in der Software. Es kann ziemlich aufgeteilt werden, schnelle und wichtige Dinge hervorheben, langsame und nicht so wichtige Dinge hervorheben, das Ganze priorisieren. Sie können sogar hochrangige Projektziele ohne einige bequeme und wichtige, aber unkritische Dinge erreichen. Mit anderen Worten: Hier liegt ein riesiges Potenzial, das wir nutzen wollen.

Noch versteht nicht jeder, dass „was die Funktionalität geschafft hat“ tatsächlich einen Zeit- und Kostenanstieg bedeuten kann, wenn der Kunde ein zusätzliches Budget genehmigt. Gleichzeitig liefern wir auf jeden Fall etwas, das bereits verwendet werden kann, nur vielleicht noch nicht so effektiv ist, wie wir es uns wünschen.

Was ist mit Scrum? Dies ist eine der Implementierungen des Agilen Manifests. Erhielt hohe Popularität für die Kürze und Klarheit der Artefakte/Aktivitäten.

Gleichzeitig wird Scrum sehr oft ohne Scrum implementiert. Wie ist es passiert? Der gesamte Kernprozess wird implementiert, jedoch ohne den Scrum Master. Ja, das kann und wird sogar agil sein. Es muss nur irgendwie nicht Scrum heißen.

Der Scrum Master ist ein Verhandler ohne IT-Kenntnisse. Für interne Teams kann es ein durchschnittliches Niveau sein (und merklich weniger Projektleiter, Abteilungsleiter, Teamleiter etc. erhalten – das ist eine der Bedeutungen). Die Hauptaufgabe: die Interaktion aller am Projekt Beteiligten (sowohl innerhalb des Teams als auch in den Außenbeziehungen) herzustellen. Es besteht kein Entscheidungsrecht (wobei auch hier die fehlenden IT-Kenntnisse hilfreich sind). Scrum-Events dienen als einer der Ausgangspunkte für regelmäßige Kommunikation.

Warum wird Scrum normalerweise nicht implementiert? Auch in internen Teams fordern viele Führungskräfte Eigenverantwortung für das Teamergebnis und wollen den Teamfortschritt in Zwischenphasen nicht zu genau betrachten. Wir brauchen Berichte an das Management oben, aber der Scrum Master weiß nicht, wie er sie schreiben soll (wenn das ein normaler Scrum Master ist, alias ein Absolvent der Fakultät für Psychologie). Daher werden eher teure Projektmanager statt Scrum Master genommen, die am Ende kein Ergebnis liefern, sondern aus irgendeinem Grund viel Papier geben, was passiert ist ein Erfolg.

Ein separates Problem von Scrum ist die Scrum Alliance und zahlreiche Coaches. Obwohl, vielleicht liegt es an ihnen, dass Scrum so viel Anerkennung erlangt hat (auch wenn es nur wenige Leute wirklich umsetzen).

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *