Найти в Дзене
Ирина Пименова

Курс: Agile и Scrum в работе над проектами и продуктами. Часть 2

Оглавление

Рубрика: Конспекты

Источник: Coursera

AGILE МАНИФЕСТ: 4 ЦЕННОСТИ, 12 ПРИНЦИПОВ

ЦЕННОСТИ

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

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

Поставка продукта пользователям важнее написания документации.
Если какая-либо документация действительно необходима ДЛЯ ПРОДУКТА или его создания, ее стоит создать.
Главное - работающий продукт, удовлетворенные заказчики и пользователи.

Артефакты – всё, что делает процессы и продукты приятными для участников и других людей. Например, это диаграммы, доски, списки, требования, дизайн продукта и сам продукт.

Для меня это про то, что действия и результат важнее, чем средства его достижения. Доски, стикеры и разговоры о том, как круто идет ПРОЦЕСС не имеют смысла, если нет результата, нужного вам или заказчику.

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

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

4. Реакция на изменения важнее следования плану

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

ПРИНЦИПЫ (описывают взаимодействия между людьми и процессами):

1. НАИВЫСШИМ ПРИОРИТЕТОМ для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного продукта.

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

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

Изменения неизбежны.

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

Для сбора обратной связи с заказчика или пользователей.

Не обязательно каждый выпуск должен быть доступен конечному пользователю.

Синергия. Только всё вместе работает.

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

Разработчики и заказчик должны быть на связи, чтобы синхронизировать связанные с проектом потребности бизнеса/пользователей. Не рекомендуется писать требования на весь проект сразу. Их нужно выяснять и писать по мере продвижения проекта и с учетом изменений.

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

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

6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

Мы обязаны обмениваться информацией быстро. Самый быстрый и эффективный способ -- делать это лично.

7. Работающий продукт - основной показатель прогресса (команды).

Объем выполненной работы является важной метрикой прогресса. Продуктовые метрики (средний чек, конверсия) к прогрессу команды отношения не имеют.

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

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

9. Постоянное внимание к техническому совершенству и качество проектирования повышает гибкость проекта.

10. Простота -- искусство минимизации лишней работы -- крайне необходима.

Keep it simple stupid. Kiss

Не делайте универсальный продукт!

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

О самоорганизующихся командах и организациях я буду писать отдельно!

Не во всех Agile подходах есть самоорганизующиеся команды.

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Ретроспектива. Время. Самосовершенствование.

Где почитать подробнее: agilemanifesto.org