Средства визуализаци, используемые при разработке программного обеспечения по Agile

Интервью. Александр Атцик, активист AgilePiter, product owner в DINS, доцент Санкт-Петербургского Университета Телекоммуникаций

The following two tabs change content below.
    Касаева Ирина

    Касаева Ирина

    13, декабря 2014

    Управление проектом разработки ПО — относительно сложная задача и инструментарий, который используется при её визуализации, прошёл долгий путь развития и улучшения, поэтому его легко применять и для решения других более простых задач — будь то ремонт в квартире, открытие бара, организация конференции или свадьбы.

    atzik2

    И в такой важной сегодня области как разработка программного обеспечения тоже есть своя культура визуального мышления. Причём наиболее интересную и комплексную систему применяют в так называемых гибких (Agile) методологиях разработки ПО.

    Именно об этом мы и поговорим с Александром Атциком, одним из активистов сообщества AgilePiter, много лет занимающегося разработкой программных продуктов в Agile командах, product owner в компании DINS и доцентом Санкт-Петербургского Университета Телекоммуникаций.

    Что такое Agile методология и зачем она появилась?
    Традиционно ПО разрабатывалось по водопадному методу (рис. 1), когда создание программы делилось на крупные и продолжительные фазы: сбор требований, анализ требований, проектирование, разработка, тестирование, развёртывание системы. У этой методики был недостаток: пока шло проектирование, разработка и тестирование, требования успевали поменяться, да и вообще изначально никто точно не знал, что он хочет получить от продукта. Это похоже на то, как если бы вы захотели спроектировать огромный жилой квартал, не попробовав в жизни построить хотя бы одноэтажный коттедж.

    vodopad

    Рис. 1 Водопадный процесс разработки ПО.

    В результате появилась методология Agile, которая ставила целью избавиться от недостатков “водопада” за счёт того, что стала считать изменения не чем-то негативным, а наоборот положительным — если мы что-то меняем, значит, мы получили более точное понимание и всё ближе приближаемся к цели продукта. А чтобы реагировать на изменения было проще, то вместо больших независимых фаз были введены относительно короткие (2-4 недели) итерации, включавшие в себя все фазы водопада в уменьшенном масштабе (рис. 2).

    iteraz

    Рис. 2 Итеративный процесс разработки ПО

    Будучи открытой методологией, стремившейся к максимальной эффективности и гибкости, Agile вобрала в себя все наиболее эффективные стратегии управления задачами, проектом и индивидуальной работой сотрудника.
    Так, визуальные инструменты Agile позволяют следить за прогрессом, фокусироваться на последовательном решении задач, избегая распыления усилий, видеть изменение объёма и количества задач в процессе работы и, следовательно, понимать причины отставания или опережения изначального графика работ.

    Какие визуальные инструменты применяются в Agile? Можно ли их использование перенести на задачи из других сфер жизни?
    Самым известным визуальным инструментом в Agile является доска задач (рис. 3). Рассмотрим доску на примере известной методологии семейства Agile — SCRUM.
    На доску команда вешает карточки Пользовательских историй (User Story) — описания требований к разрабатываемой системе, сформулированных на ежедневном или деловом языке пользователя. Карточки историй служат источником информации и используются для визуализации требований к продукту. Также на доску вешаются карточки задач, которые необходимо решить для реализации каждой Пользовательской истории.
    Карточки Пользовательских историй размещаются на доске вертикально и упорядочены по приоритету сверху вниз. Команда старается работать с историями последовательно от верхней к нижней.
    scrum

    Рис. 3 Scrum доска

    Доска поделена на три сектора — To Do (сделать), In Progress (в работе) и Done (сделано). По мере работы задачи передвигаются слева направо, пока все карточки не окажутся в Done. Карточки команда двигает каждое утро на ежедневном собрании у доски, при перемещении в In Progress карточке присваивается исполнитель. Таким образом, вся команда всегда в курсе своего прогресса и текущего распределения задач, видит, когда какая-то задача застряла и требует внимания или помощи остальных членов команды.

    Иногда для того, чтобы не упустить какие-то важные аспекты реализации историй и задач на доску вешается DoD (Definition of Done) – чеклист, по которому должна быть проверена каждая карточка перед перемещением в область Done.

    Обычно в начале итерации команда пытается оценить размер каждой истории и задачи. Поскольку размер задач может быть разным, то для того, чтобы понимать успевает ли команда справиться с запланированным объёмом работ в срок, используется Burndown график (рис. 4): по вертикальной оси которого откладываются Story Points (условные единицы оценки размера Пользовательской истории) или человеко-часы, а по горизонтали — дни, входящие в данную итерацию. Каждый раз, когда команда закрывает историю или задачу, то график Burndown падает на это количество Story Points или человеко-часов. На Burndown всегда нанесена базовая линия, относительно которой можно видеть отставания и опережения графика.

    burndown

     

     

     

     

     

     

     

     

     

     

     

    Рис. 4 Burndown chart

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

    Другая известная методология Agile — Kanban привносит на доску дополнительные графические инструменты. Во — первых, она вводит ограничение на количество задач, которые могут одновременно находиться в работе, так называемое ограничение (рис) Work In Progress (WIP). Сделано это для того, чтобы максимизировать усилия по продвижению задачи из ToDo в Done, не создавая огромного количества начатых и незавершённых задач. Если WIP исчерпан, то никто не может брать новых задач и вынужден сконцентрироваться на тех, которые застряли в работе. WIP обычно отражается цифрой над соответствующей колонкой

    В Kanban также появляются дополнительные колонки (рис. 5), отражающие путь User Story до того, как она попадает в To Do — от идеи, до её валидации и приоритезации. На каждую из этих колонок также можно поставить ограничение WIP.

    kanban2

    Рис. 5 Вариант Kanban доски

    Кроме перечисленных есть еще дополнительные средства визуализации в Agile.
    В Agile очень любят разные методы визуализации, так в одной петербургской компании-разработчике НТЦ Аргус родился интересный метод, дополняющий традиционную визуализацию на SCRUM доске:
    Пользовательская история — это единица функциональности с точки зрения бизнеса, но она не всегда напрямую соотносится с техническими задачами, и они могут иметь собственную иерархию и взаимозависимость, когда не сделав одну задачу, нельзя переходить к следующей.

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

     

     

     

     

     

     

    Рис. 6 Пример графа зависимости задач

    Таким образом, для того, чтобы уже завтра попробовать визуализировать свои задачи по Agile вам понадобится лишь плоская вертикальная поверхность в вашем доме и набор бумажных стикеров разных цветов.

    Как бы вы описали процесс построения доски задач по шагам?

    Процесс можно свести к следующей последовательности шагов:

    1. Определить ключевые истории, каждая из которых представляет отдельную ценность для конечного результата и написать их на карточках.
    2. Определить ключевые виды деятельности, которые необходимо выполнять при реализации истории.
    3. Разбить истории на задачи, для каждой из которых также создать карточку, причём для карточек одинаковых видов деятельности используется один цвет.
    4. Расположить истории по порядку выполнения сверху вниз.
    5. Напротив карточек историй слева направо расположить карточки задач.
    6. Сделать оценку объёма работ каждой истории и задачи и написать на карточках.
    7. Оценив объём работ выбрать те истории, что войдут в текущую итерацию (1-4 недели).
    8. Для итерации посчитать сколько нужно человеко-часов и построить график burndown, отметив по Y необходимые человеко-часы, а по X — дни итерации.
    9. Составить список DoD.

    Похожие новости: