
Онлайн книга «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban»
Критерии принятия
Самый быстрый способ для команды разработки начать работу не так – это не до конца разобраться в требованиях. Явное недопонимание – самая большая проблема, но, как правило, с нею разбираются быстро во время сеансов доработки журнала. Однако неявные недоразумения встречаются куда чаще; и так как они накапливаются, то могут выясниться на поздних этапах работы. Простейший способ избежать этого – совместно определить критерии принятия заранее; создать совместное представление того, как Владелец продукта будет судить о том, что выпуск продукта соответствует его видению. Это должно быть сделано не только на макроуровне (каждый спринт), но и для каждого требования (например, каждая пользовательская история). Лучший способ избежать проблем – определить всей командой эти критерии принятия. Есть много вариантов, как это сделать, но, если у вас возникают проблемы, можно просто ответить на вопрос: я знаю, что я получу <что-то>, когда <что-то сделано>. Это «что-то» оказывает ощутимое влияние, а «что-то сделанное» может быть положительным или отрицательным. Используйте это для прогнозирования того, что скажет о продукте Владелец продукта, когда вы предоставите ему результат. Начинайте сначала. Типы критериев успеха могут включать в себя: • простое описание желаемого результата; • ключевые тезисы; • условия принятия работы; • стиль языка Gherkin [1] в формате «Дано», «Если», «То». Блистательный пример Очень заманчиво начать спринт на оптимистичной ноте, пообещав себе, что вы все сделаете как надо, только чуть позже. Иногда в начале спринта энтузиазм перевешивает здравый смысл. Само собой, как же можно занудствовать, когда намечается что-то новое и интересное, – почему бы попросту не надеяться на лучшее? А потом неизбежно что-то случается – и неизвестно, как плохо все будет складываться потом. Некоторые команды могут так и не оправиться после неправильного старта. Первая неудача в выпуске продукта может безвозвратно подорвать доверие, особенно если ожидания были высоки. Неверное начало может повлечь неудачи и во втором спринте, вовлекая вас в замкнутый круг. Проблемы и так возникнут – поэтому не игнорируйте хорошие советы и не увеличивайте шансы на возникновение неудач с самого начала. Приоритезация в действии
При определении очередности нет необходимости излишне углубляться в детали. Это не Олимпиада, где разница между первым, вторым и третьим местом имеет значение, а четвертое может означать, что поездка сюда была впустую потраченным временем. Неважно, будет ли пользовательская история первой в списке, когда спринт начинается; все, что имеет значение – входит она в спринт или нет? Или, точнее, включена в этот выпуск продукта или нет. Поскольку спринты относительно короткие, это больше похоже на ожидание автобуса. Скоро будет следующий. Это уменьшает давление, и нет необходимости бесконечно мучительно расставлять приоритеты. Владельцу продукта придется просто подождать еще две недели – или какой будет согласована стандартная длина спринта – до следующего выпуска продукта. Не нужно нервничать. Лучшее – враг хорошего. Вольтер Оценивание в действии
Очень важно, чтобы каждый элемент в журнале имел шанс попасть в следующий спринт – поэтому проводится приблизительное оценивание затрат на практическую реализацию. Не очень хорошо, когда оценки просто не могут быть согласованы по одной или нескольким причинам. Плохо, когда команда не может определиться с задачами на следующий спринт, но если члены команды никак не сойдутся в оценке задач, это может указывать на более фундаментальные проблемы: • Неясные требования: расплывчатые пользовательские истории сложно оценить и, что куда более важно, сложно реализовать. Получите разъяснения. • Слишком большая и сложная задача: если часть работы требует для реализации больше, чем несколько дней, сроки выпуска продукта станут излишне неопределенными. Разбейте задачу на части! Кроме того, требования к таким объемам работы обычно менее понятны. • Неверно определенные критерии принятия: если пункт назначения неясен, трудно измерить, сколько времени потребуется, чтобы попасть туда. Даже с четкими критериями принятия кому-то может показаться, что эта часть работы огромна, в то время как другие решат, что она совсем невелика. Оценка должна быть коллективной. Тут надо повторить в очередной раз: разговаривайте друг с другом. Разношерстная группа людей, обсуждающих проблему со всех сторон, снимет завесу таинственности со всех ее аспектов и определит, что нужно для выпуска продукта. Этот процесс не нужно доводить до совершенства; вполне достаточно обозначить широкими мазками самое главное. Мы уже рекомендовали в качестве оценочной техники размеры одежды и оценочные подходы, но, возможно, новичкам проще будет использовать для оценки затрат времени старые добрые минуты, часы и дни. По опыту, приноровившись к Скраму, вчерашние новички впоследствии выбирают какую-то другую оценочную технику. Прежде чем углубиться в спринт и его проблемы, нет необходимости в многочисленных проверках. Главное, убедитесь в трех вещах: 1. Задачи в журнале распределены по порядку их выполнения, и журнал согласован с владельцем продукта. 2. Критерии принятия (по крайней мере, некоторые из них) написаны совместно с командой. 3. Все пользовательские истории оценены. Блистательный пример ![]() Блистательное определение В случае оценочного подхода один из наилучших вариантов – повышать баллы в соответствии с последовательностью чисел Фибоначчи: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 100… Все на меньшем конце последовательности будет означать задачу с наименьшими трудозатратами, и по возрастающей до самых объемных задач в конце. Такой метод прекрасно работает со многими Скрам-техниками, особенно с использованием для планирования покерных карт [2]. |