Лайфхаки из жизни одной agile-команды

 
 
 
 
 
 
 
 
 
 
 

16 октября 2019 года в офисе компании Andersen (Минск) состоялся митап Lesson Learned, организованный двумя сообществом analyst.by и agile.

За экспертным столом «Проекты с нуля» поделился своим опытом ВА lead из компании Elinext Арсений Шилов. Он предложил свои палочки-выручалочки, помогающие на первых стадиях agile-проекта.

1. В первую очередь, понять и представить для себя весь проект на высоком уровне, выделить один или несколько основных бизнес-процессов и уместить это всё на одном небольшом листике или доске.

Такое краткое описание полного бизнес-процесса на высоком уровне поможет следующим:

• Выделить главное и впоследствии не отвлекаться на второстепенное.
• Определить основные функциональные блоки и составить начальный product feature backlog;
• Учесть все необходимые роли пользователей и других заинтересованных участников
• Быстро передавать знания о проекте всем его участникам и иметь единую для всех «картину мира»

 

 

 

 

 

 

 

 

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

 

Для описания можно использовать любую походящую нотацию бизнес-процессов, а также полезно дополнить его контекстной диаграммой.

 

 2. Применять Принцип Бережливого производства Lean:

• Остановить работу над ‘мусором’ (‘мусор’ – это любая активность для достижения результата, не требующегося уже сегодня или завтра).
• Перед выполнением любой новой задачи сверять/обновлять текущие приоритеты
• Выдерживать приоритеты – не отвлекаться на ‘мусорные’ задачи и не делать больше, чем достаточно для движения вперед

 

 

 

 

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

В тупиковых ситуациях, когда разработка буксует и не набирает ход, когда «Вроде бы всё описано, но непонятно, что же делать дальше?», использование Lean помогает определить действительно верный следующий шаг и сдвинуться с мертвой точки.

 

3. Качественно формулировать, делегировать и принимать к исполнению цели и задачи:

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

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

 

 

 

 

Одним из наиболее известных и действенных методов целеполагания является SMART с его пятью критериями постановки задачи: (S – Specific) конкретная и четко понятная, (M – Measurable) — измеримая, (A – Achievable) — достижимая и исполнимая, (R – Related) явно согласующаяся с вышестоящей целью, (T – Timebound) четко ограничена по времени.

Если какой-либо из этих критериев неясен, то дальнейшая работа над этой задачей с высокой вероятностью окажется ‘мусорной’.

 

4. Понимать условия и особенности проекта, отделяя несовместимые сущности друг от друга:

• Контрактная модель: Fix Price или Time and material.

 

 

 

 

 

 

• Методология управления проектом: Scrum, Kanban, Waterfall, RUP и т.д.
• Структура команды и распределение ответственности («У кого узнать это?»)
• Список всех необходимых ролей в проектной команде (при этом один человек может выполнять несколько ролей, например PM и BA, Dev и QA, TechLead и DevOps, и т.д.)

 

5. Ограничивать глубину детализации требований до минимально необходимой. Главное, чтобы:

• Заказчик подтвердил – да, это то, что он хочет получить в ближайшей перспективе
• Техническая команда подтвердила – да, им этого достаточно для начала или продолжения работы.

 

 

 

 

 

 

 

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

 

6. Если заказчик настаивает на контрактной модели Fix Price, то проверяйте это желание на реалистичность:

• Есть ли утверждённая спецификация, которую команда разработки сочтет достаточной для всего проекта? Если нет, тогда скоуп не может быт зафиксирован, и тогда фиксация цены на него –фикция и самообман.
• Если проект превышает 5-6 чел./месяцев, значит, вероятность последующих изменений требований весьма высока.
• Готов ли клиент оплачивать закладываемые командой в оценку риски, если они не наступят? Понимает ли клиент, что при необходимости внести изменения в предыдущий скоуп и цена могут измениться?

 

7. Прочие палочки-выручалочки:

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

 

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

 
Автор: Александр Малахов