Читаем Постигая Agile полностью

Agile-команды знают, как добиться того, чтобы обе стороны остались в выигрыше. Они начинают со взаимного понимания того, что команда поставляет компании ценное программное обеспечение. Готовое программное обеспечение стоит денег. Если ценность ПО превышает издержки на его создание, то компании имеет смысл инвестировать в свое развитие.

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

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

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

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

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

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

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

В то же время проекты могут разрушаться в среде, где не ценят ПО или где люди не вознаграждены по заслугам за разработку программного продукта. Нередко компании внедряют проверку производительности и систему компенсации, которые мешают командам двигаться по эффективному, гибкому пути создания ПО, а это может помешать проекту. Вот некоторые распространенные антистимулы, которые работают против agile-команд:

• программистам предоставляется недостаточно подробный анализ эффективности: при анализе кода регулярно повторяются ошибки и им присваивается статус «чистый» код (в результате программисты перестают искать ошибки в анализе кода);

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

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

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

Исчерпывающая документация и матрицы трассируемости – это особенно коварные источники проблем для командной среды и поддержки внутри команды. Вместо обстановки доверия они поощряют CYA-среду (cover your ass, что можно перевести как «каждый спасает свою шкуру»), когда команда двигается в сторону «переговоров по контракту», а не сотрудничества с клиентом.