WikiDer > Timeboxing

Timeboxing

Zeitboxen begrenzt im Voraus die Zeit, die man für eine bestimmte Aktivität aufwenden möchte und darf. Dies soll verhindern, dass etwas ausläuft.

Benutzen

Es ist weit verbreitet, aber es gibt (noch) kein gutes niederländisches Wort dafür.^[Quelle?] Zum Beispiel können Eltern ihren Kindern erlauben, für eine bestimmte (begrenzte) Zeit zu bleiben Fernseher schauen. Meetings haben oft eine Start- und Endzeit und damit eine Timebox. Das gleiche gilt für Kurse, Prüfungen und Ferien. Auch der Wochenende ist eine Zeitbox.

Im Projektmanagement

Verschiedene Projektmanagement mit Methoden Zeitboxen.^[1] Timeboxing wird als Methode zur Verwaltung von Projekten verwendet planen. Die Planung besteht aus mehreren verschiedenen Zeiträumen (Timeboxen) mit jeweils eigenen Produkten, Budgets und Frist.

Als Alternative zum Einfrieren der Spezifikationen

Biene Projektmanagement existiert die Teufelsdreieck außerhalb der Zeit, Kosten (manchmal Budget) und Umfang (manchmal Leistung).^[2]^[3]^[4]^[5]^[6] Qualität kommt oft hinzu,^[7]^[8] manchmal ersetzt dies den Umfang.^[9] Die Änderung einer Behinderung wirkt sich wahrscheinlich auf den Rest aus.^[5]

Wenn kein Timeboxing verwendet wird, haben Projekte in der Regel festgelegt, welche Spezifikationen das Endprodukt erfüllen muss, den Umfang^[10] Dadurch kann sich das Projekt verzögern oder es werden mehr Personen involviert, um rechtzeitig fertig zu werden. Meistens macht man beides und es ist trotzdem nicht möglich, die Planung und das Budget einzuhalten, oft geht es sogar zu Lasten der gewünschten Qualität (Features).

Bei Timeboxing wird der Liefertermin fixiert, dies geht zu Lasten der Qualität. Dadurch stehen die wichtigsten Anforderungen im Fokus. Wichtig ist dann, dass die Prioritäten von den Nutzern/Kunden festgelegt werden, zum Beispiel mit dem MoSCoW-Methode, und nicht von den Softwareentwicklern.

Risikomanagement

Timeboxen werden auch als Form von Risikomanagement, um bestimmte Aufgaben, die leicht überlaufen können, eindeutig zu identifizieren. Die Zeit ist ein wichtiger Faktor in vielen Zeitplänen und kann nicht einfach geändert werden, ohne die Konsequenzen zu berücksichtigen, die dies für die kritischer Pfad. Normalerweise ist es wichtig, Fristen zu bekommen. Terminüberschreitungen können später im Projekt Konsequenzen haben, sie können zu Fehlern in der (zuvor ausgegebenen) Planung führen. Auch Teammitglieder können damit Probleme haben. Sogar der ganze Plan kann schief gehen. Es kann dazu führen, dass Ziele nicht erreicht werden und das Management lästig wird. Ein bekannter Fehler ist, dass Aufgaben nicht detailliert genug sind, was schnell zu einer Unterschätzung der Zeit führt. Timeboxing macht schnell klar, dass es nicht gut läuft. Es kann zum Beispiel auch das Team sein. Dinge, die innerhalb eines Teams schief gehen können, sind die Kommunikation im Team, mangelnde Erfahrung und zu wenig Generalisten/weit einsetzbare Leute, die Kollegen helfen können und wollen. Möglicherweise fehlt auch die Motivation.

Um Fristen einzuhalten, kommen folgende Maßnahmen in Betracht:

Reduzierung der Anzahl der gelieferten Dinge, weniger wichtige Dinge werden weggelassen, Dinge, die der Benutzer/Kunde nicht sofort vermisst.
Die Zeit ist festgelegt, sie kann sich nicht ändern
Kostenerhöhung: zum Beispiel durch im Laufe der Zeit oder zusätzliches Personal einzusetzen.

Anwendung in der Softwareentwicklung

Viele erfolgreiche Softwareprojekte verwenden Timeboxing, insbesondere die kleineren.^[11] Durch die Anwendung von Timeboxing konnte die Produktivität um den Faktor 3 bei . gesteigert werden DuPont in den 80er Jahren.^[12] Manchmal werden Anwendungen vollständig innerhalb der für die Bereitstellung einiger Funktionen vorgesehenen Zeit bereitgestellt, nur durch Verwendung von Timeboxing.^[12] Allerdings stellt Steve McConnell fest, dass dafür nicht jedes Produkt gleichermaßen geeignet ist^[12] und dass Timeboxing nur mit Zustimmung des Kunden verwendet werden kann, der es wagen muss, Schnickschnack und nicht Qualität zu schneiden.^[12] es gibt kaum Anhaltspunkte dafür, dass die Leute auch bei größeren Projekten Timeboxen wollen.^[11]

Timeboxing ist Teil einiger wichtiger Softwareentwicklungsmethoden:

Dynamische Systementwicklungsmethode (DSDM)
In der schlanken Softwareentwicklung Pull-Planung mit Kanban hat auch Timeboxing mit sehr kleinen Zeiträumen. Wenn ein großes und komplexes System entwickelt wird, das langfristige Planung und auch Timeboxing verwendet.^[13]
Schnelle Anwendungsentwicklung (RAD). Timeboxing ist laut Steve McConnell eine "Best Practice" von RAD und eine normale Timebox beträgt hier 60 bis 120 Tage.^[12]
Scrum verwendet auch viel Timeboxing und iterative Entwicklung.^[14] Scrum funktioniert nur in Sprints.^[15] Die typische Dauer eines Sprints beträgt 30 Tage.^[16]^[17] Sprint-Planung, Sprint-Retrospektive und Sprint-Reviews befinden sich alle in einer Timebox.^[16]
Extremes Programmieren zeichnet sich durch Kommunikation, Einfachheit, Feedback und Mut.^[18] Die Planung und Entwicklung erfolgt in Timeboxen, Iterationen von 1, 2 oder 3 Wochen. Die Nutzer bestimmen die Priorität der Anforderungen in Form von benutzergeschichten kurz vor der Iteration.^[19]

Agile Software Entwicklung sagt, dass man sich nicht nach einem Plan lenken sollte, sondern nach dem Wert, der produziert wird. Die Qualität und der Zeitpunkt sind festgelegt, es ist jedoch möglich, die gelieferte Menge zu variieren. Das Wichtigste am Anfang zu liefern führt zu einem besseren Kapitalrendite Dann ist die Wasserfallmethode.^[6]

Ein Mangel an detaillierten Spezifikationen ist typischerweise das Ergebnis von Zeitmangel oder mangelnder Klarheit darüber, was genau gewünscht wird. In vielen Projekten und insbesondere in Softwareprojekten ist es fast unmöglich, alle Anforderungen und Spezifikationen vorab auf den Tisch zu bekommen.

Im persönlichen Zeitmanagement

Menschen nutzen Timeboxing auch in ihrem Privatleben. Hier werden kleinere Zeiteinheiten verwendet, beispielsweise eine halbe Stunde statt einer Woche. Zum Beispiel für Haushaltsaufgaben wie Spaziergänge mit dem Hund und Staubsaugen. Es wird gesagt, dass der Einsatz von Timeboxing im persönlichen Leben perfektionistisches Verhalten einschränken kann. Adam Pash schreibt, dass Timeboxing Aufschub hilft zu verhindern. Viele Leute sagen, dass sie unter Zeitdruck eine gute Leistung erbringen und dass dies für sie ausgezeichnet ist Kreativität und Konzentration.^[20]

Andere Verwendung

Timeboxing wird häufig in Methoden des persönlichen Zeitmanagements eingesetzt.

Das Pomodoro-Technik basiert auf Timeboxen von 25 Minuten Konzentration mit kleinen Pausen, damit sich das Gedächtnis beruhigen kann.^[21]
Andy Hunt sagt, Timeboxing sei das T in SMART-Prinzip.^[22]

Siehe auch

Externe Links

Quellen, Anmerkungen und/oder Verweise

↑Poppendieck, Mary, Führende schlanke Softwareentwicklung: Ergebnisse sind nicht der Punkt. Addison-Wesley, Upper Saddle River, NJ (2010), p. 139. ISBN 978-0-321-62070-5 .
↑Was sind die dreifachen Einschränkungen im Projektmanagement?, Artikel von Rod Hutchings über Projektmanagement Australien (22.10.2008)
↑Chatfield, Carl, "Ein kurzer Kurs in Projektmanagement", Microsoft.
↑Dobson, Michael, Die dreifachen Einschränkungen im Projektmanagement. Managementkonzepte, Wien, Va (2004). ISBN 1-56726-152-3 .
↑ ^ein ^bKanabar, Vijay, MBA-Grundlagen: Projektmanagement. Kaplan Pub, New York (2008), p. 51. ISBN 978-1-4277-9744-5 .
↑ ^ein ^bLeffingwell, Dekan, Agile Softwareanforderungen: Schlanke Anforderungspraktiken für Teams, Programme und das Unternehmen. Addison-Wesley, Upper Saddle River, NJ (2011), 17–19. ISBN 978-0-321-63584-6 .
↑Snedaker, Susan; Nels Hönig, Wie man beim IT-Projektmanagement schummelt. Syngress (2005). ISBN 1-59749-037-7 .
↑Beck, Kent, Extreme Programmierung erklärt: Veränderungen annehmen. Addison-Wesley, Reading, M. A. (2000), 15–19. ISBN 0-201-61641-6 .
↑Dangelo, Markus, Innovationsrelevanz: Neuausrichtung der Organisation auf Profit: Es ist kein Kampf um die "Küstenlinien" - es ist ein Kampf um den Sinn. iUniverse, New York (2005), p. 53. ISBN 978-0-595-67081-9 .
↑Göttin, Seth, Real werden: Der intelligentere, schnellere und einfachere Weg, eine erfolgreiche Webanwendung zu erstellen. 37Signale.
↑ ^ein ^bFür alle Projektarten wurde Timeboxing auf Platz 23 und mit „Sehr gute Praxis“ bewertet; für kleine (1000 Funktionspunkte) Projekte auf Platz 7 und als „Best Practice“ in einer Umfrage bewertet in Jones, Kapern, Best Practices für Software Engineering aus erfolgreichen Projekten in den Top-Unternehmen. McGraw-Hill, New York (2010). ISBN 978-0-07-162162-5 .
↑ ^ein ^b ^c ^d ^eMcConnell, Steve, Schnelle Entwicklung: Zähmung wilder Software-Zeitpläne. Microsoft Press, Redmond, Wash (1996), 575–583. ISBN 1-55615-900-5 .
↑Poppendieck, Mary, Führende schlanke Softwareentwicklung: Ergebnisse sind nicht der Punkt. Addison-Wesley, Upper Saddle River, NJ (2010), 137–140. ISBN 978-0-321-62070-5 .
↑Coplien, James, Schlanke Architektur für agile Softwareentwicklung. Wiley, Chichester Hoboken, N.J. (2010), p. 25. ISBN 978-0-470-68420-7 .
↑Cohn, Mike, Erfolgreich mit Agile: Softwareentwicklung mit Scrum. Addison-Wesley, Upper Saddle River, NJ (2010), 257–284. ISBN 978-0-321-57936-2 .
↑ ^ein ^bSchwaber, Keno, Agiles Projektmanagement mit Scrum. O'Reilly Media, Inc, New York (2009). ISBN 978-0-7356-3790-0 .
↑Leffingwell, Dekan, Agile Softwareanforderungen: Schlanke Anforderungspraktiken für Teams, Programme und das Unternehmen. Addison-Wesley, Upper Saddle River, NJ (2011), S. fünfzehn. ISBN 978-0-321-63584-6 .
↑Beck, Kent, Extreme Programmierung erklärt: Veränderungen annehmen. Addison-Wesley, Reading, M. A. (2000), 29–35. ISBN 0-201-61641-6 .
↑Beck, Kent, Extreme Programmierung erklärt: Veränderungen annehmen. Addison-Wesley, Reading, M. A. (2000), 85–96. ISBN 0-201-61641-6 .
↑Pasch, Adam, Lifehacker der Leitfaden für intelligenteres, schnelleres und besseres Arbeiten. Wiley, Indianapolis, Indien (2011). ISBN 978-1-118-13345-3 .
↑Noteberg, Staffan, Pomodoro-Technik illustriert. Pragmatisches Bücherregal, Raleigh, N.C. ISBN 978-1-934356-50-0 .
↑Jagd, Andrew, Pragmatisches Denken und Lernen: Refactoring Ihrer Wetware. Pragmatisch, Raleigh (2008). ISBN 978-1-934356-05-0 .

[1] Poppendieck, Mary, Führende schlanke Softwareentwicklung: Ergebnisse sind nicht der Punkt. Addison-Wesley, Upper Saddle River, NJ (2010), p. 139. ISBN 978-0-321-62070-5 .

[2] Was sind die dreifachen Einschränkungen im Projektmanagement?, Artikel von Rod Hutchings über Projektmanagement Australien (22.10.2008)

[Chat-3] Chatfield, Carl, "Ein kurzer Kurs in Projektmanagement", Microsoft.

[4] Dobson, Michael, Die dreifachen Einschränkungen im Projektmanagement. Managementkonzepte, Wien, Va (2004). ISBN 1-56726-152-3 .

[Kanabar-5] Kanabar, Vijay, MBA-Grundlagen: Projektmanagement. Kaplan Pub, New York (2008), p. 51. ISBN 978-1-4277-9744-5 .

[Leffingwell-6] Leffingwell, Dekan, Agile Softwareanforderungen: Schlanke Anforderungspraktiken für Teams, Programme und das Unternehmen. Addison-Wesley, Upper Saddle River, NJ (2011), 17–19. ISBN 978-0-321-63584-6 .

[7] Snedaker, Susan; Nels Hönig, Wie man beim IT-Projektmanagement schummelt. Syngress (2005). ISBN 1-59749-037-7 .

[8] Beck, Kent, Extreme Programmierung erklärt: Veränderungen annehmen. Addison-Wesley, Reading, M. A. (2000), 15–19. ISBN 0-201-61641-6 .

[Dangelo-9] Dangelo, Markus, Innovationsrelevanz: Neuausrichtung der Organisation auf Profit: Es ist kein Kampf um die "Küstenlinien" - es ist ein Kampf um den Sinn. iUniverse, New York (2005), p. 53. ISBN 978-0-595-67081-9 .

[10] Göttin, Seth, Real werden: Der intelligentere, schnellere und einfachere Weg, eine erfolgreiche Webanwendung zu erstellen. 37Signale.

[Capers-11] Für alle Projektarten wurde Timeboxing auf Platz 23 und mit „Sehr gute Praxis“ bewertet; für kleine (1000 Funktionspunkte) Projekte auf Platz 7 und als „Best Practice“ in einer Umfrage bewertet in Jones, Kapern, Best Practices für Software Engineering aus erfolgreichen Projekten in den Top-Unternehmen. McGraw-Hill, New York (2010). ISBN 978-0-07-162162-5 .

[McConnell-12] ↑ ^ein ^b ^c ^d ^eMcConnell, Steve, Schnelle Entwicklung: Zähmung wilder Software-Zeitpläne. Microsoft Press, Redmond, Wash (1996), 575–583. ISBN 1-55615-900-5 .

[13] Poppendieck, Mary, Führende schlanke Softwareentwicklung: Ergebnisse sind nicht der Punkt. Addison-Wesley, Upper Saddle River, NJ (2010), 137–140. ISBN 978-0-321-62070-5 .

[14] Coplien, James, Schlanke Architektur für agile Softwareentwicklung. Wiley, Chichester Hoboken, N.J. (2010), p. 25. ISBN 978-0-470-68420-7 .

[15] Cohn, Mike, Erfolgreich mit Agile: Softwareentwicklung mit Scrum. Addison-Wesley, Upper Saddle River, NJ (2010), 257–284. ISBN 978-0-321-57936-2 .

[Schwaber-16] Schwaber, Keno, Agiles Projektmanagement mit Scrum. O'Reilly Media, Inc, New York (2009). ISBN 978-0-7356-3790-0 .

[17] Leffingwell, Dekan, Agile Softwareanforderungen: Schlanke Anforderungspraktiken für Teams, Programme und das Unternehmen. Addison-Wesley, Upper Saddle River, NJ (2011), S. fünfzehn. ISBN 978-0-321-63584-6 .

[18] Beck, Kent, Extreme Programmierung erklärt: Veränderungen annehmen. Addison-Wesley, Reading, M. A. (2000), 29–35. ISBN 0-201-61641-6 .

[19] Beck, Kent, Extreme Programmierung erklärt: Veränderungen annehmen. Addison-Wesley, Reading, M. A. (2000), 85–96. ISBN 0-201-61641-6 .

[20] Pasch, Adam, Lifehacker der Leitfaden für intelligenteres, schnelleres und besseres Arbeiten. Wiley, Indianapolis, Indien (2011). ISBN 978-1-118-13345-3 .

[21] Noteberg, Staffan, Pomodoro-Technik illustriert. Pragmatisches Bücherregal, Raleigh, N.C. ISBN 978-1-934356-50-0 .

[22] Jagd, Andrew, Pragmatisches Denken und Lernen: Refactoring Ihrer Wetware. Pragmatisch, Raleigh (2008). ISBN 978-1-934356-05-0 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

Navigation