О Scrum написано много, но примеры реального применения не так уж и распространены.
Я уже некоторое время внедряю Scrum в потоковую веб-разработку, мне бы хотелось поговорить на эту тему и поделиться своими мыслями.
Бум интереса к этой методологии прошел, но многие молодые команды по-прежнему легко увлекаются теоретической магией Scrum, обещаниями раскалывать новые требования как орешки и не дурачиться с техническими заданиями, спешат внедрять это в свое производство и немедленно столкнуться с трудностями.
Scrum вообще зародился как методология разработки программного обеспечения, если кто забыл, и для успешного использования в веб-разработке требуется определенная настройка.
Это отдельная тема, в этой заметке хотелось бы затронуть еще одну тему и предостеречь от очевидных, в целом, ошибок, связанных с формированием требований к проекту.
Любое описание методологии в Google говорит о важности роли scrum-мастера и презентации требований проекта в виде историй, но никто не говорит о том, откуда берутся требования и нужно ли их вообще реализовывать.
Без понимания этого момента вряд ли вы сможете сделать что-то стоящее, и методология тут ни при чем.
Scrum — панацея от всех бед
Именно так может показаться измученному менеджеру/директору после первой встречи с описанием методологии после работы без четкой системы или использования каскадных методов.К таким методам вы либо приходите сами, когда начинаете работать, либо приходите от традиционного управления проектами на основе PERT и CPM, которое сейчас преподают во многих институтах по управленческим и инженерным специальностям.
Ведь имея четкое и лаконичное представление о построении сайта, самое простое и понятное — распланировать по задачам и этапам, связать работу в цепочку и следить за тем, чтобы все приступили к работе вовремя.
Это может без проблем работать на небольших и простых проектах, но на любых серьёзных проектах начинается знакомая история с результатом, не соответствующим ожиданиям заказчика, функционал всегда готов на 98%, перед релизом всплывает куча багов.
Все это неприятно, а еще хотелось бы иметь какую-то более точную систему получения оценок трудозатрат, так как время – деньги.
Потом приходит Скрам и говорит, что мы делаем небольшие, но только законченные кусочки.
Соответственно, становится проще управлять исправлением ошибок и соответствовать ожиданиям клиента без написания технических спецификаций и длительных сообщений о будущей функциональности.
В качестве меры оценки появляется стори-пойнт, за который вполне можно принять более-менее объективный идеальный человеко-час, защитив тем самым себя и от Паркинсона, и от студента.
Кажется, на стороне клиента все довольны — получают понятные вещи за короткий промежуток времени, могут повертеть их в руках, применить на практике и показать начальству.
Головная боль любого менеджера – изменение желаний клиента с течением времени – превращается в интересную и полезную игру, позволяющую проявить профессионализм, новаторство в методах работы и заметное отличие от конкурентов.
На предстоящих проектах менеджер рассказывает клиенту о новой супертехнологии, для которой нет необходимости писать техническое задание, а любые требования можно удовлетворить в любой момент. Клиент с радостью начинает заваливать его своими идеями, и в результате от интересного и прибыльного проекта постепенно отказываются.
Требованиями также необходимо управлять.
Владелец продукта отвечает за создание историй в бэклоге продукта; соответственно, именно он решает, каким требованиям будет удовлетворять результат разработки.
Вот почему владелец продукта должен быть менеджером на стороне разработчика.
Мне кажется подозрительной информация о компаниях, работающих на российском рынке веб-разработки, которые используют Scrum и возлагают на клиентскую сторону роль Product Owner. Методология четко описывает владельца продукта как человека, который знает своих пользователей, умеет четко формулировать цели своего бизнеса и воплощать их в требования, а значит, в определенной степени знаком с технологиями разработки.
Среднестатистический заказчик сайта не подходит под это описание, не готов нести ответственность за результат разработки, не хочет заморачиваться, но хочет чувствовать себя комфортно.
Особенно он равнодушен к тонкостям методики, если работа с подрядчиками и создание сайтов не входит в его профессиональные обязанности.
Зная о своих новых инструментах реагирования на изменения требований, менеджер включает в проект все больше работы, теряя фокус на целесообразности таких улучшений, полностью погружаясь в процесс механической разработки.
Сайт приобретает все новые и новые возможности и начинает решать кучу задач вместо того, чтобы давить в нужном месте.
В результате получится то, что не нужно ни заказчику, ни интернет-сообществу, и в этом случае оба будут винить в провале исключительно разработчика, и будут правы.
Нет смысла строить иллюзии по этому поводу – владелец сайта, который не принес пользы, не взлетел и не стал коммерчески успешным, не будет размышлять над своими ошибками и оценивать свои действия; он увидит корень проблемы только в разработчике.
Если человек придет к врачу с головной болью и попросит отрезать ему ногу, то, если он согласится и операция будет проведена, он справедливо будет винить в ошибке врача.
Он профессионал и только он может знать, как решить проблему.
Где ошибка? В смещении фокуса с «что делать» на «как делать».
Хорошо, когда заказчик сайта четко понимает, что он хочет получить в результате работы (цели) и как это должно выглядеть (требования).
Если этого понимания нет, то задача менеджера – его сформировать, а затем обеспечить соответствие результата поставленным целям.
А поскольку мы допускаем, что требования могут меняться в ходе работы, нам необходимо регулярно контролировать соответствие требований сайта целям.
Строго говоря, ситуация изменения целей проекта в ходе проекта маловероятна; на первом этапе они исправляются и время от времени корректируются, но придумать новый функционал очень легко.
Добавляя новые требования по ходу работы, клиент чаще всего действует исходя из задач, рассматривая ситуацию со своей точки зрения.
По очевидным причинам он хочет, чтобы сайт выполнял как можно больше функций, и это нормально, но он не всегда знает, почему.
И здесь методика отвечает на вопрос «как двигатьсяЭ», но не предотвращает движение в неправильном направлении.
Готовься, целись, стреляй
Так какие же требования следует включать в работу, а какие нет? Для объяснения проблемы можно использовать простую аналогию: веб-проект — это задача поражения цели боевой ракетой.Рассмотрим заявленную проблему более подробно.
Предположим, что где-то в радиусе действия ракеты находится движущаяся воздушная цель, ракета находится на пусковой установке, и задача состоит в том, чтобы уничтожить цель.
В момент пуска система наведения рассчитывает траекторию достижения цели.
Самолет, требующий уничтожения, определяется из множества самолетов в небе бизнес-целями проекта; ее положение в каждый момент времени характеризует результат работы, наиболее успешный и ценный для клиента в данный момент времени.
Наведение ракеты на цель осуществляется с использованием требований, формализованных в виде технических заданий, технических заданий, заготовок продукции и т.п.
; путь, пройденный ракетой, равен объему выполненной работы.
Ракета проверяет актуальность траектории один раз в определенный период. Предположим, что через некоторое время после пуска система наведения проверяет положение цели и выясняется, что цель изменила свое положение и ракета движется не в том направлении.
Маршрут будет скорректирован.
Изменения в проекте могут носить разный характер, но они влияют на реализацию конкретного функционала, например, пришло понимание более качественной, более простой реализации сервиса.
Проходит еще немного времени, ракета продолжает двигаться к цели, реагируя на ее маневры корректировкой траектории.
И снова смена плана.
На этот раз команда столкнулась с непреодолимыми техническими трудностями; часть системы необходимо переписать.
И вот, после нескольких изменений траекторных требований, ракета попадает в цель.
Есть ли гарантия, что клиент останется доволен? Только если ракета попадет в правильную цель.
Заключение
Некоторые методологии управления проектами предоставляют инструменты для быстрого реагирования на изменяющиеся требования, но ни одна из них не гарантирует, что требования не будут содержать ошибок.В большинстве случаев ответственность владельца продукта возлагается на менеджера разработчика; в конце концов, никто не мешает взять за это больше денег.
Именно руководитель проекта совместно с клиентом сначала определяет цели проекта, а затем итеративно формирует требования к конечному результату.
В обязанности менеджера также входит анализ всех новых требований, чтобы обеспечить наилучшее достижение целей и не допустить расхождений.
Навскидку легко выделить два типа требований:
- Требования, явно высказанные клиентом, требуют тщательного анализа и оценки с точки зрения достижения цели.
Невнимательное принятие требований клиента и выполнение их может привести к поражению неправильной цели, а клиент обвиняет в неудаче только разработчика.
- Требования, не выраженные клиентом, но необходимые для достижения цели.
Основная сфера деятельности разработчика, качественная работа здесь гарантирует четкое руководство и безупречные попадания.
Причиной неудачи является невнимание команды к бизнес-целям заказчика.
Если вы хотите сделать качественную вещь, то вам нужно управлять требованиями, а не радостно махать своим Скрамом и делать все подряд. Кстати, именно Максиму Кузину впервые пришла в голову идея самолета.
Привет, Макс! Теги: #scrum #управление требованиями #управление требованиями #веб-разработка #agile
-
Счастье
19 Oct, 24 -
Типы Угроз Баз Данных
19 Oct, 24 -
Будь Моей Резиновой Уткой
19 Oct, 24 -
Мини-Конференция Веб И Гис 2011
19 Oct, 24 -
Ваш Личный Dns — Еще Немного О Dns-Хостинге
19 Oct, 24
