Если вы читаете этот пост, то, вероятно, работали по какой-то разновидности Scrum, но если нет, присаживайтесь и будьте моим гостем.
Давайте начнём с самого начала.
Что такое Scrum?
Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.
Что касается Agile, то если вы никогда не читали его манифеста (2001 год), то определю его как компактный список рекомендаций, которым нужно следовать при разработке ПО.
Agile не является: Библией разработки ПО, догматическим набором строгих правил, тикетами Jira или коучами Agile, суетящимися в вашей компании.
Дополнение: определения несовершенны по определению (а теперь прочитайте это ещё раз).
Я с открытой душой приму любую критику о своих определениях Scrum, Agile и любых других терминов, и лишь попрошу прочитать пост целиком, прежде чем писать разгневанные комментарии!
Теория и практика
Agile противоположен каскадной модели (Waterfall) — олдскульному способу создания ПО до 90-х.
Agile итеративен, каскадная модель последовательна. Agile компактен, каскадная модель тяжела. Agile быстр, каскадная модель медленна. В Agile на первое место ставится код, в каскадной модели — документация.
Я мог бы продолжать долго, но не буду, наверное, вы поняли принцип.
Источник происхождения Agile был очень хорошим, он стал революцией, превратившей разработку ПО из последовательного кошмара в дисциплину, которую с радостью практикует множество инженеров, включая и меня.
Я бы ни за что не стал оспаривать авторитет людей, придумавших его теорию, потому что реальная проблема реализации Scrum заключается в нашем не очень идеальном мире.
▍ Церемонии
Самый фундаментальный термин Scrum — это спринт. По сути, спринты — это заранее установленные временные промежутки (обычно длящиеся две недели). В течение этого промежутка времени, наряду с циклами разработки, Scrum-команда должна следовать некоторым церемониям.
Примечание: мне никогда не нравился этот религиозный термин, используемый для описания подобных совещаний, но что уж есть.
- Планирование спринтов — как бы просто ни звучало, это долгая сессия (до четырёх часов) по планированию пунктов/историй пользователя, которые необходимо реализовать в течение следующего спринта, задействующего scrum-команду.
- Ежедневные совещания — ежедневные КОРОТКИЕ совещания (примерно 15 минут), на которых маленькая команда разработчиков (примерно 3-7 человек) обсуждает свой прогресс и выделяет мешающие двигаться дальше проблемы, не вдаваясь в подробности. Это время, в которое можно попросить Алису устроить отдельное совещание о проблеме кэширования на стороне сервера и спросить Боба о том, почему параметр даты является строкой, а не временем Unix.
- Выполнение спринта — люди автономно берут задачи, а затем исполняют их и решают возможные проблемы на неформальных совещаниях, сессиях парного программирования, код-ревью и активного копипастинга из ChatGPT. А что насчёт тестирования? Это часть выполнения. QA? Тоже туда же. Документация? Вы знаете ответ. Задачи эксплуатации/DevOps/инфраструктуры? Можете догадаться сами.
- Обзор итогов спринта — долгое совещание (1-2 часа), призванное продемонстрировать результат спринта стейкхолдерам и получить от них обратную связь.
- Ретроспективное совещание — внутренний анализ того, что было сделано, с упором на помехи, чтобы убрать их из последующих спринтов и для общего постоянного совершенствования процессов, практик и инструментария для следующей итерации.
- Упорядочивание бэклога — не совсем церемония, но примерно 10% времени, которые команда во время спринта тратит на упорядочивание бэклога: разбиение, объяснение, поиск пробелов, формулирование определения «завершённости» и совместную расстановку приоритетов задач.
▍ Люди
Это отдельные личности или группы, определённые в Scrum:
- Стейкхолдеры — это заинтересованные лица, они хотят быть информированными, участвующими, они получают прибыль от продукта, чем бы ни был «продукт» в вашей компании. Да, при желании определение «продукта» можно растянуть на что угодно. Это могут быть конечные пользователи, другие команды и даже другие бизнесы.
- Владелец продукта должен использоваться в качестве моста между стейкхолдерами и разработчиками продукта, преобразующего требования в предпринимаемые действия; он должен понимать бизнес с точки зрения предметной области и целей бизнеса, управлять бэклогом и максимизировать получаемые результаты.
- Разработчики должны быть людьми, автономно отвечающими за операционные задачи, включая, но не ограничиваясь разработкой ПО, способными принимать технические решения, двигающие продукт в верном направлении.
- Scrum-мастер должен упрощать коммуникацию, отслеживать прогресс, выявлять и оценивать риски, проводить обучение и коучинг scrum самоуправляющейся команды, чтобы делать её эффективной.
Scrum поломан
Постойте-ка. То есть эти церемонии и должности настолько сложны, что для них необходим сертифицированный или профессиональный Scram-мастер? О, наивное дитя. Если вкратце, то очевидный ответ: нет. Хотите знать, почему?
Мы не живём в идеальном мире, где теория воплощается так, как написано в книгах.
По по выделенным в предыдущих абзацах фразам уже можно догадаться, что на практике реально происходит следующее:
Планирование, вне зависимости от инструментария, занимает кучу времени, и в результате вы получаете заранее установленные задачи, измеряемые в сторипоинтах. Эти поинты, которые должны помочь в понимании сложности конкретной задачи, вместо этого используются для измерения времени.
Отлично, Шерлок!
Ваша команда теперь сосредоточена на том, чтобы занять время, заполняя свой график вместо того, чтобы выпускать фичи, а вы даже не можете измерить её скорость.
Скорость (velocity) должна быть полезной метрикой, получаемой на основании предыдущих спринтов. Это должна быть относительная величина прогресса продукта, которую может обеспечить ваша команда.
Ладно, а почему мы не используем ряд Фибоначчи? И как насчёт покера планирования? Постойте, не торопитесь увольняться. Гарантирую, у меня есть оптимальное решение! Для упрощения оценки задачи можно просто назначать каждой из них размер одежды. Прекрасная идея.
Нам просто нужно обсудить, присвоить ли gRPC API размер задачи L или M, а единственным мерилом L будет время, которое мы потеряли на подборе способа непродуктивного измерения в миллиметрах.
Представим возможную ситуацию: ни владельца продукта, ни Scrum-мастера нет в офисе. Один на больничном, второй в отпуске. Будет ли ваша команда продолжать участвовать в ежедневных совещаниях? Сомневаюсь.
Что? Вы установили каждому собственную скорость как цель, которую нужно достигать в каждом спринте? Будьте готовы к отстойному коду и неполному, но автоматизированному тестированию.
Как только вы установите статическую метрику, люди рано или поздно адаптируются к тому, чтобы её обходить. А, да, и попрощайтесь с парным программированием и совместной работой, все слишком заняты зарабатыванием драгоценных сторипоинтов.
Задача слишком сложна, её нельзя разбить на части, она требует подробного анализа, в котором должны участвовать несколько команд в течение пары дней?
Никто не назначит себе эту задачу, потому что люди боятся обвинений и того, что будут выглядеть непродуктивными.
Думаете о составлении тикетов на каждую десятиминутную задачу наподобие форматирования файла, обновления URL и удаления неиспользуемых импортов? Добро пожаловать в ticket-driven development, где даже расхламление занимает кучу времени.
Пример достаточно частого случая: во время спринта кто-то нашёл баг.
«Хьюстон, у нас проблема, давайте обсудим её… с кем?»
С руководителем команды?
Со Scrum-мастером?
С техлидом?
С владельцем продукта?
С владельцем/менеджером сервиса? Да, у нас когда-то был PM в Scrum-команде, не спрашивайте, почему, это вполне реально и у меня есть доказательства.
Какое раздробленное руководство мы получили! Его слишком много для «автономной команды», не так ли?
Представьте, что вы согласовали со всеми этими людьми вашу проблему. Теперь представьте, сколько времени понадобится им для выяснения их части ответственности и нахождения решения.
Удачи, увидимся на следующем спринте!
Часто руководство считает Scrum эликсиром продуктивности и лекарством для любой недостаточно производительной команды, но в реальности всё почти наоборот.
Scrum не решает проблем с производительностью команд.
Медленная команда может стать ещё медленнее, и поверьте мне, вам будет больно смотреть на диаграмму сгорания задач.
Есть ли способ заставить Scrum работать?
Я думаю, что он есть, но никогда не видел ни одного инженера, довольного реализацией Scrum в его компании.
Бинго.
Способ работы должен определяться на уровне команды её участниками, а не компанией.
Пророчество Agile наконец исполнилось!
- Время между поставками по проекту наконец-то становится малым и гибким! Нет необходимости называть его «спринтом» и превращать в постоянную гонку со временем. Качество создаваемого ПО существенно вырастет, потому что изменение масштаба свободно от ограничений жёстко заданных промежутков времени.
- Оценки выполняются так, как и должны: интуитивно и на основании предыдущего опыта, подтверждённого на уровне команды. В разработке ПО больше, чем во всех других отраслях, время должно считаться относительной величиной.
- Наряду с руководством в планировании должны участвовать люди, исполняющие запланированное, чтобы они могли обсудить это и найти изъяны, чтобы осталось время устранить их без стресса. Работу берёт на себя каждый отдельный участник, она не назначается руководителем/менеджером.
- Исполнение даёт ощущение влияния. У каждого разработчика в зависимости от его опыта должна быть определённая степень технической свободы и ощущение ответственности по отношению к продукту, коллегам и стейкхолдерам. Это снижает зависимости, делает команду разработки более независимой и более быстрой. Ежедневные обновления наконец-то отражают статус баг-трекера, информационных потоков и документации.
- Ежедневно назначаемые задачи коротки и дают реальную информацию о выполняемой работе. Никто не ощущает потребности заполнять свой список дел мелкими задачами или лгать о том, что он отстаёт или опережает график.
- Блокирующие проблемы устраняются внутри команды, всей командой, без необходимости взаимодействия с многоуровневым руководством и взятием на себя ответственности за каждое решение, каким бы ни был результат.
- О результатах сообщают с полной прозрачностью и действительно показывают статус даже самым сложным стейкхолдерам (обычно «самым важным» клиентам). Цель — получить реальную обратную связь, а не поглаживания по голове.
- Проверка выполненного выполняется честно и без обвинений, чтобы люди перестали манипулировать данными с целью создать впечатление, что они неплохо справляются, и вместо этого сосредоточились на устранении первопричин проблем.
- Бэклог наконец становится общей ответственностью и непрерывным процессом. Вы будете поражены эффектом этого простого (но нетривиального пункта).
Исправление
- Отнеситесь к ретроспективному совещанию серьёзно, как к моменту рефлексии с чистым разумом над тем, что оказалось хорошей стратегией, о том, как итеративно над ней работать, и как к времени благодарности команде за проделанную работу. Да, разумеется, вам также понадобится подумать, что прошло не так, почему и как это улучшить.
- Вместо обратной связи спрашивайте советов о том, как улучшить работу. Люди любят давать советы (иногда непрошенные, но это уже другая история), это помогает избежать «пустой» обратной связи и ответов «всё хорошо» или «всё плохо»; при получении хорошего совета его можно сразу применить, просьба о совете заставляет человека почувствовать себя более заслуживающим доверия, чем при просьбе о «простой» обратной связи.
- Доверяйте команде, будьте честными и перестаньте пытаться заниматься её микроменеджментом. Старайтесь больше делегировать и быть гибким, вы увидите, что предоставление свободы приводит к созданию более здоровой среды, в которой легче учиться быть ответственными, даже когда руководство не смотрит.
- Помните, что метрики иногда лгут, если вы не относитесь к ним критично, не впадайте в привычную склонность подтверждения своей точки зрения. Подходящее время для одной из моих самых любимых цитат: «если мучать данные достаточно долго, они признаются в чём угодно», — Рональд Коуз.
-
Мотивируйте не бояться ошибок, признавайте их и устраняйте их без страха результатов анализа производительности. Перестаньте рассматривать под микроскопом все ошибки, сделанные разработчиками в предыдущем спринте, это только снизит их производительность и создаст токсичную рабочую среду.
Нужно изучать ошибку, но не человека. Видите, что у разработчика возникли проблемы? Попробуйте расспросить, как у него дела, дайте ему передохнуть, и посмотрите на результаты в следующей итерации.
Знаю, что некоторые из вас подумают, что сказанное мной — это чушь.
Если вы напишете гневный комментарий, то я не буду вас винить.
Давайте теперь снова прочитаем манифест:
Люди и взаимодействия важнее процессов и инструментов
Работающее ПО важнее исчерпывающей документации
Совместная работа с клиентом важнее обсуждения контракта
Реагирование на изменения важнее следования плану
На этот раз вы не можете сказать, что заголовок был кликбейтом:
Scrum действительно ужасен.
Если только не сделать его Agile.
То есть гибким, адаптирующимся, совместным, подстроенным под людей и сосредоточенным на результатах, а не на метриках.
Узнавайте о новых акциях и промокодах первыми из нашего Telegram-канала ????
Комментарии (124)
Batalmv
08.11.2023 13:40+9Если чесно, я прочитал, но не понял - так о чем собственно? Просто способ подтолкнуть перечитать манифест?
Согласитесь, эти методики уже довольно таки описаны и работают. Я думаю, многие программисты 30- лет вообще могли ни разу не видет большого ТЗ.
Середина статьи про какой-то "мифический" баг, который создал ситуацию, описанную картинку з кучей людей-пауков я вообще не понял
-------------
Если мысль в том, что кто-то делает что-то не так и получает, к примеру, кашу в Jira - так блин, это не зависит от методологии вообще. Проблемы с ДНК методологией не исправишь, разве что найдя его носителю правильное место (часто "на улице")
------------
У меня есть ощущения, что по Scrum Guide я никогда не работал. Даже не потому что, лень его читать (он короткий ... как минимум тогда, когда я его читал), а потому, что действительно команад всегда выбирает как именно удобнее работать, так или иначе. Да, удобно брать оттуда термины, но следовать слепо ...
DMGarikk
08.11.2023 13:40-1Середина статьи про какой-то "мифический" баг, который создал ситуацию,
описанную картинку з кучей людей-пауков я вообще не понялой, а мне это очень знакомо, я реально нашел баг в архитектуре в процессе спринта, который я не мог решить самостоятельно (и вообще это аффектило сильно больше компетенций чем было в команде и затрагивало другие департаменты), все до кого я дотягивался говорили что это не их дело и не их занятие, причем как я заметил по коду мои предшественники тупо копипастили код обходя его, судя по всему натыкаясь на это перекидывание ответственности и не желание его решать никем из формального руководства (у них же тоже спринт, а не ерунда какаято...за это джон отвечает...а джон на майкла перекидывает и т.п.)
я в итоге сам его экскалировал сильно выше и только так ситуация с таким кругом решилась...но это было явно не по аджайлу
Batalmv
08.11.2023 13:40+1Ну, нельзя же так. Agile/Scrum не универсальное средство от всех проблем :)
Некоторые постарше еще помнят откуда фраза " ... к пуговицам претензии есть?" или "грузите апельсины бочками. Не может короткое руководство решить все в жизни вопросы.
Метолология - это просто некий способ как делать вещи правильно. Но точно также вы можете строго по методологии делать их неправильно :)
AlexeichD
08.11.2023 13:40Прописные истины... В чем сложность организовать работу людей (если ты их сам подобрал и сам мотивируешь), я не понимаю. Придумывают всякие аджайлы со скрамами. А потом на собеседованиях - что такое спринт знаешь? Нет? Пошел вон.... Так и живем......
lair
08.11.2023 13:40+9В чем сложность организовать работу людей (если ты их сам подобрал и сам мотивируешь), я не понимаю.
Если вы не понимаете сложности, это еще не значит, что ее нет. Даже если предположить, что организованные вами люди работают хорошо, это все равно не добавляет понимания, как другим людям организовать работу хорошо. Методологии нужны именно для того, чтобы распространить опыт одних людей - другим.
AlexeichD
08.11.2023 13:40+9да ой же ты. Я за 30 лет трудового стажа изучил порядка 10ти методик по организации производств, логистики и менеджмента. Включая триллиард способов управления коллективами. Все это фигня и не имеет отношение к каким-то настоящим сложностям вроде применения симплекс-метода для оптимизации логистических процессов, ну да ладно. Сдаю поляну:
будь личным примером для каждого
вникай в работу каждого, старайся сделать так, чтобы теоретически хотя бы ты мог стать за станок вместо любого сотрудника
будь ресурсом, решай проблемы людей. Человек пришел с проблемой - это для тебя приоритет номер 0, а не рисование непонятно чего на скрам доске
будь строг, но справедлив. Не заводи любимчиков не поощряй лень и склоки
веди отчетность, планируй, размечай, снимай контрольные точки. На каждом производственном этапе это твоя зона ответственности, и ни один скрам менеджер с сертификатом вместо тебя это не сделает. Занимаешься логистикой - веди в экселе табличку с номерами фур ФИО водителей и расстояниями. Для себя. Тупо чтобы в голове отразились все нужные тебе моменты. Это будет работать без всяких спринтов. Впрочем, можно назвать это спринтом, сойдешь за умного))
проводи совещания, но не злоупотребляй, держи середину. К каждому совещанию - актуальная повестка разосланная заранее всем участникам. Требуй приходить с предложениями и ответами по повестке. Не отклоняйся от повестки, не допускай базара. Сделай совещания как молитву - регулярными, я делал в понедельник в 10 и в пятницу в 16. Строго, без исключений. В понедельник - план на неделю, в пятницу - статус по плану и обратная связь. Чтобы в выходные подумали и подготовились морально к понедельнику
ЗЫ не благодарите....
MiraclePtr
08.11.2023 13:40+2Но все эти скрамы и аджайлы - это совсем не про то. Это не про "нужно делать правильно, а неправильно не делай" в общем и абстрактном, типа как вы написали.
Всякие гибкие методологии определяют и предписывают, как и что должно работать "внутри", по факту решают "наружнюю" проблему - оценки сложности, планирование работы и взаимодействие с заказчиками. И именно вля процессов разработки софта с учетом их специфики. Не знаю, как у вас с логистике, а в разработке ПО над проблемами оценки сложности и планирования бьются умы уже не первый десяток лет. Да и с заказчиками все не так уж и просто.
vvbob
08.11.2023 13:40+1И по факту вся эта каргокультовая хрень, проблемы планирования никак и не решает.
Приходит заказчик - мне надо запилить вот такой вот проект, сколько денег и времени мне это будет стоить? Что ему ответят? Мы прогрессивная команда, у нас есть Аджайл-коучи, модный офис с кофемашиной, мы умеем митинговать по утрам, проводить спринты и демо в конце, а потом зажигаем на ретро, мы можем работать с вашим проектом (подразумевается что мы будем с ним работать многие годы, пока нам не перестанут за это платить)
MonkAlex
08.11.2023 13:40+2Опытная команда разберёт задачу, задаст все уточняющие вопросы, оценит в стори-пойнтах, возьмет какой-то фокус фактор свой и выдаст оценку.
vvbob
08.11.2023 13:40+1и выдаст оценку в сторипоинтах.. ну офигеть, скажет заказчик..
MonkAlex
08.11.2023 13:40+1И если это не первая такая задача у команды, то они вполне смогу сказать сколько и чего выйдет по деньгам и по времени, учитывая свои оценки в СП, свой фокус-фактор и свой прошлый опыт.
Оценка в СП поможет сравнить разные компоненты\элементы поставленной задачи и заказчик сможет выкинуть ненужные ему вещи, если выйдет дорого.
ПС: как вашу постановку задачи решает любой другой процесс?
vvbob
08.11.2023 13:40Вот я заказчик, я пришел и спросил, сколько это будет в деньгах и времени, мне говорят - 3000 сторипоинтов. И что мне с этим делать? 500 сторипонитов стоит часть проекта, и что дальше то? У меня есть бюджет проекта, есть время, которое я готов на него потратить, и нафига мне эти ваши сторипоинты?
Сами аджайл-сектанты очень много рассказывают о том, что сторипоинты это не про время, а тут вдруг - уже про время иденьги?Изначальный посыл был про то. что Аджайл - это про планирование работы, я аргументировал что это не так, при чем тут другие процессы?
Но и так-то, по моему мнению тот-же водопад даст более-мене адекватную оценку. хотя-бы по причине того, что он подразумевает создание достаточно детального ТЗ, перед выдачей этой самой оценки. Да, там может быть будут какие-то неточности, но это все равно лучше чем - "мы тут помитинговали, и решили что это все обойдется в 100500 сторипоинтов".
MonkAlex
08.11.2023 13:40+1У меня ощущение, что вы не работали по аджайловским фреймворкам.
Когда я как участник команды говорю "это будет стоить 4сп", я в целом подразумеваю, что это около 4 часов. Да, на деле это займет какие-нибудь 10, но поэтому у нас есть всякие доп вещи типа фокус-фактора и чота там ещё, я не очень хорош в теории.
Итого, если мы фичу оценили в 3к сторипойнтов, то я могу на основе своих допущений (мой сп = 2 часа) сказать что потребуется порядка 6к часов.
Опять таки, вы говорите про ТЗ - но я же написал о том, что нужно будет позадавать вопросы, чтобы оценить детально. Никто не выдает из головы оценку в 3к сп, это будут десятки и сотни подзадач в фиче, которые будут оценены в более-менее понятные блоки. И вот эти блоки в сумме примерную картину дадут. Как вы в водопаде примерно скажете сколько стоит реализация ТЗ, так и в аджайле вы примерно скажете, сколько стоит реализация.
SergioT4
08.11.2023 13:40мой сп = 2 часа
Так по заветам отцов
Each story point is assigned a number from the Fibonacci scale.
Как может сп быть 2часа? 10сп по сравнению с 9сп будет чуть не в два раза больше.
MonkAlex
08.11.2023 13:40+1Да, идея СП - отвязаться от времени.
В реальности опытная команда знает как одно с другим у них связано.
SergioT4
08.11.2023 13:40Ну вы пишите
У меня ощущение, что вы не работали по аджайловским фреймворкам.
А потом начинаете арифметические выражения типа 3к сп * 2ч = 6кч
Это как бы звоночек.
Тем более что нечто большее 20 сп, уже в реальности не используется, уже эпик получается, а не стори.
MonkAlex
08.11.2023 13:40+1А почему так получается то? Потому что непредсказуемая фигня =)
Я видел десятки проектов на водопаде, из которых один или два только угадали со сроками.
И видел десятки на аджайле, которые тоже приходилось резать на ходу, лишь бы успеть.
Поэтому у аджайла и есть отмазка - мы не даем оценку по времени.
Но в реальности, команда способна оценить средней степени фичи (в месяц-два-три в целом можно).
vvbob
08.11.2023 13:40+1Это все субъективщина, как и с водопадом, как и с любой другой оценкой, Аджайл тут ни разу не помогает оценить задачу адекватнее. Что вам помешает в рамках водопада разбить ТЗ на более мелкие подзадачи и оценить их в любых попугаях которые потом можно перевести в часы? Точность при этом будет не лучше и не хуже чем в Аджайле.
vvbob
08.11.2023 13:40Я работал, с тем что называли аджайлом. было оно этим или нет, я ХЗ в душе.. Вот вы пишите что вы там что-то подразумеваете, это круто, да, но пардон, ваши эти подразумевания к делу не подошьешь. Вашего менеджера спрашивают вполне конкретно - сколько времени и денег, и в качестве ответа сторипоинты какие-то там не приниаются.
Впрочем, я не первый год в деле, знаю как оно все делается, заказчику менеджер выдаст что-то что по его понятиям является конвертацией выданных командой сторипоинтов в часы.. как правило он не угадывает.
MonkAlex
08.11.2023 13:40+1Ну, аджайл и не заявляет, что помогает с такой постановкой задачи. В целом, аджайл куда-то в сторону "мы будем делать то что вам нравится до тех пор, пока вы готовы платить". Т.е. если вам нужен продукт через полгода и за какую-то сумму, то мы полгода готовы поработать (от суммы зависит количество разработчиков) -- а сколько мы успеем сделать, попытаемся оценить. Мы дадим заказчику возможность смотреть на результаты часто и дадим возможность менять мнение тоже часто.
Водопад гарантий не даст тоже, но и результат выдаст скорее в конце (если адепты не готовы к нескольким "релизам" в эти полгода).
ПС: да, все в итоге гадают. Опытные команды\менеджеры просто лучше угадывают =)
vvbob
08.11.2023 13:40Водопад не то что-бы гарантирует, но с ним вероятность выше, что к определенной дате, заказчик получит определенный функционал за оговоренные деньги. Да, там есть масса оговорок и проблем, но часто все-таки такая определенность лучше чем какая-та мутная "ориентированность на процессы".
А Аджайл это да, это про то что заказчик будет платить и
каятьсяплатить пока у него не кончатся деньги.
MonkAlex
08.11.2023 13:40+1Аджайл на это обычно аргументирует "но то, что получит заказчик, не обязательно будет тем, что он хотел". В коротких спринтах одна из главных идей - показать заказчику и получить от него обратную связь - то не то делаем, так он это видел или нет. И если мы делаем фигню - мы быстрее об этом узнаем, скорректируем результат оперативно. В водопаде у нас такой возможности нет.
И отдельный момент с тем, что вам нужно ТЗ в случае с водопадом. Это ТЗ потом должны посмотреть разработчики и оценить. И это тоже магия - потому что нет ни у аналитиков, ни у разработчиков, ни у тестировщиков, ни у кого нет гарантий, что они это сделают именно так и в указанные сроки. Опытная команда даст лучше оценку, но это же касается аджайловских команд =)
vvbob
08.11.2023 13:40Как по мне, это как раз одна из причин засилия довольно дерьмового софта. Заказчик ни на старте, ни в процессе работы сам не понимает что ему надо, а команда работает в режиме "чего изволите", по десять раз переделывая одно и то-же, хороня проект под дендро-фекальными наслоениями. Аджайл поощряет такое раздолбайство по факту, при котором огромные средства сливаются в унитаз, а виноватых в этом вроде как и нет хотя можно было-бы существенно сэкономить, просто разобравшись в задачах, и спроектировав все более-менее адекватно.
Да и водопад это тоже не догма, можно ведь и проектировать в несколько этапов, согласовывая каждый со всеми участниками, можно делать нефункциональные прототипы, много чего можно сделать.
UserAd
08.11.2023 13:40+1А если мы все так при оценке расписали и оценили разве мы не получили весь цикл планирования водопада?
MonkAlex
08.11.2023 13:40+1Получили. Хороший водопад и хороший аджайл в целом не отличаются. Просто у аджайла рекомендации про спринты в 2 недели, а водопад обычно имеет цикл больше.
Да, у всех будут свои реализации обоих этих процессов (т.е. каждая организация немного по своему будет делать), но принципиальной разницы я, как участник процесса, не замечал.
uzverkms
08.11.2023 13:40+3Если мы говорим про аджайл-подход, то это автоматически ведёт всех нас к контрактам Time & materials. Потому что с аджайлом подписываться под Fixed price с его фиксированным содержанием и временем - ну такое. Честный ответ будет такой:
Пока работы не начаты - сложно сказать, сколько это займёт времени. Только очень примерно.
После пары спринтов уже реально делать прогноз по времени, но это будет не дата, а диапазон.
Соответственно, заказчик должен определиться с ограничением: бюджет, время или содержание. Один из этих трёх параметров будет не фиксированный.
Конечно если речь не идёт про условно типовой сайт с не сильно большой кастомизацией под желания и процессы заказчика. Там можно наловчиться и на Fixed price. Просто закладывать риски неопределённости в сроки и цену.
MiraclePtr
08.11.2023 13:40Вот именно что решает. Да, это не серебряная пуля - не абсолютно везде и не абсолютно всегда, но тем не менее.
Я здесь уже как-то давно рассказывал историю, как больше десятка лет назад мы занимались промышленной автоматизацией - создавали и интегрировали программно-аппаратные комплексы для нефтепромыслов больших нефтяных компаний. Там не смузи и офис с пуфиками, там суровые мужики в спецовках и касках, нефть и трубы. И мы в нашей провинции, когда ещё даже слова такого как "аджайл" никто не знал, в итоге методом проб и ошибок сами пришли к процессам очень похожим на эти самые гибкие методологии (со спринтами, демками, и особенно 3 и 4 пунктом agile manifesto, о котором мы тогда даже и не слыхали), и это было действительно очень хорошо и для нас, и для заказчиков, и заказчики (коих было несколько) нашей работой были довольны больше, чем тем, что делали конкуренты.
vvbob
08.11.2023 13:40Да я не против Аджайла в принципе. Я против внедрения этого всего через менеджмент, когда оно навязывается команде силой, а сейчас оно в 95% случаев так и происходит. Когда к этому всему пришли естественным путем, и команде хорошо так работать - это офигенно!
jk87eva
08.11.2023 13:40+2По сути, вы сейчас описали все то, что до людей пытался донести Джефф Сазерленд, создавая Scrum. А не то, что они захотели в нем увидеть.
vvbob
08.11.2023 13:40+1Жаль плюсануть не могу, карму слили опять не пойму за что, ну да ладно..
Согласен по всем пунктам, в таком окружении работать намного приятнее и эффективнее. Есть проблема - ты всегда знаешь к кому обратиться, никто тебя не дергает каждый день с отчетом, не надо на все эти "нытинги" убивать по несколько часов своего времени (да, эти "короткие" ежедневные совещания, чаще всего выглядят как часовая нудятина, на которой большая часть присутствующих пытается или поработать беспалевно или откровенно подремывает). Нет массы всех этих бессмысленных дурацких ритуалов , нет нервотрепки с постоянной нехваткой времени и попытками запилить фичу к бессмысленно, с потолка, поставленному дедлайну. Приходишь на работу, и просто работаешь, это ли не счастье?
lair
08.11.2023 13:40+1Сдаю поляну [...] веди отчетность, планируй, размечай, снимай контрольные точки
Плохая поляна. Смысл методологии в том, чтобы объяснить как планировать и так далее.
А так ваш ответ сводится к "чтобы управлять людьми управляй людьми".
(по остальным пунктам можно было бы аналогично пройтись, но не вижу смысла, а этот самый показательный)
AlexeichD
08.11.2023 13:40да вот нифига, это про то, как организовывать людей. Планирование вытекает из правильной организации всегда и собирается как бы по кусочкам. При правильной организации труда вам люди принесут на блюдечке готовый план, и задача скрам-мастера будет положить этот на бумагу, ну или на доску, как кому удобнее. Формат планирования в виде канбан доски - тоже не новый, к вашему сведению продавцы примерно так планируют свои сделки с клиентами, и у них это называется по другому (не вижу смысла описывать, извините), и применяется много где. Есть плюсы и минусы у этого формата, он не всегда подходит даже для простых мероприятий, не говоря уже о сложных.
Я вижу в ИТ индустрии определенные сложности именно в организации работ и в управлении людьми. Всем подавай "кулеры с печенками". А следуя данной "поляне" можно организовать практически любую работу, включая ИТ
lair
08.11.2023 13:40да вот нифига, это про то, как организовывать людей.
Что "это"?
При правильной организации труда вам люди принесут на блюдечке готовый план
Вы под "правильной организацией труда" понимаете "у меня есть человек, который мне принесет готовый план"? Потому что иначе у людей, занятых разной работой, не обязательно есть достаточно информации, чтобы составить сквозной план этой работы.
А следуя данной "поляне" можно организовать практически любую работу, включая ИТ
Проблема этой "поляны" - в отличие от методологии - в том, что ей нельзя научиться. Это набор "по понятиям".
Ну и да. Вы начали с "не понимаю, в чем сложность", а потом выдали набор пунктов, где первый же - сложен в реализации.
AlexeichD
08.11.2023 13:40SCRUM - это. Это методология управления проектами, а не методика планирования
Если вам сложно быть личным примером, тогда и руководить браться не стоит)))
lair
08.11.2023 13:40+1SCRUM - это. Это методология управления проектами, а не методика планирования
Обратите внимание, что я нигде конкретно про скрам не писал. Я писал про отличие методологии (не важно какой) от "управлять людьми легко, вот я делаю так и так, делайте так же".
Если вам сложно быть личным примером, тогда и руководить браться не стоит)))
То есть все-таки в том, чтобы организовать работу людей, есть сложность?..
AlexeichD
08.11.2023 13:40То есть все-таки в том, чтобы организовать работу людей, есть сложность?..
^^^ ну не знаю, кому-то и с дивана встать сложность))
lair
08.11.2023 13:40+2Вот поэтому и не понимаете, в чем сложность.
Это вообще нормально, люди часто не понимают, почему другим сложно, и нужно учиться, чтобы сделать что-то, что им самим дается легко и непринужденно.
ruslan_sverchkov
08.11.2023 13:40+1Вероятно дело в том, что на складе требования не меняются по два раза в день, и если заказчик просит доставить холодильники, то он после этого не удивляется, что вы привезли холодильники а не космолеты) Просто в IT другие риски, для борьбы с этими рисками и придумывают всякие гибкие методологии, которые на деле сводятся к "мы не знаем, куда можно наступать, а где мины лежат, поэтому будем двигаться мелкими шажками и постоянно рефлексировать над полученным опытом". As simple as that. Внедрение этих методологий людьми, не понимающими, как они работают и почему, часто превращается в карго-культ, чем вызывает ненависть рядового персонала и гневные посты в интернетах)
kost_tr
08.11.2023 13:40Зачем?
Зачем при всеобщей гонке и конкуренции учить людей методологии:), эффективной методологии
Тут как в старом анекдоте про врачей, отец и сын
Сын приходит к отцу и говорит, я вылечил пациента, которого ты лечил 20 лет
Отец отвечает: Он нас кормил
Но самое интересное большинство и учится не хочет:) Можно же просто выучить слова, повторять их и иметь профит
lair
08.11.2023 13:40Зачем при всеобщей гонке и конкуренции учить людей методологии
Например, чтобы сохранить конкурентоспособность на рынке.
MiraclePtr
08.11.2023 13:40+6В чем сложность организовать работу людей (если ты их сам подобрал и сам мотивируешь), я не понимаю.
Я тоже не понимал, пока сам не стал техлидом и не начал участвовать в организации работы... :)
PuerteMuerte
08.11.2023 13:40+5В чем сложность организовать работу людей (если ты их сам подобрал и сам мотивируешь), я не понимаю
Хехе. Первый считает второго м...аком из-за политических взглядов. Второй на всех обиженный, что они не разделяют его политические взгляды. Третий достал четвёртую своими шуточками. Первый и второй задалбывают третьего переписыванием документации, потому что она им не нравится (она и правда хреновая, да). Четвёртая ссорится с пятой, потому что пятая считает себя более профессиональной на проекте. Шестой позитивный, все его любят, кроме второго, потому что шестой не разделяет его политические взгляды и т.д. Действительно, в чём сложность организовать работу команды живых людей? :)
beduin01
08.11.2023 13:40-2Первый считает второго м...аком из-за политических взглядов...
Аджаил тут вообще мертвому припарка. На выходе вместо продукта. Будет кусок говна с вероятностью в 100%
olku
08.11.2023 13:40+9Agile противоположен каскадной модели
Это как посмотреть. Отчетная единица в каскаде - все задачи. В скрам - пакеты задач "спринты". В канбан - 1 задача. Суть выбора в требуемой атомарности, остальное бантики.
MonkAlex
08.11.2023 13:40+13На самом деле аджайл - это очень маленький водопад, потому что вам нужно всё то же самое, но часто.
Поэтому противоположен - неправда. И это ещё один минус автору текста.
olku
08.11.2023 13:40+3Именно. Но адепты не признаются, водопадо-мастерами быть невыгодно.
MonkAlex
08.11.2023 13:40Я работал с парой сертифицированных скрам-мастеров и ещё от пары слышал про сами курсы сертификации.
В целом я хз, кто занимается этой работой в водопаде - это куча менеджерской работы, вида "провести встречу, остановить спор уходящий в сторону от темы обсуждения, назначить (и провести) встречу с соседней командой, всяческие ретро". Кто-то эту работу делать должен, а как его назвать - мне лично не жалко, пусть будет скрам-мастер.
Проблема в том, что при частых итерациях у вас коммуникаций в целом становится больше, чаще и они должны быть оперативными и короткими. И вроде как за все эти коммуникации (как внешние так и внутренние) в итоге "отвечает" скрам-мастер. Мне роль не до конца понятна =)
SergioT4
08.11.2023 13:40+1И вроде как за все эти коммуникации (как внешние так и внутренние) в итоге "отвечает" скрам-мастер. Мне роль не до конца понятна
Скрам-мастер это фаллоситейтор. Он не должен ничего сам делать, он должен убирать пробелмы с вашего пути, которые вам мешают что-то сделать.
iggr63
08.11.2023 13:40+4Лучше наверно писать "фасилитейтор", а то как-то обидно для скрам-мастера получается:)
ainoneko
08.11.2023 13:40Возможно это отсылка к картинке с "ожидание vs реальность", где главный герой в "ожидании" пинает фаллосы, а в "реальности" -- более мелких героев, которые пинают фаллосы и ещё более мелких героев?
MonkAlex
08.11.2023 13:40+1не должен ничего сам делать
Ну это тоже криво звучит. Не должен ничего делать, но убирать проблемы как-то надо, не магия же это =)
SergioT4
08.11.2023 13:40Ну например если для проекта нужен сервер, скрам мастер не установит этот сервер. Он напишет твоему руководителю - закантачь с людьми которые руководят теми кто устанавливает сервера.
Так что надо понимать уровень решения проблемы, она не решается, а создаётся движуха.
Уровень знаний срам-мастера не обязательно подразумевает знания чего-то кроме самого скрама.
Как в примере с сервером, подразумевается что возможные решения будут озвучены командой, а Мастер выберет то которое можно решить через коммуникации.
WASD1
08.11.2023 13:40Мне кажется это называется "реактивный" с точки зрения задач проекта.
SergioT4
08.11.2023 13:40+2Это ещё создатели курсов срам-мастеров не адаптировали появление новых технологий.
Тот же чатгпт даёт в рука мастера ядерное оружие. Т.е. убедительно звучащие тексты, генерируемые со скоростью десяток за минуту.
Плюс неодоценненая возможность анализировать входищий поток - емайлы, транскрипты митингов и т.п.
В скрам-мастера и раньше шли те кто не умел или не хотел работать, но обладал пресловутыми софт-скилами (т.е. без вазелина в ... залезет), то сейчас будет гремучая смесь - своё непонимание, смогут прикрыть псевотекстами помноженное на софтумения. Держите меня сто человек.
OlegUV
08.11.2023 13:40может быть водопадом, а может и просто набором задач без зависимостей, и это удобно
Areso
08.11.2023 13:40+1Аджайл противоположен водопаду не потому, что оно большое или маленькое, а потому, что только в аджайле можно сделать фигню (да и описание может быть такой же фигней в 1 строчку), и переделать её в следующем спринте, потому что "общение и гибкость дороже договоренностей" (вольная цитата из манифеста); водопад же - это про конечность и финальность сделки с момента подписания ТЗ.
Поэтому задача ставится точно, деливерится точно, как описана, принимается точно, как описана, и никому не важно, несёт ли она к концу этого бизнес-ценность или нет.
Поэтому для водопада, даже мельчайшая задача ставится с макетами, описаниями, формулами и всем необходимым.MonkAlex
08.11.2023 13:40Не соглашусь. Делать фигню можно и там и там.
Люди и на водопаде уточняют требования, показывают промежуточные результаты заказчику и прочее-прочее. Да, при стабильных задачах можно этим пренебречь (пришла вам задача вида "с 1 января меняется формат взаимодействия с партнёром на такой то" -- никакой скрам вам не нужен, делайте водопадом спокойно), проблема больше в том, что бизнес теперь хочет быстро результаты. И вот ровно тот же водопад втиснутый в 2-недели спринта даст ровно те же результаты, что и аджайл.
MonkAlex
08.11.2023 13:40+2Не стал дочитывать. Если вы убегаете от "церемоний" и вместо работы оптимизируете уход от работы -- вам никакой способ работы не поможет, ни ватерфолл, ни аджайл, ни какой-нибудь лесс или что там ещё существует.
eldog
08.11.2023 13:40+17Работал в проектах с лютым скрамом и это напоминало собрания по продаже гербалайфа. В гербалайфе и вообще mlm рассказ про продаваемый продукт занимает 5% времени, рассказ о том, как его продавать - 95%. Так и в скраме церемонии становились важнее того, что, собственно, делаем.
FreeNickname
08.11.2023 13:40Так и в скраме церемонии становились важнее того, что, собственно, делаем.
Так это же первейший пункт Agile Manifesto! "Processes and tools over individuals and interactions"! \s
MonkAlex
08.11.2023 13:40+1Есть один момент - именно у скрама в гайде написано, что если вы делаете что-то не по гайду, то у вас не скрам =)
Аджайл в целом более гибок, да.
bondeg
08.11.2023 13:40Так правильно написано, если вы не следуете методологии, то у вас не она. Всё ведь там просто и расжёвано. Бери и делай.
Обычно всё упирается в бизнес, который рушит процессы, иногда обоснованно, иногда нет. Либо в разработчиках которые сопротивляются изменениям. Хотя им-то зачастую надо радоваться, тебя на N дней не будут трогать, сиди себе да работай, кайф же.
В крупных компаниях под микросервисы это в целом хорошо ложится. В маленьких в принципе не должно быть проблем.
SSukharev
08.11.2023 13:40+6Любая методика в конце концов возводится в абсолют и становится постулатом веры. Реализация и водопада и аджайла по факту идёт плохо, криво и неумело, по шаблонам. А успех в IT достигается только там, где небольшая команда имеет полную самостоятельность и автономию в своих действиях а аджайл это будет или водопад совсем не важно.
Ivan22
08.11.2023 13:40прямо ПОЛНУЮ??? Без дедлайнов и с анлимитед бюджетом??? Это где такое существует???
SSukharev
08.11.2023 13:40Есть места, где нет менеджеров-идиотов, они предпочитают заниматься своим менеджментом, дедлайнами и бюджетом где то далеко не напрягая мозг подобной херней разработчикам
Ivan22
08.11.2023 13:40т.е. дедлайны живут где-то далеко, сами себе, а разработчики себе пилят, пофиг на сроки. Это в каком мире розовых пони??
SSukharev
08.11.2023 13:40Ну нет у нас дедлайнов, если у тебя есть, то ты живёшь а окружении идиотов, мнящих себя менеджерами, стратегами.
Ivan22
08.11.2023 13:40ну то что конкретно ты не в курсе про дедлайны, не значит что их нет. Они есть всегда, от самых маленьких стартапов у которых есть сроки и по финансированию и по опережению конкурентов, и до международных корпораций у которых все планы уже расписаны на 30 лет вперед
SashaVolushkova
08.11.2023 13:40+4Для меня scrum - это способ создать хорошее по с нулевой командой, которая даже никогда не работала в команде; с владельцем продукта, который никогда не был владельцем продукта. Вы можете слепо следовать инструкциям и у вас что-то получится. Чтоб получить хороший результат нужно следовать инструкциям обдуманно.
Как и любой "язык", scrum адаптируется под вас. Владелец продукта (возможно совместно с мастером и командой) шлифует книжные процессы и это нормально. И всегда будут ситуации, которые не встраиваются в идеальный процесс. И умение руководителей - это способность с этой ситуацией справиться. Если руководитель не имеет богатого опыта, то он будет работать по книжке и это нормально.
Оценка и "ритуал оценки" - это собрание на котором вы можете обратить внимание на отклонение. Если кто то задачи не может или дает очень большую оценку, то это сигнал как минимум поговорить о задаче. И на этом собрании команды вы можете задать вопросы, которые помогут вам с оценкой и улучшить качество постановки задачи. И оценки даются интуитивно, никто не запрещает так давать оценки задачам.
Про отсутствие скрам мастера или владельца продукта. Все в команде должны быть взаимозаменяемы. Это даже в манифесте прописано. Взаимозаменяемость среди тех специалистов полноценную я не встречала (очень ограничено), а вот роли между собой мы вполне могли менять.
Выбрать правильную методологию и адаптировать ее под свою команду - это задача руководителя. И да на некоторые проекты не ложится идеи scrum, некоторые должны работать по водопаду, а кто-то работает по Extreme programming (XP).
segment
08.11.2023 13:40Есть шанс, что если руководитель не имеет богатого опыта, то он вообще не будет работать по книжке. Сначала будет просто желание "давайте agile, это модно", а потом будет продолжать следовать своим собственным принципам.
tnc4401
08.11.2023 13:40+3Встречал только хорошие реализации Scrum - прозрачные процессы, команды самодостаточны и организованы, гарантированная доставка ценности, можно измерять производительность спринтов.
Бывает карго-культ, который скрамом не назовешь. Игры в planning poker и burndown-диаграммы. :))PuerteMuerte
08.11.2023 13:40+1Встречал только хорошие реализации Scrum - прозрачные процессы, команды самодостаточны и организованы, гарантированная доставка ценности, можно измерять производительность спринтов
Как правило, если у вас сложилась такая организация, вам и скрам-то не нужен :)
uzverkms
08.11.2023 13:40+4Любая статья про аджайл/скрам/что угодно гибкое начинается с Бабы Яги - ужасов каскадной модели, которую так же называют Waterfall. Каскадную модель описал Винстон Ройс в своей статье 1970 года как возможную на первый взгляд модель разработки, которая на самом деле НЕ существует и НЕ работает. Но продавцы
гербалайфаадажйла с тех пор используют "соломенное чучело" для более эффективной продажи своего подхода. Как-будто без этого аджайл ни кто не купит.
314159abc
08.11.2023 13:40+1В эпоху капитализма востребованность (и косвенно вытекающий из неё теоретически возможный заработок) всё-таки не измеряется единицами "кто-то" и "никто".
olku
08.11.2023 13:40Работал в разных конторах и с водопадом, скрамом, скрамбаном, и канбаном. И настоящим, и называемым таковым. Везде были свои причины, суть которых указал в комментарии выше. No two companies are alike.
shchepin
08.11.2023 13:40+1Scrum — это Agile-система управления проектами
Не правда. Фреймворк Scrum появился гораздо раньше, чем был задуман и опубликован Agile-манифест (в начале 90-х). Таким образом, Скрам никакого отношения к философии аджайл не имеет.
Agile итеративен
Строго говоря, аджайл-манифест не предписывает вообще никакого процесса (кроме короткой рекомендации отдавать ПО заказчику почаще). Но это лишь рекомендация, а их там больше десятка.
Scrum поломан
С основным посылом статьи согласен, но беда в том, что автор вообще ничего не сказал нового. Ну да, вода - мокрая, скрам - ужасен, жизнь - тлен.
Gorthauer87
08.11.2023 13:40+4Помню очень плохую историю с внедрением скрама, у нас митинги стали занимать половину рабочего времени, от чего все дико уставали и накапливалось раздражение, там все было как в скраме из статьи. Покер планирования, рубашки, длинные грумминги, ретро, созвоны с другими командами. Такое ощущение, что на нас пытались опробовать вообще все методики из скрама. Дошло даже до оценок сколько реального времени каждая задача заняла.
Как итог, треть команды уволилось, мне повезло, я догадался уйти в отпуск, а как вернулся из него, то этих скрам мастеров выгнали нафиг.
ratibordas
08.11.2023 13:40+3Никогда не понимал в чем у линейных разрабов проблема с митингами на пол спринта. Тебе дают кучу свободного времени, еще и платят за это. Сиди, решай литкод / играй в игры / работай на второй работе / ешь / любое действие рядом с компом. А если немного подумать, то можно четко определить, где тебе надо говорить / не надо говорить и просто такие созвоны принимать и уходить куда надо или вообще на телефон фоном просто присоединиться
piton_nsk
08.11.2023 13:40+1Если человек реально хочет делать дело, то такие бесконечные митинги вредят делу и раздражают. В этом и есть противоречие, с одной стороны хотят проактивного чела, который бизнес понимает, софт-скилами обладает, да и вообще горит желанием приносить пользу. С другой стороны такого человека начинают мариновать митингами, бюрократией и всякой прочей раздражающей фигней.
Это хорошо, если помитинговали, время на митинг списали и дальше работают в обычном режиме. А еще бывает когда требуют результат и сроки, а работать не дают. Митингами в том числе. Внедряют всякие мега методики, оптимизации, контроли, коучинг, личные цели, командные цели, план развития, контрольный лист исполнения контрольного листа и все такое прочее. Такое ведь тоже бывает.
ratibordas
08.11.2023 13:40+1Если человек хочет делать дело, то ему явно не в корпорат. Пожалуйста, есть стартапы, меньше созвонов / больше действий. Есть фриланс, совсем без созвонов. Есть свой бизнес, вообще как хочешь, так и делаешь. Не секрет, что в больших компаниях ( да и не очень больших, но уже и не стартапах) много созвонов и чем дальше, тем больше. В корпорате люди либо сидят тихо на зп, либо строят карьеру и тут правила игры какие есть, не хочешь быть говорящей / слушающей головой - не повысят.
Boethiah
08.11.2023 13:40Если найден баг, то его без проблем закидывают на программиста, который фиксит его в том же спринте в основном, переносы на другие спринты бывают, конечно. Не понятно откуда у сочинителя статьи взялась проблема с якобы перекладыванием ответственности за баги.
piton_nsk
08.11.2023 13:40+1который фиксит его в том же спринте
Откуда в спринте берется время на незапланированные задачи? Добавляете что-то в середине спринта, что-то надо выкинуть) Есть еще проблема что менеджеру/начальнику/заказчику понравится менять спринт на ходу. Типа починили же баг, вот есть срочная хотелка. Так что "без проблем" тут явно не обойтись.
AntoineLarine
08.11.2023 13:40+1Очередное подтверждение факта, что любую здравую идею можно превратить в УГ бестолковой реализацией.
inscriptios
08.11.2023 13:40+3Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.
Это в каком веке автор написал оригинальную статью? Смотреть нужно на https://scrumguides.org/index.html. А теперь настоящая цитата с отсылкой к источнику:
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Определение Scrum из Руководство по Scrum. Могу только лишний раз заметить, что не стоит слепо верить всему, что на Хабре пишут/переводят некоторые — все нужно перепроверять в источниках.
Церемонии
Scrum-команда должна следовать некоторым церемониям.
Примечание: мне никогда не нравился этот религиозный термин, используемый для описания подобных совещаний, но что уж есть.
А действительно, когда он это писал? 18 октября? Видимо, писал по памяти, а она, порой, как известно, подруга ненадежная) Нет там никаких церемоний, есть события (events). Ищем там же раздел События Scrum.
Ежедневные совещания — ежедневные КОРОТКИЕ совещания (примерно 15 минут), на которых маленькая команда разработчиков (примерно 3-7 человек) обсуждает свой прогресс и выделяет мешающие двигаться дальше проблемы, не вдаваясь в подробности. Это время, в которое можно попросить Алису устроить отдельное совещание о проблеме кэширования на стороне сервера и спросить Боба о том, почему параметр даты является строкой, а не временем Unix.
Ну и чушь (как автор просил называть ????) Вот такие товарищи сначала ничего не поняли, а потом вещают что это плохой способ работы) Знаете зачем Daily Scrum? Да, формально каждый должен ответить на три вопроса, однако спрашивать Боба о типах данных не нужно. Вы можете и обычно так и происходит, после Daily Scrum устроить любые беседы по обсуждению типов данных, но после. Daily Scrum — это не только апдейт для коллег и источник информации о проблемах для Scrum Master, это (о чем многие не догадываются) один из способов культивирования самоорганизующейся команды. Самоорганизующаяся команда — это одна из основ и часто вы должны задать себе вопрос: если команда не может сама организоваться и провести Daily Scrum так, как это ожидается, то как она вообще станет самоорганизующейся? У кого-то это сечас вызвало жуткий зуд)
Это отдельные личности или группы, определённые в Scrum:
Стейкхолдеры — это заинтересованные лица, они хотят быть информированными, участвующими, они получают прибыль от продукта, чем бы ни был «продукт» в вашей компании. Да, при желании определение «продукта» можно растянуть на что угодно. Это могут быть конечные пользователи, другие команды и даже другие бизнесы.
Теперь я точно уверен — да, автор изучал Scrum в прошлом веке) Нет там никаких стейкхолдеров, есть только три роли)
Планирование, вне зависимости от инструментария, занимает кучу времени, и в результате вы получаете заранее установленные задачи, измеряемые в сторипоинтах. Эти поинты, которые должны помочь в понимании сложности конкретной задачи, вместо этого используются для измерения времени.
Опять чушь) В сторипоинтах User Stories, а задачи, которые реализуют конкретную User Story — их скоуп определяется так, чтобы занимать не больше одного рабочего дня, то они, фактически, измеряются в длительности по времени, нет никаких сторипоинтов у задач)
Представим возможную ситуацию: ни владельца продукта, ни Scrum-мастера нет в офисе. Один на больничном, второй в отпуске. Будет ли ваша команда продолжать участвовать в ежедневных совещаниях? Сомневаюсь.
А теперь перечитайте выше — если команда не может сама организовать такое простое событие, как она будет вообще самоорганизовываться? Если никак, то потом и будут появляться такие авторы, которые несут эту чушь, скрывая свою ненависть за шуточными высказываниями.
MiraclePtr
08.11.2023 13:40+1Само понятие daily scrum вообще почти везде извращают полностью. А если заглянуть в определения и гайды, то там чуть ли не прямым текстом сказано: дейлики лучше иметь не длиннее 15 минут, содержимое и порядок дейликов определяется самими разработчиками (вплоть до того, что менеджеров на них может вообще не быть) и "The Scrum daily is not a status pull; if it is - you are not doing Scrum".
arTk_ev
08.11.2023 13:40Scrum - для производства, а не для разработки нового.
При разработке важна бесконечная итеративность, а результат всегда непрдсказуем.
starlet86
08.11.2023 13:40В agile/scrum я вижу очень значимый плюс - все, что не успели переносится в другую итерацию, и все счастливы. но увы у нас это не работает. А про нежелание брать сложные задачи - это особенность большинства людей, поэтому задачи надо раздавать в соответствии с должностями и умениями, мониторить прогресс и помогать, если надо. Как-то работала в команде с программистом, который, несмотря на приоритеты, сначала всегда фиксил лёгкие баги, а потом при приближении к релизу оставалась куча хороших багов, заассайненных на него, и их приходилось разгребать всем вместе в срочном порядке и с переработками. И ПМ эту ситуацию знал, даже устанавливал специально для него приоритеты, но программист особо не менял свое поведение, и где можно действовал по своей старой схеме. Поэтому мое мнение, какую бы хорошую методологию не придумали, какие бы классные не были ПМ, скрам-мастер, тим- и техлиды, все равно найдутся либо недовольные, либо пытающиеся как-то все это обойти люди. А про метрики эффективности - к сожалению большинство ПМов нормально их не анализируют, тут только в каждом случае разбираться, что не так. "Неэффективность" кстати и на мелких задачах может случаться часто, потому что недооценили или пропустили что-то, а человек вместо того, чтобы идти разбираться и заводить новую задачу, подумал "да ладно сейчас я быстро" и не получилось.
Algrinn
08.11.2023 13:40+4Персональная статистика проектов показала, что на проекте со Scrum-ом более низкий уровень здравого смысла, более высокий уровень какого-то бреда и более высокий уровень прогнивания фирмы. Наиболее здоровые проекты на мой взгляд, это проекты с диктатурой сильного и влиятельного Fullstack программиста архитектора. Которому хватает влияния и полномочий продвигать правильные решения и блокировать всякий бред.
azizoid
08.11.2023 13:40Особая удача, если этот диктатор футстек продвигает скрам и учит других брать на себя обязательства
inscriptios
08.11.2023 13:40Наиболее здоровые проекты на мой взгляд, это проекты с диктатурой сильного и влиятельного Fullstack программиста архитектора. Которому хватает влияния и полномочий продвигать правильные решения и блокировать всякий бред.
И причем тут вообще Scrum или его отсутствие?) А когда диктует один человек, то и решения получаются однобокие, один никогда не будет знать все и принимать идеальные решения, другое дело когда в Scrum Team три сеньора собрались и решили как сделать лучше и нафиг диктатуру.
piton_nsk
08.11.2023 13:40другое дело когда в Scrum Team три сеньора собрались и решили как сделать лучше и нафиг диктатуру
И не переругались между собой как именно сделать лучше.
inscriptios
08.11.2023 13:40И не переругались между собой как именно сделать лучше.
Взрослые и адекватные люди умеют договариваться, для остальных Scrum не подходит)
piton_nsk
08.11.2023 13:40+1Ага, взрослые и адекватные люди умеют договариваться, для остальных %whatewer% не подходит.
KarimAminov
08.11.2023 13:40Первый шаг к возможному улучшению - начать платить за результаты спринта.
Тогда и команда начнёт улучшаться самостоятельно, чтобы больше заработать, и помогать друг-другу будут и избавляться от слабых и токсичных, и процессы упрощать и т.д.
DMGarikk
08.11.2023 13:40+1ни в коем случае нельзя так делать
во первых согласование спринта затянется на недели
во вторых надо писать очень подробные пояснения почему мы не виноваты что прод упал после нашего спринта
в третьих менеджмент не глядя будет рубить эти премии по любому косяку...не разбираясь правомерно или нет
Тогда и команда начнёт улучшаться самостоятельно,
дада, давайте еще коллективную ответственность внесем, ведь то что вы предлагаете это и есть
10 человек пахали как лошади, а 11-й человек запорол спринт потому что простудился, все остались без денег. (добавить форсмажор в исключения? отлично, будет дежурный больной который каждый раз когда чтото не так будет болеть и спасать зарплату)
внезапно я в некотором роде это всё видел, правда не в ИТ, этому дежурному васе-стрелочнику все скидывались на премию которой его официально решали каждый раз за постоянные провалы (которые по договоренности на него вешали)
KarimAminov
08.11.2023 13:40Затянули согласование, значит делаем это не эффективно, не получаем денег. Думаем как улучшиться в следующем спринте.
Также уверен, что много адекватных топов или стейкхолдеров и косяк одного поймут и заплатят. Ну а 11ый ставится на карандаш. Косячит из спринта в спринт, когда сама его подтянет или заменит, т.к. не готова постоянно нести за него "коллективную ответственность"
На мой взгляд нужно исходить из основной цели - это заработать денег. Crum - это лишь один из инструментов (или фреймворков) как это сделать более эффективно команде разработки. Если вы его используете, чтобы наладить работу, а не заработать - вы его не правильно используете.
Команда важнее процессов и всё такое доброе - нужно правильно использовать, а не прикрываться этим.
DMGarikk
08.11.2023 13:40+2Затянули согласование, значит делаем это не эффективно, не получаем денег. Думаем как улучшиться в следующем спринте.
я тупо уволюсь и пойду туда где деньги платят за разработку, а не построение коммунизма, а вы там дальше играйте в саморегуляцию
Также уверен, что много адекватных топов или стейкхолдеров и косяк одного поймут и заплатят.
категорически не уверен, меня разок перевели в другой департамент только за то что я отправил таску на согласование в СБ потому что у меня было подозрение что она вызовет нарушение безопасности перс.данных, из-за чего просрочился спринт.
Ко мне пришел целый руководитель департамента с жалобой что у него срывается КПИ по релизам, а я крайний и вообще какого чёрта я творю (дырка в безопасности это другой департамент (куда я и пошел), а у него релизы..)... и меня перевели к другим.. это на секундочку забугорная известная крупная контора была
Если вы его используете, чтобы наладить работу, а не заработать - вы его не правильно используете.
я в компании работаю чтобы продукт создавать который компании приносит денег, а не чтобы команда где я работаю и я сам заработали денег. Это вещи не связанные друг с другом иногда вообще
Команда важнее процессов и всё такое доброе - нужно правильно использовать
Это мантра для HR-ов и скраммастеров, всё сразу заканчивается когда режут бюджет, лайофом рубанут сразу независимо от процессов и доброты.
у нас одним махом сократили всех оутстафферов, человек 50 (и меня в том числе), некоторых прям сразу после очередной сходки на тему "как мы ценим наших сотрудников и повышаем эффективнось"
KarimAminov
08.11.2023 13:40Если в компании есть не слушающие, дикие или отбитые на голову - надо сразу уходить. Полностью согласен и поддерживаю с этим.
Ну и к сожалению от диких закидонов руководителей тоже увы никто не застрахован. Но на моей практике хорошие и эффективные команды носят на руках и заливают их какими только можно благами, лишь бы они продолжали и дальше также работать. И тот же адекватный руководитель это понимает, т.к. по результаты его команды оценивают его эффективность.
DMGarikk
08.11.2023 13:40Но на моей практике хорошие и эффективные команды носят на руках и заливают их какими только можно благами
Решение о сокращении обычно принимают выше непосредственного руководства
мне вот весной списки пришли уже даже с фамилиями и датой увольнения...кое как одного человека отстоял...и то его всёравно перевели (ну хоть не уволили), потому что результаты результатами, а бюджет важнее
причем контора вполне себе адекватная
SergioT4
08.11.2023 13:40Crum - это лишь один из инструментов (или фреймворков) как это сделать более эффективно команде разработки.
Это инструмент для того чтобы переложить работу менеджера на самих разработчиков, плюс манипулировать комплексом вины для того чтобы выжать последний возможный витамин из разработчиков - типа сами на себя набрали обязательств, сами отвечайте за свои слова, а из практики следует что большинтсво разработчиков в своих оценках overoptimistic. на этом и подлавливают.
За счёт уменьшения времени на спринт и изменения структуры процесса разработки, исчезают естественные периоды низкой интенсивности, в которых разработчик имел возможность восстановиться от цикла высокой интенсивности. Теперь либо высокая, либо супервысокая интенсивность циклов разработки.
KarimAminov
08.11.2023 13:40Кстати, статья - огнище! Автору огромное спасибо за описание работы "русского" скрама.
Yuriy_75
08.11.2023 13:40Скрам ужасен уже тем, что там просто "разработчики". Техлиды, аналитики, тестировщики - нет, авторы скрама об этом не слышали.
MonkAlex
08.11.2023 13:40+1Так, а ужасного из этого что?
Developers оно просто потому, что там вся команда, все участники которые производят продукт. Туда же можно (если нужно команде) добавлять юриста, безопасника, кого вам нужно. И все они работают в рамках скрама одинаково, скрам не говорит что у какого-то участника developers есть дополнительные обязательства.
Yuriy_75
08.11.2023 13:40+1Ну как минимум два разных набора ролей выходит. Один как в книжке по скраму написано, другой как в жизни.
И обычно мнение техлида несколько важнее, чем мнение джуна. А в рамках скрама, оба они одинаковые "девелоперы".
MonkAlex
08.11.2023 13:40Так, а какая разница, техлид ты или джун?
Вы должны спланировать спринт, выполнить задачи на спринте, выпустить релиз, показать демо.
Техлид и джун в этих всех активностях выполняют свою работу как умеют. Техлид в теории лучше справляется, джун учится у опытных коллег. Когда вы проводите какой-нибудь PBR для понимания как делать сложную задачу, джун как раз получает от техлида полезную информацию, уточняет как сделать хорошо.
Какая часть процесса спринта требует разных активностей от техлида и джуна то?
Yuriy_75
08.11.2023 13:40А с аналитиками и тестировщиками как быть? Вроде обычно сначала аналитик пишет ТЗ задачи, потом программист задачу выполняет, потом тестировщик тестирует. И как это согласовать с идеей, что все участники команды во время спринта работают только над задачами спринта? Чем будет заниматься аналитик в конце спринта?
MonkAlex
08.11.2023 13:40Можно разные варианты использовать:
Писать другое ТЗ в конце спринта. Ну т.е. фича1 написана, фича2 в работе у аналитика.
Общаться с разработчиком тестировщиком и кем угодно ещё, уточняя мутные моменты. Разработка уже может быть запущена.
Прорабатывать с тестировщиком тест-кейсы или что-то ещё вокруг нового ТЗ.
Аналогично у других ролей - если для них есть хоть какая-то работа -- можно ею заниматься в "свободное" время.
И ещё момент - не обязательно загружать каждого члена команды на 100%. Главное сделать то, что вы запланировали, вам за это и платят.
vvbob
08.11.2023 13:40Насколько я понял суть этой религии, подразумевается что нет там никаких тестировщиков, аналитиков, девопсов и прочих, есть просто сферический разработчик в вакууме, который во все это умеет и все делает на отлично, сразу, с первой попытки.
Весь этот скрам это по факту про запиливание фич, но в реальности так никогда не бывает, что-бы все только и делали одни фичи.
Например как-то во все эти спринты и прочие приседания очень плохо укладывается работа с багами, а их может быть просто дохрена, особенно в условиях искусственно созданной нервотрепки с дедлайном к демо, когда все запиливается на костылях, лишь бы успеть и не облажаться.
Вообще никак не учитывается то, что часто возникают проблемы с инфраструктурой, которую надо развертывать, поддерживать, чинить при падениях,
Вообще игнорируется возможность всяких авралов, когда вся команда бросается на амбразуру падающего прода..
Да много что адепты предпочитают не замечать, и потом рассказывать что мол - это у вас аджайл просто неправильный такой, неидеальный, потому и работает все через..
MikeVentris
Не помню откуда, но вполне вероятно, что из какой-то "библии" скрама/аджайла.
У внедрения любой методологии есть 3 этапа.
1) Обучение. Когда человек/команда обучается тому, что такое методология, какими свойствами она обладает, какие артефакты предполагает и какие цели преследует.
2) Реализация. Когда человек/команда стремится реализовать методология вот прям как написано в книгах. И это правильно, тк на этом этапе человек/команда не обладает достаточным опытом, чтобы понять, куда следует вносить изменения чтобы сделать методология эффективнее. Если начать вносить изменения на этом этапе, то получится классический "Scrum-but": скрам, из которого, в благих намерениях, конечно же, убрано или добавлено что-то, что ломает всю систему. Это как прийти обучаться карате и на втором занятии сказать учителю "слушай, а почему бы просто не взять нож, вместо вот этого всего?".
3) Адаптация. Когда человек/команда обладает достаточным опытом, чтобы понять, какие слабые стороны есть у каноничной реализации в конкретно взятом случае, можно вносить изменения, чтобы адоптировать методологию под конкретный кейс. И вот на этом этапе это приведет к повышению эффективности относительно базовой реализации. В аналогии с карате это стать мастером карате, а потом основать свою школу, где профессиональное карате будет сочетаться с использованием холодного оружия.
Если посмотреть глобально, то это частный случай цикла Деминга, который как раз и предполагает развитие "Планируй -> Делай (слепо) -> Рефлексируй -> Корректируй". В данном конкретном случае (при внедрении скрама или любого другого фреймворка) люди часто начинают рефлексировать не закончив стадию "делай".
И именно поэтому опытные Scrum-мастера и Agile-коучи - важный элемент внедрения методологии. Они как мастера единоборств, которые получили черный пояс в классической десциплине, а кроме этого повидали много разных уникальных кейсов и знают как можно быстро и безболезненно адоптироваться под конкретно ваш случай.
Впрочем, как и в случае с учителем карате, никогда не знаешь, реальный мастер перед тобой или выскачка, решивший нарисовать резюме. Но это уже вопрос HR отдела.
PS: а вообще, тот факт что в IT возникают такие проблемы при, в общем-то, элементарном и давно известном процессе внедрения любого производственного метода, говорит о том, что IT-шники и их руководители считают себя уникальными, не такими как все, с уникальными проблемами и уникальными же их решениями, а по факту просто обладают недостаточной квалификацией, т.к. все это объясняется в любой книге по классическому менеджменту, не говоря уже об MBA.
Gorthauer87
Вот мне интересно, если айтишники уникальные, то почему с ними вечно такие проблемы? Что ли в других сферах, в других производственных методах мало что ли людей с ЧСВ? Почему так значит с ними справились, а с программистами нет, значит. Нет ли тут противоречия?
PabloP
Плюсую ))
virtualtoy
Чаще всего в IT цена ошибки меньше.
Tarnella
Систематическую ошибку выжившего вижу я. Проблем у них как у всех, просто у них возможностей ими делиться на интернетных площадках больше, чем у главного технолога производства промышленных стиральных машин с другими главными технологами в стране.
piton_nsk
Можно подумать только в айти проблемы, а в остальных сферах благодать. На стройке не работали?
WASD1
IT-шника найти труднее.
Цена замены IT-шника выше.
....
В итоге баланс "послать работника и уволить (для нас денежные затраты для него наука) / нянчиться с работником" - в IT смещён в сторону второго варианта.
Yuriy_75
>>Впрочем, как и в случае с учителем карате, никогда не знаешь, реальный мастер перед тобой или выскачка
Очень странная аналогия. Учителя каратэ еще могут обосновать невозможность демонстрации всех их навыков тем, что причинение серьезных травм спарринг-партнеру - это уголовка. А коуч - это разновидность менеджмента. Ему никто применять свои навыки не мешает. Следовательно, к нему применимы те же критерии, что и к набору любого другого менеджмента.