3 Gründe, warum Agile NICHT die Lösung für Ihre Projektmanagement-Probleme ist

Unternehmen, die es nicht schaffen, eine Projektmanagement-Methodik im Unternehmen zu implementieren, setzen auf Agilität.

Haben Sie versucht, eine Projektmanagement-Methodik im Unternehmen einzuführen, aber das Ergebnis war katastrophal?

Haben Sie gehört, dass es mit der agilen Methodik möglich ist, eine kürzere Markteinführungszeit als Ihr Softwareprojekt zu haben, und glauben Sie daran?

Sind Ihre Projekte, die Sie mit einer traditionellen PM-Methodik wie PMP oder Prince2 zu verwalten versucht haben, alle zu spät und über dem Budget gelandet?

…e stai ora pensando di adottare agile.

Einen Punkt möchte ich gleich klarstellen: Agil bedeutet nicht billiger. Agil bedeutet nicht schneller. Agil bedeutet nicht bessere Qualität.

Agile basiert auf 3 Annahmen:

  1. Das zu erledigende Aufgaben und die zu entwickelnden Features sie können sich ändern während des Projekts ohne Kontrollsystem o Genehmigungsbedarf durch den Projektsponsor und ohne Change-Management-System.
  2. Es gibt keinen Projektleiter verantwortlich für das Projekt in seiner Gesamtheit, sondern nur von den Moderatoren oder Koordinatoren, die zusammen mit dem Kunden entscheiden, was in jedem Sprint entwickelt werden soll.
  3. Dort Projektdokumentation es muss sein minimiert.

Problem Nummer 1: Entwicklungskosten

Zuerst die Implementierungskosten eines Projekts im agilen Modus sie sind nicht kontrollierbar per Definition: Erstens, weil es keinen Projektleiter gibt, geschweige denn einen Projektsteuerungsfunktion. Mentre nelle metodologia di project management tipo PMI l’attività di Project control è presente e può essere in carico al Project Manager o ad una figura dedicata a seconda della dimensione del progetto.

Problem Nummer 2: Lieferzeiten

Siccome le specifiche di un prodotto possono variare nel tempo anche da sprint a sprint, in generare ogni due settimane, i tempi di consegna di un prodotto sono potenzialmente infiniti. Sta al buon senso del team e del Product owner di non cambiare troppo spesso idea o di cercare di tenere il timone dritto al fine di andare live con qualche cosa. Nella metodologia PMI ma anche Prince 2, i cambiamenti di specifiche o di “scope” devono essere richieste e approvate dal team di controllo del progetto che può essere uno steering committee o il project sponsor.

Agiles Problem 3: Qualität (oder Projektumfang)

Da sich die Produktanforderungen im Laufe der Zeit ändern können, spiegelt das Endprodukt nicht unbedingt die ursprüngliche Kundenanforderung wider. Agile geht davon aus, dass der Kunde ein integraler Bestandteil des Projekts ist und zum Projekt beiträgt, indem er an Stand-up-Meetings teilnimmt, über Prioritäten entscheidet und Änderungen direkt genehmigt. Aber in Wirklichkeit ist der Kunde entweder nicht anwesend oder nicht angemessen vertreten, lassen Sie mich erklären, in Stand-up-Meetings könnte es einen Kundenvertreter geben, der nicht über ausreichende Entscheidungsbefugnisse oder Erfahrung verfügt. Klingt bekannt?

Die Produktqualität wird durch die Anwendung der agilen Methodik nicht verbessert, da sie keine Definition von Spezifikationen vorsieht, an denen die Produktqualität gemessen werden kann. Mit anderen Worten, weniger Projektdokumentation = weniger Möglichkeit, zu überprüfen, ob das Produkt die Qualitätskriterien erfüllt, weil die Projekt- und Produktspezifikationen fehlen. Zum Beispiel ein BRD.

Agiles Problem 4: Verantwortlichkeit

Bei Agile liegt die Verantwortung beim Team, das sich aus Entwicklern und einer Geschäftsfigur zusammensetzt. Wenn das Projekt hinter dem Zeitplan oder dem Budget liegt, wer ist verantwortlich? Es ist keine rhetorische Frage. In einer RACI-Matrix lautet die Regel Nummer eins, dass nur eine Person verantwortlich ist, es muss einen Grund geben, richtig?

Willkommen sich ändernde Anforderungen

Agiles Manifest https://agilemanifesto.org/principles.html

Ma sì! …cambiamo i requisiti anche ogni giorno, tanto paga il cliente.

Markteinführungszeit

Die Markteinführungszeit ist nicht kontrollierbar, die Möglichkeit, die Richtung des Projekts kontinuierlich zu ändern, kann verhindern, dass das Produkt in Produktion geht, da sich die Gründe für die Gleichheit ändern.

Komplexe Projekte mit Agile

Agile diventa poi particolarmente inefficace quando si tratta di implementare un progetto complesso come il re-platforming di un sito ecommerce. Immaginate di dover migrare un sito ecommerce da una piattaforma and un’altra supponiamo da Magento a Salesforce.

Aber denken wir auch an den Bau eines Schiffes oder einer Brücke, Agile behauptet, dass ein Produkt entwickelt werden kann, ohne die Details zu kennen, bevor es entwickelt wird. Dies ist sicherlich nicht mit einem physischen Produkt möglich, aber es ist nicht einmal mit einer komplexen Software möglich Produkt oder ein Softwareprodukt, das gesetzlichen Anforderungen genügen muss, wie z. B. Bankensoftware. Dann ist um Himmels Willen alles möglich, aber ich werde mir kaum vorstellen können, dass Software, die den Bankenvorschriften entsprechen muss, auf der Grundlage eines Entwicklungsteams in Produktion gebracht werden kann, das entscheidet, welche Funktionen wie entwickelt werden.

Se quindi iniziamo ad escludere agile dallo sviluppo di prodotti fisici e da prodotti software definiti da specifici requisiti, potremmo direi che l’utilizzo di agile è relegato ad un ambito di applicabilità ristretto.

Projektmanagement im Unternehmen

Aus diesem Grund sollte jedes Unternehmen, das eine Projektmanagementmethode anwenden möchte, die kaum mehr als ein Teamarbeitsansatz ist, um ein Team von Entwicklern mit einer Geschäftsperson (Produktmanager) zusammenarbeiten zu lassen, lernen, wie man Projekte mit einem leitet strukturierte Methoden wie PMI oder Prince2

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert