Scrum vs Kanban в reg.ru
Пораскинул мозгами и склоняюсь к тому, что нам в REG.RU таки не нужен scrum, а нужен Kanban.
Scrum, как я понимаю, больше подходит в следующей ситуации:
1. Относительно небольшая команда, максимум 7 человек.
Сейчас у нас людей в 2 раза больше. Искусственно дробить их на
команды, например "новые разработки" и "поддержка" можно, но
а) дополнительные усилия на разбиение, кто с кем будет, какие задачи
будет выполнять каждая команда и т.п;
б) те кто останутся на "поддержке" будут себя чувствовать более
ущемлёнными; чтобы компенсировать это, надо будет как-то периодически
ротировать людей и т.п.
2. Команда кроссфункциональная. Задачи ставятся команде в целом.
По факту сейчас это не так. Только небольшое число людей более или
менее представляют себе систему целиком. По факту около половины задач
так или иначе относится к конкретным людям, которые отвечают за ту или
иную часть системы.
Конечно мы хотим / будем двигаться к тому, чтобы люди были знакомы с
разными частями системы. В частности будем дальше внедрять code
review, чтобы люди были знакомы с чужим кодом и с "чужими" частями
системы.
3. Большой объём НОВЫХ и НЕСРОЧНЫХ разработок, которые можно запланировать.
Как следствие, наличие оценки, планирования, приоритезации, итераций.
У нас своя специфика: много срочных задач (в частности, срочные
багфиксы) + высокая скорость бизнеса и бизнес-нововведений. Задачи
нужно вводить в production быстро, сразу как только они готовы. В
связи с этим понятия "итерация" и "демонстрация (в конце итерации)"
для нас являются искусственными и обременительными. Ждать конца недели
чтобы кому-то что-то "продемонстрировать" -- непозволительная роскошь.
У нас относительно мало, я бы даже сказал исчезающе мало "больших"
задач, которые, как я вижу, хорошо ложатся на scrum-процесс. Это,
например, "магазин доменов" или "аукцион доменов", задачи на несколько
месяцев. Но это скорее исключение чем правило.
Для таких задач действительно можно / нужно на время выполнения
подпроекта создавать микрокоманды (2, максимум 3 человека), которые
будут решать конкретную задачу.
Для основного потока задач жёсткая приоритезация всего списка задач,
декомпозиция и оценка задач, итерации, планирование итерации,
демонстрация являются искусственными, притянутыми за уши и создающими
только дополнительные накладные расходы.
Т.е. scrum, как я вижу, подходит в ситуации, когда есть большая
задача, от которой всей командой отламываются кусочки, оцениваются, и
решаются сообща.
Такого "монолита" у нас НЕТ -- есть разнородный, слабосвязанный поток задач.
Взаимодействие разработчиков для выполнения задач нужно только если
что-то непонятно как оно устроено, "посоветоваться" и т.п. Т.е.
фактически задачи решаются в одиночку, взаимодействие только в случае
необходимости точечных консультаций / code review.
4. Требования и приоритеты не меняются в пределах итерации.
У нас это не так. В любое время могут появляться срочные
незапланированные задачи.
На scrum это, как я понимаю, ложиться слегка болезненно -- нужно всей
командой перепланировать итерацию.
Т.е. я вижу Kanban как процесс более приспособленный к управляемому
хаосу, нежели scrum. Т.е. ещё более "гибкий". Само понятие итерации в
scrum задаёт некую структуру и некие рамки, которых нужно
придерживаться. Поэтому вместо того чтобы "бороться" с изменениями в
итерации, воспринимать их как нежелательный фактор, можно просто
принять процесс максимально адаптированный к хаосу.
Т.е. как в XP, вместо того чтобы "бороться" с хаосом, мы "отдаёмся"
ему, полностью принимаем его и учимся жить с ним:
http://codingrus.ru/readarticle.php?article_id=942
5. Наличие единого product-owner, который в курсе всех задач проекта, принимает их и приоритезирует.
На данный момент в команде такого человека нет и на существующих людей не представляется возможным "повесить" такой функционал. Задач много, из ставят разные люди и их контролируют. Если есть необходимость согласовать задачи, они согласовываются между менеджерами, но чтобы кто-то один всё "держал в голове" и контролировал -- это на данный момент утопично. Можно сделать как бы несколько product-owner-ов, над которыми будет "главный owner", но это предполагает опять же дробление на разные команды, т.к. у одной команды не может быть более одного product owner.
Это сделать можно, но возникают опять же вопросы:
- как дробить на команды?
- как дробить задачи пул задач между разными product owner? Это всё один большой проект.
В случае kanban как я понимаю острота этого вопроса сглаживается. Конечно, всё равно нужно как-то приоритезировать пул задач, но это можно сделать "примерно", просто выставив приоритеты "срочный", "обычный", "низкий", что гораздо проще полной и чёткой сортировки списка из сотен задач. Именно так и делается сейчас. Просто сейчас нет инструментов для того чтобы задачи брались из пула в порядке приоритетов, процесс назначения задач несколько хаотичен. Если правильно подогнать инструменты и оговорить процесс "вытаскивания" задач для постановки в работу, думаю, это сильно повысит прозрачность назначения задач.
* * *
Таким образом, основные понятия / артефакты scrum, такие как итерация,
демонстрация, планирование итерации, приоритезированный backlog, product owner можно
притянуть к нам за уши, но это, на мой взгляд, будет неэффективно.
А если использовать практики scrum частично, фрагментарно, то это
будет не scrum, а непонятно что. Эффекта не будет. Именно это и
происходит сейчас.
В частности, ежедневные scrum-митинги, фактически вырождаются в "отчёт
о проделанной работе за день", в результате:
- люди в основном не слушают друг друга, ибо разработчиками решаются,
разные, слабо связанные друг с другом задачи и нет мотивации друг
друга слушать: это неинтересно и никак не связано с "моей" работой,
- поскольку фокус митинга смещён с обсуждения общего "фронта работ"
(которого фактически нет) на "отчёт о проделанной работе за день", в
результате разработчики делятся на две фракции:
а) те, кому психологически не комфортно "отчитываться" в подобном
ключе, доказывать что "я не валял дурака вчера",
б) те, кто чтобы показать что "что-то делал" выдаёт много лишней,
никому не нужной информации, типа "обновлял систему", "чинил интернет
в офисе", "помогал техподдержке" и т. п., что совершенно неинтересно
слушать.
Таким образом, вырванная из контекста практика "scrum-meeting" без
выполнения всех условий scrum-процесса, не только не даёт никакого
эффекта, но только создаёт дискомфорт.
А применить весь набор практик, чтобы получить синергетический эффект,
не представляется возможным в силу специфика проекта, команды и задач.
* * *
В связи с этим, считаю, что за основу стоит взять другой процесс.
В частности, процесс Kanban -- это фактически то, как мы работает сейчас.
Нужно только немного "допилить" процесс, чтобы был настоящий Kanban, в
результате без насилия над собой и командой получим работающий
процесс.
Фактически нужно просто внедрить Kanban-доску, что позволит сделать
весь производственный процесс совершенно прозрачным:
- виден объём задач на входе, легко выбрать очередную задачу для
взятия в работу,
- видно какие задачи в работе и кому они назначены,
- можно внедрить дополнительные колонки на доске под наши нужны,
например: "написание / прогон автотестов", "в review", "в
тестировании", что мы и намерены сделать (намерены создать отдел
тестирования и уже движемся в данном направлении, а также более широко
внедрять практику code review);
- за счёт того, что присутствуют дополнительные колонки, призванные
улучшить качество ("в review", "в тестировании"), автоматически, легко
и естественно мы улучшаем процесс контроля качества -- задача не
продвинется в следующую колонку пока не прошла предыдущую;
- наличие kanban-доски позволит лучше организовать взаимодействие
между разработчиками и QA: другие разработчики всегда видят список
задач которые нужно поревьюить и могут выбрать что-то для review,
тестировщики также видят что в очереди на тестирование;
Таким образом попутно легко добавляем две полезные практики:
- code review,
- приёмочное / usability тестирование.
Если добавить сюда ещё инженерные практики: довести до ума модульные
тесты, запустить сервер для непрерывного тестирования, запускать в
автоматическим режиме selenium-тесты для сайта, то вообще будет
счастье.
* * *
Prooflinks:
http://lib.custis.ru/Kanban_vs_Scrum_%E2%80%93_%D1%87%D1%8C%D1%91_%D0%BA%D1%83%D0%BD%D0%B3-%D1%84%D1%83_%D1%81%D0%B8%D0%BB%D1%8C%D0%BD%D0%B5%D0%B5_(%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB_%D0%9A%D0%BB%D0%B8%D0%BC%D0%BE%D0%B2,_AgileDays-2011)
http://devconf.ru/offers/47
UPD:
Обзор Kanban досок:
http://www.itaddict.ru/2011/04/kanban.html
Также есть kanban-примочка к mantis:
http://forrst.com/posts/1LF/original
Scrum, как я понимаю, больше подходит в следующей ситуации:
1. Относительно небольшая команда, максимум 7 человек.
Сейчас у нас людей в 2 раза больше. Искусственно дробить их на
команды, например "новые разработки" и "поддержка" можно, но
а) дополнительные усилия на разбиение, кто с кем будет, какие задачи
будет выполнять каждая команда и т.п;
б) те кто останутся на "поддержке" будут себя чувствовать более
ущемлёнными; чтобы компенсировать это, надо будет как-то периодически
ротировать людей и т.п.
2. Команда кроссфункциональная. Задачи ставятся команде в целом.
По факту сейчас это не так. Только небольшое число людей более или
менее представляют себе систему целиком. По факту около половины задач
так или иначе относится к конкретным людям, которые отвечают за ту или
иную часть системы.
Конечно мы хотим / будем двигаться к тому, чтобы люди были знакомы с
разными частями системы. В частности будем дальше внедрять code
review, чтобы люди были знакомы с чужим кодом и с "чужими" частями
системы.
3. Большой объём НОВЫХ и НЕСРОЧНЫХ разработок, которые можно запланировать.
Как следствие, наличие оценки, планирования, приоритезации, итераций.
У нас своя специфика: много срочных задач (в частности, срочные
багфиксы) + высокая скорость бизнеса и бизнес-нововведений. Задачи
нужно вводить в production быстро, сразу как только они готовы. В
связи с этим понятия "итерация" и "демонстрация (в конце итерации)"
для нас являются искусственными и обременительными. Ждать конца недели
чтобы кому-то что-то "продемонстрировать" -- непозволительная роскошь.
У нас относительно мало, я бы даже сказал исчезающе мало "больших"
задач, которые, как я вижу, хорошо ложатся на scrum-процесс. Это,
например, "магазин доменов" или "аукцион доменов", задачи на несколько
месяцев. Но это скорее исключение чем правило.
Для таких задач действительно можно / нужно на время выполнения
подпроекта создавать микрокоманды (2, максимум 3 человека), которые
будут решать конкретную задачу.
Для основного потока задач жёсткая приоритезация всего списка задач,
декомпозиция и оценка задач, итерации, планирование итерации,
демонстрация являются искусственными, притянутыми за уши и создающими
только дополнительные накладные расходы.
Т.е. scrum, как я вижу, подходит в ситуации, когда есть большая
задача, от которой всей командой отламываются кусочки, оцениваются, и
решаются сообща.
Такого "монолита" у нас НЕТ -- есть разнородный, слабосвязанный поток задач.
Взаимодействие разработчиков для выполнения задач нужно только если
что-то непонятно как оно устроено, "посоветоваться" и т.п. Т.е.
фактически задачи решаются в одиночку, взаимодействие только в случае
необходимости точечных консультаций / code review.
4. Требования и приоритеты не меняются в пределах итерации.
У нас это не так. В любое время могут появляться срочные
незапланированные задачи.
На scrum это, как я понимаю, ложиться слегка болезненно -- нужно всей
командой перепланировать итерацию.
Т.е. я вижу Kanban как процесс более приспособленный к управляемому
хаосу, нежели scrum. Т.е. ещё более "гибкий". Само понятие итерации в
scrum задаёт некую структуру и некие рамки, которых нужно
придерживаться. Поэтому вместо того чтобы "бороться" с изменениями в
итерации, воспринимать их как нежелательный фактор, можно просто
принять процесс максимально адаптированный к хаосу.
Т.е. как в XP, вместо того чтобы "бороться" с хаосом, мы "отдаёмся"
ему, полностью принимаем его и учимся жить с ним:
http://codingrus.ru/readarticle.php?article_id=942
5. Наличие единого product-owner, который в курсе всех задач проекта, принимает их и приоритезирует.
На данный момент в команде такого человека нет и на существующих людей не представляется возможным "повесить" такой функционал. Задач много, из ставят разные люди и их контролируют. Если есть необходимость согласовать задачи, они согласовываются между менеджерами, но чтобы кто-то один всё "держал в голове" и контролировал -- это на данный момент утопично. Можно сделать как бы несколько product-owner-ов, над которыми будет "главный owner", но это предполагает опять же дробление на разные команды, т.к. у одной команды не может быть более одного product owner.
Это сделать можно, но возникают опять же вопросы:
- как дробить на команды?
- как дробить задачи пул задач между разными product owner? Это всё один большой проект.
В случае kanban как я понимаю острота этого вопроса сглаживается. Конечно, всё равно нужно как-то приоритезировать пул задач, но это можно сделать "примерно", просто выставив приоритеты "срочный", "обычный", "низкий", что гораздо проще полной и чёткой сортировки списка из сотен задач. Именно так и делается сейчас. Просто сейчас нет инструментов для того чтобы задачи брались из пула в порядке приоритетов, процесс назначения задач несколько хаотичен. Если правильно подогнать инструменты и оговорить процесс "вытаскивания" задач для постановки в работу, думаю, это сильно повысит прозрачность назначения задач.
* * *
Таким образом, основные понятия / артефакты scrum, такие как итерация,
демонстрация, планирование итерации, приоритезированный backlog, product owner можно
притянуть к нам за уши, но это, на мой взгляд, будет неэффективно.
А если использовать практики scrum частично, фрагментарно, то это
будет не scrum, а непонятно что. Эффекта не будет. Именно это и
происходит сейчас.
В частности, ежедневные scrum-митинги, фактически вырождаются в "отчёт
о проделанной работе за день", в результате:
- люди в основном не слушают друг друга, ибо разработчиками решаются,
разные, слабо связанные друг с другом задачи и нет мотивации друг
друга слушать: это неинтересно и никак не связано с "моей" работой,
- поскольку фокус митинга смещён с обсуждения общего "фронта работ"
(которого фактически нет) на "отчёт о проделанной работе за день", в
результате разработчики делятся на две фракции:
а) те, кому психологически не комфортно "отчитываться" в подобном
ключе, доказывать что "я не валял дурака вчера",
б) те, кто чтобы показать что "что-то делал" выдаёт много лишней,
никому не нужной информации, типа "обновлял систему", "чинил интернет
в офисе", "помогал техподдержке" и т. п., что совершенно неинтересно
слушать.
Таким образом, вырванная из контекста практика "scrum-meeting" без
выполнения всех условий scrum-процесса, не только не даёт никакого
эффекта, но только создаёт дискомфорт.
А применить весь набор практик, чтобы получить синергетический эффект,
не представляется возможным в силу специфика проекта, команды и задач.
* * *
В связи с этим, считаю, что за основу стоит взять другой процесс.
В частности, процесс Kanban -- это фактически то, как мы работает сейчас.
Нужно только немного "допилить" процесс, чтобы был настоящий Kanban, в
результате без насилия над собой и командой получим работающий
процесс.
Фактически нужно просто внедрить Kanban-доску, что позволит сделать
весь производственный процесс совершенно прозрачным:
- виден объём задач на входе, легко выбрать очередную задачу для
взятия в работу,
- видно какие задачи в работе и кому они назначены,
- можно внедрить дополнительные колонки на доске под наши нужны,
например: "написание / прогон автотестов", "в review", "в
тестировании", что мы и намерены сделать (намерены создать отдел
тестирования и уже движемся в данном направлении, а также более широко
внедрять практику code review);
- за счёт того, что присутствуют дополнительные колонки, призванные
улучшить качество ("в review", "в тестировании"), автоматически, легко
и естественно мы улучшаем процесс контроля качества -- задача не
продвинется в следующую колонку пока не прошла предыдущую;
- наличие kanban-доски позволит лучше организовать взаимодействие
между разработчиками и QA: другие разработчики всегда видят список
задач которые нужно поревьюить и могут выбрать что-то для review,
тестировщики также видят что в очереди на тестирование;
Таким образом попутно легко добавляем две полезные практики:
- code review,
- приёмочное / usability тестирование.
Если добавить сюда ещё инженерные практики: довести до ума модульные
тесты, запустить сервер для непрерывного тестирования, запускать в
автоматическим режиме selenium-тесты для сайта, то вообще будет
счастье.
* * *
Prooflinks:
http://lib.custis.ru/Kanban_vs_Scrum_%E2%80%93_%D1%87%D1%8C%D1%91_%D0%BA%D1%83%D0%BD%D0%B3-%D1%84%D1%83_%D1%81%D0%B8%D0%BB%D1%8C%D0%BD%D0%B5%D0%B5_(%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB_%D0%9A%D0%BB%D0%B8%D0%BC%D0%BE%D0%B2,_AgileDays-2011)
http://devconf.ru/offers/47
UPD:
Обзор Kanban досок:
http://www.itaddict.ru/2011/04/kanban.html
Также есть kanban-примочка к mantis:
http://forrst.com/posts/1LF/original