Предварительная оценка (initial estimate) – начальная оценка объема работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу “идеальных человеко-дней”.
o Спросите вашу команду: “Если собрать команду из оптимального количества людей, то есть не слишком большую и не слишком маленькую (чаще всего из двух человек), закрыться в комнате с остаточным запасом еды и работать ни на что не отвлекаясь, то, сколько дней тогда онадобится на разработку завершённого, протестированного продукта, готового к демонстрации и релизу? “. Если ответ будет “Для трёх человек, закрытых в комнате, на это потребуется 4 дня”, это значит, что изначальная оценка составляет 12 story point’ов.
o В этом случае важно получить не максимально точные оценки (например, для истории в 2 story point’а потребуется 2 дня), а сделать так, чтобы оценки верно отражали относительную трудоёмкость историй (например, на историю, оцененную в 2 story point’а потребует примерно в два раза меньше работы по сравнению с историей в 4 story point’а).
Как продемонстрировать (how to demo) – краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. По сути, это простой тестовый сценарий типа “Сделайте это, сделайте то – должно получиться то-то”.
o Если у вас практикуется Test Driven Development (разработка через тестирование или кратко TDD) , то это описание может послужить псевдокодом [пр. Переводчика: в программировании специальный способ записи любого алгоритма] для приемочного теста.
Секундочку… В чём разница между “задачами” и “историями”? Очень правильный вопрос. А различие очень простое: истории это нечто, что можно продемонстрировать, что представляет ценность для product owner’а, а задачи либо нельзя продемонстрировать, либо они не представляют ценности для product owner’a.
В большинстве книг и статей, посвящённых Scrum'у, для оценки времени выполнения задач используются часы, а не дни. И мы так раньше делали. Общая формула была такой: один эффективный человеко-день равен шести эффективным человеко-часам. Однако мы отказались от этой практики по следующим причинам:
• Оценки в человеко-часах чересчур мелкие, что приводит к появлению большого количества крохотных задач по часу или два, и, как результат, к микроменеджменту (micromanagement).
• Оказалось, что всё равно все оценивают в человеко-днях, а когда нужно получить оценку в человеко-часах, просто умножают дни на шесть. "Хм, эта задача займёт примерно день. Ага, я должен дать оценку в часах. Что ж, значит шесть часов".
• Две разных единицы измерения вводят в заблуждение. "Это оценка в человеко-днях или человеко-часах?"
Поэтому мы используем человеко-дни в качестве основной единицы при оценке времени (мы называем их story point'ами). Наше наименьшее значение – 0.5. Т.е. любые задачи, оцененные менее чем в 0.5, либо удаляются, либо комбинируются с другими, либо оценка остаётся 0.5 (ничего страшного в слегка завышенной оценке нет). Изящно и просто.
Наиболее важная вещь в отношении ретроспектив – это их проведение
Хотя основной формат немного варьируется, но в основном мы делаем так:
• Выделяем 1-3 часа, в зависимости от того насколько долгая ожидается дискуссия.
• Участвуют: product owner, вся команда и я собственной персоной.
• Располагаемся либо в отдельной комнате с уютным мягким уголком, либо на террасе, либо в каком-то другом похожем месте, поскольку нам нравится вести дискуссию в спокойной и непринуждённой атмосфере.
• Зачастую мы стараемся не проводить ретроспективы в рабочей комнате, так как это рассеивает внимание участников.
• Выбираем кого-то в качестве секретаря.
• ScrumMaster показывает sprint backlog и при участии команды подводит итоги спринта. Важные события, выводы и т.д.
• Начинаем "серию" обсуждений. В этот момент каждый имеет шанс высказаться о том, что, по его мнению, было хорошего, что можно было бы улучшить и что бы он сделал по-другому в следующем спринте. При этом его никто не перебивает.
• Мы сравниваем прогнозируемую и реальную производительность. Если имеются существенные расхождения, то пытаемся проанализировать и понять, почему так получилось.
• Когда время подходит к концу, ScrumMaster пытается обобщить все конкретные предложения по поводу того, что мы можем улучшить в следующем спринте.
Вообще-то, наши ретроспективы не имеют чёткого плана проведения, но главная тема – всегда одна и та же: "Что мы можем улучшить в следующем спринте".
Имейте в виду, что каждое изменение имеет свою цену, поэтому перед тем как его внедрять, подумайте, может, стоит ничего не делать вообще и надеяться, что проблема станет меньше или исчезнет совсем.
Комментариев нет:
Отправить комментарий