TaskBoard: Управление в стиле Agile
| August 12, 2007 | Posted by Denis under Практики, Статьи |
Agile development воспринимается как инструмент программиста или команды разработчиков, я же хотел бы рассмотреть Agile со стороны руководителя. Основная задача руководителя в Agile – это visibility. Видимость и прозрачность процесса – его визуализация.
Одним из лучших способов достижения прозрачности и визуализации процесса разработки – эффективная работа через Task Board.
Какие задачи выполняет Task Board:
- Отражает список задач, поставленных на недельную итерацию (Sprint), по которым Product Owner может оценивать успехи и корректировать приоритеты.
- Позволяет оперативно взаимодействовать с командой и вовремя прояснять спорные моменты
- Позволяет сделать прозрачным процесс для заказчика:
“Что то вы медленно все делаете… Вы вообще что ни будь, делаете?”,”А где мои проекты?”
На эти и многие другие вопросы помогает ответить хорошо организованный Task Board.
Итак, от теории к практике и в обратном порядке.
Мы используем Доску задач (Task Board) для коордидействия команды.
Состоит она у нас из нескольких колонок и представляет собой список проектов список,список историй по данному проекту, задач, и статусов этих задач. Каждая задача оценена по сложности. Мы также практикуем подписи разработчиков и приоритеты задач на итерацию (очень важно, когда команда находится на стадии формирования, так как зачастую итеративные планы делаются не полностью). История (User Story) – история это аналог аналитики, с более-менее понятной формой требований, которые собираются достаточно быстро по формату “Как <пользователь>, я могу <действие>, для того, чтобы <цель>” где <пользователь> – одна из обобщенных пользовательских ролей; <действие> – действие, выполняемое пользователем посредством взаимодействия с системой; <цель> – конечная цель текущей задачи, выполняемой пользователем посредством взаимодействия с системой.
Сделать (To Do) – список карточек с заданиями на данную итерацию
Сюда мы складываем карточки, которые мы готовы выполнить на данной итеративной неделе (в нашей компании итерация равна одной рабочей неделе)
В процессе разработки (Work in process) – Колонка куда карточки попадают если член команды подписывается на ее разработку
В данную колонку задачи попадают, если задачи взяты на разработку одним из команды, это зачастую происходит на Daily Scum Meeting.
Проверить (To Verify) – Раздел в который попадают карточки если нужно проверить сделанный кем-то таск(задачу).
Бывает часто, что есть задачи, в которых требуется просто разобраться, в чем дело. В данной колонке бывают задачи, как на “просто проверить и разобраться”, так и, например, оттестировать какую либо задачку или модуль.
Сделано (Done) – В данное поле попадают задачи выполненные.
В раздел сделано попадают, задачи не только прошедшие стадию кодирования, но и выкладки на продакшн, часто эту часть называют Accept – принято.
Заметка: Лично у меня есть отдельное поле “Зарти. Выложи” – колонка в которую задачи попадают после того как разработчик отладил на сервере разработки и нужно переложить на продакшн сервер, поскольку комиттер у нас один на всю компанию. Мы создали такой раздел, чтобы раз в день, как минимум, он не забывал о комиттах и ченджсетах команды. Для любителей оставлять оповещения для команды, например “не работать с таким то классом я его еще не оттестировал” или просто оставить записку, делают раздел Для записей (Notes).
Внимание: Я лично для себя выявил одно простое правило – Не вводите на таск борд все поля одновременно, начните с простых вещей: Сделать, В процессе разработки и Сделано. Команда сама будет эволюционировать и принимать решения о создании дополнительных полей на Доске Задач, что лишний раз сплотит команду.
Некоторые примеры таск бордов.
Как это было у нас:
