Продолжим движение по процессу разработки. После того, как задача поставлена и проверена по содержанию (а поначалу - и по форме) она отправляется в бэклог проекта. Перед стартом очередного спринта совместно с заказчиком определяется его содержание. В соответствии с достигнутыми договорённостями формируется бэклог спринта.

Как я писал ранее, постановка задачи должна содержать не только сам текст задачи, но и оценку на исполнение по ролям. И первую ошибку, которую может допустить РП - это согласование содержания очередного спринта без оценки по трудозатратам. То есть он "набирает" задач на очередной период без понимания, достаточно ли временных ресурсов у команды для проведения работ. Отсюда могут расти ноги как переработок, так и простоев команды. Не делайте на проекте то, откуда растут ноги. :)

Вторая ошибка - планирование задач на весь фонд рабочего времени команды. Вот возьмём разработчика. Он тратит время на:

▫️ понимание сути очередной новой задачи и уточнение;

▫️ разработку кода по новым задачам;

▫️ исправление кода по результатам тестирования;

▫️ исправление кода по результатам показа заказчику;

▫️ накладные расходы (встречи по проекту, отчётность, тех.консультации коллег);

▫️ прочие отвлечения (перерыв на 15 минут каждые 2 часа непрерывной работы придумано неспроста и взято не с потолка).

И вот вы насогласовали новых задач на фуллтайм (то есть на первый из обозначенных пунктов). Соответственно, чтобы выполнить такой объем, разработчик обречён на переработку. Если уж вы решили назвать себя руководителем (в данном случае - РП), вы хоть изучите, как происходит рабочий процесс у ваших подчинённых, причем на уровне чуть выше, чем "разработчик разрабатывает, аналитик анализирует, а тестировщик тестирует". А лучше, прежде чем становиться руководителем, все же поработать линейным специалистом в том деле, в котором вы хотите руководить.

Третья ошибка - отсутствие функциональных границ между аналитиком и разработчиком. То есть надо заранее определить, что, например, аналитик отвечает за внешний вид, пользовательские объекты, реквизиты пользовательских объектов и бизнес-логику работы ИС и сопутствующих механизмов (функциональный слой), а разработчик - за таблицы, переменные, использование тех или иных функций или объектов ЯП или БД, индексов и т.д. (то есть системный слой).

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

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

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