Про scrum написано много, но примеры реального применения встречаются не так часто. Некоторое время я занимался внедрением scrum в потоковой web-разработке, хотел бы поговорить на эту тему и поделиться своими мыслями.
Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.
Именно так может показаться измученному менеджеру/директору после первой встречи с описанием методологии после работы без четкой системы, или по водопадным методам. К таким методам приходишь либо сам, начиная работать, либо приводит традиционное управление проектами по PERT и CPM, преподаваемое сейчас во многих институтах на менеджерских и инженерных специальностях. Действительно, имея незамутненное и незамусоренное представление о строительстве сайтов, самое простое и понятное – распланировать по задачам и этапам, связать работы в цепочку и следить за тем, чтобы все начинали работать вовремя. Это без особых проблем может сработать на небольших и простых проектах, но на сколь-нибудь серьезных начинается знакомая многим история несоответствия результата ожиданиям заказчика, вечно доделанный на 98% функционал, пучок багов, всплывающий под релиз. Все это неприятно, а еще хотелось бы иметь какую-то более точную систему получения оценок по трудозатратам, а то ж время — деньги.
Тут приходит скрам и говорит, что мы делаем маленькие, но только законченные кусочки. Соответственно, и багфиксом управлять, и соответствовать ожиданиям заказчика без написания ТЗ и затянутых коммуникаций о будущем функционале становится проще. В качестве меры оценки появляется story point, за который вполне можно принять более или менее объективный идеальный человеко-час, тем самым обезопаситься и от Паркинсона, и от студента. Вроде бы и на стороне клиента все довольны — получают понятные штуки на небольшом промежутке времени, можно покрутить в руках, применить в деле и показать начальству. Головная боль любого менеджера – изменения в желаниях клиента с течением времени – превращается в интересную и полезную игру, позволяющую показать профессионализм, инновационность в методах работы и замечательное отличие от конкурентов. На заходящих проектах менеджер заявляет клиенту о новой супер технологии, для которой писать ТЗ не нужно, а любые требования в любой момент могут быть выполнены. Клиент радостно принимается заваливать своими идеями, в результате интересный и прибыльный проект постепенно загибается.
За формирование историй в product backlog'e отвечает product owner, соответственно, именно он решает, каким требованиям будет удовлетворять результат разработки. Именно поэтому product owner'ом должен быть менеджер на стороне разработчика. Информация о компаниях, действующих на российском рынке web разработки, применяющих scrum и отдающих роль product owner'a на сторону клиента, кажется мне подозрительной. Методология четко описывает product owner'a как человека, знающего своих пользователей, умеющего четко сформулировать цели своего бизнеса и переложить их в требования, а, значит, в определенной степени знакомого с технологиями разработки. Среднестатистический заказчик сайта не подходит под это описание, не готов нести ответственности за результат разработки, не хочет заморачиваться, а хочет чувствовать себя комфортно. Тонкости методологии ему особенно безразличны, если работа с подрядчиками и производство сайтов не входит в его профессиональные обязанности.
Зная о своих новых инструментах реагирования на изменения требований, менеджер включает в проект новые и новые работы, теряя фокусировку на целесообразности подобных доработок, полностью погружаясь в процесс механической разработки. Сайт обрастает все новыми и новыми фичами, начинает решать кучу задач вместо того, чтобы давить в нужном месте. В результате получатся то, что не нужно ни заказчику, ни интернет сообществу, причем в этом случае и те и другие будут винить в неудаче исключительно разработчика, и будут правы. Строить иллюзии по этому поводу бессмысленно — хозяин сайта, который не принес выгод, не выстрелил и не стал коммерчески успешным, не станет размышлять о своих ошибках и оценивать свои действия, корень проблемы он увидит только в разработчике. Если человек приходит к врачу с головной болью и просит отрезать ему ногу, то в случае согласия и проведения операции справедливо обвинит в ошибке врача. Он профессионал, и только он может знать, как решить проблему.
В чем ошибка? В смещении фокуса на то «как делать», с того «что делать». Хорошо, когда заказчик сайта четко понимает, что он хочет получить в результате работы (цели) и как это должно выглядеть (требования). Если этого понимания нет, то задача менеджера — сформировать его, а после это проследить, чтобы результат соответствовал заданным целям. А так как мы принимаем, что требования могут меняться в ходе работы, то отслеживать соответствие требований к сайту целям нужно регулярно. Строго говоря, ситуация изменения целей проекта по ходу проекта маловероятна, они фиксируются на первом этапе и изредка корректируются, а вот придумать новый функционал очень легко. Добавляя новые требования по ходу работы, клиент чаще всего оперирует терминами задач, рассматривая ситуацию со своей точки зрения. По понятным причинам он хочет заставить сайт делать максимально большое количество дел, и это нормально, но он не всегда знает, зачем. И вот тут методология отвечает на вопрос «как двигаться?», но не мешает движению в неправильном направлении.
Так какие же требования включать в работу, а какие нет? Для разъяснения проблемы может быть использована простая аналогия: web-проект — задача поражения цели боевой ракетой.
Рассмотрим озвученную задачу подробнее. Предположим, что где-то в радиусе действия ракеты находится движущаяся воздушная цель, ракета находится на пусковой установке, ставится задача уничтожения цели. В момент пуска система наведения рассчитывает траекторию выхода на цель.
Самолет, требующий поражения, определяется из множества самолетов в небе бизнес-целями проекта, его положение в каждый момент времени характеризует результат работы, наиболее удачный и ценный для клиента в этот момент времени. Ракета наводится на цель при помощи требований, формализованных в виде спецификаций, технических заданий, product backlog'ов и так далее, пройденный ракетой путь — количество выполненной работы.
Проверка актуальности траектории ракетой происходит раз в какой-то период. Предположим, что через некоторое время после пуска система наведения проверит положение цели и окажется, что цель изменила свое положение и ракета движется в неверном направлении. Произойдет корректировка маршрута.
Изменения на проекте могут быть различного характера, но затрагивают вопросы реализации конкретных функциональностей, например, пришло понимание более качественной, простой реализации какого-либо сервиса.
Проходит еще немного времени, ракета продолжает двигаться к цели, реагируя на ее маневры корректировкой траектории.
И снова смена плана. На этот раз команда сталкивается с непреодолимыми техническими трудностями, нужно переписывать часть системы.
И вот, после нескольких смен требований траекторий ракета поражает цель.
Есть гарантия, что клиент удовлетворен? Только в том случае, если ракета поразила правильную цель.
Некоторые методики ведения проекта предоставляют инструменты быстрого реагирования на смену требований, но ни одна из них не дает гарантии отсутствия ошибки в требованиях. Обязанность product owner'a в большинстве случаев возлагаются на менеджера со стороны разработчика, в конце концов никто не мешает взять за это больше денег. Именно менеджер проекта совместно с клиентом определяет сначала цели проекта, после этого итеративно формирует требования к конечному результату. Проверка всех новых требований на предмет наилучшего достижения целей и сопротивление отклонению от курса — также обязанность менеджера.
Навскидку легко выделить два типа требований:
Чем больше требований будет аргументированно отклонено, тем выше ценность оставшихся (в разумных пределах, само собой). Если вы хотите сделать качественную вещь, то требованиями нужно управлять, а не радостно размахивать своим scrum’ом и делать все подряд.
Кстати, про самолет впервые придумал Максим Кузин. Привет, Макс!
Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.
Scrum — панацея от всех бед
Именно так может показаться измученному менеджеру/директору после первой встречи с описанием методологии после работы без четкой системы, или по водопадным методам. К таким методам приходишь либо сам, начиная работать, либо приводит традиционное управление проектами по PERT и CPM, преподаваемое сейчас во многих институтах на менеджерских и инженерных специальностях. Действительно, имея незамутненное и незамусоренное представление о строительстве сайтов, самое простое и понятное – распланировать по задачам и этапам, связать работы в цепочку и следить за тем, чтобы все начинали работать вовремя. Это без особых проблем может сработать на небольших и простых проектах, но на сколь-нибудь серьезных начинается знакомая многим история несоответствия результата ожиданиям заказчика, вечно доделанный на 98% функционал, пучок багов, всплывающий под релиз. Все это неприятно, а еще хотелось бы иметь какую-то более точную систему получения оценок по трудозатратам, а то ж время — деньги.
Тут приходит скрам и говорит, что мы делаем маленькие, но только законченные кусочки. Соответственно, и багфиксом управлять, и соответствовать ожиданиям заказчика без написания ТЗ и затянутых коммуникаций о будущем функционале становится проще. В качестве меры оценки появляется story point, за который вполне можно принять более или менее объективный идеальный человеко-час, тем самым обезопаситься и от Паркинсона, и от студента. Вроде бы и на стороне клиента все довольны — получают понятные штуки на небольшом промежутке времени, можно покрутить в руках, применить в деле и показать начальству. Головная боль любого менеджера – изменения в желаниях клиента с течением времени – превращается в интересную и полезную игру, позволяющую показать профессионализм, инновационность в методах работы и замечательное отличие от конкурентов. На заходящих проектах менеджер заявляет клиенту о новой супер технологии, для которой писать ТЗ не нужно, а любые требования в любой момент могут быть выполнены. Клиент радостно принимается заваливать своими идеями, в результате интересный и прибыльный проект постепенно загибается.
Требованиями тоже нужно управлять
За формирование историй в product backlog'e отвечает product owner, соответственно, именно он решает, каким требованиям будет удовлетворять результат разработки. Именно поэтому product owner'ом должен быть менеджер на стороне разработчика. Информация о компаниях, действующих на российском рынке web разработки, применяющих scrum и отдающих роль product owner'a на сторону клиента, кажется мне подозрительной. Методология четко описывает product owner'a как человека, знающего своих пользователей, умеющего четко сформулировать цели своего бизнеса и переложить их в требования, а, значит, в определенной степени знакомого с технологиями разработки. Среднестатистический заказчик сайта не подходит под это описание, не готов нести ответственности за результат разработки, не хочет заморачиваться, а хочет чувствовать себя комфортно. Тонкости методологии ему особенно безразличны, если работа с подрядчиками и производство сайтов не входит в его профессиональные обязанности.
Зная о своих новых инструментах реагирования на изменения требований, менеджер включает в проект новые и новые работы, теряя фокусировку на целесообразности подобных доработок, полностью погружаясь в процесс механической разработки. Сайт обрастает все новыми и новыми фичами, начинает решать кучу задач вместо того, чтобы давить в нужном месте. В результате получатся то, что не нужно ни заказчику, ни интернет сообществу, причем в этом случае и те и другие будут винить в неудаче исключительно разработчика, и будут правы. Строить иллюзии по этому поводу бессмысленно — хозяин сайта, который не принес выгод, не выстрелил и не стал коммерчески успешным, не станет размышлять о своих ошибках и оценивать свои действия, корень проблемы он увидит только в разработчике. Если человек приходит к врачу с головной болью и просит отрезать ему ногу, то в случае согласия и проведения операции справедливо обвинит в ошибке врача. Он профессионал, и только он может знать, как решить проблему.
В чем ошибка? В смещении фокуса на то «как делать», с того «что делать». Хорошо, когда заказчик сайта четко понимает, что он хочет получить в результате работы (цели) и как это должно выглядеть (требования). Если этого понимания нет, то задача менеджера — сформировать его, а после это проследить, чтобы результат соответствовал заданным целям. А так как мы принимаем, что требования могут меняться в ходе работы, то отслеживать соответствие требований к сайту целям нужно регулярно. Строго говоря, ситуация изменения целей проекта по ходу проекта маловероятна, они фиксируются на первом этапе и изредка корректируются, а вот придумать новый функционал очень легко. Добавляя новые требования по ходу работы, клиент чаще всего оперирует терминами задач, рассматривая ситуацию со своей точки зрения. По понятным причинам он хочет заставить сайт делать максимально большое количество дел, и это нормально, но он не всегда знает, зачем. И вот тут методология отвечает на вопрос «как двигаться?», но не мешает движению в неправильном направлении.
Готовься, целься, пли
Так какие же требования включать в работу, а какие нет? Для разъяснения проблемы может быть использована простая аналогия: web-проект — задача поражения цели боевой ракетой.
Рассмотрим озвученную задачу подробнее. Предположим, что где-то в радиусе действия ракеты находится движущаяся воздушная цель, ракета находится на пусковой установке, ставится задача уничтожения цели. В момент пуска система наведения рассчитывает траекторию выхода на цель.
Самолет, требующий поражения, определяется из множества самолетов в небе бизнес-целями проекта, его положение в каждый момент времени характеризует результат работы, наиболее удачный и ценный для клиента в этот момент времени. Ракета наводится на цель при помощи требований, формализованных в виде спецификаций, технических заданий, product backlog'ов и так далее, пройденный ракетой путь — количество выполненной работы.
Проверка актуальности траектории ракетой происходит раз в какой-то период. Предположим, что через некоторое время после пуска система наведения проверит положение цели и окажется, что цель изменила свое положение и ракета движется в неверном направлении. Произойдет корректировка маршрута.
Изменения на проекте могут быть различного характера, но затрагивают вопросы реализации конкретных функциональностей, например, пришло понимание более качественной, простой реализации какого-либо сервиса.
Проходит еще немного времени, ракета продолжает двигаться к цели, реагируя на ее маневры корректировкой траектории.
И снова смена плана. На этот раз команда сталкивается с непреодолимыми техническими трудностями, нужно переписывать часть системы.
И вот, после нескольких смен требований траекторий ракета поражает цель.
Есть гарантия, что клиент удовлетворен? Только в том случае, если ракета поразила правильную цель.
Вывод
Некоторые методики ведения проекта предоставляют инструменты быстрого реагирования на смену требований, но ни одна из них не дает гарантии отсутствия ошибки в требованиях. Обязанность product owner'a в большинстве случаев возлагаются на менеджера со стороны разработчика, в конце концов никто не мешает взять за это больше денег. Именно менеджер проекта совместно с клиентом определяет сначала цели проекта, после этого итеративно формирует требования к конечному результату. Проверка всех новых требований на предмет наилучшего достижения целей и сопротивление отклонению от курса — также обязанность менеджера.
Навскидку легко выделить два типа требований:
- Требования, явно высказанные клиентом – требуют тщательного анализа и оценки с точки зрения попадания в цель. Невнимательное принятие требований клиента и удовлетворение их может стать причиной поражения неверной цели, а в неудаче клиент винит только разработчика.
- Требования, не высказанные клиентом, но необходимые для попадания в цель. Основное поле деятельности разработчика, качественная работа здесь обеспечивает четкое наведение и безупречное попадание. Невнимание команды к целям бизнеса заказчика – причина промаха.
Чем больше требований будет аргументированно отклонено, тем выше ценность оставшихся (в разумных пределах, само собой). Если вы хотите сделать качественную вещь, то требованиями нужно управлять, а не радостно размахивать своим scrum’ом и делать все подряд.
Кстати, про самолет впервые придумал Максим Кузин. Привет, Макс!
