переделка[51].

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

Но разве нельзя предотвратить такие изменения? Теоретически можно. В том же учебнике по разработке программ есть ответ: документируйте требования к программному обеспечению. Если вы добросовестно собираете требования, записываете их и оцениваете вместе с заказчиками, то можете предотвратить необходимость изменений. Команда способна разработать продукт, наиболее соответствующий всем требованиям пользователей, клиентов и заинтересованных сторон. Конечно, изменения будут, но минимальные!

Однако это в теории.

Но, оказывается, это может работать и на практике. Многие команды создали достаточное количество превосходных программных продуктов, используя четкие требования[52].

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

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

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

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

Еще по теме переделка[51].:

  1. Существуют ли две экономики и две экономические науки?
  2. XXXIX Ваша «горячая девятка»
  3. Члены группы могут ухватить несколько трендов, но они погибают, когда рынок меняется на противоположный. Когда вы присоединяетесь к группе, вы действуете как ребёнок, следующий за родителями. Рынок не заботится о вашем благополучии. Успешные игроки – всегда независимые мыслители. Зачем присоединяться к толпе?
  4. Наземный контроль
  5. ЕДИНСТВЕННОЕ, ЧТО ОСТАЕТСЯ ПОСТОЯННЫМ, - ПЕРЕМЕНЫ
  6. Аудит операций по заработной плате
  7. План по управлению запасами
  8. Ситуация на фирме Ксерокс
  9. Должное прилежание: получить "яйцо с сюрпризом"
  10. Приложение 1. Домашние упражнения
  11. Разные стили менеджмента для разных типов бизнеса?
  12. Упрощенная сложность
  13. Правила самомотивации
  14. 6 Цени мгновение
  15. На дне
  16. Вспомогательная аксиома № 15. Никогда не пытайтесь спасти плохие инвестиции за счет усреднения
  17. Спекулятивная стратегия
  18. Основная аксиома № 12