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