День 109. Agile (I)

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

Материалов про Agile у меня было довольно много, но в основном в голове (+ еще 4 презентации, две из которых так и не провел на бывшей работе). К сожалению, пока ни одного поста, затрагивающего эту тему, не было (поскольку не было связанных событий и я уже давно не читал ничего на эту тему).

Сейчас хочу, чтобы какая-то информация сохранилась в блоге. Возможно, кому-то будет интересно.

Писать буду по мотивам этой книги:

Начнем с эпиграфа:                                                                       Будь гибким, чтобы не сломаться

Зачем это нужно?

— гибкая разработка позволяет доносить до заказчика максимум ценности за определенный период

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

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

— гибкая разработка позволяет анализировать результаты работы и организации процесса, вносить в него изменения и совершенствовать команду

 

К чему приходят гибкие команды?

— создают качественное ПО

— успешно работают вместе в атмосфере доверия и взаимовыручки

— удовлетворяют запросы своих пользователей

— добиваются этого в спокойной атмосфере без переработок

 

С чего начнем?

— гибкая разработка начинается не с формальных процедур, а с изменения образа мысли команды

— необходимо принять необходимость и готовность совершенствоваться

— коллективное владение информацией и открытые обсуждения

 

Немного истории

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

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

В чем недостаток такого подхода? Небольшие ошибки, совершенные на ранних стадиях, накапливаются и становятся большими проблемами — например, 1 час, не потраченный на стадии анализа, может вылиться в лишнюю 1000 часов разработки.

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

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

Задумавшись о решении этих проблем, группа новаторов составила Manifesto for Agile Software
Development, провозгласивший основные ценности гибкой разработки:

1. Люди и взаимодействие важнее процессов и инструментов

2. Работающий программный продукт важнее исчерпывающей документации

3. Сотрудничество с заказчиком важнее согласования условий контракта

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

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

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

Сахаров Денис
Сахаров Денис
сейчас на сайте
Читателей: 21 Опыт: 786.781 Карма: 6.74063
все 22 Мои друзья