Klausur Zur Vorlesung Projektmanagement

Transkript

1 Klausur Zur Vorlesung Projektmanagement Name: Matrikelnummer: Fachbereich: Anmerkung: Englische Texte sind erlaubt. Einfacher Taschenrechner ist erlaubt. Desktop-Computer(chen) und Bücher sind nicht erlaubt. Bei der Klausur ist es wichtig, dass Sie die richtigen Stichworte verwenden. Lange Texte helfen nicht viel. In dieser Musterlösung sind mögliche Lösungen angegeben. Dies bedeutet nicht, dass dies die einzig möglichen Lösungen sind. Bei den Lösungen wurde insbesondere darauf geachtet, dess der untesrstrichene Text in der Lösung inhaltlich enthalten ist. Versionshistorie Zielstatus: fertig Version Status Datum Kommentar Verantwortlicher 1.0 Fertig Initiale Version Malte Foegen 1.1 Fertig Fehler korrigiert Malte Foegen 2.0 Fertig Musterlösung eingefügt Malte Foegen Seite 1

2 1. Multiple Choice (56 Punkte) Kreuzen Sie an, welche der folgenden Punkte bei jeder Frage zutreffen. a. Welche der folgenden Punkte defnieren ein Projekt? zeitlicher Anfang einmaliger Prozess Team zeitliches Ende einmaliges Endergebnis wendet CMMI an es gibt ein Projektmanagement b. Was bedeutet Institutionalisierung? Die Arbeitsweise... Ist in einer Organisation fest verwurzelt Ist durch ein Tool unterstützt Wird selbstverständlich umgesetzt Ist Teil der Organisationskultur Funktioniert automatisch, es muss sich keiner mehr darum kümmern Wird durch ein zentrales Team untersützt (z.b. durch Messungen) c. CMMI... Definiert, was gemacht werden muss Definiert, wie etwas gemacht werden muss Definiert die Vorgehensweise in einem Projekt Ist ein Referenzmodell Ist ein Vorgehensmodell Erfordert für jede Praktik ein spezielles Dokument d. Ein Capability Level... Definiert den Grad der Institutionalisierung für ein einzelnes Prozessgebiet Hat ein Generisches Ziel Hat mehrere Generische Ziele Hat eine generische Praktik Hat mehrere generische Praktiken Die generischen Praktiken definieren die Management-Aufgaben, die der Projektleiter für ein Prozessgebiet umsetzen muss Die generischen Praktiken definieren, wie die Institutionalisierung erreicht und aufrecht erhalten wird Seite 2

3 e. Ein Maturity Level... Umfasst eine bestimmte Menge von Prozessgebieten Umfasst eine Menge vonprozessgebieten, die die Organisation selbst aussuchen kann Erfordert einen bestimmten Capability Level für die Prozessgebiete des Maturity Levels Erfordert einen bestimmten Capability Level für alle Prozessgebiete, die die Organisation umsetzt Definiert die Reihenfolge der Prozessgebiete bei der Verbesserung andere Prozessgebiete dürfen nicht umgesetzt werden f. Requirements... Sind funktionale Anforderungen an das Produkt Sind nichtfunktionale Anforderungen an das Produkt Sine alle Wünsche der Anwender an das Produkt Sind Anforderungen und Rahmenbedingungen an das Projekt (wie z.b. Kostenrahmen, Budget, zeitliche Anforderungen, Ressourcenzusicherungen, Qualitätsanforderungen) Können beliebig geändert werden Stehen unter Konfiguartionsmanagement g. Ein Change Request Ist eine Anfrage zur Einbringung einer neuen Anforderung Ist eine Anfrage zur Änderung von Rahmenbedingungen (Ressourcen, Zeit) Bezieht sich auf eine Baseline Wird nur in großen Projekten benötigt Kann vom Auftraggeber (Product Owner) gestellt werden Kann vom Team gestellt werden Darf nicht vom Team gestellt werden h. Bidirectional traceability ( bidirektionale Verfolgbarkeit )... Ist zwischen allen Ergebnissen notwendig Bedeutet, dass ein Bezug zwischen Anforderungen und umsetzenden Arbeitsergebnissen hergestellt wird Bedeutet, dass man bei Arbeitsergebnissen sehen kann, auf Grund welcher Anforderungen sie erstellt wurden Bedeutet, dass ich weiß, auf welche Anforderungen sich Tests beziehen Wird in Scrum durch den ProductOwner gepflegt Hilft bei der Bewertung von Change Requests Seite 3

4 i. Was enthält ein Projektplan? Management Aufgaben Systemarchitektur Budget Zeitplan Anforderungen Meilensteine Datenmanagement Technische Aufgaben Konfigurationsmanagementsystem Risken Testfälle Ressourcen Code Stakeholder-Identifizierung und Einbindung j. Bei der Schätzung... Wird gleichzeitig der Zeitplan erstellt Werden wesentliche Arbeitsergebnisse oder -aufgaben (Work Breakdown Structure) identifiziert Muss die Function-Point Methode verwendet werden Werden für die Arbeitsergebnisse die Attribute geschätzt Werden Aufwand und Kosten geschätzt Werden Aufwand und Kosten auf Basis der Attribute ermittelt Werden die Projektphasen (project life cycle) bestimmt k. Was sind Attribute? Uhrzeit Größe / Umfang eines Arbeitsergebnisses Versionsnummer Qualitätsanspruch an ein Arbeitsergebnis Kosten Komplexität eines Arbeitsergebnisses Fähigkeiten des Bearbeiters l. Eine Baseline... Ist immer der Stand der Arbeitsergebnisse am Ende eines Tages Umfasst nur Code Ist eine Menge von Arbeitsergebnissen Ist ein bestimmter Versionsstand von Arbeitsergebnissen Ist die Basis weiterer Arbeit oder einer Auslieferung Wird nur zu Projektanfang und -ende gemacht Wird typischerweise zu Meilensteinen gemacht Seite 4

5 m. Bei Zulieferungen... Müssen nur Zulieferungen von externen Firmen überwacht werden Muss das Ergebnis abgenommen werden Müssen die Zulieferungen einfach nur bestellt werden Muss der Projektleiter den Fortschrit des Lieferanten überwachen Kann es sein, dass auch der Auftraggeber Zulieferungen beistellt Muss der Projektleiter darauf vertrauen, dass der Lieferant gute Prozesse hat n. Beim Risikomanagement gibt es die folgenden grundsätzlichen Möglichkeiten zum Umgang mit den Risiken: Risiko vermeiden (risk avoidance) Risiko verlagern (risk transfer) Risiko ignorieren (risk ignorance) Risiko drücken (risk squeezing) Risiko kontrollieren (risk control) Risiko überwachen (risk monitoring) Risiko akzeptieren (risk acceptance) Risiken verbergen (risk hiding) Seite 5

6 2. Scrum (39 Punkte) a. Was sind die drei Fragen beim Standup Meeting (Daily Scrum Meting)? (3 Punkte) What did you do yesterday? What will you do today? Is anything in your way? b. Was sind die wesentlichen Arbeitsergebnisse bei Scrum? Geben Sie den Namen an und definieren Sie mit einem Satz was das Arbeitsergebnis ist. (10 Punkte) Impediment Backlog all issues that have to be solved within or concerning the team Product Backlog A porioritized list of requirements/features of the Product Sprint Backlog The list of requirements/features selected for the Sprint and the tasks to implement the requirements/features Potentially Shippable Product The result of a Sprint Burndown Chart Estimated work remaining is updated daily Shows the progress of the work Seite 6

7 c. Wie werden Changes in Scrum behandelt? (3 Punkte) No change during a Sprint Changes to existing requirements/features or new requirements/features are added to the Product Backlog, and addressed in the next Sprint Planning (prioritized by Product owner, selected by Team) If a change to the existing Sprint is demanded by the Product Owner, the current Sprint is aborted and a new Sprint is started d. Was sind die wesentlichen Team-Meetings bei Scrum? Geben Sie den Namen an und definieren Sie das Meeting mit einem Satz. (8 Punkte) Sprint planning Analyze and evaluate product backlog Select sprint goal Create sprint backlog (tasks) from product backlog items Estimate sprint backlog in hours Sprint review Team presents what it accomplished during the sprint Sprint retrospective Periodically take a look at what is and is not working lessons learned Daily scrum meeting Status meeting Commitment to tasks in front of peers Seite 7

8 e. Was sind die drei wesentlichen Rollen bei Srcum? Welche Rechte und Pflichten hat jede Rolle? (15 Punkte) Rolle Recht Pflicht ProductOwner Define the features of the product Decide on release date and content Prioritize features according to market value Adjust features and priority every iteration, as needed Accept or reject work results Is responsible for the profitability of the product (ROI) Team Define which features are selected for implementatio nin one Sprint Determine effort for tasks Deliver the product. ScrumMaster Represent management to the project Enact Scrum values and practices Enable close cooperation across all roles and functions Remove impediments Ensure that the team is fully functional and productive Shield the team from external interferences Seite 8

9 3. Abgrenzung von PMC, PPQA, VER und VAL (20 Punkte) Grenzen Sie die Aufgabengebiete PMC, PPQA, VER und VAL gegeneinander ab. Tragen Sie dabei ein: Den vollständigen Namen des Aufgabengebiets Das Ziel des jeweiligen Aufgabengebiets Was untersucht wird Gegen was verglichen wird PMC Name: Project Monitoring and Control Ziel: provide an understanding of the project s progress so that appropriate corrective actions can be taken when the project s performance deviates significantly from the plan. Was wird untersucht: project s progress Gegen was wird verglichen: plan PPQA Name: Process and Product Quality Assurance Ziel: provide staff and management with objective insight into processes and associated work products. Was wird untersucht: processes and work products Gegen was wird verglichen: applicable process descriptions, standards, and procedures Seite 9

10 VER Name: Verification Ziel: ensure that selected work products meet their specified requirements. Was wird untersucht: selected work products Gegen was wird verglichen: specified requirements VAL Name: Validation Ziel: demonstrate that a product or product component fulfills its intended use when placed in its intended environment. Was wird untersucht: product or product component Gegen was wird verglichen: intended use Seite 10

11 4. Generische Praktiken (34 Punkte) a. Tragen Sie in die folgende Tabelle die Titel der 10 generischen Praktiken vom CMMI Capability Level 2 ein. Geben Sie ein typisches Arbeitsergebnis an, dass man sieht, wenn die Arbeit der generischen Praktik (ordentlich) gemacht wurde. Geben Sie an, welche Rolle für die Arbeit der jeweiligen generischen Praktik typischerweise verantwortlich ist. (30 Punkte) Name der generischen Praktik Establish an Organizational Policy GP 2.1 Typisches Arbeitsergebnis (Was sehe ich, wenn diese generische Praktik ordentlich gemacht wurde?) Ein Dokument mit den Policies Oder: Dokument mit den Richtlinien/Grundsätzen der Organisation Typische verantwortliche Rolle Senior Manager (z.b. CEO) Plan the Process (ok ist auch: Plan the work) GP 2.2 Ein Plan für die Arbeitschritte (mit Aktivitäten, Zeitplan, Risiken, etc.) Projektleiter bzw. jeder, der eine Arbeit führt (z.b. auch der Leiter des Testteams oder der PPQA) Provide Resources GP 2.3 Eine Ressourcenanfrage und genehmigung Oder: die Übereinstimmung von geplanten und vorhandenen Ressourcen (dann sind die notwendigen Ressourcen offensichtlich bereitgestellt worden) Ressourcenverantwortliche (z.b. Linienmanager) Seite 11

12 Assign Responsibility GP 2.4 Train People GP 2.5 Manage Configurations GP 2.6 Identify and Involve Relevant Stakeholders GP 2.7 Monitor and Control the Process (ok ist auch: Monitor and Control the work) GP 2.8 Rollendefinition mit Rechten und Pflichten Schulungsmaterial Oder: Liste der Ausbildungsmaßnahmen / Skills einer Person in der Personalakte Configuration Management Plan Oder: Konfigurationsmanagementsystem Oder: diverse Dokumente, die unter Konfigurationsmanagement stehen (ersichtlich durch Versionshistorie im Dokument oder im CM Tool) Stakeholder Involvement Plan Oder: Stakeholder-Diagramm Oder: Kommunikationsplan Tracking gegenüber dem Plan (z.b. aktuelle Aufwandswerte neben den geplanten Aufwänden im Plan) Statusbericht mit Kennzahlen Alle Personen in der Organisation, die Aufgaben zuweisen z.b. der Projektleiter (setzt sein Team ein) und der Linienmanager (setzt den Projektleiter ein) Linienmanager, der die Ausbildung der Mitarbeiter verantwortet (manchmal ein eigener Personalvorgesetzter) Projektleiter bzw. jeder, der eine Arbeit führt (z.b. auch der Leiter des Testteams oder der PPQA) (der Config Manager verantwortet das CM, aber der Führungsverantwortliche muss dafür sorgen, dass alle Mitarbeiter CM nutzen) Projektleiter bzw. jeder, der eine Arbeit führt (z.b. auch der Leiter des Testteams oder der PPQA) Projektleiter bzw. jeder, der eine Arbeit führt (z.b. auch der Leiter des Testteams oder der PPQA) mit seinem Team Linienmanager mit seinen Projektleitern Seite 12

13 Objectively Evaluate Adherence GP 2.9 Review Status with Higher Level Management GP 2.10 Bericht der PPQA zu einem Projekt Oder: Liste von Abweichungen (Non- Compliances) zu einem Projekt (oder einer überprüften Arbeitsweise) Protokoll des Reviews Oder: Review-Anleitung Oder: Offene Punkte (aus dem Review) PPQA (führt Evaluierungen durch) Linienmanagement (verfolgt Lösung der Abweichungen) Seniot Manager b. Wozu dienen die generischen Praktiken? (4 Punkte) Die generischen Praktiken unterstützen die Institutionalisierung der Arbeitsweise einer Organisation (d.h. sie helfen, dass Arbeitsweisen zum selbstverständlichen Teil der Unternehmenskultur werden -> siehe Multiple Choice Frage Seite 13

14 5. Übersicht über alle Prozessgebiete (30 Punkte) Geben Sie alle Prozessgebiete von CMMI an, die wir in der Vorlesung behandelt haben. Beschreiben Sie dessen Ziel und Zweck. Geben Sie für jedes Prozessgebiet ein typisches Arbeitsergebnis an, das die Arbeit dieses Prozessgebiets charakterisiert. Beschreiben Sie, warum dieses Prozessgebiet für das Projektmanagement von Bedeutung ist. Die Prozessgebiete PPQA und PMC lassen Sie bitte aus, da wir die schon in Aufgabe.3 hatten. Requirements Management Ziel und Zweck des Prozessgebiets: The purpose of Requirements Management is to manage the requirements of the project's products and product components and to identify inconsistencies between those requirements and the project's plans and work products. Ein typisches Arbeitsergebnis: Requirements Liste oder Change Request oder Traceability Matrix Warum dieses Prozessgebiet für Projektmanagement von Bedeutung ist: Die Anforderungen sind die Grundlage für die Planung des Projekts Project Planning Ziel und Zweck des Prozessgebiets: The purpose of Project Planning is to establish and maintain plans that define project activities. Ein typisches Arbeitsergebnis: z.b: Projektplan, Schätzung, Work Breakdown Structure Warum dieses Prozessgebiet für Projektmanagement von Bedeutung ist: Ohne Plan können die Aktivitäten des Projekts nicht gesteuert werden Supplier Agreement Management Ziel und Zweck des Prozessgebiets: The purpose of Supplier Agreement Management is to manage the acquisition of products from suppliers for which there exists a formal agreement. Ein typisches Arbeitsergebnis: z.b: Auswahl der Lieferungen und der Lieferanten, Vertrag, Statusberichte des Lieferanten, Ergebnisse eines Abnahme-Tests Warum dieses Prozessgebiet für Projektmanagement von Bedeutung ist: Um mit den Lieferanten die Lieferungen zu vereinbaren und die Lierferanten während der Erstellung des Lieferergebnisses führen zu können. Insgesant stellt SAM sicher, dass ich die richtige Zulieferung zum richtigen Zeitpunkt in der richtigen Qualität erhalte. Seite 14

15 Risk Management Ziel und Zweck des Prozessgebiets: The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives. Ein typisches Arbeitsergebnis: z.b: Risikoliste, Risk Management Plan, Liste der Minderungsmaßnahmen Warum dieses Prozessgebiet für Projektmanagement von Bedeutung ist: Um Risiken rechtzeitig zu identifizieren und zu mindern. Sichert die Stabilität eines Projekts Measurement and Analysis Ziel und Zweck des Prozessgebiets: The purpose of Measurement and Analysis is to develop and sustain a measurement capability that is used to support management information needs. Bzw: Aufbau der Fähigkeit einer Organisation, Messungen zu erheben und zu nutzen, um Informationen zur Steuerung und Führung bereitzustellen. Ein typisches Arbeitsergebnis: z.b. Kennzahlen, Definition der Kennzahlen, Statusberichte mit Kennzahlen Warum dieses Prozessgebiet für Projektmanagement von Bedeutung ist: Kennzahlen sind zur Verfolgung und Steuerung (d.h. für Monitoring and Control und für GP 2.8 Monitor and Control the work) notwendig Configuration Management Ziel und Zweck des Prozessgebiets: The purpose of Configuration Management is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. Ein typisches Arbeitsergebnis: z.b. Konfigurations-Management-System, Baseline, Versionshistorie von Dokumenten Warum dieses Prozessgebiet für Projektmanagement von Bedeutung ist: Konfigurationsmanagement hilft bei der Steuerung der Arbeitsergebnisse. Es vermeidet, dass Ergebnisse verloren gehen, dass Konfigurationen unklar sind. Es hilft mir als PL, zu erkennen, ob mein Team mit seinen Ergebnissen auf ein definiertes Ziel (Baseline) zuläuft und zeigt mir den aktuellen Status aller Arbeitsergebnisse. Seite 15

16 6. Earned Value (38 Punkte) a. Beschreiben Sie kurz, was die folgenden Abkürzungen bedeuten (6 Punkte) BCWS Budgeted Cost of Work Scheduled oder: Geplante Kosten für Geplante Arbeit ACWP Actual Cost of Work Performed oder: Tatsächliche Kosten der durchgeführten Arbeit BCWP Budgeted Cost of Work Performed oder: Geplante Kosten der durchgeführten Arbeit b. Geben Sie die Formeln für die folgenden Begriffe an und definieren Sie kurz deren Bedeutung (12 Punkte): SV Schedule Variance = BCWP BCWS Kosten der bisher geplanten und nicht durchgeführten Arbeit (negative Werte bedeuten einen zeitlichen Verzug) CV Cost Variance = BCWP ACWP Kostenabweichung bei den durchgeführten Arbeiten (negative Werte bedeuten Budgetüberzug) SPI Schedule Performance Index = BCWP / BCWS Abweichung vom Zeitplan in %; (1-SPI) ist der %-Satz, den das Projekt derzeit hinter dem Zeitplan liegt (oder: <1: Projekt ist hinter Zeitplan, >1: Projekt ist vor dem Zeitplan). CPI Cost Performance Index = BCWP / ACWP Abweichung von den Kosten in %; (1-CPI) ist der %-satz, den das Projekt derzeit über den geplanten Kosten liegt (oder: <1: Projekt über dem geplantenbudget, >1: Projekt ist unter dem geplantenbudget). BAC Budget at Completion = Summe aller geplanten Kosten bis Projektende EAC Estimate at Completion = ACWP + ( (BAC BCWP) / CPI ) Geschätzte Kosten zu Projektende unter Berücksichtigung der bisherigen Abweichungen Seite 16

17 Arbeitsergebnis c. Berechnen Sie den Earned Value, den das folgende Projekt am hatte und prognostizieren Sie den wahrscheinlichen Gesamtaufwand zum Ende des Sprints (20 Punkte). Geplantes Fertigstellungsdatum Geplanter Aufwand (in Personentagen) Tatsächliches Fertigstellungsdatum Tatsächlicher Aufwand (in Personentagen) (hier Spaltentitel hinschreiben) BCWS (hier Spaltentitel hinschreiben) BCWP Product Backlog 25/01/ /01/ and Sprint Goal Sprint 28/01/ /01/ Backlog Sketch von 29/01/ /01/ Webseite Bestell-Button im 31/01/ /02/ Formular Hierarchisches 05/02/ /02/ Menü Newsletter 07/02/ /02/ eingebunden Content für 30/01/ Webseite Bilder für 31/01/ /01/ Webseite Display-Fehler 04/02/ /02/ beseitigt Drucken- 05/02/ /02/ Funktion Ansprechpartner 06/02/ mit Bild Sprint 08/02/ Review Sprint 11/02/ Retrospective Summen SV -4 CV -2 SPI 0.76 CP 0.87 BAC 23 EAC 26.5 (hier Spaltentitel hinschreiben) ACWP Wahrscheinlicher Gesamtaufwand: 26.5 Personentage Seite 17

18 7. Messung und Analyse (12 Punkte) a. MA Geben Sie drei Beispiele für Messungen in einem Projekt an. Geben Sie für jede Messung an: Name der Messung Definition der Messung Wer ist für die Messung verantwortlich Wer nutzt die Messung Earned Value hatten wir schon, dass können Sie hier nicht mehr aufführen Name: Phase Containment Effectiveness Definition: beschreibt, wie gut ein Team in der Lage ist, Fehler zu finden, indem es die entdeckten Fehler in Phase (Error) mit den Fehlern, die in späteren Phasen gefunden werden (Defects) vergleicht. Wer ist für die Messung verantwortlich: Das Projektteam Wer nutzt die Messung: Das Projektteam, um die Effektivität der Verfication-Verfahren zu analysieren und verbessern Name: Burndown Chart Definition: beschreibt den Restaufwand, den Team für einen Sprint noch hat y-achse: Restaufwand pro Sprint in h x-achse: Zeit Wer ist für die Messung verantwortlich: das Projektteam Wer nutzt die Messung: das Projektteam, um den Restaufwand je Sprint zu verfolgen Name: Änderung von Anforderungen in % Definition: y-achse: %-Anzahl der geänderten Anforderungen y-achse: Zeit (z.b. %-Anzahl der geänderten Anforderungen vergangener Sprints jeweils zu Beginn eines jeweiligen Sprints) Beschreibt, wie viele Anforderungen geändert wurden und gibt damit Auskunft über die Stabilität der Anforderungen Wer ist für doe Messung verantwortlich: das Projektteam Wer nutzt die Messung: das Projektteam und der ProductOwner Seite 18

19 8. Beispielfall (50 Punkte) Lesen Sie das folgende Beispiel durch. Identifizieren Sie die Probleme, die das Projekt hat. Denken Sie bei den Problemen auch an die Projektumgebung werden auch hier Fehler gemacht? Nutzen Sie, wenn möglich, Begriffe aus CMMI, um die Probleme präzise zu lokalisieren. Fassen Sie sich kurz und geben Sie Ihre Maßnahmen als Liste an. Lange Sätze sind nicht erwünscht. Geben Sie für jeden von Ihnen identifizierten Punkt an: Was Sie als Problem sehen Welche spezifische(n) oder generische(n) Praktik(en) von CMMI nicht umgesetzt ist(sind) (und deren fehlende/mangelnde Umsetzung zu dem Problem führt) Wer jetzt was tun sollte Szenario: Die QuickBuild Software AG setzt Scrum als Planungstechnik ein. Nach der Sprint- Planung mit Maria (ProductOwner) und der Aufstellung des Sprint Backlogs hat das Team angefangen, die identifizierten Aufgaben, die im Sprint Backlog stehen, abzuarbeiten. Jack, ein erfahrener Projektleiter, ist allerdings ganz neu in seiner Rolle als ScrumMaster und lernt gerade noch die agilen Planungstechniken. Der Senior Manager Klaus hat für die Firma Scrum als verbindliche Planungstechnik festgelegt, Jack traut ihr aber nicht so ganz und nutzt lieber seine bewährten Planungstechniken. Die Standup-Meetings waren Jack zu aufwendig, er hat diese daher mit den Worten bitte stimmt euch selbständig ab ihr seid ja alle in einem Großraumbüro gestrichen. Statt dessen verfolgt Jack die Aufwände lieber selbst, indem er im Team rumgeht und nach den Restaufwänden fragt. Leider hat Jack aber diese Woche keine Zeit, da er noch die Änderungswünsche von Klaus in den Sprint Plan einarbeitet. Zur Sicherheit damit keiner vom Team nervös wird, speichert Jack den Plan nur auf seiner lokalen Platte ab. Den Statusreport für Klaus füllt Jack da er ja diese Woche keine aktuellen Aufwände hat mit hochgerechneten Zeiten aus. Das wird schon hinkommen denkt er. Dabei kommt Simon (ein Teammitglied) vorbei und erzählt, dass der Lieferant eine unbekannte Bibliothek nutzt und sie daher vielleicht länger zum Integrieren brauchen. Außerdem müsste der Betrieb informiert werden, damit er diese Bibliothek auf dem Produktionssystem installiert. Das müsste alles noch als Aufgaben in das Sprint Backlog aufgenommen werden. Jack winkt ab: Das geht nicht, wir müssen mit den Aufwänden hinkommen, die wir haben. So geht der Sprint-Monat ins Land. Am Ende hat das Team trotz aller Widrigkeiten dennoch ein lauffähiges Produkt, allerdings fehlen einige Anforderungen. Jack meint: kein Problem, das machen wir im nächsten Sprint, das merkt ja keiner. Das Team stöhnt leise vor sich hin und hofft, das einer mit Jack mal die Planungstechnik reviewt. Seite 19

20 CMMI Praktik (Wo liegt das Problem? Was wird nicht gemacht?) GP 2.5 Train People GP 2.9/PPQA Objectively Evaluate PMC SP 1.6 Conduct Progress Reviews REQM SP 1.3 Manage Requirements Changes GP 2.6/ CM Manage Configurations GP 2.7 Involve Stakeholder MA SG 2 Provide Measurement Results GP 2.8 Monitor and Control GP 2.10 Senior Management Review PMC SG 2 Manage Corrective Actions Problem Jack traut Scrum nicht so ganz und nutzt lieber seine bewährten Planungstechniken Das Team hofft, das einer mit Jack mal die Planungstechnik reviewt -> offensichtlich gibt es keine PPQA, die prüft, ob Jack die Scrum-Techniken richtig umsetzt Jack macht keine Standup-Meetings Jack arbeit Änderungswünsche von Klaus in den Sprint Plan ein Jack speichert den Plan nur auf seiner lokalen Platte ab, damit das Team nicht nervös wird, wenn es den angepassten Plan sieht Den Statusreport für Klaus füllt Jack da er ja diese Woche keine aktuellen Aufwände hat mit hochgerechneten Zeiten aus. Das wird schon hinkommen denkt er. Dabei kommt Simon (ein Teammitglied) vorbei und erzählt, dass der Lieferant eine unbekannte Bibliothek nutzt und sie daher vielleicht länger zum Integrieren brauchen. Außerdem müsste der Betrieb informiert werden, damit er diese Bibliothek auf dem Produktionssystem installiert. Das müsste alles noch als Aufgaben in das Sprint Backlog aufgenommen werden. Jack winkt ab: Das geht nicht, wir müssen mit den Aufwänden hinkommen, die wir haben. Wer jetzt was tun sollte Coaching für Jack, damit er die scrum Planungstechniken lernt Durchführung von Audits/Reviews mit Jack auf seine Scrum Vorgehzenweise, um Abweichungen zu entdecken und zu adressieren Scrum Change Request Verfahren einhalten Alle Ergebnisse im Projektrepository ablegen und unter Konfigurationsmanagement stellen Das Team in die Planung einbinden Die Messungen werden nicht gemacht Jack nutzt die Messungen nicht zur Steuerung seines Projekts Ein Manager sollte mit Jack regelmäßig den Status des Projekts besprechen, anstatt nur einen Der Senior Manager sollte eine repräsentative Auswahl von Projekten reviewen, damit er weiß, inwieweit seine Vorgabe, Scrum zu leben, umgesetzt wird, und damit er Probleme adressieren kann Die Issues (bei Sprint: Impediments genannt) müssen behandelt (und nicht ignoriert) werden Seite 20

21 PP SP 2.6 Plan Stakeholder Involvement GP 2.7 Involve Stakeholders REQM SP 1.4 Maintain Traceability REQM SP 1.5 Identify Inconsistencies PP SG 3 Obtain Commitment Außerdem müsste der Betrieb informiert werden, damit er diese Bibliothek auf dem Produktionssystem installiert. allerdings fehlen einige Anforderungen Die Beteiligten und Betroffenen hier der Betrieb müssen eingebunden werden Jack muss verfolgen, welche Anforderungen umgesetzt werden Für den nächsten Sprint müssen die nicht umgesetzten Anforderungen wieder in das Product Backlog aufgenommen werden. Der Product Owner nicht Jack entscheidet, ob diese Anforderungen in den nächsten Sprint aufgenommen werden. Hier fehlt das Commitment vom Product Owner zum Plan (da Jack einfach etwas aufnimmt, dass der ProductOwner für den nächsten Sprint nicht bestellt hat). Auch generell bügelt Jack Einwände des Teams ab fraglich ist, ob es auch ein Commitment des Teams zum aktuellen Plan und den Maßnahmen von Jack gibt. Seite 21