Спасибо за интерес. Постараюсь осветить в отдельной заметке.
Если коротко. Ретро релиза — это как ретро спринта, только для всех команд разом в огромном зале с "+" и "-", которые берутся решать не только члены команды-автора минусов, но и другие могут помочь. Кроме этого, "+" берут на заметку другие команды, т.о. обмениваемся опытом положительным и отрицательным. А еще благодарим коллег за помощь на протяжении релиза :)
Не очень понял Ваши расчеты. Откуда взялись 1000 человеко-часов работы в месяц? Если это неправильная арифметика из приведенных в статье расчетов, то готов поспорить. Конкретно, как менеджер уменьшит участие команд в активностях вроде стендапов, ретро, демо и синхронизациях? Или при участии менеджера необходимость в этих активностях пропадет?
Интересное у Вас восприятие. Продукт овнер поставляет бэклог, команда оценивает. И Вы считаете, что без менеджеров команда будет выходить за сроки? Или менеджер, по вашему, урежет качество взамен большей скорости? В Вашем мире разработчик хочет сидеть и писать идеальные программы, а не доставлять результат конечному пользователю?
На синхронизации 7 команд стоят по стойке смирно и на вопрос: «Кто сделал?», — отвечают: «Я!», как в Гайдаевском фильме :) Не помню, чтобы кто-то замалчивал ответственность.
Приветствую. Скорее, посыл статьи: «И без менеджеров возможно». В современном IT мире большинство книг и методологий настаивают на том, что обязательно должен быть в IT структуре *отдельный* человек с функциями менеджера. Я же пытаюсь показать, что возможно организовать эффективную работу без такого человека. Я могу быть не прав, готов спорить. Но пока что спор никак не завязывается :)
Были груминги в рамках команды с аналитиком. Записали требования к фиче, обсудили, разошлись. Требования выявляем заранее, спринта за 2-3 до фактической реализации. И вот через 2-3 спринта, понимаем, что не успеваем сделать эту фичу. На синхронизации выяснилось, что у другой команды возникает пул времени, так как большую фичу они сделать не успеют, а маленькие закончились.
На следующий день, вторая команда-помощник собирается обсуждать аналитику фичи (как бы второй раз), но уже без аналитика, — только тим лид от первой команды. Обсуждают требования, как на груминге (как бы второй раз). И вот тут Вы абсолютно правы. Новая команда смотрит свежим взглядом и тут же находит пару непонятных моментов, которые уточнили у аналитика. В этом как раз видится большой плюс.
Так что не похоже, что остались какие-то пробелы :) С другой стороны, и цикл статей не окончен!
Позвольте мне провести аналогию с Вашим вопросом. Это очень похоже на такую критику: бизнес работает с маржинальностью в 40%. Участники бизнеса всем довольны. Приходит критик и говорит, ваша эффективность не максимальна! Так и не надо, если только Вы не хотите поупражняться в решении математической задачи оптимизации «эффективности процессов agile» :)
В этом-то и суть. Баланс между затрачиваемыми на процесс усилиями и выхлопом в виде прозрачности, повышения качества архитектуры кода и т.д. Мы не пытаемся найти максимальную эффективность, мы решаем задачи, которые перед нами ставит бизнес. И решаем их с эффективностью, достаточной для успешного закрытия бизнес-планов.
Приветствую. Если хотите конструктивно обсудить, разъясните, пожалуйста, что Вы вкладываете в фразу «po является частью команды»?
Что касается терминологии, может, у нас и не скрам, но мы эффективно доставляем пак фичей к сроку. В этом и есть посыл моих статей. Книжная методология — не панацея и не решение всех проблем. Каждая организация должна найти свои активности и свои процессы, которые позволяют максимально эффективно доставить продукт конечным пользователям в срок и с нужным качеством.
Простите мое лукавство. Конечно, наши Product Owner'ы озабочены тем, что команды не успевают или доставляют баги в продакшн. Они даже часто говорят об этом на синхронизациях и обсуждениях темпов разработки.
Тем не менее, они не осуществляют контроль за разработкой, не контролируют в общем смысле процессы. Сами команды выстраивают процессы, тимлиды и все заинтересованные периодически (обычно сразу после релиза) обсуждают, что можно улучшить в процессах. Сильно помогает кросс-командное ретро релизов. Направления для улучшений у нас возникает изнутри и может вноситься кем угодно, имеющим достаточно смелости, чтобы не просто рассказать о клевой идее в процессах, а донести ее до всех. Каждый спринт мы привносим что-то новое в нашу работу сами, но это ни в коей мере не умаляет роли продуктовиков в контроле сроков.
Если между спринтами есть два дня на ретро, демо и планирование — это не значит, что в эти два дня не пишется код. Это значит, что в эти дни активности — с бОльшим приоритетом, чем написание кода. Эти два дня являются хорошим буфером для амортизации недооценок/переоценок по спринту.
По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28*0.4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа в 12 на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.
Поделитесь, сколько времени интегрально у Ваших программистов уходит на активности помимо разработки? На мой взгляд, 1 час в день на разговоры — очень небольшая плата за распространение знаний и рефлексию команд.
Сомневаюсь, что внедрение lean и agile связано именно с количеством стейкхолдеров.
Как правило, критерием становится именно цена ошибки. Самая простая ошибка — потеря $. Самые сложные — смерть людей, вред экологии, уничтожение других материальных ценностей (памятники культуры, например). Поэтому самолеты, атомные электростанции и дома не производят по agile…
… каждый разработчик должен ещё помнить о том, что кому-то надо таки организовать встречу ...
Интересная подмена понятий. Я работал в трех IT-компаниях в CAD индустрии. Ни в одной я не сталкивался с тем, что разработчики «должны» помнить. Каждый почему-то понимал и ценил каждую активность, которая у нас проводилась и сам напоминал, если кто-то в потоке забывал о времени. Бывало, что из-за потока забывали о совещаниях, но было это редко и проблем не доставляло.
И да, разработчикам, с которыми я работаю и работал, в радость созывать народ для обсуждения какой-то фичи или архитектуры. Ведь каждый профессионал понимает, что, как правило!, только в разговоре и споре рождается лучший вариант решения.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Если коротко. Ретро релиза — это как ретро спринта, только для всех команд разом в огромном зале с "+" и "-", которые берутся решать не только члены команды-автора минусов, но и другие могут помочь. Кроме этого, "+" берут на заметку другие команды, т.о. обмениваемся опытом положительным и отрицательным. А еще благодарим коллег за помощь на протяжении релиза :)
Были груминги в рамках команды с аналитиком. Записали требования к фиче, обсудили, разошлись. Требования выявляем заранее, спринта за 2-3 до фактической реализации. И вот через 2-3 спринта, понимаем, что не успеваем сделать эту фичу. На синхронизации выяснилось, что у другой команды возникает пул времени, так как большую фичу они сделать не успеют, а маленькие закончились.
На следующий день, вторая команда-помощник собирается обсуждать аналитику фичи (как бы второй раз), но уже без аналитика, — только тим лид от первой команды. Обсуждают требования, как на груминге (как бы второй раз). И вот тут Вы абсолютно правы. Новая команда смотрит свежим взглядом и тут же находит пару непонятных моментов, которые уточнили у аналитика. В этом как раз видится большой плюс.
Так что не похоже, что остались какие-то пробелы :) С другой стороны, и цикл статей не окончен!
Позвольте мне провести аналогию с Вашим вопросом. Это очень похоже на такую критику: бизнес работает с маржинальностью в 40%. Участники бизнеса всем довольны. Приходит критик и говорит, ваша эффективность не максимальна! Так и не надо, если только Вы не хотите поупражняться в решении математической задачи оптимизации «эффективности процессов agile» :)
В этом-то и суть. Баланс между затрачиваемыми на процесс усилиями и выхлопом в виде прозрачности, повышения качества архитектуры кода и т.д. Мы не пытаемся найти максимальную эффективность, мы решаем задачи, которые перед нами ставит бизнес. И решаем их с эффективностью, достаточной для успешного закрытия бизнес-планов.
Что касается терминологии, может, у нас и не скрам, но мы эффективно доставляем пак фичей к сроку. В этом и есть посыл моих статей. Книжная методология — не панацея и не решение всех проблем. Каждая организация должна найти свои активности и свои процессы, которые позволяют максимально эффективно доставить продукт конечным пользователям в срок и с нужным качеством.
Тем не менее, они не осуществляют контроль за разработкой, не контролируют в общем смысле процессы. Сами команды выстраивают процессы, тимлиды и все заинтересованные периодически (обычно сразу после релиза) обсуждают, что можно улучшить в процессах. Сильно помогает кросс-командное ретро релизов. Направления для улучшений у нас возникает изнутри и может вноситься кем угодно, имеющим достаточно смелости, чтобы не просто рассказать о клевой идее в процессах, а донести ее до всех. Каждый спринт мы привносим что-то новое в нашу работу сами, но это ни в коей мере не умаляет роли продуктовиков в контроле сроков.
По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28*0.4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа в 12 на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.
Поделитесь, сколько времени интегрально у Ваших программистов уходит на активности помимо разработки? На мой взгляд, 1 час в день на разговоры — очень небольшая плата за распространение знаний и рефлексию команд.
Как правило, критерием становится именно цена ошибки. Самая простая ошибка — потеря $. Самые сложные — смерть людей, вред экологии, уничтожение других материальных ценностей (памятники культуры, например). Поэтому самолеты, атомные электростанции и дома не производят по agile…
Интересная подмена понятий. Я работал в трех IT-компаниях в CAD индустрии. Ни в одной я не сталкивался с тем, что разработчики «должны» помнить. Каждый почему-то понимал и ценил каждую активность, которая у нас проводилась и сам напоминал, если кто-то в потоке забывал о времени. Бывало, что из-за потока забывали о совещаниях, но было это редко и проблем не доставляло.
И да, разработчикам, с которыми я работаю и работал, в радость созывать народ для обсуждения какой-то фичи или архитектуры. Ведь каждый профессионал понимает, что, как правило!, только в разговоре и споре рождается лучший вариант решения.