Содержание

Аннотация

Докладчики

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

Чтобы уменьшить риск непонимания в команде и между командой и заказчиком вам следует принять «критерии готовности» (Definition of Done) и начать использовать их в своей ежедневной работе. С целью предупреждения возможных проблем и скрытых сложностей, в докладе я поделюсь собственным опытом создания компактных и эффективных критериев готовности. Будут затронуты темы жизненного цикла, важных пунктов, подходов и практик для создания критериев готовности для вашего проекта. Также отдельное внимание будет уделено вопросам различных уровней критериев готовности и основным ошибкам, с которыми вы можете столкнуться.

Вы должны гордиться своей работой, в очередной раз произнося слово «Готово!».

Видео


Для этого доклада нужен подкаст (аудиозапись)?

Презентация

Примечания и отзывы

…ко времени начала нашего доклада народ подтянулся и зал заполнился наполовину. Не все доклады закончились к тому времени, и некоторые участники присоединялись по ходу доклада. Мы постарались донести до аудитории простую, но очень полезную практику в Agile подходах – Definition of Done. В докладе речь шла о предпосылках применения данной практики, полезных приемах и подходах к ее внедрению, проблемах и решениях при ее применении. В конце мы предложили участникам составить свой собственный Definition of Done, а за наиболее понравившиеся варианты подарили оставшиеся книги Хенрика Книберга. Судя по отзывам в ленте Twitter, наш доклад понравился многим. ©

Star.svgStar.svgStar.svg

Те же двое, что утром рассказывали про code review. Но на этот раз все было гораздо более скучно почему-то. То ли я просто уже устал?

Заметок осталось очень мало, помню, что по-моему говорилось много очевидных вещей. Например, что для разных стадий процесса нужен свой чеклист «DoD», или что гораздо полезнее автоматизировать процесс так, чтобы необходимо было обработать чеклист (workflow или как наши бегунки).

Докладчики пытались работать с залом, задавать вопросы, но люди часто предлагали какие-то жутко несуразные вещи. Под конец я окончательно заснул.

AgileDays-2011: Отчет Беспальчука И.А./Николай Алименков, Алексей Солнцев. Что означает «Готово!»: применение практики Definition of Done

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

Заметки. Как-то они примитивно про скрам — мол в середине никто не смотрит за процессом… А как же движение по доске? И про канбан — что только одна задача в разработке. В целом по-разному оно.

Ну и дальше — no commitment, no understanding, какие-то известные штуки. Надо искать способы договоренности, всякая демократия и прочее…

Несогласие двух вариантов: без аргументов и с аргументами. Если с аргументами — обсуждаем. Если без — решаем с менеджером (Хенрик сказал бы — гнать из команды).

Максим Цепков - AgileDays-2011/Что означает «Готово!»

Доклад очень хороший, один из лучших на конференции. Парни реально спелись, и выступали дуэтом (в свое время мы с Андреем Бибичевым собирались такие номера освоить, но не успели).

Правда этот парный конферанс было очень сложно:

С самого начала, ссылаясь на старого доброго Деминга, ребята заявили, что и никакие отделы и комитеты по качеству проблему не решат — качество должно быть встроено в процесс.

А Agile, и SCRUM в частности — это не «гибкость во всем», это гибкость, за счет того, что есть железно прочные элементы, и в SCRUM таковым является «Definition of Done», и бинарная логика выполненности задач.

В некотом смысле (мои личные фантазии-метафоры), это переход от классической физики, где частицы могли иметь любые координаты и состояния (ну и соотвественно, задач, которые могли быть выполнены на 45%, 57%, и зачастую даже на 154%) к квантовой, где состояния задач внутри итерации внешнего наблюдателю вообще неизвестны («неопределенность Гейзенберга»), но к концу итерации («проекция на базис»), они могут быть только в одном из двух состояний — «выполнено»/fail».

Может это излишний идеализм — метафора выступающих «ваша жена же не зовет вас обедать, когда еще не готово!» (бггг, они не знакомы с моей), но видимо, идеализм правильный.

Говорилось и о технических вопросах — как и где хранить Definition Of Done, как его формулировать на неконфликтующие уровни (DoDы для отдельных задач, фич, итераций, релизов, …)

Интересный момент — у ребят в DoD релиза обязательно входят тесты на Production серверах, вне зависимости от количества тестирования в тестовом окружении. Настоящие боевые тесты — они держат фейковые аккаунты с настоящими карточками и деньгами (тут мне вспоминается широко известная в нашей компании история про «шесть проводок»).


Обсуждение:Что означает «Готово!» — применение практики Definition of Done (Николай Алименков, Алексей Солнцев, AgileDays-2011)/Заметки Стаса Фомина




Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Что означает «Готово!» — применение практики Definition of Done (Николай Алименков, Алексей Солнцев, AgileDays-2011)»