День 292. Agile (VIII). Экстремальное программирование (II)

Внесение изменений

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

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

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

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

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

Принципы ХР

Гуманизм

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

Экономика

Всегда есть тот, кто платит за разработку программного обеспечения, и каждый должен учитывать размер бюджета.

Взаимная выгода

Ищите практики, которые одновременно приносят пользу отдельному программисту, команде и клиенту.

Сходство

Месячный, недельный и дневной циклы строятся по одному шаблону.

Улучшение

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

Разнообразие

Объединяйте различные мнения и взгляды, чтобы получить наилучший результат.

Рефлексия

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

Поток

Непрерывная поставка означает постоянную доставку результатов труда разработчиков, не разделяемую на этапы.

Возможность

Каждая проблема, встающая перед командой, — это шанс узнать что-то новое о разработке программного обеспечения.

Избыточность

Хотя на первый взгляд это может показаться расточительным, избыточность позволяет избежать серьезных проблем с качеством.

Неудача

Неудачи могут многому научить. Нет ничего предосудительного в том, чтобы пробовать подходы, которые не работают.

Качество

Нельзя обеспечивать скорость поставки за счет снижения качества продукта.

Принятие ответственности

Если кто-то берет на себя ответственность, то он должен иметь полномочия для выполнения обещанного.

Маленькие шаги

Лучше делать маленькие шаги в правильном направлении, чем вносить грандиозные изменения при внедрении новых методов.

SCRUM и XP имеют сходства и различия


Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
Был на сайте сегодня в 15:47
Читателей: 21 Опыт: 920.487 Карма: 10.1215
все 22 Мои друзья