Comments 276
У скрама много недостатков, но то, что автор раз за разом пинает именно разбиение задач - наводит на определенные мысли об авторе.
Декомпозиция - ключевой инженерный навык. Вообще, вне всяких методологий. Даже вне разработки ПО. Обучение джунов я всегда начинаю именно с обучения декомпозиции. Иначе все быстро скатывается в задачи без конца и края. Над ними сначала месяц сидит и охреневает разработчик. Потом месяц сидят и охреневают ревьюеры, что им нужно вникнуть в 5000+ новых строк. Потом еще месяц задача ходит по кругу In Progress - In Testing, потому что QA охреневает от количества ассертов. В итоге 3 месяца - и полный ноль результата. Спасибо, лучше буду дробить.
Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения
Разрабатываем трейдинговую платформу по скраму. Неизвестного и нового довольно дофига, скопипастить особо неоткуда. Как раз все отлично ложится в процесс, когда заказчик приходит с хотелкой, а команда накидывается, делает дорожную карту фичи и распределяет задачи по исполнителям. Опять же есть подозрения, что в тексте имеет место экстраполяция "я не умею - значит никто не умеет".
Разрабатываем трейдинговую платформу по скраму.
Это у вас в вебе все так легко и прозрачно.
А теперь зайдите в геймдев где при разработке чего-то реально нового, каждая задача тянет на полноценный рисерч в рамках которого задача может быть выполнена без всякой декомпозиции, либо наоборот потребовать еще рисерчей. Кроме того познания в графике/физике итд требуют годы опыта и задачи требующие глубоких познаний банально некому оценивать так как людей с такими познаниями просто мало, не то что в компании а в целом на рынке. Собственно на таких реально больших и сложных задачах скрам умирает. И не редко в геймдеве есть задачи с неизвестным исходом рисерч которых может длится месяцы, а если это что то уникальное (например тысячи интерактивных крыс в игре A Plague Tale: Requiem) то разработка и доработки будут длится годами.
А теперь зайдите в геймдев
А зачем мне заходить в геймдев? Это пусть автор пишет границы применимости его теории. А то получается странный разговор:
Автор: Пингвинов не существует!!!
Хабр: Да почему же? Антарктида, Тасмания, Южная Америка - там водятся пингвины.
Автор: А вы зайдите в пустыню Гоби - там пингвинов нет!!!
при чем же здесь пустыни? вы написали:
Вообще, вне всяких методологий. Даже вне разработки ПО. Обучение джунов я всегда начинаю именно с обучения декомпозиции.
То есть вы написали, что не только в геймдеве, а вообще в любой промышленности - даже где компьютеров нет вообще - скрам работает. А если скрам не работает, то причина - как вы пишете - в том, что все работнгики - низкоквалифицированные джуны, которых никто не учил ГЛАВНОМУ.
В общем-то вы проиллюстрировали тезис про "элегантный коммунизм". Который в рекламе работает везде, а после продажи - почти нигде.
То есть вы написали, что не только в геймдеве, а вообще в любой
промышленности - даже где компьютеров нет вообще - скрам работает
Серьезно? Прям так и написал? А мне казалось, что:
Декомпозиция - ключевой инженерный навык. Вообще, вне всяких методологий. Даже вне разработки ПО
У вас декомпозиция == скрам? В следующий раз попросите помощи ЧятикаГПТ, если настолько тяжело написанное воспринимать.
У скрама много недостатков, но то, что автор раз за разом пинает именно разбиение задач
Вы сказали, что единственная причина по которой пинают скрам, это когда пинающие не умеют в декомпозицию, и поэтому не могут заранее просчитать сложность задачи.
Других причин, кроме неумения в декомпозицию, для недовольства скрамом нет, согласно вашему тезису.
Вы сказали, что единственная причина по которой пинают скрам
Неа, не говорил, лол. Продолжаю самоцитирование
У скрама много недостатков, но то, что автор раз за разом пинает именно
разбиение задач - наводит на определенные мысли об авторе
Где что-то про "единственную причину"? Я говорю конкретно про автора, что есть вероятность, что навык декомпозиции у него не наработан. А если он не наработан, то жить в целом становится тяжелее.
Насчет ЧятикаГПТ я серьезно. Говорят, умеет разжевывать написанное.
Я говорю конкретно про автора, что есть вероятность, что навык декомпозиции у него не наработан.
То есть вы больше обсуждаете автора и его бэкграунд нежели саму по себе проблему.
Вы учитываете, что ИТ в принципе крайне молодая индустрия и в ней всё ещё большинство это самоучки и как и описано автором ИТ-шники это исследователи и RnD-специалисты по умолчанию или стремящиеся к этому? Если вы слышали интерес сферического ИТ-шника в вакууме, то он обычно сводится к задачам разработки "чего-то нового", а не клепанию одинаковых колош на ИТ-фабрике, то есть дословно в движении к исследовательской/RnD деятельности.
Конечно, в крупных компаниях у бизнеса уже давно пришло желание видеть вместо огромного RnD отдела с непонятым выхлопом на инвестицию - ИТ-фабрику с понятным потоком производства ценности для бизнеса.
Да, этот процесс старается структурировать Scrum и SAFe и прочие метОды. Но давайте говорить честно, по имеющимся методологиям нет научных исследований. Чтобы на базе статистических данных подтверждали эффективность того или иного подхода с учётом контрольных групп, точного учёта всех параметров, исключения большого количества внешних влияний.
Ни к одной из применяемых методологий не были приложены чёткие гипотезы, исследования и фактические подтверждения того, что эти гипотезы подтверждаются. Фактически эти методологии - просто заявления людей о том как они считают и как им бы хотелось работать и взаимодействовать, дословно = манифесты, коим и является Agile
Может быть, дело в том, что у Вас некоторые процессы идут в не в том ключе, как у других? Как я понимаю, Вашей команде заказчикв выделил бюджет на конечный продукт ( трейдинговую платформу ), а как Вы распределите бюджет на задачи, его не волнует.
Я тоже работаю в веб, но у меня ситуация иная. Приходит менеджер, далее диалог: менеджер: заказчик хочет вот такую фичу, сколько это часов?
я: не знаю, мы такого не делали. Мы можем сделать вот такой кусочек за N часов, и понять, что делать дальше.
менеджер: а какая часть задачи это будет? Половина? Четверть?
я: говорю же, не знаю. Мы такого не делали.
менеджер: нет, меня это не устраивает, мне надо сначала продать задачу заказчику.
Та самая RnD задача, о которой писал автор статьи.
При этом на другом проекте, где заказчик просто хочет получить результат (где-то в будущем), такой проблемы нет.
Ну так а причём здесь скрам или не скрам? Неважно как вы у себя устроите процессы, но у вас всё равно остаются две проблемы: вы всё ещё не знаете сколько будет стоить решение задачи, а менеджеру всё ещё надо её сначала продать.
То есть вам в любом случае надо сначала продать клиенту ваш R&D. Или взять на себя риски и назвать ему какую-то конкретную цену за эту задачу.
так тут проблема не самого скрама, а попытка применить его к RnD задачам... у меня от такого тоже болит... и да, скрам тут не работает. нужно смотреть как решать RnD задачи и донести до менеджеров, что этот процесс не укладывается в дейлики и закрытию какой-то таски каждый день
В чем проблема взять задачу-плейсхолдер на весь спринт (спайк, POC, RnD, называйте как хотите). В конце спринта, через условные 10 рабочих дней (в случае 2-недельного спринта) у разработчика появится примерное понимание сколько дней (стори-поинтов) _примерно_ еще потребуется. Далее создаете еще таких же задач в следующие спринты.
Если же вообще понимания не появилось (делаем что-то суперсложное, "тысячи активных крыс в Plague Tale") - ну созадавайте опять плейсхолдер на 1 инженера на следующий спринт и все.
Всем участникам процесса надо быть гибче просто, не надо все воспринимать всё "в лоб".
Задачу на весь спринт, ага. Хорошо если максимальный срок по задаче 3 дня, а если один день? Как будете отчитываться о ходе выполнения задачи, как же цели спринта. Скрум-мастер быстро объяснит в чем вы не правы)
В чем проблема взять задачу-плейсхолдер на весь спринт (спайк, POC, RnD, называйте как хотите). В конце спринта, через условные 10 рабочих дней
А зачем ? что эта задача дает кроме пересоздания задач каждые 10 дней и переназначение на нее все того же единого разработчика. Какая фактическая польза кроме того что скрам мастер сможет накормить своих детей ведь у него еще осталась работа.
Автор говорит про "неизвестное неизвестное". Эта задача-плейсхолдер снимает первый уровень неизвестности. Ты целый спринт на законных основаниях занимаешься вскрытием проблем и рисков, поиском решения. В результате спринта от тебя ожидают ответа в виде "невозможно никак", "надо так, оценка - 3 месяца", "надо вообще по-другому", "можно обойтись без этого" и подобных. Если через спринт бизнес узнает, что нужно влупить в эту хотелку все деньги мира, наверняка задача резко потеряет приоритет. А в водопаде будут делать до тех пор, пока деньги не закончатся, а потом еще и в кредит, потому что "уже потрачено"
Ты целый спринт на законных основаниях занимаешься вскрытием проблем и рисков, поиском решения.
Это если можно срок задачи установить в 2 недели. А у фанатичных адептов так делать нельзя, надо декомпозировать, как их не волнует.
Для "(спайк, POC, RnD, называйте как хотите)" допускается планировать хоть целый спринт. Даже если в итоге выяснится, что решалась задача за 5 минут. Адепты, как правило, понимают, что лучше ограничить период неопределенности, чем иметь неопределенную неопределенность. За фанатичных не ручаюсь.
То, о чем мы говорим, это же вопрос культуры и коммуникаций. Если скрам-команда не имеет возможности вернуть обратную связь заказчику и работает по принципу "мы люди маленькие, нам задачу дали, мы будем её пилить пока не сделаем, либо пока не устанем", то, конечно же, никакого спайка, никакой декомпозиции и никакой ответственности не дождешься. Если же команда имеет голос и может в процессе принятия задачи в работу сказать "нет, стоп, нам непонятно, мы не подписываемся", тогда просто задача в работу не идёт. Ну и кто в проигрыше от этого?
В результате спринта от тебя ожидают ответа в виде "невозможно никак", "надо так, оценка - 3 месяца",
А кто сказал что спринта хватит на оценку ? Спринты у кого то неделя а у других 2 месяца. Кроме того кто сказал что эти оцененные 3 месяца хватит ? А если задачу сделают в рамках рисерча ведь рисерч без mvp по таске считай бесполезен, а этот mvp уже зачастую закрывает таску.
В итоге скрам ради скрама а задача была выполнена as is, про разработчика забыли на X времени без рамок спринтов, и он все сделал. И никаких подзадач и оценок ему для этого не надо.
Если через спринт бизнес узнает, что нужно влупить в эту хотелку все деньги мира, наверняка задача резко потеряет приоритет
На самом деле если команда с опытом то сразу после озвучивания задачи идет оценка типа "изи" или "мы на этом встрянем очень надолго" из которой бизнес уже прекрасно понимает надо ему это или нет.
Hidden text
В итоге скрам полезен для менеджеров и руководства как метод слежения за производительностью сотрудников. Но чисто для работы это действительно ощущается как рак отнимающий время вникуда. банальный канбан с задачами уже покрывает 99% задач. Тут в пример хочется привести Apple / Google которые всухую слились в AI гонке на данный момент, и тот же openAI где по сути стартап мусорка без аджайла и скрама существовала годами, и только такой подход без мозгоделия позволил им реально делать работу а не красивые задачки для руководства.
Еще пример в виде разработки игр в крупных компаниях типа Rockstar и найтидог, мега крупняк с кучей людей, скрамом и аджайлом, а переработок миллион, баги в играх вылазят постоянно, все фиксят в последний момент, куча кранчей. Наверное оценивают задачи плохо, и разработчики плохие, надо наказать их.
А кто сказал что спринта хватит на оценку ?
я живу в мире, где работа над какой-либо задачей продвигает меня в её решении. сами по себе они, почему-то, не решаются :(
может и не хватить, но явно будет лучше, чем на старте.
А если задачу сделают в рамках рисерча ведь рисерч без mvp по таске считай бесполезен, а этот mvp уже зачастую закрывает таску.
идеальный случай. большей частью потому, что решена задача была в рамках установленного ограничения по времени. Х, в данном случае, не "когда нибудь", а вполне себе "через две (подставьте свое число) недели"
На самом деле если команда с опытом
когда команд > 1, то начинается ручное управление:
– эти знают лучше, давайте дадим им!
– но у них уже есть другая задача аналогичного приоритета!
– пусть вспотеют посильнее!
в то время, как рядом сидит менее опытная команда, но которая может немного закосячить с оценкой. даже если они ошибутся на 50%, в рамках спринта это половина. если дать задачу опытной команде, то, по-хорошему, они сделают её в следующем спринте. результат ручного управления - задача сделана на полспринта позже, зато опытной командой. вопросы качества не затрагиваю, в этом диалоге слишком много неизвестных.
Как минимум – такой подход заставит тебя раз в этот самый спринт подытожить, а что же ты выяснил, и какая новая информация появилась.
Потому у тебя будет планирование, где ты подумаешь: а надо ли вообще эту задачу сейчас брать? Может быть ты потратил три спринта, команда поняла что неопределённость особо не сокращается, и за такие деньги нафиг эти тысячи активных крыс продукту не нужны.
Согласись, намного удобнее, чем разработчик который ушёл куда-то на полгода, раз в месяц говорит "я разбираюсь", а в конце говорит "ну, не получилось"
Как минимум – такой подход заставит тебя раз в этот самый спринт подытожить, а что же ты выяснил, и какая новая информация появилась.
А что мне мешает подытожить это без скрама, без заведения задачек и спринтов ?
Если из вашего же сообщения взять " разработчик который ушёл куда-то на полгода, раз в месяц говорит "я разбираюсь"" то ему явно нечего еще сказать под конец двухнедельного спринта раз он разбирается в задаче которой требуется "ушёл куда-то на полгода", и тут хоть есть задачка и хоть нет, он работает. А если ему есть что сказать то он и без эстимейта и задач вам это расскажет без проблем.
В той же веб разработке все как в китайской потогонке, все рассчитано и уже готово, только клепай на конвейере. А в сложной разработке с неизвестными алгоритмами и результатами, как у художников, нужна тишина, покой, студя с хорошим светом, вдохновение итд =) Иначе будет как у Microsoft на последней презентации. Показали 5 игр а они все дженерик мусор, не игры с душей и именем а game_1, game_2, game_3, так как все выштампованно из готовых ассетов по скраму с оценками времени, и там небыло времени на полет души и эксперименты.
Так ничего не мешает :)
SCRUM – явно не единственный способ работать работу.
Но фреймворк, при правильном использовании, заставляет тебя задуматься о том, как сделать свою процесс более управляемым.
Разработчику может и хотелось бы сказать "ой, ну я ничего не узнал", но фрейморк пушит тебя завершить работу, зафиксировать результат, и запланировать новую работу (опять же, сформулировав ожидания – что именно ты пойдёшь исследовать, и что расскажешь через две недели)
Разработчику может и хотелось бы сказать "ой, ну я ничего не узнал", но фрейморк пушит тебя завершить работу,
Что мешает писать заметки по результатам изучения, и делать это без скрама с задачами оценками и переносом задач каждые 2 недели на следующий спринт ?
Я не говорю что скрам не нужен, но я привел пример где он как рак для человека, вы пытаетесь убедить меня в обратном именно в рамках этой ситуации, то вы заведомо проиграли.
Скрам жив и он полезен в определенных проектах, но не везде, далеко не везде где его пытаются пихать. И вот вы сейчас этим самым пиханием скрама и занимаетесь, вызывая все большее отвращение у тех кто с ним поработал но на моих условиях (весь геймдев)
То, что вы описали, можно назвать Скрамбаном. То есть это эдакий канбан поперек скрама. Может тогда сразу уже перейти на канбан?
В чем проблема взять задачу-плейсхолдер
Я бы так не делал, так как тогда - о чем все. Ну смотрите. Есть человек, он "копает" что-то неведомое. Тут не важно, неведомое вообще, для команды или только для него (хотя эта опция явно требует другого решения).
Но в любом случае у него есть идеи, что он делат. К примеру:
ищет варианты решения
пробует конкретный вариант
формулирует требования
...
И это уже формализуется и легко вносится в спринт
И это уже формализуется и легко вносится в спринт
чтобы внести в спринт нужно оценить.
как оценивать "ищу варианты решения" и уложиться в дедлайн? нужно дать обещание неизвестного и уложиться в него
чтобы внести в спринт нужно оценить.как оценивать "ищу варианты решения" и уложиться в дедлайн? нужно дать обещание неизвестного и уложиться в него
Ну смотрите. Если мы примем, что требования к решению есть либо описана проблема, которую надо решить, то очевидно декомпозируются либо требования, либо сама проблема
К примеру, очень сложный пример. Мы хотим долететь до Марса и высадить там Марсоход и вы ищете решение. Очевидно, что начинать надо с декомпозиции задачи, которую повторять многократно. Первый уровень может быть разбиение на:
Ракета носитель для выхода на орбиту Земли
Ракета для того, чтобы долететь до Марса и выйти на его орбиту
Корабль, чтобы приземлить на Марсе
Сам марсоход
И дальше разбиваете до требуемого уровня детализации
Если простой пример, медленный отклик приложения. Разбиваем и ищем
------------
Тогда ваша первая задача - сделать декомпозицию. Вот и все
Я вполне четко задал вопрос и он был не в том, как декомпозировать задачу
как оценивать "ищу варианты решения" и уложиться в дедлайн?
Я вполне четко задал вопрос и он был не в том, как декомпозировать задачу
Это и есть ответ :) Не знаешь как делать - бей на части. Либо требования, либо проблему, либо архитектуру решение.
И так часть или части, которая будет разбита до элементов, о которых можно сказать "знаю" - будет оценена и внесена в спринт/план.
Или исполнитель не обладает требуемой квалификацией для занимаемой позиции
-------------
Мне даже грустно писать этот ответ, если честно
Так знаешь как делать.
Набрейнштормить варианты решения - 2 дня с разгребанием, в спринт укладываемся
Копать наиболее перспективный вариант либо до точки отказа либо до получения ясности - мы не можем внести в спринт, так как до брейншторма мы не знаем, что это за вариант, какие ресурсы потребует, какой будет признак отказа
Довести наиболее перспективный вариант до решения или начать копать следующий по перспективности вариант или провести новый брейншторм с учетом полученных на п.2 данных - да, для третьего пункта мы не знаем не только ресурсов, но и что это будет за задача. Вносить в спринт нечего. А за один спринт по 2 дня на гипотезу мы можем и до 5 пункта дойти. А уже здесь вносить нечего.
И дальше разбиваете до требуемого уровня детализации
То, что нужны ракета, марсоход и т.д. — это очевидно, здесь декомпозицию сделать достаточно легко. А вот дальше уже сложнее. Например, в марсоходе нам нужен некий двигатель и некие колёса, ну или что-то вместо них, а их нельзя проектировать совершенно отдельно, потому что от мощности двигателя зависит вес марсохода и, значит, характеристики колёс, которые должны всё это везти, а, в свою очередь, увеличивая колёса увеличиваем общую массу, изменяем габариты, меняются размеры корпуса и передаточного механизма, то есть, это снова может повлиять на требуемую мощность двигателя, а увеличенные размеры нового двигателя возможно повлияют на расположение центра тяжести, что для марсохода может быть критично, и т.д. Нельзя просто взять и разделить конструкцию на отдельные элементы и их отдельно спроектировать. Тем более, если нужно минимизировать размеры и массу конструкции (чтобы легче было доставлять её на Марс).
Конечно, но я специально взял граничный кейс с мега задачей. Если мы остаемся в плоскости планирования, а не как это сделать технически (я тут не претендую на экспертность по очевидным причинам), но именно декомпозиция, которую вы продолжили позволяет в конечном итоге прийти к измеряемым задачам
В нашем варианте это может быть задача определить направления, определить состав групп проекта и т.д.
Суть в том, что камрад спросил - как делать и планировать то, что еще не знаешь как сделать. Ответ прост, декомпозировать то, что знаешь. Либо принять, что ты не соответствуешь позиции :)
-------------------
На самом деле на старте любого проекта возникает такая ситуация, когда ты еще на знаешь, но уже есть конкретные задачи, исполнители и сроки :)
Поэому вообще вопрос вызывает, как минимум, чуток недоумения
В чем проблема взять задачу-плейсхолдер на весь спринт
Именно про это я и говорю! Какая польза от этого? Мы синтетически "натягиваем" рабочий процесс на спринты, чтобы "было по скраму", при этом скрам никак не отражает реальный процесс, а то, что мы видим в нем - фикция, плейсхолдер.
В итоге рабочий процесс идет как и шел, а в трекере стоят нерепрезентативные заглушки, но зато менеджмент доволен, все под контролем!
Скрам ритуалы требуют даже по такой задаче плана эксперимента и отчета о результатах - та самая демка "которую можно в прод".
Тем самым механически не дает нырнуть на полгода в свободное плавание переходящее в броуновское движение с одной укладывающейся в WIP задачей канбана в InProgress.
Да можно избегать этого и без скрама. И возможно 100%RnD процесс эффективнее вести не по скраму. Но если вы уже работаете по скраму 90% задач, то и оставшиеся 10% RND логично оставить в том же процессе, если их делают те же люди.
скрам смещает фокус с того что надо делать на вот эти все формальные пляски с декомпозицией и примерно всегда неверными оценками. Нормальные разрабы не уходят на пол года делать непонятно что чтобы потом сказать "не получилось", все равно апдейты даешь команде, но я хочу чтобы это я выбирал когда апдейтить или когда ещё поработать, в идеале, вообще не приходя на дейлик. А не чтобы кто-то мне задавал один и тот же тупой вопрос каждое утро суть которого "дай репорт по задаче", репортить что-либо вообще раздражает.
втыкаемся в эту проблему.
заказчик захотел
пм с дизайнером нарисовали макет
макет приносят команде на оценку по срокам
разработчику ставят задачу на оценку. эта задача выполняется в течение спринта рядом с обычными
разработчик оценивает
к оценке добавляется x запаса
если не отказались от идеи, увидев оценку - задачу ставят на разработчика, дедлайн = оценка
это тоже ломается об r&d
как оценивать решение задачи неизвестным образом - неизвестно. можно было бы закладывать время на "попробовать варианты абв и выбрать", но для этого нужно комплексно продумать каждый
оценку надо успеть выдать к следующему диалогу ПМа с заказчиком, чтобы они договорились о приоритетах
во время работы по задаче можно придумать лучшее решение, чем то что заложено в оценке. лучшее не значит более быстрое, а значит что в будущем поможет с другими задачами, емли заложиться в нее сейчас
на одной неделе тебе дают задачу x, а через еще две - x'. для решения задачи x не вводили новых сервисов/слоев, а для x' уже не получится. можно было сразу делать инфраструктуру для x', чтобы потом быстро закрыть обе задачи, но не вышло. теперь тебе нужно переносить x на x'. системно не решаемо, тк ПМ не может обобщить
при разработке чего-то реально нового,
Хз в чем тут особенность геймдева, но это работает в любой сфере, если нужно что-то новое сделать, то нужен ресерч
Исследование (рисёч) всегда с неизвестным исходом, в этом его смысл. Но вообще говоря, мысль о том, что исследование нельзя спланировать и декомпозировать, это большое преувеличение.
В начале исследования программист вполне может сформулировать, как он планирует исследовать:
- ознакомиться с такими-то материалами
- если узнает то-то, то проверить такую-то гипотезу
- если это работает, написать прототип
- если нет, то поставить более конкретные задачи на другие исследования
Это уже декомпозиция, которую можно оценивать. Хоть целиком, хоть по отдельности.
Если человек говорит что он хочет "просто посмотреть такую-то тему" без понимания, что и как он будет исследовать, это уже плохой звоночек.
И если этого не делать, человек может месяцами даже не замечать, что занимается ненужной фигнёй. А декомпозиция и оценка (если остальные не понимают в теме - ну ок, не будут ставить оценку, но даже блин кошке полезно объяснить, что ты собираешься делать) спасёт его же самого от непродуктивной траты времени.
Вот эти самые несколько слов, которые толком ничего не значат: "если узнает то-то" и содержат ошибку. Ты не знаешь, что узнаешь в процессе изучения материалов и проверки гипотез. И не можешь этого знать в принципе. Так и выходит, что планирование возможно только ближайшего шага, или просто полагаясь на интуицию и известные величины(вроде известных частей прототипа).
Только исследование, как правило, включает в себя десятки гипотез, до исчерпания идей. По сути, каждая новая гипотеза - новое исследование. Какие именно будут гипотезы невозможно узнать, пока не дойдёшь до них.
Проработка для оценки гипотез почти = проверке гипотезы во множестве случаев, т.е. дешевле сразу код писать. Фактически это то же программирование, но без собственно кода, что ещё сложнее и подвержено большому кол-ву ошибок.
Кстати, если делать по скраму, то "поставить более конкретные задачи на другие исследования" = новому спринту, что = полной потере гибкости. Если делать иначе - это уже не скрам. Цепочка гипотез растянется на годы работы, вместо дня
Ты не знаешь, что узнаешь в процессе изучения материалов и проверки гипотез. И не можешь этого знать в принципе.
Да, но это не отмазка ничего не писать в описание задачи :) Никто ж не просит описать все, просто внесите в задачу
Так и выходит, что планирование возможно только ближайшего шага
И все. Дальше напишете результаты и создадите таски для следующих задач
Так то оно в теории так. На деле это смотрел и даже несколько применял, как раз в рамках теста - была попытка решить проблему таким способом, для чего задачу прямо в процессе разбирали на части. Буквально в тот же день и выяснили, что это не работает, записав решение нескольких задач на условные несколько часов. Выходили цепочки в несколько задач для решения, чаще 3-5, но порой и цепочки в несколько десятков. Изредка совсем простые в 1 шаг, типа багов, которые уже знали как починить, а если не знаешь - то же самое. Каждую надо описать как задачу, согласовать, затем Заново делать, т.к. из контекста уже выпадаешь. Ну и смысл? По скраму, как уже писал, вообще работать невозможно, т.к. нужен новый спринт на каждую задачу в цепочке
Мне кажется, вы сознательно себя "загоняете в угол", выполняя буквально правила, которые, по большому счету не нужны
Ну смотрите, идет нормальный проект написания софта. Что делает аналитик/дизайнер? Очевидно копают вперед. Они знают наперед, как будет реализована фича? НЕТ. Не знают. Даже заказчик не знает, так как может оказаться, что "люди с полей" принесут новую инфу.
Но никто не страдает, так как в спринте таска "проработать определенное нанравление".
--------------
Вы ж не на доску работаете, а на результат.
В Вашем примере - а зачем столько деталей? Надо time tracking? Делайте по факту, чтобы заказчик видел? Не надо time tracking - вообще перестаньте себя мучать бухгалтерией. Ну или пусть по факту ПМ ее сводит, раз ему надо.
-------------
Если вернуться к Scrum (What is Scrum? | Scrum.org ), возможно стоит перечитать и посмотреть, а точно ли вы работаете по нему
Мы же об оценках в т.ч. и объективности. Нельзя просто сказать - исследуй это. Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)
Что делает аналитик/дизайнер? Очевидно копают вперед.
Дизайнер исследует и получает +- полную картину объёма работ. Это вообще самый плохой пример. Даже в геймдеве предсказать объём выходит крайне точно, на месяцы вперёд с ошибкой в неделю. Проблема может быть только с не достаточно опытными, но дешёвыми дизайнерами.
Аналитик не знает ситуацию, но так же имеет представление. И сроки исходят так же из представления. Он является постановщиком и передаёт задачи вниз. И в случае чего, за сроки работы программистов не отвечает, а часть анализа благополучно сливает на конечных исполнителей - программистов. Анализ того, что и как должно быть в целом же более-менее постоянен. Т.е. можно ошибиться в некоторых аспектах, в некоторых недоработать, пропустить что-то. И они ошибаются и сроки так же едут. Только вот ошибка при поверхностном анализе так же велика. И многие проекты так же затягиваются и/или выполняются не полностью) Т.е. проблема с аналитиками такая же и не решается. Помню в ВУЗ-е ещё про интеграцию длиной аж в 10+ лет говорили! А план в 2 был, и оставался примерно таким же все годы)
-----
В нашем примере берётся скрам, из него выдёргиваются спринты, пытаются как-то прикрутить, оно не работает. "Не особо умный" менеджер бесится, руководители бесится. Сделать ни черта не могут, в худшем случае винят разрабов и на этом конец) Пару раз видел как команды/компании валятся из-за этого. Сейчас такого поменьше стало, но раньше было частым явлением.
Тут не про трекер времени, а про оценку срочного(т.е. у которого есть дедлайн) проекта.
Проблема в том, что надо это не только ПМ-у, но и всем отвечающим за проект в целом. А они просираются из-за своих ошибок, но видят в этом ошибку программистов. Иногда начинается с установки оценки, а заканчивается тем, что сроки не сходятся и в ответе за сроки оказываются программисты, лиды, а не менеджер.
-----
Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач. Убрать краеугольный камень скрама - получить хромую лошадь. Многие то не могут это заставить работать в принципе, и получается урод, что только маскируется под скрам, а на деле является старой концепцией с 5 ногой.
Нужны сроки. И они всегда есть на каком-то уровне проекта. И они очень часто не работают ожидаемо на любом не типовом проекте)
Давайте на примере. Ну честно, когда за плечами 20+ лет, можно промазнуться со сроками, но говорить о не "типовом" проекте ... либо по странному стечению обстоятельств условно архитектра из финтеха засунули в гейм дев и теперь смотрят, как он выгребет :)
Понятно, такая ситуация маловероятна
В остальном ... сорян, я не уловил. Я предполагаю, у вас есть какой-то обширный контекст, но я его не знаю и понять вашу мысль не могу :(
-------------
Если вы столкнулись с тем, что уже надо на кого-то списать "факап" - это безусловно плохо, но вряд ли имеет отношение к общей теме
Но понятно, что если сроки поплыли, либо они были не релеванты - то дело явно не в методологии
Вот как раз одна из основ скрама - инструмент со спринтами и менеджментом задач
Вопрос в том, понимается ли он. Как его задумали? Возможно имеет место бьіть банальное исполнение каких-то процедур, которые имеют далекое отношение к тому, что написано в исходной методологии
Лично я совершенно не перевариваю идею кросс-функциональности, а также роль скрам мастера, которая породила по сути кучу дармоедов. Остальное выглядит довольно таки рационально и понятно
Также я могу по опыту сказать, что народ вообще забывает, что цель итерации - это в первую очередь, а что делать - во-вторую, из-за чего планинги часто просто превращаются в накидывание пока не закончится капаситет, а потом оно вместе не собирается
Но понятно, что если сроки поплыли, либо они были не релеванты - то дело явно не в методологии
Ровно наоборот. Если она применялась правильно и оказалась не эффективна, то дело в методологии.
а потом оно вместе не собирается
Это вообще у меня редкая проблема. Каждый спринт - должен быть рабочий продукт и фичи в рамках спринта.
когда за плечами 20+ лет, можно промазнуться со сроками
Ну даже если с опытом в 20+ промахи, то что уж говорить про менее скилловых рядовых разрабов?
Нет особого контекста. Просто скрам для Agile разработки ПО не подходит. И поэтому провалы по срокам я вижу везде. А смириться с таким положением дел и рулить тем, что есть, не могут. Особенно низкоскилловые управленцы/владельцы/манагеры.
А про типовые говорю, т.к. есть сфера с 1С, где делают на платформе много раз повторяемые вещи. Там все считают работу в часах... Но! Тратят на часовую работу в один раз 20 минут, а другой 90, фактическое время постоянно скачет. Т.е. оценка всё так же наобум.
был аналогичный опыт, только я тот самый менеджер продукта, который ставит ограничения сверху. Нет в этом ничего особо сложного, ты оцениваешь как-то сверху, сколько тебе нужно времени на разобраться, это время явно укладывается в спринт (если ты хочешь несколько месяцев разбираться, то сорян, задача уже, очевидно, не нужна вообще). После старта задача уточняется, и уже можно ее разбивать на более конкретные вещи.
Да и в целом планирование же нужно не чтобы кого-то поставить раком в рамки, а чтобы спланировать загрузку и прогнозировать результат этой загрузки, команда же не сама по себе ради своего интереса живет, такие вот дела, что за это кто-то платит, а кто платит, тот и заказывает музыку. А если хочется просто в свободного ученого поиграть - то это уже не про работу, а про любопытство, и то на это в рабочее время принято выделять время, но в целом - это нерабочая активность. Если потрогать технологию занимает больше месяца, то надо уже не ее изучать внутренними силами, а привлекать кого-то, кто за месяц сделает, это эффективней как-тл для проекта. Для человека, который хотел потрогать - нет, но для команды и проекта - однозначно
Смешались в кучу кони и люди.
Вам говорят, что декомпозиция это отличный навык.
Вы говорите, что декомпозиия не подходит для каких-то задач RnD, потому скрам это плохо.
Простите, возможно в момент написания вы не поняли этого, но надеюсь сейчас до вас дойдёт, что:
Декомпозиция это хороший инструмент.
Нет универсальных инструментов для всего. Для разных задач лучше подходят разные инструменты и это навык инженера - уметь их применять.
Неприменимость инструмента к задаче не делает инструмент плохим.
Ну и отдельно - честно говоря, ваши примеры скорее больше говорят не о том, что в вебе всё просто, а у вас сложно, а о том, что в вебе порядка больше, чем в геймдеве, притом в первую очередь в головах.
Всегда было интересно про геймдев. Со стороны кажется что там кранч на кранче и костыль на костыле и происходит это потому что игру нужно выпускать асап в определенное окно, но при этом большой список хотелок и релиз в духе "все или ничего".
А как это выглядит изнутри индустрии?
Геймдев разработчики всегда игры позиционируют как что-то из ряда вон выходящее. Про "окно" согласен. Но почему игру надо выпускать "асап", а не когда она доведена до ума? Потому что так решил менеджмент и инвесторы ждут (если они есть). Чем это отличается принципиально от релиза в каком-нибудь retail крупном? Там зависимостей от окружающей среды не меньше: топ менеджмент ставит сроки и ждёт их соблюдения, в горячий сезон релизить нельзя из-за рисков все сломать и упустить прибылью. Конкуренты толже могут поджимать.
А так - и в геймдеве бывают нормальные релизы, почти без багов и коанчей (Baldurs Gate 3), а бывает забагованное дерьмо с лопаты и кранчи. Все от комнды и менеджмента зависит, а не от того что это "геймдев".
Да вот поэтому интересно в чем такая особая специфика геймдева, что оттуда историй про кранчи, багованные баги и костыли в виде поездов-шапок больше, чем в других отраслях.
это безболезнено и смешно. никак не сравнить с реальным миром, как баг (и костыль MCAS) у боинга, когда самолёт не может взлететь из-за одного неправильного датчика. или у атомного реактора, но хорошо, хоть защита сработала. пара багов в реальном мире - и самолётам запретили летать. А в это время в геймдеве - набираем предзаказы на новые костыли и баги, кто быстрее заплатит, то будет главным тестировщиком багов!
Я думаю тут дело в том, что даже посредственная и багованная игра, как правило окупается, поэтому менеджеров устраивает что выйдет говно - главное побыстрее выпустить и продать.
Там зависимостей от окружающей среды не меньше: топ менеджмент ставит сроки и ждёт их соблюдения, в горячий сезон релизить нельзя из-за рисков все сломать и упустить прибылью. Конкуренты толже могут поджимать.
Приведите пример, что это за ритейл крупный?
Мне вот про геймдев как раз всё понятно.
Из своего опыта.
Как 0, т.е. всегда. Пилишь игру, получается плохо, переписываешь. Так повторяется до хорошего результата. Получается плохо в любом случае. Дизайн кривой - переписываешь. Поменяли геймплей(а это по ходу разработки норма) - переписываешь. Иногда под релиз уже нет времени переписывать, тогда неудачные решения просто удаляются. Какой объём будет и как будет работать толком никто не знает. Потому как игры ещё нет, дизайн со старта целиком в работе. Даже если 2 часть, очень похожая на первую.
1) Надо быстро, команда маленькая изначально, не успеваешь в срок, но вытягиваешь качество, делаешь конфетку. В результате получаешь по шапке, часть команды потребуют уволить и все без премии. И пох, что игра на 1 месте в сторе с миллионами продаж, что на много лучше других команд.
2) Финансирование по ходу проекта прекращается по независящим причинам. Нужен новый инвестор, но игры ещё нет - надо либо выпускаться, либо новый инвестор. В любом случае игра должна быть готова уже вчера. Я так в 1 проект с 3 крупными издателями... хотел бы сказать поработал, но они так ни черта и не сделали! Обидно, ведь каждый требует своих изменений, впендюрить свой суперкрутой велосипед и т.п., а в результате время потрачено впустую.
3) Проекты длятся очень мало, но слишком велики, чтобы сделать быстро. То же тестирование в отрасли не особо прижилось, т.к. долго. Местами можно и нужно, но проще потерять даже 5-10% пользователей и сделать гораздо быстрее, очевидные ошибки будут поправлены в любом случае. А баги мб потом поправят, если деньги будут. Длина проекта в 6 месяцев - нормально. В 2 года на ~ ААА - более чем. Нет, может быть и много дольше, но это обычно растянутое переписывание)
4) Изначальная идея и оценка не соответствует тому, что в итоге требуется. Потому что проверить идею и реализацию сразу не выходит. Прототипы помогают и позволяют найти хорошее. Но это хорошее умирает чаще(не интересно игрокам при расширении прототипа), чем живёт. Хотели обычный платформер. Довольно примитивная штука же? Что там делать даже 1 прогеру пол года? А получилось так, что переписывали всё прямо до релиза. А игра поменяла концепцию по ходу разработки пару раз. А релиз остался там же, где был.
Если задача длится 2 месяца, нету никаких этапов и рубежей, чтоб оценить прогресс, то это не проблема геймдева, а проблема декомпозиции и оценки задач.
Так вы разбиваете задачу на исследовательские, которые влезают в спринт и в каждой новой указываете направление исследования, на основе того, что наисследовали в прошлый раз. А если получилось в прошлый раз не только наисследовать, но и понять, что надо делать, ставите задачу на выполнение.
Это же тоже никак не связано со скрамом. Независимо от того, как вы работаете, вы каждый день выходите на смену и что-то делаете, и получаете какой-то результат, который примените в будущем. А если вы не можете сформулировать результат после выполнения работы, то и работа выполнена не была.
Краткий ответ - декомпозиция очень важный инженерный навык, с этим спорить было бы глупо.
Однако разбивать RnD задачи на мелкие атомарные части часто не получается, или получается плохо, так как скоуп задачи заранее неизвестен, и часто может измениться на несколько порядков от оценки.
Можно свалить на неумение разбивать - с этим тоже не спорю. Большинство аргументов в пользу скрама и сводятся к тезису "вы просто не умеете его готовить".
Но если мало кто умеет его готовить, может не в поваре дело?
Удивительно, но вообще не существует такой методологии, куда RnD вписывается как родной. Вернее, есть, и это называется грантовая система. Но это не про разработку ПО.
Если у вас именно в разработке постоянно возникают RnD задачи поперек скрама, то у меня большой вопрос, что вы там такое разрабатываете? AGI?
У нас RnD задачи тоже есть и тоже встречают сопротивление менеджмента. Но их не так много и для этих целей самых скилловых просто на время освобождают от спринтов. Да, команда разработки должна иметь кахонас, чтобы иногда проталкивать свою повестку.
RnD задачи, по идее - стандартная задача поддержки(которую почему-то уж слишком сильно разделяют с разработкой). "Произошло нечто. Нам кажется, что это не правильно и хочется, чтобы не происходило". И тут может быть так, что причина/исправление за 5 минут ищется, а может - что очень долго нужно разбираться, а как и почему оно вообще произошло.
У меня другое понимание RnD. Вот, например, сидим мы на одном инстансе, который еще с MVP остался, а хотим хайлоад, отказоустойчивость, мультиинстанс, доступность 99999. Вот как этот скачок совершить, продолжая работать в проде, - это как раз задача RnD.
Ну а баги расследовать - такое себе RnD. Опять же, если постоянно возникают баги, которые расследуются неделями, то точно скрам виноват?
Если у вас именно в разработке постоянно возникают RnD задачи поперек скрама, то у меня большой вопрос, что вы там такое разрабатываете? AGI?
Банальный highload например. Когда стандартные архитектурные паттерны перестают работать. И на привычные инструменты (СУБД, библиотеки, фреймворки) уже нельзя положиться. Когда не понимаешь, где "горлышко бутылки", даже обложившись метриками сверху до низу. Когда не готов дать внятного теоретического обоснования возникающим проблемам. И всё, что ты можешь - генерировать гипотезы и проверять их экспериментально. И когда внезапно выстреливает самая безумная и неперспективная гипотеза, проверить которую решились от отчаяния. Вот какой тут нахрен скрам?
подготовка материала по best practice решения RnD задач - менеджеру нужно объяснить, что "это другое"
брайншторм гипотез, взвешивание каждой - 1 день
задача на исследование каждой гипотезы - покрытие метриками - фиксирование результат(не важно удачного или нет) - 1-2 дня на каждую гипотезу
груминг фикса
а тут уже дальше технические задачи
что-то такое я предоставлял менеджеру.. )
Ну, генерируйте и проверяйте. Но вообще-то в хайлоаде вполне себе часто видны бутылочные горлышки.
Я прочитал ветку и у меня впечатления, что люди, жалующиеся на скрам и приводящие примеры, чаще не видят, что проблема не в скраме, а в их подходах и, возможно, уровне компетенций. Как следствие идёт перекладывание ответственности на "внешнего врага".
Опять же, даже если мы берём за константу, что вы правы и всё так и есть и даже если скрам вам вообще не подходит, это не делает его хуже и уж тем более раком. Он всё ещё просто не подходит вам.
В самом скраме ничего плохого нет. Раком его делают люди, которые по умолчанию пихают его куда можно, и куда нельзя. И религиозные фанатики, доводящие рекомендации скрама до абсурда.
PS
В нескольких своих проектах я сам лично вводил разработку по скраму. И ничуть об этом не жалею. Просто там он был по делу.
Именно так! Если команда берет задачу и 2 месяца даже не знает как начать решать - зачем брала то?
Если задача не имеет решения для конкретной команды - не поможет никакой скрам. Но, возможно, скрам поможет выявить этот факт побыстрее.
Удивительно, но вообще не существует такой методологии, куда RnD вписывается как родной.
Никогда не работал в чистом R&D, поэтому возможно предположу что-то совершенно неправильное. Поправьте меня тогда, пожалуйста, но мне кажется, что Канбан зайдет в R&D на ура. У вас имеются некие задачи. Срок выполнения этих задач очень размытый, и не факт, что каждая вообще может быть выполнена на 100% В то же время имеется ограниченное количество ресурсов (ученых, доступного времени на лабораторных установках и т.д.), поэтому нельзя допустить, чтобы в работе было одновременно 100500 задач, т.к. это будет крайне неэффективно. Соответственно, мы имеем доску задач с колонками:
Общий список задач, над которыми еще не начинали работать, но возможно будут взяты в работу. Количество задач нелимитированно.
Список задач которые решено взять в работу, но работа над ними еще не начата. Количество от нелимитированного, до некоего предела, чтобы не получилось очень большого списка.
Список задач, над которыми ведется работа. Количество жестко лимитировано. Нельзя взять в работу новые задачи, пока не решены предыдущие
Время решения каждой задачи неограниченно. Или ограничено неким приемлемым для всех логическим пределом (нельзя решать одну задачу год, или 10 лет и т.д.) Такая организация не подходит для R&D?
Если у вас именно в разработке постоянно возникают RnD задачи поперек скрама, то у меня большой вопрос, что вы там такое разрабатываете? AGI?
Можно много чего - статический или динамический анализ кода, компиляторы (например для нового языка), формальные доказательства корректности программ, профайлеры, линтеры и все такое. Например в статическом анализе кода (нормальном), используется, так называемое символьное выполнение (не путать с обычным), так вот, полностью его, на реальной программе выполнить невозможно (экспоненциальный рост сложности), поэтому приходится постоянно искать приближение к идеалу, и это - terra incognita
Ну вот честно говоря, у меня почти все задачи RnD полностью или с элементами. И, кмк, элементы встречаются всегда в работе программиста.
Для начинающих это любая задача с вопросом "как?", коих... все. Потом становится всё лучше, но появляются сторонние проблемы. Баги IDE, системы, фреймворков и т.д. Чем дальше, тем больше таких проблем. И решает эти проблемы тот у кого опыта больше вырулить на опыте и общих знаниях, т.к. другие просто не справятся за адекватные сроки. Я одинаковых задач то знал буквально по пальцам руки. Даже если называются одинаково, то делались принципиально по разному через год.
PS: сам я в геймдеве больше работал. Может в других сферах и иначе, но что-то сомневаюсь, что там простая перегонка json-чиков для кодеров.
Но если мало кто умеет его готовить, может не в поваре дело?
Когда я занимался джедайскими техниками, то заметил один удивительный факт. Люди думали, что навык планирования зависит от инструмента.
Пример: У меня проблемы с планированием, а я вижу как хорошо у Васи получается планировать с помощью Jira (или Notion, или Singularity). И начинаю думать, что я научусь планировать так же хорошо как Вася как только начну применять его инструмент.
Только это так не работает. Я не стану хорошим фотографом от того, что куплю себе крутой фотик. Для этого нужно что-то ещё, кроме инструмента, а именно умение увидеть и поймать хороший кадр. И от перехода в Jira у меня не появятся навыки планирования.
Сдается мне, что с декомпозицией та же история. Любой процесс разработки будет идти сложно (хоть ватерфол, хоть скрам), если вы не умеете декомпозировать. Однако я предполагаю, что в скраме проблема с декомпозицией будет лучше видна.
Но многие продолжают думать, что переход на скрам автоматически научит людей декпомозировать/планировать/делать то, что они раньше не умели делать.
И в этом проблема. В ложной связке "я купил пианино - и теперь я классный пианист". Или "Стоит мне перейти на скрам - я сразу стану таким же крутым разрабом как тот чувак"
В целом это основная причина плохой готовки скрама. Что кроме скрама надо знать и уметь много чего, о чем не говорят в силу того, что это сложно и неочевидно. А среднестатистический тренер находится в ложной связке "сейчас введем процедуры дейли, демо и ретро, и тогда научимся всему тому, чего раньше не умели". При этом этот же тренер даже не осознает, что среди навыков, которым надо научиться, может быть умение декомпозировать. И не знает как научить декомпозиции. Но надеется, что на ретро все такие моменты подсветит команда. И та же команда придумает как научить декомпозиции.
RnD задачи разбиваются не полностью на мелкие атомарные части, а только выделяются те части, которые можно взять в ближайший спринт. Перед следующим спринтом задача целиком пересматривается и делается следующее выделение. Зачастую то, что вы делали в предыдущем спринте, полностью выбрасывается, и это нормально, поскольку в этот момент вы лучше понимаете, что надо делать, чтобы вывести фичу.
Собственно, это и есть суть Скрама.
Последний абзац - ключевой, когда чужая неспособность всех на дно тянет, вместо саморазвития, как минимум.
Чаще всего проблема не с методологиями, а с людьми, которые эти методологии применяют. Поработал разок с каким-нибудь упоротым менеджером, а потом ходишь рассказываешь про ужасный скрам. Ну, бывает :)
Когда в руках молоток, весь мир состоит из гвоздей. К сожалению Скрам воспринимается многими как тот самый молоток. Если к этому еще добавить типовое понимание Скрам по принципу "Там есть спринты и оценка эффективности. Любая задача должна быть завершена за один спринт", то на выходе получаем адскую жесть, после которой люди начинают шарахаться от слова Скрам как черт от ладана. Если же к этому добавить, что найти нормального Скрам-мастера еще сложнее чем нормального менеджера проектов, то результат отношения людей к подобной псевдо-Скрам организации процесса абсолютно предсказуем.
Знаю пару особо упоротых случаев, когда дэйлики использовались начальством для штрафов и наказаний. Ведь как удобно, когда народ сам говорит о проблемах: не надо даже искать кого наказывать. Т.е. некий Вася сказал на дейлике, что у него по таким-то причинам затормозилась разработка и все будет реализовано с задержкой в сколько-то дней. Васю немедленно карают, т.к. он по мнению начальства плохо работает. Что в результате думает о Скрам Вася, можно описывать только ненормативной лексикой.
Проблема в том что упоротых менеджеров слишком много. Так и не встретил адекватных. Везде всякие скрамы и аджайлы применяются как попало.
Ушёл в итоге нафиг из большого ИТ и сам себе техдир, строю свое ИТ в небольшой компании.
я сам лишь со стороны поддержки этого всего знаком, но вот со стороны впечатление такое, что менеджеры просто берут либо тот инструмент, которым они умеют пользоваться (типа "всегда работал в скраме, не хочу канбан - там ниче непонятно") либо тот, который именно им удобен. Не смотря на необходимость и/или удобство для команды конкретно этого инструмента
да и без всякого скрама, меня лид HR вгонял в ступор, обозначая огромную бесформенную гига-задачу на "подумать" и мгновенным вопросом - сколько тебе нужно времени на нее?
Я долгое время думал, что это со мною что-то не так, и наверное когда-нибудь я научусь их оценивать... (а там, например, на одну только четкую формулировку задачи из этого бесформенного может уйти не одна неделя) И вот я стою, представляю, что это может занять от 1 минуты до бесконечности - и прямо так в лоб и отвечаю - может завтра сделаю, а может через год - не знаю)
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Простите, но вышенаписанное абсолютно неверно. Скрам создан как противовес водопадной разработке и нужен в первую очередь как раз для задач, когда мы (или заказчики) сами точно не представляем, что именно хотим получить. Когда требования и планы могут меняться каждый месяц. Когда сам заказчик сначала говорит сделать "А", а потом через пару недель приходит и говорит, что они опробовали "А", и лучше переделать его в "Б". Или когда у нас есть 100500 теоретически требуемых фич, а порядок их реализации (и нужна ли реализация вообще) определяется по факту их реального использования в поле. Легкость или сложность оценки задач при этом вообще не важна. Описанное вами является не Скрамом, а, к сожалению, очень типовым случаем, который представляет собой водопадную разработку, завернутую в псевдо-Скрам. В вашем сценарии не имеет никакого значения, будет задача реализована за 2 спринта, или за один, т.к. конечная цель неизменна: реализовать заранее определенный заданный функционал. В такой ситуации Скрам вообще не нужен, т.к. если у нас нет изменений требований в процессе разработки, то нам не требуется Скрам. Если я буду писать софт для управления ядерным реактором, то использовать там Скрам не имеет никакого смысла, т.к. все требования к его функционалу жесточайшим образом уже прописаны на 100500 листах документации, и никаких отклонений изначально не планируется и не допускается. А вот если я буду разрабатывать игру, то Скрам там зайдет просто идеально, т.к. изменение требований может происходить чуть ли не каждую неделю, и ни разработчики, ни сама целевая аудитория заранее не могут 100% быть уверены, что понравится, а что нет.
Когда требования и планы могут меняться каждый месяц...
Вы сейчас описываете не скрам, а аджайл манифесто.
Скрам то изначально и задумывался действительно как противовес ватерфолу и как одну из реализаций идеи гибких методологий. Но со временем вырос в большой корпоративный карго-культ.
"Scrum is an agile project management framework"
https://www.atlassian.com/agile/scrum
Скрам - это одна из аджайл методик, которых довольно много. Скрам, Канбан, Скрамбан и т.д. А то, что он вырос в карго-культ (как вы абсолютно верно написали), как раз и является причиной всех мучений автора статьи.
который представляет собой водопадную разработку, завернутую в псевдо-Скрам.
Я всегда думал, что если скинуть всю шелуху, то весь аджайл - это серия коротких (длиною в спринт) вотерфолов. Буду рад ошибаться.
Могу вас одновременно обрадовать огорчить :)
Вы на 100% ошибаетесь, когда понимаете Скрам как "серия коротких (длиною в спринт) вотерфолов "
К сожалению 99% "внедрятелей Скрама" именно так его и понимают + дэйлики, которые часто длятся по часу каждый день, где внезапно могут начать решать любые проблемы и т.д. В результате народ совершенно справедливо шарахается от Скрам как черт от ладана.
Проблема на мой взгляд состоит в том, что есть два основных ресурса, связанных со Скрам, которые отвечают на вопрос "как", но абсолютно игнорируют вопросы "в каких случаях?" и "зачем?"
Agile Manifesto
https://agilemanifesto.org/iso/ru/manifesto.html
Собственно документация по Скрам
https://www.scrum.org/
Игнорируют они эти вопросы потому, что авторы этих методик прекрасно себе представляли, для решения каких конкретных проблем они создаются, и совершенно не рассчитывали на то, что успех данного подхода в его конкретной нише приведет к настоящему карго-культу, когда Скрам пихают везде и всюду, при этом не имея ни малейшего представления, как он на самом деле должен быть организован, и зачем он нужен.
Дополнительных проблем добавляет то, что другие аджайл методики, не документированы практически никак. Т.е. есть те, кто в теме, и знают, как и когда ими пользоваться, но эти знания передаются исключительно коллегам во время работы. Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности. Между тем имеется целая охапка только наиболее популярных базовых аджайл методик: Scrum, Kanban, Scrumban, Feature-Driven Development (FDD), Extreme Programming (XP)б Dynamic Systems Development Method (DSDM), и еще масса менее известных.
Теперь конкретно про Скрам и ваше заблуждение. Я, разумеется, не могу тут пересказывать всю документацию, но это и не надо. Основной проблемой, которую решает Скрам, является разработка с заданием "Сделай то, не знаю что". Заказчик представляет, что он хочет, в самых общих чертах (хочу программу торговли на бирже, хочу шутер и т.п.), т.к. не имеет опыта, не знает, что понравится его аудитории, как будет работать его персонал, какие конкретно процессы появятся во время и т.д. и т.п. Как эту проблему решает Скрам (очень короткое и поверхностное описание). Мы пилим очень небольшой функционал в течении короткого времени (тот самый спринт) и сразу отдаем его заказчику на обкатку. Заказчик играется с полученной версией и дает отзыв в виде обратной связи, что и как надо поменять, а команда немедленно (уже в следующем спринте) реагирует на этот отзыв. Т.е. имеем список а-ля (просто как пример)
Фича A отлично подошла, но там есть пара багов. Вот баг-репорты
Фича B получилась неудобной в использовании, уберите ее. Вместо нее нам срочно нужна фича X, которая ранее была с очень низким приоритетом. С этого момента бросьте все силы на ее разработку, что мы получили фичу X как можно скорее
Фича C в общем неплохая, но там надо поменять вот это и это. Эти изменения важны, но их приоритет ниже чем у фичи X
Понимаете глобальную разницу между отписанным вами "серия коротких (длиною в спринт) вотерфолов" и данным процессом?
Во-первых, если у нас нет нужды менять функционал, и заказчик точно знает, что он хочет получить, что нам не нужен Скрам. Нам необязательно использовать водопад, возможно лучше подойдет другая аджайл техника. Чаще всего это Канбан или Скрамбан (надо смотреть ситуации). Но вот Скрам нам точно не нужен. Более того, даже если мы точно знаем, что функционал будет меняться на ходу, то и здесь Скрам не всегда оптимален. Повторюсь: это конкретный инструмент, созданный для решения конкретной (хотя и достаточно часто встречающейся) проблемы. Если я буду пытаться проделать отверстие в доске при помощи рубанка, это не значит, что рубанок плохой. Это значит, что я - идиот, который использует инструмент не по назначению
Во-вторых нет никакого водопада. Мы не разбиваем один большой отрезок разработки на кучу маленьких, а заказчик видит продукт в самом конце.
В-третьих заказчик принимает участие в разработке наравне с командой. В водопаде мы берем задание и заказчик может идти спать до даты релиза. В Скраме такое в принципе невозможно, т.к. для разработки нужно прямое и постоянное участие заказчика в процессе.
В-четвертых, у нас нет и не может быть сколько-нибудь долгого плана по работе, т.к. никто не знает, что будет разрабатываться даже в следующем спринте, не говоря уже о следующем месяце или квартале. Горизонт планирования - один спринт (обычно 2 недели)
И еще забавный момент. Если спросить "внедрятелей Скрама", какой длины должен быть спринт, то 99% ответов будет: "2 недели". Но если спросить "А почему именно 2 недели? А можно короче или длиннее?", то ответа не будет., т.к. у них нет ни малейшего понимания о вышеописанном процессе. На самом деле ответ очень прост, если знать вышеописанное: по результатам практического использования выяснилось, что 2 недели - наиболее оптимальный срок для заказчика, чтобы обкатать новую функциональность и дать по ней отзыв. Неделя - слишком короткий срок (хотя иногда встречаются проекты, где неделя оптимальна), а 3 недели и тем более 4 - слишком долгий срок без обратной связи, за который можно успеть наворотить массу ненужного заказчику функционала.
> что 2 недели - наиболее оптимальный срок для заказчика
...а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?
Потому что это очень сильный критерий применимости скрама.
абсолютно игнорируют вопросы "в каких случаях?"
Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом
немедленно
на реальных или идентичных реальным задачах
то вот и получился критерий "не тот случай"
а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?
Не в настолько явном виде. 30 дней прописаны в явном виде, а вот насчет времени для обкатки прописаны в виде "Product Goal". Тут мы опять приходим к тому, что создатели не описывали некоторые очевидные для них вещи. "Product Goal" - заказчик доволен текущей версией продукта. Он доволен, если успел ее обкатать и дать отзыв, что там надо поменять. А для этого ему нужно время и т.д.
https://scrumguides.org/scrum-guide.html#the-sprint
Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом
немедленно
на реальных или идентичных реальным задачах
то вот и получился критерий "не тот случай"
Именно так. Только под "пользоваться" надо, разумеется, понимать тестовую обкатку с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.
с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.
Первое требует второго. Хотя, конечно, второе не гарантирует первого.
"В лабораторных условиях" я и сам могу протестить, мне для этого даже и QA не нужен. А реальные задачи вне боевого не тестируются. У покупателя тоже нет лишних сотрудников, которые будут буквально повторять все реальные задачи обычных сотрудников на отдельном контуре.
...и это я ещё про "плавающие ошибки" не говорю ;-)
Первое совершенно не требует второго. Вы путаете тестирование в смысле тестирование на наличие багов и тестирование функционала. Под тестированием в Скрам имеется в виду именно функционал, а не ловля багов. Для тестирования функционала совершенно необязательно выкатывать его в прод. Как в Скрам организуется качество разработки (в смысле отлова багов) - это отдельная большая тема
так чтобы понять "удобно или не удобно" - опять же требуется долгосрочная работа по реальному, каждодневному сценарию.
то, что покажется удобным, в течении 5 минут, может оказаться нифига не удобным за 5 часов. То, что кажется удобным при тестировании одной функции, может оказаться неудобно, когда надо выполнять разные функции (в том числе никак не относящиеся к изменённому функционалу).
условно, в качестве фичи для фастфуда выкатили кофе-машину, в которой оператор работает на площадке, на которую надо по лесенке подниматься. Пока оператор тестирует ТОЛЬКО изменения - всё зашибись. А вот как только из тестового контура передеплоим в боевой, где надо продавать не только кофе, - сразу становится плохо. Но в чистой теории, конечно, если покупатель выделит несколько сотрудников которые в full time будут повторять работу других сотрудников и ничего кроме этого - тогда можно и на тестовом. Либо частичный деплой, берём 5% сотрудников покупателя и переключаем их на работу с тестовой сборкой в реальном контуре.
будь оно иначе - не требовалось бы две недели на спринты давать, хватило бы полдня.
Мне кажется, у нас есть глобальное недопонимание, т.к. некоторые очевидные для меня вещи, для вас неочевидны :) Разумеется, некоторые версии выкатываются в реальный прод после соответствующих тестов на баги. И если по результатам реального прода будет выявлено, что какая-то уже одобренная фича не подходит, то она снова будет изменена. Проект в Скраме не является чем-то застывшим, в.т.ч и уже одобренный функционал. Абсолютно любой функционал может быть изменен в любой момент, если окажется, что он не устраивает заказчика. Это процесс продолжается до тех пор, пока заказчик не будет удовлетворен результатом и / или пока у него есть время и деньги на разработку.
Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности.
Канбан неплохо описан в книгах по управлению производством, правда там отдельный упор на вытягивающее производство, а это далеко от разработки ПО
Может быть я как-то неправильно прочитал Ваш комментарий, но, тем не менее, я из него не смог понять, чем, с Вашей точки зрения, сценарий развития событий в рамках одного спринта существенно отличается от каскмдной модели?
Вы говорите о неопределённости для продукта в целом, об обратной связи. Но разве это не вопрос масштаба?
Нет, если говорить о получении финансирования от внешнего заказчика, который пытается вывести продукт на рынок с высокой конкуренцией, то можно говорить о важности коротких интервалов, необходимости оперативно реагировать на настрой конечного потребителя продукта и рисках проиграть гонку конкурентам.
Но разве это не вопрос масштаба?
Разработчики, к примеру, Windows 95 тоже не знали, что линейку свернут в пользу Windows NT и понятия не имели, какой должна получиться Windows 11. Чем это концептуально отличается от описанного Вами? "Спринты" в несколько лет вместе двух недель? Долго ждали обратной связи?
Так это, опять же, вопрос масштаба.
Необпределенность требований (на отрезке в 30 лет) была? Была. Обратная связь важна? Важна.
Что тогда остаётся от "спринт - это вовсе не маленький водопад"? Условное деление на "готовый продукт" и "кусочек будущего продукта"? Ну так, это опять вопрос масштаба.
Или, всё-таки есть принципиальная разница?
Чем это концептуально отличается от описанного Вами? "Спринты" в несколько лет вместе двух недель? Долго ждали обратной связи?
В т.ч. и это - принципиальное отличие, о чем я писал в этой ветке выше. Продукт меняется не через 100 лет, когда все уже перестало соответствовать условиям, а прямо сейчас.
Так это, опять же, вопрос масштаба.
Нет. Это - принципиальное отличие. Пока вы в вашем "большом масштабе" через -цать лет отреагируете на изменения, эти самые изменения уже 100 раз успеют поменяться и выша реакция не будет соответствовать текущим реалиям. Весь смысл именно в мгновенной реакции на изменения окружающих условий здесь и сейчас. Поэтому в Скрам явным образом прописано, что 30 дней - максимальный размер спринта, а на практике спринт обычно длится 2 недели, т.к. за месяц можно успеть наворотить массу ненужного
https://scrumguides.org/scrum-guide.html#the-sprint
Я, всё-таки, про логику рассуждения спрашивал, совсем не о том, как сделать востребованный продукт.
Вы говорите о том, что есть принципиальная разница между получением обратной связи и реакцией на изменения на коротких временных интервалах и на длинных. И, вероятно, о том, что без оперативной реакции и корректировки направления разработки будущего продукта можно получить то, что заказчику совершенно не пригодится.
И вот это как раз понятно.
Но эта ветка начилась с того, что в рамках одного спринта (вне зависимости от его продолжительности) можно увидеть ты самую каскадную разработку.
Но Вы говорите, что нет, это не так потому, что... И далее говорите о вещах которые уже за рамки спринта выходят. То есть, исходный тезис забыт.
Я понимаю, что можно сказать, что я к словам придираюсь (хотя, Вы там человеку намекнул, что он не прав, хотя по его исходному утверждению ничего не сказали, так что, вряд ли это стоит считать придиркой) или что рассуждения о сферических спринтах в вакууме не имеют никакого смысла, но мне кажется, куча людей занимается рассуждениями на тему "Agile vs Waterfall" не замечая, что это классическое сравнение темплого с мягким.
Теперь я понял, что вы имели в виду. Извиняюсь за непонимание. Да, формально в рамках одного спринта у нас водопад. Т.е. вот эти типовые две недели у нас ведутся с заранее согласованным планом, и если рассматривать их обособленно от всего остального, то мы получим 2-недельный водопад. Тут, конечно, можно начать углубляться в детали, что, например, в Скрам нет заданных ролей (т.н. трансформация Т ролей в Х роли), соответственно, по сравнению с водопадом там, например, нет отдельных тестировщиков для ловли багов и т.д., но в целом, да - вы правы: формально получаем 2 недели водопада.
весь аджайл - это серия коротких (длиною в спринт) вотерфолов. Буду рад ошибаться.
Вы так говорите как будто это что-то плохое)
Ну, если взять только третий принцип, творчески его перефразировать, а остальные 11 выкинуть - то да :)
Но уже наверное доллжно быть понятно, что оставив только 1/12, вы наверное пришли к чему-то другому :)
Проблема не в методологиях, а в их применении. Если шуруповертом забивать гвозди, то это не шуруповерт плохой, а дурак тот кто взял его в руки. Скрам хорошо ложится на продуктовые компании с плановыми релизами. Но абсолютно не подходит для корпоративных разработок и внедрений где важні сроки и бюджеты. Канбан хорошо подходит для поддержки. А какой нибудь XP для проектов которые прое.... и уже подгорает ж.....
Скрам - это новый ватерфол
Waterfall: *не существует*
Идеологи Agile: всю жизнь воюют с Waterfall
Ненавистники Agile: начинают применять "Waterfall"...
Проблема ведь не в скраме. Возможно, проблема в том, что "фасилитаторы встреч" вдруг начали называться "проджект-менеджерами". И внезапно все начали думать, что достаточно прочитать небольшую книжечку, внедрить некоторые ритуалы из неё, и вот оно – управление разработкой! Простое, удобное, осилит даже обезьяна. Теперь мы называем её скрам-мастером.
А может проблема в том, что "настоящие" проектные менеджеры внезапно повымирали и не оставили потомства. Новое поколение же как слепые котята тычутся в булшит-слова "Waterfall", "Agile", "Scrum" и "Kanban". Ни одно из которых не имеет отношения ни к проектному менеджменту, ни к управлению разработкой.
Scrum — рак, убивающий индустрию
Готов подписаться под каждым словом!
Когда я это говорил 10 лет назад, мне рассказывали про то, какой плохой водопад и что я ничего не понимаю. Ну, или что надо попробовать и сам все увидишь!
Водопад за 10 лет избавился от своих проблем?
Я за 10 лет не видел водопада ниразу. Я видел только сектантов, рассказывающих об ужасах водопада, и почему я должен принять именно их религию.
"Водопада" никогда не существовало. Каскадная модель вот прям с момента её первого упоминания в 1956 – это гипотетический антипаттерн, с которым сравнивают все остальные подходы.
Как люди разрабатывали между 1956 и 20...-каким-то, т.е. до появления Agile манифеста и сопутствующих фреймворков?
Вопрос, конечно, интересный. Но ответ на него – НЕ водопад.
Так что да. Думаю, не избавился ;)
"Водопада" никогда не существовало
В молодости работал в аутсорсе. Ко мне приезжал документ с описанием требований к фиче. Я писал дизайн документ, он проходил ревью и утверждение. Потом документ с тест кейсами. Потом писал код.
Если это не водопад, то я даже не знаю... Правда, это было больше 10 лет назад.
Если это не водопад, то я даже не знаю...
Я, пожалуй, неточно выразился, позвольте чуть уточню.
"Водопада" никогда не существовало как некой целостной "модели управления разработкой ПО, которой все раньше придерживались". Напротив, все работы, на которые ссылаются современные "евангелисты водопада", описывали эту модель как гипотетический антипаттерн и предостерегали от её использования. Повторюсь – вот прямо в 1956. Т.е. уже в 50-х были более адекватные и прогрессивные методики, задолго до всяких там аджайлов и скрамов.
Существует ли водопад сейчас? О, конечно. Посудите сами – люди несколько десятилетий воевали с водопадом как с ветряной мельницей. К чему это привело?
Ну вот представьте, к вам несколько десятилетий приходят люди и говорят – "смотрите, у нас есть Agile/Scrum/любой булшит, который намного лучше водопада, попробуйте его". Вы пробуете – и не получается. Реакция? "Ну к чёрту, может всё-таки водопад?"
Помножьте на массовое невежество в области проектного менеджмента, которое в последние годы поразило мир подобно чуме. Ну вот не знает человек (некий гипотетический ПМ) других слов, кроме Agile и Waterfall, так что и выбор делает между ими двумя.
Так что да, возможно вы работали по "водопаду". Рискованный шаг, но если результат адекватный, то кто вас осудит.
А может быть вы просто работали по обычной неитеративной модели, которую современные ПМы в силу неграмотности по ошибке называют "водопадом"?
Водопада" никогда не существовало как некой целостной "модели управления разработкой ПО, которой все раньше придерживались".
А для кого были писан вагон ГОСТ-ов? Хотите сказать они не применялись в госсекторе и всяких крупных хоз. секторах? Да чего там ГОСТ, в том же PMBOK до середины 2000х итеративные модели не рассматривались.
Ну, собственно, все материалы по управлению разработкой начиная с 1956 как раз предостерегают от использования подходов, применимых к промышленности, строительстве и т.п. в разработке ПО.
PMBOK – это вообще не про водопад.
Нет, если любую неитеративную модель называть "водопадом" – то пожалуйста. Называют же любой итеративный подход "аджайлом" ;) хотя итеративную разработку уже применяли в NASA ещё в 60-х...
Но как я и говорил, это слегка безграмотно. Т.к. "каноничный водопад" довольно жёсткий и содержит ряд искусственно придуманных недостатков, чтобы другие методологии с ним было сравнивать удобно. И если кто-то реально хочет внедрять себе вот прям водопад-водопад, то это карго-культ не лучше скрама, т.к. добавляются ненужные ограничения.
А что такое "каноничный водопад"? Вики под этот термин подводит любые каскадные модели, в том числе в PMBOK-е опиcанные. Думаю большинство собеседников примерно так же используют этот термин: waterfall - каскадные модели, agile - итеративные.
И много есть каскадов, в которых прям вот не возвращаются на предыдущий этап, но проект выстреливает? Ну то есть увидели ошибку в ТЗ в момент производства, но чертежи не правят?
Вики всякую ересь несёт. Как и почти все источники по теме... В то время как в первоисточниках, на которые в т.ч. ссылается Вики, определение водопада довольно жёсткое.
То есть.
Если у вас одна фаза "протекает" в другую – это не водопад, т.к. в водопаде новая фаза начинается строго после завершения предыдущей
Если у вас какие-то фазы выполняются параллельно ну или хоть как-то перекрываются – это не водопад
Если у вас есть такие вещи, как прототипирование, уточнение и т.д. и т.п. – ну вы поняли
Вот это навскидку, что получилось вспомнить.
Кстати о PMBOK... Надо будет перечитать старые версии. Потом если что вернусь с более развёрнутым ответом :)
Думаю большинство собеседников примерно так же используют этот термин: waterfall - каскадные модели, agile - итеративные.
А я уже говорил, что современные проектные менеджеры делятся на три вида – бесполезные, неграмотные и несуществующие? :))
Было бы интересно, если бы вы привели ссылки на первоисточники, которые упоминаете.
Дак можно начать с той самой презентации Бенингтона от 1956, про которую написано в Вики...
Но если вы не против, я лучше и правда всё перечитаю, освежу и обновлю свои знания, а потом вернусь к вам :)
Почитал тот доклад. Кому интересно, вот он (15 стр). Слово waterfall, кстати, в докладе вообще не используется. Вся суть доклада о том, что большие программы (которые он определяет в кол-ве инструкций в районе 100 000) дорого стоят, сложно модифицируются и жить так дальше нельзя :)
При этом в общих чертах описана некая каскадная модель разработки.
Не думаю, что этот первоисточник можно считать каноническим определением waterfall-а, т.к. там ни термин не встречается, ни конкретного описания процесса нет, а только в общих чертах, ну и в конце-концов не определено никакого запрета на "перетекания", параллельность, уточнения и прототипирования.
водопад как 10 лет назад не существовал примерно нигде, так и не существует...
Вся статья пропитана субъективным восприятием по типу
"я из за не умения пользоваться молотком размаждил себе палец, по этому молотки это зло созданное чтобы ломать пальцы"
В самом скрам нет проблем, это узкоспециализировнный инструмент, подходящих для конкретных задач, а для каких то неподходящий.
Проблема в людях, которые относятся к нему как к унивирсальной пилюле, сующтх скрам туда где он не нужен.
Потом его" адаптируют" и получается нечто что можно охарактеризовать как "работа по спринтам"
А дальше пишут статьи что скрам плохой...
Ну когда у тебя и пм и аналитик и скрам мастер это один и тот же человек, а какой эффективности может идти речь?)
Вот всегда было интересно - а зачем нужны одновременно ПМ и срам мастер на одном проекте? Дейлики по очереди проводить и задачки по борде двигать?
ну в теории, ПМ(Product Manager?) должен быть адвокатом бизнес/клиентов команды, в то время как скрам мастер - помощником команды. Объединять их в одну роль, значит создать конфликт интересов.
Ну и по объемам - для маленькой команды с ограниченным потом задач можно еще найти баланс в одном человеке, но когда будет много задач, несколько команд(в теории SM должен поддерживать максимум 2 команды, на деле может быть и 5-6) - то тут будет банальный завал + желание по пути наименьшего сопротивления.
PM -- по умолчанию всегда Project Manager, так же как "филфак" по умолчанию филологический, а не филосовский.
Скажем, PMBOK -- про управление процессами, а не продуктом.
Объединять их в одну роль, значит создать конфликт интересов.
Забавно, что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.
PM -- по умолчанию всегда Project Manage
Я бы тоже рад так думать (меньше путаницы), но в большинстве современных американских компаний, PM это Product Manager. А чистый Project Manager уже давно вымирающий вид. Даже TPM - это Technical Program Manager.
что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.
ну у бизнеса и разработки слишком разные интересы. Дай волю бизнесу, разработка будет в мыле и работать 24х7.
А дай волю разработке, так продукт будет делаться годами и так и не выйдет в прод. Поэтому требуется конфликт интересов и переговорный процесс, чтобы люди про-бизнес и про-разработка могли вести переговоры и удерживать этот самый баланс.
Правильно. Но мы начали разговор выше о том, почему объединение роли представителя заказчика и роли представителя разработчиков в одну персону, создает внутренний конфликт интересов и может закончиться не сильно хорошо.
Cоздает внутренний конфликт интересов и может закончиться не сильно хорошо.
Почему "внешний" конфликт интересов лучше "внутреннего"? Я же не просто так привёл пример про DevOps. Я застал времена, когда продуктовых разработчиков премировали за изменения, а системных администраторов за отсутствие проишествий. Надо ли говорить, что изменения в коде -- главный источник проишествий в проде, который системные администраторы едва ли контролируют? Продуктовым разработчикам же часто не хватало мотивации понять боль ops коллег, они жили несколько в разных загонах и, порой, друг друга не понимали.
В итоге я регулярно наблюдал встречи, когда продуктовая разработка просит ускорить релизы, а эксплуатация их тормозит, как может. Когда разработка хочет добавить побольше компонентов-зависимостей, а сисадмины стараются умерить их пыл.
Глядя на то, что произошло после, мне очевидно, насколько продуктивной оказалось замена устаревшей командной топологии с "внешнего" на "внутренний" конфликт интересов, а именно, на разработчиков, которые сами релизят и сами просыпаются по ночам от звонков мониторинга и платформенную команду, которая позволяет им делать всё это, не разрываясь от когнитивной нагрузки.
Теперь разработчки сами решают (в том числе с помощью методик вроде SRE Error Budget), когда надо начинать разгребать влияющий на надёжность технический долг, временно переключив деятельность с разработки бизнес-фич, на стабилизацию продуктов).
В руках мастера любой инструмент — грааль. Это я так ласково о том, что если не получается танцевать, то, возможно, дело не в балетках. Самое важное в любом фреймворке — это: понимать, когда нужен не он; и правильно внедрить.
Когда я сталкиваюсь с тем, что моя работа не может уложиться в какую-то методологию, и меня спрашивают, смогу ли я селать работу по методологии, я объясняю какую работу я должен сделать (написать код) и спрашиваю менеджера (обычно методолгист - менеджер)
- я рассказал, какую работу я должен сделать, как мастер методологии расскажите мне пожалуйста как мне уложить мою работу в эту методологию?
Я просто перестал считать себя супер профессионалом Скрама (в частности), и что я все понимаю и все в нем знаю. Профессионал Скрама - менеджер, я, как профессионал написания кода пробую найти с ним, как со специалистом в другой области контакт.
На самом деле проблемы у многих команд всего 2: 'Заставь дурака Богу молиться, он себе голову расшибет' и 'Бери ношу по себе, чтоб не падать при ходьбе'
Из личного опыта. Во многоих, очень многих случаях скрам превращается в карго культ.
очень много букв, но посыл понятен. Тем не менее, после короткого практикума в скрамтрэке, я наконец понял куда этот скрам пихать надо. Если коротко — в нулёвые проекты у которых есть только идея из которой начинает порезаться проект. Как только проект набрал ход — то там уже рулит канбан.
Проблемы начинаются когда команда не понимает когда какую методолгию применяют, что менеджмент, что линейные исполнители, тогда начинаются проблемы
Однако ловкие продавцы церемоний усвоили только часть:
Добро пожаловать в реальный мир.
Именно так всегда и происходит с прекраснодушными мечтами о построении идеала - в реальности, мечты воплощаются не так как мечтали мечтатели.
Важно понимать, что есть две разные беды:
Кто-то неправильно понимает, как использовать методологию, где она применима и зачем нужна. Это не так плохо, можно учиться и пытаться научить людей
Кто-то хорошо понимает, что он неправильно что-то применяет. И делает это очень осознанно, так как это позволяет получать зарплаты/премии, руководить все большими коллективами, выступать на мероприятиях, писать статьи и книги. Практически вокруг любого бизнеса появляется толпа людей, которые хотят отщипнуть себе деньги, как только они появляются. В ИТ и в управлении проектами сейчас просто безумное количество денег, и неудивительно, что рядом летают те, кто их хочет. В такой ситуации практически бесполезно писать статьи о том, почему «ХХХ - плохая технология/методология», важно четко понимать, что именно и зачем вы делаете
Поэтому важно понимать, с кем вы работаете - с человеком, который делает что-то по ошибке, либо с тем, кто зарабатывает на этом деньги
Зачем мы используем скрам?
Потому что надо что-то использовать, а тут есть привычка и отлаженные "церемонии и инструменты". Что тоже неплохо.
Нюанс в том, что под это определение не попадают RnD задачи, то есть задачи, в которых присутствует большая доля неизвестного
Так их туда можно не загонять. В реальности аналитик/архитектор/дизайнер работают все скрама, ну или в спринт-1. Т.е. проблемы нет.
Откройте Agile Manifesto. Вы удивитесь, насколько мало общего такие вещи, как SAFe, имеют с этим документом.
Тут респект за обраащенгие к истокам, к сожалению да. Это проблема и многие реально потеряли "фокус" и понимание зачем
----------------------
Проблема в другом. Люди вообще часто теряют фокус, что и зачем. И по любой методике пинают балду, либо изображают очень занятых на клеточном уровне. Тут не методика нужна, а личный подход
10 часов скрам церемоний в неделю, которые не дают сосредоточиться на выполнении задач, на которых постоянно спрашивают про статус этих задач (хотя статус можно узнать, просто заглянув в Jira).
Это вы сейчас не скрам описали, а что-то другое. Потому что The Scrum daily is not a status pull; if it is - you are not doing Scrum.
Вы мне про теорию, а я вам про практику. Если такого нет, почему я это вижу во многих проектах разных компаний разных стран?
почему я это вижу во многих проектах разных компаний разных стран
Ну значит они используют не SCRUM, а что-то совершенно другое. И соответственно то, что вы описываете, к скраму не имеет никакого отношения.
Потому что везде менеджеры одинаковые и пытаются контролировать процессы? Да, теория разбивается о практику, что люди не готовы терять ощущение контроля. Скрам то тут при чем?
Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать.
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
RnD задачи не вписываются в спринты
Важно разделять этап Discovery и Delivery фичи. На этапе Discovery продакт (или другой стейхолодер) изучает и описывает фичу, а разработчик (техлид, CTO) анализирует ее техническую реализуемость. И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
Однако ловкие продавцы церемоний усвоили только часть:
процесс важнее всего
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить. Как минимум потому что иначе это перестает быть управляемым.
И чем крупнее организация, тем более единообразными хочется делать эти процессы.
Инструменты Kanban, такие как проиретизация задач и WIP limit, дают возможность управлять потоком работы, не прерывая сам рабочий процесс.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер? Потому что если не опираться на размер задачи, то WiP всегда должен быть =1, иначе большие задачи будут висеть на разработчике очень и очень долго.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.
Вы не разбрасывайтесь словами. Kanban! Для автора 33 летний скрам это "новое".
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
Не уверен, что это действительно так. Кроме каких-то совсем маленьких компаний или компнаий с "особым путем", все поголовно используют скрам, многие лишь потому что "ну все так делают".
И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
Наверное можно, мне не доводилось видеть процесс, где это хорошо и повторяемо работает. Я бы хотел такое увидеть и понять, как у людей это получается на постоянной основе.
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить.
К процессам претензий нет, претензия к карго-культизму. Когда процесс не ради решения задач, а потому что надо.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер?
Я бы сказал, что это зависит. Большие задачи само по себе не очень хорошо, и дробление задач оправдано, когда это делается с целью уменьшения энтропии, а не с целью "чтобы влезло в спринт". Не знаю, делают ли так, но не вижу причин не ввести поправку на размер, если конечно мы умеем определять размер.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.
Такие проекты вообще на любую методологию хорошо ложатся. Управлять известным объемом при известном капасити много ума не надо. Сложности (и потребность в методологиях) повышается, когда растут неизвестные, а с ними и риски.
Вот так хорошо начал. Скрам плохо здесь, Скрам плохо там. Я подумал что, вот оно, сейчас приземлят на потребности бизнеса, и.... внезапно "Возьмите Канбан в нем нет оценок" я прямо осёкся.
Скрам отлично подходит для своей среды. Особенно, если вы не знаете куда идти. И особенно если Клиент не знает куда идти и какую цель достигать.
Но в RnD проектах ЕСТЬ ЦЕЛЬ. Просто часто непонятно "КАК её достигнуть". Ну так может сесть и подумать? Для этого даже специально обученные люди были.... как их там?... а вот вспомнил! Архитектор программного обеспечения!
А если вы не знаете куда идти, так может остановиться с просить Клиента, " А ты, вообще, какую проблему решаешь?"
Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:
1. Что происходит?
2. Когда будет готово?
И ему главное чтобы было: Сказал - сделал. Или выполняй обещания или не обещай. Правильные спринты Скрама дают эту прозрачность. Да и неправильные спринты тоже дают это. Только это называется "план-фактный анализ" и проводится каждую неделю. Часто никак даже не называется потому, что в понедельник нужно понять "Чем они будут заняты и почему я должен им платить?"
Вы подаете свой тезис под соусом "скрам за все хорошее и против всего плохого".
У меня нет претензий к скраму как к методологии. Как мне кажется, это хорошая, продуманная и целостная методология, которая была нужна индустрии, особенно энтерпрайзам.
Проблема (и моя претензия) в применении методологии на практике. Когда скрам спускают сверху, не глядя, а что там за процессы у команд. И когда на крики снизу "нам эти спринты только мешают, ну не ложится процесс на них, приходится выдумывать синтетические костыли" им отвечают "вы просто неправильно работаете, надо по скраму, а вы все по-старинке".
Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:
Что происходит?
Когда будет готово?
Ответы на эти вопросы можно найти в Jira; в любой момент времени и в любом формате. Не обязательно всех в шеренгу ставить.
Во первых, Скрам НЕ МЕТОДОЛОГИЯ! А процессный каркас, о чем прямо указано в Руководстве.
Во вторых, Скрам без XP для ИТ-проектов - что пиво без водки.
В третьих - Вы можете сколько угодно смотреть в трекер задач, но бизнес-человек хочет ПОСМОТРЕТЬ В ГЛАЗА и спросить "А не лапшу ли ты вешаешь, мил человек?" . Впрочем из истории Скрама именно эта практика и была вполне успешной (см. в книге Сазерленда) . Потому, что только сравнив план и факт можно задать вопрос глядя в глаза и нужные принять решения и относительно проекта и относительно людей в нём.
Архитекторы - вымерший вид. В некоторых специальных сферах есть мини-архитекторы - тематики
Всем адептам секты "разбиения больших задач на малые" (которых тут много в комментах), я хочу рекомендовать почитать о таком математическом термине как "эмерджентность". Да, конечно, декомпозиция - это важно, нужно, полезно, бла-бла-бла... Вот только, когда вы делаете что-то чуть более сложное, чем веб-форма, вас ждет масса сюрпризов. Просто не кормите себя иллюзиями и не ищите потом виноватых кроме себя. Во многом согласен с автором в отношении к RnD процессам.
Отличные наблюдения - мы в нашей команде придумали специальные RnD спринты:
Копим ижесы в течение определенного времени
Объединяем их в вехи - прорабатываем задачи
Проводим что-то вроде защиты, на которой принимаем решение достаточно ли экспертизы для промышленной реализации
Потом уже запускаем стандартный процесс через скрам
Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.
1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.
наверное, зависит от команды. очевидно может быть не всем.
плюс в процессе обсуждения можно выявить, что кто-то увидит подводные камни неочевидные для остальных, тогда такая оценка увеличивает вероятность выявить нюансы.
ну оценка важна, это факт. Но вот концепция абстрактных сторипоинтов - это дичь. Они не нужны никому, любой кто использует оценку всегда хочет поиметь её в реальных днях.
Ключевое что мы делали на оценке - это убеждались, что команда единообразно понимает задачу. То есть 3-5 это норм, а 2-13 означает, что один хочет поставить костыль, а второй-написать мини фреймворк. И вот тут надо обсудить, а что сейчас реально стоит делать. Порой это реально не очевидно.
(ну и до 8 это футболки, а не фибоначи, 1 у нас был "полденька с перерывом на перекуры")
А так при нормальной нарезке оценка действительно не важна - если всем ставить 1, а факт будет различаться в 4 раза, то статистически на пяти спринтах все утрясется.
Честно говоря даже читать толком не стал – автор или кто там всё это писал явно не понимает о чем вообще речь.
Скрам это лишь обертка от конфеты, а сама методология является формализацией здравого смысла до которого вы всё-равно дойдете, но со временем и опытом. Любой здоровый проект хочешь или не хочешь приходит к тому, что написано в методологии. И это вообще не связано с IT напрямую, это здравый смысл в целом в любом производстве, будь то фабрика, строительство.. или IT.
Поэтому поливать скрам, канбан, и любые гибкие методологии, это просто неумение их готовить которое выражается в превалировании процессов над здравым смыслом в производстве.
Если не работает и есть сложности – разбирайте сложности и руководствуйтесь здравым смыслом. Всё. Все эти процессы, "церемонии", и прочая типовая лабуда сама придет, но будет служить на пользу, а не потому что так положено.
Просто ищите где рвется, вот весь рецепт.
Кажется, автор отлично описал, где рвётся. В проекте, который разрабатывает новые фичи, интеграции и имеет сложность чуть выше, чем «собрать из кубиков готовый функционал», — чтобы провести оценку и декомпозицию задачи, нужно сначала провести ресерч, который будет содержать до половины реализации задачи и при этом сам невозможно оценить. Для проектов, где таких задач несколько больше нуля, — скрам неприменим, но его там всё равно пытаются применить.
Пример задачи — увеличить размер предзагруженного буфера в плеере до 10 минут. Может быть, это xxs и решится одной строкой в настройках, может s, потому что придётся написать и подменить какой-нибудь класс, отвечающий за буфер, а может 2xl, потому что придётся менять библиотеку плеера. И оценить это за час чтения документации не получится — потому что потом окажутся нюансы: ведь строка в настройках работает, но окажется, что в память влезает только 2 минуты, а свой класс не интегрируется в зависимую библиотеку и т. д.
...а потом (я из легаси) окажется, что после увеличения размеров буфера плеера у тебя печать документов на бумагу стала работать с задержкой в несколько часов. Пока не накопится документов страниц на 100 - принтер даже не начинает печатать. Ну вот так оно когда-то получилось, когда скрам и аджайл свели к "сделай просто, чтобы уже завтра продать".
нужно сначала провести ресерч, который будет содержать до половины реализации задачи
А вторая половина - это груминг. Когда задача уже решена, но надо её обмазать проверками ошибок, логированием, метриками, конфигурацией, документацией и прочей фигнёй, нужной для долгосрочного использования, но именно решением проблемы (в узком смысле) уже не являющимся.
Окончание ресёрча и решение задачи (пусть на уровне MVP) - это зачастую синонимы.
P.S. Кстати, вынесение задачи документирования в отдельный спринт/таск *не работает*.
По факту либо ты пишешь полную документацию "сразу в жиру", а весь таск сводится к "переписать из Жиры в Ворд" (но откуда тогда брать человекомесяцы на это?), либо таск на документацию отъезжает на пару лет, а через пару лет какой-то новый техрайтер - с нулевым знанием проекта - приходит разрабам (чьи мозги уже начисто промыты ещё 100500 тасками с тех пор решёнными) и говорит "ну, рассказывайте, что вы там за фигню наворотили два года назад, а я это в Word перепишу, один час вам на всё так и быть разрешу списать".
Но вот действительно - куча народу говорит что "вы не умеете готовить скрам", но показать на своем примере как надо - пока еще никто не показал.
У меня вот недавно была задача по глубокой переработке определенного функционала - ну разбил я ее на части, а толку? Если выложить на прод я могу только все вместе, иначе есть риск что там данные поедут не туда.
Спринты по две недели, а задача вышла на месяц. И что скрам предлагает в таких случаях делать?
Скрам - это ведь когда накидывают задач с лопаты на каждый день и ты бежишь как белка в колесе и нету даже денька расслабиться?
А ещё потом к текущим задачам прибавляются задачи in progress от QA и вообще ни конца ни края не видно задачам.
насчет "бежишь как белка" - это твоё отношение. Можно ведь и по другому посмотреть.
если тебе накидали 100 задач с равным приоритетом - то это твоя свобода и гибкость.
прочитать эти задачи, сгруппировать их для себя (по технологиям, которые нужно вспомнить, по модулям которые надо переписать, по соседним отделам с которыми совместно надо будет решать - как тебе удобнее). Потом берёшь одну группу, по своему выбору, погружаешься в неё один раз и начинаешь пилить "отсюда и до обеда".
конечно, 90% задач пролетают по срокам, но они ВСЁ РАВНО пролетели бы. И твоя реальная ответственность только в ВЫБОРЕ, какие из 10% НЕ будут сорваны.
Собственно, "100 задач с лопаты" это твой личный горизонт планирования себя. Когда ты просматриваешь это список, прислушиваешься к своему самочувствию, и решаешь. Сегодня я "голодный", я хочу закопаться в глубину и нахрен отрефакторить один говномодуль. А завтра я "с похмелья" и трёх переменных в голове не удержу, сделаю я лучше три мелких фикса, которые можно на рефлексах исправлять. И т.д.
Неужели было бы лучше, если бы ты с утра видел ровно две таски, о которых ты ничего заранее не знал, но которые до заката надо отресёрчить, имплементнуть, оттестить и передать в QA ?
Скрам-не скрам не так уж и важно. Проблема вовсе не в скраме, и не в вотерфолле. Проблема в том, что океан нынче побагровел. Конкуренция в отрасли чудовищная. На всех уровнях - как на уровне корпораций гигантов, так и на уровне мелких фирм, и даже специалистов между собой. А при такой высокой конкуренции любая работы превращается в гонку ради самой гонки на износ. Ну а скрам это лишь один из способов эту гонку организовать и придать её хоть какое то подобие цивилизованного процесса. Не было бы скрама, применяли бы старые-добрые методы чайка менеджмента, постоянно орущего начальника и регулярного биться подчинённых палкой.
Детский сад. В нормальном процессе планируются не таски, а работа и результаты. При этом инструменты могут быть любыми Скрам - ОК, Канбан - тоже ОК, банальный эксель с произвольными записями - и то подойдёт, плюс-минус. И RnD планируется тоже нормально. Автору бы спуститься на уровень и узнать, что такое планирование вообще, а потом натягивать на него конкретные методики. Все хотя быть гурами сакральных истин, а всё уже до них давно придумано, только они этого знать не хотят, иначе огонь в глазах погаснет и их идеи не купят.
Проблема не в Скраме как таковом, а в том, что редко где есть хоть какое-то правильное его внедрение и поддержка. Ну не может быть человек с 0 знаний в PM и прошедшего недельный курсы scrum master (для получения CSM), построить какой-либо правильный процесс. Такие курсы должны быть для членов команды, что бы просто понимать общий процесс, или уже для человека с опытом управления проектами.
Scrum это так - общая оболочка. А к нему еще нужен багаж опыта и знания(по объему не меньше классического PMBOK).
Скрам, вотерфол, Канбан подбирают по соображениям атомарности. Кому весь проект сразу, а кому по фиче в день. Атомарность подбирают под жизненный цикл. Например, MVP это вотерфол, а багфиксам со скачущими приоритетами ближе Канбан. Компании часто применяют не какую-то одну практику, а комбинацию их элементов. Но холиварят до сих пор.
Для RnD существуют более подходящие методологии.
Это точно.Например ГОСТ Р 15.101-2021 (и его предшественники). Рекомендую. Обращаю внимание на Приложение А. Практически все значимые научные достижения в нашей стране получены благодаря этой методологии. Но мало кто ее читал и понял, о чем там написано. И еще меньше тех, кто пытался применять на программных проектах.
Что касается SCRAM, не соглашусь. Просто надо понимать условия, для которых применение этого инструмента будет эффективно. На мой взгляд, болезнь кроется в головах рафинированных менеджеров, а не в инструментах.
Лет 10 назад мы просто работали по самым разным методикам, и всё было отлично.
А сегодня сделано следующее: тому, что раньше никак не называлось, а просто делалось, теперь были придуманы англицизмы (совершенно идиотская их заимствованность, что у нас в своём языке не нашлось слов для этого? Тупейшая мода на англицизмы выдает низкий уровень интеллекта и идиотское следование моде...), совершенно придурошное равнение на запад (ну вот нахуа...), при этом "те, кто не в теме этого сленга" - идут лесом - ещё один идиотизм...
Лет ещё через ...цать до людей начнет доходить вся абсурдность и идиотизм такой моды, равно как и очевиднейшая дискриминация по сленгу.
Ещё и HR внедрили - посадили кучу тупых крашеных девиц с уровнем интеллекта хлебушка и деревенским воспитанием (в лучшем случае), все функции которых может заменить бот-скрипт, написанный на коленке за пару часов.
Можете минусовать, но лет через 10 ещё вспомните этот пророческий пост 😏
англицизм это обычный профессиональный жаргон, удобный тем что отсекает лишние контексты.
англицизм - это явно прописанный namespace/scope/module.
переработка может означать что угодно, например печать газеты на бумаге из макулатуры.
а вот refactoring - это конкретно, и crunch - тоже конкретно.
Я говорил немного о другом.
Ожидаемые минусы это подтверждают (что неудивительно 😁)
Одно дело, если в определенном социальном круге используется свой сленг - это совершенно нормально.
Другое - когда этот социальный круг дискриминирует (относится свысока, пренебрежительно, отчуждённо) к тем, кто этот сленг не знает/не использует.
Происходит именно второе, т.е. это чистой воды дискриминация, причём, по совершенно несущественному признаку.
А к каким результатам приводят подобные дискриминации легко видеть, если изучить человеческую историю :)
пробежал глазами по комментариям, и вроде никто не написал правильный ответ.
Программисты:
- дорого стоят
- текучка
- текучка с угрозами для бизнеса, когда уходит сотрудник на котором многое держалось.
Бизнес соориентировался - необщительных сотрудников быть не должно. Об этом фактически говорят на всех докладах. Вы должны позволять себя вас грабить!
Пусть лучше галера плывет в три раза медленнее, но с уходом любого сотрудника коллективный разум пострадать не должен.
Исключения могут быть только для действительно тяжелых стартапов или действительно тяжелой разработки, где требуются фундаментальные или специфические знания, которые зарабатываются потом и кровью путём самообучения или воровства у других, но не на ревью чужого кода. В этом случае разработчиков безопаснее делать совладельцами предприятия.
...а этот понимающий бизнес нанимает техрайтеров, которые сразу по закрытию инженерной задачи подлетают к разрабу, выспрашивают у него всё-всё-всё, от верхнего уровня идей до неочевидных ловушек на низких уровнях, и записывают это в структурированной и регулярно обновляемой документации?
когда уходит сотрудник
...и чо?
вариант 1: Главный Начальник сдувает пыль с машины времени и заставляет "пустого" новичка, только что из HR, просмотреть в реальном времени все "митинги" с участием ушедшего. Сколько это времени займёт и какой процент этого потока слов новичок реально осознает?
вариант 2: новичку дают доступ к "гиту" и "жире" и говорят - быстро изучи всё, что сделал Вася Пупкин. Переменная количество_митингов_на_которых_послушно_ораторствовал_ушедший, при этом вообще не используется.
Все эти митинги никак не коррелируют с накоплением корпоративного знания. В лучшем случае это самообман.
нет.
РП следит чтобы не было узкой специализации.
Если Вася пишет лучше всех на какую-то тему, то нужно отдать эту задачу кому-то другому. Пусть лучше потеряем время, но компетенция появится у другого человека. (Вася вынужден будет делиться компетенцией).
В итоге, если Васю переедет трамвай, то коллективный разум не пострадает. "Его задачи" делали много кто.
Ничего не имею против такой схемы, особенно если Васе дадут часы на это "делиться компетенцией", но однако причём тут всякие митболы и прочие кнедлики по скраму? Обсуждение инженерных задач инженерами происходит постоянно, без привязки к красным дням календаря и без церемоний. Кнедлики только отнимают время, которое инженеры могли бы потратить на обмен опытом.
P.S. да и РП в данном контексте едва ли относится к бизнесу, скорее это прораб, самый тёртый жизнью из программистов.
Фото про Джиру - это и есть первоисточник Джиры. А потом ее изуродовали не-разработчики.
В принципе, согласен с автором. Сколько проектов и компаний я ни видел (а это были и очень большие банки, и почти стартапы) — везде скрам работает с костылями из-за того, что для любого нового функционала, отличного от шаблона и сложнее, чем добавить кнопку, — для оценки требуется сделать задачу минимум на половину. В итоге все просто врут в оценках и натягивают сову на глобус.
Кучу лет в scrum, если кратко, для себя создал вывод
Если у вас тиражируемый проект, scrum не нужен, нужен waterflow, неизвестностей же нет. Зачем строить хрущевки по scrum :), а вот измененя можно запустить по scrum
RnD это всегда Kanban, даже не пытался по скрам, очевидно, что не получится
SAFE если у вас реально один большой продукт, который вы не можете разбить из за домена. Есть интересные мысли, но имхо очень сложно заставить работать.
Scrum хорошо работает если его уметь правильно применять на подходящих проектах.
И меня, как бизнес, устраивает оценка с точностью 50%
Плюс-минус согласен.
RnD это всегда Kanban
Вот здесь что-то не совсем понял. Изначально kanban пришел из конвейерных производств и главной фишкой его было то, что он позволял визуально выявить проблемные участки, чтобы обеспечить бесперебойное производство. Но если у вас R&D, то как вам kanban поможет?
Хорошо, kanbanом я назвал просто доску, где сверху самое важное, его и делаем, оценки могут быть на задачи, но общие сроки непонятны. Конечно это не канбан тойоты
Ну так и скрам у вас будет точно так же работать. Самое важное, ну то что у вас "сверху", это следующий спринт. Его вы планируете.
Потом вы что-то сделали, как-то показали что у вас в итоге вышло и планируете следующий спринт.
А общие сроки точно так же непонятны. Это ведь как раз основная фишка всех гибких подходов: можно работать даже если точно не знаешь как должен выглядеть конечный продукт. В отличии от подходов когда сначала пишется полное ТЗ и озвучиваются сроки.
разница все же значительна, в Scrum нужно достичь цели спринта, т.е. сделать что то, визуальное-функицональное, чтобы показать заказчику.
А в RnD такой цели нет, там копаем, пока не выкапаем, как заказчику достанет, он прибьет этот проект.
В 99% обычных задач, я сразу скажу сколько попугаев/маек и буду достаточно близок, а вот с RnD очень непонятно время, даже для очень опытных разрабов... Т.е. подход "копаем с утра и до обеда"
разница все же значительна, в Scrum нужно достичь цели спринта, т.е. сделать что то, визуальное-функицональное, чтобы показать заказчику.
Вам нужно достичь цели спринта. Но результат совсем не обязательно должен быть "визуально-функицональным". Он должен быть, должно быть определено какой он должен быть и у заказчика должна быть возможность его проверить.
А в RnD такой цели нет, там копаем, пока не выкапаем, как заказчику достанет, он прибьет этот проект.
Вот вы сегодня утром начали копать. У вас есть какая-то цель или вы просто генерируете случайный код и смотрите что он делает?
Ну то есть я кучу раз в скраме делал всякие прототипы и PoC'и всё отлично укладывалось в скрам. И да когда делаешь такие вещи, то часто результат спринта заказчика не устраивает, он выкладывается и начинаешь снова. И да, бывает что в конце спринта вообще нечего показывать. Ну так это нормально.
цель в RnD конечно есть, но как ее достичь никто не знает, даже декомозировать иногда нельзя и результат спринта, должен быть потенциально готовым к проду. Да иногда в RnD садишься и с утра и до обеда ищешь выход, я понимаю, что вы клоните к исследовать такой то ресурс, попробовать то, написать нейронку... но по большому счету, результата нет, так как можно месяц эксперименты ставить, а удовлетворительного результата не найти. А цель попробовать "технологию akjdakds" нафиг бизнесу не нужна. Или когда берешь тему, потянул ниточку, а там еще вывалилось на год вперед... Конечно можно за уши притянуть, но это все не про задачи на 8 часов...
Погрешность оценки будет сильно большой, поэтому такое прогнозированию поддается плохо. Но если на половину вещей закрыть глаза, то можно.
но по большому счету, результата нет, так как можно месяц эксперименты ставить, а удовлетворительного результата не найти.
Можно. И это не проблема. Вы же можете ставить как задачу "поставить такой-то эксперимент и отчитаться о результатах". То есть результат может быть отрицательный, а задача всё равно выполнена и заказчик может проверить результат.
А цель попробовать "технологию akjdakds" нафиг бизнесу не нужна
Если она вашему заказчику не нужна, то зачем он вам за это платит?
Конечно можно за уши притянуть, но это все не про задачи на 8 часов...
А никто и не говорит что задачи должны быть ровно на 8 часов. Допустимые размеры задач и длительность спринтов вы сами можете определять.
можно так делать и можно даже сделать так, чтобы это почти соответствовало скраму, но вот оценки скорее будут сильно завышены. Если нужно чтобы технология Х дала нужный результат... я обычно делаю цель, а вот сроки очень размазанные и daily не имеют смысла, скорее раз в несколько дней, т.е. это уже не скрам. А так да через спринт поймем куда дальше грести.
можно даже сделать так, чтобы это почти соответствовало скраму, но вот оценки скорее будут сильно завышены.
Ну так это любому подходу к разработке будет "почти соответствовать". А какой-то всё рано надо.
и daily не имеют смысла, скорее раз в несколько дней
Daily имеют смысл каждый день. Чтобы люди, которые работают над одним проектом и/или в одной команде могли синхронизироваться. То есть понять если где-то какие-то проблемы с которыми кто-то не может справиться в одиночку. И это в общем-то единственная цель этих самых daily .
можно, но вся проблема RnD задач, что он не декомпозируются до дня, на практике неделю запросто, а поэтому смысла в дейли не очень много.
Но если удастся раздробить все по 8 часов, то тогда конечно скрам может подойти..
Но если удастся раздробить все по 8 часов, то тогда конечно скрам может подойти..
Откуда у вас эти "8 часов" взялись? Кто вам запрещает делать задачи побольше? Надо вам неделю, ну так сделайте задачу на неделю. До тех пор пока задача влезает в спринт это не проблема.
а поэтому смысла в дейли не очень много.
Я не особо понимаю о чём вы. Вам не надо на дейли отчитываться о сделанной задаче. У вас может быть задача на весь спринт, но вы при этом где-то застряли и у вас что-то не получается. Вы это озвучиваете на следующем дейли и другие разработчики прикидывают не могут ли они вам помочь. А вы наоборот слушаете других и прикидываете не можете ли вы помочь им.
все верно, но в действительно сложны RnD задачах другие слабо могут помочь, там в контекст можно пару дней углублятся
Проблемы бывают очень разные. Например банально у кого-то не получается виртуалку запустить. Или при использовании библиотеки какая-то непонятная ошибка вылезает.
Опять же если на дейли всем нечего сказать, то дейли сразу и заканчивается. Мы например его всегда делали по утрам когда первый раз все вместе шли за кофе. По дороге выяснили есть ли вообще какие-то вопросы. Пока машина всем делает кофе их уже и обсудили. А если вопросов нет, то просто взяли кофе и пошли работать.
Для какого количества людей такие daily нужны? То есть, какое минимальное количество людей должно быть в команде, когда они уже точно не знают о выполняемой в данный момент работе коллеги?
Для какого количества людей такие daily нужны?
Для любого.
То есть, какое минимальное количество людей должно быть в команде, когда они уже точно не знают о выполняемой в данный момент работе коллеги?
Каким образом каждый в команде должен узнать что конкретно делают другие и есть ли у них какие-то проблемы? Ну если не разговаривать друг с другом на эти темы?
Ну если не разговаривать друг с другом на эти темы?
Писать текстом в каком-нибудь 'дневнике разработки'?
Или в списке рассылки. Который почтовый и который изобрели... давно. (нет, не чатах - у них с совместимостью, поиском и интеграцией не очень хорошо).
Есть какие-нибудь методики, нацеленные на письменное общение и фиксацию происходящего?
Или у нас в индустрии, постоянно работающей с текстом и, по идее, должной уметь это делать хорошо, так до сих пор и не изобрели ничего подобного?
Писать текстом в каком-нибудь 'дневнике разработки' Или в списке рассылки
То есть писать какие-то дневники или рассылки и заставлять всех их читать по вашему более простой и удобный способ чем просто потратить 5 минут на короткий разговор? Если вообще 5 минут.
То есть вы как хотите, а лично мне точно удобнее просто обсудить дела пока идём за кофе.
Есть какие-нибудь методики, нацеленные на письменное общение и фиксацию происходящего?
Зачем такое фиксировать? Кому это надо? Это проходные вещи, которые уже на следующий день никого больше не интересуют.
То есть писать какие-то дневники или рассылки и заставлять всех их читать по вашему более простой и удобный способ чем просто потратить 5 минут на короткий разговор?
С некоторой точки зрения - да. Потому что асинхронно - разные люди читать и писать могут в разное время. Кроме того, сам факт записывания - способствует укладыванию мыслей в голове.
Это проходные вещи, которые уже на следующий день никого больше не интересуют.
Те, кто пишут ядро линукса, скажем, так не думают. Архивы доооолго хранять.
Потому что асинхронно - разные люди читать и писать могут в разное время.
Так а тут вам нужно чтобы люди это делали в конкретное время. Потому что речь идёт о блокерах, который не дают кому-то сегодня что-то сделать.
Те, кто пишут ядро линукса, скажем, так не думают. Архивы доооолго хранять.
Это слегка о другом. На дейли могут обсуждаться и вещи вроде "а мне завхоз так и не дал новую мышку".
К счастью, аджайл не ограничивается скрамом. Даже наоборот, скрам
несмотря на все старания не смог убить хорошую идею в основе гибкого
подхода.
Почитал ответы, увы до большинства так и не дошло, что автор сказал. Кстати, чего-то вспомнилось, что когда время позволяло посещать ПМ-конфы замечал, что большинство народа там просто банально безграмотные, то есть они знают что такое "скеджуал", "грумминг" и "рефайминг", но банально никто не понимал, когда спрашивали, например про "цикломатическую сложность задачи" или "факторный анализ".
Может я излишне строг, но большинство для которых применение скрама - это всего лишь "потому что все так делают, это ж модно", - то это секта.
Я когда вижу эти методики, всегда вспоминаю ту веселую книгу 60х годов от разведки США, про "тихую" подрывную деятельность, в которой в том числе было про метрики, совещания и бюрократию)
Только тут менеджеры сами себе диверсанты. Особенно, когда тянут методологии у промышленников с огромным конвеером, у японцев, чей менталитет полярно отличается от европейца... Вместо того, чтобы включить голову и на базе имеющегося мирового опыта создать свою методологию, подходящую под требования бизнеса, берут устаревшую на много лет методичку и натягивают сову на глобус. "Тут написано, что спринт неделя - значит будет неделя и точка" - ну и начинается, это перенесем, это закроем и сделаем копию, дайте оценки непонятной задаче в минутах...
Не надо так. Методологии описаны сферические в вакууме. Дальше надо адаптировать их под бизнес, а не переделывать бизнес под методологии)
Вспоминается вот один проект где:
оценки должны быть. просто быть. ситуация когда оценка реально в часах но пишется в минутах - допустима если сотрудник временно привлеченный в команде. А потому что у начальства есть графики задач без оценок и это плохо.
задачи не должны быть в работе больше дня. Да - это значит что если задача оценена в 4 дня допустим и декомпозировать лучше ну не выходит - будет 4 задачи (ну или будет декомпозиция весьма условная).
задачи должны выполнятся за спринт. потому что графики. по факту если понятно что задача не выполняется (ну ошиблись), она удаляется из старого спринта и добавляется новый (если это фича а не дефект - закрывается и клонирутся).
объем спринта увеличивать низзя потому что графики. но при этом бывают что прилетают дефекты либо от тестировщиков либо из внешних источников. заводится задача Буфер-под-дефекты, иногда не одна, и время с нее используется для тех самых дефектов.
Дичь какая. Что за галеры в которых оценки задач в часах и минутах, и не больше дня. Закрывать таски, сроки горят, больше фич, запланировано на следующие 2 часа! Релиз, гроб, кладбище, ПМ.
В таких условиях же вообще невозможно сделать что-либо нетиповое. Ни тем более узнать что-то новое разработчику. Я бы к такому адовому конвейру на пушечный выстрел не подошел.
У любого инструмента есть поклонники и хейтеры, чаще всего хейт рождается по причине того, что хейтер просто не смог совладать с тем или иным инструментом. Рождённый ползать летать не будет. А вообще... пчёлы не тратят своё время, чтобы доказать мухе, что мёд лучше дерьма... не нравится скрам - не пользуйтесь.
Первый абзац это шедевр)))
Не могу сказать, что полностью согласен, но статья отличная пища для размышлений, тут и комментарии к статье могут потянуть на отдельный материал)
как замечательно, что я даже не знаю что это такое
По поводу R&D - абсолютно согласен. Исследовательские задачи плохо оцениваются, поэтому это просто надо проговаривать. Но и границы нужны, поэтому хорош такой подход
- Через сколько времени погружения мы сможем более-менее точно понять картину и что еще нужно сделать.
- Через сколько времени станет понятно что нужен "план Б" и не добивать эту задачу до конца, или принимать какие-то другие решения.
По поводу "недооценок" - это не совсем верно, потому что тут главное не оценивать сложность точно, а понять сколько сложности мы можем переварить в спринт. То есть - если мы недооцениваем всегда одинаково, то все равно видно сколько таких недооцененных задач по суммарной сложности мы делаем.
Столкнулся с SAFe, впечатления по итогам полутора лет - отвратные. Тот же вотерфолл, только обвешанный модными блёстками. Пришло новое руководство, им стукнуло в башню, что все работают неправильно, и надо срочно всем внедрять SAFe. Почему, зачем, неважно - SAFe - это модно!
1) 3-х месячные итерации(PI), на которые надо подписываться кровью. Изменений в скоупе в течение трёх месяцев быть не может никаких, пришли новые требования/пообщались с клиентом - нет, всё, уже закоммитились, теперь только выполняем. Гибкость потерялась вся. Спринты проходят по 2 недели, но т.к. скоуп поменять нельзя, то смысла в них особо нет.
2) Исследовательские задачи никто не хочет брать, т.к. хрен знает, во что это выльется - а нужны 100% гарантии выполнения 3х месячного плана. И одновременно 100% загрузка ресурсов при планировании. В итоге любая внештатная бага/тикет/архитектурная проблема по итогам дизайна - и люди начинают кроить нужные задачи в попытках выгадать какое-то время чтобы успеть в 3 месяца. Задачи на выход начали выходить подозрительного качества. Техдолг менеджить стало в разы сложнее.
3) Все 20 департаментов по 50-100 человек должны естественно выполнять ритуалы связанные с релиз трейном. Это значит - посещать митинги на сотни человек (по 2-3 представителя от департамента), и что-то там слушать, показывать презентации и отчитываться. Толку от этого - примерно ноль, до этих PI за 6 лет работы в компании я даже не представлял, что большая часть этих людей существует. И с нашей работой они не пересекаются вообще никак. Но все сидят часами на этих планнингах, митингах, занимаемся рисовкой отчётов, рисовкой презентаций на выброс и прочей хренотой.
4) Релизы должны быть синхронизированы! Чтобы все показывали глобальное демо после 3х месяцев (опять на сотни рандомных человек) и чувствовали как движутся вперёд! С учётом пункта (2), при загрузке 100% и требовании 100% выполнение плана - времени релизить нет. Релизы стали выпускаться вместо каждого месяца - раз в три месяца, чисто чтобы под демо успеть. Зачем делать релиз если фидбек с него никак не будет использоваться ещё минимум 2 месяца до следующего планирования?
В итоге имеем падение качества продукта, падение частоты релизов, уменьшение гибкости (по 3 месяца ничего в требованиях менять нельзя), падение качества требований (т.к. надо с заказчиком/РнД/QA/Delivery всё обсудить и утрясти ровно перед планнингом, по актуальной информации, а на такой огромный скоуп это невозможно). В общем, выстрел себе в ногу удался.
Вот вот, но всякие сторонние коучи учат жить...
А вообще если есть зависимости между командами, то проще в двух командах сделать задачи ссылки в спринте, как обязательные, + некоторый commitment на уровне разработчиков. все равно же планируем исходя из того, что 70% можно только запланировать, остальные 30% на всякий саппорт уйдёт. Мне это гораздо больше SAFE понравилось, главное никого не отвлекаешь на эти ритуалы дурацкие. Блин, ночь торгов, придумали же, чтобы котики велись на эту чушь
От такой "работы" даже не выгорание наступает, тут психическое расстройство может случиться. Если бы Кафка был жив, он бы наверняка написал что-нибудь про современную индустрию разработки ПО.
Пока все радуются от систем типа copilot для программного кода,
я уже всерьез задумался о создании помощника для ведения задач в jira, (а заодно и актуализации вики).
Примерно полтора десятка ссылок на задачи в jira и страницы в вики, связанных с одной разработкой.
Если в работе параллельно четыре - пять задач, и в каждой по столько ссылок, которые нужно актуализировать, то... я меньше времени код пишу, чем статусы в задачах переставляю, и вики актуализирую :)
Все это дело годится только для контрактов поддержки и сопровождения, также, возможно, заказчики - частные компании тоже подойдут. Но аджайл совершенно не подходит для заказчиков из гос.сектора, и тут, как говорится, от тюрьмы и от сумы не зарекайся. Гос.заказчик обязан принять результат, только если он соответствует всем требованиям контракта, а исполнитель начинает лепетать про договорённости, "слонов, которых хотели съесть по частям", важность общения.
У меня сложились аналогичные впечатления: Scrum противоречит Agile. Но мне кажется причина в требовании коммитмента на сроках. То из-за чего:
... сотрудники находятся под постоянным давлением из-за того, что задачи не ложатся идеально на спринты
В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии. Мы все жертвы когнитивных искажений которые приводят к ошибке планирования. Он scrum переводит ответственность за это на разработчика.
Но мне кажется причина в требовании коммитмента на сроках
В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии
Во-первых, agile и гибкая методология это одно и тоже, это буквальный перевод.
Во-вторых, agile в целом ничего не говорит про коммитменты, он скорее про коммуникации и построение процессов вокруг коммуникации, а не вокруг документации. Сверху можно навалить больше методологических слоев, которые уже помогут зафиксировать сроки, обработать риски и прочее, например - тот самый SAFe.
То, о чем вы говорите, скорее вытекает из нежелания бизнеса признавать триаду проектного управления, из чего вытекают нереалистичные ожидания. Скрам тут только подливает масла в огонь, так как построен вокруг баланса скоуп-время (при фиксированном размере команды обычно, то есть бюджете), что в свою очередь просто не подходит для проектной деятельности, где все три параметра зафиксированы заранее.
В Agile про коммитмент ничего не сказано и он скорее противоречит духу гибкой методологии
Я имел в виду что коммитмент противоречит духу Agile. А не ставлю противопосталяю Agile и гибкую методологию.
Я бы так не скзазал. Мое понимание Agile таково, что он про гибкость, но это не исключает коммитменты. Просто не нужно делать коммитменты, которые исключают гибкость: например, можно зафиксировать бюджет, что зафиксирует человеко-часы, но при этом будет гибкость по деливери.
С другой стороны, можно зафиксировать скоуп, но тогда либо сроки будут плавать, либо качество.
Не на разработчика, а на команду. Ну и вообще commitment - сделаю все от себя зависящее, чтобы это случилось, вроде как нормально звучит... У меня раз в команде был не очень надежный девелопер, он мог просто забухать за пару дней до демо, ничего как то раскидывали, делали, вот зрелость команды крайне важна.
в конце-то концов на разработчика.
вроде как нормально звучит...
Для меня не нормально. Когда ты можешь быть уверен, что сделал все возможное?
У меня раз в команде был не очень надежный...
Для него я думаю и commitment не проблема
Это внутренняя ответственность каждого, если что то идёт не так, скажи команде, тебе помогут, если задача важная. Команда чётко понимает, сделал ты все возможное или нет, поэтому команда зрелой становиться через год работы друг с другом, когда все понимают кто и что выдаст и помогают друг другу. Иногда уходит меньше времени.
Я бы сказал, что помощь друг другу - важнейшая часть скрам.
А если кто то систематически косячит, то команда его вытолкнет со временем.
Да-да все Scrum Musters так говорят на тренингах. А по факту спринт набит под завязку и чтобы переключиться, нужно что-то выбросить, вводить в курс тестировщика или аналитика - себе дороже.
Но вообще я не об этом. Мы можем много спорить о деталях, о том что я не умею его готовить и тп. Но мой основной тезис - откуда в гибкой методологии взялся commitment? Commitment - не может быть гибким по определению, а это сердце Scrum-a.
Нам под соусом Agile (который я поддерживаю) завернули не понятно что.
Теплое с мягким путаете. Я даже не хочу общаться с распиз...ями, которые не берут commitment , мне "ехать", нет результата - до свидания.
Теперь про гибкость, гибкость заключается в том, что не надо выполнять все задачи спринта, это лишь доп фичи.. Более того, если у кого то задача сильно больше, то ему помогут, если задача важна.
Я вам это говорю, так как я не теоретик с треннингов, а практик.
По поводу того, что скрам подходит для проектов сопровождения это отчасти правда. Вы пробовали сопровождать 1С. Там на лёгкую на первый взгляд ошибку могут уйти дни
Я сопровождал SAP. Конечно бывают ошибки, на которые уходят дни (а то и недели). Но в целом в сопровождении риски напороться на подводные камни, которые значительно раздуют сроки, куда ниже, чем в разработке с нуля.
ИМХО отловить проблему в существующем коде вендора проще, чем сделать ее себе самому.
Мы так с SAP-ом пролетели по срокам на пол года и заплатили миллионы неустойки, а потом за те же пол года запилили собственный фреймворк куда лучшего качества, позволяющий за недели делать то, что на сапе пол года вымучивали и всё равно тормозило и глючило.
Хороший ход получить вечного клиента. Ведь ваш фреймворк никто кроме вашей команды не знает :)
Зато весело будет искать новых людей, которые должны будут работать с этим фреймворком.
Вообще-то это индустриальный стандарт.
А подскажите как звучит цель спринта, когда вам заказчик оформил с 10ок тикетов на разные темы? Или под саппортом вы подразумеваете доработки?
Почему нельзя просто делить ответственность в команде? Собираться на совещания тогда, когда это действительно необходимо? И просто вести задачи в таск-трекере?
Рабочая схема 👍
Статья написана стилистически и семантически очень плохо. Дебильные смехуёчки и рандомные картинки делают ситуацию еще драматичнее.
Я использую скрум чтобы мой насяльника каждый раз в момент своего озарения не объяснял мне новое виденье вселенной. А чтобы можно было сделать что то крохотное и реально работающее за пару недель спринта. И это можно будет каким то образом пре-продать или получить под это бюджет.
Только не все насяльника читают Agile Manifesto дословно. В там в начале говорится о профессионалах, а не о родственниках, студентах, профессорах и прочих.
А чтобы сделать что то маленькое и реально работающее это sort of art.
Рак - это кликбейтные заголовки на хабре
Большое спасибо за статью, наконец-то до людей начинает доходить (хотя судя по каментам довольно медленно). Давно хотел сам написать на эту тему, только как ни возьмусь, одна ругань в голову лезет.
Скрам это, мягко выражаясь, абсолютный мусор. Любят скрам лишь не умеющие работать с людьми манагеры, скольнные к микро-менджменту.
В камментах было много сказано про "скрам, на самом деле, просто извратили", так вот это тоже чушь. Я работал в пяти компаниях, в каждой из которых подход к построению "своего" скрама немного различался — в меру представления о рабочих процессах у руководства. В одной из компаний даже нанимали сертифицированного скрам-мастера за много-много деняк, который месяц объяснял команде как надо работать. Стали ли процессы от этого лучше? Нет, это всё такой же эксплуатационный подход к разработчикам. Не смог разобраться в задаче за указанное время? Тебя будет поносить твой ПМ каждый дэйлик пока задача не будет закончена, ещё и на ретро скажут какой же подлец, задачу просрочил на чудовищные три дня, чёртов бездельник!
Я уж молчу, что некоторые манагеры просто сумасшедшие, у них словно начинается приступ если они видят хоть один процент просрочки по задаче, из-за чего полдня приходится выяснить в рабочих чатах что ты делал и почему.
Видел ли я хоть в одной из этих компаний чтобы ВСЕ задачи закрывались без просрочек, хоть у одной из команд? Нет, не было такого НИ РАЗУ. Тогда зачем эти оценки, может кто-то объяснить? Просто "на глаз" дать оценку задаче я и без скрама могу, эффект будет такой же.
Отдельный момент, с которого у меня больше всего всегда пригорало — учёт рабочего времени. Окей, вы ввели скрам, наняли продакта. Продакт отрабатывает свою функцию контроля за разрабами на полную, но так как он ничерта не производит, всё своё рабочее время он посвящает извините, задрачиванию программистов идиотскими встречами, созвонами, ретро (это вообще эталонная тупость), демо, и так далее по списку. И при всё при этом, отмечать рабочее время заставляют программистов. У меня вопрос — манагер знает когда задача была взята в работу, знает когда она была закончена, в чём проблема, если ему надо, самому сходить и потыкать время затраченное на разработку? Нет, всех ВЕЗДЕ заставляют тыкать в трекер самостоятельно. В итоге рабочий день зачастую состоит из работы в лучшем случае процентов на 80%, остальное время занимают встречи, дебильные созвоны, тыканье в трекер, чтение бесполезной корпоративной почты (которую если не прочтёшь, на тебя на созвоне будут таращить удивлённые глаза с вопросами «ТЫЧТОАОАОА НЕ ЧИТАЕШЬ ПОЧТУ?») и т.п.
Ни в одном месте, повторюсь, НИ В ОДНОМ, не видел я такого, чтоб вот был скрам и всё супер. Всё равно программы с багами (хотя это отдельный вопрос, но всё-таки связанный), всё равно кривая разработка с постоянным срывом сроков, постоянная напряжённость в командах, ну и так далее. Но нет, все будут продолжать использовать эту шизу, да ещё и нахваливать, мол вот как прозрачно мы теперь знаем чем наши программисты занимаются, ага. Ведь в трекер заглянуть это непосильно для руководителя, ему "надо в глаза посмотреть" 🤡
Обиднее всего во всём этом, что решение о внедрении этого дерьма принимают вовсе не сами разработчики. А те, кто использует скрам как инструмент контроля (сиреч сами манагеры) очевидно в ближайшем будущем от него отказываться не собираются. Тем более, пока по этой методологии работают гиганты индустрии. Так что имеем то, что имеем. Я бы предложил самим программистам отказываться работать с компаниями использующими скрам, имхо это единственный путь к изменению ситуации, но боюсь поддержки не найду.
Любят скрам лишь не умеющие работать с людьми манагеры, скольнные к микро-менджменту.
Ну вот неправда. Я никоим образом не манагер, но скрам вполне себе люблю. По крайней мере отдельные варианты с которыми мне приходилось сталкиваться. Но опять же далеко не все варианты.
Не смог разобраться в задаче за указанное время? Тебя будет поносить твой ПМ каждый дэйлик пока задача не будет закончена.
Не является обязательным аттрибутом скрама. Видел реализации где этого не было. Более того на дейликах такому вообще не место.
Видел ли я хоть в одной из этих компаний чтобы ВСЕ задачи закрывались без просрочек, хоть у одной из команд? Нет, не было такого НИ РАЗУ. Тогда зачем эти оценки, может кто-то объяснить?
Чтобы можно было примерно планировать. Нигде не написано что в скраме все задачи обязательно должны закрываться в срок.
Просто "на глаз" дать оценку задаче я и без скрама могу, эффект будет такой же.
А кто вам мешает в скраме давать оценку "на глаз"? Это не запрещено и более того это вполне себе практикуется.
И при всё при этом, отмечать рабочее время заставляют программистов.
Не является обязательным аттрибутом скрама. Лично не встречал ни одной реализации где этого требовали.
Ни в одном месте, повторюсь, НИ В ОДНОМ, не видел я такого, чтоб вот был скрам и всё супер.
Ну так я тоже ни в одном месте не видел чтобы было "всё супер". Что со скрамом что без него :)
Обиднее всего во всём этом, что решение о внедрении этого дерьма принимают вовсе не сами разработчики.
И тоже не совсем верно. То есть я знаю как минимум одну фирму где разработчиков спросили хотят они перейти на скрам или нет. Более того через полгода спросили оставить лi скрам или вернуть всё как было.
Есть такое понятие fake scrum, а вы видели не fake?
PS в скраме нет необходимости сделать все задачи из спринта, есть необходимость достигнуть цели (ведь сделать все задачи - неправильная). Если у вас цель сделать все задачи, вам в pmbok или kanban какой нибудь.
Скрам нужен для снижения риска на проектах, где не понятно, что надо заказчику и он позволяет идти небольшими итерациями, чтобы корректировать направление и не залипать на совершенстве ненужного. Мы же все любим сделать классно, но это потребует х10 времени, а потом окажется, что эта фича никому не нужна.
Я работал в пяти компаниях, в каждой из которых подход к построению "своего" скрама немного различался
И это нормально. Скрам не является методологией, а фреймворк, из которого каждая команда лепит свой процесс конкретной под себя. Раком скрам становится, когда это преподносится как методология, читай, кто-то сверху за всех остальных придумал как им работать. Это так не делается. У каждой команды должна быть свобода делать как им лучше.
Всё равно программы с багами (хотя это отдельный вопрос, но всё-таки связанный)
Вообще никаким местом не связанный. Скрам не был придуман ни для улучшения качества, ни скорости разработки, ни еще чего либо кроме одного - повышения адаптируемости к изменяющимся условиям. Выйдет ли из этого экономия денег, времени - вопрос второй.
В общем, весь ваш пост вообще не про скрам, а про микроменджмент и плохое управление командами в целом. Это будет актуально при любой методологии, любом подходе. Об этом надо писать, а не о скраме. Уйдет скрам, придет другая модная фигня, на которую все кинутся в поисках решения всех их проблем. Это конечно интересно устраивать флешмоб и отказываться работать по скраму, только проблему конкретную это не решает.
Вставлю пять копеек.
Когнитивное искажение "Ошибка планирования" не позволяет планировать R&D качественно.
1. В науке это сплошь и рядом, поэтому ученые взвывают хором от любых попыток заставить из совершать открытия по расписанию (я конечно утрирую, но плюс-минус оно так).
2. Люди кто хорошо планирует и всё делает в срок - обычно решает либо неглубокие задачи либо дико перерабатывают.
3. Потому-то ценятся а) люди с опытом - они знают задачи в целом, б) люди умные - они могут разобраться в задаче привлекая множество источников информации и логику.
Если анализировать хейтеров скрама, то им не скрам не нравится, а то, что их деятельность хотят под какой-то контроль подвести. Оценка не нужна, декомпозиция не нужна, сроки не нужны, отчетность не нужна. Мы свободные художники, у нас каждая задача это RnD. Идеал работы - сидеть в темном углу и месяцами что-то ковырять ради собственного удовольствия без всякого выхлопа. А прикрывают это тем, что менеджер мудак и скрам отстой. Да, менеджер-то мудак и скрам иногда отстой, но в комментах дофига критики по сути инженерской производственной дисциплины, а не менеджеров.
Ребята, с таким настроем нужно было в андерграундное искусство идти. А вы в промышленность попали.
Идеал работы - сидеть в темном углу и месяцами что-то ковырять ради собственного удовольствия без всякого выхлопа
Да. И что интересно, некоторые задачи действительно нечто подобное требуют, а некоторые компании (в которых реально постоянный RnD, например) такое практикуют.
Вообще мечта "эталонного токсичного программиста" (не все такие, но на Хабре популярный типаж) – чтобы просто все разработчики сидели по углам и тихо пилили что-то в своё удовольствие. Не отвлекаясь на менеджеров и прочих "бесполезных" персонажей. Нередко это даже работает. Всякие крутые опенсорсные штуки порой по такому принципу и создаются. Короче, программисты хотят "просто писать код" и чтобы им не мешали. Менеджеры им не нужны.
Менеджеры нужны бизнесу. Как смазка между ним и теми самыми программистами. А ещё бизнесу нужна прозрачность и предсказуемость, что на 100% противоречит той самой "программерской мечте". Ещё бизнес должен отделять важное от неважного, и понимание что важно у бизнеса будет отличаться от программерского. И это вовсе не обязательно "бизнес хочет пилить фичи, а программисты хотят всё зарефакторить". Вполне может быть наоборот – "программист хочет запилить крутую фичу, а бизнесу сейчас критично важно закрыть техдолг". Всякое возможно. И чтобы вот это понимание, что важно, а что нет, доносить в обе стороны – и сверху вниз, и снизу вверх – опять-таки нужна прозрачность.
В общем, не даёт бизнес разработчикам сидеть по тёмным углам. Тормошит, отвлекает, заставляет планировать и оценивать, декомпозировать, выпускать недоделанное, отчитываться. А что поделать? Деньги-то платит тоже бизнес.
Сразу видно что про инженерию знаете примерно ничего.
Вы правы. Но и scrum haters тоже правы. Потому что контроль и связанные с ним процессы могут занять столько времени и сил, что на работу как таковую их не останется. Хотя, с другой стороны, всем понятно, что без контроля тоже никак. Значит, должна быть какая-то разумная граница. Но эта граница будет разной в разных случаях, даже внутри той же группы, а scrum один на всех, мы за ценой не постоим.
Скрам - как коммунизм - в теории элегантен и эффективен, на практике сколько ни пробовали - работает только в Китае
коммунизм с олигархами и потогонным конвеером )
С(к)рам нужен бизнесу чтобы перекладывать большую часть ответственности на исполнителей, заставлять их чувствовать вину за срыв сроков и регулярно перерабатывать.
Ну ещё отчёты красивые в жире смотреть. Где 90% задач идут по плану и лишь из-за косячных ленивых разработчиков никак не сделается оставшиеся 10%.
И лишь "знающие" понимают что эти 10% и есть основная работа. Но премию получат те у кого всё по графику.
В общем, это хороший инструмент для бизнеса. Как SAP. Они с нами надолго.
Автор еще плохо представляет насколько глубока кроличья нора.
На самом деле аджайл и скрам "нужны" совсем для другого.
Представьте, есть вполне вменяемая задача и не слишком сильная команда.
Если решать задачу в лоб и по старинке, есть опытный лид, который расписывает план решения задачи и делит его между членами команды согласно их спсособностям и компетенциям. И команда с минимальными усилиями движется к цели.
И тут возникает две главные проблемы:
Задачи зависят друг от друга и люди иногда блокируют друг друга и сидят без дела.
Лид не успевает все распланировать и когда это случается команда опять сидит без дела пока он думает.
В итоге менеджеры нервничают: хочется быстрее а люди явно сидят без дела.
Как решить это упроблему? Элементарно - Аджайл!
Вместо того чтобы улучшить разработку нужно ее УХУДШИТЬ! Тогда разработка пойдет в 3 раза медленнее, но все будут заняты аж пыль столбом и у лида будет гораздо больше времени подумать. Все работают, все заняты, все с пафосом называют на совещаниях номера PBI, разруливают блокеры. Менеджеры довольны!
Возвращаясь к статье, автор не знает способа планировать время на RnD задачи, но он есть. Для этого нужно просто разбавить эти задачи всякой ненужной хренью в таком количестве, чтобы неопредленность времени на эти задачи уже почти не была заметна на фоне общей "работы". Прогрммирование не похоже на укладку кирпичей и не нормируется? Давайте испортим его настолько чтобы оно стало похоже.
Немного деталей - а как ухудшить разработку? Есть несколько замечательных приемов.
Во-первых инжеренрый дух креатива и целеустнемленности нужно заменить на игру в разработку, желательно предельно пафосную и забитую разными церемониями. Фокус с работы необходимо переместить на процессы. Бесплатный бонус - в таких условиях вы можете нанимать кого угодно - все будут работть примерно одинаково. Больше нет интеллектуальных элитариев.
Во-вторых, задачи обязательно нужно раздавать совершенно случайным людям по принципе кто первый того сегодня и тапки (у нас не должно быть незаменимых!). Человек уже делал нечто подобное 10 раз с справится за пол часа? Это плохо, потому что лид потратил 2 часа чтобы принять решения что нужно сделать. Отдадим эту задачу тому кто все это в первый раз видит и он провозится весь спринт. Все при деле!
В третьих задачи нужно очень мелко поделить, чтобы работы было буквально на пол часа. Это даст сразу два преимущества. Во-первых количество бюрократии и усилий на создание PR и прочее превзойдут саму задачу. Во-вторых, люди будут сильно перескаться, мешая друг другу. Ошибка одного потребует от людей мобилизации всех их сил, чтобы понять и чего теперь делать со всеми этими уже закрытыми PBI и блокерами (командная работа!)
Наконец последнее и самое важное. Люди или заказчик могут начать что-то подозревать. Поэтому важно создать атмосферу нетерпимости к любым попытка внести в разработку здравый смысл и подвергнуть догмы сомнениям. Кто не понимает важности этой всей системы - тот не профессионал и ему не место в церкви компании.
Это был готовый рецепт как создать прибыльную галеру. Примите на заметку.
... А если серьезно, то скрам и аджайл замечательные вещи, если они вторичны по отношению к работе и воспринимаются как желательные правила игры, не более того.
Потому-то во-первых можно поставить реалистичные цели и их достичь. Пол команды делало что-то другое на самом деле поперек планов на спринт? Ничего страшного, мир не рухнул.
Во-вторых есть ясные моменты когда все синхронизируются в своем понимании происходящего, а так может поленились бы.
В третьих потому что достигая успеха в срок, пусть и условный и демонстрируя результаты люди мотивируют себя и друг друга. Но только при условии что этот срок вторичен, и если нужно забываем про все и идем к цели в разрез любым планам.
Отличная статья. И самое важное в этой фразе "Мотивации и церемоний недостаточно, чтобы решать задачи. Иногда может потребоваться работать." В этом все дело, в попытке найти простое решение сложной проблемы разработки ПО. В итоге вместо того чтобы менеджер думал вместе с тим лидом как спланировать следующие задачи, и созванивался с исполнителями по мере надобности, вырастают ритуалы бессмысленных ежедневных стендапов, и прочих не нужных команде митингов.
Все спроят в комментариях, а кто-нибудь скажет как стать хорошим планировщиком и понимать что и где применять для разных задачь, не только в IT?
Есть "сухой" PMBook, а что-то из книг где были бы примеры с использованием разных методов в разных сферах существует? Или хоть какой-то анализ импользования сравнения разных методов?
Как то все вокруг одного вертится, скрам или не скрам, декомпозиция или нет, ну и околостатейная свалка кто о чем.
Всегда задавал вопрос - если вам заказывают нестандартный конечный продукт, то почему у вас между техническим заданием и непосредственно изготовлением нет проекта (проектной документации), где изложен результат, требования к нему, высчитаны потребные ресурсы (в случае с IT фреймворки, базы данных, стандартные фронты, бэки), календарный план работ, квалификация персонала, стоимость?
Везде, где подходят серьезно, этот этап обязателен, так как только он дает стоимость, сроки и план работ. Если есть подробный проект реализации конечного продукта, то скрам, канбан, или ежедневная выработка - как хотите.
А вот там, где требуется наука и научная разработка, то никакого проекта разработать невозможно, оплачивается по смете - рабочие часы научных работников и научных руководителей плюс затраты на оборудование. Это я к тому, что многие написали о research задачах в ходе разработки IT продукта. Вы серьезно, что еще не придумано и не охвачено различными платформами (хорошими или не очень)? Вам же не надо теорему Ферма решить, а всего лишь выбрать платформы хранения данных, обработки данных, визуализации данных, и применить их к заданной задача, отобразив это в проектной документации по ее реализации.
Насколько я понимаю, есть только один вид проектов, для которых scrum и agile в привычном нам виде хорош и полезен. Делается конкретный проект для конкретного заказчика. Заказчик не факт что понимает сам, что хочет. Значит, надо проект разбивать на маленькие проектики по 1-1.5 месяца длиной, и в конце каждого проектика показывать заказчику, чтобы он оценил, что события идут в нужном направлении и с приемлемой скоростью. А если нет - то менять планы на следующий проектик в соответствии с изменениями желаний заказчика.
Все, без исключения, проекты другие, в которых я участвовал - это в реальности был waterfall чистой воды, только с лишней бюрократией. Разве с waterfall не разбивали на части? Разбивали. Порядок задач не планировали так, чтобы одни не задерживали других? Планировали. Не следили за ходом выполнения задач, не проверяли состояние дел каждые несколько дней? Следили. Не устраивали время от времени обсуждение, что и как поменять в работе? Устраивали. Ну и зачем самим себе голову морочить в угоду моде?
А если это проект сопровождения, то и там scrum ни к чему, просто клиент открывает жалобы, а разрабы их удовлетворяют по мере поступления. Ну иногда задачи большие, как же без этого, декомпозировать приходится.
А когда на разраба накладывают такие ограничения - чтобы каждая задача за неделю была готова, а то скандал, то что делает разраб? Правильно, разделяет задачи на такие маленькие, чтобы в реальности их можно было бы сделать не за неделю, а за 3-4 дня. А потом можно будет премию просить за большое количество задач.
Рак не выбирают, а вот методологию выбрать можно :)
Заметил, что сейчас очень модно хейтить Scrum. Соглашусь, что местами есть за что, потому что Scrum Guide порождает много вопросов. Но я убежден, что любую, даже самую правильную методологию можно "убить" кривыми руками. Здесь вопросы менеджерам нужно задавать, которые неправильно оперируют инструментами в неподходящей конъюнктуре. Любой менеджер должен знать три ключевых подхода по управлению проектами и продуктами - Scrum, Kanban, PMI, чтобы выбрать подходящую под конкретную ситуацию. А может вообще из практик разных подходов собрать что-то своё.
К сожалению, многие ограничиваются одним Scrum, потому что продает он себя хорошо, да и гайд всего 20 страниц. Прочитал и вот ты уже Scrum знаешь. Делов то. Идут внедрять, внедряют, набивают шишки, а потом вот такие статьи, где все помидоры в методологию улетели.
Рубрика непрошенных советов.
Кто хочет глубже погрузиться в методологию, советую обратить внимание на труды М. Кона и В. Мюллера. Первый раскрывает саму методологию, в которой находится место и оценке в часах и (о, боже) диаграммам ганта. Второй пытается решить проблему скрама с коммитментом в долгосрочные дедлайны. Концепция называется "Reliable Scrum", очень интересно.
Что касается моего кейса, то у нас с командой был успешный опыт работы по Scrum. Мы зашарашили мультиплеерный топ даун шутер, уложившись в дедлайн. Задач RnD было много, так как это был наш первый подобный продукт на новом движке. Привет ребятам из геймдева, которые говорят, что оно несовместимо :)
А можно в начале статьи писать у двух словах, что такое Scrum, и в какой сфере это применяется, что бы все читатели могли понять о чём речь, и узнать для себя что то новое, либо наоборот, не читать, поняв что им эта тема не интересна???
Нет. Я предполагал, что читатели хабра знают базовые вещи, как скрам, электричество, воздух и пользование туалетом, поэтому решил опустить определение.
Для меня это такие же "базовые вещи" как для вас УОЗ, Потенциометр, ЭБУ, MAP, MAF, Индуктивность и Стехиометрия))))) Вам будет приятно получить в рекомендациях статью, где я буду с порога оперировать этими терминами, и прочитать половину статьи, прежде чем поймёте что речь идёт об системах подачи топлива в двигатель автомобиля, и оно вам не надо?)))
Я лично не знаю как там обстоят дела с "УОЗ, Потенциометр, ЭБУ, MAP, MAF". Но слово "Scrum", которое стоит в названии статьи, гуглится на ура.
А если я не знаю что это такое и мне не интересно, то и статью читать не обязательно :)
Так в том то и проблема, что тот же гугл постоянно даёт разные определения этого термина. Причем из этих определений невозможно понять ключевых особенностей такого метода организации работы! Цитирую:
"Scrum — это методика гибкого управления проектами, помогающая командам структурировать работу и управлять ею на основе определенного набора ценностей, принципов и практик."
"Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем. "
"Scrum — методика организации совместного рабочего процесса, в основе которой — поэтапная разработка и совершенствование продукта небольшой командой специалистов различного профиля."
Статья в хабе "аджайл", я не знаю, как она к вам в рекомендации залетела.
Гугл вроде тоже пока работает, а для уверенных в себе есть яндекс.
Серьезно, вы на любой непонятный термин идете не в гугл, а в комментарии? Это не энциклопедия. Но специально для вас я дам определение в комментарии.
Scrum — это гибкая методология управления проектами и разработки программного обеспечения, которая используется для эффективного создания продуктов в условиях неопределенности и постоянных изменений. Основные принципы и элементы Scrum включают:
Итеративный и инкрементальный подход: Работа над проектом делится на короткие итерации, называемые спринтами, продолжительность которых обычно составляет от одной до четырех недель. В конце каждого спринта команда предоставляет работающий продукт или его часть.
Роли: В Scrum есть три основные роли:
Product Owner (владелец продукта): Ответственен за максимизацию ценности продукта и управление бэклогом продукта.
Scrum Master: Обеспечивает соблюдение Scrum-процессов, помогает команде устранять препятствия и содействует улучшению.
Development Team (команда разработки): Кросс-функциональная команда, которая работает над созданием продукта.
Артефакты:
Product Backlog (бэклог продукта): Список всех задач и требований к продукту, приоритезированный владельцем продукта.
Sprint Backlog (бэклог спринта): Набор задач из бэклога продукта, отобранных для выполнения в текущем спринте.
Increment (инкремент): Завершенная часть продукта, созданная за спринт, которая добавляется к предыдущим инкрементам.
События:
Sprint Planning (планирование спринта): Встреча, на которой команда планирует задачи на предстоящий спринт.
Daily Scrum (ежедневный скрам): Короткие (до 15 минут) ежедневные встречи, где команда обсуждает прогресс и выявляет препятствия.
Sprint Review (обзор спринта): Встреча в конце спринта для демонстрации выполненной работы и сбора обратной связи.
Sprint Retrospective (ретроспектива спринта): Встреча, где команда анализирует прошедший спринт и разрабатывает планы по улучшению процессов.
Scrum ориентирован на сотрудничество, адаптивное планирование и быструю доставку ценного продукта клиенту.
Если все уменьшить до одной фразы: я просто хотел программировать, а оказалось, что нужно взаимодействовать ещё с какими-то людьми
Scrum — рак, убивающий индустрию