Работа в IT, разработка программного обеспечения: Scrum framework
Почитав комментарии к предыдущей статье, стало понятно, что в основном общественность против негативного отношения в методологии разработки по названием SCRUM, в быту чаще называемой СРАМ. Давайте попробуем разобраться, что же именно так задевает людей, и почему на любую критику данного подхода большинство кидаются как бык на красную тряпку (именно большинство, конечно-же не все). Предыдущая часть: Работа в IT, разработка программного обеспечения: за и против
Начнем с определения. Вынужден дать его в оригинале, чтобы никто не говорил, что я все переврал.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
A Product Owner orders the work for a complex problem into a Product Backlog.
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Переведу вольно но близко к тексту:
Scrum это набор простых правил и ограничений помогающим людям, командам и организациям создавать ценность (для пользователя) через адаптивные решения для сложных проблем.
Кратко, Scrum требует скраммастера для построения окружения где:
Скрам это просто. Попробуйте следовать ему и определите является ли это философией и структурой позволяющей достигать поставленные цели и создавать ценность. Скрам фреймворк намеренно неполон, только определяет части, которые нужно разработать. Скрам базируется на коллективном разуме людей которые используют его. Скрам не дает подробных инмтрукций, правила Скрама определяют отношения и взаимодействия.
Не правда ли очаровательно? Вы должны взять методологию, простую как три копейки и следовать простым правилам, после этого можете не сомневаться — все получится. Хмм… нужен скрам-мастер — не беда, вокруг этого всего навыростал миллион компаний, которые помогут, сдадут в аренду хорошего скрам-мастера, который выстроит процесс в Вашей компании. Он ничего не знает о продукте? Он и не должен! В этом весь смысл.
Кроме того, читая этот текст в первый раз, меня не оставляло паскудное ощущение… данный текст по построению весьма похож на саентологические(как впрочем и любой сектантский) тексты, Вам с первых строк говорят делай так и будет тебе счастье. Если кто не верит, просмотрите в первоисточнике.
И на всякий случай повторю, оригинальный текст взят без изменений из свежего Scrum Guide. На тренингах Вам первым делом покажут бездоказательные цифры о количестве компаний, которые выбрали скрам и вознеслись и рядом будет другие, пугающие цифры о компаниях, упорствующих в своей темноте и которые либо уже пали либо скоро падут в бездну.
Проблемы-проблемки
Полезная функциональность
В скраме и подобных методиках Вы должны верить (и следовать) простому постулату
В конце каждого спринта пользователь должен получить прирост видимого функционала. Именно видимого, новую форму, минимум кнопку на форме, но это должно быть полезно и заметно.
Таким образом основатели секты на самом деле врут, существует огромное (подавляющее) количество проектов, при работе над которым скрам не применим. Например строительство самолета, со скрамом Вы должны за спринт построить дельтоплан и передать пользователю, потом добавить мотор в следующем спринте, потом возможно колеса и сиденье в еще одном спринте, а потом разработать самолетное крыло… стоп, крыло не полетит без фезюляжа, а сделать за спринт еще и фезюляж команда не успеет.
Вовлеченность заказчика
В скраме предполагается обязательным вовлечение заказчика на протяжении всей разработки продукта (помните пункт 4 — неопределенно долго), в жизни конечно заказчик обычно не готов выделять целого человека на это, либо выделенный человек видал все эти пляски в гробу.
Оценка задач
Скрам как методика не допускает неоцениваемых задач. Таким образом, если команда не может оценить задачу, то этой задачи не существует. Конечно срам-мастера сейчас начнут бесноваться и кричать — декомпозировать ее, декомпозировать! Но к сожалению тут все еще сложнее, декомпозиция как процесс во первых тоже возможна не всегда, а во вторых противоречит полезному выхлопу, т.е. вы не можете декомпозировать задачу на два куска один из которых не добавляет ценности продукту.
Оценка сроков
Не путать с оценкой задач, кореляция есть но слабая. Представьте вы и заказчик договариваетесь о новом проекте по разработке чего-либо, и на естественный вопрос «когда будет готово?» вы ему отвечаете «неизвестно, но каждые две недели мы будем показывать Вам новый красивый функционал». Т.е. сроки можно только прогнозировать, и это прогноз будет снаружи скрама, что противоречит скраму.
Кроссфункиональность команды
Вот это очень интересная проблема, на заборе (Scrum Guide) написано:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
Т.е. и это важно, постулируется, что каждый разработчик в команде (а иногда доходит что и аналитик и тестировщик) может взять и закончить любую задачу меньше чем за время спринта. Фактически это означает что все члены команды суть однояйцевые близнецы. Нежелание или желание конкретного человека заниматься чем-то выделенным (в рамках проекта) никого не интересует.
Более того, полное следование скраму неизбежно ведет к уравниванию интеллекта и знаний членов команды, что в принципе хорошо согласуется со Scrum Guide, где сквозит простая идея — набирайте 10 человек с улицы, берите скрам-мастера и когда-либо вы получите продукт.
Качество результата
В конце каждого спринта качество продукта не должно падать. Похвальный кстати постулат и абсолютно верный. Но
- О каком продукте ведется речь если разработка инкрементальная? О текущем? Так в принципе в конце каждого спринта команда имеет новый продукт.
- А почему не постулируется что качество должно расти? Только неубывание качества и новая функциональность.
Кроме того есть огромная проблема оценки качества. В скраме особо не раскрывается этот вопрос, пользователь получает новую фичу, радуется два дня потом выясняет что она работает не полно или не так как он желал. Проблема? Баг ни дай бог? Абсолютно нет, на следующей итерации мы улучшим работу данной фичи, мы же тут собрались навечно как следует из пункта 4.
Архитектура продукта
Ее нет. Есть наслоение решений различных задач здесь и сейчас.
Качество кода
В принципе если скрам команда слепо следует заветам, качества кода тоже нет. К счастью обычно разработчики более вменяемые и внедряют некие дополнительные элементы в процесс. Хотя конечно code-review например не приносит пользы инкременту и стало быть вреден.
Любите митинги?
Тогда мы идем к Вам! Вот тут нормальный скрам мастер не даст Вам скучать. У команды будет множество поводов собраться и потреньдеть.
Очаровательные сборища единомышленников, которые к примеру решают допустить ли до кода новичка в команде после двух недельного периода или еще пока рано.
Те-же сборища обсуждающие а по скраму ли живет член команды, комсомолец Борис или подался в блуд, и он теперь не комсомолец а просто член команды или вообще просто член.
Вы увидите, если повезет, процесс оценки задач, где более опытный человек говорит одно, а 10 менее опытных другое (они просто пока не отупели до одного уровня) и принимается естественное решение что миллион леммингов не может ошибаться.
Все это я видел сам и хотел-бы развидеть, да не могу.
Решение
Думаете сейчас буду призывать отказаться от этого мракобесия? Нет не буду. Причин несколько
- Решение принимает начальство нестойкое к езде по ушам на сектантских шабашах и Вы ничего сделать не сможете
- Иногда скрам действительно работает, например для простеньких продуктов, продуманных заранее вне скрама до разумной глубины проработки
- Когда код и архитектура совсем не важны, например если проект изначально разовый, без шансов на развитие
- Когда проект на столько никому не нужен, что даже о сроках никто не задумывается
- Если у вас есть кучка одинаковых разработчиков — может сработать
- Иногда это прикольно, если повезет со скрам-мастером то вообще ржачно, только относиться надо к этому попроще
- В нормальной скрам команде Вам могут действительно помочь в трудную минуту, прикрыть, подменить
Для меня идеальное решение это когда команда говорит всем, что работает по скраму а на самом деле просто нормально работает. Но тут надо вступать в сговор с PO — мы тебе не мешаем ты нам не мешай.
P.S. Без обид, если есть что возразить-добавить с аргументацией пожалуйста