При рассмотрении примеров определений, сделанных в различных источниках, они обычно включают в себя такие пункты, как
- код завершен
- модульные тесты
- код рецензируется или в паре
- проверенный код
- документация обновлена
- ...
В нашей команде у нас есть подобный список, но никто никогда не смотрит на него, потому что эти пункты кажутся настолько очевидными, что никому не придет в голову пропустить ни один из этих шагов. Поэтому нам было интересно, является ли это главным инструментом для перехода команд в гибкий процесс, и не следует ли нам просто избавиться от него.
С другой стороны, во многих литературных источниках утверждается, что у всех высокопроизводительных команд есть четкое определение «сделано». Это намеки на то, что мы можем упустить возможность улучшить здесь.
Так, каковы примеры сильных определений зрелой команды? Какие точки зрения они обычно включают?
источник
Ответы:
Руководящие принципы есть для всех. В зрелой команде, как вы упомянули, все это делают, так что это не значит, что для этого нет места. Предположим, присоединяется новый член, который ранее не был подвержен этой методологии. Наличие структуры на месте, было бы жизненно важно для него. Ему не пришлось бы беспокоить других участников или «забыть» результат.
На мой взгляд, перечислите все, в том числе и очевидное. Возможно, имейте «короткий чит-лист» для неочевидных, если он помогает тем, кто хочет более короткий список, но учитывает случай, когда новые участники прыгают.
Это итеративный процесс, каждый раз, когда вы видите что-то, что можете улучшить, добавьте это в определение готового. Со временем вы разработаете список, который имеет отношение к вашей компании. Ананн уже упомянул кое-что стоящее.
источник
То, что эти пункты очевидны, не означает, что люди всегда будут их выполнять. Давайте возьмем два других примера - пилотов и хирургов. В кабине коммерческого авиалайнера или операционной есть несколько человек, с большим опытом и знаниями. Тем не менее, все идет не так, как надо - шаги делаются не по порядку, что-то забыто, что-то сделано неправильно. Я видел несколько источников сайта, что большое количество (до 70%) авиационных происшествий, связанных с ошибкой пилота, можно было бы предотвратить с помощью контрольного списка . В медицинском мире до 29% исков о халатности в Нидерландах можно было бы предотвратить с помощью контрольного списка, считают исследователи., Хотя эти люди были обучены и в ретроспективе, вероятно, легко могли бы определить, что они сделали неправильно, что-то случилось, что заставило их упасть. Я еще не читал это, но Манифест Контрольного списка должен быть актуальным. Это написано из медицинской профессии, но преимущества создания контрольного списка или блок-схемы, видимой как напоминание о том, что делать, применимы к любой профессии.
Итак, первый шаг - создать список вещей, которые являются частью вашего определения готового, и сделать его видимым. Не имеет значения, насколько очевидна эта задача, если она должна быть завершена, чтобы история считалась выполненной, она должна быть в этом списке. Список должен быть где-то видимым для команды. Обратите внимание, что это не должно быть чем-то необычным или формальным - возможно, это просто серия вопросов, которые каждый должен задать себе перед тем, как можно будет назвать историю.
Шаг второй, чтобы решить, что входит в этот контрольный список для вашего определения готово. Все, что вам нужно сделать для выполнения задачи, должно быть конкретным, однозначным, приемлемым и реалистичным. Это также должно быть в контексте времени для рассмотрения сделанного. Например, вам не нужно включать «изменение кода» или «изменение дизайна» в определение «готово» - если вам не нужно менять рабочий продукт, вам не понадобится рассказ.
Я подозреваю, что хороший контрольный список, который послужит основой для определения сделанного, будет:
Конечно, вам нужно придумать хорошее определение выполнения, которое включает в себя любые другие действия, которые ваша команда и ваш клиент чувствуют добавленной стоимостью. Если это в контрольном списке, это должно быть что-то, что нужно сделать, чтобы повысить ценность для кого-то (команда, клиент, пользователь). Четко перечисляя, что вы делаете, вы также можете идентифицировать и исключить посторонние действия, чтобы улучшить процесс.
источник
На самом деле это звучит так, будто вы один из счастливчиков:
Ваша команда уже "взрослая" ;-). Но всегда есть возможности для улучшения!
На ваш вопрос:
В верхней части списка вы можете добавить:
Различные показатели качества кода: - нестабильность, абстракция - LOC против DLOC (задокументировано) - и т. Д ...
Эмпирическое правило может заключаться в том, что показатель не должен ухудшаться с вашим коммитом. Кроме того, вы можете сформулировать «done: withExcellence», если кто-то действительно улучшит показатели. Хотя это (улучшение показателей) обычно не является частью этапов разработки (новые функции), а этапами рефакторинга.
В одной из моих прошлых компаний у нас было определение «готово», в котором говорилось, что ваши показатели должны оставаться ниже определенных порогов, если вы превысите их, вы еще не закончили. (Цикломатическая сложность никогда не должна превышать 15, если у вас нет очень очень очень хорошего оправдания, такого как сложные кальки.)
То же самое касается нарушений типа Checkstyle, особенно если у вас есть собственный набор правил для проверки стиля кода вашей команды. Если вы нарушаете стандарт кодирования, это еще не сделано.
Тогда вы можете не только выполнить UnitTest, вы можете измерить охват кода. Если не менее 50% покрыты, вы не сделали. Несмотря на то, что это не совсем правильное определение, поскольку у вас должны быть тесты для основных / основных / критических методов, а не обязательно для 100% базы кода.
О да ... и если у вас есть (вы должны) CI-сервер с автоматизированной интеграцией ветвления ... все будет сделано, только если ваш коммит в ветке DEV слился с текущей веткой LIVE и тоже не вызовет ошибок. (Юнит-тесты и т. Д.)
хммм ... это все, что я помню, хорошо знаю по прошлым компаниям / проектам, которые не были упомянуты в вашем списке.
Я надеюсь, что это дало вам некоторые идеи ;-)
Ура,
anann
источник
В среде TDD / BDD определение «готово» (технически «код завершен», поскольку определение «действительно« сделано »» Мэтта S является довольно простым):
В этот момент вы можете двигаться дальше. Эти три пункта являются критическими, но они все, что должно беспокоить среднего командного кодера. Написанные или неписанные, они неприкосновенны в среде TDD. Документирование, когда кодировщики занимаются документированием, является дополнительным пунктом. В моей последней Agile команде документация была обработана BA / QAs; они знали, чего хочет клиент, запускали UAT и, таким образом, лучше всего могли документировать новую функцию так, чтобы это имело смысл для клиента, поэтому документирование не было частью определения кодера «выполнено», хотя и было частью из определения команды.
источник