Учет трудоемкости при использовании гибких методов разработки

1.

Учет трудоемкости при
использовании гибких методов
разработки

2.

Игра в планирование
(Planning Game)
• Задачи команды
1. Оценка времени для реализаций каждого из пожеланий;
2. Оценка времени связанной с выбором технологии
3. Распределение задачи между командами;
4. Оценка рисков, связанных с каждым из пожеланий;
5. Определение порядка в котором будет реализованы
задачи.
• Задачи заказчика
1. Определяет набор пожеланий и конкретизирует каждую
итерацию;
2. Определяет дату завершения работы(Realize)
3. Определяет приоритеты задач
Планирование должно выполняться как можно чаше

3.

Первичное обследование
• В начале работы над проектом разработчики и заказчики обсуждают новую
систему, чтобы выявить наиболее существенные функции.
• Однако они не пытаются идентифицировать все вообще функции. По мере
развертывания работ заказчики будут обнаруживать все новые и новые
функции. Поток функций не иссякнет вплоть до момента завершения
проекта. Вновь выявленная функция разбивается на одну или несколько
пользовательских историй, которые записываются на учетной карточке или
чем-то подобном.
• Пример, «Вход в систему», «Добавление пользователя», «Удаление
пользователя», «Изменение пароля»
• Разработчики совместно оценивают истории в баллах. Эти оценки
относительны, а не абсолютны.

4.

1. Принципы и особенности оценки в Agile
Принцип 1: высокая скорость оценки
•В гибких методологиях сделан акцент на скорость – быстрая разработка, быстрая поставка,
оперативная обратная связь. Также и методы оценки задач в Agile в первую очередь должны
быть быстрыми. Сама по себе оценка не несет какой-либо бизнес ценности, поэтому в
динамичном итеративном процессе логично сделать ее с наименьшими трудозатратами, как
можно дешевле и оперативнее. Оценка пользовательских историй в Agile не будет чем-то
незыблемым на основе чего будет раз и навсегда фиксироваться бюджет проекта. Тут важно
получить реальные результаты выпустив продукт или проведя демо для заказчика и при
необходимости скорректировать методы оценки на их основе.
Принцип 2: командная работа
•Agile, это командная работа, поэтому и большинство методов оценки тут являются
групповыми. В процессе участвуют все вовлеченные в разработку члены команды,
аккумулируется информация и мнения различных экспертов. Если речь идет про Scrum, то в
оценке бэклога будет принимать участие вся Scrum Team.
•Совместные методы оценки также дают возможность каждому члену команды комфортно
себя чувствовать при высказывании своего мнения, выдвижении предположений по
сложности той или иной задачи. Итоговая оценка – это мнение и ответственность всей
команды и у отдельных участников нет потребности пререстраховываться, закладывая на
всякий случай побольше времени.

5.

Принцип 3: относительные единицы измерения
•Следующая особенность методов оценки в Agile, это использование
относительных единиц измерения. При использовании гибких методологий мы не
считаем напрямую рубли, доллары, дни, килограммы и т.п. Для оценки могут
используются какие-либо маркеры, точки, карты с числами, цвета и т.д., что дает
хорошую возможность сравнивать различные задачи друг с другом напрямую и
качественно.
При этом мы избегаем каких-либо ассоциаций и привязки к
дополнительным абстрактным величинам, например, дням.
•Например, если мы оценили задачу и получили трудозатраты 100000$, то мы
невольно задумаемся много это или мало и это может повлиять на конечную
оценку. При этом если задачу оценили в 100 story points (очков, баллов, попугаев),
то само по себе это значение еще ничего не говорит, он работает только в
сравнении с другой задачей и в этом случае оценка не искажается.

6.

Метод 1: T-Shirt Sizes (Размеры футболки):
В качестве единицы измерения в этой технике используется размер футболки: XS, S, M, L, XL.
Команда принимает решение о размере той или иной пользовательской истории в ходе совместной
открытой дискуссии.
В случае неопределенности, возможно применение голосования. При желании можно договориться о
соотношении «размеров», например, S это до 2 XS, M это до 2 S и так далее.
Как правило первые несколько задач оцениваются предварительно. Далее начинает вырисовываться
картина о степени декомпозиции историй. В итоге мы находим самые мелкие относительно остальных
задачи и они принимаются за XS . После этого остальные задачи оцениваются с точки зрения насколько
они больше XS. В зависимости от этого им присваивается определенный размер S, M, L или XL.
Также можно договориться, что у нас есть, например, большой размер XXL.
Присвоение истории этого размера говорит, что на самом деле мы не можем оценить задачу и она
нуждается в дальнейшей декомпозиции и\или уточнении.
Данная техника является довольно быстрой и ее можно использовать для оценки большого количеством
user story за одну сессию.
С ее помощью вполне реально за час оценить 15-20 историй.

7.

Метод 2: Planning Poker (Покера планирования)
Это одна из самых популярных техник оценки. Участники процесса используют специально
пронумерованные карты (подобные игральным), чтобы голосовать с их помощью за оценку user story.
Обычно для «покера» используются карты с числами Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89), но
возможны и другие варианты.
Процесс оценки выглядит следующим образом:
• Каждый участник получает колоду карт с числовыми значениями для оценки, изображением «?»
(запрос уточнения задачи) и «чашки кофе» (требование перерыва).
• Product Owner делает краткий анонс очередной пользовательской истории и отвечает на вопросы
команды по данной задаче.
• Участники «покера» выбирают карту с подходящей по их мнению оценкой и кладут их рубашкой
вверх (чтобы не влиять на выбор друг друга).
• После того, как все члены команды выбрали свои оценки карты одновременно переворачиваются.
• Участникам с самыми низкими и высокими оценками делают краткие комментарии объясняя свой
выбор оценки.
• В итоге процесса обсуждения команда приходит к единому решению и после этого переходит к
следующей пользовательской истории.
Planning Poker одна из самых точных техник оценки, но подходит для сравнительно небольшого количества
задач. В течение часовой сессии таким способом можно оценить 4-10 историй.

8.

Метод 3: Bucket System (Система "ведерок")
• В этой методике используется принцип похожий на Planning Poker - задачи оцениваются и помещаются с
ведерки с соответствующим размером. Для указания размера также можно использовать числа
Фибоначчи. Однако у этих методов есть принципиальное различие – в Bucket System после начального
масштабирования задач, процесс задачи разделяются между участниками для оценки.
•Процесс оценки выглядит так:
•Все истории, которые требуется оценить, выписываются на карточки.
•На столе или доске выстраивается последовательность из «ведерок» для задач различного
размера.
•Команда выбирает по очереди 3-5 произвольные карточки с задачами и оценивает их в ходе
открытого обсуждения сравнивая и выстраивая их друг относительно друга.
•Задачи помещаются в соответствующие «ведра» задавая общий масштаб и ориентиры для
последующих оценок.
•Далее все оставшиеся задачи поровну разделяются между всеми участниками и оцениваются ими
самостоятельно, с учетом полученной шкалы измерений.
•Если кто-то из членов команды затрудняется оценить какую-либо историю, то он передает ее
другому.
•Данный метод (в отличие от Покера планирования) может использоваться для быстрой оценки очень
большого
числа
задач
(от
50)
и
с
большим
количеством
участников.

9.

Метод 4: Dot-voting (Голосование по точкам)
Этот способ предполагает использование специальных «точек», которые показывают голоса
участников\баллы оценки поставленные для той или иной задачи. В качестве таких «точек» могут
использоваться: наклейки, стикеры, магниты, точки\штрихи проставленные маркерами.
Этапы процесса оценки:
• Все оцениваемые User Stories выписываются на отдельные карточки и размещаются на
столе\доске.
• Для выполнения оценки каждый из участников получает одинаковое количество «точек». Каждый
член команды распределяет свои «точки» между задачами как он считает нужным, учитываю, что
чем больше «точек», тем сложнее задача и тем больше на нее необходимо времени.
• После того как каждый участник сделал свою оценку и распределил все свои «точки»,
подсчитывается общее количество точек выставленных для каждой пользовательской истории. В
результате все задачи ранжируются между собой по количеству «точек».
•Данный метод является очень простым и быстрым, он будет эффективно работать для оценки
небольшого
количества
историй
(до
8-10).

10.

Метод 5: Maximum Size or Less (Разделение до максимального размера или меньше)
В рамках этой техники участники процесса оценки вначале определяют максимально возможный размер
для задачи в бэклоге. Чаще всего в качестве максимального значения выбирается 1 человеко-день (1
FTE). В этом случае самые большие задачи должны требовать для их выполнения не более 1 дня.
Далее процесс оценки выглядит следующим образом:
• Каждая история обсуждается всеми участниками, чтобы ответить на вопрос: оцениваемая задача
больше максимального значения или меньше\равна ему?
• Если данная история больше максимального размера, то группа декомпозирует ее на подзадачи и
повторяет процесс с оценки для составных частей.
• Процесс продолжается пока все оцениваемые задачи не окажутся в разрешенном диапазоне
размеров – будут равны или будут меньше выбранного за максимальное значения.
Этот метод оценки также очень прост в использовании и с его помощью команда способна за справиться с
15-30 задачами (в зависимости от сложности и опыта декомпозиции).

11.

Метод 6: Big/Small/Uncertain (Большой/Малый/Неопределенный)
Данный метод похож на технику Bucket System, основное различие состоит в том, что в этом случае
используется только 3 ведра: большой размер, малый размер, неопределенный размер задачи.
Процесс оценки:
• Все оцениваемые истории обсуждаются участниками и помещаются в одну из трех категорий
Big/Small/Uncertain.
• Сначала группа проводит групповое обсуждение нескольких первых задач (3-5), определяя
масштаб и ориентиры для каждой категории.
• Затем, подобно Bucket System, оставшиеся истории распределяются между участниками и
оцениваются самостоятельно, что сильно ускоряет процесс.
Это одна из самых быстрых техник оценки. Она позволяет оценить за одну сессию большое количество
историй (от 50) и позволяет привлекать к процессу одновременно много участников.

12.

Метод 7: Ordering Rule (Выстраивание порядка)
Данный метод представляет собой пошаговую игру, цель которой выстроить все задачи друг
относительно друга на единой шкале размера.
Процесс оценки:
• Сначала все оцениваемые истории выписываются на карточки.
• Карточки с задачами случайным образом размещаются на столе или доске со шкалой, на
границах которой указаны «малый размер» и «большой размер».
• Каждый участник по очереди совершает свой «ход» оценки. Такой «ход» включает одно из
следующих возможных действий: переместить любую историю по шкале на одно деление (т.е.
поменять оценку на более низкую или высокую), обсудить историю с коллегами, пропустить свой
«ход».
• В результате «ходов» сотрудников задачи могут перемещаться по доске, их оценка друг
относительно друга уточняется.
• Когда все участники пропускают свой «ход», процесс оценки завершается. Все задачи
распределены по шкале между значениями «малый размер» и «большой размер».
Этот метод довольно эффективен для оценки небольшого количества задач (5-15). Участники вовлечены
в общий геймифицированный процесс и изменяя положения историй относительно друг друга
добиваются высокой точности оценки.

13.

Как оценить SLA команды: строим спектральную диаграмму
По оси Х фиксируем Lead Time (LT) — время производства задачи. В нашем
случае это время от «Готово к разработке» до «Готово».
•По оси Y откладывается частота — сколько задач мы сделали за LT1, LT2, LT3
и т.д.

14.

Мы закрыли 3 задачи за день, 6 — за два, больше всего — за 5, а где-то бились
над
таской
больше
двух
недель…
Ну а теперь время анализировать. Что это за задачи? Почему они попали именно
сюда? Почему мы делаем в определенный LT больше, чем в другие, что там?
Копать можно вплоть до заказчиков и исполнителей, а также изучать комментарии
к
таске.

15.

Это наша регулярная работа.
Разброс
довольно
большой,
но
он
поддается
анализу.
В целом, основная масса задач распределилась в промежутке 7-14 дней, а парочка улетела совсем далеко
— в этом хвосте было несколько задач (не все) с PR в другие сервисы. Те задачи, что завершились за 3-4
дня,
скорее
исключение,
чем
правило.
Итак, можно сказать заказчику, что если задача проходит как регулярная работа, с вероятностью 75% она
доедет до прода за 10 дней.
А с вероятностью 90% это займет 14 дней. Ну а если разработка затрагивает другие сервисы компании,
ждать придется немного дольше, — нам нужен код-ревью от другой команды и потом еще деплой.

16.

Класс
«Важный».
По каким-то причинам эти задачи берутся в работу раньше других: там или больше ценности или цена задержки выше.
И тут мы также можем озвучить SLA: с 75% вероятностью задача попадет на прод за 5 дней, с 90% вероятностью за 7.
Те самые задачи, ради которых мы бросаем всё и пилим, пилим, пилим — блокеры.

17.

Те самые задачи, ради которых мы бросаем всё и пилим, пилим, пилим — блокеры.
В 100% случаев это мелкие доработки, которые мы не учли при реализации основной фичи, либо баги, которые аффектят
жизненно
важный
функционал
на
проде.
Несмотря на то, что все подобные ситуации нам удалось разрешить за 2 дня, всё равно озвучим 90’ый процентиль. Вопервых, не стоит обещать 100% — никому и никогда :) Во-вторых, нужно закладывать вариабельность: вспомним случай с
регулярной работой, когда несколько задач улетело за 20+ дней, потому что появилась зависимость от других команд.

18.

Готово! Можем согласовать SLA по всем классам обслуживания:

19.

Объединение, разбиение и скорость
• Если история слишком велика, то ее следует разбить на меньшие
части.
• Если история слишком мала, ее следует объединить с другими
• История «Пользователи могут безопасно переводить деньги на
свой счет, со своего счета или с одного счета на другой» может
быть разбита на истории:
• • Пользователь может войти в систему
• • Пользователь может выйти из системы
• • Пользователь может положить деньги на свой счет
• • Пользователь может снять деньги со своего счета
• • Пользователь может перевести деньги с любого из своих счетов
на другой

20.

Планирование выпуска
• Каждую неделю мы завершатся реализация нескольких историй.
Сумма оценок завершенных историй дает скорость.
• Зная скорость, заказчик может получить представление о
стоимости каждой истории, а также о ее значимости для бизнеса
и о приоритете. Это позволяет заказчику решить, какие истории
реализовывать первыми.
• Разработчики и заказчик согласуют дату первого выпуска
проекта. Обычно это занимает 2–4 месяца. Заказчик указывает,
какие истории реализовать в этом выпуске и примерный порядок
реализации. Не разрешается выбирать больше историй, чем
укладывается в текущую скорость.

21.

Планирование итерации
• Разработчики и заказчик определяют длительность итерации:
обычно 1 или 2 недели. И снова заказчик решает, какие истории
реализовать на первой итерации, но не может выбрать больше
историй, чем позволяет текущая скорость.
• Порядок реализации историй в пределах итерации – вопрос
решаемый самими разработчиками.
• Заказчик не может изменять истории после начала итерации. Он
вправе изменять или переупорядочивать любые истории, кроме
тех, над которыми разработчики уже трудятся.
• Итерация заканчивается в заранее оговоренный день, даже если
не все истории реализованы. Оценки всех завершенных историй
суммируются, и вычисляется скорость на данной итерации. Эта
величина ис-пользуется для планирования следующей итерации.

22.

Определения понятия ≪готово≫
• История не считается реализованной, пока не пройдут все
приемочные тесты. Эти тесты автоматизированы.
• Пишут их заказчики, бизнес аналитики, специалисты по контролю
качества, тестировщики и даже программисты в начале каждой
итерации.
• Тесты определяют детали истории и являются неоспоримым
авторитетом в вопросе о поведении историй.

23.

Планирование задач (1)
• В начале новой итерации разработчики и заказчики
вырабатывают план. Разработчики разбивают истории на задачи.
• Задачей называется объем работы, с которым один разработчик
может справиться за 4–16 часов.
• Истории анализируются совместно с заказчиком, и задачи
формулируются максимально полно.
• Список задач записывается в лекционном блокноте, на доске или
на любом другом носителе.
• Затем разработчики выбирают себе задачи, которые хотели бы
реализовать, присваивая каждой задаче произвольную оценку в
баллах.

24.

Планирование задач (2)
• Разработчик может выбрать любую задачу вне зависимости от
специализации.
• Каждый разработчик знает, сколько баллов он заработал на
задачах на предыдущей итерации; это число составляет бюджет
разработчика.
• Никто не берет себе задач на большую сумму, чем его бюджет.
• В середине итерации команда устраивает рабочее совещание. В
этот момент должна быть реализована половина историй,
запланированных на даннуюитерацию. Если это не так, то команда
пытается перераспределить задачи и ответственность таким
образом, чтобы к концу итерации все истории были реализованы.

25.

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

26.

Мониторинг (1)
• Мониторинг и управление XP-проектом сводятся к записи
результатов каждой итерации и использованию этих данных для
прогнозирования следующих итераций. Рассмотрим, например,
рис.. Этот график называется диаграммой скорости.

27.

Мониторинг (2)
• Диаграмма выгорания показывает, сколько баллов оставалось
набрать в конце каждой недели до следующей важной
контрольной точки. Наклон этого графика – индикатор даты
завершения.

28.

Тестирование
(Testing)
Тестирование применяемое в XP
• Тестирование модулей (unit testing)
• Приемочное тестирование (acceptance testing)

29.

Разработка через тестирование
1. Не писать код, пока не будет написан автономный тест,
который не проходит.
2. Не писать автономный тест большего объема, чем необходимо
для неудачного завершения или неудачной компиляции.
3. Не писать больше кода, чем необходимо для того, чтобы ранее
не проходивший тест завершился успешно.
• Написание теста до кода способствует проектированию кода,
который было бы удобно вызывать.
• Предварительное написание тестов заставляет писать слабо
связанные программы!
• Тесты могут выступать как чрезвычайно полезная документация.
Она всегда актуальна. Она не лжет.

30.

Программирование парами
(Pair Programming)
Преимущества парного программирования
• Любые решения принимаются не одним программистов а двумя;
• Какую бы часть системы не взять, в ней будут хорошо разбираться как
минимум два человека;
• В паре партнеры контролируют друг друга – снижение вероятности
написания не корректного, не аккуратного кода;
• Партнеры в парах постоянно меняются, это дает возможность всем
членам команды знать функционал системы

31.

Рефакторинг
(Refactoring)
Refactoring – процесс изменения программной системы таким
образом, что ее внешнее поведение не изменяется, а внутренняя
структура улучшается.
• У каждого программного модуля есть три функции:
1) та функция, которую он реализует во время выполнения
2) модуль должен допускать изменение. Почти все модули на
протяжении своей жизни изменяются, и задача разработчика –
обеспечить возможность и простоту внесения изменения.
Модуль, который трудно изменять, следует считать непригодным
и нуждающимся в исправлении, даже если он работает.
3) модуль должен быть доступным для понимания. Разработчики,
не знакомые с модулем, должны иметь возможность прочитать и
понять его, не прилагая сверхъестественных умственных усилий.
Модуль, который не информативен, также непригоден и
нуждается в исправлении.

32.

Простой дизайн
(Simple Design)
Цели Simple Design:
• Спроектировать систему один раз и на всегда невозможно. В XP –
проектирование происходит постоянно.
Simple Design :
• Обеспечение корректного срабатывания всех тестов;
• Отсутствие дублирующего кода;
• Хорошо выраженные намерения программиста для конкретного участка
кода;
• Минимальное количество классов и методов;

33.

Коллективное владение кодом
(Collective Code Ownership)
• Каждый член команды может вносить изменения в любой код
системы;
• Разработчик может выбрать любую задачу. Специалисты по базе
данных не обязаны ограничиваться только задачами, связанными
с базой.
• Специалисты по разработке ГИП могут при желании выбрать
задачу, касающуюся базы данных. Хотя на первый взгляд это
может показаться неэффективным, но выгода очевидна: чем
больше каждый разработчик знает о проекте в целом, тем
успешнее и информированнее вся команда.
• Добиваемся, чтобы за проект отвечала команда целиком,
независимо от специализации.

34.

Улучшение дизайна
• Плохой код не должен доживать до заката. Код все время
должен оставаться максимально чистым и выразительным.

35.

Постоянная интеграция (Continuous
Integration)
• Интеграция модулей в систему выполняется постоянно,
несколько раз в день.
• Обеспечение интеграции осуществляется за счет систем
совместной работы.

36.

Заказчик в команде
(On-Site Customer)
• Постоянная доступность заказчика, который может ответить на
возникшие вопросы, пускай даже по телефону;
• Наличие заказчика в команде позволяет работать с оптимальной
скоростью.
• «… Я предпочел бы, чтобы нужный человек был доступен мне,
по крайне мере один час в день, чем если бы ненужный человек
был доступен мне в течении всего рабочего дня, или нужный
человек – в течении одного дня в неделю» Кен Ауэр.

37.

Частые выпуски версий
(Small Realize)
Версии должны выпускаться в эксплуатацию, как
можно чаще. Работа над каждой версией должна
занимать как можно меньше времени. При этом
каждая версия должна быть осмысленной.

38.

40 – часовая рабочая неделя
(40-hour Week)
«… желаю быть свежим и энергичным каждое
утро, ровно как уставшим и удовлетворенным
каждый вечер » K.Beck Extrem Programming.

39.

Стандарты кодирования
(Coding Standards)
• Весь код выглядит так, будто его писал один – очень
квалифицированный – человек.
Благодаря стандартам:
• Члены команды не тратят время на глупые споры о вещах, которые
фактически никак не влияют на скорость работы над проектом;
• Обеспечивается эффективное выполнение остальных практик.

40.

Метафора системы
(System Metaphor)
• Команда поддерживает общее видение работы программы.
Метафора системы - это архитектура системы.
Метафора системы дает команде представление о
том, каким образом система работает в настоящее
время, в какие места добавляются новые
компоненты и какую фору они должны принять.

41.

Постановка задачи
Разработать Web-портал для хранения и анализа информации о скидках на товары.
• Основные функциональные требования к системе:
• Возможность регистрации нового пользователя в системе.
• Возможность бана пользователя за нарушения разглашения информации о скидках
• Возможность бана скидки. Если более 10 разных пользователей в течении 10 дней оценит
негативно скидку(-5) она банится, при этом статус пользователя, который ее разместил
понижается на 1 бал.
• Возможность добавлять информацию о скидке указывая название магазина, название
товара, скидка, базовая цена товара (по желанию).
• Возможность выводить списки всех скидок по определенной категории, магазину,
району.
• Возможность находить товар со скидкой по определенному критерию.
• Возможность группировать товары по категориям и все отображать на экране браузера.
• Возможность получать информацию о текущих скидках на электронный ящик, только в
том случае, если оплатил ваучер.
• Возможность получать информацию на электронный адрес или на экран браузера о
предстоящих скидках, в том случае если оплатил ваучер.
• Возможность добавлять комментарии к текущим или выполненным скидкам, а также
оценивание их по 10 бальной шкале от -5 до +5.
Архитектура приложения
• Наличие модульной системы.