самоорганизующаяся команда

не имеет явных требований или фаз разработки. Ее члены совместными усилиями планируют проект (вместо того чтобы полагаться на одного человека, «владельца» плана) и регулярно его пересматривают. Такие команды, как правило, разбивают проект на пользовательские истории или другие мелкие части и начинают работать с наиболее ценными для компании частями. Только после этого подходит очередь подробных требований, дизайна и архитектуры.

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

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

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

Еще по теме самоорганизующаяся команда:

  1. Самоорганизующиеся системы
  2. КОМАНДЫ КОМАНДА МЕЧТЫ И ЭФФЕКТ РЫЧАГА
  3. Динамические, самоорганизующиеся сети и сети со встречным распространением
  4. 5.1. Команда - основа успеха
  5. НАСТРОЕННАЯ КОМАНДА
  6. Искусство создания команды
  7. Группы и команды
  8. Взаимоотношения с Вдохновителями Команды
  9. Улучшение мотивации в команде
  10. НЕОБЫКНОВЕННАЯ КОМАНДА МЕЧТЫ
  11. ЧЕТВЕРТОЕ ПРОЯВЛЕНИЕ «Я ПРИТЯГИВАЮ КОМАНДУ МЕЧТЫ» ВМЕСТЕ
  12. Кто мне, команда, - становись!
  13. Почему команда необходима?
  14. ОДНОМИНУТНЫЙ ОБЗОР КОМАНД МЕЧТЫ
  15. Специальные команды поискового запроса