Прошлый модуль онлайн курса “Agile своими силами” был характерен тем, что я не накопил “вопросного долга” и за дополнительное время сумел ответить на все вопросы участников. Стараюсь потихоньку отвечать на вопросы с прошлых модулей 🙂

Один из мега популярных вопросов, которые мне доводится слышать на тренингах, конференциях и просто в частных беседах звучит как “Можно ли применять Scrum (Agile в целом) для уже существующих проектов?”. Участники первых модулей спрашивали подобные вопросы тоже:

Q: Можно ли применять agile для сопровождения продукта

Q: Чем может помочь уже в живых проектах, поддержке – постоянное исправление багов, планируется внедрение юнит тестов. Код legacy

Q: Как совместить разработку и корректировку ошибок (по саппорту) по одному продукту при скраме? Проблема в том, что объем саппорта нельзя запланировать.

Если ответить коротко, то ДА, можно и нужно (а какого ответа вы ожидали? :-)). Обычно уже идущие проекты характеризуются потоком новых идей, запросов на изменения от пользователей, да и, банально, дефектов – все это создает некий поток заказов к команде разработчиков. Если работа идет “традиционно”, то получается некая хаотическая разработка (ad-hock development).

Как правило, заказчики страдают от того, что отсутствует прозрачность состояния дел, непонятно когда и что будет готово и сколько это нам обходится. Как результат, менеджмент продукта может давать обещания пользователям или клиентам, не спрашивая команду разработки.

Разработчики тоже страдают от того, что не понятны приоритеты, и они часто меняются (бросай все и делай сейчас это), нет времени на нормальное качество и в этом замкнутом круге усугубляется состояние постоянного стресса.

Знакомо? 🙂

Когда-то я писал статью “Agile и Scrum – счего начать”, где давал, можно сказать, пошаговую инструкцию по внедрению. Советы актуальны и для упомянутой ситуации.

Именно в случае, когда уже есть поток “хотелок”, помогает ЕДИНЫЙ БЭКЛОГ ПРОДУКТА, который заставляет упорядочить все в список и уже лучше осознавать, что делать дальше. Причем ситуация становится прозрачной как для бизнеса (продукт менеджера), так и для команды.

Дальше уже команда переваривает “хотелки” в готовый продукт, и тут регулярные итерации создают ритм, к которому быстро привыкают все участники. Даже если вы не работаете итерациями по Scrum, а применяете, например, Канбан – все равно вы становитесь более предсказуемыми для бизнеса, да и для себя самих.

Отдельно о вопросе незапланированных работ (баги, супер срочные “хотелки” и т.п.) я подробно рассказывал в статье “Что Agile команде делать с «авралами»”. Там перечислены основные возможные сценарии и что делать в каждом из них.

Для обеспечения качества во время работы, я рекомендую вам внимательно посмотреть на свои “Критерии Готовности” (done criteria) и создать их, если вы еще этого не сделали. Кстати, с термином “Критерии Готовности” часто наблюдается путаница в понимании, поэтому отдельно рассказывал и про это.

Соответственно, в очень старых проектах, наблюдается “наследство” (legacy code), которое требует переработки, также большое количество заявок о том, что мол у пользователей работает не так как они хотят – это мы называем дефектами, ну и как всегда новые пожелания. Когда-то я рассказывал о концепции цветовой маркировки элементов бэклога разного типа: “Какого цвета ваш Бэклог?”. Помещайте все эти типы заявок в единый список Бэклога Продукта и уже выбирайте оптимальное сочетание на каждый спринт – это позволит сбалансировать работы, в зависимости от вашей текущей ситуации и долгосрочных целей.

Ну и подводя итог, не суть важно, какой именно каркас вы применяете (Scrum, Scrum-ban, Kanban и т.п.) – вы начнете упорядочивать свою работу, основываясь на простых принципах. Когда-то, в интервью для нашего блога Майк Кон сказал:

“Прежде всего я бы предложил каждый раз, когда это удобно, начать что-то делать, против чего руководство не может реально возражать: собираться вместе и планировать, что вы будете делать в течение короткого периода времени, в конце этого периода закончите запланированное, ежедневно общайтесь и т.д. Это всего лишь хорошая практика.”

Действительно, начните с простых практик, которые вам точно помогут. Так, по неофициальным опросам, которые я проводил, Ежедневные Встречи (Stand Up, Daily Scrum) являются самой популярной практикой. Именно о них мы и поговорим на следующем модуле “Agile своими силами”, уже в этот четверг – вы еще успеете присоединиться 😉

Если появились дополнительные вопросы по этой теме, то не стесняйтесь оставить комментарий, думаю есть еще ряд связанных тем о которых стоит написать – дайте мне знать. И подписывайтесь на RSS, чтобы не пропустить новые статьи.