Работа в 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 требует скраммастера для построения окружения где:
- Владелец продукта (PO) размещает задачи на разработку в продуктовом бэклоге (бэклог — это такая братская могила из невыполненных задач)
- Скрам команда выполняет избранные задачи и порождает добавленную пользу (именно пользу для конечного пользователя) за один спринт (просто период времени).
- Скрам команда и другие заинтересованные стороны анализируют результаты и принимают решения по улучшению процесса на следующий спринт.
- Провторяем до бесконечности (в оригинале условие выхода из цикла не задано)
Скрам это просто. Попробуйте следовать ему и определите является ли это философией и структурой позволяющей достигать поставленные цели и создавать ценность. Скрам фреймворк намеренно неполон, только определяет части, которые нужно разработать. Скрам базируется на коллективном разуме людей которые используют его. Скрам не дает подробных инмтрукций, правила Скрама определяют отношения и взаимодействия.
Не правда ли очаровательно? Вы должны взять методологию, простую как три копейки и следовать простым правилам, после этого можете не сомневаться — все получится. Хмм… нужен скрам-мастер — не беда, вокруг этого всего навыростал миллион компаний, которые помогут, сдадут в аренду хорошего скрам-мастера, который выстроит процесс в Вашей компании. Он ничего не знает о продукте? Он и не должен! В этом весь смысл.
Кроме того, читая этот текст в первый раз, меня не оставляло паскудное ощущение… данный текст по построению весьма похож на саентологические(как впрочем и любой сектантский) тексты, Вам с первых строк говорят делай так и будет тебе счастье. Если кто не верит, просмотрите в первоисточнике.
И на всякий случай повторю, оригинальный текст взят без изменений из свежего 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. Без обид, если есть что возразить-добавить с аргументацией пожалуйста
36 комментариев
Добавить комментарий
Последний абзац конечно про другую крайность, у меня таки варианты были, когда работали по заказу от госпредприятий (ну почти — РЖД).
Да что же такое с людьми…
1. Скраму требуется персонал, способный жить по эджайлу. Уже одно это подходит не всем. Без согласия с эджайлом скрам выглядят странным сектантством. Это нормально.
2. Скрам-мастеру и впрямь не обязательно понимать в продукте. Будет меньше лезть в решения команды.
3. Скрам, как любая методология, имеет свои ограничения по применимости. Сюрприз! И по масштабированию тоже. Внезапно! Хотя, говорят, есть методики…
4. Скрам с эджайлом хороши для начала разработки чего-то нового (желательно — принципиально) командой единомышленников. До единорогов на скраме команды дорастали.
Меня просто удивляют люди которые отрицают ограниченность любой методологии включая скрам.
и никто не мешает наличию команды действующей по четкому плану, создающую каркас системы или аккуратно рефакторящую код выросший из реальной жизни, а поэтому убогий и бессистемный
Я привел в начале выдержку из СкрамГайда, и перевод, понять его не правильно невозможно. Или я в переводе ошибся?
Основываясь на определении, как раз таки нет, не позволяет, скорее это способ растянуть проект.
А по поводу командного kpi, даже слов нет, но попробую покорректнее: во первых это и есть то самое уравнивание всех, а во вторых умная команда всегда будет строить спринт так чтобы получить премию. Всегда. Исключений нет. Делать при этом может даже меньше, но премию получит.
Ну и судя по всему, работаете Вы не по скраму, а по некому процессу который Вам подходит — ну и норм, можно только поаплодировать.
Скрам основан на эмпирицизме — сделал, измерил, улучшил. АЭС по такому подходу действительно не строят, но большинство людей их и так не строят. Кроме того, многие заказчики хотят как можно раньше выйти на рынок. Кроме того, не все заказчики могут заранее сформулировать то, чего они хотят (или чего хочет рынок) и создать полный и точный перечень требований. Кроме того, рынок может поменяться, пока идёт разработка и приходится реагировать.
ВОВЛЕЧЕННОСТЬ ЗАКАЗЧИКА
Иногда PO может быть не от бизнеса. Будет вовлекать заказчика в виде стейкхолдера по мере необходимости. Но нужно понимать недостатки.
ОЦЕНКА ЗАДАЧ
В скрам гайде нет ни слова про оценку задач. Он про другое.
Декомпозиция это только один из методов оценки. Оценка нужна и разработчикам, и бизнесу. Оценку делают и в классических подходах (см. иерархическую структуру работ в PMBoK). Отличие в том, что в Agile учитывают конус неопределенности и оценка уточняется по мере необходимости, не перезакладываясь на лишние риски.
ОЦЕНКА СРОКОВ
В скрам гайде нет ни слова про оценку сроков. Он про другое.
Agile команды не делают вид, будто бы они знают, если на самом деле они не знают. Стараются не тыкать пальцем в небо. Они просто обеспечивают прозрачность.
КРОССФУНКЦИОНАЛЬНОСТЬ КОМАНДЫ
Там написано «The members have all skills», а не «Each member has all skills».
КАЧЕСТВО РЕЗУЛЬТАТА
1. Процитируйте точную фразу, с чем вы спорите. Продукт один и тот же, даже если инкрементов несколько.
2. Можно написать, чтобы росло, но только вы потянете такое? Ну и суть в том, что если регулярно ослаблять DoD, то ни разрабы, ни заказчик не будут понимать что же они делают и на что можно рассчитывать. Ценность такого продукта будет не очень высокой.
АРХИТЕКТУРА ПРОДУКТА
В скрам гайде про это нет. Он про другое.
Если не производится предварительный детальный дизайн всей системы, то это не значит, что архитектуры нет. Просто такая работа часто считается потерями. А вообще команда всегда видит весь бэклог продукта и может проектировать систему так, как считает необходимым.
КАЧЕСТВО КОДА
Про качество кода в скрам гайде нет ничего. Он про другое.
В agile командах качеству кода уделяется огромное внимание, потому что иначе вы не сможете адекватно реагировать на изменения. Например множество практик описано в XP.
ЛЮБИТЕ МИТИНГИ?
В скрам гайде в рамках спринта есть 4 события — планирование, дейли, обзор и ретро. Для каждого события есть таймбокс, место/время и свое четкое предназначение. Это позволяет наладить обратную связь, определить, когда решаются те или иные вопросы и сократить лишние совещания в произвольные моменты времени.
РЕШЕНИЕ
К сожалению, все подряд сейчас пытаются пролезть в айти в погоне за легкими деньгами. При этом умеют только болтать языком, поэтому идут скрам-мастерами и всякими коучами, не понимая, что они делают. После этого у многих айтишников появляется крайне плохой опыт и рождаются такие вот статьи. Решение — учиться. Ну или избегать нынешнюю реальность, но вряд ли это хорошее решение.
На самом деле конечно есть, возможно не декларативно, но косвенно. Sprint capacity например это именно про возможности команды взять N задач оцененных в попугаях.
Дык я про это и написал-же. Он вообще про другое, он про процесс разработки а не про результат.
Я ни с чем не спорю, а говорю как есть. Представьте продукт в момент Х содержащий N фичь. После пары итераций, в момент X+2 спринта команда утопила часть фичь и добавила часть новых. Превнеся и новые баги и новый функционал.
Так что продукт формально будет другим.
По поводу Архитектуры и Качества кода мы с Вами пишем примерно одно и то-же, но разными словами.
С Вашей версией решения тоже согласен.
В рамках планирования спринта предлагается ответить на вопрос «что может быть сделано в рамках спринта» (причём «может быть» — это не обязательство). Используйте любой удобный вам подход, с попугаями, без попугаев или ещё как — дело ваше, скраму без разницы.
Да просто обратил внимание, что в заголовке указано Scrum Framework, но по факту в заметке про что угодно, кроме скрама.
Это зависит от вашего определения слова «продукт».
Теперь что касается того, что заказчик получает не то, что ожидал. Вообще требования должны быть в бэклоге продукта (кроме некоторых отдельных моментов) и как раз заказчик, в лице PO, управляет бэклогом продукта, в т.ч. участвует и в груминге. Если требования представлены в формате пользовательских историй, то кроме краткого описания, там часто пишут критерии приёмки, а к ним приёмочные тесты, которые проясняют, как что должно работать. Но это всё, опять же, не про скрам. От скрама здесь требуется только предоставить событие — ретроспективу — где могут обсуждаться подобные проблемы. Он и предоставляет.
Да нет, в заметке как раз именно про то, во что имплементирует ScrumFramework большинство команд. По незнанию ли, по злому умыслу, но народ массово сваливается во все эти игры, и фреймворк повинен тут в том, что описывает удобный и легкий путь сделать это.
Откуда взялось это «именно видимого»? А если в спринте переработали существующий алгоритм и, например(!), какой-то отчет не изменился, но стал формироваться в X раз быстрее, то все — «прироста видимого функционала» не произошло, туши свет, сливай воду?
И суть не в частностях, а в общем подходе. Отчет был примером (поэтому там и стоит «например»).
Вы почему-то сами интерпретировали value как «видимое изменение» и возмущаетесь этим.
Может быть проблема не в том, чтобы увидеть эту разницу, а в том, чтобы ее выразить в понятном пользователям виде? Так это проблема исполнителей, а не методологии.
Врать на работе — вообще плохой подход.
У вас, похоже, опыт в разработке ограничен пользовательскими приложениями, поэтому вы так и уперлись в интерфейс. Есть масса программ, которые от версии к версии не сильно-то меняются в интерфейсе (если он вообще есть), например драйвера устройств, кодеки, библиотеки, ПО для встроенных контроллеров и т.п. В вашей парадигме в командах, которые разрабатывают такое ПО, вообще скрам применять нельзя, получается, т.к. никакой «видимой пользы» никогда не продемонстрировать.
Убеждать в том, что вам кажется правильным — это медвежья услуга на самом-то деле, так как вы можете ошибаться. Особенно если вы в предметной области не так давно, как заказчик. Куда плодотворнее (хоть и тяжелее) вместе с заказчиком анализировать проблему и вычленить суть, нежели с высоты башни из слоновьей кости мудро поучать людей чего же они хотят «на самом деле».
Скорее наоборот, мой опыт ничем не ограничен, от участия в разработке Java до каких нибудь процессов на Pega PRPC, включая как ни странно и низкоуровневую ботву временами.
Полезная функциональность
Бесполезно притягивать за уши аналогии со сбором самолета или строительством дома. И то и другое делается по подробнейшей и практически неизменной (в процессе) проектной документации. Если у вас есть заказчик, готовый дать такой документ на софт-проект — вы умерли и попали в Вальгаллу для программистов. Поэтому в строительстве вполне хорошо работают старые добрые диаграммы Ганта, но попытки использовать этот подход в ПО превращаются в смердящий ужас.
Вовлеченность заказчика
Если заказчик не готов предоставить человека, принимающего участие в проекте — заказчик по дефолту идет нафиг. Такой проект изначально обречен на внезапные и болезненные переделки, дрязги, недовольство и пр. Никто, кроме заказчика не знает чего он хочет и как он это видит. Если у заказчика есть подробнейший проект — см. выше.
Оценка задач
Тут уже элементарное непонимание методологии скрама. Никто не запрещает декомпозировать задачу на куски, которые в отдельности могут не добавлять ценности продукту. Нормальная практика, когда есть story, которая добавляет ценность, но внутри она декомпозирована на отдельные таски. Можно даже таски не заносит, просто для себя на бумажке декомпозировать и посчитать. Это вообще не проблема скрама.
Оценка сроков
Для того чтобы оценить конечный срок нужен детальный проект, который не будет меняться в процессе. А он — см. выше.
Ну и так далее.
Скрам это не то что написано в СкрамГАйде, а то что из него делают отмороженные люди со стеклянными глазами. Никогда не работали в таких компаниях? Я работал к сожалению, хорошо, что есть испытательный срок, когда можно просто сказать «до свидания нам не по пути».
На самом деле было интересно пообщаться с разумными людьми (в этой теме), которые могут аргументировать свою точку зрения на разработку, почему-то в жизни мне попадается другой вариант.
Что касается «людей со стеклянными глазами» — ну да, сталкивался, конечно. Но, опять же, это не проблема скрама как метода. Если человек не понимает методологии или не умеет пользоваться — это проблема данного конкретного человека. Ровно та же самая проблема возникнет и при использовании других подходов. Если человек не умеет — он с высокой вероятностью нагородит фигни. И да, намного хуже когда человек не осознает, что он не умеет и со «стеклянными глазами» лепит что-то в рамках своего недопонимания.
Разумеется все это относительно разработки софта. В других отраслях скрам вполне может быть не применим или неэффективен в сравнении с другими подходами.
1. Разработка внутреннего инструмента для компании разрабатывающей процессинговый софт, работал там два раза, во второй был скрам: ПМ, команда только из меня одного — кончилось быстро и плохо, свалил оттуда.
2. Крупная банка — разработка бизнесс процессов на Pega PRPC, половину команды фактически уволили по решению самой команды. Обучил сменщика и свалил.
3. Мелкий стартап, куча безумных людей со стеклянными глазами делающими вид, что они работают по скраму, ушел на испытательном сроке.
Вчера друг уволился из лавки, проработав 1 месяц, послал в задницу скраммастера приглашенного в лавку для выстраивания процессов, поговорил с СТО и уволился текущим днем, пользуясь тем, что еще испытательный срок.
Было и пару положительных опытов, например сейчас, когда мы пилим софт, в котором есть работающий код 1998 года, правда скрам у нас очень относительный.
Добавить комментарий