Управление проектами - статьи

         

Временные рамки


И, наконец, я должен упомянуть определение временных рамок ("timeboxing"), замечательно эффективную стратегию, о которой я пока не говорил, потому что она, как правило, "обманом" не считается.

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

Однако есть и разница: в первом случае, требования "замораживаются" до истечения временного промежутка. Соответственно, в этих условиях команда может спокойно заниматься разработкой функциональности. Такой смысл термину "временные рамки" принято придавать в методологии Scrum (Schwaber, 2001). В другом случае, требования могут свободно меняться когда угодно, подразумевая, разумеется, что те, кто вносят изменения, имеют на это весьма веские причины. Именно так понимают этот термин приверженцы "экстремального программирования".

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

Одно из важнейших правил увеличения эффективности проекта, которое касается механизма "временных рамок", гласит:

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

На это существует ровно три причины:

  • Поставка продукта, какой бы урезанной ни была его функциональность, дает программистам ощущение настоящей победы, что поддерживает моральную обстановку в команде;
  • Постоянные поставки продукта в запланированные сроки дает всем четкое представление о темпах работы команды;
  • Чтобы суметь вовремя поставить продукт заказчику, надо не агонизировать в поисках идеального решения проблемы, а остановиться на подходящем.
  • Первое даст команде ощущение уверенности, отчего со временем люди станут работать еще более эффективно. Второе поможет хорошо управлять проектом и планировать работу. И, наконец, последнее станет настоящим двигателем процесса разработки. Я сам с удивлением слушаю рассказы руководителей проектов о том, как ускорился процесс разработки лишь потому, что люди поняли необходимость принятия временно удовлетворительных решений.



    Содержание раздела