Agile Entwicklung

[HeikoDeik89]

Hi Leute,

ich habe heute eine Frage auf die ich bis jetzt noch keine Antwort gefunden habe. Es geht darum das im Softwarebereich momentan viel das Wort Agile Entwicklung / Scrum auftaucht.

Zum einen würde mich interessieren in wie weit das nur ein Trend ist oder ob das sehr viele Unternehmen einsetzten, zum anderen würde mich interessieren ob agile Entwicklung auch in anderen Industrieteilbereichen eingesetzt wird, wenn ja in welchen und in welcher Form.

Danke.

LG Heiko

 

[HaZu]

Hi,

wir setzen das Scrum Modell momentan im Bereich Medizintechnik zur entwcklung eines Softwaretools auf SAP Basis ein. Meine Erfahrungen sind eher durchwachsen. Es erfordert eine präzise Planung der einzelnen Sprints und viel Kontrolle der Ergebnisse. Es ist allerdings in meinen Augen die einzige Möglichkeit Software zu entwickeln von der man am Anfang noch nicht genau weiß wie die Anforderungen genau umgesetzt werden und welche Anforderungen überhaupt im Detail bestehen. Das führt aber auch schnell zu Problemen und erfordert, wie gesagt, präzise Planung und Kontrolle. Ohne ein eingespieltes team mit Erfahrung in dem Bereich macht es in meinen Augen wenig sinn auf Agile Entwicklung zu setzen. Aber es liegt sehr im Trend, soviel steht fest.

 

[benneq]

Erstens das was HaZu geschrieben hat und zweitens geht das nur mit kleinen Gruppen/Grüppchen. Ich würde mal maximal 30 Leute veranschlagen. Und diese 30 teilen sich dann in grob 4-6 Teams auf. Jedes Team bekommt einen eigenen Aufgabenbereich, sodass sie sich nicht in die Quere kommen.
Außerdem erforder Scrum ziemlich viele Meetings, der die Projektleitung irgendwie alles mitbekommen und steuern muss.

Prinzipiell finde ich Agile Entwicklung sehr angenehm, vor allem je kleiner die Gruppe ist. Mit 4-8 Leuten geht das super! Da kann man auch immer zusammen im Raum sitzen, jeder bekommt alles mit. So ist es dann auch besonders einfach Module zu verknüpfen, da man schnell mal die Anforderungen an Kommunikationsschnittstellen absprechen kann, etc.

 

[Erdmännchen]

Na da werf ich doch gleich mal mit dem nächsten Modewort um mich: Agile Softwareentwicklung mit Kanban.
Siehe: http://www.heise.de/developer/artikel/Software-Kanban-im-Einsatz-1235465.html (schon älter aber umschreibt es ganz gut).

Scrum hab ich schon wieder hinter mir, es war zu starr, zu viel Planungs-Overhead. Mit Kanban ist das noch viel mehr im Fluss (noch ein modischer Begriff ;-) ).
Und viel übersichtlicher.

 

[Jesterfox]

Jo, gibt verschiedene "Agile" Methoden, Scrum ist nur eine davon. Scrum funktioniert nur wenn man nicht nur das Team sondern auch das komplette Umfeld darauf anpassen kann. Dann aber sehr gut (eigene Erfahrung). Kanban setzt da weniger Agressiv an und lässt sich einfacher einführen.

Insgesamt bringt das ganze aber schon was. Die meisten sehen ja erst einmal nur den "riesigen" Overhead durch die Meetings. Aber in der Praxis sind die eher kurz und bringen sehr viel Transparenz und Feedback in die Entwicklung. Auf lange Sicht ist das einfach sehr wertvoll.

 

[antred]

Der Artikel hier spricht mir aus dem Herzen:

http://entwickler.de/zonen/portale/psecom,id,157,online,5218,p,0.html

 

[SheepShaver]

Habe mittlerweile in den letzten sechs Jahren in drei verschiedenen Firmen - vom Konzern bis zum größeren mittelständischen Unternehmen - mit Scrum zu tun gehabt, davon drei Jahre als Scrum Master. Eine Modeerscheinung ist agile Entwicklung mit Sicherheit nicht mehr. Auch Kanban ist nicht wirklich neu, obwohl es jetzt wieder vermehrt hochkommt. Kanban hat den Vorteil des geringeren Overheads, erfordert aber auch mehr Disziplin. Im Übrigen empfinde ich den Overhead bei Scrum nicht wirklich als extrem. Täglich ein 10 minütiges Standup-Meeting und alle drei Wochen ein Sprint-Planning. Was ist das schon? Backlog-Grooming macht man ja relativ selten.
Mit Scrum habe ich ein sehr facettenreiches Erfahrungsspektrum gesammelt. Prinzipiell kann ich behaupten, dass Scrum auch in größeren Projekten mit 40+ Entwicklern, die quer über den Globus verteilt sind, gut machbar ist. Idealerweise sollte ein einzelnes Scrumteam (das idealerweise nicht mehr als 5-7 Mitglieder haben sollte) natürlich am selben Ort sein, aber selbst das ist keine Notwendigkeit. Derzeit bin ich in einem Scrum-Team, das sich über zwei verschiedene Standorte erstreckt, und auch hier funktioniert alles wunderbar.
Problematisch ist üblicherweise jeder Übergang vom klassischen Wasserfallmodell zu einer agilen Methodik. Diese Übergangsphase kann auch mal ein Jahr oder mehr dauern. Natürlich erfordert jeder agile Prozess mehr Verantwortung vom einzelnen Entwickler, womit sich auch wieder einige schwer tun.

 

[Tumbleweed]

Wir sind auch Anfang dieses Jahres vom Wasserfall auf Scrum umgestiegen (mit Coaching usw.). Nach wochenlanger Vorbereitung und ständig neuen Meetings, die einen vom Arbeiten abhalten, haben die Entwickler (die stehen ja zum Glück im Zentrum des ganzen Wirbels) die Reißleine gezogen und dem Management-Layer gesagt, sie sollen mal runterkommen von ihrem Prozesskarussell. Das hat zum Glück auch recht schnell gewirkt und nun ist der Prozess sehr angenehm.

Also falls man in die Sache einsteigen will kann ich nur raten - nicht den Prozess overengineern. Das geht nach hinten los und dann heißt es "uuuh agile development, haufenweise overhead".

Ob agile development das Ende der Fahnenstange ist? Vermutlich nicht, wäre ja auch sonst zu langweilig. Wasserfall würde ich mir aber freiwillig nicht mehr antun, nach den positiven Eindrücken bisher. Kanban scheint mir aber auch noch angenehmer als Scrum. Vielleicht kommen wir da auch noch hin.

 

[Jesterfox]

Wenn Scrum mal wirklich läuft gibts eigentlich wenig Grund auf was anderes wie Kanban zu wechseln. Die Frage ist da eher ob man Scrum überhaupt ans Laufen bekommt oder ob organisatorische Puinkte dagegen sprechen.

Aber ja, die große Gefahr bei sowas ist bei der Einführung an sich nicht "agil" vorzugehen. Denn nicht nur die Entwicklung, auch den Prozess sollte man so betrachten und eben kein "Overengineering" betreiben.

 

[Tumbleweed]

Was mir an unserem Scrum bisher nicht so gut gefällt, ist die Hemmung Storys nachzuziehen, am Ende einer Iteration. Man will ja sein burndown chart nicht vermurksen und riskieren nicht fertig zu werden. Nach meinem Verständnis ist das bei Kanban ganz anders, weil da alles mehr im Fluss ist und nicht in Sprints abgeschlossen.

Edit: muss vielleicht dazusagen, wir sind externer Dienstleister, wobei das Ziel ist als ein Team aufzutreten und entsprechend mit Vertrauen usw. zusammen zu arbeiten.