Здравствуйте, дорогой читатель! В предыдущем статья Я рассказал о том, как 28 разработчиков смогли построить рабочий процесс, в котором нет управленческой роли.
Мы продолжаем работать с удовольствием и выпускаем сложные функции одну за другой.
Скоро нас ждут бессонные ночи перед релизом.
А дальше самый приятный этап — технический спринт и реализация ретро-релиза, а также планирование деятельности для следующего релиза.
Сегодня я расскажу о мероприятиях, которые обеспечивают максимальную прозрачность рабочего процесса и позволяют разработчикам не оставаться в стороне от событий, происходящих в компании в целом и в других командах в частности.
Хотите выстроить качественные процессы и работать с удовольствием? Добро пожаловать коту! 
Прежде чем продолжить делиться своим опытом организации процесса разработки, хочу прояснить пару вопросов, касающихся специфики компании.
Структура бизнеса компании предполагает собственную разработку продукта и последующую продажу решения клиентам.
Помимо отдела разработки в компании есть отдел маркетинга, отдел продаж и другие отделы.
Это во многом определяет возможность прямого взаимодействия с продуктовым аналитиком, который является поставщиком основных требований к продукту.
В обычном понимании у нас нет стороннего клиента.
Мы сами разрабатываем требования, сами их разрабатываем и сами их продаем.
Традиционная продовольственная компания.
Однако я настаиваю на том, что опыт организации процессов между командами разработки и разработчиков внутри команд можно использовать как пример построения процессов в вашей компании, будь то разработчик аутсорс-решений или продуктовая компания.
Классический Скрам «по книге», как показывает опыт, неприменим в реалиях разработки реальных продуктов, и именно поэтому специфика продукта определяет специфику процессов.
Напомню, что в нашей компании на данный момент работают 28 разработчиков.
То, что работает для 7 команд (по четыре разработчика в каждой), может оказаться непрактичным для 15 команд, и наоборот. В то же время как разработка высококачественной архитектуры кодовой базы, так и построение высококачественных процессов подразумевают свободу масштабирования без больших затрат. Кроме того, в большинстве компаний отдел разработки одного направления крупного продукта состоит всего из 5-7 команд (20-30 человек).
Такой отдел, как правило, имеет свободу принимать самостоятельные архитектурные решения, свободу организовывать внутренние взаимодействия и выстраивать процессы.
Узнайте больше о семействе продуктов Renga (осторожно, маркетинг!) Ренга Архитектура – система архитектурно-строительного проектирования.
Программа создана для оказания максимальной помощи проектировщику в решении его задач: создание архитектурного облика здания и информационной модели, быстрая компоновка чертежей в соответствии со стандартами СПДС и многое другое.
Структура Ренга — система проектирования конструктивной части зданий/сооружений.
Программа для инженеров-строителей и проектировщиков для создания информационной модели здания или сооружения и получения чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Ренга предназначен для проектирования с использованием технологии BIM. Высокая производительность систем позволяет работать с крупными проектами без видимого снижения качества работы с 3D-моделью: Объектный дизайн Создание 3D модели здания/сооружения в Renga с использованием инструментов проектирования объектов (стена, колонна, окно и т.д.) Командная работа Обмен, хранение и управление данными осуществляется с помощью BIM-Server Pilot. Взаимодействие с системами учета затрат. Интеграция Renga через API с системами 1С-смета и АВС-смета для взаимодействия проектно-сметного отдела.
Обмен данными Renga позволяет обмениваться данными с другими системами в различных форматах (.
ifc, .
dwg, .
dxf, .
obj, .
dae, .
stl, .
3ds, .
lwo и .
csv).
Автоматизация получения спецификаций и ведомостей В Renga имеется функция получения отчетов для формирования спецификаций, ведомостей и пояснений.
Автоматизация получения чертежей На основе данных 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
Итак, 5-7 команд, разрабатывающих свой продукт. Как построить процесс без участия менеджера? В первой части статьи я уже рассказывал о таких видах деятельности, как груминг, планирование и ретро-команды.
Далее мы поговорим о деятельности, позволяющей синхронизировать работу нескольких команд и двигаться в одном направлении.
Пример проекта в Renga Structure
Синхронизация команд
Продолжительность нашего спринта составляет десять рабочих дней.Между спринтами есть два дня для демонстрации, ретроспективы и планирования.
Если между спринтами есть два дня на ретро, демо и планирование, это не значит, что в течение этих двух дней код не пишется.
Это означает, что в эти дни деятельность имеет более высокий приоритет, чем написание кода.
Эти два дня являются хорошим буфером для амортизации недооценок/переоценок в спринте.
Синхронизация команды — это деятельность, не привязанная к расписанию спринта.
Эта синхронизация происходит каждую пятницу в одно и то же время после обеда.
При синхронизации присутствуют все разработчики, тестировщики и продуктовые аналитики.
В общем смысле, командная синхронизация — это стендап, где по одному разработчику от каждой команды выступает и рассказывает о том, что сделала команда, какие части кода были затронуты и как это может повлиять на другие команды.
Часто в компаниях синхронизация проводится в форме встречи руководителей команд. У этого подхода есть недостаток, о котором я подробно говорил в предыдущей статье: один человек может забыть, не обратить внимание на многие детали, важные для других.
Таким образом, синхронизация тимлидов экономит время команд, но существенно ухудшает качество коммуникаций.
Подразумевается, что после такой встречи тимлид каждый будет рассказывать своей команде о прогрессе других команд, что опять же будет тратить время каждой команды.
Вот здесь и проявляется минус «глухого телефона» при передаче знаний от тимлида команде.
Таким образом, команда остаётся как бы «в стороне» от работы других команд, общаясь только через тимлида.
В результате снижается интерес и увеличивается разрыв в понимании общего движения развития всего отдела.
Экономия командного времени никак не может перекрыть недостатки оторванности от общего направления разработки и общения между разработчиками.
После каждого выступления команды, как правило, уточняющие вопросы задаются любому из присутствующих.
Если кто-то понимает, что ответ на вопрос перерастает в отстраненное, продолжительное обсуждение, то он может прервать диалог и предложить перенести его на другое время.
Таким образом, синхронизация семи команд длится не более сорока минут и позволяет всем разработчикам оставаться в потоке разработки продукта другими командами.
Еще один важный аспект, который обсуждается во время синхронизации, — обновление сроков разработки.
Обычно каждые две недели команды публично оценивают свои шансы «сделать релиз вовремя».
В ходе обсуждения становится понятно, какая команда не успевает, а какая выполняет задачи в срок.
Кроме того, благодаря присутствию продуктовых аналитиков можно менять приоритеты развития.
Например, одна команда не успевает выпустить функционал к релизу.
У другой команды тоже нет времени, но аналитик понимает, что бизнес-ценность работы первой команды выше, поэтому вторая команда откладывает запланированный к выпуску функционал и помогает первой команде закончить работу в срок.
Важно, чтобы каждый член команды услышал доводы и аргументы, которые привели к такому решению.
Я уверен, что в большинстве компаний, где такое решение было принято во время синхронизации тимлидов, у команд возникло явное непонимание, почему одни функции важнее, а другие нет. Здесь можно задавать все вопросы и не должно оставаться неясных моментов.
Результатом такой синхронизации является осознание и принятие каждым участником процесса разработки текущих сроков и приоритетов развития.
Также каждый участник понимает текущие изменения в различных частях кода приложения, что позволяет избежать недоразумений при мержах, конфликтах версий и других неожиданных изменениях в работе приложения.
Пример проекта в Renga Architecture
Демо
Еще одно занятие, позволяющее быть в курсе изменений продукта, происходит уже не на уровне кода, а на уровне пользователя — демо.Демо проводится на следующий день после завершения спринта.
Демо-версия организована аналитиками продукта для всех заинтересованных сторон продукта — инвесторов, отдела маркетинга, руководителей компании и отделов внутренних разработок.
Демонстрацию проводят аналитики команды, каждый из которых представляет функциональность продукта, который был разработан, протестирован и объединен в основную ветку разработки.
Каждый демонстрационный сценарий перед показом проверяется на соответствие требованиям (Определение готовности).
Важно понимать, что демо-версии никогда не показывают незавершенные функции или сценарии.
Подразумевается, что любой скрипт, показанный в демо-версии, имеет хорошие шансы быть использован конечным пользователем продукта без каких-либо ошибок.
В процессе показа сценария, как правило, поясняется основная мотивация разработки этой возможности и показываются основные пользовательские сценарии работы.
После завершения сценария все присутствующие могут задавать вопросы.
Как правило, стейкхолдеры уточняют тонкости фичи, отдел маркетинга уточняет применимость фичи для клиента и некоторые особенности реализации, высказывает пожелания по улучшению.
Не раз в процессе показа в отдел маркетинга поступали запросы на улучшение функций, которые были добавлены в план разработки на следующие спринты.
Результатом демо является публикация очередного приращения функционала продукта для всех заинтересованных лиц.
Благодаря присутствию на демо разработчиков, тестировщиков и сотрудников отдела маркетинга проясняются многие моменты и происходит обмен актуальной информацией о сценариях работы продукта.
Такая прозрачность знаний о продукте минимизирует различия в ожиданиях от того или иного функционала и позволяет быстро реагировать на любые предложения.
Ретро-релиз
Одно из самых длительных и трудоемких мероприятий — выпуск ретро.Это занятие длится около 5 часов с перерывом на обед. Ведущим ретро-мероприятия может стать любой желающий, но, как правило, его проводят руководители-евангелисты.
Ретро-релиз разделен на несколько блоков смысловых задач, выполняемых каждой командой.
По результатам каждого задания появляется определенный артефакт, например, карта успеха, карта разочарования, карта полезных и мешающих моментов во время релиза.
Каждый такой артефакт презентуют, как правило, разные участники команды.
В результате ретро каждая команда учитывает положительные практики других команд и пытается найти решение негативных моментов в методах работы других команд. Каждый ретро-релиз призван повысить прозрачность практик внутри каждой команды и помочь командам обсуждать различные подходы к решению проблем, возникающих в ходе разработки.
Пожалуй, ретро-релиз — самое интересное и полезное мероприятие из всех мероприятий, проводимых в компании.
За короткое время все команды обмениваются положительным и отрицательным опытом, помогают друг другу находить решения проблем в организации рабочего процесса, оценке задач и написании описаний к фичам.
Тайная комната
Секретная комната — это наша демонстрационная комната, где и происходят все описанные действия.Здесь есть все необходимое – флип-чарты, таблицы по количеству команд, доски и проектор.
В нашем отделе разработки есть много конструктивных упоминаний о Гарри Поттере.
У нас есть Сириус, Рейвенкло и даже Орден Феникса, но об этом в будущих статьях.
В нашем отделе разработки много отсылок к Гарри Поттеру.
Вместо заключения
В комментариях к предыдущей статье было высказано предположение, что в таком процессе «без менеджеров» слишком много времени разработчиков тратится на встречи.Я позволил себе оценить отвлекающие факторы этой деятельности.
В чистом времени на стендапы уходит около 0,4 часа, на планирование — 5 часов, на ретро — 2 часа, на демо — 2 часа.
28*0,4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа за 12 дней на 28 человек или 1 час в день на человека .
Я не принял во внимание такие мероприятия, как code-review и архитектурные обсуждения, поскольку считаю их неотъемлемой частью процесса разработки.
Поделитесь, пожалуйста, сколько времени вы (или ваши команды) тратите на деятельность помимо разработки? На мой взгляд, 1 час в день «поговорить» — это очень небольшая цена за распространение знаний, отражение команд и повышение прозрачности.
Анатолий Осокин, ведущий инженер-программист Renga Software.
Теги: #bim #bim Systems #scrum #agile #процесс разработки #ретро #груминг #планирование #планирование #CAD/CAM #управление разработкой #agile #Карьера в ИТ-индустрии
-
Задачи Хорошего Системного Инженера
19 Oct, 24 -
Каковы Особенности Хостинга Для Windows?
19 Oct, 24 -
Делаем Это Онлайн
19 Oct, 24 -
12 Неписаных Правил В Дизайне
19 Oct, 24 -
Неожиданная Угроза: Объекты В Файлах Rtf
19 Oct, 24
