главе 4

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

Приведем пример того, как scrum-команда использует вариантное мышление. Скажем, во время планирования спринта она разбила историю на четыре задачи, основанные на предположениях, сделанных о хранении данных в базе, и включающие задачу проектирования базы данных, которая, вероятно, должна быть выполнена ее администратором (Database administrator, DBA). Спустя две недели разработчик обнаруживает, что нужные данные уже есть в базе в другом формате. И для него гораздо полезнее самому создать объект или сервис, чем собирать данные в прежнем формате, который может использоваться остальной системой. Для scrum-команды это хорошая новость! Теперь она удалит задачу с доски задач на следующем ежедневном scrum-митинге, освобождая время в спринте, чтобы добавить еще один пункт бэклога или прояснить некоторые технические вопросы.

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

Многие разработчики ощущают, что их попросили пойти на ненужные или даже вредные технические компромиссы некие руководители, недостаточно разбирающиеся в проекте, – например, менеджер проекта или технический архитектор. С точки зрения программиста команду просят нарушить целостность программного обеспечения. А с позиции менеджера проекта или архитектора все выглядит так, будто разработчик нарушает обязательства. У каждого есть причина обвинить другого.

Проблема заключается в том, что разработка дизайна не должна стоять на первом месте – если его рассматривают как вариант, то команде легче создать лучшее ПО, а руководителю проекта и архитектору не придется менять свои планы и чувствовать себя ущемленными.

Но как добиться того, чтобы и руководство, и члены команды брали меньше обязательств и воспринимали большее количество «окончательных» решений в качестве вариантов?

ХР дает ясный ответ на этот вопрос – применять инкрементальное (пошаговое) проектирование. Когда команда создает простые компоненты и каждый из них выполняет что-то одно, это позволяет комбинировать их множеством различных способов. Рефакторинг и разработка через тестирование помогают поддерживать эти компоненты в максимально независимом состоянии.

Иными словами, отделенные, независимые компоненты создают варианты.

При возникновении новой идеи или обнаружении нового требования, если компоненты крупные и между ними много зависимостей, то команда потратит большую часть своих усилий на разделение этого кода путем «стрельбы дробью». Но команда XP, использующая инкрементальную архитектуру, сохраняет свои варианты открытыми. Она добавит только минимальный код, который должен удовлетворять новым требованиям, проведет рефакторинг и продолжит использовать разработку через тестирование. Команда прибавит минимум зависимостей, что позволит ей в дальнейшем сохранить максимум открытых вариантов.

Так XP и scrum-команды практикуют вариантное мышление в том, как они планируют свою работу и проектируют ПО. Но есть ли что-то такое, что команда может сделать, чтобы явно создавать и применять варианты в своем проекте?

Да. Когда команда практикует

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме главе 4:

  1. Введение к главе
  2. Введение к главе
  3. Введение к главе
  4. Введение к главе
  5. Введение к главе
  6. Введение к главе
  7. Введение к главе
  8. Введение к главе
  9. Введение к главе
  10. Введение к главе
  11. Главе 18
  12. Выводы по главе 1
  13. Выводы по главе 2
  14. Выводы по главе 3
  15. Выводы по главе 4
  16. Выводы по главе 5
  17. Выводы по главе 6