Das Blog muss schneller werden! Zum Jahreswechsel bin ich zum PowerPlus-Paket von Strato gewechselt, habe aber teilweise 1-2 Minuten Antwortzeit oder gleich 500er-Serverfehler. D.h. die Performance im Shared Hosting-Bereich entspricht nicht dem angestrebten Qualitätsniveau. Normal vermeldet Google 4-6 Sekunden Ladezeit, ein Bruchteil einer Sekunde wäre akzeptabel.
Ausschreibung: High-Performance WordPress Ops
24.05.2011 
Kommentare deaktiviert | 
Best-of, News | Tagged: Blogs, Project management, Projektmanagement | 
Permalink 
Posted by Andreas Heilwagen
Scrum Pattern: Pigs Estimate
23.05.2011
| Context | Product Backlog Items need to be estimated realistically. |
| Problem | How do I get reliable estimates? Often, estimates are produced by people, who do not know the work to be done in depth or forget important aspects like testing. |
| Forces | too little/too much overhead too little/too much detail planning |
| Solution | Let the people estimate who do the actual work. The people, who do the work usually know best, how much effort it requires. However, the same people usually calculate a buffer, sometimes even without knowing it. So, estimates need to be challenged. This should be done by asking for a team estimate, e.g. in a Product Backlog Grooming Meeting or in a Sprint Planning Meeting. In Scrum, the estimate is done by Pigs, not by Chickens. |
| Resulting Context | The Product Backlog Items are estimated. |
1 Comment | Scrum | Tagged: Project management, Projektmanagement, Scrum | Permalink Posted by Andreas Heilwagen
Lust auf Projektmanagement für De-Mail bei 1&1?
19.05.2011Derzeit bin ich als Interim Head of De-Mail u.a. für die Softwareentwicklung dieses Projekts bei 1&1 verantwortlich. Für De-Mail und das neue User-Interface für web.de Mail sind wir auf der Suche nach senioren Projektmanagern, die Lust haben
- das De-Mail-Projekt und weitere Vorhaben zu leiten,
- die Projektmanagement-Methodik weiterzuentwickeln,
- hohe Affinität zu agilen Vorgehensweisen wie Scrum haben und
- über eine Projektmanagement-Zertifizierung wie den PMP® verfügen.
Interessiert? Melden Sie sich bei mir per Mail.
1&1 und ich freuen uns schon auf die Rückmeldungen. Wir sehen uns hoffentlich bald ,-) Kommentare deaktiviert | Best-of, News, Praxis, Scrum | Tagged: Project management, Projektmanagement | Permalink Posted by Andreas Heilwagen
Scrum Pattern: Stop Sponsoring
18.05.2011
| Context | The Product Backlog is full and project sponsoring is not limited. |
| Problem | When do we stop realizing requirements? On average, 60% of all features of a software product, are not used. Scrum projects are usually limited by the size of the Product Backlog or limited sponsoring regarding budget and time. As the most important and/or highest value requirements are realized first, continuing the project leads to less value while keeping the costs for realization roughly the same. |
| Forces | too little/too many features |
| Solution | Define a threshold of value vs. costs and stop building after crossing the line. There are always many good ideas regarding additional features, just stop building them when the value does not justify the effort, time and costs. |
| Resulting Context | Only the features with sufficient value get realized. |
Kommentare deaktiviert | Scrum | Tagged: Project management, Projektmanagement, Scrum | Permalink Posted by Andreas Heilwagen
Mapping des PMBOK® Guide v4 auf agile Prozesse
17.05.2011
Während der Recherche auf dem Blog Leading Answers von Mike Griffith bin ich auf sein Mapping von Prozesse des PMBOK® Guide in die agile Welt gestoßen. Start ist eine anklickbare “Landkarte” der Prozesse (hier die Tabelle anklicken), die zu weiteren Details führt. Falls die Landkarte in Mike’s Blog nicht vollständig angezeigt wird, muss man das Browserfenster verbreitern:
Viel Spaß! 1 Comment | Best-of, News, PMI, Scrum, Standards | Tagged: PMI, Project management, Projektmanagement, Scrum, Standards | Permalink Posted by Andreas Heilwagen
Scrum Pattern: Granularity Gradient
16.05.2011
| Context | The Product Owner has created Product Backlog Items for the a release. |
| Problem | When do which Product Backlog Items need to be broken down? Decomposing all Product Backlog Items for estimation and realization in a Sprint for a complete release creates wasted effort as requirements change and new requirements arise. Furthermore, estimations are not precise if the Product Backlog Items are realized far in the future. |
| Forces | too little/too much effort wasted too little/too much detail planning |
| Solution | Decompose Product Backlog Items depending on their realization date. Break down and estimate Product Backlog Items which will be realized in the next few Sprints and use Themes and Epics for requirements, which are far away. Themes are medium-sized, but too large to be implemented in a single Sprint, Epics can even span multiple Releases. Although estimates of Themes and Epics are not as precise as estimates of small Product Backlog Items, the effort of breaking them down immediately is wasted in many cases. Furthermore, too many Product Backlog Items clutter the Backlog. |
| Resulting Context | The Product Backlog Items have been broken down efficiently. |
Kommentare deaktiviert | Scrum | Tagged: Project management, Projektmanagement, Scrum | Permalink Posted by Andreas Heilwagen
