Сталкиваясь со скрамом, создаётся иллюзия, что проектами можно управлять играючи.
Скрам-тренера убеждают нас, что любой человек за два дня станет сертифицированным скрам-мастером, и создаётся ощущение, что он овладеет искусством управления проектами по мощной методологии скрам. На курсах, за весьма кругленькую сумму, будущий джедай весело перекидывает шарики, машет карточками с числами и, через два дня, окрылённый легкостью управления командой и проектами, а также имеющий подтверждение своей крутости в виде сертификата, готов управлять своим первым проектом по скраму.
Говорил ли скрам-тренер, что скрам — это не гарантия успеха?
Спустя время, неся ношу похороненных проектов и потерянных бойцов, молодой джедай всё больше постигает неизведанные миры. Постигает то, на чём скрам-тренер не акцентировал внимание, а именно:
- пользовательские истории — это часть чего-то большого. И это большое, до начала реализации проекта, желательно представлять всем членам команды, к числу которых относится и заказчик. Не представляя всю картину в целом, архитектор не сможет построить грамотную архитектуру приложения. Отсутствие грамотной архитектуры приводит к проектам:
- с возрастающей стоимостью реализациии каждого последующего требования, поскольку нет очевидных связей различных частей приложения;
- с бесконечным рефакторингом, как попытка упорядочивания исходного кода и удаления критичных костылей;
- с бесконечным багфиксингом, как результат хаотично созданных костылей.
Все эти последствия отсутствия архитектуры увеличивают время реализации проекта и его стоимость.
Последовательное выполнение пользовательских историй не приведёт к созданию продуманной архитектуры проекта.
- готовность команды быстро и легко вносить изменения в существующий код на каждой итерации сопровождается необходимостью пересматривать архитектуру приложения и делать рефакторинг предыдущего кода для избежания накапливания технического долга. Игнорирование технического долга сродни игнорированию банковского долга. Чем раньше начать его выплачивать, тем меньше пеня. Бесконтрольное увеличение технического долга легко становится причиной прекращения разработки проекта.
Изменчивость требований проекта увеличивает технический долг, убивающий проект.
- изменения кода могут поломать существующую логику работы приложения и внести дефекты. Раннее обнаружение дефектов уменьшает стоимость их устранения. А для этого необходимо наличие юнит-тестирования и интеграционного сервера. Другими словами, процесс создания новой фичи также включает создание новых тестов и изменения уже существующих.
Тестирование, как часть разработки, позволяет создать качественный продукт.
- скорость команды (velocity) зависит не только от опыта сотрудников, а также от жизненного цикла команды. Более того, скорость работы одного и того же сотрудника разная в разных командах. Поэтому учитывая и уделяя время:
- мотивации команды в целом и каждого её члена в отдельности, описанной Маслоу;
- командной динамике, описанной Такманом
можно в разы повысить скорость работы команды.
Скорость работы команды увеличивается при выращивании команды.
- иногда поставленные задачи могут не выполняться сотрудником или выполняться не должным образом. Это происходит по одной из трёх НЕ:
- не может — отсутствия условий, при которых задача могла быть реализована как ожидалось;
- не хочет — потеря мотивации, краткосрочная или долгосрочная;
- не умеет — нет необходимых знаний и квалификации.
Любое невыполнение задачи отражается на скорости работы всей команды и её настроении, поэтому надо постоянно отслеживать и устранять причины перечисленных НЕ.
Скорость работы команды увеличивается при устранении препятствий
- не все проекты могут быть реализованы, используя методологию скрам. Есть целые области, в которых успешный проект, разработанный по методологии скрам, скорее случайность, чем практика. Более того, в зависимости от нужд проекта, на разных этапах развития проекта, скрам может не являться лучшим выбором. Именно поэтому кроме скрама есть ещё много других подходов к разработке проекта, которые нужно знать. Владея различными подходами, можно их комбинировать, выбирая те их аспекты, которые более вероятно приведут проект к успеху.
Сколько раз слово СКРАМ ни повторяй, за проект отвечаете вы.
Столкнувшись с вышеперечисленными моментами разработки проекта, уже опытный джедай понимает, что скрам — одна из многих методологий, получившая известность благодаря её коммерциализации и лёгкости освоения. Много лет назад он попался на удочку рекламы, подчёркивающей плюсы скрама и скромно умалчивающей о всех составляющих разработки проекта с момента его инициации и до закрытия. За понимание этого факта ему пришлось заплатить бесчисленным количеством нервных клеток, бессонными ночами и, как это ни прискорбно, проваленными проектами.
