Роли
В этом нашем Scrum-Based LeSS-Like мы выделяем 5 ролей, хотя скрам подразумевает всего 3.
Chief Product Owner - Имеет верхнеуровневое видение вектора развития продукта в целом. Взаимодействует с продуктовыми командами, передает это видение.
Area Product Owner - отвечает за определенную зону продукта. Приоритезирует задачи в бэклоге зоны, чтобы максимизировать ценность своей зоны продукта; Плотно работает с командами в своей зоне;
Product developer - создает качественный регулярный инкремент в продукт. Обычно работают со своим APO;
Product IT Manager - помогает разработчикам продукта поддерживать вектор развития инженерных практик и процессов разработки. И индивидуального развития самих разработчиков;
Scrum master - поддерживает и развивает процессы нашего фреймворка. В нашей команде нет выделенного человека на этой роли, но я считаю что справляемся неплохо и своими силами.
В этом нашем Scrum-Based LeSS-Like мы выделяем 5 ролей, хотя скрам подразумевает всего 3.
Chief Product Owner - Имеет верхнеуровневое видение вектора развития продукта в целом. Взаимодействует с продуктовыми командами, передает это видение.
Area Product Owner - отвечает за определенную зону продукта. Приоритезирует задачи в бэклоге зоны, чтобы максимизировать ценность своей зоны продукта; Плотно работает с командами в своей зоне;
Product developer - создает качественный регулярный инкремент в продукт. Обычно работают со своим APO;
Product IT Manager - помогает разработчикам продукта поддерживать вектор развития инженерных практик и процессов разработки. И индивидуального развития самих разработчиков;
Scrum master - поддерживает и развивает процессы нашего фреймворка. В нашей команде нет выделенного человека на этой роли, но я считаю что справляемся неплохо и своими силами.
Запись в трудовой
Нас, айтишников, в продукте примерно сто-двести человек. То, что написано в трудовой, кажется формальностью.
Но на подсознательном уровне узко-специализированная должность, например, “инженер по тестированию”, может быть стоп-фактором, чтобы начать погружаться в вёрстку. Поэтому сейчас запущен процесс переоформления должностей, чтобы в трудовой так и было написано: “продуктовый разработчик”.
Нас, айтишников, в продукте примерно сто-двести человек. То, что написано в трудовой, кажется формальностью.
Но на подсознательном уровне узко-специализированная должность, например, “инженер по тестированию”, может быть стоп-фактором, чтобы начать погружаться в вёрстку. Поэтому сейчас запущен процесс переоформления должностей, чтобы в трудовой так и было написано: “продуктовый разработчик”.
Ок. Теперь ты продуктовый разработчик. Что дальше?
В серии из 4 постов расскажу о цикле разработки с точки зрения изнутри.
Часть 1 - проработка бэклога.
Работа над задачей начинается гораздо раньше, чем у программиста. До взятия задачи в спринт, команда проясняет все вопросы.
📌- Выпытывает у владельца продукта критерии приемки;
📌- Проводит предоценку: сколько примерно задача принесет денег, и сколько будет стоить в разработке;
📌- Прорабатывает все архитектурные аспекты;
📌- Согласовывает будущие изменения со всеми внешними заинтересованными сторонами;
📌- Понимает, как будет проводить постоценку;
📌- Решает, какой нужен мониторинг работоспособности фичи после спринта;
📌- Составляет верхнеуровневый план спринта.
Это не исчерпывающий список, я покажу наш Definition of Ready for sprint (DoR) позже.
В серии из 4 постов расскажу о цикле разработки с точки зрения изнутри.
Часть 1 - проработка бэклога.
Работа над задачей начинается гораздо раньше, чем у программиста. До взятия задачи в спринт, команда проясняет все вопросы.
📌- Выпытывает у владельца продукта критерии приемки;
📌- Проводит предоценку: сколько примерно задача принесет денег, и сколько будет стоить в разработке;
📌- Прорабатывает все архитектурные аспекты;
📌- Согласовывает будущие изменения со всеми внешними заинтересованными сторонами;
📌- Понимает, как будет проводить постоценку;
📌- Решает, какой нужен мониторинг работоспособности фичи после спринта;
📌- Составляет верхнеуровневый план спринта.
Это не исчерпывающий список, я покажу наш Definition of Ready for sprint (DoR) позже.
Часть 2 - планирование спринта
Спринт начинается с планирования. Чем лучше команда подготовит задачу к спринту, тем быстрее и проще пройдет планирование. Чем четче планирование, тем больше вероятность что мы не отклонимся от плана в спринте. Если идти по плану в спринте, то с большой вероятностью на выходе получится то, чего мы ожидали.
На планировании мы декомпозируем предварительный план на задачи размером не больше дня. Участники берут на себя задачи и распределяют их по дням. При этом желательно оставить время на проработку бэклога и на улучшение процессов и инженерных практик.
После планирования команда расходится работать. Работа может быть как парной, так и индивидуальной. Но каждый понимает вклад его индивидуальной работы в общую цель спринта.
Общая цель - на мой взгляд основное отличие команды от рабочей группы. Конец планирования ознаменует для нас очередную возможность сделать что-то полезное. Мы не фанатики, но в конце планирования в шутку поздравляем друг друга с началом нового спринта🚀
Спринт начинается с планирования. Чем лучше команда подготовит задачу к спринту, тем быстрее и проще пройдет планирование. Чем четче планирование, тем больше вероятность что мы не отклонимся от плана в спринте. Если идти по плану в спринте, то с большой вероятностью на выходе получится то, чего мы ожидали.
На планировании мы декомпозируем предварительный план на задачи размером не больше дня. Участники берут на себя задачи и распределяют их по дням. При этом желательно оставить время на проработку бэклога и на улучшение процессов и инженерных практик.
После планирования команда расходится работать. Работа может быть как парной, так и индивидуальной. Но каждый понимает вклад его индивидуальной работы в общую цель спринта.
Общая цель - на мой взгляд основное отличие команды от рабочей группы. Конец планирования ознаменует для нас очередную возможность сделать что-то полезное. Мы не фанатики, но в конце планирования в шутку поздравляем друг друга с началом нового спринта🚀
Часть 3 - работа в спринте
Иногда рабочие группы проводят ритуал, называемый стендапом. Они встают в проходе и по очереди рассказывают, кто чем занимался вчера и чем планирует заниматься сегодня. Как у рабочей группы нет общей цели, так и у этого ритуала нет смысла.
Каждое утро команда собирается, чтобы ответить на один вопрос: "всё ли идёт по плану?" Даже при идеальном планировании может случиться влёт. В таком случае нужно либо срезать часть работы, либо использовать резервное время. Если его заложили, конечно. Сидеть вечерами - точно не путь к успеху. Это путь к выгоранию. Лучше как можно раньше увидеть отклонение от плана и договориться с владельцем продукта о срезании каких-то критериев приемки.
Если всё по плану, релиз случается в начале-середине второй недели. Это дает возможность успеть собрать первую обратную связь от вселенной к концу спринта. Обратной связью могут быть например метрики или интервью с пользователями.
Собирать эту обратную связь может тот же самый разработчик, который вот буквально вчера дописал код.
Скажу за себя: через сбор обратной связи я понимаю реальную полезность этого кода.
Иногда рабочие группы проводят ритуал, называемый стендапом. Они встают в проходе и по очереди рассказывают, кто чем занимался вчера и чем планирует заниматься сегодня. Как у рабочей группы нет общей цели, так и у этого ритуала нет смысла.
Каждое утро команда собирается, чтобы ответить на один вопрос: "всё ли идёт по плану?" Даже при идеальном планировании может случиться влёт. В таком случае нужно либо срезать часть работы, либо использовать резервное время. Если его заложили, конечно. Сидеть вечерами - точно не путь к успеху. Это путь к выгоранию. Лучше как можно раньше увидеть отклонение от плана и договориться с владельцем продукта о срезании каких-то критериев приемки.
Если всё по плану, релиз случается в начале-середине второй недели. Это дает возможность успеть собрать первую обратную связь от вселенной к концу спринта. Обратной связью могут быть например метрики или интервью с пользователями.
Собирать эту обратную связь может тот же самый разработчик, который вот буквально вчера дописал код.
Скажу за себя: через сбор обратной связи я понимаю реальную полезность этого кода.
Часть 4 - ревью спринта
В конце спринта происходит встреча всех команд продукта. Кто-то называет это событие Демо. Раньше у нас тоже было демо. Но в какой-то момент мы изменили формат встречи и теперь проводим ревью спринта.
Демо - полезное мероприятие, чтобы сделать более прозрачной работу смежных команд. Оно дает возможность видеть, какие фичи рождаются в продукте, понимать какие компоненты есть в продукте и как их можно переиспользовать.
Ревью спринта кроме демонстрации подразумевает еще сбор обратной связи. Обратная связь может исходить от коллег. Или от живых пользователей. На спринт ревью можно сразу озвучить предварительную постоценку фичи.
Спринт ревью на мой взгляд приносит больше ценности и продукту и разработчикам. Оно дает возможность видеть пользу от себя и коллег, получить обратную связь, выявить риски и запарковать в бэклог новые гипотезы.
В конце спринта происходит встреча всех команд продукта. Кто-то называет это событие Демо. Раньше у нас тоже было демо. Но в какой-то момент мы изменили формат встречи и теперь проводим ревью спринта.
Демо - полезное мероприятие, чтобы сделать более прозрачной работу смежных команд. Оно дает возможность видеть, какие фичи рождаются в продукте, понимать какие компоненты есть в продукте и как их можно переиспользовать.
Ревью спринта кроме демонстрации подразумевает еще сбор обратной связи. Обратная связь может исходить от коллег. Или от живых пользователей. На спринт ревью можно сразу озвучить предварительную постоценку фичи.
Спринт ревью на мой взгляд приносит больше ценности и продукту и разработчикам. Оно дает возможность видеть пользу от себя и коллег, получить обратную связь, выявить риски и запарковать в бэклог новые гипотезы.
Как ретроспектива отражает этап становления команды
Цель ретроспективы - проинспектировать процесс и договориться об изменениях.
Мы ощутили на себе все этапы по Брюсу Такмену, и ретро спринта очень наглядно это показывало.
Forming. Сначала мы тупо молчали. Не понятно было, зачем собрались. Не понятно как (или страшно) давать обратную связь. Побухтели, вроде всё норм, разошлись. Никаких решений не приняли.
Storming. Это время киданием говняхами. Сложное время, но неизбежное. Зрелый и самодостаточный персонаж использует это время с пользой. На этом этапе на ретроспективе мы принимали эмоциональные "договоренности", которые сами потом не соблюдали. И это был еще один повод для кидания говняхами.
Norming. Научились давать ненасильственную обратную связь. Пошли первые рабочие решения на ретро. Их всё еще мало, но продуктивность команды уже вышла на уровень почти форминга.
Performing. Не смотря на конец спринта, чувствуется драйв. Есть что обсудить. Ретроспективы проходят динамично, конкретно и с четкими решениями. Обратная связь конструктивная.
Цель ретроспективы - проинспектировать процесс и договориться об изменениях.
Мы ощутили на себе все этапы по Брюсу Такмену, и ретро спринта очень наглядно это показывало.
Forming. Сначала мы тупо молчали. Не понятно было, зачем собрались. Не понятно как (или страшно) давать обратную связь. Побухтели, вроде всё норм, разошлись. Никаких решений не приняли.
Storming. Это время киданием говняхами. Сложное время, но неизбежное. Зрелый и самодостаточный персонаж использует это время с пользой. На этом этапе на ретроспективе мы принимали эмоциональные "договоренности", которые сами потом не соблюдали. И это был еще один повод для кидания говняхами.
Norming. Научились давать ненасильственную обратную связь. Пошли первые рабочие решения на ретро. Их всё еще мало, но продуктивность команды уже вышла на уровень почти форминга.
Performing. Не смотря на конец спринта, чувствуется драйв. Есть что обсудить. Ретроспективы проходят динамично, конкретно и с четкими решениями. Обратная связь конструктивная.
Medium
Forming, Storming, Norming, and Performing
Much like individuals grow and develop over time, so does a team. In a 1965 article in the Psychological Bulletin, Bruce Tuckman introduced a team and group development model that maps a team’s…
Три лайфхака к ретроспективе
Сегодня пятница и у многих ретро. Поделюсь тремя лайфхаками, которые помогают нашей команде извлекать больше пользы из этого события.
1️⃣ Собирать темы во время спринта
Пример из нашего чатика:
#ретро не учли потенциальную нагрузку на сервис и забыли про нагрузочное тестирование. Добавить пункт DoR?
Во время спринта процессные боли или предложения мы паркуем с хэштегом #ретро.
Это позволяет нам не отвлекаться в спринте и иметь актуальные темы для обсуждения на ретроспективе.
2️⃣ Найти свой инструмент
В оффлайне проводили с доской и стикерами.
В условиях удалёнки встал вопрос инструмента: пробовали в гугло-таблицах и Miro. Потом наш PO где-то откопал инструмент https://easyretro.io/
Это простая общая доска со столбцами, куда каждый участник может накидать карточек, ставить лайки и комментировать. Есть шаблоны для разных форматов проведения ретро. Теперь пользуемся им.
3️⃣ Некоторые решения можно отложить
Если тема важная, но обсуждение буксует и сходу принять решение не получается, то есть выход: "Вася составит агенду и проведёт встречу по проблеме в следующем спринте".
Чем четче и понятнее предложение, - тем больше шанс что его примут. Такое предложение обречено на успех. Оно отвечает на вопросы:
- что?
- кто?
- когда?
Сегодня пятница и у многих ретро. Поделюсь тремя лайфхаками, которые помогают нашей команде извлекать больше пользы из этого события.
1️⃣ Собирать темы во время спринта
Пример из нашего чатика:
#ретро не учли потенциальную нагрузку на сервис и забыли про нагрузочное тестирование. Добавить пункт DoR?
Во время спринта процессные боли или предложения мы паркуем с хэштегом #ретро.
Это позволяет нам не отвлекаться в спринте и иметь актуальные темы для обсуждения на ретроспективе.
2️⃣ Найти свой инструмент
В оффлайне проводили с доской и стикерами.
В условиях удалёнки встал вопрос инструмента: пробовали в гугло-таблицах и Miro. Потом наш PO где-то откопал инструмент https://easyretro.io/
Это простая общая доска со столбцами, куда каждый участник может накидать карточек, ставить лайки и комментировать. Есть шаблоны для разных форматов проведения ретро. Теперь пользуемся им.
3️⃣ Некоторые решения можно отложить
Если тема важная, но обсуждение буксует и сходу принять решение не получается, то есть выход: "Вася составит агенду и проведёт встречу по проблеме в следующем спринте".
Чем четче и понятнее предложение, - тем больше шанс что его примут. Такое предложение обречено на успех. Оно отвечает на вопросы:
- что?
- кто?
- когда?
EasyRetro
EasyRetro | Improve your team with fun sprint retrospectives | EasyRetro
Our fun, simple, and intuitive tool will revolutionize your teams collaboration process. Try it today for free and discover how fun retrospectives can help you. | EasyRetro
Discovery vs Delivery, ч.1
Что если разработчик будет не только кодить? Как встроить проработку задач в рабочий процесс разработчика?
В серии из 3 постов расскажу о процессе и профитах для продукта и самого разраба.
Процесс проработки бэклога не очень подробно описан в Scrum, но по идее он подразумевает вовлечение всей команды.
В отличие от проектной работы, в продуктовой разработке задачи попадают в бэклог совсем сырыми.
Перед тем, как думать о коде, нужно доуточнить и согласовать бизнесовую постановку, требования, ожидаемый эффект.
В эту работу не получается продуктивно вовлечь всю команду.
С другой стороны, разделение участников команды на Discovery и Delivery по сути делит команду пополам. Скрам явно не про это.
Ага! Этот ваш скрам не работает!
На помощь приходит Jeff Patton и его Dual-Track development. Он говорит, что Discovery и Delivery - это два направления работы одной команды.
Посмотрите на картинку.
Снизу - спринты Scrum, а сверху что?
- циклы вариативной длины
- непрерывная поставка задач, готовых к спринту
добавим к этому визуализацию процесса через столбцы на доске + лимиты work in progress...
Да это ж Kanban!
Выходит, что мы в этом своём Scrum-based LeSS-like добавляем еще "Kanban-discovered"?
Оригиналная статья Jeff Patton
Адаптация Авито и их опыт
Сравнение Scrum и Kanban от Atlassian
Что если разработчик будет не только кодить? Как встроить проработку задач в рабочий процесс разработчика?
В серии из 3 постов расскажу о процессе и профитах для продукта и самого разраба.
Процесс проработки бэклога не очень подробно описан в Scrum, но по идее он подразумевает вовлечение всей команды.
В отличие от проектной работы, в продуктовой разработке задачи попадают в бэклог совсем сырыми.
Перед тем, как думать о коде, нужно доуточнить и согласовать бизнесовую постановку, требования, ожидаемый эффект.
В эту работу не получается продуктивно вовлечь всю команду.
С другой стороны, разделение участников команды на Discovery и Delivery по сути делит команду пополам. Скрам явно не про это.
Ага! Этот ваш скрам не работает!
На помощь приходит Jeff Patton и его Dual-Track development. Он говорит, что Discovery и Delivery - это два направления работы одной команды.
Посмотрите на картинку.
Снизу - спринты Scrum, а сверху что?
- циклы вариативной длины
- непрерывная поставка задач, готовых к спринту
добавим к этому визуализацию процесса через столбцы на доске + лимиты work in progress...
Да это ж Kanban!
Выходит, что мы в этом своём Scrum-based LeSS-like добавляем еще "Kanban-discovered"?
Оригиналная статья Jeff Patton
Адаптация Авито и их опыт
Сравнение Scrum и Kanban от Atlassian
👍1
Разработчик в Discovery: профит для продукта
Непринуждённым движением программист переодевается в продуктового разработчика.
И вот он уже может участвовать в проработке задачи на ранних этапах.
Прорабатывая задачу, разработчик получает тонну мотивации потом её реализовать. Это теперь _его_ задача, от начала и до конца.
Чем же он может помочь?
📌 В первую очередь, технической экспертизой.
1️⃣ — Примерно оценить стоимость разработки даже сырой задачи.
Можно не тратить время на проработку космических по сложности задач с сомнительным эффектом.
2️⃣ — Предложить вариант решения продуктовой проблемы по принципу Парето.
Иногда срезание 20% объема бизнесовой задачи дают экономию 80% в ресурсах на разработку. Важно: это не должно значить снижение качества решения.
3️⃣ — Знание больных мест системы позволяет протащить задачи по рефакторингу.
После рефакторинга открывается портал в инженерный рай, из которого начинают сыпаться фичи. Мы так случайно приделали новый способ оплаты на платежную форму 🙂
4️⃣ — Откровенно бредовые фантазии решений можно отсечь на раннем этапе.
Лучше узнать подробнее о проблеме и тогда уже предложить адекватное по технике решение.
В таком случае не придется придумывать, как рисовать красные линии зеленым цветом.
Пунктов было больше. Для удобства читателя я разбил пост на два. Отдельно будет про то, как задействовать другое полушарие разработчика.
Непринуждённым движением программист переодевается в продуктового разработчика.
И вот он уже может участвовать в проработке задачи на ранних этапах.
Прорабатывая задачу, разработчик получает тонну мотивации потом её реализовать. Это теперь _его_ задача, от начала и до конца.
Чем же он может помочь?
📌 В первую очередь, технической экспертизой.
1️⃣ — Примерно оценить стоимость разработки даже сырой задачи.
Можно не тратить время на проработку космических по сложности задач с сомнительным эффектом.
2️⃣ — Предложить вариант решения продуктовой проблемы по принципу Парето.
Иногда срезание 20% объема бизнесовой задачи дают экономию 80% в ресурсах на разработку. Важно: это не должно значить снижение качества решения.
3️⃣ — Знание больных мест системы позволяет протащить задачи по рефакторингу.
После рефакторинга открывается портал в инженерный рай, из которого начинают сыпаться фичи. Мы так случайно приделали новый способ оплаты на платежную форму 🙂
4️⃣ — Откровенно бредовые фантазии решений можно отсечь на раннем этапе.
Лучше узнать подробнее о проблеме и тогда уже предложить адекватное по технике решение.
В таком случае не придется придумывать, как рисовать красные линии зеленым цветом.
Пунктов было больше. Для удобства читателя я разбил пост на два. Отдельно будет про то, как задействовать другое полушарие разработчика.
Разработчик в Discovery: профит для разработчика
Так, ладно, допустим для продукта есть польза от привлечения разработчика к проработке задачи.
А мне, разработчику, это зачем?
Скажу за себя:
1️⃣ - Дополнительная мотивация
Прорабатывая задачу, разработчик видит потенциальную ценность для продукта;
2️⃣ - Получение новых навыков
Есть возможность прокачать hard skills типа SQL. Или soft skills, например снять ментальный барьер и начать общаться с людьми за пределами команды;
3️⃣ - Прокачка бизнес-мышления
Научиться мыслить показателями продукта. Это проясняет в голове картинку: зачем, для кого и что разрабатывать;
4️⃣ - Расширение круга общения
Вытекает из необходимости много разговаривать на этапе проработки задачи;
5️⃣ - Справедливое вознаграждение и офигенный буст профессионального роста
Да, если приносить больше пользы для продукта, можно рассчитывать на взаимность. Такое вот откровение.
В общем, я это расцениваю как одну из ветвей эволюции программиста.
Занять ведущую роль в стартапе или известной компании можно только эффективно разбираясь во всех областях IT-разработки, чтобы построить продукт с нуля.
Разработчик продуктов - хороший старт для этой роли.
Так, ладно, допустим для продукта есть польза от привлечения разработчика к проработке задачи.
А мне, разработчику, это зачем?
Скажу за себя:
1️⃣ - Дополнительная мотивация
Прорабатывая задачу, разработчик видит потенциальную ценность для продукта;
2️⃣ - Получение новых навыков
Есть возможность прокачать hard skills типа SQL. Или soft skills, например снять ментальный барьер и начать общаться с людьми за пределами команды;
3️⃣ - Прокачка бизнес-мышления
Научиться мыслить показателями продукта. Это проясняет в голове картинку: зачем, для кого и что разрабатывать;
4️⃣ - Расширение круга общения
Вытекает из необходимости много разговаривать на этапе проработки задачи;
5️⃣ - Справедливое вознаграждение и офигенный буст профессионального роста
Да, если приносить больше пользы для продукта, можно рассчитывать на взаимность. Такое вот откровение.
В общем, я это расцениваю как одну из ветвей эволюции программиста.
Занять ведущую роль в стартапе или известной компании можно только эффективно разбираясь во всех областях IT-разработки, чтобы построить продукт с нуля.
Разработчик продуктов - хороший старт для этой роли.
Что значит «задача сделана». Когда заканчивается работа разработчика?
Для программиста зачастую ответ - «когда я написал код».
Но для бизнеса нет прямой пользы от написанного кода.
Допустим, код дотащили до прода некие третьи лица через месяц. А еще через неделю он перестал работать. И мы узнаём об этом только от пользователей.
Хреново. Особенно, если это произошло ночью, а функция критичная, и звонком будят того самого программиста.
Еще хреновее, если у этого программиста нет возможности быстро понять причину поломки.
Допустим, программист переодевается в продуктового разработчика. Что изменится?
Работа продуктового разработчика заканчивается сильно позже написания своего куска кода.
Он заинтересован в еще нескольких аспектах:
📱 — собрать весь паззл фичи. После того как напедалил свой код, помочь товарищу, чтобы общими силами выдать инкремент.
Это про командную работу. Нет никакой ценности в том, чтобы в конце спринта говорить «фронт готов к релизу, но вот у бэкендеров апи недоделано».
🚀 — вывести фичу в продакшен, чтобы результат его работы начал влиять на пользователя.
Это в том числе про Continious Delivery. Процесс релизов должен быть непрерывным, чтобы катить атомарные релизы. Тогда один релиз будет занимать меньше времени и нести меньше рисков.
📟 — обеспечить жизнеспособность фичи, чтобы результат его работы не сгинул незаметно.
Это про покрытие метриками, мониторинг, логи, трассировку. Нужно узнать о поломке от своего мониторинга, а не от пользователей. И нужно иметь четкий план действий на случай поломки, чтобы проснувшись быстро починить и пойти дальше спать.
В своих постах я призываю программистов расширять свою зону ответственности. Это сложный шаг. Для этого должна быть соответствующая рабочая среда. Это должно быть прозрачно для всех.
Если вы руководитель, то у вас есть возможность обеспечить такую среду. Попробуйте пустить программистов в релиз и сопровождение.
Вот увидите, от этого будет профит для вас, для бизнеса и для самих программистов!
Это версия значения «задача сделана» от Продуктового Разработчика.
А еще мне интересна версия от Тимлида. Мы договорились с Женей Антоновым, что каждый напишет пост на эту тему и мы выпустим их одновременно.
Его версия будет здесь: https://news.1rj.ru/str/general_it_talks/102.
Я её еще не читал, пойду почитаю 🙂
Для программиста зачастую ответ - «когда я написал код».
Но для бизнеса нет прямой пользы от написанного кода.
Допустим, код дотащили до прода некие третьи лица через месяц. А еще через неделю он перестал работать. И мы узнаём об этом только от пользователей.
Хреново. Особенно, если это произошло ночью, а функция критичная, и звонком будят того самого программиста.
Еще хреновее, если у этого программиста нет возможности быстро понять причину поломки.
Допустим, программист переодевается в продуктового разработчика. Что изменится?
Работа продуктового разработчика заканчивается сильно позже написания своего куска кода.
Он заинтересован в еще нескольких аспектах:
📱 — собрать весь паззл фичи. После того как напедалил свой код, помочь товарищу, чтобы общими силами выдать инкремент.
Это про командную работу. Нет никакой ценности в том, чтобы в конце спринта говорить «фронт готов к релизу, но вот у бэкендеров апи недоделано».
🚀 — вывести фичу в продакшен, чтобы результат его работы начал влиять на пользователя.
Это в том числе про Continious Delivery. Процесс релизов должен быть непрерывным, чтобы катить атомарные релизы. Тогда один релиз будет занимать меньше времени и нести меньше рисков.
📟 — обеспечить жизнеспособность фичи, чтобы результат его работы не сгинул незаметно.
Это про покрытие метриками, мониторинг, логи, трассировку. Нужно узнать о поломке от своего мониторинга, а не от пользователей. И нужно иметь четкий план действий на случай поломки, чтобы проснувшись быстро починить и пойти дальше спать.
В своих постах я призываю программистов расширять свою зону ответственности. Это сложный шаг. Для этого должна быть соответствующая рабочая среда. Это должно быть прозрачно для всех.
Если вы руководитель, то у вас есть возможность обеспечить такую среду. Попробуйте пустить программистов в релиз и сопровождение.
Вот увидите, от этого будет профит для вас, для бизнеса и для самих программистов!
Это версия значения «задача сделана» от Продуктового Разработчика.
А еще мне интересна версия от Тимлида. Мы договорились с Женей Антоновым, что каждый напишет пост на эту тему и мы выпустим их одновременно.
Его версия будет здесь: https://news.1rj.ru/str/general_it_talks/102.
Я её еще не читал, пойду почитаю 🙂
👍1
Определение готовности задачи
По мотивам предыдущего поста «Что значит «задача сделана».
В Scrum есть офигенный инструмент, который стоит втащить к себе, даже если у вас другой процесс и вы ненавидите скрам.
Этот инструмент - чеклист Definition of Done.
!Не путать с бизнесовыми критериями приемки!
С помощью DoD можно однозначно договориться, когда говорить «готово».
Делать каждую задачу с соблюдением DoD — способ не рождать техдолг. Потратить чуть больше времени сейчас и не занимать время у себя из будущего.
Есть несколько важных свойств DoD:
— Принадлежит продукту
Не команде и не программному компоненту, а всему продукту. При совместном владении кодом это гарантия стабильного уровня качества продукта, чтобы холакратия не скатилась в раздолбайство.
— Должен быть однозначным и выполнимым
Если хоть один пункт будет непонятным или невыполнимым, это может создавать впечатление необязательности.
Лучше стабильно выполнять слабый DoD из нескольких пунктов, чем игнорировать исчерпывающий но невозможный DoD.
— Составляется разработчиками
Этот пункт следует из предыдущего. Составляя чеклист, разработчики договариваются друг с другом и обязуются выполнять эти договоренности. Нельзя заставить разрабов делать то, чего они не понимают и под чем они не подписывались.
На скрине наш DoD из 12 пунктов. Мы составляли его составом участников из шести команд и потратили на это в сумме 8 часов. С тех пор прошел год, мы получили опыт использования. Наш DoD не идеален, но я точно могу сказать, что он помогает. Мы проходимся по нему на планировании и в конце спринта. Создаем карточки, если забыли о чем-то. Это не только контроль качества, но и шпаргалка: что именно нужно сделать, чтобы было качественно.
Если у вас еще нет DoD, советую начать с нескольких самых простых пунктов и постепенно его дополнять. Не надо рождать сразу исчерпывающий. Попробуйте итерационный подход к формированию DoD.
Эффект будет, вот увидите!
По мотивам предыдущего поста «Что значит «задача сделана».
В Scrum есть офигенный инструмент, который стоит втащить к себе, даже если у вас другой процесс и вы ненавидите скрам.
Этот инструмент - чеклист Definition of Done.
!Не путать с бизнесовыми критериями приемки!
С помощью DoD можно однозначно договориться, когда говорить «готово».
Делать каждую задачу с соблюдением DoD — способ не рождать техдолг. Потратить чуть больше времени сейчас и не занимать время у себя из будущего.
Есть несколько важных свойств DoD:
— Принадлежит продукту
Не команде и не программному компоненту, а всему продукту. При совместном владении кодом это гарантия стабильного уровня качества продукта, чтобы холакратия не скатилась в раздолбайство.
— Должен быть однозначным и выполнимым
Если хоть один пункт будет непонятным или невыполнимым, это может создавать впечатление необязательности.
Лучше стабильно выполнять слабый DoD из нескольких пунктов, чем игнорировать исчерпывающий но невозможный DoD.
— Составляется разработчиками
Этот пункт следует из предыдущего. Составляя чеклист, разработчики договариваются друг с другом и обязуются выполнять эти договоренности. Нельзя заставить разрабов делать то, чего они не понимают и под чем они не подписывались.
На скрине наш DoD из 12 пунктов. Мы составляли его составом участников из шести команд и потратили на это в сумме 8 часов. С тех пор прошел год, мы получили опыт использования. Наш DoD не идеален, но я точно могу сказать, что он помогает. Мы проходимся по нему на планировании и в конце спринта. Создаем карточки, если забыли о чем-то. Это не только контроль качества, но и шпаргалка: что именно нужно сделать, чтобы было качественно.
Если у вас еще нет DoD, советую начать с нескольких самых простых пунктов и постепенно его дополнять. Не надо рождать сразу исчерпывающий. Попробуйте итерационный подход к формированию DoD.
Эффект будет, вот увидите!
❤3
Используете Definition of Done?
Anonymous Poll
43%
Да
43%
Еще нет, но задумался
9%
Нет, не понимаю ценности
5%
Свой вариант в комментариях
Привет! У меня сразу два анонса событий.
Первое - большая онлайн-конфа ТехноРеволюция 2.0 завтра, в субботу, 20 марта.
Я там буду говорить головой о нашей любимой теме продуктовой разработки в 11:20 Мск. Запись будет.
Еще будут господа из SimbirSoft, Точка, ВкусВилл, Ак Барс, Спортмастер, Skillbox, Магнит и других айтишных компаний.
На конфе три потока, разные форматы. Развернутое описание по ссылке выше, что-то наверняка вас заинтересует.
Второе - наш скромный онлайн OpenSpace-митап 1 апреля 19:00 - 21:00 Мск.
Тут не будет докладов и выступлений. Просто соберемся в онлайне и потрындим, где же граница зоны ответственности разработчика.
Приходите и приносите актуалные темы про зоны ответственности разработчика, каждая из которых найдёт заинтересованных в отдельной комнате-станции. Каждый участник сможет поделиться своим опытом и мнением, и услышать других.
Увидимся! 🙂
Первое - большая онлайн-конфа ТехноРеволюция 2.0 завтра, в субботу, 20 марта.
Я там буду говорить головой о нашей любимой теме продуктовой разработки в 11:20 Мск. Запись будет.
Еще будут господа из SimbirSoft, Точка, ВкусВилл, Ак Барс, Спортмастер, Skillbox, Магнит и других айтишных компаний.
На конфе три потока, разные форматы. Развернутое описание по ссылке выше, что-то наверняка вас заинтересует.
Второе - наш скромный онлайн OpenSpace-митап 1 апреля 19:00 - 21:00 Мск.
Тут не будет докладов и выступлений. Просто соберемся в онлайне и потрындим, где же граница зоны ответственности разработчика.
Приходите и приносите актуалные темы про зоны ответственности разработчика, каждая из которых найдёт заинтересованных в отдельной комнате-станции. Каждый участник сможет поделиться своим опытом и мнением, и услышать других.
Увидимся! 🙂
Технический долг — как кредит, ч.1
Техдолг — техническое несовершенство системы, порождённое в момент разработки.
Словосочетание Технический Долг — удобная метафора, чтобы объяснить не-технарям причину замедления поставки ценности.
Давайте попробуем развить эту метафору, чтобы лучше понять причины и следствия, какие виды техдолга бывают и можно ли не порождать техдолг. Пост получился объемным, поэтому для удобства читателя я разбил его на две части.
🏦 Кредит: заёмщик не копит деньги, а берет их у банка. И сразу тратит их на какие-то блага, здесь и сейчас. А далее долгое время регулярно отдает часть своего дохода банку за пользование деньгами. Заёмщик накопил бы нужную сумму быстрее, чем погасит кредит. Он вынужден отказывать себе в других благах. Но он уже пользуется первоначальными благами и платит за это свою цену. Поначалу платёж почти полностью уходит в переплату.
Разумный заёмщик будет гасить тело кредита частичными досрочными погашениями.
🏃♂️Техдолг: разработчики не тратят время на корректное техническое решение. Они поставляют ценность здесь и сейчас. У этого есть цена: замедление поставки ценности в будущем, пока техдолг не будет выплачен. Зачастую техдолг только копится. Со временем поставка ценности становится всё медленнее.
Разумный владелец продукта заинтересован в долгосрочном сохранении скорости поставки, поэтому готов инвестировать во внутреннее качество продукта.
Кредит может быть разумным и ответственным. Например, ипотека. Жить где-то надо, и ипотека может быть решением проблемы. Обычно люди осознанно входят в ипотеку. Они видят график платежей, понимают свой достаток и возможность платить вовремя и без просрочек.
А может быть неразумным или безответственным. Например, микрозайм с целью закрыть очередной платёж по другому микрозайму. Из такой ситуации сложно выйти, она засасывает и негативно влияет на качество жизни.
Мартин Фаулер разделяет техдолг на 4 квадранта, по степени осознанности и ответственности разработчиков, этот техдолг порождающих.
В следующем посте поговорим конкретно об этих видах техдолга, можно ли не порождать техдолг в принципе, и если да, то как.
Техдолг — техническое несовершенство системы, порождённое в момент разработки.
Словосочетание Технический Долг — удобная метафора, чтобы объяснить не-технарям причину замедления поставки ценности.
Давайте попробуем развить эту метафору, чтобы лучше понять причины и следствия, какие виды техдолга бывают и можно ли не порождать техдолг. Пост получился объемным, поэтому для удобства читателя я разбил его на две части.
🏦 Кредит: заёмщик не копит деньги, а берет их у банка. И сразу тратит их на какие-то блага, здесь и сейчас. А далее долгое время регулярно отдает часть своего дохода банку за пользование деньгами. Заёмщик накопил бы нужную сумму быстрее, чем погасит кредит. Он вынужден отказывать себе в других благах. Но он уже пользуется первоначальными благами и платит за это свою цену. Поначалу платёж почти полностью уходит в переплату.
Разумный заёмщик будет гасить тело кредита частичными досрочными погашениями.
🏃♂️Техдолг: разработчики не тратят время на корректное техническое решение. Они поставляют ценность здесь и сейчас. У этого есть цена: замедление поставки ценности в будущем, пока техдолг не будет выплачен. Зачастую техдолг только копится. Со временем поставка ценности становится всё медленнее.
Разумный владелец продукта заинтересован в долгосрочном сохранении скорости поставки, поэтому готов инвестировать во внутреннее качество продукта.
Кредит может быть разумным и ответственным. Например, ипотека. Жить где-то надо, и ипотека может быть решением проблемы. Обычно люди осознанно входят в ипотеку. Они видят график платежей, понимают свой достаток и возможность платить вовремя и без просрочек.
А может быть неразумным или безответственным. Например, микрозайм с целью закрыть очередной платёж по другому микрозайму. Из такой ситуации сложно выйти, она засасывает и негативно влияет на качество жизни.
Мартин Фаулер разделяет техдолг на 4 квадранта, по степени осознанности и ответственности разработчиков, этот техдолг порождающих.
В следующем посте поговорим конкретно об этих видах техдолга, можно ли не порождать техдолг в принципе, и если да, то как.
❤1
Технический долг — как кредит, ч.2
Этот пост - продолжение предыдущего. По мотивам статьи Мартина Фаулера
С ростом финансовой грамотности человек начинает осознавать разницу между микрозаймом, потребительским кредитом и ипотекой. Чуть позже он начинает разбираться в инвестировании и может принимать взвешенное решение: купить в ипотеку или арендовать и копить.
Можно провести аналогию опыта и ответственности с разработкой и техдолгом:
1️⃣ «Какие такие слои архитектуры?» — Первый микрозайм;
2️⃣ «У нас нет времени на проработку архитектуры» — Когда нет денег на очередной платёж по микрозайму и человек берет для этого еще один микрозайм;
3️⃣ «Мы должны релизить сейчас и отвечать за последствия» — Кредит с адекватным процентом и понятным графиком платежей. Осознанный ответственный долг;
4️⃣ «Теперь мы знаем, как это следовало бы реализовать» — Если бы я знал о грядущих локдауне и удалёнке, то купил бы дом, а не студию в центре. В частном доме больше места, удобнее организовать рабочее пространство и есть свой двор. Спрос на частные дома сильно вырос, а с ним и цены.
Если разработчик находится в среде, где от него требуют наиболее быстрой и дешевой поставки ценности пользователю, то он с большой вероятностью будет порождать техдолг. В этом нет вины разработчика, это системная проблема рабочей среды.
Среду формируют отношение руководства и инструменты. Среди этих инструментов — Definition of Done. С помощью DoD мы избавляемся от первых двух вариантов безответственного техдолга.
Третий вариант возможен только по просьбе владельца продукта, для быстрой проверки сырой гипотезы, или срочного удовлетворения текущей потребности рынка.
От четвертого варианта техдолга не защищены лучшие команды. © M. Fowler
Я призываю создавать такую среду и инструменты, чтобы системно не допускать первых трёх вариантов техдолга.
У нас и так есть риск породить техдолг, даже если будем ответственно и осознаннно подходить к проработке архитектуры.
Этот пост - продолжение предыдущего. По мотивам статьи Мартина Фаулера
С ростом финансовой грамотности человек начинает осознавать разницу между микрозаймом, потребительским кредитом и ипотекой. Чуть позже он начинает разбираться в инвестировании и может принимать взвешенное решение: купить в ипотеку или арендовать и копить.
Можно провести аналогию опыта и ответственности с разработкой и техдолгом:
1️⃣ «Какие такие слои архитектуры?» — Первый микрозайм;
2️⃣ «У нас нет времени на проработку архитектуры» — Когда нет денег на очередной платёж по микрозайму и человек берет для этого еще один микрозайм;
3️⃣ «Мы должны релизить сейчас и отвечать за последствия» — Кредит с адекватным процентом и понятным графиком платежей. Осознанный ответственный долг;
4️⃣ «Теперь мы знаем, как это следовало бы реализовать» — Если бы я знал о грядущих локдауне и удалёнке, то купил бы дом, а не студию в центре. В частном доме больше места, удобнее организовать рабочее пространство и есть свой двор. Спрос на частные дома сильно вырос, а с ним и цены.
Если разработчик находится в среде, где от него требуют наиболее быстрой и дешевой поставки ценности пользователю, то он с большой вероятностью будет порождать техдолг. В этом нет вины разработчика, это системная проблема рабочей среды.
Среду формируют отношение руководства и инструменты. Среди этих инструментов — Definition of Done. С помощью DoD мы избавляемся от первых двух вариантов безответственного техдолга.
Третий вариант возможен только по просьбе владельца продукта, для быстрой проверки сырой гипотезы, или срочного удовлетворения текущей потребности рынка.
От четвертого варианта техдолга не защищены лучшие команды. © M. Fowler
Я призываю создавать такую среду и инструменты, чтобы системно не допускать первых трёх вариантов техдолга.
У нас и так есть риск породить техдолг, даже если будем ответственно и осознаннно подходить к проработке архитектуры.
Open Space Technology - инструмент для проведения мероприятий с большим числом участников.
В группе размером больше чем 6 участников обычно общаются два-три наиболее активных. При этом другие не имеют возможности высказать свое мнение.
Если не все выскажутся, это может привести к трём проблемам:
1️⃣ — Упустят какие-то важные аспекты;
2️⃣ — Примут менее качественное решение;
3️⃣ — Тот, кто не смог высказаться, может почувствовать себя ненужным.
Open Space — фреймворк мероприятия, который решает эти проблемы в любом масштабе, вплоть до тысячи участников.
Он даёт возможность каждому внести свой вклад и рассмотреть тему со всех возможных сторон.
Основная концепция Open Space - выделять аспекты общей темы и отделять обсуждение аспекта в отдельную комнату, куда придут все желающие поговорить именно об этом.
Предлагаю попробовать на практике на нашем митапе 1 апреля после работы.
Регистрация на Timepad
В посты на канале я стараюсь закладывать пространство для мыслей и обсуждений. Например, серия постов про зоны ответственности разработчика.
1 апреля в 19:00 соберемся в зуме, чтобы потрындеть как раз про зоны ответственности разработчика.
Вместо докладов будет свободное общение в формате Open Space.
Единственное отличие от классического Open Space - мы не будем принимать решения.
Каждое мнение правильное, нет цели принять какое-то одно за единственно верное.
Цели:
— собрать вместе разрабов из разных компаний;
— получить удовлетворение от дискуссии;
— завязать новые знакомства;
— узнать, какие есть варианты границ зон ответствености разработчиков, какие у них особенности и как они влияют на продукт и самого разработчика.
Регистрация на Timepad
Увидимся! 🙂
В группе размером больше чем 6 участников обычно общаются два-три наиболее активных. При этом другие не имеют возможности высказать свое мнение.
Если не все выскажутся, это может привести к трём проблемам:
1️⃣ — Упустят какие-то важные аспекты;
2️⃣ — Примут менее качественное решение;
3️⃣ — Тот, кто не смог высказаться, может почувствовать себя ненужным.
Open Space — фреймворк мероприятия, который решает эти проблемы в любом масштабе, вплоть до тысячи участников.
Он даёт возможность каждому внести свой вклад и рассмотреть тему со всех возможных сторон.
Основная концепция Open Space - выделять аспекты общей темы и отделять обсуждение аспекта в отдельную комнату, куда придут все желающие поговорить именно об этом.
Предлагаю попробовать на практике на нашем митапе 1 апреля после работы.
Регистрация на Timepad
В посты на канале я стараюсь закладывать пространство для мыслей и обсуждений. Например, серия постов про зоны ответственности разработчика.
1 апреля в 19:00 соберемся в зуме, чтобы потрындеть как раз про зоны ответственности разработчика.
Вместо докладов будет свободное общение в формате Open Space.
Единственное отличие от классического Open Space - мы не будем принимать решения.
Каждое мнение правильное, нет цели принять какое-то одно за единственно верное.
Цели:
— собрать вместе разрабов из разных компаний;
— получить удовлетворение от дискуссии;
— завязать новые знакомства;
— узнать, какие есть варианты границ зон ответствености разработчиков, какие у них особенности и как они влияют на продукт и самого разработчика.
Регистрация на Timepad
Увидимся! 🙂
qiwi-events.timepad.ru
Онлайн OpenSpace Meetup: Зоны ответственности разработчика / События на TimePad.ru
Живое общение - источник вдохновения
Раньше мы виделись с коллегами в офисе и общались с айтишниками из других компаний на митапах и конференциях. Из этого общения мы черпали вдохновение, узнавали о трендах и процессах в айтишном мире. Такое взаимное опыление было в привычном порядке вещей, и оно сильно влияло на развитие индустрии.
Год удалёнки нас изменил. Мы смогли адаптироваться к сидению по домам, но все силы ушли на эту адаптацию. Мы меньше общаемся с коллегами из других компаний, взаимного опыления не происходит. Максимум - пойти послушать вебинар. После вебинара - сессия Q&A. И это всё. Формат обычно разделяет спикера и слушателей и не подразумевает общения между участниками.
Потихоньку мы начинаем это осознавать и выползать из своих нор.
За последний месяц я попал на несколько мероприятий, где формат располагал участников общаться друг с другом. И это был восторг. Я понял, чего мне не хватало весь год: живого общения с людьми из индустрии.
Говорю «живое», имею ввиду интересную дискуссию в зуме с включенными камерами. Включенная камера - обязательный аттрибут живого общения. Камера помогает входить в эмоциональный контакт с собеседником и лучше понимать друг друга.
Рекомендую найти в себе силы, чтобы вырваться из привычной рутины удалёнки и начать участвовать в сообществе. Вам есть, что сказать, а у других людей есть интересное для вас!
Ходите на митапы, где можно не просто смотреть доклад, а общаться с другими участниками.
Такие мероприятия проводят ребята из Podlodka Crew и TechnicalExcellence. Благодаря им я и понял ценность живого общения.
Такой митап вчера провели мы.
Дать пространство и время для общения и собрать живых людей может каждый!
Спасибо всем, кто помогал в организации и огромное спасибо всем тем, кто вечер четверга посвятил живому общению с коллегами из других компаний.
Вы развиваете айтишное сообщество!
Раньше мы виделись с коллегами в офисе и общались с айтишниками из других компаний на митапах и конференциях. Из этого общения мы черпали вдохновение, узнавали о трендах и процессах в айтишном мире. Такое взаимное опыление было в привычном порядке вещей, и оно сильно влияло на развитие индустрии.
Год удалёнки нас изменил. Мы смогли адаптироваться к сидению по домам, но все силы ушли на эту адаптацию. Мы меньше общаемся с коллегами из других компаний, взаимного опыления не происходит. Максимум - пойти послушать вебинар. После вебинара - сессия Q&A. И это всё. Формат обычно разделяет спикера и слушателей и не подразумевает общения между участниками.
Потихоньку мы начинаем это осознавать и выползать из своих нор.
За последний месяц я попал на несколько мероприятий, где формат располагал участников общаться друг с другом. И это был восторг. Я понял, чего мне не хватало весь год: живого общения с людьми из индустрии.
Говорю «живое», имею ввиду интересную дискуссию в зуме с включенными камерами. Включенная камера - обязательный аттрибут живого общения. Камера помогает входить в эмоциональный контакт с собеседником и лучше понимать друг друга.
Рекомендую найти в себе силы, чтобы вырваться из привычной рутины удалёнки и начать участвовать в сообществе. Вам есть, что сказать, а у других людей есть интересное для вас!
Ходите на митапы, где можно не просто смотреть доклад, а общаться с другими участниками.
Такие мероприятия проводят ребята из Podlodka Crew и TechnicalExcellence. Благодаря им я и понял ценность живого общения.
Такой митап вчера провели мы.
Дать пространство и время для общения и собрать живых людей может каждый!
Спасибо всем, кто помогал в организации и огромное спасибо всем тем, кто вечер четверга посвятил живому общению с коллегами из других компаний.
Вы развиваете айтишное сообщество!
Как совмещать Бизнесовые фичи и Развитие инженерки
Вот мы зафиксировали нижний порог уровня качества выпускаемых фич с помощью Definition of Done.
Не факт, что этот нижний порог — высокий. Скорее всего, тут и там в процессах разработки есть несовершенство и техдолг. Это несовершенство нас тормозит и делает продукт менее качественным.
Например, мы не могли включить в DoD пункт про Unit тесты, пока не было однозначных договоренностей в виде Unit Tests Best Practices. Без них этот пункт не принёс бы ценности: его было бы легко нарушить, или отмазаться, написав один незначительный тест.
Отсутствие Best Practices дает свободу вкусовщине, что может привести к срачам на ревью и разножопице в реализации компонентов. При совместном владении кодом это негативно влияет на Time2Market и на стабильность и поддериживаемость систем в целом.
Как бы так сделать, чтобы команда могла вынырнуть из потока бизнесовых фич, подтянуть инженерные практики и процессы, доработать инструменты для самих разработчиков, улучшить CI/CD, расплатиться с техдолгом?
При чем не однократно, типа субботника, а сделать это непрерывным процессом.
У нас такая проблема была и для её решения мы собрали непрерывный процесс развития разработки.
Раньше я писал про Dual Track Development, когда задачи прорабатываются меньшими циклами разной длины параллельно запилу конкретной фичи в спринте.
С учётом процесса развития разработки у нас получается Tripple Track Development:
1️⃣ — Проработка задач из бэклога
2️⃣ — Разработка фичи в спринте
3️⃣ — Развитие инженерных практик и процессов
В следующем посте подробно опишу этот третий трек и какие результаты он приносит.
Вот мы зафиксировали нижний порог уровня качества выпускаемых фич с помощью Definition of Done.
Не факт, что этот нижний порог — высокий. Скорее всего, тут и там в процессах разработки есть несовершенство и техдолг. Это несовершенство нас тормозит и делает продукт менее качественным.
Например, мы не могли включить в DoD пункт про Unit тесты, пока не было однозначных договоренностей в виде Unit Tests Best Practices. Без них этот пункт не принёс бы ценности: его было бы легко нарушить, или отмазаться, написав один незначительный тест.
Отсутствие Best Practices дает свободу вкусовщине, что может привести к срачам на ревью и разножопице в реализации компонентов. При совместном владении кодом это негативно влияет на Time2Market и на стабильность и поддериживаемость систем в целом.
Как бы так сделать, чтобы команда могла вынырнуть из потока бизнесовых фич, подтянуть инженерные практики и процессы, доработать инструменты для самих разработчиков, улучшить CI/CD, расплатиться с техдолгом?
При чем не однократно, типа субботника, а сделать это непрерывным процессом.
У нас такая проблема была и для её решения мы собрали непрерывный процесс развития разработки.
Раньше я писал про Dual Track Development, когда задачи прорабатываются меньшими циклами разной длины параллельно запилу конкретной фичи в спринте.
С учётом процесса развития разработки у нас получается Tripple Track Development:
1️⃣ — Проработка задач из бэклога
2️⃣ — Разработка фичи в спринте
3️⃣ — Развитие инженерных практик и процессов
В следующем посте подробно опишу этот третий трек и какие результаты он приносит.
Engineering Improvements Track
Мы перешли от конфликта бизнеса и разработки к взаимовыгодному сотрудничеству. Один-два часа в неделю каждый разработчик может посвятить развитию инженерных практик и процессов. Бизнес довольно легко соглашается на один-два часа в неделю. А мы построили такой процесс, который приносит профит даже при минимальных затратах времени.
Наш третий трек базируется на Scrum:
📌 Продукт — Инженерные практики и процессы;
📌 Бэклог продукта — Задачи, направленные на устранение техдолга и улучшение инженерных практик;
📌 Владелец продукта — Сообщество разработчиков, которые приоритезируют бэклог и решают, какие задачи самые важные;
📌 Проработка задач из бэклога (PBR) — Рабочая группа описывает задачу: в чем проблема, как часто возникает, какие риски несёт, если не решать, и какая ценность для бизнеса. Очень важно объяснить бизнесу ценность от этой работы. Чаще всего ценность в более быстром выпуске фич (T2M) и более стабильных системах (внутреннее качество);
📌 Планирование итерации — Один час на первой неделе;
📌 Три Команды разработки — каждую итерацию для трёх задач набираются рабочие группы из разных продуктовых команд;
📌 Фиксированная длина итераций — 8 недель, что эквивалентно 4 бизнесовых спринта из Delivery Track.
Итерации долгие, но мы тратим всего один-два часа в неделю.
При этом раз в 4 бизнесовых спринта прогнозируемо появляется три значимых улучшения инженерных практик и процессов. Обычно мы договариваемся о стандартах типа Best Practice, чтобы не плодить велосипеды. Реже — разрабатываем конкретные улучшения инфраструктуры и инструментов для разработчиков.
Примеры результатов работы по этому треку:
— Тесты в CI Pipeline;
— Повышение стабильности при использовании Kafka;
— Best Practice документирования архитектуры;
— Best Practice по Unit тестам;
— Best Practice по Интеграционным тестам;
— Best Practice по разработке и деплою миграций БД микросервисов;
— стандартизация code style;
— SQL-Linter для Oracle PL/SQL;
— автоматизация разворачивания новой БД для микросервиса;
— Проработали требования и план разработки системы бизнес-мониторинга;
и еще с десяток улучшений, которые сложно описать без погружения в контекст.
Мы собирали этот процесс несколько лет и продолжаем менять. Этот процесс не идеален, но видно что он приносит свои плоды. Сообщество разработчиков из разных команд вместе договариваются о стандартах и лучших практиках, разрабатывают и внедряют инструменты для разработки, ci/cd, мониторинга.
В этот процесс не очень хорошо вписываются конкретные прикладные задачи "накодить". Чтобы их тоже делать в рамках этого процесса, мы думаем, как этот процесс изменить. Возможно, нужна именно dev2dev команда, которая занималась бы конкретно инструментами для разработчиков. Но пока довольны тем что имеем.
А у вас есть непрерывный процесс улучшения инженерки? Пишите в комментах.
Мы перешли от конфликта бизнеса и разработки к взаимовыгодному сотрудничеству. Один-два часа в неделю каждый разработчик может посвятить развитию инженерных практик и процессов. Бизнес довольно легко соглашается на один-два часа в неделю. А мы построили такой процесс, который приносит профит даже при минимальных затратах времени.
Наш третий трек базируется на Scrum:
📌 Продукт — Инженерные практики и процессы;
📌 Бэклог продукта — Задачи, направленные на устранение техдолга и улучшение инженерных практик;
📌 Владелец продукта — Сообщество разработчиков, которые приоритезируют бэклог и решают, какие задачи самые важные;
📌 Проработка задач из бэклога (PBR) — Рабочая группа описывает задачу: в чем проблема, как часто возникает, какие риски несёт, если не решать, и какая ценность для бизнеса. Очень важно объяснить бизнесу ценность от этой работы. Чаще всего ценность в более быстром выпуске фич (T2M) и более стабильных системах (внутреннее качество);
📌 Планирование итерации — Один час на первой неделе;
📌 Три Команды разработки — каждую итерацию для трёх задач набираются рабочие группы из разных продуктовых команд;
📌 Фиксированная длина итераций — 8 недель, что эквивалентно 4 бизнесовых спринта из Delivery Track.
Итерации долгие, но мы тратим всего один-два часа в неделю.
При этом раз в 4 бизнесовых спринта прогнозируемо появляется три значимых улучшения инженерных практик и процессов. Обычно мы договариваемся о стандартах типа Best Practice, чтобы не плодить велосипеды. Реже — разрабатываем конкретные улучшения инфраструктуры и инструментов для разработчиков.
Примеры результатов работы по этому треку:
— Тесты в CI Pipeline;
— Повышение стабильности при использовании Kafka;
— Best Practice документирования архитектуры;
— Best Practice по Unit тестам;
— Best Practice по Интеграционным тестам;
— Best Practice по разработке и деплою миграций БД микросервисов;
— стандартизация code style;
— SQL-Linter для Oracle PL/SQL;
— автоматизация разворачивания новой БД для микросервиса;
— Проработали требования и план разработки системы бизнес-мониторинга;
и еще с десяток улучшений, которые сложно описать без погружения в контекст.
Мы собирали этот процесс несколько лет и продолжаем менять. Этот процесс не идеален, но видно что он приносит свои плоды. Сообщество разработчиков из разных команд вместе договариваются о стандартах и лучших практиках, разрабатывают и внедряют инструменты для разработки, ci/cd, мониторинга.
В этот процесс не очень хорошо вписываются конкретные прикладные задачи "накодить". Чтобы их тоже делать в рамках этого процесса, мы думаем, как этот процесс изменить. Возможно, нужна именно dev2dev команда, которая занималась бы конкретно инструментами для разработчиков. Но пока довольны тем что имеем.
А у вас есть непрерывный процесс улучшения инженерки? Пишите в комментах.