Timeboxing - Timeboxing

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и свод знаний
Глоссарии
Контуры

В Тайм-менеджмент, таймбоксинг выделяет фиксированный период времени, называемый ящик времени, в рамках которого происходит запланированная деятельность. Его используют несколько управление проектом подходы и для личного тайм-менеджмента.

В управлении проектами

Timeboxing используется как планирование проекта техника. График разделен на несколько отдельных периодов времени (временных рамок), каждая часть имеет свои собственные результаты, срок и бюджет.[нужна цитата ] Иногда упоминается как расписание как независимая переменная (SAIV).[1]

Как альтернатива фиксации прицела

В управление проектом, обычно считается три ограничения времени (иногда график ), стоимость (иногда бюджет ), и объем;[2][3][4][5][6] с качественный часто добавляется как четвертое ограничение (представленное в виде середины треугольника),[7][8][9] Предполагается, что изменение одного ограничения повлияет на другие.[5]

Без тайм-бокса проекты обычно работают в фиксированном объеме,[10] в этом случае, когда становится ясно, что некоторые результаты не могут быть выполнены в запланированные сроки, необходимо либо продлить крайний срок (чтобы дать больше времени для завершения фиксированного объема), либо привлечь больше людей (для выполнения фиксированного объема в том же время). Часто случаются и то, и другое, что приводит к задержке доставки, увеличению затрат и часто к снижению качества (согласно Мифический человеко-месяц принцип).

При использовании тайм-бокса крайний срок фиксирован, а это означает, что объем придется сократить. Поскольку это означает, что организации должны в первую очередь сосредоточиться на завершении наиболее важных результатов, временные рамки часто идут рука об руку со схемой приоритезации результатов (например, с Метод MoSCoW ).[11]

Управлять риском

Таймбоксы используются как форма управление рисками, чтобы явно идентифицировать неопределенные отношения задача / время, т. е. работу, которая может легко выйти за пределы установленного срока. Временные ограничения часто являются основной движущей силой при планировании, и их нельзя изменять без учета критических путей проекта или подпроекта. То есть обычно важно уложиться в сроки. Факторы риска пропущенных сроков могут включать осложнения на начальном этапе проекта, ошибки планирования в рамках проекта, проблемы, связанные с командой, или неправильное выполнение плана. Проблемы, связанные с разведкой, могут включать изменения в миссии проекта или поддержку / поддержку со стороны руководства. Распространенной ошибкой планирования является неадекватная разбивка задач, что может привести к недооценке времени, необходимого для выполнения работы. Проблемы, связанные с командой, могут включать проблемы с межгрупповой коммуникацией; отсутствие опыта или необходимая кросс-функциональность; отсутствие приверженности / стремления / мотивации (т.е. плохое командообразование и управление).

Чтобы уложиться в срок, обычно оцениваются следующие действия против тройных ограничений:

  • Уменьшение объема: требования к падению с меньшим воздействием (те, которые не будут напрямую пропущены пользователем)
  • Время здесь фиксированное ограничение
  • Увеличение стоимости: например, добавление сверхурочных или ресурсов

Принятие в разработке программного обеспечения

Многие успешные разработка программного обеспечения в проектах используется таймбоксинг, особенно в небольших.[12] Использование тайм-бокса более чем в три раза увеличило продуктивность разработчиков на DuPont в 80-х.[13] В некоторых случаях заявки были полностью доставлены в предполагаемое время для завершения всего лишь Технические характеристики.[13] Тем не мение, Стив МакКоннелл утверждает, что не каждый товар подходит[13] и что временные рамки следует использовать только после того, как клиент соглашается сократить функции, а не качество.[13] Мало свидетельств того, что этот самый большой класс проектов пользуется успехом.[12]

Таймбокс был принят некоторыми известными методологии разработки программного обеспечения:

Гибкая разработка программного обеспечения выступает за переход от план управляемый к ориентированный на ценность разработка. Качество и время фиксированы, но возможна гибкость в объеме. Предоставление наиболее важных функций в первую очередь ведет к более раннему прибыль на инвестиции чем модель водопада.[6]

Отсутствие подробных спецификаций обычно является результатом нехватки времени или незнания желаемого конечного результата (решения). Во многих типах проектов, особенно в разработке программного обеспечения, анализ и определение все требований и технических условий до начала этапа реализации невозможно. Timeboxing может быть благоприятным типом заключения контрактов для проектов, в которых установлен крайний срок. то наиболее важный аспект, и когда не все требования полностью указаны заранее. Это также позволяет отразить новые отзывы или идеи, обнаруженные в ходе проекта, в конечном результате.[11]

В личном тайм-менеджменте

Основная статья: Блокировка времени

Timeboxing может использоваться для личных задач, и в этом случае он использует сокращенную шкалу времени (например, тридцать минут) и результатов (например, домашняя работа вместо результатов проекта) и часто называется блокировка времени.

Персональный таймбоксинг также действует как ухищрение чтобы помочь обуздать стремление к перфекционизму (устанавливая твердое время и не уделяя чрезмерного внимания задаче), что также может повысить творческий потенциал и сосредоточенность (создавая ощущение срочности или повышенного давления).[20]

Связь с другими методами

Таймбоксинг действует как строительный блок в других методах управления личным временем:

  • В Техника Помидора основан на 25-минутных временных окнах сосредоточенной концентрации, разделенных перерывами, позволяющими уму восстановиться.[21]
  • Энди Хант дает таймбоксинг как свою букву "Т" УМНАЯ.[22]

Рекомендации

  1. ^ Boehm, Barry W .; Бем, Барри; Тернер, Ричард (2004). Уравновешивание ловкости и дисциплины: руководство для озадаченных. Эддисон-Уэсли Профессионал. ISBN  9780321186126.
  2. ^ Каковы тройные ограничения в управлении проектами В архиве 2006-08-20 в Archive.today, статья Рода Хатчингса о Управление проектами Австралия В архиве 2009-02-16 в Wayback Machine (22 октября 2008 г.)
  3. ^ Чатфилд, Карл. «Краткий курс управления проектами». Microsoft.
  4. ^ Добсон, Майкл (2004). Тройные ограничения в управлении проектами. Вена, Вирджиния: концепции управления. ISBN  1-56726-152-3.
  5. ^ а б Канабар, Виджай (2008). Основы MBA: управление проектами. Нью-Йорк: паб «Каплан». п. 51. ISBN  978-1-4277-9744-5.
  6. ^ а б Леффингуэлл, Дин (2011). Требования к гибкому программному обеспечению: методы бережливого производства требований для команд, программ и предприятия. Река Аппер Сэдл, Нью-Джерси: Аддисон-Уэсли. С. 17–19. ISBN  978-0-321-63584-6.
  7. ^ Снедакер, Сьюзен; Нельс Хёниг (2005). Как обмануть в управлении ИТ-проектами. Syngress. ISBN  1-59749-037-7.
  8. ^ Бек, Кент (2000). Объяснение экстремального программирования: примите изменения. Ридинг, Массачусетс: Эддисон-Уэсли. стр.15 –19. ISBN  0-201-61641-6.
  9. ^ Дангело, Марк (2005). Инновационная значимость: перестройка организации для получения прибыли: это не битва за «береговые линии» - это борьба за цель. Нью-Йорк: iUniverse. п. 53. ISBN  978-0-595-67081-9.
  10. ^ Годин, Сет. Получение реального: более умный, быстрый и простой способ создания успешного веб-приложения. 37сигналов.
  11. ^ а б c Дженнифер, Стэплтон (1997). DSDM, метод разработки динамических систем: метод на практике. Харлоу, Англия: Эддисон-Уэсли. ISBN  0201178893. OCLC  36755892.
  12. ^ а б По всем типам проектов таймбокс занял 23-е место и получил оценку «Очень хорошая практика»; для маленьких (1000 функциональная точка ) проекты заняли 7 место и получили оценку «Лучшая практика» по результатам опроса в Джонс, Каперс (2010). Уроки программной инженерии из успешных проектов в ведущих компаниях. Нью-Йорк: Макгроу-Хилл. ISBN  978-0-07-162162-5.
  13. ^ а б c d е МакКоннелл, Стив (1996). Rapid Development: укрощение дикого расписания программного обеспечения. Редмонд, Вашингтон: Microsoft Press. стр.575 –583. ISBN  1-55615-900-5.
  14. ^ Поппендик, Мэри (2010). Ведущая экономичная разработка программного обеспечения: главное не в результатах. Река Аппер Сэдл, Нью-Джерси: Аддисон-Уэсли. С. 137–140. ISBN  978-0-321-62070-5.
  15. ^ Коплиен, Джеймс (2010). Бережливая архитектура для гибкой разработки программного обеспечения. Чичестер Хобокен, штат Нью-Джерси: Wiley. п. 25. ISBN  978-0-470-68420-7.
  16. ^ Кон, Майк (2010). Успех с Agile: разработка программного обеспечения с использованием Scrum. Река Аппер Сэдл, Нью-Джерси: Аддисон-Уэсли. стр.257 –284. ISBN  978-0-321-57936-2.
  17. ^ а б Швабер, Кен (2009). Гибкое управление проектами с помощью Scrum. Нью-Йорк: O'Reilly Media, Inc. ISBN  978-0-7356-3790-0.
  18. ^ Леффингуэлл, Дин (2011). Гибкие требования к программному обеспечению: методы бережливого производства требований для команд, программ и предприятия. Река Аппер Сэдл, Нью-Джерси: Аддисон-Уэсли. п. 15. ISBN  978-0-321-63584-6.
  19. ^ Бек, Кент (2000). Объяснение экстремального программирования: примите изменения. Ридинг, Массачусетс: Эддисон-Уэсли. стр.85 –96. ISBN  0-201-61641-6.
  20. ^ Паш, Адам (2011). Lifehacker руководство по работе умнее, быстрее и лучше. Индианаполис, штат Индиана: Wiley. Взломать 29. ISBN  978-1-118-13345-3.
  21. ^ Нётеберг, Стаффан (2009). Иллюстрированная техника помидора. Роли, Северная Каролина: Прагматическая книжная полка. ISBN  978-1-934356-50-0.
  22. ^ Хант, Эндрю (2008). Прагматическое мышление и обучение: рефакторинг программного обеспечения. Роли: Прагматичный. ISBN  978-1-934356-05-0.