Anti Pattern in Project Management
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Albert Zündorf
6. Anti Pattern in Project Management
Buch:
W. J. Brown, H. W. McCormick III, S. W, Thomas: AntiPatterns in Project Management;
Wiley,ISBN 0-471-36366-9, 2000
• Liste typischer Fehler im Projekt Management
• wird garantiert jedem mal begegnen
• wird im Hautpstudium in "Software Engineering II" Vorlesung vertieft
SE7ProjManAntiPattern.fm,1Albert Zündorf
Das "Size Isn’t Everything" Anti-Pattern
(How to have a baby in one month with nine women)
Problem:
• zu viele Leute in einem Team behindern sich gegenseitig
- Besprechngen
- doppelte Arbeiten
- Kompetenzstreitigkeiten
-...
• Personalbedarf ändert sich über’s Projekt (wenig, wenig, wenig, viel, mittel)
SE7ProjManAntiPattern.fm,2Albert Zündorf
• es gibt eine "optimale" Teamgröße für ein Projekt:
SE7ProjManAntiPattern.fm,3Albert Zündorf
Auswege:
• nach Boehm / Balzert:
optimale Entwicklungsdauer = 2,5 * Personenmonate0,35
optimale Teamgröße = Personenmonate / optimale Entwicklungsdauer
• Bei 9 Monaten Aufwand ergibt sich daraus z.B.
- optimale Entwicklungsdauer = 2,5 * 90,35 = 5,3 Monate
- optimale Teamgröße = 9 Personenmonate / 5,3 Monate = 2 Personen
• besser bei Humphrey nachschaun
• langsames Teamwachstum
• gewachsene Teams (siehe sd&m)
SE7ProjManAntiPattern.fm,4Albert Zündorf
Das "Batteries Not Included" Anti-Pattern
Problem:
• Einführung neuer Tools / Technologien / Programiersprachen wird oft unterschätzt
• Lieferzeiten
• Hardware-Anforderungen
• Einarbeitungszeiten / Schulungsaufwand
• mangelnde Stabilität / Funktionalität
Lösung:
• Einführung planen
• Pilotprojekte
• schrittweise Ausweitung
Variante:
• häufige Upgrades
SE7ProjManAntiPattern.fm,5Albert Zündorf
Das "Gilding the Lily" oder "Gold Plating" Anti-Pattern
(auch "Second System Syndrom")
Problem:
• Technik verliebte Teammitglieder / Designer wollen eine 150% Lösung machen
• aufwändige Lösungen für selten gebrauchte Funktionalität
• unnötige Bitfummelei
• übertriebene Speichereffizienz
• ...
Gründe:
• zu viel Zeit in der Anforderungs- und Analyse-Phase
• Detail-verliebter Kunde (späterer Anwender)
• Design-verliebte Architekten
• Technik-verliebte Entwickler
SE7ProjManAntiPattern.fm,6Albert Zündorf
Lösungen:
• begrenzte Budgets
• Reviews
• gutes / starkes / technisch kompetentes Mangement
SE7ProjManAntiPattern.fm,7Albert Zündorf
Das "One-Shot Deal" Anti-Pattern
Merke: Provisorien halten machmal sehr lange
Problem:
• Man braucht "mal eben schnell" ein kleines Script / Programm für eine kleine, einmalige Auf-
gabe
• das funktioniert gut
• das spricht sich rum
• das könnte doch eigentlich auch noch das und das machen
• ...
• So wird aus der Kaffeekassen-Tabelle ein vollständiges Buchhaltungsprogramm
• So wird aus der CD-Verwaltung ein Multi-Media-Recherche System
• So wird aus dem Fujaba-Zeilenzähl-Skript ein Work-Flow-System
• ...
• Lisp
Lösung:
• rechtzeitig erkennen und durch richtiges Projekt ablösen
SE7ProjManAntiPattern.fm,8Albert Zündorf
Das "Micro-Management" Anti-Pattern
Problem:
• der Projektmanager trifft auch Detailentscheidungen selber
• der Projektmanager macht viel (die spannende) technische Arbeit selber
• damit ist der Projektmanager typischerweise überfordert
• wichtige Dinge bleiben liegen
• die Entwickler fühlen sich gegängelt
• der Projektmanager respektiert / anerkennt nicht die technische Kompetenz der Entwickler
• Entwickler werden zu "niederen" Befehlsempfängern
• Entwickler warten lange auf Entscheidungen
• keine Motivation
• keine Perspektiven
• schlechte Produktivität
SE7ProjManAntiPattern.fm,9Albert Zündorf
Gründe:
• schlechte "Menschenführung"
• schlechte Planung und hektische Änderungen => ständiger wechsel der Aufgabeneinteilung
• "Aufgabenverteilung" in der Gruppe ist noch unklar, das Team / der Entwickler muss
- sich formen
- sich Kompetenzen erkämpfen
- zu klarer Aufgabenverteilung finden
• Rollenverteilung zwischen Projektmanager und Entwicklern ist noch unklar
• Projektmanager hat lieblings "Superprogrammierer"
SE7ProjManAntiPattern.fm,10Albert Zündorf
Auswege:
• Mitarbeiter sind "Human Resources" (wertvolles Kapital)
• Entwickler "Empowerment"
Mitarbeiter dürfen in ihrem Aufgabenbereich weitgehend selbständig entscheiden
• Mitarbeiter werden in Planungen einbezogen
• Mitarbeiterweiterbildung
• Gruppendynamische Erfolgserlebnisse / Erfahrungen
• "Zielvereinbarung"
• Mitarbeiter haben Einfluß auf / Auswahl bei eigenen Tätigkeiten
• Mitarbeiter werden gemäß besondere Fähigkeiten eingesetzt
• Mitarbeiter haben langfristige / kontinuierliche Perspektiven
• Der Projektmanager hält sich möglichst aus der technischen Arbeit raus
• Der Projektmanger managt möglichst wenig
• Aufgabe des Projektmanager ist gemeinse Visionen vorzugeben
SE7ProjManAntiPattern.fm,11Albert Zündorf
Beispiel
SE7ProjManAntiPattern.fm,12Albert Zündorf
Das "Corporate Craziness" Anti-Pattern
Problem:
• Nur Häuptlinge keine Indianer
• "Pyramide":
- einfach zu viele Layer in der Management-Hierarchie
• "Inverse Pyramide" (Kopf breiter als Körper):
- Einfach zuuu viele Manager für zuuu wenig Entwickler
- Manager bekämpfen sich untereinander
- Entscheidungswege sind unklar
- ...
• "Eindimensionale Hierarchie":
- zu flache (einstufige) und breite Hierarchie
- Manager ist überfordert
- es wird zu wenig gemanagt
- alle wurschteln vor sich hin
SE7ProjManAntiPattern.fm,13Albert Zündorf
• "Despoten"
- höherer Manager regiert am Projektmanager vorbei ins Team hinein
- Abläufe und Pläne werden über den Haufen geworfen
- die Autorität des Projektmanagers wird ausgehöhlt
• "Cabal"-Hierarchie (Clifford, Arlingtion, Buckingham, Ashley, Lauderdale 1672)
- Geheimbruderschaft über Abteilungen und Hierarchieebenen hinweg
- verborgene Entscheidungswege / -mechanismen
- Position des normalen Managements wird untergraben
- großes Intrigenspiel setzt ein
• "Evolutionäre Hierarchie"
- die Hierarchie wird ständig umgebaut
- keine Kontinuität
- Autoritäten werden untergraben
- Problem werden ausgesessen
- Visionen Perspektiven können nicht entwickelt werden
- Entscheidungswege sind ständig unklar
SE7ProjManAntiPattern.fm,14Albert Zündorf
Gründe:
• schlechte "Menschenführung"
• schlechte Planung und hektische Änderungen => ständiger wechsel der Aufgabeneinteilung
• "Aufgabenverteilung" in der Gruppe ist noch unklar, das Team / der Entwickler muss
- sich formen
- sich Kompetenzen erkämpfen
- zu klarer Aufgabenverteilung finden
• Rollenverteilung zwischen Projektmanager und Entwicklern ist noch unklar
• Projektmanager hat lieblings "Superprogrammierer"
SE7ProjManAntiPattern.fm,15Albert Zündorf
Auswege:
• Mitarbeiter sind "Human Resources" (wertvolles Kapital)
• Entwickler "Empowerment"
Mitarbeiter dürfen in ihrem Aufgabenbereich weitgehend selbständig entscheiden
• Mitarbeiter werden in Planungen einbezogen
• Mitarbeiterweiterbildung
• Gruppendynamische Erfolgserlebnisse / Erfahrungen
• "Zielvereinbarung"
• Mitarbeiter haben Einfluß auf / Auswahl bei eigenen Tätigkeiten
• Mitarbeiter werden gemäß besonderer Fähigkeiten eingesetzt
• Mitarbeiter haben langfristige / kontinuierliche Perspektiven
• Der Projektmanager hält sich möglichst aus der technischen Arbeit raus
• Der Projektmanger managt möglichst wenig
• Aufgabe des Projektmanager ist gemeinsame Visionen vorzugeben
SE7ProjManAntiPattern.fm,16Albert Zündorf
Zusammenfassung und Ausblick:
• Programmiermethodik: UML
• Software Engineering I: Projektmanagement
• Design Pattern: Design Tricks, Vererbung
• Graphentechnik: formale Grundlagen
SE7ProjManAntiPattern.fm,17Albert Zündorf
• Reverse Engineering:
- Which line of code in which file creates this (error) message?
- Who is calling this method?
- Whow is reading / writing this attribute or variable?
- Which parts of my code deals with computing this result?
- Who has programmed this bug when?
- Which parts of my system implement the functionality attached to this Button at my
GUI?
- Which parts of my program are affected by a change of the current operating system or
GUI library?
- Which parts (classes) of my program colaborate very closely?
- Which parts of the program needs to be extracted in order to provide a certain set of
functionality as a library to multiple other projects?
- Is my program well structured?
- Do I have a maintenance problem?
- etc.
-
SE7ProjManAntiPattern.fm,18Albert Zündorf
• Typical reverse engineering techniques are:
-
- pattern based search (grep)
- data flow and control flow analysis
- slicing
- clustering
- runtime trace analysis
- etc.
-
SE7ProjManAntiPattern.fm,19Sie können auch lesen
