За годы участия в разработке ПО, я вывел для себя 3 правила, пересечение которых дает нужный результат: Делать правильные вещи правильно и быстро. Любопытно взглянуть, как Scrum нам помогает достигать эти цели?
Правильные вещи — скраму вообще пофиг, делается ли правильная вещь. Формирование backlog отдается на откуп продукт оунеру. Команде разработчиков по большому счету пофиг, делают они правильные вещи или нет. Есть козел отпущения — продукт оунер. С него и весь спрос. Продукт оунер превращается в монументальную фигуру, которая должна знать о пользователях все, знать о рынке все, знать о трендах все, вообще знать дофига всего чтобы единолично решить, какой продукт делать.
Более того, внимание, цитата
По большому счету, успех всего продукта строится на продукт оунере. Если у него будет фейл, не так уж важно, какие крутые бобры были в команде и какой крутой тест coverage на проекте.
Вещи правильно — скраму вообще пофиг, как что делается. Это отдается на откуп команде. Главное чтобы команда собиралась и обсуждала, что такое правильно и как вообще нам делать вещи правильнее. Как команда это делает — скраму абсолютно все равно. Скрам предполагает, что команда достаточно крута, чтобы улучшать свой процесс. К сожалению, это не всегда так. К примеру, команда без опытных разработчиков вряд ли сможет быстро разобраться, что такое хорошо, а что такое плохо.
Быстро — скраму вообще пофиг, делаются ли вещи быстро. Как команда может — так и делает. Может быстро — замечательно. Не может — давайте соберемся и поговорим, как можно исправить ситуацию. Для этого у нас имеются ретроспективы.
Хоть что-то хорошее — на самом деле Scrum все же дает кое-что, он ускоряет обратную связь и настоятельно рекомендует создавать кросс-функциональные команды. Для менеджера, который ждал результат проекта год, увидеть работающую версию с ограниченным функционалом через 3 месяца похоже на чудо. Ему стало возможно потыкать кнопочки и сказать, что вот здесь система ведет себя неожиданно. Ему стало возможно влиять на дальнейшую разработку и выбирать фичи по приоритетам. Сокращение петли обратной связи по большому счету единственное полезное, что однозначно дает Scrum. Все остальное идет непосредственно от Scrum-тренеров, от их личного опыта и видения процесса разработки ПО.
Благодаря внешней простоте процесса, Scrum показался очень привлекательным для многих управленцев. Но для неопытной команды без внешних консультантов улучшить свой процесс на основе Scrum достаточно сложно. Это трудоемкий и долгий процесс, который может занять годы.
Scrum сам по себе не является сильной инновацией. Ему просто повезло. Экстремальное программирование содержит практически те же вещи, но не получило такой популярности. Scrum коммерциализовался и ему удалось с помощью маркетинга стать методологией номер 1 в agile мире. Тем не менее, он служит неплохим базисом для развития и построения собственных процессов. При определенной доработке напильником (а скорее тюнинге) Scrum можно превратить в годный процесс разработки.
Правильные вещи — скраму вообще пофиг, делается ли правильная вещь. Формирование backlog отдается на откуп продукт оунеру. Команде разработчиков по большому счету пофиг, делают они правильные вещи или нет. Есть козел отпущения — продукт оунер. С него и весь спрос. Продукт оунер превращается в монументальную фигуру, которая должна знать о пользователях все, знать о рынке все, знать о трендах все, вообще знать дофига всего чтобы единолично решить, какой продукт делать.
Более того, внимание, цитата
The Product Owner is not part of the team
По большому счету, успех всего продукта строится на продукт оунере. Если у него будет фейл, не так уж важно, какие крутые бобры были в команде и какой крутой тест coverage на проекте.
Вещи правильно — скраму вообще пофиг, как что делается. Это отдается на откуп команде. Главное чтобы команда собиралась и обсуждала, что такое правильно и как вообще нам делать вещи правильнее. Как команда это делает — скраму абсолютно все равно. Скрам предполагает, что команда достаточно крута, чтобы улучшать свой процесс. К сожалению, это не всегда так. К примеру, команда без опытных разработчиков вряд ли сможет быстро разобраться, что такое хорошо, а что такое плохо.
Быстро — скраму вообще пофиг, делаются ли вещи быстро. Как команда может — так и делает. Может быстро — замечательно. Не может — давайте соберемся и поговорим, как можно исправить ситуацию. Для этого у нас имеются ретроспективы.
Хоть что-то хорошее — на самом деле Scrum все же дает кое-что, он ускоряет обратную связь и настоятельно рекомендует создавать кросс-функциональные команды. Для менеджера, который ждал результат проекта год, увидеть работающую версию с ограниченным функционалом через 3 месяца похоже на чудо. Ему стало возможно потыкать кнопочки и сказать, что вот здесь система ведет себя неожиданно. Ему стало возможно влиять на дальнейшую разработку и выбирать фичи по приоритетам. Сокращение петли обратной связи по большому счету единственное полезное, что однозначно дает Scrum. Все остальное идет непосредственно от Scrum-тренеров, от их личного опыта и видения процесса разработки ПО.
Благодаря внешней простоте процесса, Scrum показался очень привлекательным для многих управленцев. Но для неопытной команды без внешних консультантов улучшить свой процесс на основе Scrum достаточно сложно. Это трудоемкий и долгий процесс, который может занять годы.
Scrum сам по себе не является сильной инновацией. Ему просто повезло. Экстремальное программирование содержит практически те же вещи, но не получило такой популярности. Scrum коммерциализовался и ему удалось с помощью маркетинга стать методологией номер 1 в agile мире. Тем не менее, он служит неплохим базисом для развития и построения собственных процессов. При определенной доработке напильником (а скорее тюнинге) Scrum можно превратить в годный процесс разработки.
