SCRUM? Какой SCRUM?
Впервые подход SCRUM (англ. scrum «схватка вокруг мяча») описали Хиротака Такэути и Икудзиро Нонака, которые заметили, что небольшие команды (5 — 9 человек), укомплектованные разнопрофильными специалистами, дают лучшие результаты. Наиболее полное описание SCRUM впервые представил в своей книге Джефф Сазерланд. Книга так и называется — SCRUM. Джефф начинал свою карьеру как военный летчик, во время войны во Вьетнаме выполнивший более ста боевых вылетов. Затем Джефф занимался наукой, но мир его запомнит как одного из родоначальников SCRUM. Книга начинается с реальной истории из жизни ФБР, тратившего миллионы долларов на разработку автоматизированной системы, предназначенной для поиска и отслеживания преступников. Проблема заключалась в том, что по истечении сроков проекта подрядчики демонстрировали ФБР абсолютно нерабочий продукт. Это означало лишь одно — американские налогоплательщики потратили миллионы впустую. Ситуация казалась безвыходной до тех пор, пока руководство ФБР не обратилось к тогда еще зарождавшемуся методу управления проектами SCRUM. Этот метод описан доступным языком в вышеупомянутой книге, которая, кстати, переведена на русский язык. Далее в статье рассмотрены основные заблуждения и мифы, которые могут отпугнуть топ менеджеров, задумавших внедрить SCRUM в свои проекты.
1. Тотальный контроль, который убивает творческий подход
В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход, в отличие от классического менеджмента, где сотрудникам делегируют выполнение конкретных низкоуровневых действий, а те, в cвою очередь, часто даже не понимают, для чего это и как это повлияет на проект в целом. Таким образом, в SCRUM руководство не контролирует действия проектной команды, а та, в свою очередь, отчитывается только о результатах в конце каждого спринта (установленного заранее промежутка времени, например, 2 недели). Прозрачность существует только среди членов проектной команды. В чем она она проявляется? В первую очередь, ежедневные stand-up митинги, на которых каждый участник проектной команды рассказывает, что он сделал вчера, что сделает сегодня, какие проблемы у него возникли. Такая практика не преследует цели проконтролировать объем работ, выполненный каждым сотрудником. Stand-up митинги предназначены для того, чтобы помочь каждому члену команды устранить препятствия в работе и посвятить коллег в свои планы, чтобы каждый понимал куда движется проект сегодня и осознавал свою роль в развитии продукта. Для этих же целей, кстати, служит общая SCRUM доска со стикерами, которую может посмотреть каждый, и опенспейсы, которые уничтожают препятствия для свободного общения членов команды.
2. SCRUM лишает прав самых опытных инженеров, потому что они подчиняются решению команды
SCRUM создает такую среду, в которой авторитетом пользуются не титулы и должности, а навыки и опыт. Ярким примером обратной ситуации является иерархия у военнослужащих, где власть основывается на должности и на звании. Капитан может быть много более талантливым и эрудированным, чем полковник. Несмотря на это, капитан должен неукоснительно подчиняться. Такая жесткая структура идеально подходит для экстремальных условий, таких как боевые действия, где решения должны приниматься быстро, а их обсуждение приводит к промедлению, которое приводит к гибели людей. SCRUM не отменят титулов. Каждый сотрудник имеет свою должность в соответствии с его опытом и матрицей компетенций. Тем не менее, в процессе обсуждения того или иного решения главенствующим фактором является четкая и обоснованная позиция, подкрепленная личным опытом сотрудника в обсуждаемой области, а не его титул. Таким образам, вопреки мифу, SCRUM дает власть именно тем членам команды, кто ясно формулирует здравые идеи. А как известно — кто ясно мыслит, тот ясно формулирует.
3. SCRUM нацелен на краткосрочные ценности бизнеса, а не на долгосрочное развитие проекта
Данная проблема, действительно, актуальна. К счастью, на вопрос «Что же делать?» есть ответы. Следует начать с того, что если проект не долгоиграющий, с продолжительностью не более полугода, то данная проблема скорее всего не всплывет. Другое дело, когда софт развивается 2-3 и более лет. Существует множество статей, в которых авторы изливают свою боль касаемо таких проектов. Армия джунов и мидлов (синеры, как известно, стоят дорого и их мало) уверенно коммитит в master своё творчество, а заказчик спринт за спринтом пожинает блестящие результаты SCRUM. Но вот незадача, через 5-10 спринтов добавлять новые фичи становится проблематично, и чем дальше, тем сложнее. Следовательно, SCRUM — это хорошо, но о стратегии и об архитектуре задумываться надо. Предотвратить подобную ситуацию можно. Во-первых, на проекте должны работать
4. SCRUM не дает развиваться инженерам
SCRUM предполагает, что все решения, касаемые способа достижения бизнес-целей делегируются команде. Владелец продукта решает, что нужно сделать, а команда решает — как. Из этого вытекает, что команда должна быть достаточно компетентной, чтобы принимать эффективные решения. Таким образом, краеугольным камнем методологии SCRUM является обучение. Вот почему во всех крупнейших банках и IT аутсорсерах так много внимания уделяется развитию: тренингам, семинарам, курсам. Профессиональный рост сотрудников — это неотъемлемая составная часть SCRUM. За счет того, что SCRUM команды относительно маленькие, членам команды приходится осваивать весь стек технологий в рамках проекта, над которым они работают. По окончании проекта инженер получает новые навыки, что увеличивает его стоимость на рынке труда.
Промежуточный итог
SCRUM, как и любой другой метод управления проектами, имеет свои особенности и шероховатости, которые надо знать и учитывать. Несмотря на это, он дает лучший результат среди известных на сегодняшний день методов.
1. Джефф Сазерленд // SCRUM 2017.
Комментарии (50)
sbnur
15.06.2019 19:19+6Отмечено, что необходимым условием я вляется компетентность команды (хотя какой смысл применения этих методик для некомпетентной команды, точнее какой в ней смысл вообще).
Хотя если команда компетентна, регулярно повышает свой уровень компетентности, то зачем ей траты времени на всякие организационные мероприятия.
Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархияzloy_stas
15.06.2019 23:37> Хотя если команда компетентна, регулярно повышает свой уровень компетентности, то зачем ей траты времени на всякие организационные мероприятия.
Команда подразумевает совместную работу над продуктом в скраме. Совместная работа предполагает необходимость договариваться, обсуждать и принимать решения. Собственно, все встречи в скраме так или иначе про это. И без этих встреч эффективность была бы хуже — лебедь, рак и щука тянули бы в разные стороны.
> Также, если на первое место выводится здравомыслие, навыки и опыт, то зачем нужна производственная иерархия
Скрам про организацию не любых работ или проектов, а только в применении к разработке продуктов в небольших (до 9 человек) кросс-функциональных командахapapacy
16.06.2019 01:03Вот Вы сказали 9 человек. И упомянули о кросс-функиональности. Хотелось бы знать на реальном (не гипотетическом примере) из реальной разработки кто эти девять человек. Не поименно, а по функциям, конечно.
zloy_stas
16.06.2019 01:10На реальном примере: владелец продукта, 2 фронтенд разработчика, 3 бекенд разработчика.
выделенных тестировщиков — нет, но автотесты пишут разработчики, мы сознательно «убили» QA.
бизнес-аналитика в основном на плечах владельца продукта.
инжнерная часть — devops с настройкой пайпланов выкладки, мониторинг, алертинг все на стороне команды.
«Железная» часть — на стороне эксплуатации, которая не входит в команду.
VolCh
16.06.2019 15:35Кроссфункциональость часто понимают как владение всеми навыками всеми членами команды. Но многие считают, что суть кроссфункционалтности в том, что в команде просто должны быть все ключевые компетенции, что команда должна быть способна "зарелизиться" без внешних блокеров. Если есть внешние зависимости (очень часто, например, дизайнеры и админы/девопсы не часть команды), то по скрам должны быть изменения в постановке задач (дизайн как часть условий, а не "вы пока пилите логику, а дизайн-отдел будет рисовать) и приёмки, например, результаты разработки не реальный релиз, а поставленная админам задача на его выкатывание.
vintage
16.06.2019 16:31не реальный релиз, а поставленная админам задача на его выкатывание.
Поставленная админам задача не содержит business value — краеугольного камня скрама.
ApeCoder
17.06.2019 10:57Т.е. бизнесу пофиг выкатят релиз или нет — никакого value нет?
vintage
19.06.2019 08:47А постановка задачи админам — это ещё не выкатка. Более того, сама по себе выкатка — это ещё не business value, если релиз пришлось откатить из-за того, что он не держит нагрузки.
ApeCoder
19.06.2019 11:40Поставленная админам задача не содержит business value
Более того, сама по себе выкатка — это ещё не business valueДа, выкатка не value, но его содержит. Так же как канистра не является молоком, например, но может его содержать.
ApeCoder
17.06.2019 11:00Кроссфункциональость часто понимают как владение всеми навыками всеми членами команды.
Это кроссфункциональность команды состоящей из одного человека. Мне кажется, это совсем неверное понимание термина — он просто совсем не то означает (см. доступные определения)
ggo
17.06.2019 18:59например, результаты разработки не реальный релиз, а поставленная админам задача на его выкатывание.
как уже отметили, это очень плохой пример, противоречащий духу agile.
правильно — у команды есть реальные рычаги на админов, а еще лучше команда и админы понимают, что в общей упряжке, и решают общее дело. это все требует усилий и от команды, и от админов, но agile как раз и был ответом на потребность бизнеса — все ваши IT-шные заморочки решайте внутри себя, дайте мне, бизнесу реальный результат, я не хочу разбираться, кто из вас, разрабов или админов правее, у меня своих бизнес-проблем хватает.VolCh
18.06.2019 01:42Ответ был в виде, если грубо, "админы, выкатывающие наши релизы должны быть в нашей команде, команда должна быть способна предоставить бизнесу нужный ему результат самостоятельно — или админов давайте, или админские доступы нам, или результат — готовое к выкате приложение, а не выкатанное"
uhf
15.06.2019 21:26+9В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство
Другими словами, руководство перекладывает часть своих обязанностей на команду? Логично, пусть «тыжпрограммисты» думают — они же в очках и умные. Но в чем тогда функция руководства? Увольнять и делить прибыль?
SCRUM дает власть именно тем членам команды, кто ясно формулирует здравые идеи
То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.zloy_stas
15.06.2019 23:49-3> Другими словами, руководство перекладывает часть своих обязанностей на команду? Логично, пусть «тыжпрограммисты» думают — они же в очках и умные. Но в чем тогда функция руководства? Увольнять и делить прибыль?
В скраме функция руководства, точнее того, что не отдано на откуп команде — это обеспечение ресурсами — рабочее место, сервера и т.д, плюс верхнеуровневое целеполагание, ну и увольнять и делить прибыль, как правильно замечено. «Перекладывание» ответственности — это просто необходимость, потому что в условиях высокой неопределенности централизация менеджмента становится крайне неэффективной.
> То есть тем, кто понаглее, и громче кричит? Кто и как определяет здравость этих идей? Каким-то общим голосованием? За кем последнее слово? Тут я серьезно спрашиваю, без сарказма.
У команд есть обычно командные правила относительно того, как принимаются решения. Это может быть консенсус — все должны быть согласны или не-против, большинство — мнение большинства, это может быть апрув самого важного по функциональной части. Или все три.
Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другом. Если работать в команде кому-то не нравится, или команде не нравится, как кто-то работает, совершенно спокойно можно это обсудить, для этого в скраме есть специальная встреча — ретроспектива. И по результатам, либо меняются процессы, либо, например, человек может покинуть команду.uhf
16.06.2019 08:54+2в условиях высокой неопределенности централизация менеджмента становится крайне неэффективной
Спорное утверждение. Но если заменить слово «неопределенности» на «некомпетентности», то тогда ближе к правде. Глупость начальника многократно усиливается его административным рычагом, и может все разрушить. В такой ситуации отдать решения команде будет эффективнее. А руководитель пусть ретранслирует желания клиента, или сам фантазирует — назовем это целеуказанием.
Это может быть консенсус — все должны быть согласны или не-против
Т.е. если два фронтендера не могут определиться с выбором фреймворка, решающие голоса будут у девопса и бэкэндера?
Предполагается, что люди в команде обычно взрослые и зрелые и могут договорится друг с другом
Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире. Не могут договориться лидеры мировых держав, не могут договориться депутаты в парламенте. Даже здесь, на Хабре, среди, казалось бы, спокойных уравновешенных айтишников, Вы легко найдете полемику на сотни комментариев. Рассчитывать, что разногласия в команде решатся «как-то сами» несколько наивно и безответственно. По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.zloy_stas
16.06.2019 11:08+2> Т.е. если два фронтендера не могут определиться с выбором фреймворка, решающие голоса будут у девопса и бэкэндера?
Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуре и быть гуру разрешения конфликтов? Т.е. быть самым компетентным и самым лучшим во всем — как в софт-скиллах, так и в хард? Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
> По факту, инакомыслящие и несогласные при такой методике из команды будут вынуждены уйти, не получив даже шанса на реализацию своих нестандартных или старомодных подходов. Останутся только приверженцы одинаковых взглядов и идей, одинаковых ценностей, как в какой-то тоталитарной секте.
Все так. Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных. Т.е. вместо тоталитарный секты — авторитарная. Хотя какая разница какая секта, если работа сделана в срок? ;)
> Эх, если бы это было так — насколько лучше и спокойнее было бы в нашем мире.
А если конфликтов в команде много, то получается, что начальник по факту принимает все решения и чуть ли не один везет весь проект? В таком случае не проще ли научить команду саму принимать решения — дать критерии принятия решений, и помогать решать только важные и сложные конфликты?
Начальник — это очень часто ОДНА из сторон конфликта. И получается, что начальник должен разрешить конфликт, в котором он участвует. Совершенно очевидно, как будет конфликт решен и в чью пользу. И конфликты с начальником не будут разрешаться должным образом.
И по моему опыту проблема ровно обратная: конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе. Люди не хотят брать на себя ответственность, им проще, чтобы за них решил начальник.uhf
16.06.2019 12:15Т.е. должен определять начальник (тим лид)? Т.е. он должен уметь разбираться прекрасно в бекенде, во фронтенде, в девопсе, в архитектуре
Да, а в чем проблема? Разве тим лид не должен быть более зрелым и опытным, чем остальные члены команды? Сначала он выслушает все мнения, но решение в итоге принимает он. Я вижу такой подход более эффективным, чем псевдодемократия.
Ровно так же как это происходит в случае начальника, который нанимает в команду только тех, кто ему нравится, с кем он может и хочет работать, и увольняет остальных
Так начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
Начальник — это очень часто ОДНА из сторон конфликта
Начальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
конфликт разных инициатив встречается реже, чем отсутствие инициативы и проактивности со стороны разработчиков в принципе
Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.zloy_stas
16.06.2019 13:14> Да, а в чем проблема? Разве тим лид не должен быть более зрелым и опытным, чем остальные члены команды? Сначала он выслушает все мнения, но решение в итоге принимает он.
Одновременно разбираться во всем невозможно. Быть самым умным чуваком в команде можно только в том случае, если ты управляешь джунами-мидлами.
> Я вижу такой подход более эффективным, чем псевдодемократия.
В скраме нет задачи сделать всем хорошо, в скраме есть задача сделать качественный продукт за минимальное время.
Псевдодемократии — нет. При принятии рабочих решений есть критерий, который все знают, и которым руководствуются. Если критерий не срабатывают — идут к медиатору (и это совсем не обязательно начальник), который решает конфликт.
Демократия и обсуждения нужны для того, чтобы все понимали, что сейчас происходит. Эта прозрачность дает возможность всем принимать более качественные решения на местах.
> Так начальник в любом случае уволит того, кто его не устраивает. Но компетентный начальник будет больше оценивать профессиональные качества сотрудника, в то время как SCRUM-начальник может оценить только софт-скиллы (т.е., проще говоря, умение работать языком).
«Начальником», которые оценивает профессиональные качества сотрудником может быть функциональный руководитель — главный по фронту или главный по беку, который не входит в состав команды.
> Начальник и подчиненный изначально на разных ступенях, какой между ними может быть конфликт? Подчиненный говорит — начальник слушает. Начальник говорит — подчиненный выполняет. Не согласен с решением начальника? Выбор есть: смириться и делать, обращаться в высшие инстанции, увольняться, самому становиться руководителем.
Конфликт может быть любой — «Вася не нравится Пете-начальнику как человек, поэтому Пете Васе не дает премию». «Петя-начальник дает скучные и простые задаче Васе, Вася этим не доволен, но боится прийти к Пете, потому что его уволят». И т.д. и т.п.
Уход человека — это обычно самый плохой исход конфликта, потому что поиск нового человека и его адаптация — это очень затратно.
> Здесь интересно было бы послушать, как SCRUM мотивирует реально проявлять инициативу, а не радостно поддакивать на митингах и со всем соглашаться, оставаясь пассивным на деле. Как распределяется ответственность в команде, кто ее распределяет, и как применяется система поощрений и наказаний, если она вообще есть.
Скрам не призван решать эту проблему. Но в целом возможность брать на себя инициативу, определенная свобода в выборе технических решений и определении сроков, возможность видеть результаты своего труда вживую — это очень сильный мотиватор.
Скрам не решает проблему распределения отвтественности внутри команды. Считается, что люди сами между собой могут договорится. В целом у меня за несколько лет, в нескольких командах было не больше 5-6 конфликтов, когда люди не смогли договорится кто что делает и кто за что отвечает. И те решались на ретроспективе самостоятельно командой, либо между собой без эскалации наверх.
Система поощрений и наказаний тоже вне рамок скрама. Но обычно проста как палка — функциональный руководитель принимает решение о том поощрять человека или нет.
> Я допускаю, что если взять группу отборных высококвалифицированных японских трудоголиков, они могут показать очень высокий результат, работая по данной системе. Но это вовсе не означает, что эту методику можно перенести на всех остальных.
нельзя, поэтому главное требование к таким командам — это зрелость. Скрам не заработает в случае, если у нас склочная команда инфантильных разработчиков. Более того, в таких ситуациях скрам противопоказан.Zenitchik
16.06.2019 13:31Одновременно разбираться во всем невозможно. Быть самым умным чуваком в команде можно только в том случае, если ты управляешь джунами-мидлами.
Почему тилид должен быть один на всех? У нас их два, один по фронту, другой по беку. На скраме — общаемся все вместе.
OnYourLips
16.06.2019 13:55Т.е. должен определять начальник (тим лид)?
Конечно, ведь ответственность за команду и результаты на нём.
К тому же простым большинством решать вопросы не всегда продуктивно даже среди представителей одного узкого направления ввиду разного опыта. Например в команде, где есть сеньор, два мидла и два джуна я однозначно не стал бы играться в демократию.
lxsmkv
16.06.2019 05:11Идеология скрама произрастает из исследования Нонака и Такеуши (Ikujiro Nonaka, Hirotaka Takeuchi, 1986, "The New Product Development Game"). Они рассмотрели, как успешные компании изменяют подход к разработке новых продуктов. Раньше разработка новых продуктов проходила фазы, продукт передавался по цепочке от одного отдела другому. А подход «рэгби», как они назвали его в работе, стирает эти границы. Собирают команду, и дают им задачу. Например сделать фотокамеру компактной, надежной, простой и на 30% ниже средней рыночной стоимости. (Т.е. дают явно «невозможную» задачу)
Такая команда представляет собой «Task Force». Выкладываясь более чем на 100 %, люди работают в тесном взаимодействии друг с другом. Они притираются друг к другу и работают как одно целое.
Естественно, для такого взаимодействия необходимо, чтобы у людей не было завышенного эго, чтобы не было рангов и титулов. Каждый имеет свою сильную сторону. Каждый умеет что-то лучше других.
В статье говорится,It may not apply to organizations where product development is masterminded by a genius
who makes the invention and hands down a welldefined set of specifications for people below to followuhf
16.06.2019 09:09С фотокамерой, допустим, понятно: там неудачная идея сразу же негативно отразится на характеристиках, а через два года камера морально устареет и её выбросят.
Как быть с разработкой софта, где выбор неподходящего инструмента или технологии, на определенном этапе, может создать большие проблемы спустя годы, а чтобы это предвидеть, нужно обладать опытом в определенной сфере, которым не владеют все члены команды?
И существуют ли примеры создания серьезных ответственных вещей по данной методике? (самолет, АЭС, ракетный двигатель, другое сложное инженерное сооружение)apapacy
16.06.2019 11:29Я думаю что при создании таких прорывных изделий как например буран использовались. Только называлось это программно целевое планирование и управление.
Но в том виде как сейчас это пытаются сделать вайти это конечно скорее напоминает упоминавшуюся недавно опубликованную на одном из штатовских официальных сайтах инструкцию для саботажа фашистской Германии авторства ЦРУ опубликованную по истечению срока секретности
ggo
17.06.2019 10:07Очевидно, что АЭС строить или ракетный двигатель, лучше по другим подходам.
Почему?
Очевидно, из-за природы software и hardware.
В software ты можешь каждый день выкатывать релиз и проверять его пригодность на практике.
В hardware получать на сколько нибудь регулярной основе новую версию можно (в некоторых случаях) но периоды этой активности несколько больше.
apapacy
16.06.2019 11:27+1А ещё за десять лет до этого вышла монография Гермогена Поспелова Программно целевое планирование и управление. Вне зависимости от вопроса о приоритетах. Почему упоминание о скраме в нашем средечтатичтичесуом айти вызывает явную досаду у многих комментаторов этой статьи. Мне кажется что причина в том что наш менеджер в опять же среднестатистическом случае выбрасывает суть метода и концентрируется на внешних атрибутах, которые на самом деле не имеют никакого значения.
vintage
16.06.2019 09:32Можно много фантазировать о том, какие люди должны быть, но красивые рассказы о скраме обычно разбиваются о суровую реальность.
В SCRUM как достичь бизнес-цели, решает проектная команда, а не руководство. Такой метод мотивирует и стимулирует творческий подход
В реальном мире большинство людей не склонны отходить от привычных паттернов. Тем более, если нововведения предложены не ими самими. Толпой вы можете сделать очередной клон популярного сервиса. Но чтобы создать что-то по настоящему новое нужен визионер, которому не будут бить по рукам, когда он гонит очередную дичь.
SCRUM создает такую среду, в которой авторитетом пользуются не титулы и должности, а навыки и опыт.
Наоборот, он создаёт среду, где любая посредственность имеет такое же право голоса, как и опытный инженер. Звучит это, конечно, красиво, но ровно до тех пор пока такие посредственности не собираются в группы и не продавливают своё мнение большинством голосов. Можно сколько угодно высказывать свою "чёткую и обоснованную позицию", но от тебя с лёгкостью отмахнутся, воспользовавшись одним из многочисленных когнитивных искажений.
SCRUM — это хорошо, но о стратегии и об архитектуре задумываться надо.
Но кто и когда это будет делать? Если потратить N итераций вначале на проектирование, то это ничем не отличается от водопада. А если, как обычно, сразу начать пилить, то потом никакой итерации не хватит на изменение архитектуры.
За счет того, что SCRUM команды относительно маленькие, членам команды приходится осваивать весь стек технологий в рамках проекта, над которым они работают.
И насколько качественный выйдет результат, если над проектом работают люди, которые в процессе реализации только осваивают технологии?
Резюмируя: скрам — методология, как посредственной командой достичь посредственного результата за долго и за дорого, растеряв по дороге всех талантливых людей.
VolCh
16.06.2019 15:23Как я понимаю, в большинстве проектов, которые хорошо попадают под аджайл на бищнес-уровне, рефакторинг архитектуры на техническом уровне постоянная и неотъемлемая часть процесса разработки. При груминге задач иногда нужно специально поднимать вопрос а ложится ли планируемой решение на существующую архитектуру или перед началом имплементации новых требований, нужно изменить архитектуру. Как минимум занести нелюобходимые изменения в техдолг.
vintage
16.06.2019 18:14рефакторинг архитектуры на техническом уровне постоянная и неотъемлемая часть процесса разработки
Рефакторинг кода. Изменение платформы, языка или хотя бы фреймворка — вещи неподъёмные.
При груминге задач иногда нужно специально поднимать вопрос
И этот вопрос всегда откладывается в долгий ящик, так как всегда можно придумать какой-нибудь влезающий в итерацию костыль. А потом костыль к костылю и тд.
VolCh
18.06.2019 21:27Есть приёмы, позволяющие даже язык менять малой кровью. Например, MSA.
Не всегда. Причём способы достичь этого есть разные.
ApeCoder
19.06.2019 07:36А можно ссылочку на MSA? Я попробовал найти, но не получилось
vintage
19.06.2019 08:45+1Он говорит про микросервисную архитектуру, сама разработка которой — уже та ещё боль. А продавить микросервисы на старте проекта зачастую не получится, ибо монолит можно состряпать быстро, а с микросервисами можно итерацию только потратить на обсуждение протокола их взаимодействия.
lxsmkv
17.06.2019 03:34В lean есть такой принцип — «defer commitment» или «decide as late as possible» — откладывать решения (тяжелые, необратимые) как можно дольше. Это не значит, что не надо об этом думать, наоборот. Но есть масса вещей которые можно сделать до принятия необратимого решения.
Создавать техдолг идет вразрез с идеологией lean. Техдолг это inventory — «запас». Его надо уменьшать. (см. Applying Lean Thinking to Software Development by Steven Peeters, 2013)
Рефакторинг архитектуры это уменьшение техдолга. Но нужно учитывать, что он сам по себе в общем случае не добавляет ценности конечному продукту. Однако, в частном случае, если задача поставлена так, что нужно, например, приложение ускорить, то тут изменение архитектуры явно корреллирует с целью. Но такую задачу можно/нужно раздробить, чтобы не одна работа не блокировала другую. Ведь есть еще и другие точки в которых можно добиться улучшения производительности.
Да, приходится думать как организовать работу так, чтобы был постоянный результат. Это часть подхода. И в моем понимании, в скраме это одна из компетенций скрам-мастера — обеспечивать «текучесть» проекта.
В техническом плане если мы хотим сначала сделать самокат, потом велосипед, потом мотоцикл, потом автомобиль — то рефакторинг архитектуры на каком-то этапе может понадобиться. Но если планировать изначально, что ты в конце концов собираешься делать автомобиль, то можно выбрать такие технические рамки (например фреймворк) которые будут позволять трансформировать продукт по ходу дела. На каком-нибудь высокоразвитом фрейворке типа spring можно делать и самокат, а можно и самолет. Просто в разные сроки. Ведь один из принципов agile это — design for change.
А если мы будем учитывать, что все может измениться, то и архитектура приложения будет максимально гибкая, где мы ничего не прибиваем гвоздями.
Проблема аджайла в том, что его продают заказчикам как «быстро и дешево», но на самом деле это не быстро и не дешево. Это гибко. Когда заказчик сам еще не знает до конца что ему нужно. Как в истории про Стива Джобса, когда ему не понравился дизайн калькулятора, и он заставлял его переделывать, пока команда не сделала ему конструктор, и он не подобрал все параметры так, как нравится ему.ggo
17.06.2019 10:14Это гибко.
Надо выделить жирным. Не быстро, не дешево, не качественно, а гибко.
Еще важно отметить agile у носителей английского, это не столько гибкий (резиновый), а сколько ловкий. Ловкий в решении проблем, которые стоят перед бизнесом. Опять же, проблем бизнеса, а не проблем ИТ.lxsmkv
17.06.2019 12:58Я бы сказал «юркий» — т.е. ему легче остановиться и развернуться.
То что гибкие проекты выпускаются быстрее (что не всегда и не обязательно так) обусловлено тем, что по сравнению с эстафетной (или водопадной, если хотите) моделью, меньше вероятности, что под конец выяснится, что сделали вообще не то что надо было и придется переделывать вообще с нуля. Этот риск действительно меньше.
Качественно оно должно быть в понимании «good enough quality» — достаточное качество. Стандартное качество, потребительское.
Дешево оно скорее всего не будет. Как я приводил в комментарии выше — люди работают в принципе в режиме кранча, с чего бы оно было дешево? Да и про стоимость вообще нигде ничего не говорится.
Т.е нужно понимать какому клиенту нужна именно гибкая разработка, а кому нет, Пихать гибкую методологию во все дыры как это сейчас делают, это, конечно, в корне неправильно.lxsmkv
17.06.2019 16:57Хорошее сравнение:, например нужно сделать ремонт в квартире. При эстафетном подходе сначала приходит один мастер, делает свое дело и уходит, приходит другой, говорит что предыдущий свое дело не доделал и он не может начинать, снова вызываем первого, тот валит на второго. И так далее, картина всем знакомая. Как было бы удобно если бы они оба сразу пришли и договорились. Это и был бы аджайл. Пришли все мастера, договорились и начали делать работу.
Будет это дешевле? Нет, не обязательно. Будет это качественней? Не обязательно. Но заказчик может прийти через два дня и внести поправки в работу. Вот и весь «фокус-покус», аккордная работа вроде бы это называется, и существовало еще до компьютеров.
apapacy
18.06.2019 02:41Проверить опытным путем какие по какой из методик проект будет сделан быстрее невозможно! Т.к. один и тот же проект невозможно сделать дважды той же самой командой и в то же самое время. Если основываться на чисто умозрительных на суждениях то по аджайлу проект будет выпускаться гораздо дольше, хотя по идее он принесет больше пользы заказчику. Т.к. в аджайл предполагается на первое место ставить выполнение так сказать сверьхзадачи решение проблемы заказчика а не простое следование ТЗ и выполнение пунктов договора. Теперь вопрос знатокам, насколько фирмам разработчикам это выгодно затратить уйму времени, отклониться от ТЗ не выполнить условия договора? Здается мне что разговоры о том что мы работаем по аджайлу в большей степени носят маркетинговый характер.
Когда эти методики примняются для себя например в Apple или в Пентагоне, то здесь ясно что для себя важен результат. Хотя конечно бюрократия есть всюду. А если это говориться что мы вам по аджайлу создадим что то то слабо веритсяggo
18.06.2019 09:26Теперь вопрос знатокам, насколько фирмам разработчикам это выгодно затратить уйму времени, отклониться от ТЗ не выполнить условия договора?
Настолько, насколько это выгодно заказчику.
Кого-то интересует следование ТЗ, кого-то решение конкретной проблемы.
Am0ralist
18.06.2019 09:41Но если вы выполните не по ТЗ, а по хотелкам, а результат заказчика не устроит, то ваша компания может оказаться в очень сложном положении. Так что решение конкретной проблемы путем, отличным от ТЗ, таки стоит тоже фиксировать допами.
ggo
18.06.2019 10:11Вы немного не туда…
Исполнителю выгодны те приоритеты, которые озвучил заказчик.
Если заказчик очень хочет работать строго по ТЗ, значит работаем строго по ТЗ.Am0ralist
18.06.2019 10:19Да нет, заказчик очень хочет работать не по ТЗ, вы ж все его хотелки делаете. Потом вдруг оказывается, что результат не по ТЗ оказался фигней и вот вы уже не смогли закрыть договор и вам грозят штрафные санкции, ибо в договоре прописан ТЗ и то, чем должна соответствовать программа по нему. Удачи доказывать, что высказанные в личном разговоре хотелки клиента важнее прописанного в договоре ТЗ)
ApeCoder
18.06.2019 09:52Могу поделиться только тем, что читал:
https://en.wikipedia.org/wiki/Agile_contracts
https://martinfowler.com/bliki/ScopeLimbering.html
https://www.scaledagileframework.com/agile-contracts/
VolCh
18.06.2019 21:31Каждый спринт может оформлять допкой к рамочному договору. В каждой допке скоуп работ и критерии приёмки.
apapacy
Практически все хайповые методики включают два как мне кажется важных пункта
1 наладить взаимодействие в команде
2 все кроме пункта один (канбан доски, стоячие оперативки и т.п.) опциональны за исключением пункта 1
В противном случае применение хайповых методик напоминает русскую народную сказку Солнце, Месяц и Ворон Воронович. Да и кстати если уж применять методики то на всех этапах проекта. Поясню что имею в виду. Полтора года потрачено на предварительные невнятные работы. За три месяца до сдачи проекта наконец дело доходит с высот менеджмента до низов разработки. И тут кого то наконец осеняет идея. А давайте будем теперь пинать их по скраму.
zloy_stas
> 1 наладить взаимодействие в команде
это и называется организовать работу ;) Собственно скрам, канбан и весь остальной аджайл вроде именно про то, как «наладить взаимодействие в команде». Подходят ли конкретные практики для компании и команды и как они «внедряются» — это конечно отдельный разговор.
apapacy
Да если эти предметы не превращаются в фетиш за которыми уже некогда думать о взаимодействии людей, в формальность так сказать.
0x131315
Классика.
Скоро сдавать один из проектов. Полгода по нему кидают десятки задач. Ничего не согласовано — менеджмент договаривается еще.
На что они рассчитывают? Не ясно.
По сути срок сорван еще на уровне менеджмента: до разработчиков задачи еще не дошли, и оставшегося времени на их реализацию им при всем желании не хватит.
Так и живем.
mmMike
Да все так живут.
Каждый новый проект — все то же… Достало.