На встрече в AgileRussia мы в прошлый раз обсуждали тему Kanban vs Scrum. В числе прочего мы получили список случаев, где "scrum не работает". Этот результат сам по себе интересный, поэтому я решил описать его в блоге. Прошу заметить, что я ни в коем случае не претендую на авторство. Создатели - участники встречи AgileRussia. Я просто все записал и кое-где постарался пояснить поподробнее и без шуточек :-)
Это первая часть. Вторая половина случаев в следующем посте
Команда поддержки
Проблема.
Команда поддержки системы. Задачи возникают спонтанно, исправлять надо быстро. Крупные задачи соседствуют с мелкими. Сформировать объем работ на итерацию очень трудно.
Scrum
Вариант №1. Размер итерации сокращается до 1 дня и иногда даже меньше. Крупные задачи декомпозируются.
Вариант №2. На доске задач появляется "фича" "срочные баги". Эта фича имеет высокий приоритет и даже оценку. Впрочем, это скорее бюджет, чем оценка, то есть количество времени, которое мы готовы выделить в итерации на работу со срочными задачами. Давайте возьмем, для примера, бюджет в 30 часов. Срочные баги оцениваются и "прикрепляются" к этой фиче. Их можно подцеплять до тех пор, пока не кончится выделенный на них бюджет в 30 часов. Если он превышен, идем к PO и просим выкинуть низкоприоритеную задачу из итерации. На ретроспективе можно скорректировать бюджет на следующую итерацию.
Канбан
Осложняется наличием "больших" и "маленьких" фич в разработке. Пример: WIP = 2 фичам, то есть одновременно в разработку можно поставить не более 2 фич. Допустим, (так получилось) мы работаем над более или менее крупными фичами, трудоемкостью в несколько дней. Тогда никакую другую фичу поставить в разработку нельзя, не нарушив ограничение на WIP. А задачи по саппорту, как правило, достаточно срочные, это может быть проблемой.
Вариант №1. В этом случае можно поставить ограничение WIP = "2, ну максимум 3" :-). Либо WIP = 2 для больших и 2 для маленьких. Правда, в этом случае придется оценивать фичи хотя бы по порядку величины.
Вариант №2. Делать работу в 2 потока. Один их них для мелких багов, второй для крупных. Баги имеют более высокий приоритет.
Вариант №3. "Если вам так важно, возьмите задачу, сделайте и успокойтесь"(с)
Низкая кроссфункциональность, низкая самоорганизация, распределенная разработка
Проблема.
Низкая взаимозаменяемость разработчиков мешает делать фичи в порядке
приоритета внутри итерации. У каждого разработчика образуется пул "личных" задач. В итоге, к концу итерации, как правило, куча недоделанной работы. Работа по тестированию фич скатывается к концу итерации. Нагрузка на тестировщиков высокая, что приводит к низкому качеству результата. Производительность такой команды слабо прогнозируется.
Scrum
Постепенно повышать взаимозаменяемость людей в команде. Решать проблему низкой кроссфункцинальности.
Канбан
Сам подход не требует самоорганизации от команды. Однако, в некоторой степени, он будет ей способствовать. Допустим у нас есть 2 программиста. Допустим, они сделали отведенные им фичи (WIP) и остались без работы. Если в этот момент времени кто-то застрял (например, тестировщики), программисты должны пойти и помочь товарищам. Это, безусловно, повышает взаимозаменяемость.
С другой стороны, безусловно, есть соблазн "еще немного поработать над фичей", так как "время-то еще есть, тестеры еще не готовы взять наши фичи."
Проблема до какой-то степени снимается в следующем случае. Допустим, у вас распределенная команда и вам необязательно полностью загружать их работой. Например, если ваш дизайнер - фрилансер и он сидит в Казани, ему совершенно необязательно бежать к программистам в Минск помогать решать проблему, которая его задерживает. В этот момент он может совершенно спокойно заняться стороними проектами с другими заказчиками, коих у него, как у фрилансера, наверняка много. Нас это, по идее, не должно слишком пугать, потому что мы оплачиваем ему работу только по задачам, которые он делает для нас.
Маленькая команда
Проблема
Команда размером в 2 человека и меньше не является командой в полноценном смысле. Перестает работать закон больших чисел. Этот закон позволял при довольно серьезных промахах в оценках каждой из задач довольно неплохо (как правило) угадывать план на итерацию за счет их большого количества.
Scrum
Scrum просто уменьшается в этом случае до комфортного уровня. Например, часто отменяются daily scrum. Иногда не рисуют burndown chart. И т.д. Формально, это уже не Scrum
Kanban
Удобен в том смысле, что вам можно отменить меньше практик :-)
Несинхронный Deployment
Проблема
Иногда по каким-то бизнес соображениям deploy должен происходить не в конце итерации, а по каким-то иным законам. Например, во внутренней разработке деплой и внедрение часто привязаны к запуску новых бизнес-процессов. Дата может определяться исходя из потребностей других подразделений компании.
Scrum
Внутри Scrum появляются задачи типа "выполнить deploy" с указанной датой. То есть, вообще говоря, дата деплоя не всегда на 100% привязана к дате окончания итерации.
Канбан
Деплой происходит тогда, когда вы считаете нужным это сделать. Не нужно ожидать конца итерации. Правда, само по себе это проблему решает не всегда. Канбан никак не предполагает оценку работ, а для синхронизации работ с другими отделами необходимо знать дату окончания работ.
Research and Development
Проблема
Поставить цели и критерии окончания и дать оценку трудозатрат невозможно. Например, типичный R&D проект - разработать несуществующую еще технологию или новый алгоритм расчета. как правило, в этом случае вообще неизвестно, имеет ли задача решение. Провести оценку и сформировать scope итерации очень трудно.
Scrum
Надо признаться, Scrum эту проблему решает не то чтобы хорошо. В общем, подход выглядит так. В любой задаче (даже самой иновационной и сложной) есть фаза анализа, в течение которой мы генерим набор идей по ее решению. На следующей фазе мы будем пробовать и проверять самые перспективные идеи. После проверки наш список идей уменьшится и уточнится. Далее мы опять сможем засесть за генерацию идей. Например, нужно разработать модуль, решающий определенную математическую задачу. Команда генерит альтернативы решений, начиная от линейных аппроксимаций, которые можно попробовать "на коленке", заканчивая разработкой собственных подходов и разделов математики.
Мы можем попробовать начать с простых вариантов и проверить, достаточно ли они хороши для нас. Получается, что некоторые задачи довольно четко определенны (например, реализация линейной оптимизации). С прочими задачами действительно проблема. Как вы оцените задачу "Поковырять в сторону марковских цепей"?. В итерацию оцениваются и ставятся все задачи по реализации и проверке идей. Все неопределенные задачи также ставятся в итерацию, но оценка точно не проводится. Как правило, они получают "бюджет", то есть количество времени, которое Product Owner готов потратить на решение задачи без промежуточного результата. Что-то типа "Ребята, я готов потерять на это не более 3ех дней". В целом, Scrum неплохо справляется с проектами, где R&D задачи соседствуют с опреденными.
Канбан
Подход канбан не требует оценки работ, так что проблема снимается. Ограничение на Work In Progress заставляет команду сосредоточиться на командной работе по решению задач. Это ускоряет работу, так как команды, как правило, лучше справляются с сложными задачами, чем индивидуалы. Кроме того, визуализация процесса позволит команде эффективнее синхронизировать свою работу и упростить планирование. Итак, канбан лучше подходит для чистых R&D проектов.
В следующем посте:
- Нет одного PO
- Разработка ПО одновременно с железом
- Авралы
- Расслабление команды
- Технологическая цепочка
- Крупные задачи, быстро меняющийся scope
- Мелкие и крупные задачи
- Артимия (демо, ретро, планирование)
- PO - узкое место
