Принципы общения в agile-команде

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

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

Разработка продукта вместе с клиентом

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

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

Да, можно ждать окончания проекта, когда станут видны результаты работы команды, и уже тогда дать обратную связь. Но внесение правок на этом этапе стоит гораздо дороже. Каждый из участников проекта сэкономит немало времени, если отследит изменения как можно раньше. Ежедневная командная работа на протяжении всего проекта в конечном счете экономит личное время каждого из его участников, в том числе и заказчика!

Понимание ценности работы

Мотивация в Agile — это не только деньги. Здесь каждый член команды знает, что создает значимый, важный продукт. Каждый замотивирован принести пользу компании заказчика. Есть антистимулы, которые применяются в традиционных компаниях и от которых предостерегают авторы книги:

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

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

Только для читателей Cossa— скидка 30% на электронную книгу «Постигая Agile». Промокод: 2607mif. Действует до завтра, 27 июля, 23:59 (мск).

О других принципах создания идеальной команды читайте в книге «Постигая Agile».