Если вы получаете гнилой код, значит, команда на самом деле не завершает истории, не так ли? Я предполагаю, что ваше определение «Готово» включает в себя наличие достаточного количества модульных тестов и приемочных тестов, их прохождение и наличие хорошо структурированного (т.е. реорганизованного) кода; если это не так, я рекомендую вам изменить его, чтобы он работал.

Я предполагаю, что если основное внимание уделяется выполнению отдельных задач, то:

1) Отдельные задачи видны команде, а общая ценность спринта — нет, и

2) Члены команды индивидуально вознаграждаются или оцениваются в соответствии с количеством выполненных задач, а не в соответствии с общей ценностью спринта.

Если вы хотите, чтобы команда приносила пользу в целом, вам нужно измерять (и делать видимыми) ценность на командном уровне, а не усилия на индивидуальном уровне. (Кстати, это пример See the all .)

Производительность также является вопросом всей системы, но по-другому: единственные части системы, на ускорение которых вы хотите потратить усилия, — это узкие места. Быть узким местом — это свойство не части системы (даже той части, которая в настоящее время является узким местом), а целого.

Я рекомендую вам часто измерять производительность системы, либо каждый день, либо при каждой интеграции, в зависимости от того, что происходит чаще. Это позволит вам узнать, когда производительность упадет ниже порогового значения, и даст вам представление о том, какие изменения частично вызвали это. Повышение производительности, вероятно, должно принимать форму историй: обычно всплеск, чтобы попробовать определенный подход к оптимизации, а затем (если он успешен) история разработки для его реализации.

Постоянный рефакторинг поможет вам достичь 3 (Решить как можно позже). Регулярные ретроспективы помогут вашей команде достичь 7 (Просмотреть все). Они также являются возможностью 1 (устранить потери), особенно если вы включите в свою ретроспективу деятельность, направленную на выявление потерь (подсказка: ищите работы, накапливающиеся в очередях).

Я надеюсь, что это полезно.

Я рекомендую вам прочитать этот пост в блоге , так как он предлагает множество практик, предназначенных для содействия планированию по запросу, вовлечению команды и быстрой доставке. Также, на мой взгляд, вы можете проводить все три типа совещаний для совместной работы: совещание по планированию, ежедневное совещание, ретроспективное совещание. Такой подход позволит вам общаться и взаимодействовать с вашей командой, таким образом, удерживая их занятыми и в курсе текущей ситуации в вашем проекте.

What we feel is now that the team is more focused on completing individual tasks instead of thinking 

Раньше у меня был такой опыт, как ваш, когда программисты соревнуются друг с другом, чтобы набрать больше очков во время обзора спринта, когда мы показываем диаграмму выгорания. Формат моей диаграммы выгорания рассчитан на человека. Что я пытаюсь сделать, чтобы улучшить командную работу, так это убрать диаграмму выгорания, которая показывает только то, сколько баллов сожрал программист.

Чтобы еще больше улучшить это, я указываю только, сколько баллов сжигается за проект. Допустим, проект А, над ним работают 5 программистов, затем к концу дня (обзор спринта) я покажу, что мы сделали.

Чтобы разработчики «увидели целое», PO должен обсудить с ними свое видение. Ему нужно определить, как минимум, следующую глобальную цель проекта и объяснить ее разработчикам. Например, он может планировать этапы. Вехи обычно состоят из нескольких историй/эпопей. Обсудите следующую веху, когда будет достигнута последняя, ​​что даст разработчикам общую картину.

К сожалению, по моему опыту, это может поставить под угрозу «решить как можно позже». Разработчики, знающие «все», как правило, стараются предвидеть события. Принцип простого дизайна — одна из самых сложных вещей для изучения. Это проблема опыта и мышления. Даже при том, что я прекрасно знаю об этом, я часто делаю это неправильно. Проблема в том, что интуитивно это неправильно. На самом деле, предвидеть вещи не так уж плохо. Просто мы обычно предвосхищаем неправильные вещи, потому что еще не видим полной картины. На мой взгляд, единственный способ научиться этому — заставить себя внедрить «бережливое производство» и испытать, что из этого получится. Занимайтесь парным программированием, просматривайте код и старайтесь помнить друг друга о своей философии обучения. Со временем станет легче. И вы убедитесь, что это работает.

«Расширение возможностей команды» неизбежно в Scrum. «Поставить как можно быстрее» происходит от «решить как можно позже» / «простой дизайн» + Scrum «сделать одно дело, прежде чем приступать к следующему». «Устранение отходов» тесно связано с «Простым дизайном»; если вы реализовали слишком много: не бойтесь выбрасывать. Парное программирование/обзоры невероятно «усиливают обучение»; также дайте разработчикам время прочитать о чистом коде, рефакторинге и т. д. и попрактиковаться в этом.

1. Устранение отходов. Найдите способ измерить то, что является расточительным (неиспользуемые функции, незавершенные функции, редко используемые функции, сбои связи, передачи и т. д.), все, что не добавляет ценности конечному результату.

Измерение потерь — это, вероятно, одно из самых простых мест для начала, и, по моему опыту, потери — это одна из самых больших потерь в любом проекте разработки программного обеспечения. Он проникает с самого высокого уровня функциональности, с которой сталкивается пользователь, на самые глубокие уровни ненужного кода. Проблема в том, что никому не нравится удалять функциональность, поэтому со временем она просто растет, как рак. Чем раньше она будет удалена, тем раньше никому не придется задаваться вопросом, какова ее ценность.

Начните измерять использование приложений в областях высокого уровня. Если вы заметили низкий уровень использования, расширьте свой мониторинг в соответствующей области. Как только вы определите области ненужной функциональности, запланируйте ее удаление, а затем выясните, как она вообще появилась. Скорее всего, ненужная функциональность возникла из-за другой формы потерь, таких как первоначальный сбой связи или передача решения.

Конечно, не сходите с ума, убедитесь, что ваши инвестиции в выявление отходов разумны, а не сами отходы :) по мере уменьшения отдачи не продолжайте инвестировать в более высокие уровни мониторинга... в конечном итоге вы можете изменить способность выявлять отходы чтобы заранее избегать сбоев связи и переключения каналов связи, что устраняет необходимость мониторинга постфактум.