Сегодня гибкими методологиями сложно кого-то удивить: со дня принятия манифеста 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 это не серебряная пуля, а всего лишь способ организации командной работы в незнакомой области. Оно не дает вам гарантию от факапов, а выстраивание работающего процесса будет стоить вам времени и нервов.
Стоит ли им вообще заниматься? Каждый ответит на этот вопрос сам, я лишь хочу предостеречь вас от ошибок, которые совершал сам. Этот список ограничен моей практикой, если вы сталкивались с другими мифами – буду рад, если вы дополните его в комментариях.
Поделиться с друзьями
Комментарии (39)
techus
12.12.2016 16:36Как Вы круто всю концепцию ребят из «Гильдии проектировщиков» в один миф запихнули. Не обидятся ли они?
dkiz
12.12.2016 16:45Надеюсь, что нет.
Ничего против них не имею, но именно в концепции аналитика-проектировщика есть определенные минусы, которые в моем случае получилось устранить за счет проектирования всей командой.
Rock_N_Roll_Queen
12.12.2016 18:03+1У заказчика/стейкхолдера может быть свое видение продукта, у владельца продукта другое, у вас третье.
А еще есть тестировщики, дизайнеры и аналитики, не говоря уже о пользователях. И всем надо проводить демо и как можно чаще. Не боитесь ли Вы перегнуть палку с количеством времени, которое тратится на взаимодействие?dkiz
13.12.2016 09:20Тестировщики и аналитики по-хорошему это участники процесса проектирования, демо для них не нужно.
Если говорить про остальных «заинтересованных лиц», то в любом случае придется потратить время на взаимодействие. Либо в виде демо, либо в виде постоянных ответов на их вопросы, потому что сами они могут неправильно понять что вы делаете и зачем.
Che_K
14.12.2016 09:21+1Все они (тестировщики, дизайнеры, аналитики) должны участвовать в процессе проектирования продукта и демо для них не должно быть первой встречей с продуктом.
Не нужно проводить весь спринт в обсуждении видения продукта, но нужно понимать, что без должного взаимодействия не выйдет ничего хорошего.
Cromathaar
12.12.2016 19:17+4Когда вы что-то обсудили с заказчиком, не записали, забыли, а потом он спрашивает, что вы придумали по его вопросу – то это повод поменять две вещи: тему разговора и свой подход к документированию.
Забрал цитату в копилку :)
А по делу, можете более четко прояснить, что вы понимаете под проектированием? Конкретно. Потому что иногда возникает ощущение, что вы говорите «проектирование», а имеете в виду «планирование», а иногда и еще чего похлеще.dkiz
13.12.2016 09:50Владелец продукта ставит перед командой задачу: что и зачем нужно сделать, на уровне его видения. Дальше проектируем: разбираемся как будем делать, потом декомпозируем на мелкие части и оцениваем.
Похоже на планирование, но:
- задачи бывают сложные, за один день планирования спринта успеть физически невозможно.
- часто до того, как начать делать нужно получить одобрение владельца продукта и заказчика/стейкхолдера
- видение владельца продукта бывает поверхностным, требуется исследование предметной области, конкурентов, кейсов работы пользователей
Lofer
13.12.2016 13:17Не могли бы Вы сказать какие проекты и в каких предметных областях вы реализовали по такой методологии?
Если вы работаете в незнакомых и сложных предметных областях — возьмите в команду аналитика, подружитесь с ним – он не кусается.
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»? в какую итерацию они помещаются или делаются вне итераций?
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Сколько у вас примерно «стоит» проектирование, «Показывать заказчику работающие прототипы» и получать отзывы, разработка, тестирование и развертывание? в среднем для 1...5 спринтов по времени. 10% этап Х, 15% этап Y и т.д.
Как новый участник проекта получает необходимие знания по проекту? Куда деваются знания проекта ушедшего человека?dkiz
14.12.2016 12:26Не могли бы Вы сказать какие проекты и в каких предметных областях вы реализовали по такой методологии?
Конкретные проекты назвать не могу, предметная область — ЕСМ и все что вокруг ЕСМ.
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой. Задач по ходу спринта хватает для 100% загрузки.
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»
Все в рамках проектирования в итерации. Если это будет отдельно, а потом отдельно проектирование, а потом отдельно реализация это уже не совсем Scrum :-)
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
Потому что это нужно для проектирования, чтобы понять полную картину. Конечно можно исследования проводить заранее, но на практике они устаревают и забываются к началу итерации, поэтому делаем все вместе.
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Мы сейчас на выброс ничего не пишем, я собственно об этом и писал. Документируем необходимый минимум, в основном в виде мокапов.
А вообще «программисты пишут бумажки» это распространенная практика, особенно когда заказчик требует тщательно описать все в ТЗ, правда потом его сам не всегда читает.
Сколько у вас примерно «стоит» проектирование?
Посмотрел по прошлому релизу: проектирование + разработка, тестирование и поддержка реализованного (баги, развертывание, продуктивы и т.д.) занимают одинаковое время.
Как новый участник проекта получает необходимие знания по проекту?
Обучение внутри команды + самостоятельно по справке к продукту, парное программирование, своя wiki по архитектуре и приемам разработки, привлечение к проектированию и планированию.
Обычно этого достаточно, чтобы освоиться за пару месяцев.Lofer
14.12.2016 14:01Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой.
Предположим, освоение нормативного документа и предметной области занимает 3 месяца времени.
Т.е вся команда что бы понять что важно а что нет для проектирования, все 10 человек будут сидеть и читать эту предметную область?
А если изучение предметной области занимает месяцев 3..9? тогда как вписывается в итерации?
Документируем необходимый минимум, в основном в виде мокапов.
Необходимый минимум для кого? Команды или Клиента?
А вообще «программисты пишут бумажки» это распространенная практика, особенно когда заказчик требует тщательно описать все в ТЗ, правда потом его сам не всегда читает.
Наверное, вы знаете что такие «бумажки» пишут как раз не программисты, а архитекторы и аналитики.
Это Presale документация? или уровень функциональной спецификации?
Как этот процес работает с контрактами Time & Material и Fixed Price?dkiz
14.12.2016 17:41А если изучение предметной области занимает месяцев 3..9?
У нас с этим попроще, но попробую предложить решения:
- Исследовать по кусочкам, если это возможно. Сначала разбить по-крупному, а дальше в каждый спринт брать по одной теме для глубокой проработки и реализации. Повторюсь, если такое возможно в конкретной предметной области
- Увеличить количество аналитиков/развивать компетенции аналитиков у других участников команды. Например, у тестировщиков.
А если не секрет какая предметная область требует изучения нормативной документации по 9 месяцев?
Необходимый минимум для кого?
В нашем случае (продуктовая разработка) получается для команды и заинтересованных лиц. Но и на практике внедрений и внешних проектов заказчики (не все конечно) готовы идти на компромиссы и отказываться от жесткого ТЗ.
«бумажки» пишут как раз не программисты
Где как, но чаще архитекторы и аналитики, вы правы. Я имел ввиду именно проектную документацию (ТЗ, спецификации).
Как этот процес работает с контрактами Time & Material и Fixed Price?
Сильно зависит от заказчика, но может работать. Коллега из отдела внедрения недавно писал статью по опыту недавних внедрений как раз по fixed price и time&material.Lofer
14.12.2016 18:25В нашем случае (продуктовая разработка)
С этого «нюанса» и надо было начинать :)
нормативной документации по 9 месяцев?
да практически любая из гос кодексов с обвязкой в виде постановлений, инструкций. из межгосударственный вещей с кучей перекрестной документации, специфическая: банковская, налоговая, финансовая, картографическая, медицина.
. Я имел ввиду именно проектную документацию (ТЗ, спецификации).
Проектную «спецификацию и ТЗ» — это работа аналитиков, после контракт. там пофиг итерации и показы. Клиент просто скажет: А покажи мне Отчет Х из твоей системы? сошлось с моим? молодец!.. нет? иди фикси дальше, чего людей отвлекаешь?
Askofen
14.12.2016 12:03Прочитал статью. С моей точки зрения, статья представляет набор банальностей. Это первый минус. Второй минус — то, что советы выливаются в благие пожелания, не предоставляющие какие-либо инструментальные решения.
Что я имею в виду?
Например, автор замечает, что программисты любят писать код и не любят описывать технический дизайн системы. Автор пытался разобраться, почему так происходит? Явление одно, а причины у него могут быть разные.
Первый вариант — некоторые программисты не знают английского языка, а заказчик — иностранец, и требует документацию на английском языке.
Другой вариант — это шаблон документа содержит много разных разделов, которые не нужны, фактически переписываются из документа в документ, и программисту не хочется тратить на это время. Что это за разделы? Как удалось обойтись без них? Какой шаблон документа был изначально и какой шаблон предлагает автор? На эти вопросы нет ответов.
Третий вариант — это огромный набор задач, часто спутанных между собой, на которые нужно найти решения. При чем решение одной задачи может порождать другие задачи, которые, в свою очередь, тоже требуют решения. Часто одни решения плохо согласуются с другими решениями. И программист просто теряется в этом клубке задач. Наступает ситуация, которую в профессиональной литературе называют «паралич от анализа». Что предлагает автор, чтобы устранить подобную проблему и помочь программисту справиться с объемом навалившихся задач? Да, фактически, ничего: нанять аналитика (который справится с этой проблемой, а то, что перед аналитиком может встать точно та же проблема — об этом даже не думается) и проектировать быстро.
И так вся статья.Rock_N_Roll_Queen
14.12.2016 14:10+1Я думаю, что программисты, в первую очередь, не любят описывать технический дизайн системы не потому, что не могут его спроектировать, а именно потому, что его надо «описать». А значит надо подобрать слова, использовать правильные термины, четко и кратко сформулировать мысли. Знаю разработчиков, для которых написать программу и показать ее работу гораздо легче, чем объяснить как она работает на пальцах «не программисту». Согласитесь, не всем дано красиво выражать свои мысли, для многих это сложная и неприятная задача.
По поводу поиска решений для большого количества задач:
Если я правильно понимаю автора статьи, идея как раз в том, что проектированием занимается не один выделенный человек, а практически вся команда. В таком случае, даже если у кого-то возникает «паралич от анализа», то остальная команда продолжает генерировать идеи и решения. При чем команда состоит не только из разработчиков, а значит может подойти к решению проблемы с разных сторон.
Можно провести аналогию с подбором команды в «Что? Где? Когда?»: чем сильнее отличаются по опыту, образованию и увлечениям члены команды, тем больше шансов, что при ответе на вопрос, хоть кто-нибудь будет понимать о чем речь, знаком с темой или знать «тонкости» области вопроса.Askofen
14.12.2016 19:08+1Я думаю, что программисты, в первую очередь, не любят описывать технический дизайн системы не потому, что не могут его спроектировать, а именно потому, что его надо «описать».
Умение писать техническую документацию входит в квалификационные требования к инженеру. Вряд ли кому из программистов не приходилось писать пояснительную записку к дипломной работе. Также в институте было много и курсовых, и лабораторных работ.
А значит надо подобрать слова, использовать правильные термины, четко и кратко сформулировать мысли.
Это действительно задача. Мне было бы интересно узнать, какие решения предлагает автор статьи. В свою очередь, я бы мог предложить использовать шаблоны документов. Также у нас не требуется писать длинный текст. Используем диаграммы и пару-тройку конкретных фраз, описывающих идею решения. Если мы пишем техническую документацию, то только для инженера, который будет все это реализовывать. Как правило, это один и тот же человек. Нет необходимости соблюдать излишние формальности и писать общие фразы.
Если я правильно понимаю автора статьи, идея как раз в том, что проектированием занимается не один выделенный человек, а практически вся команда. В таком случае, даже если у кого-то возникает «паралич от анализа», то остальная команда продолжает генерировать идеи и решения.
На мой взгляд, это не поможет, т.к. «паралич от анализа» появляется не из-за малого количества людей, работающих над задачей, а из-за наличия множества (порой, мелких) взаимосвязанных задач, и решение каждой из этих задач приводит к возникновению новых задач, которые могут перечеркнуть намеченные решения предыдущих задач.dkiz
15.12.2016 09:17+1Насчет технической документации.
Да, у нас есть шаблон, так и называется «Шаблон тех. проекта». А еще есть чеклисты по инициации проектирования, организации обсуждений, исследованию. Это все не строго обязательно, просто упрощает документирование.
У нас документ «по-крупному» должен содержать 4 раздела:
- В разделе «Открытые вопросы» зафиксированы текущие вопросы, которые необходимо обсудить на ближайшем совещании, либо вопросы, на которые нужно ответить к ближайшему обсуждению.
- Раздел «Решения» состоит из текущих прорабатываемых вариантов решений, итоговой оценки трудоемкости, мокапов, скриншотов прототипов. Для предлагаемых вариантов выделяются плюсы и минусы в виде таблицы.
- В раздел «Приложения» переносятся:
- закрытые вопросы;
- результаты исследований;
- ссылки на связанные документы;
- прочая вспомогательная информация.
- При согласовании документа с заказчиком, рекомендуется выделять вверху документа раздел «Аннотации» с кратким содержанием и выводами.
При этом документы получаются короткими, воду лить не нужно. Описать решение тому, кто его придумал обычно не сложно, плюсы и минусы тоже. В документ пишут все участники команды. Проектная документация на спринт команды из 6 человек — 5-6 страниц (с картинками).Lofer
15.12.2016 14:55У нас документ «по-крупному» должен содержать 4 раздела:
Это фактически у вас работа с рисками: идентификация и анализ/оценка рисков.
Это внутренний документ для управления проектом :) это не техническая документация :))
Ваш ревью спринта, если верно понял, будет привязан к этой «табличке»?
так и называется «Шаблон тех. проекта»
Обычно, это часть PreSale, это тоже не тех документация проекта, и обычно идет в свободной форме что бы " не морщить мозг". По идее этот документ сопровождается бюджетом проекта/решения?
dkiz
15.12.2016 09:36+1По поводу «аналитического паралича».
Из личного опыта я усвоил, что командная работа от него спасает не всегда. «Закапываться» и «залипать» впятером можно так же, как и одному.
На мой взгляд решение стоит искать в других подходах (предупреждаю, они не всем подойдут):
- Не пытаться придумать заранее детальное решение всех проблем. Сделать схему по-крупному с зависимостями, а дальше двигаться: каждый спринт брать кусочек, проектировать и сразу делать. Если при этом возникнут проблемы с уже сделанным — дорабатывать старое или даже переделывать (переделки очень тонкий момент, обсудите с заказчиком заранее). Со временем ваше понимание и знания увеличиваются и вы находите решения, которые не нашли бы находясь в «аналитическом параличе».
- Урезать функциональность. Бывает просят кучу вещей, которые друг другу противоречат. Тогда помогает сначала понять, что действительно важно, донести это до заказчика/стейкхолдера и выкинуть лишнее. Так вы уменьшите количество связанных задач и распутать «клубок» будет легче.
- Проектировать от кейсов пользователей. Обычно кейсы реальной жизни противоречат друг другу реже, чем написанные кем-то «требования».
- Периодически оценивать трудоемкость фич. Наверняка у вас есть максимальная цена в совокупности для всего проекта. Чаще всего нет смысла проектировать фичи, которые вы не будете делать. Если вы оцените весь «клубок» и выясните, что у вас превышение бюджета в два раза переходите к пункту «урезать функциональность».
- Чаще обсуждать проблему. Я имею ввиду не только обсуждения в команде, но и с владельцем продукта, заказчиком. Совет спорный, все таки это затраты времени, но проверено на себе: в случае «паралича» это встряхивает проектировщиков и некоторые проблемы решаются сами собой.
Lofer
14.12.2016 14:14Предположу, что поскольку
Мы начали внедрять Scrum с 2011 года.
…
релизный цикл у нас состоит из 6 спринтов разработки
…
длительность итерации – 12 рабочих дней.
…
предметная область — ЕСМ и все что вокруг ЕСМ.
Долгая работа в одной предметной области и уже есть какие «шаблонные» решения :)
Все типовые риски и проблемы уже устранены в этих «шаблонных» решениях и давно :)
И это далеко не заслуга Scrum. После, не означает в следствии.dkiz
14.12.2016 18:24Вы правы, со временем так или иначе начинаешь работать эффективнее и процессы становятся отлаженными.
Почему я упомянул Scrum?
Потому что он в моем случае подталкивал к таким решениям. Командная работа подталкивает к командному проектированию. Итерационная разработка заставляет искать способы ускорения процесса. Ретро это отличный способ работы над улучшениями — вопросы проектирования на ретро поднимаются чаще всех остальных, даже сейчас.Lofer
14.12.2016 18:30Можно было бы привести еще пару методологий с фишками «ревью».
Возможно, я сильно ошибаюсь, но что-то у вас от карго культа получилось:)
Но если у вас оно работает и приносит пользу — не мне судить :)
А за метрики и детали — спасибо :)
dkiz
14.12.2016 18:12Уже ответили про документирование, примерно того же мнения придерживаюсь и я.
Вы подняли интересную тему «analysis paralysis». Я с ней сталкивался сам, пытался решить разными способами и Вы совершенно правы: нанять аналитика это не решение, он впадет в такой паралич часто быстрее разработчика. Проблема сложная и возможно заслуживает отдельного анализа и статьи. Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?Askofen
15.12.2016 15:51Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?
В качестве ещё одной сложности можно взять миф 2 из Вашей статьи — это опытный проектировщик, который является «бутылочным горлышком», и вся команда фактически вынуждена ждать, пока он не разработает решение.
Вы, конечно, пишите, что в выработке технического решения должна принимать участие вся команда. Но что делать, если остальные не тянут? Например, могут сделать работу по заранее известному шаблону, но не могут справиться с клубком задач (помните, про «паралич от анализа»?) и выработать приемлемые решения.
Что Вы делаете, чтобы занять проектированием всю команду? Как выстраиваете работу команды с опытным проектировщиком? Как неопытные сотрудники обучаются? Тут тоже целый клубок задач.dkiz
16.12.2016 12:27+1Ваши вопросы относятся к теме развития людей и команды, это большая и важная тема. Может быть напишу и по ней статью.
Кратко по тому, как работаем мы: команды периодически перетасовываем по чуть-чуть, но стараемся сделать так, чтобы в каждой команде всегда был опытный проектировщик, в идеале — два. Проектирование всегда парное, если есть только один сильный проектировщик — он проектирует парно с кем-то из способных новичков, обычно за несколько месяцев тот прокачивается до хорошего уровня.
Пара проектировщиков и аналитик начинают проектирование как можно раньше, команда в это время занимается понятными задачами, техдолгом, поддержкой продуктива. По мере понимания задачи команда подключается к прототипированию, проработке конкретных деталей.
MonkAlex
14.12.2016 22:52программисты любят писать код и не любят описывать технический дизайн системы
Я даже слов то таких страшных не знаю, как техдизайн. Судя по дальнейшему описанию вариантов, у вас какой то свой кейс, но я его так и не понял.
Третий вариант вроде частично понятен — но тут как раз спасает скрам команда, в которой всегда найдется или более опытный (или достаточно опытный) коллега, с которым можно обсудить проблему и прийти к её решению.
ПС: я может совсем промахнулся и не понял о чём речь, можете игнорить меня =)Askofen
14.12.2016 23:29Я даже слов то таких страшных не знаю, как техдизайн.
К сожалению, в России и на просторах СНГ это сильно зависит от компании, в которой работаешь, и от проектов, над которыми работаешь. Опытный флэшер может сделать пару-тройку мини-игр за месяц. С другой стороны, некоторые игровые AAA-тайтлы выпускаются командами из 200 человек за полтора-два года.
На всякий случай, я пишу не о мини-проектах, каждый из которых можно сделать за одну-две человеко-недели, а о более крупных проектах, для которых требуется 2-3 человеко-года.
Хотя и для разработки небольшого проекта требуется продуманный технический дизайн. Как правило, это скелет программы, который слабо меняется от приложения к приложению. Тот же флэшер, клепающий мини-игры пачками, от игры к игре использует наработанную кода-базу.
тут как раз спасает скрам команда, в которой всегда найдется или более опытный (или достаточно опытный) коллега
Вы предлагаете не решение задачи, а возможность переложить его на плечи более опытного коллеги. А если такого коллеги нет? Или решение целого клубка задач требуют именно от Вас?MonkAlex
15.12.2016 02:04Если я неправильно вырываю мысли из ваших текстов, говорите сразу, каждый по своему мыслит же.
скелет программы, который слабо меняется от приложения к приложению
Вот это в принципе не существует, на мой взгляд. Есть фреймворки, которые позволяют однотипную работу на них сгрузить, но чтобы прям скелет? Это уже какой то движок готовый, к которому только цвет кнопочек под заказчика менять.
Вы предлагаете не решение задачи, а возможность переложить его на плечи более опытного коллеги. А если такого коллеги нет? Или решение целого клубка задач требуют именно от Вас?
Ну если вопрос целиком на мне — я его и решу. Вопрос всегда решаем, но обычно далеко не всех устраивает цена, после чего нужно накидать разные варианты цена\качество, а накидать их как раз надо на проектировании… возвращаемся к топику.
Сложные вопросы (не обязательно технически, но и логически, оно часто связано, хоть и не всегда) — проектирование, простые — на реализации.
http2
Кого еще харит скрам-хайп, ставим плюсик. :)
MonkAlex
А по русски? А то я понял только часть после запятой =)
ServPonomarev
харит — harrasment — домогательство
MonkAlex
Вот и меня удивил этот комментарий, ибо гугл меня вывел куда-то…
http2
У Гугла выдача согласно предпочтений пользователя… :)
http2
Нужно было ставить плюсик.
http://teenslang.su/id/11687
MonkAlex
Я боюсь ставить плюс тому, что не на русском, да и к статье относится вряд ли.
Статья про проектирование, а вы ругаетесь =)
http2
А на каком же? На австро-венгерском?
Так мой же коммент не о ругани.
:)
dkiz
Мне кажется «скрам-хайп» был актуален лет 5 назад, как раз тогда мы на него и перешли. С тем, что он с тех пор набил оскомину соглашусь, но все таки методологий управления разработкой не так уж и много, повторения неизбежны.
А фишка в том, что взять методологию — это половина дела, надо еще адаптировать ее под себя. И я как раз scrum не пиарю, он в этом не нуждается, а просто делюсь наблюдениями за эти 5 лет.
http2
Хайп наблюдается в последнее время на хабросайте. :)
Вот именно, что все эти методологии — сырые. Это примерно что заставить дурака богу молиться.
Здравый смысл — самая лучшая методология.