Crystal Agile: Процесс обеспечивающий качество

Editor's Notes

• #3: Менеджмент со стороны заказчика распределен по странам, с командой одновременно работает 5 менеджеровКоманда распределена: 6 разработчиков в одном офисе и 3 в другомНекоторые члены команды имеют ярко выраженную специализацию1 тестировщик
• #6: Тестирование каждый раз «внезапно» стало сваливаться на последние 4-5 дней итерацииРезерв спринта не закрывался после планированияМного митингов отнимают много времени, единственный тестировщик должен присутствовать на всех нихОснова успеха быстрых процессов – комплексная автоматизация отсутствует из-за острой нехватки времени и плохого внутреннего качества проектаВ итоге мы поняли, что внедрили на проекте процесс направленный на скорость поставки, а не на обеспечение максимального качества
• #7: Анализ проблем указал на основные недостатки нашего подхода:Неэффективное планирование.Заказчик не понимает что такое Story Point и требует оценки в часах. Точной оценки.Закрыть спринт сразу после планирования итерации невозможно, ввиду того, что мы ведем не только разработку, но и поддержку старых версийВ угоду скорости страдает качество кода, накапливается технический долгМного времени тестировщика тратится на активности не связанные с тестированием
• #8: У нас было два пути:Пользуясь «гибкостью» аджайла создать свою методологию
• #9: Нами был выбран второй вариант. Мы остановились на методологии Crystal Clear.Какие её основные характеристики:“Human-powered” means that the focus is on achieving project success through enhancing the work of the people involved (other methodologies might be process-centric, or architecture-centric, or tool-centric, but Crystal is people-centric).“Ultralight” means that for whatever the project size and priorities, a Crystal-family methodology for the project will work to reduce the paperwork, overhead and bureaucracy to the least that is practical for the parameters of that project.“Stretch-to-fit” means that you start with something just smaller than you think you need, and grow it just enough to get it the right size for you (stretching is easier, safer and more efficient than cutting away)."Человек с питанием" означает, что акцент делается на достижении успеха проекта через повышение эффективности работы людей, вовлеченных (другие методологии может быть процесс-ориентированной, или архитектура-ориентированной, или инструмент-ориентированной, но Кристалл люди-ориентированной). "Ultralight" означает, что для любой размер и приоритетов проекта, методология Кристалл-семья для проекта будет способствовать снижению документы, накладные расходы и бюрократии мере, это практично для параметров этого проекта. "Растягивание к монтажу" означает, что вы начинаете с чем-то просто меньше, чем вы думаете, вам нужно, и вырастить его достаточно только, чтобы получить это правильный размер для вас (растяжение проще, безопаснее и эффективнее, чем срезая).
• #11: Решение этой проблемы начали со внедрения TDD, как самого популярного средства в подобных ситуациях.Однако внедрение затянулось и даже почти застопорилось. Почему?Фраза «напиши тест» действует на разработчик магическим образом, он перестает понимать чего от него хотят.Что является критерием достаточности теста для каждого отдельного случая?А может быть стоит писать юнит тесты по тестовым сценариям?Если да, то какие группы тестов использовать?А как быть, если разработка началась, но тестировщик не успел написать тестовые сценарии?Вместо TDD внедряем BDD (Behavior Driven Developement).Что это такое?Фактически это техника, с помощью которой можно научить разработчика критически оценивать свой код и писать тесты.Для составления достаточного количества тестов разработчику необходимо определить поведение системы в ситуациях прямо покрытых требованиями и покрыть тестами лишь эти ветви кода. (Пример вынес в Notes)Фрэнк: Что такое стек?Линда: Это структура данных, хранящая объекты в порядке «первым вошел, последним вышел» или «последним вошел, первым вышел». Обычно у этой структуры есть API с такими методами, как push() и pop(). Иногда присутствует метод peek().Фрэнк: Что делает метод push()?Линда: Метод push() принимает входной объект, например, foo и помещает его во внутренний контейнер, например, массив. Метод push() обычно ничего не возвращает.Фрэнк: Что будет, если передать методу push() два объекта, например, сначала foo, а потом bar?Линда: Второй объект bar должен оказаться наверху концептуального стека, содержащего по крайней мере два объекта, так что при вызове метода pop() объект bar должен быть извлечен первым, до первого объекта foo. Если метод pop() вызвать еще раз, должен быть возвращен объект foo и стек должен стать пустым (предполагается, что в нем ничего не было до того, как мы добавили эти два объекта).Фрэнк: Так метод pop() удаляет самый последний элемент, добавленный в стек?Линда: Да, метод pop() должен удалить верхний элемент, при этом предполагается, что в стеке есть элементы, чтобы их удалять. Метод peek() работает точно также, но при этом объект не удаляется. Метод peek() должен оставить верхний элемент в стеке.Фрэнк: Что будет, если вызвать метод pop(), когда в стек еще ничего не было добавлено?Линда: Метод pop() должен выдать исключение, показывающее, что в стек еще ничего не добавлялось.Фрэнк: Что будет, если выполнить команду push() null?Линда: Стек должен выдать исключение, так как null не является допустимым значением для метода push(). 
• #12: Вторая проблема – плохое планирование. И дело не в сложности оценки в часах, дело в том, что команда разбита на группы, которые занимаются различными модулями проекта, а также используют разные технологии.Что же в таком случае плохо в Planning Poker?Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта.Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories.
• #13: Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта.Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories.Пример 1:На планировании находятся 2 Java девелопера, 1 верстальщик, 1 тестировщик, 1 Flex/Flash разработчик, 1 JavaScript девелопер. На обсуждение выносится задача по разработке front-end приложения на Flex.Оценка флексера – 12 часов. Оценка тестировщика и верстальщика – 20 часов. Остальные оценивают в 4 часа, хотя тонкостей не знают. В итоге, даже обосновав правильность своей оценки основной разработчик уменьшает время в угоду остальным до 10 часов и в итоге не укладывается в него.То же самое с переоценкой времени, если никто не понимает как работает твой модуль, очень легко обосновать 40 часов вместо необходимых 12.Такой же пример будет для каждого пункта, их у меня из личной практики не одна сотня наберется.
• #14: Если разрабатывается функциональность затрагивающая один модуль приложения – участвуют только ответственные за эту часть разработчики веса их голосов равныЕсли затрагивается комплексная фича – каждый член команды, в зависимости от модуля и используемой технологии разработки получает вес голосаВведение персональных коэффициентов зависящих от предыдущей эффективности члена команды (пример в ноутах)Обязательно вводим в тестирование время на юнит тесты, не даем оценок только по функционалуВремя на тестирование оценивается тестировщиком совместно с непосредственно ответственным за разработку девелоперамПланирование ведется с учетом того, чтобы тестировщик начал работу в первый день спринта и не имел простоев в середине цикла и не был перегружен в конце (пример в ноутах)Пример:Разработчик 1 последние три спринта недооценивал время – даем ему повышающий коэффициент 1.2Разработчик 2 наоборот имеет склонность к переоценке времени – вводим понижающий коэффициент 0.7Пример 2: Идеальный цикл таков: Дни 1-2: Составление чеклистов по новым фичамДни 3-4: Начало тестирования, либо написание автотестов на фичи из предыдущих релизовДни 5-8: Тестирование по функциональностей по мере готовностиДень 9: Code freeze и полная регрессияДень 10: Поставка и UATТакже будет сопровождающая пояснения временная диаграмма
• #17: При планировании мы исходим из того, что при 10-дневном спринт мы берем из бэклога задач лишь на 9 дней.В итоге каждый член команды имеет день в запасе на urgent задачи.
• #18: Что делать, если срочных задач не появилось?Если кто-либо из команды не получил незапланированное задание, он берет первую по приоритету задачу из этого бэклога и занимается ей.
• #19: Каждый спринт выбирается член команды ответственный за каждую разрабатываемую фичу, в митингах участвует только он. Остальные занимаются работой.Ответственные меняются каждый спринт (если конечно функциональность не растянута на несколько спринтов, в таком случае смысла в смене человека нет).
• #20: Мы решили избавиться также от стэндап митингов.Почему?Зачем верстальщику, который пришел на работу в 8 утра и работающему над приложением А, знать что вчера делал разработчик. который пришел на работу в 12 и работает над приложением Б, которое не пересекается с А?А если нужно узнать статус?Мы перешли на Jira. Каждый день начиная работу над таском, разработчк жмет кнопку Start Work, уходя с работы делает Stop Work.Активность за день описывается в таске одним кратким, но понятным комментарием.