Сегодня гибкими методологиями сложно кого-то удивить: со дня принятия манифеста Agile прошло уже 15 лет, еще раньше мир узнал про Scrum. Это уже обыденность для многих компаний, занимающихся разработкой ПО и кажется, что добавить здесь нечего.
Но при всей популярности Scrum в своей работе и на разного рода семинарах и конференциях временами сталкиваюсь с непониманием его базовых принципов. И все чаще в комментариях на Хабре вижу негативные отзывы: у кого-то не получается договориться с заказчиками о переходе на итерационную разработку, кто-то не может адаптировать команду. Наверно, самый популярный отзыв о Scrum, который можно встретить звучит так: «Мы тратим по полчаса на митинги с нулевой пользой, а потом работаем как раньше, только добавилась головная боль с демо, ретро и планированием».
Мы начали внедрять Scrum с 2011 года. Проект у нас непростой: 6 команд (scrum of scrum), более 40 участников и фичи на годы работы. Естественно у нас вначале не все было гладко, после первых неудач всерьез думали вернуться к привычной водопадной модели, но в итоге смогли адаптировать Scrum под себя. В результате мы имеем выстроенный стабильный и предсказуемый процесс разработки, без факапов и с высоким качеством. Все это время я был и остаюсь тимлидом одной из команд и практически ни одна проблема, с который мы сталкивались, не проходила мимо меня.
Можно долго рассуждать о причинах провала Scrum в отдельных компаниях, но сегодня хочется обратить ваше внимание на одну из важных частей разработки – проектирование. Дальнейшие рассуждения будут основаны на личном опыте, все персонажи вымышлены, а совпадения случайны. Итак, начнем.
Миф 1. Я программист, я не хочу проектировать
И тут возможно многие узнали себя. Простой эксперимент: спросите себя и коллег, кто хочет «проектировать». По моим наблюдениям 70-80 % скажут «нет». А почему?
Для начала нужно разобраться, а что такое «проектирование»? Мне довелось пару лет поработать на проектах «под заказ» с чистым водопадным процессом и большой любовью к спецификациям и толстым томам проектных решений. И знаете, тогда я бы тоже сказал, что не хочу проектировать. Два месяца в одиночку генерировать сотни страниц документации невесело и совсем не похоже на то, что любят все программисты – писать код.
Но давайте поговорим о «проектировании в Scrum». Целей у проектирования немного: снизить риски при разработке, дать владельцу продукта, стейкхолдеру/заказчику и команде понимание того, что и как будет делать команда и в результате повысить ценность продукта. В результате получается реалистичная модель «как будет» с учетом ограничений, ресурсов и компетенций. В общем случае не нужны тонны исчерпывающей документации, достаточно понимания, что нужно делать и детальной декомпозиции работ.
Можно вообще не проектировать, в конце концов есть bug driven development. Если налить воду в решето и быстро затыкать пальцем его дно создается ощущение, что вода не вытекает. Аналогичным образом обеспечивается качество многих программных продуктов.
Но ведь подумать о том, как ты будешь делать задачу из баклога это тоже проектирование. Планирование спринта — это тоже проектирование. А в командной итерационной работе есть отличные приемы как добиться желаемого и не мучать разработчиков «проектированием»:
- Если вы работаете в незнакомых и сложных предметных областях — возьмите в команду аналитика, подружитесь с ним – он не кусается. Он может проработать описания ролей пользователей и кейсов их работы (но только не требования, пожалуйста, только не требования), составить обзор конкурентов, изучить законодательство и предметную область в целом.
И при этом он в команде на протяжении всего спринта, а значит он может помочь команде и консультациями при разработке. А с разработчиков это снимет головную боль, ведь работа аналитика — это то, что не любят делать сами программисты при проектировании. - Не пишите лишнюю документацию — пишите код. За последние пару лет у меня выработалось четкое правило: для любого мало-мальски сложного проекта нужно сделать прототип. Кажется, что это ничего не даст, но на деле при его реализации постоянно всплывают разные мелочи, которые мы бы не заметили без прототипа. Показывать заказчику работающие прототипы вместо бумажек — это плюс к доверию вашей оценке проекта и вам лично. И самое главное: разрабатывать прототипы может вся команда!
- Проектируйте быстро. Затягивание проектов плохо сказывается на достижении целей спринта и моральном духе разработчиков. Лучше «навалиться» всей командой, закончить проектирование и перейти к реализации.
В общем – «я программист, а не проектировщик» это не отговорка, Scrum – это в первую очередь команда, а в команде каждому найдется чем заняться при проектировании.
Миф 2. «Мудрец в стеклянной башне»
Это выражение придумано не мной, но мне кажется оно точно отражает еще один миф насчет проектирования – можно найти суперпроектировщика, который возьмет на себя все проектные решения, сделает в срок и с нужным качеством и все будет в шоколаде. У него все компетенции, знания и на нем вся ответственность.
Например, в этом контексте у ребят из гильдии проектировщиков используется термин «аналитик-проектировщик». Лично работал с человеком, который раньше выполнял такую роль и, наверное, в других обстоятельствах сам бы стал таким «мудрецом в стеклянной башне». В общем, это довольно распространенный подход.
Почему это не работает?
На самом деле работает, но есть несколько минусов:
- Очевидные вещи типа отсутствия взаимозаменяемости и зависимости от настроения, здоровья и лояльности одного человека расписывать не нужно, это и так понятно.
- «Мудрецу» очень легко перейти на общение с командой в исключительно командном стиле. Он спускает «из башни» требования, а остальные их реализуют. Здесь нужно пояснить, почему я не люблю «требования». User story говорят нам о том, что нужно пользователям и почему, а требования говорят нам лишь о том, что показалось важным «мудрецу». К тому же придется потратить немало времени, чтобы донести идеи «мудреца» до команды, чтобы все участники поняли, что от них хотят.
- За счет того, что «мудрец» проектирует один он делает это очень долго. Даже не так: ооо-о-очень долго. За время одного спринта получается нереально успеть закончить фичу целиком, в результате появляются «спринты проектирования», потом «спринты реализации» и «спринты поддержки». Не очень похоже на Scrum, правда?
- Отдельно выделю то, что такое проектирование совершенно не развивает команду. А между тем именно команда, ее работа и развитие важны в Scrum.
В итоге: суперпроектировщик это работающее решение, но еще лучше, чтобы команда проектировала вместе с ним, это будет и быстрее, и качественнее.
Миф 3. Отказались от бумаги и чувствуем себя отлично
Вопрос документирования в гибких методологиях часто бывает болезненным. Толстые тома документации все равно никто не читает, и они устаревают уже после написания первой строчки кода. А программисты, видя это, не хотят писать бумажки «на выброс». Может быть, вообще откажемся от документирования?
Было бы отлично, но совсем отказаться не получится.
На волне минимизации «исчерпывающей документации» (манифест Agile, пункт 2) легко решить, что проектную документацию мы больше не пишем. Вопросы решаем устно, команда все равно в курсе что мы делаем, заказчику на пальцах объясним.
Вживую это, к сожалению, выглядит так, как будто человечество тысячелетиями изобретало и развивалось письменность как способ фиксации знаний, а в 2016 году разработчики ПО вернулись к устным сказаниям. Когда вы что-то обсудили с заказчиком, не записали, забыли, а потом он спрашивает, что вы придумали по его вопросу – то это повод поменять две вещи: тему разговора и свой подход к документированию.
Из личной практики есть несколько рекомендаций:
- писать бумажки программистам реально тяжело и скучно – найдите способ документирования, который нравится лично вам. Рисуете мокапы – отлично. Любите майндмапы – ок. Рисуете на доске – замечательно, пусть это будет вашим форматом проектного решения. Главное – договориться со всеми, что у вас теперь такой формат. В остальном – Scrum’ом не запрещено и получается на 95% интереснее, чем писать большие тексты.
- определитесь с тем, кому кроме команды будут интересны ваши проектные решения. Это могут быть: менеджеры по продажам, маркетологи, консультанты, работающие с заказчиками. Часто проще потратить время и записать, чем потом пересказывать одно и то же раз за разом.
- ведите список вопросов, которые вам задали на обсуждениях, демо или просто в коридоре. Необязательность не имеет ничего общего с гибкостью и выглядит как неуважение к коллегам.
В итоге: документируйте проектные решения осознанно, а не спонтанно, и подстраивайте формат под себя.
Миф 4. А ладно, потом на демо покажем
Работая в команде легко забыть, что есть заказчики, пользователи, ведь коммуникаций и так хватает и создается ощущение общего консенсуса. На демо конечно нужно показать работающий инкремент продукта, но по ходу спринта команда выглядит самодостаточной.
Но тут я задам простой вопрос: бывало ли у вас такое, что после демо вы все переделывали?
Если да, то вполне возможно, что вам не хватает коммуникаций по ходу спринта. Это актуально и для разработки, а для проектирования регулярное общение с владельцем продукта или заказчиком и вовсе обязательно.
У заказчика/стейкхолдера может быть свое видение продукта, у владельца продукта другое, у вас третье. В идеале нужно встречаться лично каждый день и обсуждать результаты проектирования и вопросы на проработку. Если вы показываете на этих обсуждениях прототипы, то для вас почти наверняка не будет сюрпризов на демо.
Миф 5. С миру по нитке и в продакшен
Давайте будем честны: практически все, что мы делаем уже кто-то придумал до нас, скорее всего, реализовал и возможно даже сделал это неплохо. Российский ИТ-рынок изначально развивается за счет копирования западных продуктов и идей. Получается, что в проектировании нет ничего уникального, можно взять подборку решений конкурентов, выделить лучшее и сделать?
И да и нет.
Анализ готовых решений — это почти обязательная часть для проектирования, но чтобы продукт был максимально ценным нужно понять, что мы делаем, для кого и как. Проектирование должно быть осмысленным и контролируемым. В этом плане есть масса готовых приемов:
- проектируйте от персонажей/ролей. Персонажи/роли – это ваши будущие пользователи и ваша задача уменьшить их головную боль и сделать их жизнь хоть чуть-чуть попроще.
- используйте пользовательские истории. Ценность продукту придает не набор фич, а его способность закрывать реальные ситуации. Рекомендую прочитать User Stories Applied For Agile Software Development. M. Cohn.
- проектируйте архитектуру исходя из кейсов пользователей. В конечном итоге продуктом пользуются живые люди и его развитие скорее всего будет идти от их кейсов. Правильно выстроенная предметная модель позволит со временем дополнять ее, а не переписывать с нуля. А разработчик оперирующий понятиями реальной предметной области имеет фору перед тем, кто оперирует исключительно билдерами, визитерами и хелперами. Поясню: паттерны полезны для проектирования абстракций, но они не могут скрыть отсутствие продуманной объектной модели. Рекомендую прочитать Предметно-ориентированное проектирование (DDD) Эрика Эванса.
В итоге: не нужно лениться и ограничиваться готовыми решениями при проектировании. Потратьте время на изучение ваших пользователей и их потребностей и ваш продукт будет выгодно выделяться на фоне конкурентов.
Кратко о том, как работаем мы
Это не best practices, но конкретно у нас это дало положительный эффект:
- релизный цикл у нас состоит из 6 спринтов разработки и для того, чтобы грамотно спланировать релиз мы проводим по сути короткий «нулевой» спринт: предварительное исследование и проектирование. В результате все четко знают, чем мы будем заниматься по ходу спринтов и если мы отстаем от плана всегда понимаем, что будет минимально-ценным продуктом (MVP), а что можно выкинуть.
- длительность итерации – 12 рабочих дней. Идеально, если вы исследуете, проектируете и делаете все в один спринт, тогда у вас будет быстрый фидбек (тестирование, приемочное тестирование, коридорное тестирование, демо) и в следующем спринте вам нужно заложить небольшой резерв на доработки. При этом мы пробовали и более длинные итерации, когда все это входило в один спринт, но по факту чем чаще вы делаете «check» из PDCA, тем меньше вероятность для вас сделать не то.
- мы используем парное проектирование. Это значит, что как минимум два человека из команды участвуют в исследовании, генерации вариантов, прототипировании. Это быстрее и проще, чем проектировать в одиночку. Также к ним обычно подключается бизнес-аналитик и зачастую остальная команда в части прототипирования.
Вместо заключения
Проектирование в Scrum это не серебряная пуля, а всего лишь способ организации командной работы в незнакомой области. Оно не дает вам гарантию от факапов, а выстраивание работающего процесса будет стоить вам времени и нервов.
Стоит ли им вообще заниматься? Каждый ответит на этот вопрос сам, я лишь хочу предостеречь вас от ошибок, которые совершал сам. Этот список ограничен моей практикой, если вы сталкивались с другими мифами – буду рад, если вы дополните его в комментариях.
Автор: dkiz
