Некоторые мысли о Scrum

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

Суть вопроса — в деньгах, ведь любой проект — это деньги. Затраты на разработку проекта — это деньги, прибыль от реализации проекта — это деньги, даже время разработки проекта и создание [кодирование] приложения — это тоже деньги. Вопрос выбора технологии процесса разработки и сопровождения программного продукта — вопрос личности, которая управляет [распоряжается] этими деньгами. Если при «обычном» подходе — это менеджер проекта, в Scrum — это, возможно, сам заказчик.

Стоимость каждой итерации проекта, при этом, достаточно просто посчитать. Это сумма оплаты трудодня пяти — девяти программистов, умноженная на продолжительность спринта, плюс ставка их «коуча». Эта сумма является естественным ограничением размера аванса группе разработчиков. Она, же — минимальный размер потерь, при ошибке планирования.

Продолжительность итерации проекта — спринт — максимальный период, в течение которого группа программистов «уходит в себя» и заказчик не имеет никакой другой [кроме случаев остановки спринта] информации о ходе разработки, кроме как, что все идет «хорошо». По окончании спринта, предполагается, что он получит все те «фичи», которые были запланированы на старте спринта.

Методологически, Scrum часто сопряжен с XP и его подходом TDD. Таким образом, набор требований к программному обеспечению преобразуется в набор программных тестов, определяющих правила его взаимодействия с пользователем. Это не инструкция пользователя и не схемы бизнес-процессов, а набор критериев, естественным образом, позволяющих оценить достижение результата разработки. Следовательно, нацеленность на результат при постановке задач лежит в основе самой методики.

Вышеуказанные преимущества обусловлены и проистекают из идей, лежащих в основе Scrum, которые, в различных вариациях представляют следующий набор:

1. Люди и их взаимодействие важнее, чем процессы и инструменты
2. Рабочее ПО важнее, чем документация
3. Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
4. Готовность к внесению изменений важнее, чем первоначальный план

При изучении его преимуществ, может показаться, что Scrum — это «панацея», но, на самом деле, это — всего лишь метод и выбор его применения для разработки в текущих условиях должен быть обоснован. Давайте попробуем представить, где и в каких случаях этот метод может нас «подвести».

Используя этот подход, мы никогда не сможем точно сказать, во сколько нам обойдется весь проект целиком. Мы, также, не сможем сказать, когда он закончится. И, в итоге, какой набор функций [границы проекта] будет реализовано. Это ни плохо и ни хорошо. Это ограничение в применимости методологии. Если заказчик согласен терпеть эту неопределенность в силу некоторых причин, применять Scrum можно. Если же он постоянно думает о границах проекта и задает конкретные вопросы, тогда, скорее всего, нельзя.

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

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

Отдельно требует упоминания выбор архитектуры проекта и обусловленные с этим технические риски. Предполагается, что выбранная архитектура должна поддерживать и удовлетворять всем возникающим в ходе разработки продукта, требованиям. Если же нет, в какой то момент времени, владелец продукта может оказаться перед выбором — отказаться от нового требования или выбрасывать продукт и начинать новый проект.

Если говорить о состоянии кода — то, экстремальное программирование оставляет после себя мало-связные и плохо читаемые не задокументированные куски кода, написанного разными программистами. И хотя, разработчики Scrum, вроде как, обещают сделать «рефакторинг» кода, когда относительно функциональности продукта появится больше определенности, все эти обещания так и останутся обещаниями, ведь ими уже управляет backlog. И если в RUP прямо говорится, что прототип должен быть «выброшен» — в Scrum, напротив — он должен быть «продан» клиенту.

Отдельно стоит упомянуть такие вещи, как реинжениринг процессов и концепция проекта. Реинжениринг процессов — тоже, достаточно модная, в свое время, вещь и использовался преимущественно там, где компания принимала решение не работать так, как раньше. Связано это было, чаще всего, с так называемым, кризисом роста компании, когда бизнес-процессы, стихийно сложившиеся в начале работы компании, на каком-то этапе, начинали давать сбои или просто переставали работать. Либо приводили к таким расходам, что ставили под сомнение возможность дальнейшего существования компании. Так вот, для реинжениринга компании требуется взгляд профильного специалиста со стороны. Люди, которые ежедневно «варятся» во всем этом, как правило, тут ничего не могут сделать. В результате, рождается идея, концепция, как сделать лучше. И, чтобы в ходе проекта эта концепция не «развалилась», нужно ее не только оформить в ограниченном, завершенном виде, но и удерживать от разрушающих ее дополнений — а это прямой путь к каскадной разработке.

Теперь, возможно, мы подошли к тому, чтобы понять, где хорошо применим Scrum, где он не подведет.

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

Также, сюда могут входить случаи, когда найм квалифицированного персонала для решения задачи, по тем или иным причинам, составляет проблему. Это выглядит, как парная работа программиста и специалиста-предметника. Проект, если его так можно назвать, движется итерационно. Результат работы программиста измеряется степенью удовлетворенности специалиста-предметника, а специалист-предметник, он же, возможно, владелец бизнеса, принимает на себя всю ответственность и в ходе работы, либо решает свою задачу, либо не решает. Практически, так работают все 1С-франчайзи. В какой-то момент, возможно, принимается решение по смене подрядчика или привлечении грамотного фрилансера или о найме [группы] опытных программистов в штат, которое [решение], отчасти может являться следствием и изменения руководством подходов к разработке программного обеспечения также.

Вам понравиться

Добавить комментарий