ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 360
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Планирование
113
истории, помещенные на эти карточки . Еще состоится много встреч вроде этой . Они будут проводиться каждый раз, когда будут до- бавлены новые истории или уточнено что-то насчет старых . Стоит ожидать, что такие встречи будут непринужденными, но законо- мерными для каждой итерации .
Однако еще начало нулевой итерации, и это самая первая, оценоч- ная встреча . До этого оценка историй не проводилась .
Итак, мы выбираем из кипы историю средней сложности . До- пустим, это история «вход» . Многие из нас присутствовали при написании этой истории, поэтому слышали разнообразные под- робности, которые, как представляли себе заинтересованные сто- роны, должны быть приведены в ней . Мы, скорее всего, попросим партнеров рассмотреть эти подробности сейчас, чтобы убедиться в том, что понимаем сложившиеся обстоятельства одинаково .
Потом мы оценим реализацию истории в пунктах . История «вход» получит 3 единицы по сложности разработки соответствующей функции (рис . 3 .1) . Почему 3? А почему бы и нет? История «вход» средняя по сложности, поэтому она получает средний балл . Три — это средний балл при шестибалльной шкале оценки историй .
Вход
3 6
Выдача наличных
5
Внесение наличных
3
Перевод
1
Выход
Рис. 3.1. История «вход» получает три единицы сложности
Глава 3. Методы взаимодействия с клиентами
114
Теперь история «вход» становится эталоном . С ней будут сравни- вать все истории при проведении оценки . Так, например, выход из системы гораздо проще, чем вход в нее . Поэтому история «выход» получает единицу . Выдача наличных, вероятно, в два раза сложнее, чем вход, поэтому эта история получает 6 единиц . Внесение на- личных представляет собой примерно то же самое, что и выдача, однако эту историю реализовать чуть легче . Отдадим ей 5 единиц .
И, наконец, реализация перевода не сложнее, чем реализация вхо- да, поэтому она получает те же 3 единицы .
Мы записываем эти числа в одном из верхних углов карточки с историей, которую мы оценивали . Я еще расскажу подробнее о том, как даются оценки . А сейчас давайте считать, что у нас есть кипа карточек с историями, которые мы оцениваем в единицах от 1 до 6 . Почему от 1 до 6? А почему бы нет? Существует много схем, по которым можно оценивать сложность . Обычно чем проще система оценок, тем лучше .
В этой связи, возможно, у вас появится вопрос: а что в действи- тельности измеряют единицы сложности? Возможно, вы поду- маете, что время — часы, дни, недели или что-то подобное . Но нет . Скорее это единица измерения затрачиваемых усилий, а не времени . Действительно, они позволяют измерить сложность выполнения истории .
Единицы сложности историй должны быть линейными . История на карточке, оцениваемая в 2 единицы, должна быть вдвое легче той, что оценена в 4 . Впрочем, линейность не обязана блюстись в совершенстве . Помните, что это оценка, поэтому точность на- меренно остается размытой . На историю, оцененную в 3 единицы,
Джим может потратить два дня, если больше не появится ошибок, на которые приходится отвлекаться . А Пэт сможет выполнить ее за день, если работает из дома . Эти оценки слишком расплывчаты,
Планирование
115
неотчетливы и неточны, поэтому их нельзя связывать с определен- ными промежутками времени .
Но в таких расплывчатых и неотчетливых оценках есть своя пре- лесть . Эта прелесть — закон больших чисел
1
. При многократном выполнении задания размытость сводится на нет! Это преимуще- ство мы будем использовать позднее .
Планирование первой итерации
Между тем пришло время планировать первую итерацию . Встречу по ее планированию можно считать началом . Эта встреча по плану должна составлять одну двадцатую продолжительности всей ите- рации . То есть если итерация длится две недели, на нее требуется затратить полдня .
На встрече должна быть вся команда, в том числе заинтересован- ные стороны, программисты, тестировщики и менеджер проекта .
Заинтересованные стороны должны заблаговременно прочитать оцениваемые истории и отсортировать их в порядке выполнения в зависимости от своих потребностей . Бывает, что команды оцени- вают приоритет историй в зависимости от требований клиента тем же способом, что и сложность выполнения задач . Есть команды, которые большее внимание уделяют приоритетам .
На встрече задача заинтересованных сторон заключается в том, что- бы выбрать истории, которые программисты и тестировщики будут выполнять во время итерации . Чтобы это сделать, им нужно знать, сколько единиц программисты, по их мнению, смогут выполнить .
Количество историй за итерацию называется скоростью . Конечно, поскольку это только первая итерация, никто не может сказать, ка-
1
https://ru.wikipedia.org/wiki/Закон_больших_чисел.
Глава 3. Методы взаимодействия с клиентами
116
кова будет скорость хода работ . Поэтому приходится делать предпо- ложения . Предположим, что скорость будет 30 единиц за итерацию .
Важно осознавать, что скорость не является обязательством . Ко- манда не дает обещание, что 30 единиц будут выполнены за итера- цию . Она даже не обещает постараться выполнить эти 30 единиц .
Эта скорость не более чем предположение о том, сколько единиц в лучшем случае будут выполнены к концу итерации . А такое пред- положение не может отличаться высокой достоверностью .
Прибыль от вложений
Теперь заинтересованные стороны нарисовали квадрат и поделили его на четыре участка (рис . 3 .2) .
Сделать позже
Сделать сейчас
Сделать позже
Не делать вообще
Низк ая в ажност ьВ
ыс ок ая в ажность
Высокая сложность
Низкая сложность
Рис. 3.2. Квадрат с четырьмя участками
Приоритетные и несложные истории можно начинать выполнять хоть сейчас . Приоритетные, но более сложнее можно немного от- ложить на потом . Неприоритетные и несложные можно сделать за день . А о тех, что не представляют особой ценности, да еще и сложны, можно забыть .
Планирование
117
С помощью этого квадрата выполняется расчет окупаемости инве- стиций (ROI) . Здесь нет формальностей и не нужно никакой ма- тематики . Заинтересованные стороны просто смотрят на карточку и делают вывод, основываясь на оценках приоритета и сложности истории .
Например: «Вход довольно важен, но также и сложен . С ним подо- ждем . Выход тоже важен, но будет попроще . О! Давайте его! Вы-
дача наличных . . . сложно, очень сложно . Но нам в первую очередь важно показать как раз эту функцию . Поэтому делайте ее» .
Мы только что увидели, как заинтересованные стороны расстав- ляют приоритеты . Заинтересованные стороны рассматривают карточки с историями и ищут те, от которых можно получить наи- большую отдачу . Они останавливаются, когда выбранные истории в сумме дают 30 единиц сложности . Это план на итерацию .
Промежуточная проверка
А теперь за работу! Позже я расскажу в подробностях о том, как ведется разработка по историям . А сейчас просто представим, что есть какой-то способ превратить истории в работающий код . Пред- ставьте этот способ как перекладывание карточек с историями из кучи запланированное в кучу сделанное .
К середине итерации должно быть выполнено много историй .
А сколько единиц должно оставаться? Правильно, столько же, сколько и сделано . В нашем случае это 15 . Чтобы провести про- межуточную проверку, нужно уметь делить на два .
Поэтому давайте созовем всех на промежуточное совещание . Пу- скай это будет понедельник, первый день второй недели итерации .
На встречу должны прийти члены команды и заинтересованные стороны — последние оценивают ход работ .
1 ... 4 5 6 7 8 9 10 11 ... 20
Глава 3. Методы взаимодействия с клиентами
118
Ой-ей, да истории выполнены только на 10 единиц! Осталась всего неделя, вряд ли за нее выполнят больше двадцати! Поэтому заин- тересованные стороны вычитают некоторое количество историй из плана, чтобы осталось только 10 единиц до конца итерации .
В пятницу после обеда подводится итог итерации с демонстра- цией . Оказывается, выполнено лишь 18 единиц . Итерация про- вальна?
Нет! Итерации не бывают провальными . Целью итерации является сбор данных для менеджеров . Конечно, было бы здорово, если бы во время каждой итерации появлялся код, но даже когда этого не происходит, главное — собрать данные .
Вчерашняя погода
Теперь мы знаем, сколько единиц сложности историй мы можем выполнить за неделю — около 18 . Как думаете, сколько единиц запланируют заинтересованные стороны в понедельник, в начале следующей итерации? Без сомнений, восемнадцать . Это называют вчерашней погодой . Вчерашняя погода лучше всего предскажет, какая погода будет сегодня . А вернее всего ход текущей итерации может предсказать то, что получено в ходе предыдущей .
Поэтому на встрече по планированию заинтересованные стороны добавляют столько историй, чтобы получилось 18 единиц . Но на этот раз на таком же промежуточном совещании происходит кое- что, что не укладывается в голове . Выполнено 12 единиц . Надо ли говорить об этом партнерам?
Нет, не стоит . Они сами все увидят . Поэтому заинтересованные стороны добавляют шесть дополнительных единиц, чтобы по плану вышло 24 .
Планирование
119
Конечно, выходит так, что команда успевает выполнить только 22 .
Поэтому на следующую итерацию планируется 22 единицы .
Окончание проекта
И на этой итерации происходит то же самое . По завершении ите- рации скорость, с которой выполняются истории, наносится на соответствующий график, чтобы все могли видеть, как быстро команда выполняет свою работу .
Предположим, что так продолжается итерация за итерацией, месяц за месяцем . Что происходит с кипой карточек с историями? Пред- ставьте, что кругооборот итераций — это насос, перекачивающий
ROI из этой кипы . И представьте, что непрерывное появление тре- бований в ходе проекта — это насос, перекачивающий окупаемость обратно в кипу . Пока входящие вложения превосходят их отток, проект будет продолжаться .
Однако может случиться и так, что количество новых функций для реализации постепенно сведется к нулю . Когда это произойдет, денежные средства, которые содержат карточки, будут исчерпаны через несколько итераций . Придет день, когда на встрече по плани- рованию заинтересованные стороны посмотрят на карточки с исто- риями и поймут, что работы больше не осталось . Проект завершен .
Проект заканчивается не тогда, когда выполнены все истории .
Проект можно считать завершенным, когда больше не остается карточек с историями, которые стоит выполнять .
Иногда удивляет, какие карточки с историями остаются в кипе, когда проект заканчивается . Однажды я работал над проектом, который длился год . Самая первая история, написанная для про- екта и давшая ему название, так и не была реализована . Эта исто-
Глава 3. Методы взаимодействия с клиентами
120
рия была важна в свое время, но позже появились более срочные истории, за которые брались разработчики . И к тому времени, когда срочные истории были выполнены, оказалось, что важность первоначальной истории испарилась .
Истории
Пользовательские истории — это простые инструкции, которые напоминают нам о свойствах функций . Мы стараемся не записы- вать слишком много подробностей, истории мы пишем как раз потому, что знаем, что подробности наверняка не раз изменятся .
Подробности нужно записывать позже, в качестве приемочных тестов .
Истории должны соответствовать следующим атрибутам качества
(критерии INVEST) .
z
Независимость (Independent) . Пользовательские истории не- зависимы друг от друга . Это значит, что истории необязательно выполнять в каком-то определенном порядке . Например, выход не нужно выполнять после входа .
Это гибкое требование: бывает и так, что какие-то истории будут зависеть от других, которые нужно реализовать в первую очередь .
К примеру, если мы реализуем вход без функции восстановления
забытого пароля, то однозначно восстановление пароля в какой-то мере зависит от входа . И все же мы стараемся отделить истории так, чтобы они были зависимы друг от друга в наименьшей мере .
Это позволяет выполнять истории в нужном клиенту порядке .
z
Обсуждаемость (Negotiable) . А это еще одна причина, по которой мы не записываем все подробности . Нужно, чтобы раз- работчики и клиенты могли обсуждать эти подробности .
Планирование
121
Например, клиенты могут запросить классный интерфейс с воз- можностью перетаскивания в него чего-либо . Разработчики могут посоветовать интерфейс попроще, с флажками, объяснив, что разработка в таком случае будет проще и дешевле . Обсуждения важны, поскольку это один из немногих способов, с помощью которых клиенты получают представление о том, как управлять стоимостью разработки ПО .
z
Ценность (Valuable) . Клиенты хотят видеть, что у истории есть определенная измеримая ценность .
Рефакторинг нельзя считать историей . Архитектуру тоже нельзя .
И чистка кода никакая не история . История — это всегда что-то, имеющее ценность для бизнеса . Не переживайте, нам доведется иметь дело с рефакторингом, архитектурой и чисткой кода, но не с самими историями .
Это значит, что история будет проходить через все уровни разра- ботки программы . То есть она может частично затрагивать часть реализации графического интерфейса, промежуточного программ- ного обеспечения, баз данных и так далее . Представьте, что исто- рия — это тонкий вертикальный срез, проходящий сквозь горизон- тальные слои проекта .
Количественное измерение ценности можно проводить без фор- мальностей . Некоторым командам может вполне подойти шкала приоритетов «высокий — средний — низкий», кому-то больше понравится десятибалльная шкала . Не имеет значения, какую шкалу использовать, главное — уметь чувствовать разницу между историями, ценность которых значительно отличается .
z
Поддаваемость оценке (Estimable) . Пользовательская история должна быть достаточно конкретной, чтобы разработчики могли сделать прогноз .