Heutzutage ist die agile Entwicklung die "default" Option. Viele Firmen und Teams setzen agile Entwicklung ein. Auch im Data-Science-Bereich. Wir verwenden Stand-Up Meeting, JIRA, User Story, Story Punkte, usw.

Ich habe im Internet viele Seite gelesen, um die Begriffe, Konzepte und Werkzeuge zu verstehen, die für die agile Entwicklung typisch sind. Ich habe auch Erfahrung mit der agile Entwicklung.

Die Denkart der agilen Entwicklung finde ich gut, aber ich bin gegen einige Prozesse und Konzepte der agilen Entwicklung. Da ich eine Person gefunden habe, deren Meinung ähnlich (nicht gleich) wie meine ist, habe ich keine Angst davor, dass ich nicht allein in der Welt bin.

Deshalb schreibe ich in diesem Eintrag über etwas, welche Konzept der agilen Entwicklung ich nicht mag.

1. Stand-Up Meeting

Wissen Sie das Ziel von dem "Stand-Up Meeting"? Nicht, wie der Ablauf des Meetings aussieht. Diese Seite sagt,

Es [...] dient dem Team dazu, sich abzustimmen und gegenseitig zu informieren.

Aber wenn man sich informieren möchte, ist es genug, JIRA nachzusehen. Dort steht der Zustand aller Aufgaben. Man kann sofort verstehen, wer welche Aufgabe macht/gemacht hat.

Die einzigen Informationen, die nicht in JIRA steht, sind die Hindernis der Arbeit:

Nur die Team Members sprechen und berichten einander jeweils Folgendes:

• Was habe ich seit dem letzten Daily Scrum getan?
• Was plane ich, bis zum nächsten Daily Scrum zu tun?
• Was hat mich bei der Arbeit behindert (Impediments)?

Aber warum muss man das Hindernis erwähnen? Falls Sie eine Frage stellen möchte oder eine Hilfe einer Kollegin braucht, ist es genug, persönlich darum zu bitten.

"Stand-Up Meeting" muss kurz sein. Wenn die Projektleiterin/Chefin das nicht versteht, fängt sie beim Meeting eine technische Diskussion an, wenn einer der Teilnehmer das Hindernis erwähnt. Alle anderen Teilnehmer verschwenden die Zeit, die sie für die Entwicklung verwenden könnten. (Übrigens habe ich in der jetzigen Firma kein Start-Up Meeting.)

Wer Agile-Methode sehr gut kennt, kann behaupten, dass das keine agile Entwicklung mehr ist. Das kann sein. Aber die Hauptsache liegt woanders.

• Warum ist Stand-Up Meeting nötig? Warum ist JIRA nicht genug?
• Warum muss man das Hindernis sagen? Was für ein Hindernis soll erwähnt werden?
• Warum muss das Meeting kurz sein?

Haben Sie eine glasklare Antwort darauf? Wissen die Teilnehmer Ihre Antwort? Sind alle Teilnehmer (Entwicklerinnen und Projektleiterin) der gleichen Meinung?

Ich bin ziemlich sicher, dass viele Leute auf einem Stand-Up Meeting sind, ohne das Ziel zu verstehen. Falls meine Vermutung falsch wäre, könnte ich einfach im Internet finden, warum das Stand-Up Meeting nötig wäre. Ich habe mehrmals im Internet das Ziel des Stand-Up Meetings gesucht, aber alle Seiten erklären nur den Ablauf des Meetings.

Grundsätzlich müssen alle Teilnehmer an einem Meeting das Ziel des Meetings verstehen. Wenn man gegen die Regel verstoßt, funktioniert kein Meeting.

2. Story Point

Wie oft gesagt, ist ein Story-Punkt kein Aufwand, sondern Komplexität.

Story Points spiegeln den Funktionsumfang, ggf. auch die Komplexität von Anforderungen wider. Es handelt sich nicht um absolute Schätzgrößen für Aufwände, wie z.B. Personentage, sondern um relative Vergleichsgrößen der einzelnen

Der Unterschied zwischen dem Aufwand und die Komplexität wird auf dieser Seite erklärt.

Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert.

Also die Komplexität sei nicht abhängig von der Erfahrung des Teams.

Aber wie kann man die Komplexität einer Aufgabe richtig schätzen? Was wäre, wenn Sie mit einem neuen Werkzeug arbeiten müssen. Es gibt sicherlich viel etwas Unklares und Sie erwarten eine hohe Komplexität. Die Realität kann anders sein. Das neue Werkzeug macht viel automatisch, obwohl das System des Werkzeugs sehr kompliziert ist.

Was wäre, wenn es zwei sehr ähnliche aber nicht gleiche Aufgaben geben würde. Wenn man eine davon macht, kann man eine ähnliche Lösung für die andere Aufgabe verwenden. Deshalb ist die zweite Aufgabe sehr leicht, aber trotzdem muss die Komplexität der zwei Aufgaben gleich sein.

Die Story Punkte werden verwendet, um das Performance des Teams zu berechnen. Warum messen wir das Performance des Teams? Was macht man mit dem berechneten Performance?

Was wäre, wenn es eine nicht komplizierte Aufgabe gibt, die aber lange Zeit verlangt. Zum Beispiel muss man den Eigennamen in einer Dokument korrigieren. Die Aufgabe hat sicherlich leichte Komplexität. Aber der Eigenname besteht aus "normalen" Wörtern, deshalb muss man manuell korrigieren. Die Arbeit dauert lang und infolgedessen ist das Performance des Sprints schlecht.

Solange die Komplexität vage ist, kann man die Komplexität nicht richtig schätzen. Und mit der falsch geschätzten Komplexität berechnet man das Performance des Teams. Ich finde die Idee verrückt.

3. Agile zwingt eine schlechte Qualität

Eine der wichtigsten Eigenschaften der agilen Entwicklung ist ein kurzer Zyklus. Jede Woche oder alle zwei Wochen kontrollieren wir die Entwicklungsplan. Auf dieser Weise behalten wir flexibel den Plan.

Aber der kurze Zyklus übt Zwang auf Entwickler aus. (Fast) alle Aufgaben sind innerhalb der Sprintdauer fertig zu machen. Infolgedessen gibt es keine großen Aufgaben.

It's a culture of terminal juniority. Product development and architecture aren't the programmer's job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level "user stories". This is OK for a junior who's learning the codebase and software engineering principles and may appreciate the guidance, but anyone with more than 5 years of experience is going to find it to be a dissatisfying way to work. There is no place for an actual senior engineer on a Scrum team.

Natürlich hat niemand die Zeit, die Lösung zu optimieren.

It punishes R&D, and it hurts the best engineers the most. [...] Agile and Scrum, however, single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it. This means that there's no room to fail, thus no room to experiment.

Es ist am wichtigsten, die einfachste Lösung schnell zu implementieren. Es ist egal, ob ein Problem später wegen der einfachen Lösung entsteht.

Wegen des kurzen Zyklus hat man keine Zeit, kreativ die Aufgabe zu erledigen. Das liegt daran, dass eine neue kreative Idee normalerweise die Zeit zum Test verlangt. Natürlich braucht man die Zeit, um eine neue Idee zu entwickeln.

Im Data-Science-Bereich wird oft die agile Entwicklung verlangt, aber trotzdem passt sie gar nicht zum Data-Science.

Wenn Sie der Meinung sind, dass die Kreativität wichtig für Data Science ist, müssen Sie überlegen, wie man Kreativität und Agile-Prozesse unter einem Hut bringen kann.

4. Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung

Ja, das ist eine gute Idee, wenn die Kunden die Idee der agile Entwicklung verstehen.

Die Kunden müssen die User Stories schreiben, Fragen der Entwickler beantworten, Logik der Implementierung bestätigen, gegebenenfalls das Ergebnis testen. Die Kunden müssen nämlich proaktiv reagieren. Dass sie nur an Sprint-Review teilnehmen, geht nicht.

Fazit

Ich habe 4 Punkte geschrieben, die ich in Bezug auf die agile Entwicklung nicht mag.

Aber was ich wirklich nicht mag, ist, dass viele Managerinnen / Projektleiterinnen / Kunden die Prozesse und Methoden einsetzen, ohne das Ziel zu verstehen. Natürlich verstehen die Entwickler das Ziel auch nicht. Ich bin der Meinung, dass alle das Ziel der Prozesse verstehen müssen und dazu der gemeinsamen Meinung sein.

Eigentlich habe ich meine Antwort für die erste zwei Punkte. Vielleicht schreibe ich irgendwann darüber.