- PVSM.RU - https://www.pvsm.ru -
Сегодня гибкими методологиями сложно кого-то удивить: со дня принятия манифеста Agile прошло уже 15 лет, еще раньше мир узнал про Scrum. Это уже обыденность для многих компаний, занимающихся разработкой ПО и кажется, что добавить здесь нечего.
Но при всей популярности Scrum в своей работе и на разного рода семинарах и конференциях временами сталкиваюсь с непониманием его базовых принципов. И все чаще в комментариях на Хабре вижу негативные отзывы: у кого-то не получается договориться с заказчиками о переходе на итерационную разработку, кто-то не может адаптировать команду. Наверно, самый популярный отзыв о Scrum, который можно встретить звучит так: «Мы тратим по полчаса на митинги с нулевой пользой, а потом работаем как раньше, только добавилась головная боль с демо, ретро и планированием».
Мы начали внедрять Scrum с 2011 года. Проект у нас непростой: 6 команд (scrum of scrum), более 40 участников и фичи на годы работы. Естественно у нас вначале не все было гладко, после первых неудач всерьез думали вернуться к привычной водопадной модели, но в итоге смогли адаптировать Scrum под себя. В результате мы имеем выстроенный стабильный и предсказуемый процесс разработки, без факапов и с высоким качеством. Все это время я был и остаюсь тимлидом одной из команд и практически ни одна проблема, с который мы сталкивались, не проходила мимо меня.
Можно долго рассуждать о причинах провала Scrum в отдельных компаниях, но сегодня хочется обратить ваше внимание на одну из важных частей разработки – проектирование. Дальнейшие рассуждения будут основаны на личном опыте, все персонажи вымышлены, а совпадения случайны. Итак, начнем.
И тут возможно многие узнали себя. Простой эксперимент: спросите себя и коллег, кто хочет «проектировать». По моим наблюдениям 70-80 % скажут «нет». А почему?
Для начала нужно разобраться, а что такое «проектирование»? Мне довелось пару лет поработать на проектах «под заказ» с чистым водопадным процессом и большой любовью к спецификациям и толстым томам проектных решений. И знаете, тогда я бы тоже сказал, что не хочу проектировать. Два месяца в одиночку генерировать сотни страниц документации невесело и совсем не похоже на то, что любят все программисты – писать код.
Но давайте поговорим о «проектировании в Scrum». Целей у проектирования немного: снизить риски при разработке, дать владельцу продукта, стейкхолдеру/заказчику и команде понимание того, что и как будет делать команда и в результате повысить ценность продукта. В результате получается реалистичная модель «как будет» с учетом ограничений, ресурсов и компетенций. В общем случае не нужны тонны исчерпывающей документации, достаточно понимания, что нужно делать и детальной декомпозиции работ.
Можно вообще не проектировать, в конце концов есть bug driven development. Если налить воду в решето и быстро затыкать пальцем его дно создается ощущение, что вода не вытекает. Аналогичным образом обеспечивается качество многих программных продуктов.
Но ведь подумать о том, как ты будешь делать задачу из баклога это тоже проектирование. Планирование спринта — это тоже проектирование. А в командной итерационной работе есть отличные приемы как добиться желаемого и не мучать разработчиков «проектированием»:
В общем – «я программист, а не проектировщик» это не отговорка, Scrum – это в первую очередь команда, а в команде каждому найдется чем заняться при проектировании.
Это выражение придумано не мной, но мне кажется оно точно отражает еще один миф насчет проектирования – можно найти суперпроектировщика, который возьмет на себя все проектные решения, сделает в срок и с нужным качеством и все будет в шоколаде. У него все компетенции, знания и на нем вся ответственность.
Например, в этом контексте у ребят из гильдии проектировщиков [1] используется термин «аналитик-проектировщик». Лично работал с человеком, который раньше выполнял такую роль и, наверное, в других обстоятельствах сам бы стал таким «мудрецом в стеклянной башне». В общем, это довольно распространенный подход.
Почему это не работает?
На самом деле работает, но есть несколько минусов:
В итоге: суперпроектировщик это работающее решение, но еще лучше, чтобы команда проектировала вместе с ним, это будет и быстрее, и качественнее.
Вопрос документирования в гибких методологиях часто бывает болезненным. Толстые тома документации все равно никто не читает, и они устаревают уже после написания первой строчки кода. А программисты, видя это, не хотят писать бумажки «на выброс». Может быть, вообще откажемся от документирования?
Было бы отлично, но совсем отказаться не получится.
На волне минимизации «исчерпывающей документации» (манифест Agile [2], пункт 2) легко решить, что проектную документацию мы больше не пишем. Вопросы решаем устно, команда все равно в курсе что мы делаем, заказчику на пальцах объясним.
Вживую это, к сожалению, выглядит так, как будто человечество тысячелетиями изобретало и развивалось письменность как способ фиксации знаний, а в 2016 году разработчики ПО вернулись к устным сказаниям. Когда вы что-то обсудили с заказчиком, не записали, забыли, а потом он спрашивает, что вы придумали по его вопросу – то это повод поменять две вещи: тему разговора и свой подход к документированию.
Из личной практики есть несколько рекомендаций:
В итоге: документируйте проектные решения осознанно, а не спонтанно, и подстраивайте формат под себя.
Работая в команде легко забыть, что есть заказчики, пользователи, ведь коммуникаций и так хватает и создается ощущение общего консенсуса. На демо конечно нужно показать работающий инкремент продукта, но по ходу спринта команда выглядит самодостаточной.
Но тут я задам простой вопрос: бывало ли у вас такое, что после демо вы все переделывали?
Если да, то вполне возможно, что вам не хватает коммуникаций по ходу спринта. Это актуально и для разработки, а для проектирования регулярное общение с владельцем продукта или заказчиком и вовсе обязательно.
У заказчика/стейкхолдера может быть свое видение продукта, у владельца продукта другое, у вас третье. В идеале нужно встречаться лично каждый день и обсуждать результаты проектирования и вопросы на проработку. Если вы показываете на этих обсуждениях прототипы, то для вас почти наверняка не будет сюрпризов на демо.
Давайте будем честны: практически все, что мы делаем уже кто-то придумал до нас, скорее всего, реализовал и возможно даже сделал это неплохо. Российский ИТ-рынок изначально развивается за счет копирования западных продуктов и идей. Получается, что в проектировании нет ничего уникального, можно взять подборку решений конкурентов, выделить лучшее и сделать?
И да и нет.
Анализ готовых решений — это почти обязательная часть для проектирования, но чтобы продукт был максимально ценным нужно понять, что мы делаем, для кого и как. Проектирование должно быть осмысленным и контролируемым. В этом плане есть масса готовых приемов:
В итоге: не нужно лениться и ограничиваться готовыми решениями при проектировании. Потратьте время на изучение ваших пользователей и их потребностей и ваш продукт будет выгодно выделяться на фоне конкурентов.
Это не best practices, но конкретно у нас это дало положительный эффект:
Проектирование в Scrum это не серебряная пуля, а всего лишь способ организации командной работы в незнакомой области. Оно не дает вам гарантию от факапов, а выстраивание работающего процесса будет стоить вам времени и нервов.
Стоит ли им вообще заниматься? Каждый ответит на этот вопрос сам, я лишь хочу предостеречь вас от ошибок, которые совершал сам. Этот список ограничен моей практикой, если вы сталкивались с другими мифами – буду рад, если вы дополните его в комментариях.
Автор: dkiz
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/scrum/220071
Ссылки в тексте:
[1] гильдии проектировщиков: https://www.facebook.com/theguildru/
[2] манифест Agile: http://agilemanifesto.org/iso/ru/manifesto.html
[3] User Stories Applied For Agile Software Development. M. Cohn.: https://www.amazon.com/User-Stories-Applied-Development-Addison-Wesley-ebook/dp/B0054KOL74
[4] Предметно-ориентированное проектирование (DDD) Эрика Эванса.: https://www.ozon.ru/context/detail/id/5497184/
[5] PDCA: https://ru.wikipedia.org/wiki/Цикл_Деминга
[6] Источник: https://habrahabr.ru/post/317376/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.