Was macht die agile Softwareentwicklung so attraktiv?

Agile Softwareentwicklung wird heutzutage zu einem unterhaltsamen Schlagwort.

Als Entwickler verstehe ich den pragmatischen Wert der iterativen Entwicklung, aber (meistens) ist es keine Entscheidung der Entwickler, sich für einen agilen Ansatz bei der Softwareentwicklung zu entscheiden. Es ist eine Top-Down-Management-Wahl! Ob es sich um Kristall, agile Methoden, dsdm, rup, xp, scrum, fdd, tdd handelt, Sie nennen es. Es ist keine Wahl für Entwickler.

Was sind für alle Manager die wichtigsten Gründe, sich für eine agile Entwicklung zu entscheiden, wenn (meiner Erfahrung nach) die meisten Manager noch nicht einmal einen Code in ihrem Leben berührt haben?

Verschobene Anforderungen, schnellere Lieferung

Agile ist ansprechend, weil es die Möglichkeit bietet, sich schneller (oder überhaupt) an veränderte Bedürfnisse anzupassen und diese Änderungen dem Kunden schneller zu übermitteln.

Dies ist der Grund, warum viele Unternehmen bei der Verwendung von Agile / Scrum scheitern: Manager verstehen nicht, dass es bei großer Leistung (schnellere Veröffentlichungstermine festlegen und Anforderungen oft ändern) in der Verantwortung liegt, sich bei Schätzungen auf Entwickler zu verlassen . Damit agil arbeiten kann, muss der Manager bereit sein, den Umfang zu verringern.

Sie wollen die Kraft von beiden.

Trends folgen

Manchmal machen die Leute Dinge, nicht wegen des Verdienstes der Sache, die sie anfangen (agil), sondern nur, weil es populär ist und andere Leute versuchen, das Gleiche zu tun.

"Was? Macrojam macht Agile? Warum nicht? Wir sind nicht langsam, wir sind Agile, verdammt!"

Manche Leute geben keinen guten Scheiß darauf, was es eigentlich bedeutet, agil zu sein. Es ist nur ein Mittel, um ihre Existenz zu rechtfertigen. Schafe, Gruppenzwang usw.

Das Codieren selbst ist nicht der Hauptgrund, warum Manager davon überzeugt sein können, Agile als Methode zu wählen. Es ist ansprechend, dass Sie schneller auf sich ändernde Anforderungen und Prioritäten reagieren können. Der Manager muss dem Endbenutzer / Kunden / seinem Manager eine Lösung liefern.

Wenn Funktionen, die beim Starten des Projekts von zentraler Bedeutung waren, während des Projekts abgeschafft und durch neue, relevantere Anforderungen ersetzt werden können, ist dies ein großer Vorteil.

Wichtig ist auch, dass meistens (zB wie bei Scrum) jede Zwischenlieferung fast fertig zur Serienreife sein sollte. Gleichzeitig wurden die dringendsten Funktionen zuerst entwickelt. Für den Fall, dass das Projekt aufgrund einer Unternehmensentscheidung abgebrochen wird, ist das Management sicher, dass Sie am Ende etwas erhalten, das funktioniert und in Produktion gehen kann.

Hoffe das hilft.

Erhöhen Sie die Sichtbarkeit der aktuellen Ereignisse und steigern Sie die Produktivität

1. Manager sind in der Regel daran interessiert, Sichtbarkeit agil zu gestalten, insbesondere bei Scrum. Es ist eines der meistgenutzten Verkaufsargumente in den Seminaren, die sich an Manager richten.

2. Höhere Produktivität wird auch häufig verwendet, um sie anzuziehen, da dies (dank der Sichtbarkeit) leicht zu demonstrieren ist. Einige agile Evangelisten versprechen ihnen von ihren bestehenden Mitarbeitern eine herausragende Produktivität. "Was? Ich drücke sie schon wie Zitronen und du sagst mir, dass ich noch mehr bekommen kann " ?

Viele Manager setzen Agile ein, um ihre Angestellten noch ein bisschen mehr zu vernichten, und ich habe gesehen, wie sie die Burn-Down-Tabelle als nachlässige Jagdmaschine in einem großen Unternehmen verwendeten.

Ergebnis? Viele team in distress. Sie dachten, dass Agilität all ihre Probleme lösen würde, aber genau das Gegenteil war der Fall. Das Problem war woanders.

Ich kämpfe aktiv dagegen an. Aus diesem Grund pervertedschlage ich vor, dass das Management manchmal, wenn die Wahrscheinlichkeit groß ist, dass agile Methoden nicht zum Einsatz kommen, dies nicht innerhalb des Unternehmens erwähnt.

Die Antwort auf diese Frage könnte ein Buch füllen.

Ich denke, einer der Hauptgründe ist, dass sich die agile Entwicklung auf das Erbringbare konzentriert. Es geht immer darum, genau das zu liefern, was hier und jetzt am dringendsten ist.

Ein weiterer Grund ist, dass die handlungsbasierten Planungs- und Schätzungspraktiken, denen agile Prozesse folgen, eine weitaus bessere Einschätzung darüber liefern, was wann geliefert werden kann.

Ein gutes Beispiel für die Effektivität der geschichtenbasierten Planung ist ein Projekt, an dem ich gearbeitet habe. Einige Monate (bevor wir uns für die agile Entwicklung entschieden haben) glaubte der Projektleiter, dass wir pünktlich liefern könnten, und das waren ungefähr 18 Monate nach dem Abgabetermin. Alle Entwickler hatten das Gefühl, dass das wahrscheinlich unrealistisch war. Nach dem Start der agilen Planung hatte der Projektleiter noch eine optimistische Einschätzung der Situation. Aber erst nach ein paar Sprints stellte der Projektleiter fest, dass das Team einfach nicht in der Lage war, alle Anforderungen zur erwarteten Zeit zu erfüllen. Und das war jetzt noch mehr als 12 Monate von der Frist.

So machen agile Praktiken auch die Realität viel früher deutlich.

Und schließlich tendieren agile Teams dazu, häufiger Praktiken anzuwenden, die eine bessere Codequalität schaffen, z. B. testgetriebene Entwicklung, häufiges Refactoring, kontinuierliche Integration, Peer-Code-Überprüfung / Paarprogrammierung usw. Nicht, dass herkömmliche Softwareprojekte diese Praktiken verbieten, sie tendieren einfach dazu nicht so sehr im Fokus.

Die meisten Manager haben noch nicht einmal einen Code in ihrem Leben angerührt!

Ich war 12 Jahre lang Entwickler und jetzt 5 Jahre lang Manager. Während der 5 Jahre bin ich schrittweise von einem Manager gewechselt, der immer noch in erster Linie ein reiner Manager war (ich behebe gelegentlich noch Fehler oder mache Prototyping-Übungen).

Was sind die Hauptgründe für die Entscheidung für Agile Development?

• Sichtbarkeit oder Erfolg schnell / Fehler schnell - Wir sind ein Produktentwicklungs-Shop mit Zyklen von 6 Monaten bis 24 Monaten. Die iterative Entwicklung mit funktionierenden, getesteten Funktionen spiegelte den Projektstatus besser wider.
• Veränderung - In unserer Umgebung sind Anforderungen und Zeit normalerweise festgelegt. Aber das Geschäft durchläuft zu regelmäßig schnelle, rasante Richtungsänderungen. Die iterative, sichtbare Entwicklung erleichterte den Projekten den Richtungswechsel.
• Story-basierte Anforderungen mit iterativer Entwicklung erleichterten die Arbeit mit dem Unternehmen, das die technischen Aspekte der Anforderungen nicht immer verstand oder die Geschäftstreiber einiger Details nicht vollständig verstand. In unseren bisherigen Bemühungen waren hochrangige Spezifikationen oder Dokumente zu Marketinganforderungen nicht immer ausreichend. Jetzt, da sich Projekte entwickeln, kann es zu parallelen Markt- und Kundenrecherchen kommen.
• Die Prozessänderung war mit vielen anderen Entwicklungsattributen verbunden, wie TDD, automatisierten oder manuellen Tests, kürzeren Testzyklen (wir haben keine QC-Gruppe mehr, nur noch eine QA-Gruppe) und einer höheren Wertschätzung und einem höheren Qualitätsaufwand (wir verwenden a) viel mehr Tools und Metriken).

Wir hätten dies auf andere Weise erreichen können, aber der Einsatz agiler Methoden und Ideen hat uns enorm geholfen.

Wir verfeinern auch weiterhin unseren Prozess. Zum Beispiel das Gleichgewicht zwischen der Arbeit im Vorfeld und dem Design kurz vor der Implementierung. Wir überprüfen regelmäßig alle unsere Entscheidungen, um festzustellen, ob wir frühere Entwurfsentscheidungen hätten aufschieben können. Und wenn etwas schief geht, wie viel Vorarbeit wäre nötig gewesen, bis der Fehler identifiziert worden wäre. Oft sind Ausfälle Eckfälle, die eine gründliche Analyse erfordern. Der Aufwand, um diese Details zu erhalten, ist oft der gleiche wie der Aufwand, um sie auf dem Weg zu ermitteln und umzugestalten. Teams werden für diese Art von Fehlern nicht bestraft und zu aggressiverem Verhalten ermutigt.

Ich habe eine Reihe von Unternehmen gesehen, die agil agierten. Leider nur sehr wenige von ihnen verabschieden agil. Was ich meine, ist nur iterative Entwicklung und tägliche Stand-ups (wo sich die meisten Teammitglieder hinsetzen), die das Team nicht agil machen. TDD, Refactoring, kontinuierliche Integration, Kundenpräsenz und SOLID-Praktiken machen ein Team agil. Ohne diese bewegst du dich nur im Kreis.

Es gibt eine Menge Anziehungskraft, die die Botschaft von Agile mit sich bringt. Anpassungsfähigkeit an Veränderungen ist am größten. Leider wird Ihr Code nicht anpassungsfähiger, nur weil Sie Ihre Projektverwaltung ändern. Bis mehr Unternehmen dies realisieren, werden wir nur von immer mehr gescheiterten agilen Projekten hören.

Ich weiß nichts über das Schlagwort. Ich habe das die ganze Zeit in einem nicht so formalisierten oder identifizierten Prozess gemacht. Ich hatte Kunden, die mir buchstäblich über die Schulter sahen, als ich ihre Website erstellte. Es wurden ungefähr 50 E-Mails gespeichert und der Kunde hat etwas über diesen Vorgang gelernt - es ist nicht einfach.

Die ganze Vorstellung, dass wir eine lange Zeit brauchen werden, um alles aufzuschreiben, was der Benutzer von der Software verlangt, und dann eine längere Zeit, um das zu erstellen, was er unserer Meinung nach nur innerhalb von 2 Sekunden nach dem Testen der App herausfinden möchte, dass dies der Fall ist ist nicht das, was sie erwartet haben, widerlich. Wie schwer ist es, ein Projekt oder eine Anwendung in vernünftige Teile zu zerlegen, um ein Feedback zu erhalten, bevor Sie ein anderes Teil erstellen?

Ich weiß, dass dies eine übermäßige Vereinfachung ist und nicht die tatsächlichen Entwicklerpraktiken anspricht, aber es ist nicht schwer, es auch an nicht-technische Manager oder Kunden zu verkaufen. Welcher andere Ansatz ist ansprechender? Lieben Kunden wirklich die Tatsache, dass die Programmierer für 6-12 Monate keine Haare mehr haben, während sie sich während eines Wasserfallprojekts entwickeln? Würden Sie jemanden beauftragen, auf diese Weise ein Haus zu bauen?

Das Management drängt diese Dinge nicht auf die Entwickler. Entwickler und Teams sollten Initiative ergreifen und sich bemühen, ihre Arbeit besser zu machen. Das Management hat die Aufgabe, diese Initiativen zu unterstützen.

Als Manager, der in meiner Karriere eine Menge Code geschrieben hat, bin ich möglicherweise nicht derjenige, nach dem Sie suchen, um darauf zu antworten. In jedem Fall hat die Auslosung von Agile in diesen Tagen vor allem damit zu tun, schneller auf Kundenbedürfnisse zu reagieren und die Rückkopplungsschleife zwischen Spezifikation, Codierung, Tests und Kunden zu verkürzen. Genau aus diesen Gründen sind wir auf dem Weg zu einer agileren Entwicklung.

Ich denke, Sie sollten den Agile-Prozess und die Codierungs- / Entwicklungspraktiken nicht durcheinander bringen. Zum Beispiel sagt Ihnen Scrum nicht, wie Sie Ihren Code entwickeln sollen - es geht nur um den Prozess, der Änderungen begrüßt.

Letztendlich geht es darum, den Entwickler zu befähigen; Es geht darum, die Tatsache anzuerkennen, dass nur diejenigen, die ganz unten in der Hierarchie stehen, wirklich verstehen, inwieweit und wie dies getan werden muss. Wenn Sie sie also bereits aufgrund ihres Fachwissens eingestellt haben - warum Lassen Sie sie nicht die volle Kontrolle übernehmen, oder warum sollten sie sich von der eigentlichen Entscheidungsfindung distanzieren?