Scrum, Kanban, etc - Erfahrungswerte?

[Unfug]

Hallo 3dc,

zu später Stund eine Frage an die IT Profis. Wer hat denn Erfahrung mit einer der oben genannten oder anderen Softwareentwicklungsmethode?

Wenn ich das alles richtig intepretiere, dann könnte man diese agilen Methoden runterbrechen und sagen:

Man spricht viel miteinander, am besten täglich
Man macht das Projekt und den Fortschritt sichtbar (z.B. an einem Whiteboard)
Man spricht viel mit dem Kunden und bietet ihm somit die Möglichkeit an, die Entwicklung durch neue angepasste Anforderung zu beeinflussen.

Ich habe eigentlich nie anders gearbeitet und jetzt mach ich mir aber Gedanken, was Scrum und Kanban besser machen?
Kanban im Sinne: Ich nutze jetzt ein Whiteboard, wo ich meine ToDos aufliste habe ich versucht zu verwenden. Allerdings dieses Whiteboard stets aktuell zu halten, klappte jedoch nicht. Es wurde auch sehr unübersichtlich. Jeder Softwareentwickler (es waren 5) hatte seine Spezialität und somit auch seine eigene Zeile mit ToDos, UserStories u.s.w

Sehr gute Erfahrung habe ich mit einer anderen Art und Weise gemacht. Und zwar indem man sich mit mehreren in einen Raum eingeschlossen hat und alles runtergehackt hat wie verrückt. Es wird kontinuierlich der Quellcode refaktort. Ein Tag programmieren, am nächsten Morgen erstmal sauber machen, dann neu programmieren.
Man brauchte nicht mal vorher irgendwelche Interfaces definieren oder UML Klassendiagramme definieren. Man sagte einfach dem entsprechenden Entwickler, dass er eben sein Interfaces anpassen möchte...fertig.
Das Ergebnis war eine extrem stabile und fehlertolerante Serversoftware.

Hat jemand Erfahrung wie das bei Software abläuft, die von den verschiedensten Menschen auf der Welt programmiert wird? Z.B. Ubuntu? Oder andere OpenSource Software?
Welche Software nutzt ihr für das Projektmanagement? ToDo Listen ala Jira / TFS?

Eure Vorgehensweise würde mich interessieren.
Danke für eure Erfahrung und Tipps.

Gruß
Unfug

[Monger]

Ich geh darauf ein andermal ausführlicher ein, aber grundsätzlich:

Ich hab im Studium einiges zu dem Thema gemacht, wir haben sowas z.B. als Praxisarbeit dann umgesetzt. War ziemlich spannend.
Hat ungefähr acht Jahre gedauert bis auch auf Arbeit das mal zum Thema wurde, sei ungefähr zwei Jahren versucht man auf verschiedenen Ebenen das bei uns zu etablieren.

Ich würds anders formulieren: eigentlich geht es darum, gerade so viel zu kommunizieren wie nötig, und die Informationsflüsse von dem Grundrauschen zu trennen was einem vom effizienten Arbeiten abhält.
Erstmal oberflächlich wirken z:b. Daily Standups so als würde man mehr kommunizieren, aber netto ist das eigentlich weniger als vorher, dafür halt effizienter. Daily Standups sollen ein Stück weit all die Einzelgespräche die sich sonst über den Tag verteilen eben zusammensammeln, um anschließend die Arbeit unterbrechungsfreier zu machen.

[littlejam]

Hallo 3dc,

zu später Stund eine Frage an die IT Profis. Wer hat denn Erfahrung mit einer der oben genannten oder anderen Softwareentwicklungsmethode?

SCRUM als Sysadmin seit ein paar Monaten.

Man spricht viel miteinander, am besten täglich
Man macht das Projekt und den Fortschritt sichtbar (z.B. an einem Whiteboard)
Man spricht viel mit dem Kunden und bietet ihm somit die Möglichkeit an, die Entwicklung durch neue angepasste Anforderung zu beeinflussen.

Stimmt schon, klingt aber in der Theorie besser als es tatsächlich ist.
Man spricht viel miteinander, ja. Das hilft vor allem bei introvertierteren Teammitgliedern.
Einen Gesamtfortschritt sieht man auf dem Whiteboard eigentlich nicht, da nach dem Sprint alles was Fertig ist weg kommt und neues auf der Input-Seite dazu kommt.
Man sieht eher wieviel vom vorgenommenen geschafft wurde, also eher den Fortschritt in einem kleinerm Zeitfenster.
Die Dailies find ich eigentlich gut, fördert auf jeden Fall die Teamarbeit.

Ich habe eigentlich nie anders gearbeitet und jetzt mach ich mir aber Gedanken, was Scrum und Kanban besser machen?
Kanban im Sinne: Ich nutze jetzt ein Whiteboard, wo ich meine ToDos aufliste habe ich versucht zu verwenden. Allerdings dieses Whiteboard stets aktuell zu halten, klappte jedoch nicht. Es wurde auch sehr unübersichtlich. Jeder Softwareentwickler (es waren 5) hatte seine Spezialität und somit auch seine eigene Zeile mit ToDos, UserStories u.s.w

Naja, der größte Nutzen für mich ist derzeit, dass Probleme und Größere Projekte runtergebrochen- und einfach gemacht werden.
Über die Sprintlänge kann man streiten, imho sind die üblichen 2 Wochen hart am Limit. Mir wäre oft eine Woche lieber, da man so die Plannings verkürzt und auf neue Situationen schneller reagieren kann.
Kanban würde mir wohl besser liegen, aber im großen und Ganzen bin ich noch skeptisch.

Gruß

[flagg@3D]

Wir machen Scrum seit ca. 2 Jahren und haben grundsätzlich gute Erfahrungen damit gemacht, Probleme, Hindernisse können schnell eskaliert werden was für mich in der QA gerade bei Feature begleitendem Testen Gold wert ist. Bisher habe ich noch nie 100% sitzende Konzepte erlebt und da unser Produktmanager auch teil nimmt kann man schnell die Lage zwischen Entwicklung und Produktmanager auf Linie bekommen, zudem bekommt man mMn. das Gefühl das alle im selben Boot sitzen.

Ach ja, wir setzen auch Jira ein für Backlog, Sprintplanung, Tasks und Issues (intern wie auch Kunden), war am Anfang holprig, speziell wenn unsere Produktlinien sich an den Schnittstellen mischen, weil verschiedene Teams verschiedene Vorgehensweisen entwickelt haben, aber zwischenzeitlich läuft es ganz rund. Dazu werden alle wichtigen Infos, Konzepte aller Art etc.pp ins Wiki (Confluence) gepackt, möglichst sauber.

[Kenny1702]

Seit einem Jahr benutzen wir offiziell "Scrum". Wobei sich ehrlich gesagt so gut wie nichts geändert hat. Unsere wöchentlichen Besprechungen sind gelieben, nur alle 3-Wochen gibt es Spring Planning / Review stattdessen, das tägliche Stand-Up haben wir nach 6 Monaten eingemottet (wir reden tendenziell zu viel nicht zu wenig miteinander ;) ) und der eigenliche Grund warum wir es machen... das Management braucht Zahlen zum Planen:freak:.

Softwareseitig benutzen wir VersionOne.

[Gast]

Ich arbeite als IT-Berater für zwei große Firmen. Bei diesen Firmen wird Scrum eher dazu genutzt, noch weniger denken undarbeiten zu müssen. Ganz der Konzernmentalität folgend, den Gegenüber mit noch mehr Prosa vollzusabbeln, um ja nichts mehr aufschreiben zu müssen. Macht dann ja alles der Dienstleister ;)

Scrum mag als Idee ganz gut sein, wird aber oft schlecht angwandt. Das liegt auch daran, das Entscheider in bestimmten Positionen einer Opfermentalität folgen, ohne zu wissen, was Scrum überhaupt ist. Ganz dem Motto, hauptsache es ist Hip und ich kann das Management damit beindrucken.

[Unfug]

Guten Morgen,

setzen ja scheinbar doch ein paar mehr User ein. In erster Linie Scrum wie ich lese.

Das Problem was bei mir noch hinzukommt ist, dass ich nicht täglich anwesend bin. Mal hier mal da. Dann habe ich auch gefühlte 20 andere Sachen zu tun, die gar nichts mit dem Projekt/en zu tun hat. Muss das überhaupt der Scrum-Master?

Ich könnte also nicht jeden morgen mich mit den Entwicklern treffen. Allein deswegen schon nicht, weil diese auch nicht täglich anwesend sind.

Wenn ich das richtig lese, dann ist Scrum eher was für Firmen, die fixe Arbeitszeiten von 7-17h haben und das Team immer vor Ort ist.
Bei uns herrscht sehr viel Flexibilität. HomeOffice, Gleitzeit, mehrere Projekte gleichzeitig.

Löst Scrum eigentlich eine ordentliche Spezifikation ab? Normalerweise, bei Wasserfall, wird ja am Anfang eine fixe Architektur erstellt mit allen drum und dran (inkl. Methoden u.s.w). -Wie wird das bei Scrum gemacht? Benötigt man da auch noch eine Spezifikation? Architektur, Methoden mit Beschreibung von Parametern u.sw., UML Diagramme etc. etc. oder geschieht das on-the-fly?

[flagg@3D]

Klar benötigt man noch Spezifikationen mit Scrum.

@Homeoffice: Leute werden per skype zugeschalten, wenn einer vom Team nicht da ist, fehlt er halt und muss ggfls die herkömmlichen Wege benutzen.

[noid]

Klar benötigt man noch Spezifikationen mit Scrum.

Ich glaube der größte Fehler ist, dass man denk dank Userstories&Co braucht man keine Spec. X-D

Wir entwickeln auch agile nach Scrum, aber nur auf dem Zettel. Die ersten Pilotgruppen hingegen waren richtig klasse und man hatte auch nen besseren Ablauf, weil die nächsten 2 Wochen (bei uns) klar definiert waren.
Selbst zum schreiben einer Spec ist Scrum nicht schlecht.

Aber woran hakt es immer wieder? Die Leute haben zuviel auf einmal zu tun, weil ja alles prio eins ist und alles wichtig. Denke manchmal die Methode nennt sich Fakir - living the spikes.

[RLZ]

Einer der schlimmsten Fehler, die man mit Methoden machen kann, ist das Weglassen und Modifizieren der Methode von Anfang an, weil etwas zu kompliziert erscheint und "wir da ja gar nicht braucht".

Ich bin mit Scrum sehr zufrieden, sehe es aber eher als Werkzeug für passende Projekte. Man definiert schön die Schnittstellen nach Außen und alle Leute, die Einfluß nehmen wollen, müssen sich in die Rollen integrieren. Die Entwickler können sich dadurch voll auf die nächsten 1-2 Wochen konzentrieren, keiner darf ungefragt eingreifen und Features, die nicht an der Wand hängen (in kleinen Teams finde ich Papier an der Wand der Kaffeeecke besser als elektronische Hilfen), darf keiner danach fordern.

Zwingend erforderlich ist auch die gründliche Einarbeitung in die Methode. Die Wikipediaseite zu lesen reicht dafür definitiv nicht aus.

[Monger]

Kanban im Sinne: Ich nutze jetzt ein Whiteboard, wo ich meine ToDos aufliste habe ich versucht zu verwenden. Allerdings dieses Whiteboard stets aktuell zu halten, klappte jedoch nicht. Es wurde auch sehr unübersichtlich.

Erstens mal: Kanban hat pauschal nicht unbedingt was mit agilen Entwicklungsmethoden zu tun, obwohl es dort sehr populär ist.
Zweitens: einer der Fehler die gern gemacht werden, ist dass man das dogmatisch angeht. Es bringt nix, ein riesiges Board mit unzähligen Feldern und detaillierter Beschreibung hochzuziehen, wenn sich keiner dran hält.

Wir haben z.B. jetzt bei uns quasi ein Kanban-Light stehen. Hintergrund war: wir haben immer wieder mal Phänomene, die laut Spec kein Bug sind, die aber trotzdem aus unserer Sicht ein unerwartetes Verhalten zeigen, und regelmäßig für uns Arbeit in Form von Workarounds etc. produzieren. Da das in verschiedenen Bereichen des Teams (Team insgesamt: ca 30 Leute. Davon in dieser Art von Problem involviert, ca. 5-7, je nach Phase) aufschlagen kann, wollten wir ein zentrales Board was jederzeit einsichtig ist, und wo jeder schnell nachgucken kann wen man denn für dieses Problem befragen kann. Deshalb stehen auf unseren Zetteln üblicherweise auch nur drei Informationen: Ansprechpartner, aufgetreten seit, Kurzbeschreibung.

Wer dieses Phänomen auch schonmal gesehen hat, schreibt seinen Namen mit auf den Zettel. Wer glaubt dass das keine Rolle mehr bei ihm spielt, streicht seinen Namen durch. Wenn auf einem Zettel alle Namen durchgestrichen sind, kommt er in die Spalte "Fixed?". Alle zwei Wochen gibt es dann ein Meeting wo wir die Zettel aus dieser Spalte mitnehmen, kurz für alle nochmal vorstellen was denn konkret das Problem war und wie es dann gefixt wurde, und wenn alle zustimmen wird der Zettel getrasht.


Was ich damit sagen will: man darf sich nicht zum Sklaven einer Methode machen, sondern man muss die Methoden so für sich abstimmen dass sie leicht und locker von der Hand gehen. Es muss klar erkennbar sein wie diese Methode die tägliche Arbeit erleichter, und nicht etwa bürokratischer macht, dann wird sie auch angenommen.

Wenn dein Kanban Akzeptanzprobleme hatte, habt ihr es mit hoher Wahrscheinlichkeit mit Informationen überladen die für eure Arbeit nicht gewinnbringend genug waren. Das schöne an dem System ist: ausweiten geht immer, also erstmal simpel anfangen, und dann vorsichtig erweitern.



Sehr gute Erfahrung habe ich mit einer anderen Art und Weise gemacht. Und zwar indem man sich mit mehreren in einen Raum eingeschlossen hat und alles runtergehackt hat wie verrückt.

Ich sag mal so: wenn alle Verantwortlichen des Projektes in einen Raum passen, sind eure Entwicklungsprozesse eh nicht so komplex. Da ist jedes Modell - egal ob Wasserfall oder agil - wahrscheinlich Overkill.

[Monger]

Wenn ich das richtig lese, dann ist Scrum eher was für Firmen, die fixe Arbeitszeiten von 7-17h haben und das Team immer vor Ort ist.
Bei uns herrscht sehr viel Flexibilität. HomeOffice, Gleitzeit, mehrere Projekte gleichzeitig.

Scrum ist ja erstmal nur das Entwicklungsprozessmodell, und damit nur eins von mehreren denkbaren Modellen in der agilen Entwicklung.
Agile Entwicklung ist ja der Oberbegriff, und umfasst auch andere Themenfelder wie Arbeitszeitregelungen, Firmenkultur etc.

Wenn diese Voraussetzungen bereits nicht gegeben sind, wird auch Scrum nicht funktionieren.
So wie du das beschreibst, klingt das für mich als hättet ihr kein Projekt im strengeren Sinne (d.h. ein klar abgegrenztes Ziel, fixer Start- und Endtermin), eher sowas wie einen stetig laufenden Service. Ihr betreut offenbar verschiedene Systeme gleichzeitig, und reagiert halt dann immer sobald mal wieder eine neue Anfrage reinrieselt. Ich vermute mal, das temporäre Ziel ist dann aber innerhalb weniger Tage oder Wochen erledigt.

Man kann sich jetzt darüber streiten ob das so sinnvoll ist oder nicht, aber: wenn das bei euch so sein sollte, habt ihr wahrscheinlich wichtigere Sorgen als das Prozessmodell.


Löst Scrum eigentlich eine ordentliche Spezifikation ab? Normalerweise, bei Wasserfall, wird ja am Anfang eine fixe Architektur erstellt mit allen drum und dran (inkl. Methoden u.s.w). -Wie wird das bei Scrum gemacht?

Die Spezifikation sieht halt schlicht anders aus. Weg von den technischen Details, hin zum modellieren des Workflows. Die Architektur ist halt nur Mittel zum Zweck. Wenn man die zu früh spezifiziert, ohne konkret die Anforderungen an sie zu kennen, endet man halt schnell bei dicken Pflichtenheften die alles mögliche beschreiben, nur nicht das gewünschte Projekt. Im Endeffekt ist dem Kunden auch die Architektur schnurzpiepegal, es darf kein Tabu sein die Architektur nochmal auf den Kopf zu stellen, wenn es dem Projektziel nützt.
Scrum versucht die User Story immer im Fokus zu haben. Das heißt nicht dass man sonst nix dokumentieren muss, aber es wird halt spezifiziert sobald man das kann, und nicht vorher (wie es ja gerne im Wasserfallmodell passiert :rolleyes: )

[Unfug]

Prima, Vielen Dank für eure Antworten.

Ich werde mir wohl ein paar Features von Scrum | Kanban herausziehen. Komplett umsetzen wird nicht klappen. Es ist auch nicht so, dass wir keine ordentliche Software on Time bisher erstellt. Der Fokus lag bisher immer auf eine sehr sehr sehr ausführliche Spezifikation und die eigentliche Entwicklung wurde suboptimal begleitet.

Gruß

[noid]

Prima, Vielen Dank für eure Antworten.

Ich werde mir wohl ein paar Features von Scrum | Kanban herausziehen. Komplett umsetzen wird nicht klappen. Es ist auch nicht so, dass wir keine ordentliche Software on Time bisher erstellt. Der Fokus lag bisher immer auf eine sehr sehr sehr ausführliche Spezifikation und die eigentliche Entwicklung wurde suboptimal begleitet.

Gruß

Was genau in der Entwicklung? Das liest sich fast wie: "Spec ist super, aber ob hinten das richtige Rauskommt kann keiner mehr sagen". Wenn ihr Lücken in der Nachvollziehbarkeit zwischen Spezifikation und den Tests habt, dann werden euch andere Prozesse auch nicht helfen.
So blöd es klingt, aber ihr solltet euch entweder intern Gedanken machen was nicht rund läuft, oder eben einen Externen suchen - nur für die Bewertung.

[TongPo]

ich habe die scrum einführung nun schon in der dritten firma miterlebt und selbst auch einmal angestossen. das hauptproblem ist immer der grund, warum was an den prozessen geändert wird - es gibt nämlich immer zu viele projekte nebeneinander, zu viele aufgaben nebenbei und nichts wird fertig. und scrum (oder welche methode auch immer) ist halt kein zaubermittel, um entwickler schneller arbeiten zu lassen. eher im gegenteil sollen resourcen gebündelt und auf ein problem fokussiert werden.

meistens wird dann nach ein paar wochen der versuch "scrum" abgebrochen und übrig bleiben board und daily standups - das ist ja erstmal eine verbesserung, aber mit scrum hat das nicht viel zu tun.

[Frucht-Tiger]

Ich habe sehr gute Erfahrungen mit Scrum gemacht, allerdings wurde es in diesem Unternehmen auch sehr konsequent von allen Seiten durchgezogen.

Denke mal oft scheitert Scrum daran, dass der Product Owner nicht wirklicht mitspielt, er muss eben mit dem Machtverlust ggü konventionellen Vorgehensweisen leben können. Wenn nur die Entwickler mittels Scrum arbeiten, kann es sein volles Potential nicht ausschöpfen.

Allgemein macht es aber denke ich immer Sinn sich mal Scrum anzuschauen und mit dem eigenen Vorgehen zu vergleichen, auch wenn man es gar nicht einführen will. Da findet man immer Anregungen wo man bei sich verbessern könnte, z.B., dass es bei euch Spezialisten gibt die jeder ihr eigenes Tätigkeitsfeld haben, was ein sehr risikobehaftetes Vorgehen ist. Hier würde Scrum anregen das Wissen durch z.B. Pair Programming mit anderen Entwicklern zu teilen.

[noid]

Ich habe sehr gute Erfahrungen mit Scrum gemacht, allerdings wurde es in diesem Unternehmen auch sehr konsequent von allen Seiten durchgezogen.

Denke mal oft scheitert Scrum daran, dass der Product Owner nicht wirklicht mitspielt, er muss eben mit dem Machtverlust ggü konventionellen Vorgehensweisen leben können. Wenn nur die Entwickler mittels Scrum arbeiten, kann es sein volles Potential nicht ausschöpfen.

Allgemein macht es aber denke ich immer Sinn sich mal Scrum anzuschauen und mit dem eigenen Vorgehen zu vergleichen, auch wenn man es gar nicht einführen will. Da findet man immer Anregungen wo man bei sich verbessern könnte, z.B., dass es bei euch Spezialisten gibt die jeder ihr eigenes Tätigkeitsfeld haben, was ein sehr risikobehaftetes Vorgehen ist. Hier würde Scrum anregen das Wissen durch z.B. Pair Programming mit anderen Entwicklern zu teilen.

Pair programming... wäre auch mal interessant wie die Meinungen hier sind. Ich empfinde es als gefährlich, da meistens das Umfeld und die Vorraussetzungen nicht da sind - und dann pflanzt sich stellenweise ein Quark durch... unglaublich. :freak:

[Monger]

Pair programming... wäre auch mal interessant wie die Meinungen hier sind. Ich empfinde es als gefährlich, da meistens das Umfeld und die Vorraussetzungen nicht da sind - und dann pflanzt sich stellenweise ein Quark durch... unglaublich. :freak:
Das wäre ja jetzt ein allgemeines Argument gegen Wissensaustausch! ;)

Ich weiß von einigen Teams die damit mal experimentiert haben, aber wirklich hängen geblieben ist meines Wissens dabei bisher keiner.
Da halte ich Code Reviews für relevanter und praxisnäher.

[flagg@3D]

Bei uns wird für Feature Entwicklung oft Pair programming gemacht für gefährlichere Sachen (speziell unser Core Team) eher Code Reviews. Am besten gefällt mir aber, dass wir jetzt seit einem Jahr auch für technische Konzepte Reviewmeetings machen, das hat sich mMn. sehr ausgezahlt. Ein Feature wurde z.B. komplett eingestampft, als wir gemeinsam in einer Review bemerkt haben was da für ein Rattenschwanz dranhängt.