Новый офис Марины в Москва-сити имеет захватывающий вид на Москву-реку, но в этот вечер она не может наслаждаться им, так как с тревогой смотрит на экран своего компьютера.
Она управляет быстрорастущим технологическим стартапом и несколько обеспокоена ощутимыми затратами на аренду офисов в престижном бизнес-центре Москвы. Но дела у компании идут хорошо. Только что она заключила новый крупный контракт на программное обеспечение, и это может закрепить ее положение на рынке.
Марина обеспокоена тем, что покупателем выдвинуты жесткие сроки поставки, и ее команда может не уложиться в них. Частичным ответом на проблемы Марины может быть использование диаграммы сгорания задач. Этот четкий и простой график сопоставляет оставшуюся работу по проекту с выделенным на ее выполнение временем.
В этой статье мы объясним, как создавать и использовать диаграммы сгорания задач, какие у них есть плюсы и минусы и как они вписываются в гибкое управление проектами Agile.
Вы можете получить более глубокое представление о гибком управлении проектами из наших статей на эту тему. Узнайте, как использовать «летучки», покер-планирование, доски канбан и пользовательские истории. Вы также можете изучить инструменты и ресурсы, которые охватывают более традиционные аспекты управления проектами в статьях раздела «Операционное управление».
Что такое диаграммы сгорания задач
Чтобы разобраться в диаграммах сгорания задач, сначала нужно понять некоторые принципы, лежащие в основе гибкого управления проектами. Как следует из названия, Agile — это гибкий способ управления проектами, предусматривающий быструю реакцию на происходящие изменения и сосредоточенный на цели.
Несмотря на неизменное существование четко определенных целей, «гибкие» команды в большей степени ориентированы на себя и не так жестко управляются руководителем проекта, по сравнению с традиционными командами разработчиков. Требования к проекту часто разрабатываются непосредственно перед началом работы над его частью; основное внимание уделяется пользовательскому тестированию и обратной связи от клиентов, а также постоянной оценке и переоценке масштаба и направленности продукта или проекта.
Команды разработчиков обычно работают «короткими очередями», или «спринтами», стандартной продолжительностью от двух до четырех недель, чтобы добиться ощутимого прогресса в своей части проекта, например, разрабатывая рабочие версии продукта или отдельные программы. Они могут использовать «пользовательские истории» для планирования работы и оценки требуемых действий и достигнутых результатов с точки зрения конечного пользователя.
Agile-команды также используют «летучки» (scrum meetings) и доски канбан. «Летучки» — это краткие встречи в режиме реального времени, которые обычно проводятся ежедневно и позволяют командам сотрудничать, выслушивать друг друга, обсуждать прогресс, достижения, препятствия и осуществлять взаимную поддержку. Доски канбан — это способ визуального отображения состояния проектов, которые должны быть выполнены во время спринта.
Диаграммы сгорания задач — это визуальный инструмент, который можно использовать вместе с «летучками» или досками канбан. Они были изобретены разработчиком программного обеспечения Кеном Швабером в 2000 году, чтобы предоставить командам доступный способ подсчета рабочих часов или «очков историй», оставшихся для выполнения проекта, в зависимости от имеющегося времени.
Они показывают «сгорание» для каждого отдельного спринта (что помогает членам команды видеть прогресс, достигнутый в ходе него) или для проекта в целом, предоставляя команде визуализацию отставания от графика работ или его опережения.
Диаграммы также могут быть использованы для отображения «сгорания» (когда прогресс идет медленнее, чем ожидалось) или дней, которые были «сожжены» (опять же, когда прогресс отличается от запланированного). Они также могут быть настроены на отображение новых вариаций проекта или задачи.
Создание и использование диаграммы сгорания задач
Ваша оценка прогресса в диаграмме сгорания задач, естественно, будет зависеть от конкретного проекта и типа команды, которой вы управляете.
Давайте посмотрим, как это может сработать, вернувшись к Марине в ее офис в Москва-сити...
Марина хочет ежедневно отслеживать прогресс, чтобы гарантировать соблюдение крайне жестких сроков выполнения ее проекта. Для этого она возглавляет Agile- команду, которая ежедневно проводит «летучки» для обсуждения задач, которые необходимо реализовать в текущем спринте.
Эти задачи могут быть выражены в виде «очков историй», которые соответствуют времени и усилиям, необходимым для их выполнения. Команда использует доску канбан для управления потоком проекта и обновляет ее после каждой «летучки», чтобы показать количество очков, полученных в этот день. (Очко предоставляется только в том случае, если проект или пользовательская история, к которой оно относится, успешно прошли проверку качества.)
Чтобы создать свою диаграмму сгорания задач «Проекта AБВ», Марина отмечает количество очков на вертикальной оси графика и количество спринтов — на горизонтальной. См. рис. 1 ниже.
Вам не обязательно использовать очки и спринты в качестве единиц измерения. Например, можно поменять“очки историй” на “количество задач” на вертикальной оси, а на горизонтальной оси — “спринты” на “количество дней для завершения задач”.
Однако нужно будет четко определить, что вы подразумеваете под «задачами», чтобы точно оценить, что было выполнено.
Диаграммы сгорания задач также обычно используются для отслеживания прогресса отдельных спринтов, при этом на вертикальной оси отображается объем выполняемой работы, а на горизонтальной — количество дней спринта.
Теперь Марина может начать строить график прогресса от своей начальной точки в 240 очков. Ее цель — завершить проект за шесть спринтов, в среднем 40 очков за спринт. Если это удастся, на графике появится простая диагональная прямая линия вниз между отметками 240 и 6, как показано на рис. 2 ниже.
В действительности, конечно, так гладко проекты практически не выполняются, и именно здесь диаграмма сгорания задач может себя проявить. На рис. 3, приведенном ниже, показан фактический прогресс команды Марины в спринте.
График показывает, что в течение первых двух спринтов все шло по плану, но количество очков историй, которые нужно было реализовать, немного увеличилось между вторым и третьим спринтами, прежде чем после третьего спринта скорость проекта вернулась в норму.
Этому могло послужить несколько причин: во время этого спринта ключевой член команды был болен, спринт оказался более трудным или объемным, чем ожидалось, или, возможно, клиент изменил масштаб проекта. Важно то, что Марина и ее команда смогут увидеть, что прогресс задерживается, и принять соответствующие меры.
Плюсы и минусы диаграмм сгорания задач
Главное преимущество диаграмм сгорания задач заключается в их простоте: они наглядно представляют, что вашей «гибкой» команде уже удалось достичь, что еще предстоит достичь, и получается ли уложиться в установленные сроки.
Они могут быстро предупредить вас о любых потенциальных проблемах или узких местах. Плато на графике дает четкое представление о том, где нужно приложить дополнительные усилия, чтобы вернуть проект в нужное русло.
Диаграммы сгорания задач также могут быть полезным мотивационным инструментом. Они показывают вашей команде предстоящий фронт работ, а также степень успеха, достигнутую при их завершении.
Но у этих графиков есть и отрицательные стороны. Например, они показывают только завершенные работы, а не задачу, находящуюся в процессе выполнения, и соответствующие ей очки, а также не показывают насколько текущая работа близка к завершению. Вы можете освещать этот момент на своих регулярных «летучках», но недостаток остается недостатком — диаграмма сгорания задач отображает только часть картины.
Диаграммы сгорания задач могут привести к завышенным ожиданиям. Если вы планируете, что ваша диаграмма сгорания задач будет выглядеть как прямая линия с рис. 1, и, соответственно, агрессивно управляете эффективностью своей команды, может возникнуть риск того, что члены команды будут недовольны или демотивированы. Особенно если они почувствуют, что график стал «кнутом» для наказания, или что они стали «рабами производительности».
Часто на полпути к окончанию проекта может возникнуть плато, когда одновременно подходит к завершению множество самых сложных элементов, а затем возникает ускорение до финиша в конце. Вы должны это признать и учитывать в методах управления своими командой и проектом. Опять же, можно решать эти вопросы во время «летучек».
Важно не слишком полагаться только на свою диаграмму сгорания задач и использовать весь спектр ваших навыков управления проектами.