Qualitätsmanagement für Software-Projekte

Posts 1-10 of 12

Back
Next

Gerhard Weinand Premium Member Group moderator
The company name is only visible to registered members.

19 Dec 2010, 11:43 pm

Lessons learned

Endlich! Das Projekt / das Release ist fertig, der Kunde ist zufrieden und freut sich auf viele neue Features (und Fehler).

Jetzt ist die Zeit für ein "lessons learned"! Während sich das Management gegenseitig auf die Schultern klopft setzen sich die IT'ler aus verschiedenen Abteilungen wie Entwicklung und Test zusammen und beratschlagen, wie man es beim nächsten Mal besser, effizienter oder einfach nur anders machen kann.

So oder ähnlich läuft es in vielen Unternehmen ab. Doch wie wird das gelernte umgesetzt? Kann sich noch irgendjemand an das letzte lessons learned erinnern? Gab es vielleicht sogar Ergebnisse? Und wer geht da überhaupt hin?

Ich sehe schon die ersten Antworten aus dem Lehrbuch wie "bei uns ist das lessons learned als Bestandteil des kontinuierlichen Verbesserungsprozesses fest in der IT verankert." Das sieht super aus in jeder Powerpoint-Präsentation! Aber wie läufts bei Ihnen wirklich?

Viele Grüße
Gerhard Weinand
Gerhard Weinand wrote: > Endlich! Das Projekt / das Release ist fertig, der Kunde ist > zufrieden und freut sich auf viele neue Features (und Fehler). > > Jetzt ist die Zeit für ein "lessons learned"! Während sich das > Management gegenseitig auf die Schultern klopft setzen sich die > IT'ler aus verschiedenen Abteilungen wie Entwicklung und Test > zusammen und beratschlagen, wie man es beim nächsten Mal besser, > effizienter oder einfach nur anders machen kann. > > So oder ähnlich läuft es in vielen Unternehmen ab. Doch wie wird das > gelernte umgesetzt? Kann sich noch irgendjemand an das letzte lessons > learned erinnern? Gab es vielleicht sogar Ergebnisse? Und wer geht da > überhaupt hin? > > Ich sehe schon die ersten Antworten aus dem Lehrbuch wie "bei uns ist > das lessons learned als Bestandteil des kontinuierlichen > Verbesserungsprozesses fest in der IT verankert." Das sieht super aus > in jeder Powerpoint-Präsentation! Aber wie läufts bei Ihnen wirklich? > > Viele Grüße > Gerhard Weinand
Post visible to registered members
Dr. Thomas Servene Group moderator
The company name is only visible to registered members.

20 Dec 2010, 07:41 am

Re: Lessons learned

Gerhard Weinand schrieb:

Jetzt ist die Zeit für ein "lessons learned"! Während sich das Management gegenseitig auf die Schultern klopft setzen sich die IT'ler aus verschiedenen Abteilungen wie Entwicklung und Test zusammen und beratschlagen, wie man es beim nächsten Mal besser, effizienter oder einfach nur anders machen kann.
So oder ähnlich läuft es in vielen Unternehmen ab. Doch wie wird das gelernte umgesetzt? Kann sich noch irgendjemand an das letzte lessons learned erinnern? Gab es vielleicht sogar Ergebnisse? Und wer geht da überhaupt hin?
An einem Lessons Learned Workshop sollten alle Projektbeteiligten teilnehmen. Bei verteilter Entwicklung kann es notwendig sein, mehrere Workshops an den beteiligten Entwicklungsstandorten durchzuführen und die Ergebnisse gemeinsam zu diskutieren. Ggf. ist manchmal eine 5-Why-Analyse erforderlich, um zur eigentlichen Ursache des Problems vorzudringen. Das kann sehr aufwändig sein, ist aber meiner Erfahrung nach sehr erfolgreich.

Aus einem Lessons Learned lassen sich meist konkrete Maßnahmen ableiten. Diese müssen mit einem konkreten Termin versehen werden (manchmal heisst es auch nur 'nächstes Projekt'). Die QS tracked dann die Abarbeitung der Maßnahmen. So geht nichts verloren.

T. Servene
Dr. Thomas Servene wrote: > Gerhard Weinand schrieb: > > > Jetzt ist die Zeit für ein "lessons learned"! Während sich das > > Management gegenseitig auf die Schultern klopft setzen sich die > > IT'ler aus verschiedenen Abteilungen wie Entwicklung und Test > > zusammen und beratschlagen, wie man es beim nächsten Mal besser, > > effizienter oder einfach nur anders machen kann. > > So oder ähnlich läuft es in vielen Unternehmen ab. Doch wie wird das > > gelernte umgesetzt? Kann sich noch irgendjemand an das letzte lessons > > learned erinnern? Gab es vielleicht sogar Ergebnisse? Und wer geht da > > überhaupt hin? > > An einem Lessons Learned Workshop sollten alle Projektbeteiligten > teilnehmen. Bei verteilter Entwicklung kann es notwendig sein, > mehrere Workshops an den beteiligten Entwicklungsstandorten > durchzuführen und die Ergebnisse gemeinsam zu diskutieren. Ggf. ist > manchmal eine 5-Why-Analyse erforderlich, um zur eigentlichen Ursache > des Problems vorzudringen. Das kann sehr aufwändig sein, ist aber > meiner Erfahrung nach sehr erfolgreich. > > Aus einem Lessons Learned lassen sich meist konkrete Maßnahmen > ableiten. Diese müssen mit einem konkreten Termin versehen werden > (manchmal heisst es auch nur 'nächstes Projekt'). Die QS tracked dann > die Abarbeitung der Maßnahmen. So geht nichts verloren. > > T. Servene
Mark Michaelis
The company name is only visible to registered members.

20 Dec 2010, 08:27 am

Re: Lessons learned

Bei uns war ein "Lessons Learned" ein schon lange verwendeter Begriff. Einige verhallten irgendwann mit der Zeit, moderten dahin im Unternehmenswiki. Inzwischen setzen wir in der Entwicklung auf Scrum und ein fester Bestandteil ist dort die Retrospektive. Wichtig dabei vielleicht: Diese Retrospektive findet im Kleinen statt - in einem kleinen Team.

Die Erkenntnisse aus dieser Retrospektive finde ich immer sehr hilfreich und es werden Maßnahmen beschlossen, um den dringlichsten Problemen zu begegnen (oder besonders gut gemachte Dinge zu unterstreichen). Diese Maßnahmen fließen meist in Team-Spielregeln hinein - eine kurze Liste, was wir innerhalb des Teams beachten wollen.

Wichtig dabei: Die Liste der Regeln ist ein lebendes Dokument. Bei jeder Retrospektive wird überprüft, ob Punkte darauf noch valide sind, oder uns beschlossene Regeln vom letzten Mal geholfen haben.

Ob nun Scrum oder nicht, ich denke, das Wichtigste ist: Kurze Zyklen (z. B. 2 Wochen), stetige Review-Prozesse, Review-Ergebnisse in Regeln/Maßnahmen festhalten und diese Regeln/Maßnahmen auch beim nächsten Review-Prozess mit betrachten.
Mark Michaelis wrote: > Bei uns war ein "Lessons Learned" ein schon lange verwendeter > Begriff. Einige verhallten irgendwann mit der Zeit, moderten dahin im > Unternehmenswiki. Inzwischen setzen wir in der Entwicklung auf Scrum > und ein fester Bestandteil ist dort die Retrospektive. Wichtig dabei > vielleicht: Diese Retrospektive findet im Kleinen statt - in einem > kleinen Team. > > Die Erkenntnisse aus dieser Retrospektive finde ich immer sehr > hilfreich und es werden Maßnahmen beschlossen, um den dringlichsten > Problemen zu begegnen (oder besonders gut gemachte Dinge zu > unterstreichen). Diese Maßnahmen fließen meist in Team-Spielregeln > hinein - eine kurze Liste, was wir innerhalb des Teams beachten > wollen. > > Wichtig dabei: Die Liste der Regeln ist ein lebendes Dokument. Bei > jeder Retrospektive wird überprüft, ob Punkte darauf noch valide > sind, oder uns beschlossene Regeln vom letzten Mal geholfen haben. > > Ob nun Scrum oder nicht, ich denke, das Wichtigste ist: Kurze Zyklen > (z. B. 2 Wochen), stetige Review-Prozesse, Review-Ergebnisse in > Regeln/Maßnahmen festhalten und diese Regeln/Maßnahmen auch beim > nächsten Review-Prozess mit betrachten.
Dr. Roland Philipp Hofmann
The company name is only visible to registered members.

20 Dec 2010, 08:54 am

Re^2: Lessons learned

Erfahrungsgemäß am besten: Wenn irgend möglich, sobald ein Problem aufgetaucht ist, überlegen, woran es lag, und wie man es verhindern hätte können, und dann sofort die Lösung implementieren. Wenn also genug Zeit dazu ist, nicht erst bis zum Ende des Projektes warten, denn dann hat man entweder das Problem oder aber die Details über seine Ursachen bereits vergessen.

Das spricht nicht gegen ein regelmäßiges Washup-Meeting. Man sollte aber die Lösungen nicht solange verschieben.

Schöne Grüße,
rph
Dr. Roland Philipp Hofmann wrote: > Erfahrungsgemäß am besten: Wenn irgend möglich, sobald ein Problem > aufgetaucht ist, überlegen, woran es lag, und wie man es verhindern > hätte können, und dann sofort die Lösung implementieren. Wenn also > genug Zeit dazu ist, nicht erst bis zum Ende des Projektes warten, > denn dann hat man entweder das Problem oder aber die Details über > seine Ursachen bereits vergessen. > > Das spricht nicht gegen ein regelmäßiges Washup-Meeting. Man sollte > aber die Lösungen nicht solange verschieben. > > Schöne Grüße, > rph
Winrich Germann Premium Member
The company name is only visible to registered members.

20 Dec 2010, 5:44 pm

Re: Lessons learned: Interne Audits!

Die "Lessons Learned" Workshops, an denen ich als Vertreter von IT Quality teilnehmen durfte, waren meist völlig unverbindliche Abschluss-Shows des Projektmanagements. Außerdem noch auf Grund der hohen Anzahl an Beteiligten richtig teuer.
Wesentlich sinnvoller ist m.E. die systematische Auditierung des Projektes bzw. des Entwicklungsprozesses durch einen nicht direkt beteiligten internen Auditor.

Fragen könnten z.B. sein:
- Wurden die Projektziele aus dem Projektantrag nachweisbar erreicht?
- Sind nachträgliche Änderungen des Projektumfangs vom Sponsor freigegeben?
- Konnte der geplante Business-Nutzen tatsächlich realisiert werden?
- Steht die Leistung (z.B. Features, Codequalität) in einem akzeptablen Verhältnis zum verbrauchten Budget?
- Gab es im Projekt ein proaktives Risikomanagement? Wurden ggf. Probleme rechtzeitig eskaliert?
- Erfolgten Milestone-Abnahmen zeitnah und nachvollziehbar?
- Ist die Projektdokumentation zeitnah und vollständig?
- Existieren nachvollziehbare Nachweise für die Leistung (z.B. dokumentierte Tests, Trainingsprotokolle)?

Interne Audits sind ein sehr wirksames Management-Werkzeug. Meine Erfahrungen in diesem Bereich gebe ich gerne an Sie weiter - kontaktieren Sie mich bei Interesse einfach über Xing.
Winrich Germann wrote: > Die "Lessons Learned" Workshops, an denen ich als Vertreter von IT > Quality teilnehmen durfte, waren meist völlig unverbindliche > Abschluss-Shows des Projektmanagements. Außerdem noch auf Grund der > hohen Anzahl an Beteiligten richtig teuer. > Wesentlich sinnvoller ist m.E. die systematische Auditierung des > Projektes bzw. des Entwicklungsprozesses durch einen nicht direkt > beteiligten internen Auditor. > > Fragen könnten z.B. sein: > - Wurden die Projektziele aus dem Projektantrag nachweisbar erreicht? > - Sind nachträgliche Änderungen des Projektumfangs vom Sponsor > freigegeben? > - Konnte der geplante Business-Nutzen tatsächlich realisiert werden? > - Steht die Leistung (z.B. Features, Codequalität) in einem > akzeptablen Verhältnis zum verbrauchten Budget? > - Gab es im Projekt ein proaktives Risikomanagement? Wurden ggf. > Probleme rechtzeitig eskaliert? > - Erfolgten Milestone-Abnahmen zeitnah und nachvollziehbar? > - Ist die Projektdokumentation zeitnah und vollständig? > - Existieren nachvollziehbare Nachweise für die Leistung (z.B. > dokumentierte Tests, Trainingsprotokolle)? > > Interne Audits sind ein sehr wirksames Management-Werkzeug. Meine > Erfahrungen in diesem Bereich gebe ich gerne an Sie weiter - > kontaktieren Sie mich bei Interesse einfach über Xing.
Post visible to registered members
Pierre Kaufmann Premium Member
The company name is only visible to registered members.

21 Dec 2010, 12:09 pm

Re: Lessons learned

Lesson learned aus dem praktizierten Ansatz einer LL session ist, daß einer Präsentation keine Maßnahme folgt. Denn das nächste Projekt ist bereits angelaufen, Maßnahmen sind oft mit Trainings verbunden, dazu fehlen Zeit und ein Investitionswille seitens der Unternehmensführung. Ursache sind u.a. Kostendruck und kurze Entwicklungszyklen. Sind Paradigmenwechsel oder Änderungen in Prozessen erforderlich, wird meist auf das bestehendes Muster zurückgegriffen. Gründe auch hierfür siehe oben. Kurzum: Als Instrument sehr wichtig und informativ duch Offenlegung von Prozess- und ggf Skill-Lücken, über diese Erkenntnis hinaus leider zu wenig abgeleitete nachhaltige Maßnahmen. Lösung: Letztendlich Eigeninitiative ergreifen im möglichen Rahmen. VG, PK
Pierre Kaufmann wrote: > Lesson learned aus dem praktizierten Ansatz einer LL session ist, daß > einer Präsentation keine Maßnahme folgt. Denn das nächste Projekt ist > bereits angelaufen, Maßnahmen sind oft mit Trainings verbunden, dazu > fehlen Zeit und ein Investitionswille seitens der > Unternehmensführung. Ursache sind u.a. Kostendruck und kurze > Entwicklungszyklen. Sind Paradigmenwechsel oder Änderungen in > Prozessen erforderlich, wird meist auf das bestehendes Muster > zurückgegriffen. Gründe auch hierfür siehe oben. Kurzum: Als > Instrument sehr wichtig und informativ duch Offenlegung von Prozess- > und ggf Skill-Lücken, über diese Erkenntnis hinaus leider zu wenig > abgeleitete nachhaltige Maßnahmen. Lösung: Letztendlich > Eigeninitiative ergreifen im möglichen Rahmen. VG, PK
Post visible to registered members
Frank Möhle
The company name is only visible to registered members.

27 May 2011, 3:28 pm

Re^2: Lessons learned

Lessons Learned ist eigentlich gut gemeint; ich glaube in der Praxis wird dieser Abschnitt im "Lebenszyklus" eines Projektes zu oft vergessen.

So nach dem Motto: Kunde hat das Projekt abgenommen, das nächste Projekt steht schon vor der Tür, und eine Kostenstelle für LL gibt es nicht. Unter solchen Bedingungen ist doch klar, wie sich ein budget-gesteuerter Projektleiter verhalten wird.
Wer gerade den Kaffee genossen habe (Projekt abgenommen), hat meistens keine Lust mehr auf den Kaffesatz in der Tasse ;-)

Bei uns im Bereich haben wir das Thema in die regelmäßigen multiprojekt-Runden verlegt. Wenn ein PL eine "rote Ampel" zu berichten hat, gibt es die standard-Frage "wie könnte ein ähnliches Problem das nächste mal vermieden werden". Dabei kommen dann schon mal sehr gute Verbesserungsvorschläge.

anderer Aspekt: wer ISO9001 zertifiziert ist, muss nachweisen dass er den "kontinuierlichen Verbesserungsprozess" im Griff hat. Und da ist LL ein gutes Argument. Wichtig ist nur, dass es jemanden gibt, der den "Ball" auffängt, und für die Nachverfolgung der Verbesserungs-Massnahme sorgt.
This post was modified on 27 May 2011 at 03:38 pm.
Frank Möhle wrote: > Lessons Learned ist eigentlich gut gemeint; ich glaube in der Praxis > wird dieser Abschnitt im "Lebenszyklus" eines Projektes zu oft > vergessen. > > So nach dem Motto: Kunde hat das Projekt abgenommen, das nächste > Projekt steht schon vor der Tür, und eine Kostenstelle für LL gibt es > nicht. Unter solchen Bedingungen ist doch klar, wie sich ein > budget-gesteuerter Projektleiter verhalten wird. > Wer gerade den Kaffee genossen habe (Projekt abgenommen), hat > meistens keine Lust mehr auf den Kaffesatz in der Tasse ;-) > > Bei uns im Bereich haben wir das Thema in die regelmäßigen > multiprojekt-Runden verlegt. Wenn ein PL eine "rote Ampel" zu > berichten hat, gibt es die standard-Frage "wie könnte ein ähnliches > Problem das nächste mal vermieden werden". Dabei kommen dann schon > mal sehr gute Verbesserungsvorschläge. > > > anderer Aspekt: wer ISO9001 zertifiziert ist, muss nachweisen dass er > den "kontinuierlichen Verbesserungsprozess" im Griff hat. Und da ist > LL ein gutes Argument. Wichtig ist nur, dass es jemanden gibt, der > den "Ball" auffängt, und für die Nachverfolgung der > Verbesserungs-Massnahme sorgt.