Продолжаем про разработку на этапе 2 “Разработка и настройка”. В этом посте поговорим о проверке сформулированной задачи на соответствие рамкам и детализированным требованиям.

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

Этот подход грозит следующими негативными моментами:

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

- излишняя функциональность. Тут могут быть разные причины - от “что-то пропустили при детализации требований на предыдущем этапе” до “подумалось, что лучше дополнительно сделать вот это”. Но дело в том, что какими бы ни были причины появления дополнительной функциональности, работа на ними несёт дополнительные затраты. В любом случае прежде чем запускать “допник” в работу, нужно понять, а откуда взять на это ресурсы и исполнителей. Может действительно дополнительная функциональность принесет заказчику ощутимые плюсы, ну так почему бы предварительно не согласовать это дело с ФА и РП?

- логические несостыковки с имеющейся или планируемой к разработке функциональностью. Дело в том, что ФА обладает (ну точнее - должен) целостным представлением о функциональной архитектуре проекта, а аналитик работает на определенном участке. И может так статься, что, например, постановка для функциональности на стыке 2 процессов будет учитывать потребности только одного из процессов.

Я не говорю о банальных ошибках. Все мы - люди-человеки и можем ошибаться (более того, ошибаемся). Однако при правильном построении процесса работы, многие ошибки (банальные и не очень) можно отсечь элементарной проверкой со стороны ФА.

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

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

Также в случае, если у аналитика появилась инициатива, не стоит ее отметать сразу. Бывает так, что в процессе работы появляются мысли, как сделать функциональность более универсальной, но с возможностью использовать ее в нескольких процессах. А это может оказаться в итоге и менее трудозатратным, и более элегантным решением, чем представлялось на этапе обследования и анализа (у меня на практике такое было). Но ещё раз повторю, сначала это должно быть согласовано с ФА и РП.

Соответственно, далее задача либо направляется в разработку (строго говоря: бэклог проекта -> бэклог спринта -> разработчик, но об этом в следующем посте), либо возвращается аналитику на доработку.

Полностью цепочка этапов разработки - здесь. Полный перечень результатов по этапам проекта - здесь.