Wie passt Software von der Stange in die agile Entwicklung?

Question

Vielleicht ist mein Verständnis von agiler Entwicklung nicht so gut, wie es sein sollte, aber ich bin neugierig, wie ein agiler Entwickler möglicherweise Software von der Stange (OTS) verwenden würde, wenn sich die Anforderungen und das Wissen darüber, wie das endgültige System aussehen soll, so schnell ändern, wie ich es verstehe (oft nach jeder Iteration der Entwicklung).

---

Ich sehe zwei Situationen, die für mich von besonderem Interesse sind:

(1) Ein OTS-System erfüllt die anfänglichen Anforderungen mit wenigen bis gar keinen Änderungen, abgesehen von einer möglichen Integration in ein bestehendes System. Nach einigen Iterationen der Entwicklung entspricht dieses System jedoch nicht mehr den Anforderungen, ohne dass der Kerncode neu geschrieben werden muss. Die Entwickler müssen sich entscheiden, ob sie zusätzliche Zeit aufwenden, um den Kerncode dieser OTS-Software zu erlernen, oder ob sie ihn wegwerfen und von Grund auf neu entwickeln. Beides würde sich drastisch auf die Entwicklungszeit und die Projektkosten auswirken.

(2) Die anfänglichen Anforderungen entsprechen keinem der vorhandenen OTS-Systeme, doch wenn der Kunde das Produkt abnimmt, ähnelt es aufgrund der zusätzlichen Anforderungen und der Abstriche bei den Anforderungen den vorhandenen Lösungen. Hätten die Entwickler mehr Anforderungen gehabt und im Vorfeld mehr Zeit darauf verwendet, hätte man diese Lösung verwenden können, anstatt sie neu zu entwickeln. Das Projekt wurde zwar geliefert, aber später und zu höheren Kosten als nötig.

---

Als Software-Ingenieur gehört es zu meinen Aufgaben (wie mir beigebracht wurde), dem Kunden qualitativ hochwertige Software pünktlich und zu den geringstmöglichen Kosten zu liefern (neben anderen Dingen). Agile Entwicklung ermöglicht qualitativ hochwertige Software, aber in manchen Fällen ist es vielleicht nicht offensichtlich, dass es bessere Alternativen gibt, bis es zu spät ist und zu viel Geld ausgegeben wurde.

Meine Fragen sind:

1. Wie passt Software von der Stange zur agilen Entwicklung?
2. Wie gehen der agile Manager und der agile Entwickler mit diesen Fällen um?
3. Was sagen die agilen Paradigmen zu diesen Fällen?

Answer 1

Szenario1:

Dies kann unabhängig von der OTS-Natur der Komponente geschehen. Agil bedeutet nicht kurzsichtig man muss die großen Brocken kennen die Gerüstteile und vorher Zeit zum Nachdenken haben. Abgesehen davon kann man nur auf dem aufbauen, was man weiß, und nur bis zum letzten verantwortlichen Moment warten, um dann eine der Alternativen zu wählen und damit zu beginnen. (Ich würde die Anwendung eines Drittanbieters vermeiden, es sei denn, die Kosten für eine interne Entwicklung sind nicht tragbar, aber das ist nur meine Meinung). Erstellen Sie einen Prototyp für mehrere Lösungen, um die Machbarkeit anhand der bekannten Anforderungen zu prüfen. Halten Sie die Dinge lose gekoppelt (austauschbar), einfach zu ändern und vollständig getestet. Wenn Sie an der Gabelung zwischen "weiter hacken" und "neu schreiben" angelangt sind, müssen Sie sich überlegen, was für das Unternehmen besser ist, und diese Option wählen. Es geht um die Frage: "Was ist das Beste, was wir jetzt tun können?

Szenario2:

Das kann passieren, obwohl die Wahrscheinlichkeit gering ist, dass das Team 2-3 Monate damit verbringt, die Anforderungen "fertig zu stellen", nur um dann festzustellen, dass sich die Marktbedürfnisse oder die Meinung des Kunden geändert haben und "Jetzt wollen wir es so". Auch hier stellt sich die Frage, bis zu welchem Zeitpunkt Sie bereit sind, Untersuchungen durchzuführen und zu erforschen, bevor Sie sich auf einen Aktionspfad festlegen. Entscheiden Sie weise mit den Informationen, die Sie bis zu diesem Zeitpunkt haben. Einsicht ist immer 20-20, aber die Kunden werden nicht ewig warten. Sie können nicht bis zu dem Zeitpunkt warten, an dem sich die Anforderungen so zusammenfügen, dass sie zu einer bekannten OTS-Komponente passen :)

Agile sagt: Tun Sie, was sinnvoll ist, und streichen Sie die nicht wertschöpfenden Aktivitäten :) Agile ist kein Wundermittel. nur meine 2 agilen Cents :)

Answer 2

Das ist keine eindeutige Antwort, aber ich denke, dass die Verwendung von Standardsoftware als Bestandteil einer Softwarelösung sehr vorteilhaft sein kann, wenn:

• Die Daten sind offen, z. B. eine offene Datenbank oder ein Webdienst zur Interaktion mit ihnen
• Das System von der Stange kann individuell angepasst werden einfach unter Verwendung eines ähnlichen Programmierparadigmas wie der Rest Ihrer Lösung
• Es kann nahtlos an den Rest Ihres Arbeitsablaufs angepasst werden

Ich bin ein großer Fan davon, das Rad nicht neu zu erfinden, und es kann ein großer Gewinn sein, wenn Sie Ihre Entwicklungsfähigkeiten nutzen, um den "Klebstoff" zwischen Standardlösungen zu entwerfen.

Denken Sie daran, dass "offen" der wichtige Teil ist, und ein Anbieter wird seine Lösung oft als offen anpreisen, obwohl sie es nicht wirklich ist.

Answer 3

Ich glaube, ich habe irgendwo gelesen, dass man, wenn man während einer Iteration feststellt, dass man mehr als 20 % mehr Arbeit hat, als man ursprünglich dachte, den Sprint abbrechen und einen neuen Sprint planen sollte, der die zusätzliche Arbeit berücksichtigt.

Das würde also bedeuten, dass man mit dem Unternehmen neu planen muss, um zu sehen, ob es die ursprünglichen Anforderungen noch erfüllen will, jetzt, wo man mehr weiß.

In unserem Unternehmen nutzen wir auch das Prototyping vor dem Sprint, um zu versuchen, diese Art von Situationen zu identifizieren, bevor sie in einem Sprint auftreten. Obwohl das natürlich immer noch nicht die Art von Situation identifizieren kann, die Sie beschreiben.

Answer 4

C2-Wiki-Diskussion: http://c2.com/cgi/wiki?BuyDontBuild