Книги
Постигая Agile
Agile-команды знают, как добиться того, чтобы обе стороны остались в выигрыше. Они начинают со взаимного понимания того, что команда поставляет компании ценное программное обеспечение. Готовое программное обеспечение стоит денег. Если ценность ПО превышает издержки на его создание, то компании имеет смысл инвестировать в свое развитие.
Хороший проект должен быть достаточно ценным, чтобы предприниматели убедились: затраченные усилия необходимы для дальнейшего хода проекта.
Когда бизнесмены и разработчики трудятся над созданием ПО как одна команда, в долгосрочной перспективе наиболее эффективно ежедневное сотрудничество на протяжении всего проекта. Альтернатива – это ждать окончания проекта, когда станут видны результаты работы команды, и дать обратную связь. Но внесение изменений на этом этапе стоит гораздо дороже. Каждый из участников проекта сэкономит немало времени, если отследит изменения как можно раньше. Ежедневная командная работа на протяжении всего проекта экономит личное время каждого из его участников.
Именно поэтому команды, поставляющие рабочее программное обеспечение, должны отдавать приоритет наиболее значимым функциям – чтобы предприниматели могли как можно раньше получать ценное ПО. Эта часть сделки и объясняет, почему хорошие agile-команды считают предпринимателей частью команды наравне с программистами. В этом различие между гибкой и традиционной командами.
Традиционная команда рассматривает бизнес-пользователей как сторону, с которой нужно договариваться. Agile-команда сотрудничает с клиентом (как правило, это владелец продукта) как с равным в выборе пути осуществления проекта. (Вспомните одну из основных agile-ценностей, гласящую, что сотрудничество с клиентом главнее переговоров по контрактам!)
Хороший владелец продукта поможет уменьшить количество времени, которое бизнесмены проводят с командой. Им все равно придется встречаться ежедневно, но владелец продукта сосредоточит свое внимание на понимании ценности программного обеспечения и бизнес-задачи, которую нужно решить. Таким образом, команда будет использовать личную встречу с предпринимателями для проверки информации, которую она уже узнала от владельца продукта.
Проекты работают лучше, когда каждый в компании признает, что команда создает значимое программное обеспечение, и ее члены, в том числе владелец продукта, понимают, что придает продукту значимость и делает его ценным для компании.
В то же время проекты могут разрушаться в среде, где не ценят ПО или где люди не вознаграждены по заслугам за разработку программного продукта. Нередко компании внедряют проверку производительности и систему компенсации, которые мешают командам двигаться по эффективному, гибкому пути создания ПО, а это может помешать проекту. Вот некоторые распространенные антистимулы, которые работают против agile-команд:
• программистам предоставляется недостаточно подробный анализ эффективности: при анализе кода регулярно повторяются ошибки и им присваивается статус «чистый» код (в результате программисты перестают искать ошибки в анализе кода);
• тестировщиков награждают за количество ошибок, которые они обнаруживают (тем самым поощряются придирки и плохая отчетность, а также нарушается сотрудничество с программистами, потому что это создает антагонистические отношения между ними);
• оценки эффективности бизнес-аналитиков базируются на количестве производимой документации (а не объеме знаний, которыми они поделились с командой).
Производительность каждого специалиста должна основываться на достижениях команды, а не на тех ролях, которые они играют в проекте. Это не означает, что программист, который плохо выполняет свои обязанности или отрицательно влияет на команду, не должен отвечать за это перед руководителем. Людей нужно оценивать по их вкладу в достижение общих целей команды. Но их
Исчерпывающая документация и матрицы трассируемости – это особенно коварные источники проблем для командной среды и поддержки внутри команды. Вместо обстановки доверия они поощряют CYA-среду (cover your ass, что можно перевести как «каждый спасает свою шкуру»), когда команда двигается в сторону «переговоров по контракту», а не сотрудничества с клиентом.
Тестировщики в CYA-среде прежде всего стремятся убедиться в том, что каждое условие протестировано, а не в улучшении качества ПО. Разработчики соблюдают требования буквально, не затрудняя себя мыслями о том, действительно ли они создают ценный для клиента продукт. Потому что иначе, работая в CYA-среде и пытаясь сделать то, что нужно клиенту, они рискуют получить выволочку за то, что не следуют спецификации. Бизнес-аналитики и владельцы продукта в CYA-среде заботятся прежде всего о том, чтобы сфера охвата пользователей и требования выстраивались в идеальную линию. Поэтому они нередко пренебрегают докучными требованиями, которые не вполне совпадают с существующей документацией, независимо от их значимости.
Члены команды программного обеспечения должны бороться каждый за себя там, где негативно относятся к изменениям. Команде, которая использует исчерпывающую документацию, легко понять, что изменения – это плохо: они требуют слишком много работы, чтобы пересмотреть область охвата, обновить спецификации, изменить дизайн, произвести ремонт матрицы трассируемости и т. д. Это приводит к расколу среды, потому что менеджеры в такой компании обычно пытаются найти «виноватого», на которого можно возложить ответственность за все дополнительные работы, вызванные изменениями. Члены команды все чаще обращаются к «оборонительной документации», чтобы защитить себя от незаслуженных обвинений. Это заставляет их применять принцип «каждый за себя»: чтобы избежать критики и наказания, они ссылаются на документацию, которой придерживались.
Альтернатива CYA-среде – доверие. Компания, разрабатывающая только документацию, необходимую для проекта, создает среду, в которой команде доверено делать именно то, что надо, когда происходят изменения. В agile-команде с отношением «мы все вместе» в случае провала проекта все разделяют вину и никто не «прикрывает свой зад». Им проще внедрять изменения, потому что не нужно придерживаться всей этой ненужной документации. Вместо этого они могут работать лицом к лицу, решать реальные проблемы и записывать только необходимое. И они могут делать это, зная, что компания верит, что они сделают все правильно – даже если проект займет больше времени.
Наш проект «Электронная книга» определенно выиграл от улучшения коммуникации. Помните интенсивные встречи, на которых бизнес-аналитики совместными усилиями тщательно выводят обширный список исчерпывающих требований? Эти требования начинались вовсе не как циничная CYA-схема. Каждый в команде искренне полагал, что если он будет последовательно отстаивать свою точку зрения по поводу полноты спецификации, то это поможет создать более успешный продукт.
Из-за того, что они потратили массу времени, чтобы в перспективе получить результат, они держали оружие наготове и защищали оригинальную спецификацию, даже когда оказалось, что конечный продукт нежизнеспособен. И если бы можно было предсказать, в чем будет нуждаться рынок через два года, то все бы превосходно сработало! Очень жаль, что не получилось, но по крайней мере никто не потерял работу, потому что можно было сослаться на в точности реализованную спецификацию.
Что было бы, если бы сразу применялась более эффективная коммуникация? Как бы изменился продукт, если бы вместо развернутых требований команда с самого начала написала минимальное количество документов, необходимых для работы?