Таймбоксинг

Метод управления временем

В agile - принципах тайм-боксинг выделяет максимальную единицу времени для деятельности, называемую тайм-боксом , в рамках которой происходит запланированная деятельность. Он используется в подходах к управлению проектами на основе agile-принципов и для управления личным временем.

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

Timeboxing используется как метод планирования проекта . Расписание делится на несколько отдельных временных периодов (timeboxes), при этом каждая часть имеет свои собственные результаты, крайний срок и бюджет. ^{[ требуется ссылка ]} Иногда называется расписанием как независимой переменной (SAIV). ^[1] «Timeboxing лучше всего работает в многоэтапных проектах или задачах, которые занимают мало времени и которые можно втиснуть в один временной интервал. Его также стоит применять в случае обязанностей, которые имеют предсказуемые временные рамки завершения». ^[2]

В качестве альтернативы фиксации области действия

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

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

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

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

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

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

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

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

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

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

Метод разработки динамических систем (DSDM). ^[12]
В бережливой разработке программного обеспечения вытягивающее планирование с Kanban обеспечивает краткосрочное управление временем. При разработке большой и сложной системы, где требуется долгосрочное планирование , таймбоксинг накладывается выше. ^[15]
Процесс разработки программного обеспечения для быстрой разработки приложений (RAD) включает итеративную разработку и прототипирование программного обеспечения . По словам Стива Макконнелла , таймбоксинг является «лучшей практикой» для RAD, а типичная длина таймбокса должна составлять 60–120 дней. ^[14]
Scrum находился под влиянием идей ограничения по времени и итеративной разработки . ^[16] Регулярные ограниченные по времени единицы, известные как спринты, образуют базовую единицу разработки. ^[17] Типичная продолжительность спринта составляет менее 30 дней. ^[18]^[19] Планирование спринта, ретроспектива спринта и обзорные встречи спринта ограничены по времени. ^[18]
В методологиях экстремального программирования планирование разработки ограничено по времени итерациями, обычно длиной в 1, 2 или 3 недели. Бизнес переоценивает ожидающие пользовательские истории перед каждой итерацией. ^[20]

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

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

В управлении личным временем

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

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

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

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

Метод «Помодоро» основан на 25-минутных интервалах сосредоточения, разделенных перерывами, позволяющими разуму восстановиться. ^[22]
Энди Хант называет таймбоксинг своей «Т» в SMART . ^[23]

Смотрите также

Дизайн-спринт — ограниченный по времени пятиэтапный процесс, используемый в дизайн-мышлении.

Ссылки

^ Boehm, Barry W.; Boehm, Barry; Turner, Richard (2004). Баланс гибкости и дисциплины: руководство для растерянных. Addison-Wesley Professional. ISBN 9780321186126.
^ "Timeboxing – почему вы должны его использовать?". Firmbee . 2022-01-17 . Получено 2022-01-25 .
^ Что такое тройные ограничения в управлении проектами. Архивировано 20 августа 2006 г. на archive.today , статья Рода Хатчингса об управлении проектами в Австралии. Архивировано 16 февраля 2009 г. на Wayback Machine (22 октября 2008 г.)
^ Чатфилд, Карл. «Краткий курс по управлению проектами». Microsoft.
^ Добсон, Майкл (2004). Тройные ограничения в управлении проектами . Вена, Вирджиния: Концепции управления. ISBN 1-56726-152-3.
^ Аб Канабар, Виджай (2008). Основы MBA: Управление проектами . Нью-Йорк: Паб Каплан. п. 51. ИСБН 978-1-4277-9744-5.
^ ab Leffingwell, Dean (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Upper Saddle River, NJ: Addison-Wesley. С. 17–19. ISBN 978-0-321-63584-6.
^ Снедакер, Сьюзен; Нельс Хениг (2005). Как обмануть при управлении ИТ-проектами . Syngress. ISBN 1-59749-037-7.
^ Бек, Кент (2000). Экстремальное программирование eExplained: примите изменения . Reading, MA: Addison-Wesley. стр. 15–19. ISBN 0-201-61641-6.
^ Данжело, Марк (2005). Инновационная релевантность: перестройка организации для получения прибыли: это не битва за «береговые линии» — это борьба за цель. Нью-Йорк: iUniverse. С. 53. ISBN 978-0-595-67081-9.
^ Годин, Сет. Getting Real: более умный, быстрый и простой способ создания успешного веб-приложения . 37signals.
^ abc Jennifer., Stapleton (1997). DSDM, метод разработки динамических систем: метод на практике . Harlow, England: Addison-Wesley. ISBN 0201178893. OCLC 36755892.
^ ab Для всех типов проектов time boxing занял 23 место и получил оценку «Очень хорошая практика»; для небольших (1000 функциональных точек ) проектов занял 7 место и получил оценку «Лучшая практика» по результатам опроса в Jones, Capers (2010). Уроки передовой практики разработки программного обеспечения из успешных проектов в ведущих компаниях . Нью-Йорк: McGraw-Hill. ISBN 978-0-07-162162-5.
^ abcde Макконнелл, Стив (1996). Быстрая разработка: укрощение диких графиков программного обеспечения . Редмонд, Вашингтон: Microsoft Press. С. 575–583. ISBN 1-55615-900-5.
^ Поппендик, Мэри (2010). Руководство разработкой бережливого программного обеспечения: результаты не главное . Upper Saddle River, NJ: Addison-Wesley. стр. 137–140. ISBN 978-0-321-62070-5.
^ Коплиен, Джеймс (2010). Бережливая архитектура для гибкой разработки программного обеспечения. Чичестер Хобокен, Нью-Джерси: Wiley. стр. 25. ISBN 978-0-470-68420-7.
^ Кон, Майк (2010). Успех с Agile: Разработка программного обеспечения с использованием Scrum . Upper Saddle River, NJ: Addison-Wesley. стр. 257–284. ISBN 978-0-321-57936-2.
^ ab Schwaber, Ken (2009). Agile Project Management with Scrum. Нью-Йорк: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0.
^ Леффингвелл, Дин (2011). Требования к гибкому программному обеспечению: бережливые требования к практикам для команд, программ и предприятия. Аппер Сэддл Ривер, Нью-Джерси: Addison-Wesley. стр. 15. ISBN 978-0-321-63584-6.
^ Бек, Кент (2000). Экстремальное программирование eExplained: примите изменения . Reading, MA: Addison-Wesley. стр. 85–96. ISBN 0-201-61641-6.
^ Паш, Адам (2011). Lifehacker — руководство по работе умнее, быстрее и лучше. Индианаполис, Индиана: Wiley. Hack 29. ISBN 978-1-118-13345-3.
^ Нотеберг, Стаффан (2009). Иллюстрированный метод Pomodoro . Роли, Северная Каролина: Pragmatic Bookshelf. ISBN 978-1-934356-50-0.
^ Хант, Эндрю (2008). Прагматичное мышление и обучение: рефакторинг вашего программного обеспечения. Raleigh: Pragmatic. ISBN 978-1-934356-05-0.

[1] Boehm, Barry W.; Boehm, Barry; Turner, Richard (2004). Баланс гибкости и дисциплины: руководство для растерянных. Addison-Wesley Professional. ISBN 9780321186126.

[2] "Timeboxing – почему вы должны его использовать?". Firmbee . 2022-01-17 . Получено 2022-01-25 .

[3] Что такое тройные ограничения в управлении проектами. Архивировано 20 августа 2006 г. на archive.today , статья Рода Хатчингса об управлении проектами в Австралии. Архивировано 16 февраля 2009 г. на Wayback Machine (22 октября 2008 г.)

[Chat-4] Чатфилд, Карл. «Краткий курс по управлению проектами». Microsoft.

[5] Добсон, Майкл (2004). Тройные ограничения в управлении проектами . Вена, Вирджиния: Концепции управления. ISBN 1-56726-152-3.

[Kanabar-6] Аб Канабар, Виджай (2008). Основы MBA: Управление проектами . Нью-Йорк: Паб Каплан. п. 51. ИСБН 978-1-4277-9744-5.

[Leffingwell-7] Leffingwell, Dean (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Upper Saddle River, NJ: Addison-Wesley. С. 17–19. ISBN 978-0-321-63584-6.

[8] Снедакер, Сьюзен; Нельс Хениг (2005). Как обмануть при управлении ИТ-проектами . Syngress. ISBN 1-59749-037-7.

[9] Бек, Кент (2000). Экстремальное программирование eExplained: примите изменения . Reading, MA: Addison-Wesley. стр. 15–19. ISBN 0-201-61641-6.

[Dangelo-10] Данжело, Марк (2005). Инновационная релевантность: перестройка организации для получения прибыли: это не битва за «береговые линии» — это борьба за цель. Нью-Йорк: iUniverse. С. 53. ISBN 978-0-595-67081-9.

[11] Годин, Сет. Getting Real: более умный, быстрый и простой способ создания успешного веб-приложения . 37signals.

[:0-12] Jennifer., Stapleton (1997). DSDM, метод разработки динамических систем: метод на практике . Harlow, England: Addison-Wesley. ISBN 0201178893. OCLC 36755892.

[Capers-13] Для всех типов проектов time boxing занял 23 место и получил оценку «Очень хорошая практика»; для небольших (1000 функциональных точек ) проектов занял 7 место и получил оценку «Лучшая практика» по результатам опроса в Jones, Capers (2010). Уроки передовой практики разработки программного обеспечения из успешных проектов в ведущих компаниях . Нью-Йорк: McGraw-Hill. ISBN 978-0-07-162162-5.

[McConnell-14] Макконнелл, Стив (1996). Быстрая разработка: укрощение диких графиков программного обеспечения . Редмонд, Вашингтон: Microsoft Press. С. 575–583. ISBN 1-55615-900-5.

[15] Поппендик, Мэри (2010). Руководство разработкой бережливого программного обеспечения: результаты не главное . Upper Saddle River, NJ: Addison-Wesley. стр. 137–140. ISBN 978-0-321-62070-5.

[16] Коплиен, Джеймс (2010). Бережливая архитектура для гибкой разработки программного обеспечения. Чичестер Хобокен, Нью-Джерси: Wiley. стр. 25. ISBN 978-0-470-68420-7.

[17] Кон, Майк (2010). Успех с Agile: Разработка программного обеспечения с использованием Scrum . Upper Saddle River, NJ: Addison-Wesley. стр. 257–284. ISBN 978-0-321-57936-2.

[Schwaber-18] Schwaber, Ken (2009). Agile Project Management with Scrum. Нью-Йорк: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0.

[19] Леффингвелл, Дин (2011). Требования к гибкому программному обеспечению: бережливые требования к практикам для команд, программ и предприятия. Аппер Сэддл Ривер, Нью-Джерси: Addison-Wesley. стр. 15. ISBN 978-0-321-63584-6.

[20] Бек, Кент (2000). Экстремальное программирование eExplained: примите изменения . Reading, MA: Addison-Wesley. стр. 85–96. ISBN 0-201-61641-6.

[21] Паш, Адам (2011). Lifehacker — руководство по работе умнее, быстрее и лучше. Индианаполис, Индиана: Wiley. Hack 29. ISBN 978-1-118-13345-3.

[22] Нотеберг, Стаффан (2009). Иллюстрированный метод Pomodoro . Роли, Северная Каролина: Pragmatic Bookshelf. ISBN 978-1-934356-50-0.

[23] Хант, Эндрю (2008). Прагматичное мышление и обучение: рефакторинг вашего программного обеспечения. Raleigh: Pragmatic. ISBN 978-1-934356-05-0.