Чистый Agile. Основы гибкости

Методы Agile, а именно «игра в планирование» и «одна команда», помогут провести оценку запланированных задач.

Умение говорить «нет»

Хотя и очень важно стремиться найти решение задачи, лучше сказать «нет», если такого решения не найдено. Просто осознайте, что вас взяли на работу даже не потому, что вы хорошо пишете код, а потому что вы можете сказать «нет», когда это нужно. Вы, программисты, — как раз те, кто знает, что возможно, а что нет. Как технический директор я ожидаю от вас сведений, дабы не упасть в пропасть. Я рассчитываю на это независимо от того, поджимают ли сроки, независимо от того, что желают услышать менеджеры. Просто ответьте «нет», когда это действительно нужно.

Метод Agile «одна команда» научит честно говорить «нет», если того требует положение дел.

Тяжело в учении, легко в бою

Как технический директор я ожидаю от вас стремления постоянно учиться. В нашей сфере все быстро меняется. И мы должны быть способны меняться вместе с ней. Так что век живи — век учись! Иногда компания сможет себе позволить отправить сотрудника на курсы или конференции. А иногда — закупить обучающую литературу и видеоуроки. Но даже если этого всего не будет, нужно искать возможность учиться самому, не дожидаясь помощи дяди из вашей компании.

Метод Agile «одна команда» поможет достичь новых вершин в обучении.

Мудрый коуч

Как технический директор я ожидаю от вас и ваших коллег взаимного обучения. Правда в том, что лучше всего мы учимся тогда, когда сами кого-то учим. Поэтому когда в команду приходят новички, не стесняйтесь их учить чему-то. Учитесь помогать друг другу. И снова на помощь приходит метод Agile «одна команда», который научит вас друг друга поддерживать.

Билль о правах

Во время встречи в Сноуберде Кент Бек заявил, что цель Agile — построить мост над пропастью, существующей между клиентами и разработчиками. Для этого Кент Бек, Уорд Каннингем, Рон Джеффрис и некоторые другие составили «Билль о правах».

Обратите внимание на то, что права клиентов и права разработчиков дополняют друг друга. Они подходят друг к другу, словно шестерни одного механизма. Благодаря им существует некий баланс ожиданий между одними и другими.

Права клиента

У клиента есть следующие права:

• Ознакомиться с общим планом, знать, что и когда можно получить и за какие деньги.

• Получать наилучшую, насколько это возможно, отдачу от каждой итерации.

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

• Изменять решения, функциональность и приоритеты, не неся непомерных расходов.

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

Права разработчика

У разработчика есть следующие права:

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

• Выполнять работу качественно, несмотря ни на какие обстоятельства.

• Получать помощь от коллег, руководителей и самих клиентов.

• Проводить оценку задачи и уточнять ее в зависимости от обстоятельств.

• Брать на себя личную ответственность и не позволять возлагать на себя лишнее.

Все эти утверждения звучат весьма громко. Давайте рассмотрим их по очереди.

Клиенты

В данном контексте слово «клиент» относится к представителям бизнеса. Сюда относятся непосредственно клиенты, менеджеры, начальники, менеджеры проекта и им подобные, то есть все, кто способен нести ответственность за соблюдение сроков и расходование средств, либо те, кто платит деньги и получает выгоду от использования программы.

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

Многие утверждают, что такое предварительное планирование не является частью методологии Agile. Самое первое из прав клиента уже опровергает это высказывание. Безусловно, в бизнесе требуется планирование. И, конечно, в план должны входить график работ и их стоимость. Разумеется, план должен быть как можно более точным и осуществимым.

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