вторник, 21 февраля 2012 г.

С чего начинается Scrum

Ранее:
Введение в Scrum
Роли при Scrum разработке

Итак, вы собрались своей командой, выбрали или вам назначили Product Owner-а, собственно есть общее представление о том что надо делать и...


Как правило, именно этому, начальному, этапу и не уделяется внимание. Большинство литературы уже здесь бы начало рассказывать о том, что нужны User Story, оценки и так далее. Но, мне кажется, правильнее, если вы только начинаете знакомиться со Scrum, запустить "нулевой цикл". Чем на нем заняться? Сколько он должен быть по длительности? Все просто. Если проект большой, новый, в неизвестной предметной области, то "нулевой цикл" может быть и в 2-4 недели. На нем придется познакомиться с предметной областью, спроектировать архитектуру, опробовать различные варианты ее реализации, познакомиться с технологиями. Если проект уже идет, то 2-3 дней волне может хватить, потратьте их на формирование видения системы, проектирование перечня "полезностей".

Мне очень нравится, для укладывания в голове представления о предметной области, два подхода: SADT и Use Case диаграммы. Первым мы пользовались достаточно долго, но в связи с тем, что инструментарий для него, мягко говоря, дорогой, от SADT диаграмм отказались. Сейчас, особенно в связи с тем, что все равно используем Visual Studio перешли на UML диаграммы прецедентов использования (Use Case). Данный вид диаграмм позволяет понять, какие роли есть в системе, какие функции этим ролям нужны, как эти функции будут взаимодействовать между собой, какие будут последовательности. Все это и составит виденье. Получив которое можно переходить к написанию Backlog-а.

Backlog - список функций (полезностей) которые предполагается предоставить пользователю в разрабатываемой системе. Если уже нарисована Use Case диаграмма, то все просто, все функции с нее и составят в первом приближении этот список. Нужно понимать, что Backlog штука гибкая. Он может увеличиваться, уменьшаться, переупорядочиваться. Собственно, если есть Product Owner, то именно он и должен составить этот список. Элементы списка называют User Story (пользовательские истории) или просто Product Backlog Item.

Итак, Product Owner все бросил и сел за написание Product Backlog Item-ов. Что он должен по каждому написать?

1. Название - короткое и максимально простое описание будущей функции.

2. Развернутое описание - фраза, составленная по шаблону: "Как <имя роли>, я могу <описание функции>, с целью <полезность для пользователя>".

3. Приоритет - определяет, насколько велика полезность этой функции.

4. Как проверить (иногда говорят продемонстрировать) – простой тестовый сценарий, описывающий последовательность шагов которые должен выполнить пользователь в тривиальном случае.

Перед тем как привести пример, поясню одну вещь: создавать Product Backlog Item может любой участник процесса разработки. Например, тестировщик, вводя данные обнаружил, что две функции, которые приходится вызывать одну за другой разнесены по интерфейсу очень далеко, так почему бы не внести новую полезность: "вызов второй функции в процессе работы с интерфейсом выполнения первой функции" (Классическое: Выбираем должность нового сотрудника, и если нужной должности еще нет, приходится лезть в другую часть программы, чтобы ее добавить. Намного проще, если новую должность можно будет добавить по кнопке расположенной рядом с полем выбора).

Все Product Backlog Item-ы попадают в Backlog со статусом New (новые).

Пример:

Название - Добавление нового сотрудника.

Развернутое описание - Как сотрудник отдела кадров, я могу внести ФИО, паспортные данные, должность и подразделение принимаемого на работу сотрудника, с целью автоматизированного формирования приказа о приеме на работу.

Приоритет - 1000.

Статус - Новый.

Как проверить - Открыть форму добавления нового сотрудника. Ввести ФИО,паспортные данные, должность и подразделение. Нажать кнопку сохранить. Убедиться, что в списке сотрудников введенный сотрудник появился.

Пара комментариев:

1. Обратили внимание на полезность? Сотрудник отдела кадров не просто как мартышка вбивает данные сотрудника... А он, тем самым, облегчает себе жизнь. Вбив данные в одном месте, он получает документ, в котором те же ФИО, ну как минимум в двух метах уже проставлен.

2. По поводу приоритета. У нас приняты приоритеты от 0 до 2000. Ставим мы их так: если что то "горит", и должно быть сделано в первую очередь, то приоритет 1500-2000. Если это планы на отдаленное будущее, на поэкспериментировать, то 0-500. Все остальное в диапазоне от 500 до 1500. Основная масса равно приоритетных полезностей колеблется около 1000. Судя по тем данным которые я сейчас смотрю, можно отказаться от последних двух нулей, но пусть будут, вдруг пригодятся.

Итак, мы (Product Owner и команда) сформировали свой первый Backlog, напоминаю, что все что там есть имеет статус New. Затем Product Owner, уже единолично просматривает весь Backlog и выбирает, что же из этих полезностей будет в первой версии нашего продукта. Всем этим элементам статус меняется на Approved (одобрено).

Теперь наступает очередь команды. Они должны оценить сложность, объем работ по задаче (Effort). Самая большая ошибка, это попытаться выразить эту оценку в часах, днях, количестве форм, строк кода и т.д. Нет, потом, через 3-4 итерации будет найдено соответствие этой оценки часам. Но не сейчас. Так в чем же оценивать? В сложности! Мы у себя применяем шкалу кратности 2. Т.е. самая простая задача (сообщение о некорректно введенных данных, форма с показом информации о состоянии объекта) приравнивается к 1 баллу. А все остальные задачи в зависимости от сложности получают 2, 4, 8, 16, 32 балла. У нас принято, что если Product Backlog Item получает оценку 64 или 128, то это значит, что его надо либо разбивать на более мелкие, либо что по нему ничего непонятно и надо уточнять, перед тем как брать в работу. Да, самое главное! Кто в команде ставит эту сложность? А вся команда и ставит. Есть разные методики, мы например, делаем это в Skype. Все элементы Backlog-а пронумерованы, у всех разработчиков открыт этот самый Backlog, я кидаю номер элемента в общий чат, и каждый проставляет свою оценку:


Рекомендую, открыть картинку в новом окне и поглядывать на нее читая этот абзац. Видите по 599 все поставили оценку 16? Все, именно эта оценка и ушла в BackLog, на принятие решения ушло меньше минуты. По 600 мнения разошлись, и мы, уже голосом, высказали свои доводы, пришли к общему мнению и записали его. На этот элемент, т.к. оценки были рядом ушло около 3 минут. 601 - единогласно, меньше минуты. 602 - очень сильное расхождение, на обсуждение 5 минут. 603 - вызвал много вопросов, и даже для первой оценки потребовалось почти 15 минут. Именно из-зп обсуждений присутствуют все, в том числе и заказчик (Product Owner), чтобы давать комментарии по возникшим вопросам.

По окончании этого этапа у всех элементов Backlog-а в состоянии Approved должны стоять оценки. Если войдете во вкус, то можно и оценить и те, что со статусом New.

Как только оценен Backlog, все все почитали, посмотрели, поэкспериментировали и готовы начать создавать проект - можно сказать, что "нулевой цикл" закончен.

В заключении. Как кто не знаю, а мы в Backlog записываем и Item-ы которые к пользователю напрямую отношения и не имеют. Это всякие настройки TFS, тестовой среды, проектирование базы данных, подготовка "каркасов" приложений (сейчас у нас это создание проекта доступа к данным, создание проекта бизнес-логики, создание сервисов, клиентской библиотеки доступа к данным на основе RIA сервисов, создание проекта клиентского приложение, настройка всего этого). Все это потребляет время, про все это надо помнить, и проще всего это "помнить" и учитывать в вашей системе управления задачами.
В следующей статье обсудим, как уйди на первую итерацию.

Комментариев нет:

Отправить комментарий