День 285. Agile (III)

Продолжим выдержки из книги Эндрю Стеллмана и Дженнифер Грин «Постигая Agile»:

С чего начать коучу

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

— Расспросите всех участников группы о ценностях Agile-манифеста: что они думают о них, какие считают важными, полагают ли, что эти ценности касаются всех

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

12 принципов гибкой разработки программного обеспечения

1. Наш наивысший приоритет — это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения

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

Гибкие методологии, как правило, итеративны. Agile-команды планируют итерации проекта путем выбора показателей и требований, которые обеспечивают максимальную отдачу. Единственный способ, при помощи которого команда может выяснить, какие показатели реализуют эту ценность, — сотрудничество с клиентом и встраивание обратной связи от предыдущей итерации. Это позволяет команде удовлетворить запросы потребителя в краткосрочной перспективе, демонстрируя ценность продукта на раннем этапе сотрудничества, а в долгосрочной перспективе предоставить ему готовый продукт, обладающий всеми возможными ценными качествами.

2. Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта. Agile-процессы позволяют использовать изменения для повышения конкурентоспособности продукта

Так что же такое «приветствовать изменения»? Это значит:

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

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

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

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

— Мы учимся на изменениях. Это наиболее эффективный способ командного роста и строительства лучшего ПО.

3. Мы стремимся поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае — каждые несколько месяцев. Чем чаще, тем лучше

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

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

4. Наиболее эффективный и действенный способ передачи информации — это встреча членов команды разработки ПО

Agile-практики признают, что документация — это просто одна из форм общения. Когда я пишу документ и передаю его вам, цель не в написании документации. Моя задача состоит в том, чтобы убедиться: мои мысли почти полностью соответствуют вашим.

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

5. Представители бизнеса и команда разработки должны работать над проектом вместе

Некоторые функции более значимы для компании, чем остальные. Команде нужно сбалансировать ценности (сколько стоит функция) по отношению к затратам (сколько потребуется работы для ее создания) при определении, какие из них следует включить в каждую итерацию.

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

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

7. Рабочее программное обеспечение — это главная мера прогресса проекта.

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

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

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

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

Сахаров Денис
Сахаров Денис
Был на сайте вчера в 17:59
Читателей: 17 Опыт: 784.319 Карма: 5.92687
все 18 Мои друзья