Дата публикации: 18.09.16
Примерный чек-лист для скрам мастеров (ScrumMasters) Часть 3 и 4
Примерный чек-лист для скрам мастеров (ScrumMasters) Часть 3 и 4. Есть ли в вашей системе для разработки кнопка "нажми, чтобы проверить", с помощью которой каждый из вашей или другой команды мог ы просто обнаружить допущенные ошибки регресса (сломанную функциональность, работавшую до изменений)?Продолжаем)
Часть 3 - Как поживают ваши инженерные практики?
- Есть ли в вашей системе для разработки кнопка "нажми, чтобы проверить", с помощью которой каждый из вашей или другой команды мог ы просто обнаружить допущенные ошибки регресса (сломанную функциональность, работавшую до изменений)? Обычно это достигается с помощью xUnit (jUnit, nUnit и т.д.).
- Существует ли оптимальный баланс между автоматическим системным полным тестированием (функциональным тестированием) и автоматическим юнит тестированием?
- Использует ли команда при системном и юнит тестировании язык совпадающий я языком разработки? Совместная работа не становится лучше от использования проприетарных скриптовых языков или инструментов записи действий, которыми только часть команды умеет пользоваться.
- Затрагивает ли команда "серую зону" между системным тестированием и юнит тестированием?
- Существует ли на сервере непрерывной интеграции автоматическое уведомление в случае появления ошибки регресса? Может ли скорость появления такого уведомления быть снижена до часов или минут? ("Ежедневные билды для слабаков" Kent Beck)
- Входят ли все тесты в результат работы сервера непрерывной интеграции?
- Поняли ли члены команды всю прелесть непрерывного дизайна и постоянного рефакторинга, как альтернативу Большого дизайна до разработки? Рефакторинг имеет четкое определение: изменение внутренней структуры системы без изменения внешнего поведения. Рефакторинг должен случаться несколько раз в час, где бы ни было - дублирование кода, сложная условная логика (видная по избыточным отступам и длинным методам), плохое именование идентификаторов, избыточная связь между объектами и т.п. Выполнять рефакторинг с уверенностью возможно только при покрытии автоматическими тестами. Пренебрежение рефакторингом делает сложным изменение продукта в будущем, особенно с тех пор, как стало тяжело найти хорошего разработчика, готового работать с плохим кодом.
- Включают ли ваши критерии выполнения задачи для каждого функционального задания из бэклога полное автоматизированное покрытие тестами и рефакторинг? Изучение методов разработки через тестирование (TDD) увеличит возможность достижения такой задачи.
- Применяется ли парное программирование при большинстве разработок? Парное программирование радикально повышает уровень пригодности кода к сопровождению и уменьшает количество багов. Но этот метод сталкивается с проблемой взаимодействия людей и иногда занимает большее время (если вы измеряете производительность в строчках кода, чаще чем в рабочей функциональности). Введите для примера дни парного программирования. И наверняка некоторые разработчики предпочтут работать таким образом.
Часть 4 - Как дела в вашей организации?
- Достаточное ли количество меж группового взаимодействия в вашей организации? Скрам скрама (Scrum of Scrum) единственный путь добиться такого взаимодействия и не обязательно самый лучший.
- Могут ли ваши команды независимо друг от друга реализовать работающую функциональность даже при пересечении архитектурных границ?
- Встречаются ли ваши скрам мастера друг с другом, для устранения возможных препятствий на уровне организации?
- При необходимости передаются ли организационные проблемы в офис директора по разработке? Может ли быть определена цена в долларах потерь от позднего выхода на рынок, потерь от падения качества, потерь клиентов от нереализованных возможностей? (Но учитесь на ошибках Ken Schwaber "Мертвый скрам мастер бесполезный скрам мастер")
- Относится ли ваша организация к тем редким организациям, где карьерный путь совпадает с общими целями ваших команд? Отвечайте "нет", если в вашей организации в карьерном смысле выгоднее заниматься разработкой или архитектурой, чем тестированием, автоматизацией или документированием.
- Признавала ли отраслевая пресса или другие независимые источники вашу организацию, как одну из лучших организаций для работы или лидером в вашей индустрии?
- Создаете ли вы из вашей организации "обучающуюся организацию"?
Заключение
Если вы сможете ответить на большинство этих пунктов, и у вас еще останется время до конца дня, дайте мне знать)))
Нет готовой формулы для овладения мастерством. Этот список может как помочь вам в вашей ситуации, так и быть бесполезным.
После того, как вы начинаете понимать, что вы могли бы сделать, чтобы изменить всю ситуацию, вы поймете, что вы боитесь делать это. Это знак вам - вы на правильном пути.