ڪے~ ~(̅_̅_̅_̅(̅_̅_̅_̅_̅_̅_̅_̅_̅̅_̅()

[janteloven]

Ist das der neue Trend? Oder wird es eine Nischenerscheinung bleiben? Und hat dieser Ansatz nicht auch woanders eine Chance verdient?

[Kulle]

....
Ist das der neue Trend? Oder wird es eine Nischenerscheinung bleiben? Und hat dieser Ansatz nicht auch woanders eine Chance verdient?

Hier in D wird das nix. Teamarbeit wird zwar erfordert. Aber man will sehen das man die Ellenbogen im Team stemmt.

[Druide]

Ausserdem gibt es einen Trend zu "Cross Functional Teams", in denen jeder alles kann, aber eben keiner absoluter Spezialist für genau eine Sache ist.

Dieser "Trend" wird seit ca. 2 Jahren in unserer Abteilung angestrebt; wobei einige "mit machen", andere sich wiederum
"bewusst blöd (an-)stellen" und dann "die anderen" deren Arbeit (mit-)machen dürfen.

LG v. Druiden

[Mattieu]

Dieser "Trend" wird seit ca. 2 Jahren in unserer Abteilung angestrebt; wobei einige "mit machen", andere sich wiederum
"bewusst blöd (an-)stellen" und dann "die anderen" deren Arbeit (mit-)machen dürfen.

Das ist ja seit jeher eine Eigenart von Teams.
Team = Toll ein anderer macht's.

Was agile Arbeitsweise jetzt vom bisherigen Arbeitsalltag unterscheiden sollte, ist mir allerdings nicht klar geworden. Was bedeutet das im Beispiel der IT-Abteilung konkret?

[phoenix]

Hier in D wird das nix. Teamarbeit wird zwar erfordert. Aber man will sehen das man die Ellenbogen im Team stemmt.

Kann icht nicht bestätigen. Und Ja agiles Arbeiten kommt.

[phoenix]

Das ist ja seit jeher eine Eigenart von Teams.
Team = Toll ein anderer macht's.

Was agile Arbeitsweise jetzt vom bisherigen Arbeitsalltag unterscheiden sollte, ist mir allerdings nicht klar geworden. Was bedeutet das im Beispiel der IT-Abteilung konkret?

Das bedeutet konkret, nicht das Pflichtenheft abarbeiten.

2-4 Wochen einige Features fertigbauen, dann Review mit Kunden und Kunden,
Das ermöglicht auch, "oh, nee, das Feature wollte ich zwar, aber jetzt lassen wir das", ohne die Deadline des Gesamtprojekts zu reißen.

[phoenix]

Nach einer kurzen Eingewöhnungszeit muss ich sagen, dass mir diese Art zu arbeiten sehr viel Spass macht. Man identifizert sich mit den Leuten im Team und diese iterativen Abläufe, die wir Sprints nennen, die schweissen richtig zusammen. Man bekommt einen "work flow" und genau das ist auch das Ziel des Managements.

Vor allem managed ein Product Owner, was bis wann gemacht ist und er priorisiert auch was gemacht wird.

[Conte Palmieri]

http://globalnerdy.com/wordpress/wp-content/uploads/2007/11/dilbert-agile_programming.gif

[Araxes]

Ist das der neue Trend? Oder wird es eine Nischenerscheinung bleiben? Und hat dieser Ansatz nicht auch woanders eine Chance verdient?

Also agiles Vorgehen ist schon weit verbreitet und funktioniert auch. Probleme gibt's dann, wenn man (der Kunde, das Mangement, das Team) sich nicht konsequent darauf einläßt und versucht, alte Vorgehensweisen mit agilen zu mischen.

Bei uns sieht das momentan so aus, daß der Kunde agil draufschreibt, aber immer noch mit längeren Releases von einigen Monaten plant. Das paßt dann einfach nicht zusammen.

Der Sinn von "agil" bei Softwareprojekten ist ja, kontinuierlich in Sprint-Zyklen, also z.B. alle zwei Wochen eine neue Version zu liefern. Und man beschreibt und plant dann eben auch nur in diesen Zyklen. Unser Kunde will aber nach wie vor wissen, was er in 6 Monaten kriegt. Das kommt daher, daß er nach wie vor eine Budgetplanung und -freigabe in diesen langen Zeiträumen macht und dafür beim Fachbereich anmelden muß, was der FB für das Geld bekommt. Am Ende heißt "agil" dann, daß er weniger Arbeit in die Lastenhefte (Storyboards) steckt und jederzeit Planung umschmeißen kann, womit der Zulieferer (wir) dann klarkommen muß. Das geht natürlich nicht. Agil heißt, daß sich beide Seiten einlassen.

Korrekt wäre, daß der FB das Budget hergibt, ohne konkret zu wissen, was er in 6 Monaten dafür kriegt, sondern daß das sprintweise entschieden wird. Das sieht der FB dann u.U. nicht ein, obwohl es für ihn von Vorteil ist, weil man auf diese Weise viel näher an den Anwenderwünschen bleibt, statt etwas für 6 Monate zu planen und nach 2 Monaten festzustellen, daß die Hälfte davon verworfen und anders gemacht werden muß und man dann haufenweise Change Requests formuliert und abschätzt.

[Araxes]

Das ermöglicht auch, "oh, nee, das Feature wollte ich zwar, aber jetzt lassen wir das", ohne die Deadline des Gesamtprojekts zu reißen.

Genau genommen gibt's gar keine Deadline, denn man liefert kontinulierlich aus und die Anwendung wächst und reift kontinuerlich. Sieht man ganz gut an Anwendungen wie Immobilienscout oder eBay. Es gehen ständig Features rein und raus. Manche setzen sich sogar die Vorgabe, daß für jedes Feature, das reinkommt, eins raus muß, damit man keinen unbenutzbaren Moloch erzeugt.

[Araxes]

Sprint-Zyklen und Storyboards sind eigentlich kein Bestandteil von "agil".

Bestandteil von Scrum und Scrum ist agil. Das dürfte wohl neben Kanban der am häufigsten angewendete Prozeß sein.

[phoenix]

Ich nehme mal an, dass du von Scrum redest und nicht von agilem Projektmanagement im allgemeinen?

In diesem speziellen Fall, ja.

[bullnatter]

Ich arbeite ebenfalls in einer Firma, die Agile zumindest einzuführen versucht. Es klappt auch in einigen Bereichen, jedoch weniger bei sehr grossen und verschiedene Abteilungen übergreifenden Teams, und auch dann weniger, wenn die Produktanforderungen sehr spezifisch und/oder rechtlich vogegeben sind. Aber in gewisen Bereichen, wie z.B. der UI Entwicklung habe ich sehr gute Erfahrungen mit Agile gemacht.

"Lean" und/oder "Six Sigma" usw. sind dann wieder ganz andere Ansätze.