Вариант ЛЁХА строится следующими шагами.
1. Забиваете на пункт из Скрам Гайда, который запрещает вам изменять Скрам. Если что, скажете потом - Лёха разрешил.
2. Разделяете команду на две части - в одну загоняете UXеров, дизайнеров и аналитиков (назовем ее кокетливо Discovery Team), в другую загоняете разработчиков, QA и аналитиков (назовем ее незамысловато Dev Team). Тут вы скажете - Лёха, проснись, ты уже не понимаешь, что сам пишешь - у тебя аналитики сидят и там, и там. Но нет: так надо, слушайте дальше.
Эти две подкоманды будут заниматься радикально разными вещами. Так, Discovery Team возьмет на себя исследовательскую работу, которая сопряжена с большой мерой неопределенности. Она возьмет идею фичи от менеджера и пойдет говорить с бизнесом, пользователями, раскапывать имеющиеся возможности, описывать решение и так далее. Dev Team же будет работать с уже очерченными (и отрисованными!) задачами, вышедшими из-под пера Discovery Team - будет брать в работу постановку и дальше делать свою черную девелоперскую магию.
3. При этом деление между командами должно быть весьма условным - аналитик будет в зависимости от ситуации востребован и там, и там, дизайнер должен быть готов придти на помощь разрабу, а разраб - помочь Discovery Team разобраться с техническими ограничениями новой задачи. Как правило, в такой конструкции больше всего рвет на части аналитиков (ну и продактов, но их и так постоянно рвет на части, служба такая).
4. Пытливый читатель, я думаю, обратил внимание, что Discovery Team и Dev Team отличаются друг от друга степенью рискованности своей работы. Если Discovery работает в режиме «пойди туда не знаю куда, принеси то не знаю что», то Dev Team, в идеале, работает с четко сформулированной задачей, которая, конечно же, может притаить в себе рискованную жопу (кому сейчас легко), но хотя бы на уровне базовых вводных шататься не будет. И в этом есть своя суровая крестьянская правда: разработчики как никто другой ценят определенность, четкость и однозначность, а дизайнеры и исследователи, по долгу работы, не должны пугаться лютой неопределенности.
5. Раз у нас есть две подкоманды с радикально разными ценностями - то и процессы мы им можем дать разные. Следите за руками:
⁃ Discovery Team, вся из себя неопределенная, может работать со своими задачами по Канбану - по сути, постоянному конвейеру задач (который идеально подходит для того, чтобы довести задачи до реализации максимально быстро, насколько позволит неопределенность);
⁃ Dev Team, вся из себя системная и четкая, может работать со своими задачами по Скраму (который идеально подходит для того, чтобы дать команде четкий фронт работ, спрогнозировать результат и не лезть к ним лишний раз с дурацкими изменениями).
6. Иными словами, мы выстраиваем глобальный процесс, при котором канбанный конвейер Discovery Team своим дальним концом упирается в Скрам Dev Team и служит для него постоянно работающим источником задач.
7. Выглядит все это примерно так:
1. Забиваете на пункт из Скрам Гайда, который запрещает вам изменять Скрам. Если что, скажете потом - Лёха разрешил.
2. Разделяете команду на две части - в одну загоняете UXеров, дизайнеров и аналитиков (назовем ее кокетливо Discovery Team), в другую загоняете разработчиков, QA и аналитиков (назовем ее незамысловато Dev Team). Тут вы скажете - Лёха, проснись, ты уже не понимаешь, что сам пишешь - у тебя аналитики сидят и там, и там. Но нет: так надо, слушайте дальше.
Эти две подкоманды будут заниматься радикально разными вещами. Так, Discovery Team возьмет на себя исследовательскую работу, которая сопряжена с большой мерой неопределенности. Она возьмет идею фичи от менеджера и пойдет говорить с бизнесом, пользователями, раскапывать имеющиеся возможности, описывать решение и так далее. Dev Team же будет работать с уже очерченными (и отрисованными!) задачами, вышедшими из-под пера Discovery Team - будет брать в работу постановку и дальше делать свою черную девелоперскую магию.
3. При этом деление между командами должно быть весьма условным - аналитик будет в зависимости от ситуации востребован и там, и там, дизайнер должен быть готов придти на помощь разрабу, а разраб - помочь Discovery Team разобраться с техническими ограничениями новой задачи. Как правило, в такой конструкции больше всего рвет на части аналитиков (ну и продактов, но их и так постоянно рвет на части, служба такая).
4. Пытливый читатель, я думаю, обратил внимание, что Discovery Team и Dev Team отличаются друг от друга степенью рискованности своей работы. Если Discovery работает в режиме «пойди туда не знаю куда, принеси то не знаю что», то Dev Team, в идеале, работает с четко сформулированной задачей, которая, конечно же, может притаить в себе рискованную жопу (кому сейчас легко), но хотя бы на уровне базовых вводных шататься не будет. И в этом есть своя суровая крестьянская правда: разработчики как никто другой ценят определенность, четкость и однозначность, а дизайнеры и исследователи, по долгу работы, не должны пугаться лютой неопределенности.
5. Раз у нас есть две подкоманды с радикально разными ценностями - то и процессы мы им можем дать разные. Следите за руками:
⁃ Discovery Team, вся из себя неопределенная, может работать со своими задачами по Канбану - по сути, постоянному конвейеру задач (который идеально подходит для того, чтобы довести задачи до реализации максимально быстро, насколько позволит неопределенность);
⁃ Dev Team, вся из себя системная и четкая, может работать со своими задачами по Скраму (который идеально подходит для того, чтобы дать команде четкий фронт работ, спрогнозировать результат и не лезть к ним лишний раз с дурацкими изменениями).
6. Иными словами, мы выстраиваем глобальный процесс, при котором канбанный конвейер Discovery Team своим дальним концом упирается в Скрам Dev Team и служит для него постоянно работающим источником задач.
7. Выглядит все это примерно так: