Права клиента
У клиента есть следующие права:
• Ознакомиться с общим планом, знать, что и когда можно получить и за какие деньги.
• Получать наилучшую, насколько это возможно, отдачу от каждой итерации.
• Отслеживать ход работ, назначать необходимые тесты, получить рабочее и многократно протестированное программное обеспечение.
• Изменять решения, функциональность и приоритеты, не неся непомерных расходов.
• Получать сведения о графике работ, изменениях сроков, чтобы вовремя принять решение о том, как сократить объем работ и успеть к нужному числу. Отменить проект в любое время и получить полезный рабочий код, который оправдывает текущие вложения средств.
Права разработчика
У разработчика есть следующие права:
• Знать, что требуется от команды, а также иметь четкое представление о поставленных приоритетах.
• Выполнять работу качественно, несмотря ни на какие обстоятельства.
• Получать помощь от коллег, руководителей и самих клиентов.
• Проводить оценку задачи и уточнять ее в зависимости от обстоятельств.
• Брать на себя личную ответственность и не позволять возлагать на себя лишнее.
Все эти утверждения звучат весьма громко. Давайте рассмотрим их по очереди.
Клиенты
В данном контексте слово «клиент» относится к представителям бизнеса. Сюда относятся непосредственно клиенты, менеджеры, начальники, менеджеры проекта и им подобные, то есть все, кто способен нести ответственность за соблюдение сроков и расходование средств, либо те, кто платит деньги и получает выгоду от использования программы.
Клиенты могут потребовать предоставить им общий план на ознакомление, также имеют право знать, что и когда можно получить и за какие деньги.
Многие утверждают, что такое предварительное планирование не является частью методологии Agile. Самое первое из прав клиента уже опровергает это высказывание. Безусловно, в бизнесе требуется планирование. И, конечно, в план должны входить график работ и их стоимость. Разумеется, план должен быть как можно более точным и осуществимым.
Именно на последнем пункте мы часто не знаем, что делать, так как единственный способ построить точный и выполнимый план можно только в процессе выполнения проекта. Невозможно, почти ничего не делая, создать нормальный план. Так что мы, разработчики, должны убедиться, что наши планы, оценки и графики работ правильно создают представление об уровне нашей неопределенности, и найти способы снизить этот уровень, чтобы гарантировать это право.
Проще говоря, нельзя соглашаться с невозможностью изменить объем и сроки работ. И объем работ, и сроки должны быть гибкими. Мы представляем такую гибкость с помощью кривой вероятностей. Например, согласно нашей оценке, вероятность того, что мы выполним первые десять историй к назначенному числу — 95 %. С вероятностью 50 % мы выполним вовремя следующие пять. И с вероятностью 5 % мы выполним еще пять историй в требуемый срок.
У клиентов есть право ознакомиться с этим планом, основанным на вероятности, потому что они не могут вести дела без плана.
Клиенты имеют право получать наилучшую, насколько это возможно, отдачу от каждой итерации.
Agile позволяет разбить объем работ на временные отрезки, называемые итерациями. Клиенты имеют право ожидать от разработчиков работы над наиболее важными задачами в любое время, а от каждой итерации — максимально возможную пользу для бизнеса. Приоритеты устанавливаются клиентами на этапе планирования в начале каждой итерации. Клиенты выбирают истории, которые приносят наибольшую отдачу от капиталовложений и которые команда разработчиков может, по ее оценкам, выполнить за итерацию.
Клиенты имеют право на отслеживание хода работ, назначение необходимых тестов, получение рабочего и многократно протестированного программного обеспечения.
Это право кажется очевидным с точки зрения клиента. Конечно, у них есть право отслеживать, как продвигается ход работ. Безусловно, у них есть право определять показатели того, что работа действительно продвигается. Несомненно, у них есть право незамедлительно и неоднократно проверять, действительно ли ход работ соответствует требуемым показателям.
Клиенты имеют право на изменения решений, функциональность и приоритеты, не неся при этом непомерных расходов.
В конце концов, мы говорим об отрасли разработки программного обеспечения. Цель программного обеспечения — легко изменять функциональность техники, которую мы используем. Первым делом ПО изобрели затем, чтобы функциональности придать гибкость. Поэтому, конечно же, у клиентов есть право на изменение своих требований.
Читать дальше
Конец ознакомительного отрывка
Купить книгу