Как выглядит «определение выполненного» для зрелой команды?

9

При рассмотрении примеров определений, сделанных в различных источниках, они обычно включают в себя такие пункты, как

  • код завершен
  • модульные тесты
  • код рецензируется или в паре
  • проверенный код
  • документация обновлена
  • ...

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

С другой стороны, во многих литературных источниках утверждается, что у всех высокопроизводительных команд есть четкое определение «сделано». Это намеки на то, что мы можем упустить возможность улучшить здесь.

Так, каковы примеры сильных определений зрелой команды? Какие точки зрения они обычно включают?

Тобиас
источник
10
Когда клиент звонит, это сделано.
Мэтт С
7
Никто никогда не пропустит обновление документации?
JeffO
1
Есть ли у вашей организации проблемы с некоторыми людьми, думающими, что что-то сделано, когда другие люди думают, что еще есть чем заняться? Если нет, то вам не нужно тратить время здесь. Если они это сделают , у вас есть отправная точка для вашего списка
AakashM
@MattS: Если вам нужно подождать, пока клиент сделает это, у вас есть много историй, ожидающих завершения. Должен быть какой-то статус «разработка завершена» или «готов к UAT» для истории, которая в разговорной речи «сделана, насколько команда знает».
KeithS
Выберите систему и придерживайтесь ее. Кайдзан это изредка. Это тот случай, когда последовательность повышает производительность. Сложной частью является процесс (диктатор на всю жизнь) в начале, пока все не увидят выгоды (да, да, продайте его).
Пол

Ответы:

9

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

На мой взгляд, перечислите все, в том числе и очевидное. Возможно, имейте «короткий чит-лист» для неочевидных, если он помогает тем, кто хочет более короткий список, но учитывает случай, когда новые участники прыгают.

Это итеративный процесс, каждый раз, когда вы видите что-то, что можете улучшить, добавьте это в определение готового. Со временем вы разработаете список, который имеет отношение к вашей компании. Ананн уже упомянул кое-что стоящее.

Насир
источник
Отличное замечание о новых членах команды, Насир.
Carson63000
Спасибо. Мы сталкиваемся с этой ситуацией довольно регулярно, и такие старые вещи, как я, иногда забывают.
Насир
7

То, что эти пункты очевидны, не означает, что люди всегда будут их выполнять. Давайте возьмем два других примера - пилотов и хирургов. В кабине коммерческого авиалайнера или операционной есть несколько человек, с большим опытом и знаниями. Тем не менее, все идет не так, как надо - шаги делаются не по порядку, что-то забыто, что-то сделано неправильно. Я видел несколько источников сайта, что большое количество (до 70%) авиационных происшествий, связанных с ошибкой пилота, можно было бы предотвратить с помощью контрольного списка . В медицинском мире до 29% исков о халатности в Нидерландах можно было бы предотвратить с помощью контрольного списка, считают исследователи., Хотя эти люди были обучены и в ретроспективе, вероятно, легко могли бы определить, что они сделали неправильно, что-то случилось, что заставило их упасть. Я еще не читал это, но Манифест Контрольного списка должен быть актуальным. Это написано из медицинской профессии, но преимущества создания контрольного списка или блок-схемы, видимой как напоминание о том, что делать, применимы к любой профессии.

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

Шаг второй, чтобы решить, что входит в этот контрольный список для вашего определения готово. Все, что вам нужно сделать для выполнения задачи, должно быть конкретным, однозначным, приемлемым и реалистичным. Это также должно быть в контексте времени для рассмотрения сделанного. Например, вам не нужно включать «изменение кода» или «изменение дизайна» в определение «готово» - если вам не нужно менять рабочий продукт, вам не понадобится рассказ.

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

  • Были ли обновлены все связанные юнит-тесты, интеграционные, системные и приемочные тесты?
  • Был ли продукт работы преобразован в его высвобождаемую форму? Например, встроенный код, документация в формате экспортируемого файла и т. Д.
  • Все ли связанные рабочие продукты прошли рецензирование? Примеры рабочих продуктов включают исходный код (производство и тестирование), комментарии, проектную документацию, процедуры тестирования и руководства пользователя.
  • Все ли соответствующие тесты (на всех уровнях тестирования) были выполнены и пройдены?
  • Код был объединен с хранилищем интеграции?

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

Томас Оуэнс
источник
Все это звучит очень хорошо в теории, но как вы пришли к тому, что актуально? Например, мне не нужен контрольный список, чтобы чистить зубы каждое утро, но я все еще делаю это. Точки, которые вы перечисляете (тесты проходят, рецензируются ...), напоминают чистку зубов, так в чем же ценность?
Тобиас
@Tobias Значение приходит в повторяемости. Теперь вы можете визуализировать свой процесс и поделиться им с другими. Вы также можете визуализировать его, чтобы определить области для улучшения (то, что люди делают, которых нет в списке, вещи, которые не должны быть в списке, вещи, которые люди не делают, которые есть в списке).
Томас Оуэнс
1

На самом деле это звучит так, будто вы один из счастливчиков:

В нашей команде подобный список есть, но никто никогда не смотрит на него, потому что эти пункты кажутся настолько очевидными

Ваша команда уже "взрослая" ;-). Но всегда есть возможности для улучшения!

На ваш вопрос:

Так, каковы примеры сильных определений зрелой команды? Какие точки зрения они обычно включают?

В верхней части списка вы можете добавить:

Различные показатели качества кода: - нестабильность, абстракция - LOC против DLOC (задокументировано) - и т. Д ...

Эмпирическое правило может заключаться в том, что показатель не должен ухудшаться с вашим коммитом. Кроме того, вы можете сформулировать «done: withExcellence», если кто-то действительно улучшит показатели. Хотя это (улучшение показателей) обычно не является частью этапов разработки (новые функции), а этапами рефакторинга.

В одной из моих прошлых компаний у нас было определение «готово», в котором говорилось, что ваши показатели должны оставаться ниже определенных порогов, если вы превысите их, вы еще не закончили. (Цикломатическая сложность никогда не должна превышать 15, если у вас нет очень очень очень хорошего оправдания, такого как сложные кальки.)

То же самое касается нарушений типа Checkstyle, особенно если у вас есть собственный набор правил для проверки стиля кода вашей команды. Если вы нарушаете стандарт кодирования, это еще не сделано.

Тогда вы можете не только выполнить UnitTest, вы можете измерить охват кода. Если не менее 50% покрыты, вы не сделали. Несмотря на то, что это не совсем правильное определение, поскольку у вас должны быть тесты для основных / основных / критических методов, а не обязательно для 100% базы кода.

О да ... и если у вас есть (вы должны) CI-сервер с автоматизированной интеграцией ветвления ... все будет сделано, только если ваш коммит в ветке DEV слился с текущей веткой LIVE и тоже не вызовет ошибок. (Юнит-тесты и т. Д.)

хммм ... это все, что я помню, хорошо знаю по прошлым компаниям / проектам, которые не были упомянуты в вашем списке.

Я надеюсь, что это дало вам некоторые идеи ;-)

Ура,

anann

Wizard Of Tech
источник
Метрики качества кода - интересная идея, о которой мы еще не думали. Остальное (стиль кодирования, CI зеленый после слияния) уже является частью "очевидных частей".
Тобиас
1

В среде TDD / BDD определение «готово» (технически «код завершен», поскольку определение «действительно« сделано »» Мэтта S является довольно простым):

  • Все автоматизированные тесты пройдены (эти автоматические тесты должны включать новые, написанные для рассматриваемой истории, чтобы убедиться, что требуемая функциональность или поведение существует и работает)
  • Проверка кода пройдена (по крайней мере один старший разработчик в команде доволен тем, что ваша работа становится частью кодовой базы, и что вы не «обманули» или «взломали» свой путь в истории)
  • Успешная фиксация (в том числе сборочный бот, прошедший все автоматические тесты, метрики покрытия кода, проверки стиля и т.д.)

В этот момент вы можете двигаться дальше. Эти три пункта являются критическими, но они все, что должно беспокоить среднего командного кодера. Написанные или неписанные, они неприкосновенны в среде TDD. Документирование, когда кодировщики занимаются документированием, является дополнительным пунктом. В моей последней Agile команде документация была обработана BA / QAs; они знали, чего хочет клиент, запускали UAT и, таким образом, лучше всего могли документировать новую функцию так, чтобы это имело смысл для клиента, поэтому документирование не было частью определения кодера «выполнено», хотя и было частью из определения команды.

Keiths
источник