Вроде мы все разговариваем на одном языке, но каждый из нас понимает слова «скоро», «качественно» и «готово» по-разному. Вы заканчиваете итерацию, а заказчик отказывается принимать «готовую» функциональность? Тестировщики не могут начать тестирование «законченного» кода? Вся команда не может продолжать работу из-за того, что один из разработчиков «завершил» задачу? Вы тратите кучу времени в следующей итерации чтобы «доделать» работу из предыдущей итерации, которая считалась успешной? Все это происходит от разного понимания базовых, но очень важных терминов.
Чтобы уменьшить риск непонимания в команде и между командой и заказчиком вам следует принять «критерии готовности» (Definition of Done) и начать использовать их в своей ежедневной работе. С целью предупреждения возможных проблем и скрытых сложностей, в докладе я поделюсь собственным опытом создания компактных и эффективных критериев готовности. Будут затронуты темы жизненного цикла, важных пунктов, подходов и практик для создания критериев готовности для вашего проекта. Также отдельное внимание будет уделено вопросам различных уровней критериев готовности и основным ошибкам, с которыми вы можете столкнуться.
Вы должны гордиться своей работой, в очередной раз произнося слово «Готово!».
Что означает «Готово!» — применение практики Definition of Done (Николай Алименков, Алексей Солнцев, AgileDays-2011)
Те же двое, что утром рассказывали про code review. Но на этот раз все было гораздо более скучно почему-то. То ли я просто уже устал?
Заметок осталось очень мало, помню, что по-моему говорилось много очевидных вещей. Например, что для разных стадий процесса нужен свой чеклист «DoD», или что гораздо полезнее автоматизировать процесс так, чтобы необходимо было обработать чеклист (workflow или как наши бегунки).
Докладчики пытались работать с залом, задавать вопросы, но люди часто предлагали какие-то жутко несуразные вещи. Под конец я окончательно заснул.
Что означает «Готово!» — применение практики Definition of Done (Николай Алименков, Алексей Солнцев, AgileDays-2011)
Слушал с середины. В целом показалось, что это борьба с ветряными мельницами бюрократии с одной стороны, и самообманов — с другой — принять почти готовое. Экспрессивно, подряд и несколько сумбурно, без логики изложения.
Заметки.
Как-то они примитивно про скрам — мол в середине никто не смотрит за процессом… А как же движение по доске? И про канбан — что только одна задача в разработке. В целом по-разному оно.
Ну и дальше — no commitment, no understanding, какие-то известные штуки. Надо искать способы договоренности, всякая демократия и прочее…
Несогласие двух вариантов: без аргументов и с аргументами. Если с аргументами — обсуждаем. Если без — решаем с менеджером (Хенрик сказал бы — гнать из команды).
Доклад очень хороший, один из лучших на конференции.
Парни реально спелись, и выступали дуэтом (в свое время мы с Андреем Бибичевым собирались такие номера освоить, но не успели).
Правда этот парный конферанс было очень сложно:
Снимать — они расположились в двух, противоположных концах сцены, и видеооператор (Игорь?) был не в силах, даже на самом большом удалении поймать их обоих в кадр, а переключатся на «говорящего» было еще сложнее. Такое, по уму, можно снять только с двух камер, но увы, этого мы позволить не могли.
Монтировать — сначала я пытался смонтировать с переключением сцен — но это было нереально, и бестолку — ибо в половине случаев говорил тот участник, который отсутствовал на видео. Пришлось повесить их фото, разрезать картинку, засунуть в середину экран, ну и получить что-то, похожее на присутствие (плюс фантастические спецэффекты, когда выступающий телепортирует части тела из одной части сцены в другую).
С самого начала, ссылаясь на старого доброго Деминга, ребята заявили, что
и никакие отделы и комитеты по качеству проблему не решат — качество должно быть встроено в процесс.
А Agile, и SCRUM в частности — это не «гибкость во всем», это гибкость, за счет того, что есть железно прочные
элементы, и в SCRUM таковым является «Definition of Done», и бинарная логика выполненности задач.
В некотом смысле (мои личные фантазии-метафоры), это переход от классической физики, где частицы могли иметь любые координаты и состояния (ну и соотвественно, задач, которые могли быть выполнены на 45%, 57%, и зачастую даже на 154%) к квантовой, где состояния задач внутри итерации внешнего наблюдателю вообще неизвестны («неопределенность Гейзенберга»), но к концу итерации («проекция на базис»), они могут быть только в одном из двух состояний — «выполнено»/fail».
Никаких «99% готовности!» — угу, «все задачи готовы, на 99%».
Если вы нарушаете этот принцип — то у вас что угодно, только не SCRUM.
Если вы дали слабину в этом принципе, хоть в одном случае то все, «пропал калабуховский дом», вашему процессу крышка.
Может это излишний идеализм — метафора выступающих «ваша жена же не зовет вас обедать, когда еще не готово!» (бггг, они не знакомы с моей), но видимо, идеализм правильный.
Говорилось и о технических вопросах — как и где хранить Definition Of Done, как его формулировать на неконфликтующие уровни (DoDы для отдельных задач, фич, итераций, релизов, …)
Интересный момент — у ребят в DoD релиза обязательно входят тесты на Production серверах,
вне зависимости от количества тестирования в тестовом окружении.
Настоящие боевые тесты — они держат фейковые аккаунты с настоящими карточками и деньгами (тут мне вспоминается широко известная в нашей компании история про «шесть проводок»).
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
