Comments 21
UFO just landed and posted this here
Демарко еще в середине 90-х про тогдашние модные метрики высказался. Как и про многие другие.
Ну и нахера мне знать мнение команды про «погружение в эджайл» если я просто могу посчитать ряд метрик типа code coverage, cyclomatic complexity и так далее и по ним четко видеть и качество и скорость разработки?
Очередной bullshit для продажи очередной херни.
Ну и нахера мне знать мнение команды про «погружение в эджайл» если я просто могу посчитать ряд метрик типа code coverage, cyclomatic complexity и так далее и по ним четко видеть и качество и скорость разработки?
Очередной bullshit для продажи очередной херни.
но по ним не посчитать использование практик завязанных на коммуникации, таких как парное программирование, общение с заказчиком, внутрикомандное взаимодействие и т.д.
P.S. Людям изнутри разработка видна гораздо лучше, чем менеджеру снаружи. Поэтому я не отбрасываю мнение команды.
P.S. Людям изнутри разработка видна гораздо лучше, чем менеджеру снаружи. Поэтому я не отбрасываю мнение команды.
ИМХО, считать метриками коммуникацию и человеко-зависимые вещи — не очень хорошая идея. Об этом Демарко тоже пишет (в «Peopleware»).
Peopleware был написан в конце 80-х, тот-же Agile Manifesto был сформулирован более чем 10 годами позже. Возможно сейчас ДеМарко смотрел бы на это по другому.
Соглашусь, что делать метрики из человеко-зависящих вещей не хорошо, но это смотря для чего их использовать. Если для того, чтобы построить SLA для премирования команды — это плохо, а если эта метрика будет служить для тог, о чтобы команда сама искала пути использования best practices (именно сама, а не насаждалось сверху) для повышения своей продуктивности — это хорошо.
Соглашусь, что делать метрики из человеко-зависящих вещей не хорошо, но это смотря для чего их использовать. Если для того, чтобы построить SLA для премирования команды — это плохо, а если эта метрика будет служить для тог, о чтобы команда сама искала пути использования best practices (именно сама, а не насаждалось сверху) для повышения своей продуктивности — это хорошо.
Опять же имхо, но если команда сама не ищет пути внедрения best practices надо срочно задуматься о профессионализме как минимум синьоров.
Ну это всё сводит дискуссию к тому, нужны ли нам самоорганизующиеся команды или нет, а это уже оффтоп и холивор
Приведенная выше метода как раз для самоорганизующейся команды находящейся без функционального руководства (находящейся на стадии S4 по Херши-Бланшару)
Приведенная выше метода как раз для самоорганизующейся команды находящейся без функционального руководства (находящейся на стадии S4 по Херши-Бланшару)
Согласен, что дальше уже в оффтоп уходим.
А нужны ли тогда самоорганизующейся команде метрики типа вашей?
А нужны ли тогда самоорганизующейся команде метрики типа вашей?
Скажем так, у меня 4 команды разработки и сейчас они созрели к введению подобной оценки (Agile:EF на базе Shodan,). В жизни любой команды наступает момент, когда у них появляется мнение, что у них и так всё хорошо и ничего не надо менять (соотв. если они самоорганизующиеся, то они ничего менять и не будут) вот подобная оценка должна показать векторы роста по некоторым направлениям (сдвинуть команду с мёртвой точки)
А вы уверены, что дальнейшая «эджайлизация» увеличит эффективность и качество именно на ваших проектах? Проекты-то разные бывают.
Хотя я опять ухожу в оффтоп и холивар.
Хотя я опять ухожу в оффтоп и холивар.
Не, тут не оффтоп. Я понимаю, что проекты бывают разные и вполне может получаться как в известной пословице, как дурака заставили богу молиться.
У себя в проекте я вижу, что от этого будет profit.
Пост я написал для того, чтобы этот инструмент знали и про него помнили, а уж пользоваться или нет — это дело каждого. Ведь инструмент хорош к месту и ко времени.
Серебряных пуль не бывает (с) Ф.Брукс
У себя в проекте я вижу, что от этого будет profit.
Пост я написал для того, чтобы этот инструмент знали и про него помнили, а уж пользоваться или нет — это дело каждого. Ведь инструмент хорош к месту и ко времени.
Серебряных пуль не бывает (с) Ф.Брукс
Ну и есть некоторые сомнения, что подобный опрос команды, которая считает, что у них «все хорошо», даст реальную картину. Тут нужна взвешенная оценка эксперта снаружи. ИМХО, конечно.
Тут надо подходить к команде не как PM а как Agile Coach. Надо им не указывать на промахи, а делать так, чтобы они сами их заметили и сами выработали решение по развитию.
Про экспертную оценку вспомнилась пословица: «Дай человеку рыбу и он будет сыт весь день, научи человека ловить рыбу и он будет сыт всю жизнь»
P.S. Но опять-же это не всегда и не везде применимо. Надо действовать по ситуации.
Про экспертную оценку вспомнилась пословица: «Дай человеку рыбу и он будет сыт весь день, научи человека ловить рыбу и он будет сыт всю жизнь»
P.S. Но опять-же это не всегда и не везде применимо. Надо действовать по ситуации.
Попробую переформулирую уже озвученную мысль — в сильной команде всегда есть люди, которые всегда интересуются тем, как делать свою работу эффективнее (и надо давать им время на то, чтобы у них была возможность что-то читать и экспериментировать). В командах, где есть разделение по статусу, такие люди обычно и становятся синьорами.
Синьоры обычно всегда знают, что именно можно улучшить (совершенствование — процесс бесконечный).
Если таких людей нет — это проблема не процесса, а команды, и мне кажется, что ваши метрики тут ничего не дадут. Просто потому что команда уже считает, что у них все хорошо, по вашему же условию.
P.S. Сорри, но я от «Agile Coach» и прочих скрамовских переименований и подмен понятий сразу вспоминаю культ карго и книжку про кактусы и розы.
Синьоры обычно всегда знают, что именно можно улучшить (совершенствование — процесс бесконечный).
Если таких людей нет — это проблема не процесса, а команды, и мне кажется, что ваши метрики тут ничего не дадут. Просто потому что команда уже считает, что у них все хорошо, по вашему же условию.
P.S. Сорри, но я от «Agile Coach» и прочих скрамовских переименований и подмен понятий сразу вспоминаю культ карго и книжку про кактусы и розы.
Всё верно, но «синьоры» хорошо работают с технологиями и плохо с процессами и коммуникациями. Вот у меня как раз подобная вещь выходит, в командах есть люди продвигающие технологии, библиотеки, стандарты. Проблемы начинаются когда дело доходит до коммуникаций. Разгребаешь то как отработали и видишь:
* тут слишком затянули ревью кода
* тут не до конца договорились с аналитиком, на финальной стадии пришлось переделывать
* тут не договорились с архитектором, сделали не так как надо, пришлось переделывать
* писали долго код, начали мержиться — всё развалилось
это всё проблемы которые решаются коммуникативными практиками: парная работа, раннее ревью, частая интеграция, валидация курса работы с заказчиком (аналитиком), внутренняя коммуникация в команде, чтобы заранее распознавать проблемы
* тут слишком затянули ревью кода
* тут не до конца договорились с аналитиком, на финальной стадии пришлось переделывать
* тут не договорились с архитектором, сделали не так как надо, пришлось переделывать
* писали долго код, начали мержиться — всё развалилось
это всё проблемы которые решаются коммуникативными практиками: парная работа, раннее ревью, частая интеграция, валидация курса работы с заказчиком (аналитиком), внутренняя коммуникация в команде, чтобы заранее распознавать проблемы
Всё верно, но «синьоры» хорошо работают с технологиями и плохо с процессами и коммуникациями.
Синьоры, которые не шарят в процессах — нифига не синьоры. Синьорство — это не столько скилл кодинга, а в том числе и понимание целей и процесса разработки.
* тут не до конца договорились с аналитиком, на финальной стадии
пришлось переделывать
Это происходит всегда, надо учитывать при планировании.
* тут не договорились с архитектором, сделали не так как надо, пришлось переделывать
Аналогично.
* писали долго код, начали мержиться — всё развалилось.
Continious Integration, без которого собственно любой эджайл плохо работает (см. Фаулера). И это не коммуникативная методика, чисто техническая.
Мне тут за спиной подсказывают, что есть одна реально осмысленная метрика процесса — cycle time, и рекомендуют перечитать Conitious Delivery.
Синьоры, которые не шарят в процессах — нифига не синьоры. Синьорство — это не столько скилл кодинга, а в том числе и понимание целей и процесса разработки.
* тут не до конца договорились с аналитиком, на финальной стадии
пришлось переделывать
Это происходит всегда, надо учитывать при планировании.
* тут не договорились с архитектором, сделали не так как надо, пришлось переделывать
Аналогично.
* писали долго код, начали мержиться — всё развалилось.
Continious Integration, без которого собственно любой эджайл плохо работает (см. Фаулера). И это не коммуникативная методика, чисто техническая.
Мне тут за спиной подсказывают, что есть одна реально осмысленная метрика процесса — cycle time, и рекомендуют перечитать Conitious Delivery.
Итак:
cycle time — это основополагающий показатель если выработаете по Kanban, его считать может кто угодно (а лучше автоматизированная система) его анализ даёт понять где в системе узкие места, но не даёт рецептов по их исправлению. Тема данного топика и предыдущего совсем про другое.
Синьоры, которые не шарят в процессах — нифига не синьоры. Синьорство — это не столько скилл кодинга, а в том числе и понимание целей и процесса разработки.
ключевое я выделил жирным, но они не понимают что такое синергия и чем командная работа отличается от индивидуальной работы нескольких человек. Вы не задумывались над тем, что вы как те синьоры, которых я выше описывал просто не видите куда дальше можно копнуть в процессе, чтобы повысить производительность?
Это происходит всегда, надо учитывать при планировании.
В таком случае вы просто признаёте этот риск и никак не пытаетесь с ним бороться. А с ним бороться можно и очень эффективно (сужу по своему опыту)
Continious Integration, без которого собственно любой эджайл плохо работает (см. Фаулера). И это не коммуникативная методика, чисто техническая. В теории код надо интегрировать чуть ли не раз в 2 часа, на практике получается гораздо реже (ведь интегрировать надо потенциально рабочий код а не код который даже не компилируется). При нормальной внутрикомандной коммуникации главные проблемы слома сборки из-за каких-то изменений (кто-то поменял протокол, или поменял версию какой-то библиотеки) все готовы к сломам и заранее планируют время починки.
cycle time — это основополагающий показатель если выработаете по Kanban, его считать может кто угодно (а лучше автоматизированная система) его анализ даёт понять где в системе узкие места, но не даёт рецептов по их исправлению. Тема данного топика и предыдущего совсем про другое.
Синьоры, которые не шарят в процессах — нифига не синьоры. Синьорство — это не столько скилл кодинга, а в том числе и понимание целей и процесса разработки.
ключевое я выделил жирным, но они не понимают что такое синергия и чем командная работа отличается от индивидуальной работы нескольких человек. Вы не задумывались над тем, что вы как те синьоры, которых я выше описывал просто не видите куда дальше можно копнуть в процессе, чтобы повысить производительность?
Это происходит всегда, надо учитывать при планировании.
В таком случае вы просто признаёте этот риск и никак не пытаетесь с ним бороться. А с ним бороться можно и очень эффективно (сужу по своему опыту)
Continious Integration, без которого собственно любой эджайл плохо работает (см. Фаулера). И это не коммуникативная методика, чисто техническая. В теории код надо интегрировать чуть ли не раз в 2 часа, на практике получается гораздо реже (ведь интегрировать надо потенциально рабочий код а не код который даже не компилируется). При нормальной внутрикомандной коммуникации главные проблемы слома сборки из-за каких-то изменений (кто-то поменял протокол, или поменял версию какой-то библиотеки) все готовы к сломам и заранее планируют время починки.
cycle time — это основополагающий показатель если выработаете по Kanban, его считать может кто угодно (а лучше автоматизированная система) его анализ даёт понять где в системе узкие места, но не даёт рецептов по их исправлению. Тема данного топика и предыдущего совсем про другое.
Не канбана, а любого итеративного процесса.
Посмотрите вот здесь — martinfowler.com/articles/planningXpIteration.html
А какие рецепты дают ваши метрики?
Вы не задумывались над тем, что вы как те синьоры, которых я выше описывал просто не видите куда дальше можно копнуть в процессе, чтобы повысить производительность?
В том процессе, что у нас, я вижу огромное количество того, что можно поменять и улучшить ;)
синергия и чем командная работа отличается от индивидуальной работы нескольких человек.
Еще раз, если человек не понимает как работать в команде — ему рано в синьоры. Каким бы крутым кодером он ни был.
У нас получается чаще чем раз в 2 часа.
При нормальной внутрикомандной коммуникации главные проблемы слома сборки из-за каких-то изменений (кто-то поменял протокол, или поменял версию какой-то библиотеки) все готовы к сломам и заранее планируют время починки.
Отвечу вашей же фразой:
В таком случае вы просто признаёте этот риск и никак не пытаетесь с ним бороться. А с ним бороться можно и очень эффективно (сужу по своему опыту)
Не канбана, а любого итеративного процесса.
Посмотрите вот здесь — martinfowler.com/articles/planningXpIteration.html
А какие рецепты дают ваши метрики?
Вы не задумывались над тем, что вы как те синьоры, которых я выше описывал просто не видите куда дальше можно копнуть в процессе, чтобы повысить производительность?
В том процессе, что у нас, я вижу огромное количество того, что можно поменять и улучшить ;)
синергия и чем командная работа отличается от индивидуальной работы нескольких человек.
Еще раз, если человек не понимает как работать в команде — ему рано в синьоры. Каким бы крутым кодером он ни был.
У нас получается чаще чем раз в 2 часа.
При нормальной внутрикомандной коммуникации главные проблемы слома сборки из-за каких-то изменений (кто-то поменял протокол, или поменял версию какой-то библиотеки) все готовы к сломам и заранее планируют время починки.
Отвечу вашей же фразой:
В таком случае вы просто признаёте этот риск и никак не пытаетесь с ним бороться. А с ним бороться можно и очень эффективно (сужу по своему опыту)
И да, при нормальной внутрикомандной коммуникации и выделенных ответственных лицах поломок протоколов и смен версий библиотек не бывает.
Это очень большая проблема «чистокровного» скрама, за что я его и не признаю.
Это очень большая проблема «чистокровного» скрама, за что я его и не признаю.
Sign up to leave a comment.
Глубина погружения в Agile: Agile Evaluation Framework