Итак:
cycle time — это основополагающий показатель если выработаете по Kanban, его считать может кто угодно (а лучше автоматизированная система) его анализ даёт понять где в системе узкие места, но не даёт рецептов по их исправлению. Тема данного топика и предыдущего совсем про другое.
Синьоры, которые не шарят в процессах — нифига не синьоры. Синьорство — это не столько скилл кодинга, а в том числе и понимание целей и процесса разработки.
ключевое я выделил жирным, но они не понимают что такое синергия и чем командная работа отличается от индивидуальной работы нескольких человек. Вы не задумывались над тем, что вы как те синьоры, которых я выше описывал просто не видите куда дальше можно копнуть в процессе, чтобы повысить производительность?
Это происходит всегда, надо учитывать при планировании.
В таком случае вы просто признаёте этот риск и никак не пытаетесь с ним бороться. А с ним бороться можно и очень эффективно (сужу по своему опыту)
Continious Integration, без которого собственно любой эджайл плохо работает (см. Фаулера). И это не коммуникативная методика, чисто техническая. В теории код надо интегрировать чуть ли не раз в 2 часа, на практике получается гораздо реже (ведь интегрировать надо потенциально рабочий код а не код который даже не компилируется). При нормальной внутрикомандной коммуникации главные проблемы слома сборки из-за каких-то изменений (кто-то поменял протокол, или поменял версию какой-то библиотеки) все готовы к сломам и заранее планируют время починки.
Всё верно, но «синьоры» хорошо работают с технологиями и плохо с процессами и коммуникациями. Вот у меня как раз подобная вещь выходит, в командах есть люди продвигающие технологии, библиотеки, стандарты. Проблемы начинаются когда дело доходит до коммуникаций. Разгребаешь то как отработали и видишь:
* тут слишком затянули ревью кода
* тут не до конца договорились с аналитиком, на финальной стадии пришлось переделывать
* тут не договорились с архитектором, сделали не так как надо, пришлось переделывать
* писали долго код, начали мержиться — всё развалилось
это всё проблемы которые решаются коммуникативными практиками: парная работа, раннее ревью, частая интеграция, валидация курса работы с заказчиком (аналитиком), внутренняя коммуникация в команде, чтобы заранее распознавать проблемы
Тут надо подходить к команде не как PM а как Agile Coach. Надо им не указывать на промахи, а делать так, чтобы они сами их заметили и сами выработали решение по развитию.
Про экспертную оценку вспомнилась пословица: «Дай человеку рыбу и он будет сыт весь день, научи человека ловить рыбу и он будет сыт всю жизнь»
P.S. Но опять-же это не всегда и не везде применимо. Надо действовать по ситуации.
Не, тут не оффтоп. Я понимаю, что проекты бывают разные и вполне может получаться как в известной пословице, как дурака заставили богу молиться.
У себя в проекте я вижу, что от этого будет profit.
Пост я написал для того, чтобы этот инструмент знали и про него помнили, а уж пользоваться или нет — это дело каждого. Ведь инструмент хорош к месту и ко времени.
Скажем так, у меня 4 команды разработки и сейчас они созрели к введению подобной оценки (Agile:EF на базе Shodan,). В жизни любой команды наступает момент, когда у них появляется мнение, что у них и так всё хорошо и ничего не надо менять (соотв. если они самоорганизующиеся, то они ничего менять и не будут) вот подобная оценка должна показать векторы роста по некоторым направлениям (сдвинуть команду с мёртвой точки)
Ну это всё сводит дискуссию к тому, нужны ли нам самоорганизующиеся команды или нет, а это уже оффтоп и холивор
Приведенная выше метода как раз для самоорганизующейся команды находящейся без функционального руководства (находящейся на стадии S4 по Херши-Бланшару)
Peopleware был написан в конце 80-х, тот-же Agile Manifesto был сформулирован более чем 10 годами позже. Возможно сейчас ДеМарко смотрел бы на это по другому.
Соглашусь, что делать метрики из человеко-зависящих вещей не хорошо, но это смотря для чего их использовать. Если для того, чтобы построить SLA для премирования команды — это плохо, а если эта метрика будет служить для тог, о чтобы команда сама искала пути использования best practices (именно сама, а не насаждалось сверху) для повышения своей продуктивности — это хорошо.
но по ним не посчитать использование практик завязанных на коммуникации, таких как парное программирование, общение с заказчиком, внутрикомандное взаимодействие и т.д.
P.S. Людям изнутри разработка видна гораздо лучше, чем менеджеру снаружи. Поэтому я не отбрасываю мнение команды.
Совершенно верно.
Тут я не хорошо подобрал формулировку
Только тут речь скорее не о продукте, а о процессе. Команда должна работать над улучшением своего процесса работы и как следствие улучшением продукта (по качеству, скорости выдачи релизов и т.д.)
Улучшение процесса связано с большим погружением в практики XP и как следствие ростом процента погружения.
cycle time — это основополагающий показатель если выработаете по Kanban, его считать может кто угодно (а лучше автоматизированная система) его анализ даёт понять где в системе узкие места, но не даёт рецептов по их исправлению. Тема данного топика и предыдущего совсем про другое.
Синьоры, которые не шарят в процессах — нифига не синьоры. Синьорство — это не столько скилл кодинга, а в том числе и понимание целей и процесса разработки.
ключевое я выделил жирным, но они не понимают что такое синергия и чем командная работа отличается от индивидуальной работы нескольких человек. Вы не задумывались над тем, что вы как те синьоры, которых я выше описывал просто не видите куда дальше можно копнуть в процессе, чтобы повысить производительность?
Это происходит всегда, надо учитывать при планировании.
В таком случае вы просто признаёте этот риск и никак не пытаетесь с ним бороться. А с ним бороться можно и очень эффективно (сужу по своему опыту)
Continious Integration, без которого собственно любой эджайл плохо работает (см. Фаулера). И это не коммуникативная методика, чисто техническая. В теории код надо интегрировать чуть ли не раз в 2 часа, на практике получается гораздо реже (ведь интегрировать надо потенциально рабочий код а не код который даже не компилируется). При нормальной внутрикомандной коммуникации главные проблемы слома сборки из-за каких-то изменений (кто-то поменял протокол, или поменял версию какой-то библиотеки) все готовы к сломам и заранее планируют время починки.
* тут слишком затянули ревью кода
* тут не до конца договорились с аналитиком, на финальной стадии пришлось переделывать
* тут не договорились с архитектором, сделали не так как надо, пришлось переделывать
* писали долго код, начали мержиться — всё развалилось
это всё проблемы которые решаются коммуникативными практиками: парная работа, раннее ревью, частая интеграция, валидация курса работы с заказчиком (аналитиком), внутренняя коммуникация в команде, чтобы заранее распознавать проблемы
Про экспертную оценку вспомнилась пословица: «Дай человеку рыбу и он будет сыт весь день, научи человека ловить рыбу и он будет сыт всю жизнь»
P.S. Но опять-же это не всегда и не везде применимо. Надо действовать по ситуации.
У себя в проекте я вижу, что от этого будет profit.
Пост я написал для того, чтобы этот инструмент знали и про него помнили, а уж пользоваться или нет — это дело каждого. Ведь инструмент хорош к месту и ко времени.
Серебряных пуль не бывает (с) Ф.Брукс
Приведенная выше метода как раз для самоорганизующейся команды находящейся без функционального руководства (находящейся на стадии S4 по Херши-Бланшару)
Соглашусь, что делать метрики из человеко-зависящих вещей не хорошо, но это смотря для чего их использовать. Если для того, чтобы построить SLA для премирования команды — это плохо, а если эта метрика будет служить для тог, о чтобы команда сама искала пути использования best practices (именно сама, а не насаждалось сверху) для повышения своей продуктивности — это хорошо.
P.S. Людям изнутри разработка видна гораздо лучше, чем менеджеру снаружи. Поэтому я не отбрасываю мнение команды.
Тут я не хорошо подобрал формулировку
Только тут речь скорее не о продукте, а о процессе. Команда должна работать над улучшением своего процесса работы и как следствие улучшением продукта (по качеству, скорости выдачи релизов и т.д.)
Улучшение процесса связано с большим погружением в практики XP и как следствие ростом процента погружения.