Комментарии 135
Не помню откуда, но вполне вероятно, что из какой-то "библии" скрама/аджайла.
У внедрения любой методологии есть 3 этапа.
1) Обучение. Когда человек/команда обучается тому, что такое методология, какими свойствами она обладает, какие артефакты предполагает и какие цели преследует.
2) Реализация. Когда человек/команда стремится реализовать методология вот прям как написано в книгах. И это правильно, тк на этом этапе человек/команда не обладает достаточным опытом, чтобы понять, куда следует вносить изменения чтобы сделать методология эффективнее. Если начать вносить изменения на этом этапе, то получится классический "Scrum-but": скрам, из которого, в благих намерениях, конечно же, убрано или добавлено что-то, что ломает всю систему. Это как прийти обучаться карате и на втором занятии сказать учителю "слушай, а почему бы просто не взять нож, вместо вот этого всего?".
3) Адаптация. Когда человек/команда обладает достаточным опытом, чтобы понять, какие слабые стороны есть у каноничной реализации в конкретно взятом случае, можно вносить изменения, чтобы адоптировать методологию под конкретный кейс. И вот на этом этапе это приведет к повышению эффективности относительно базовой реализации. В аналогии с карате это стать мастером карате, а потом основать свою школу, где профессиональное карате будет сочетаться с использованием холодного оружия.
Если посмотреть глобально, то это частный случай цикла Деминга, который как раз и предполагает развитие "Планируй -> Делай (слепо) -> Рефлексируй -> Корректируй". В данном конкретном случае (при внедрении скрама или любого другого фреймворка) люди часто начинают рефлексировать не закончив стадию "делай".
И именно поэтому опытные Scrum-мастера и Agile-коучи - важный элемент внедрения методологии. Они как мастера единоборств, которые получили черный пояс в классической десциплине, а кроме этого повидали много разных уникальных кейсов и знают как можно быстро и безболезненно адоптироваться под конкретно ваш случай.
Впрочем, как и в случае с учителем карате, никогда не знаешь, реальный мастер перед тобой или выскачка, решивший нарисовать резюме. Но это уже вопрос HR отдела.
PS: а вообще, тот факт что в IT возникают такие проблемы при, в общем-то, элементарном и давно известном процессе внедрения любого производственного метода, говорит о том, что IT-шники и их руководители считают себя уникальными, не такими как все, с уникальными проблемами и уникальными же их решениями, а по факту просто обладают недостаточной квалификацией, т.к. все это объясняется в любой книге по классическому менеджменту, не говоря уже об MBA.
Вот мне интересно, если айтишники уникальные, то почему с ними вечно такие проблемы? Что ли в других сферах, в других производственных методах мало что ли людей с ЧСВ? Почему так значит с ними справились, а с программистами нет, значит. Нет ли тут противоречия?
Можно подумать только в айти проблемы, а в остальных сферах благодать. На стройке не работали?
IT-шника найти труднее.
Цена замены IT-шника выше.
....
В итоге баланс "послать работника и уволить (для нас денежные затраты для него наука) / нянчиться с работником" - в IT смещён в сторону второго варианта.
>>Впрочем, как и в случае с учителем карате, никогда не знаешь, реальный мастер перед тобой или выскачка
Очень странная аналогия. Учителя каратэ еще могут обосновать невозможность демонстрации всех их навыков тем, что причинение серьезных травм спарринг-партнеру - это уголовка. А коуч - это разновидность менеджмента. Ему никто применять свои навыки не мешает. Следовательно, к нему применимы те же критерии, что и к набору любого другого менеджмента.
Все так, вот только чтобы доказать умение причинять серьезные травмы, достаточно одного показательного боя, а чтобы продемонстрировать навыки менеджмента, коучинга, наставничества - нужно долго и сестематически работать по всем направлениям, в то время как решение об оффере нужно принимать до начала непосредственной работы. Поэтому крутых управленцев и коучей ищут исключительно по рекомендации доверенных знакомых.
Впрочем, тоже относится и к любым другим специалистам: от программиста до HRа, разница только в масштабе влияния. Если идеально прошедший техническое интервью программист, вдруг, оказался некомпетентным - страдает только его участок производственного процесса, который помогут закрыть товарищи по команде (а вот это, к слову, причина, почему часто в команде остаются некомпетентные специалисты - их прикрывает остальная команда, ценой двойных усилий), а если довелось нарваться на плохого коуча - он может всю компанию превратить в поле проигранной битвы.
Если чесно, я прочитал, но не понял - так о чем собственно? Просто способ подтолкнуть перечитать манифест?
Согласитесь, эти методики уже довольно таки описаны и работают. Я думаю, многие программисты 30- лет вообще могли ни разу не видет большого ТЗ.
Середина статьи про какой-то "мифический" баг, который создал ситуацию, описанную картинку з кучей людей-пауков я вообще не понял
-------------
Если мысль в том, что кто-то делает что-то не так и получает, к примеру, кашу в Jira - так блин, это не зависит от методологии вообще. Проблемы с ДНК методологией не исправишь, разве что найдя его носителю правильное место (часто "на улице")
------------
У меня есть ощущения, что по Scrum Guide я никогда не работал. Даже не потому что, лень его читать (он короткий ... как минимум тогда, когда я его читал), а потому, что действительно команад всегда выбирает как именно удобнее работать, так или иначе. Да, удобно брать оттуда термины, но следовать слепо ...
Середина статьи про какой-то "мифический" баг, который создал ситуацию,
описанную картинку з кучей людей-пауков я вообще не понял
ой, а мне это очень знакомо, я реально нашел баг в архитектуре в процессе спринта, который я не мог решить самостоятельно (и вообще это аффектило сильно больше компетенций чем было в команде и затрагивало другие департаменты), все до кого я дотягивался говорили что это не их дело и не их занятие, причем как я заметил по коду мои предшественники тупо копипастили код обходя его, судя по всему натыкаясь на это перекидывание ответственности и не желание его решать никем из формального руководства (у них же тоже спринт, а не ерунда какаято...за это джон отвечает...а джон на майкла перекидывает и т.п.)
я в итоге сам его экскалировал сильно выше и только так ситуация с таким кругом решилась...но это было явно не по аджайлу
Ну, нельзя же так. Agile/Scrum не универсальное средство от всех проблем :)
Некоторые постарше еще помнят откуда фраза " ... к пуговицам претензии есть?" или "грузите апельсины бочками. Не может короткое руководство решить все в жизни вопросы.
Метолология - это просто некий способ как делать вещи правильно. Но точно также вы можете строго по методологии делать их неправильно :)
Прописные истины... В чем сложность организовать работу людей (если ты их сам подобрал и сам мотивируешь), я не понимаю. Придумывают всякие аджайлы со скрамами. А потом на собеседованиях - что такое спринт знаешь? Нет? Пошел вон.... Так и живем......
В чем сложность организовать работу людей (если ты их сам подобрал и сам мотивируешь), я не понимаю.
Если вы не понимаете сложности, это еще не значит, что ее нет. Даже если предположить, что организованные вами люди работают хорошо, это все равно не добавляет понимания, как другим людям организовать работу хорошо. Методологии нужны именно для того, чтобы распространить опыт одних людей - другим.
да ой же ты. Я за 30 лет трудового стажа изучил порядка 10ти методик по организации производств, логистики и менеджмента. Включая триллиард способов управления коллективами. Все это фигня и не имеет отношение к каким-то настоящим сложностям вроде применения симплекс-метода для оптимизации логистических процессов, ну да ладно. Сдаю поляну:
будь личным примером для каждого
вникай в работу каждого, старайся сделать так, чтобы теоретически хотя бы ты мог стать за станок вместо любого сотрудника
будь ресурсом, решай проблемы людей. Человек пришел с проблемой - это для тебя приоритет номер 0, а не рисование непонятно чего на скрам доске
будь строг, но справедлив. Не заводи любимчиков не поощряй лень и склоки
веди отчетность, планируй, размечай, снимай контрольные точки. На каждом производственном этапе это твоя зона ответственности, и ни один скрам менеджер с сертификатом вместо тебя это не сделает. Занимаешься логистикой - веди в экселе табличку с номерами фур ФИО водителей и расстояниями. Для себя. Тупо чтобы в голове отразились все нужные тебе моменты. Это будет работать без всяких спринтов. Впрочем, можно назвать это спринтом, сойдешь за умного))
проводи совещания, но не злоупотребляй, держи середину. К каждому совещанию - актуальная повестка разосланная заранее всем участникам. Требуй приходить с предложениями и ответами по повестке. Не отклоняйся от повестки, не допускай базара. Сделай совещания как молитву - регулярными, я делал в понедельник в 10 и в пятницу в 16. Строго, без исключений. В понедельник - план на неделю, в пятницу - статус по плану и обратная связь. Чтобы в выходные подумали и подготовились морально к понедельнику
ЗЫ не благодарите....
И по факту вся эта каргокультовая хрень, проблемы планирования никак и не решает.
Приходит заказчик - мне надо запилить вот такой вот проект, сколько денег и времени мне это будет стоить? Что ему ответят? Мы прогрессивная команда, у нас есть Аджайл-коучи, модный офис с кофемашиной, мы умеем митинговать по утрам, проводить спринты и демо в конце, а потом зажигаем на ретро, мы можем работать с вашим проектом (подразумевается что мы будем с ним работать многие годы, пока нам не перестанут за это платить)
Опытная команда разберёт задачу, задаст все уточняющие вопросы, оценит в стори-пойнтах, возьмет какой-то фокус фактор свой и выдаст оценку.
и выдаст оценку в сторипоинтах.. ну офигеть, скажет заказчик..
И если это не первая такая задача у команды, то они вполне смогу сказать сколько и чего выйдет по деньгам и по времени, учитывая свои оценки в СП, свой фокус-фактор и свой прошлый опыт.
Оценка в СП поможет сравнить разные компоненты\элементы поставленной задачи и заказчик сможет выкинуть ненужные ему вещи, если выйдет дорого.
ПС: как вашу постановку задачи решает любой другой процесс?
Вот я заказчик, я пришел и спросил, сколько это будет в деньгах и времени, мне говорят - 3000 сторипоинтов. И что мне с этим делать? 500 сторипонитов стоит часть проекта, и что дальше то? У меня есть бюджет проекта, есть время, которое я готов на него потратить, и нафига мне эти ваши сторипоинты?
Сами аджайл-сектанты очень много рассказывают о том, что сторипоинты это не про время, а тут вдруг - уже про время иденьги?
Изначальный посыл был про то. что Аджайл - это про планирование работы, я аргументировал что это не так, при чем тут другие процессы?
Но и так-то, по моему мнению тот-же водопад даст более-мене адекватную оценку. хотя-бы по причине того, что он подразумевает создание достаточно детального ТЗ, перед выдачей этой самой оценки. Да, там может быть будут какие-то неточности, но это все равно лучше чем - "мы тут помитинговали, и решили что это все обойдется в 100500 сторипоинтов".
У меня ощущение, что вы не работали по аджайловским фреймворкам.
Когда я как участник команды говорю "это будет стоить 4сп", я в целом подразумеваю, что это около 4 часов. Да, на деле это займет какие-нибудь 10, но поэтому у нас есть всякие доп вещи типа фокус-фактора и чота там ещё, я не очень хорош в теории.
Итого, если мы фичу оценили в 3к сторипойнтов, то я могу на основе своих допущений (мой сп = 2 часа) сказать что потребуется порядка 6к часов.
Опять таки, вы говорите про ТЗ - но я же написал о том, что нужно будет позадавать вопросы, чтобы оценить детально. Никто не выдает из головы оценку в 3к сп, это будут десятки и сотни подзадач в фиче, которые будут оценены в более-менее понятные блоки. И вот эти блоки в сумме примерную картину дадут. Как вы в водопаде примерно скажете сколько стоит реализация ТЗ, так и в аджайле вы примерно скажете, сколько стоит реализация.
Да, идея СП - отвязаться от времени.
В реальности опытная команда знает как одно с другим у них связано.
А почему так получается то? Потому что непредсказуемая фигня =)
Я видел десятки проектов на водопаде, из которых один или два только угадали со сроками.
И видел десятки на аджайле, которые тоже приходилось резать на ходу, лишь бы успеть.
Поэтому у аджайла и есть отмазка - мы не даем оценку по времени.
Но в реальности, команда способна оценить средней степени фичи (в месяц-два-три в целом можно).
Это все субъективщина, как и с водопадом, как и с любой другой оценкой, Аджайл тут ни разу не помогает оценить задачу адекватнее. Что вам помешает в рамках водопада разбить ТЗ на более мелкие подзадачи и оценить их в любых попугаях которые потом можно перевести в часы? Точность при этом будет не лучше и не хуже чем в Аджайле.
Я работал, с тем что называли аджайлом. было оно этим или нет, я ХЗ в душе.. Вот вы пишите что вы там что-то подразумеваете, это круто, да, но пардон, ваши эти подразумевания к делу не подошьешь. Вашего менеджера спрашивают вполне конкретно - сколько времени и денег, и в качестве ответа сторипоинты какие-то там не приниаются.
Впрочем, я не первый год в деле, знаю как оно все делается, заказчику менеджер выдаст что-то что по его понятиям является конвертацией выданных командой сторипоинтов в часы.. как правило он не угадывает.
Ну, аджайл и не заявляет, что помогает с такой постановкой задачи. В целом, аджайл куда-то в сторону "мы будем делать то что вам нравится до тех пор, пока вы готовы платить". Т.е. если вам нужен продукт через полгода и за какую-то сумму, то мы полгода готовы поработать (от суммы зависит количество разработчиков) -- а сколько мы успеем сделать, попытаемся оценить. Мы дадим заказчику возможность смотреть на результаты часто и дадим возможность менять мнение тоже часто.
Водопад гарантий не даст тоже, но и результат выдаст скорее в конце (если адепты не готовы к нескольким "релизам" в эти полгода).
ПС: да, все в итоге гадают. Опытные команды\менеджеры просто лучше угадывают =)
Водопад не то что-бы гарантирует, но с ним вероятность выше, что к определенной дате, заказчик получит определенный функционал за оговоренные деньги. Да, там есть масса оговорок и проблем, но часто все-таки такая определенность лучше чем какая-та мутная "ориентированность на процессы".
А Аджайл это да, это про то что заказчик будет платить и каяться платить пока у него не кончатся деньги.
Аджайл на это обычно аргументирует "но то, что получит заказчик, не обязательно будет тем, что он хотел". В коротких спринтах одна из главных идей - показать заказчику и получить от него обратную связь - то не то делаем, так он это видел или нет. И если мы делаем фигню - мы быстрее об этом узнаем, скорректируем результат оперативно. В водопаде у нас такой возможности нет.
И отдельный момент с тем, что вам нужно ТЗ в случае с водопадом. Это ТЗ потом должны посмотреть разработчики и оценить. И это тоже магия - потому что нет ни у аналитиков, ни у разработчиков, ни у тестировщиков, ни у кого нет гарантий, что они это сделают именно так и в указанные сроки. Опытная команда даст лучше оценку, но это же касается аджайловских команд =)
Как по мне, это как раз одна из причин засилия довольно дерьмового софта. Заказчик ни на старте, ни в процессе работы сам не понимает что ему надо, а команда работает в режиме "чего изволите", по десять раз переделывая одно и то-же, хороня проект под дендро-фекальными наслоениями. Аджайл поощряет такое раздолбайство по факту, при котором огромные средства сливаются в унитаз, а виноватых в этом вроде как и нет хотя можно было-бы существенно сэкономить, просто разобравшись в задачах, и спроектировав все более-менее адекватно.
Да и водопад это тоже не догма, можно ведь и проектировать в несколько этапов, согласовывая каждый со всеми участниками, можно делать нефункциональные прототипы, много чего можно сделать.
Не понял вашу мысль. Заказчик в моем примере - один человек, да. И я размышлял в случае вида "у нас есть бизнес процессы, которые надо автоматизировать". Для такого случая понять, чего мы добились очень просто - автоматизированы ли процессы, стали ли процессы стабильнее, быстрее, ещё какие-то качественные оценки (что кстати требуется в аджайле\скраме - оценка результатов, метрики).
А есть ещё формат, где аджайл дает преимущество - всяческие сайты с большой аудиторией. Соцсети, крупные сетевые магазины, любые популярные сайты. И вот там очень удобно и логично регулярно проверять свои (менеджерские) идеи - понравится ли пользователям фича А, понравится ли фича Б, можно быстро выкатить какое-нибудь АБ тестирование, собрать статистику и реализовать фичу по результатам или отменить изменения. Можно смотреть даже комбинации фичей - пользаки любят А и Б вместе, но по отдельности работает плохо.
Ещё раз, чем аджайл отличается? Короткими спринтами. Почему? Потому что мы быстро получаем обратную связь от всех от кого можем. В идеале - от клиентов (соцсети и магазины), иногда от всяких заказчиков\лпр (когда у нас заказная разработка). И предназначено это всё для достижения быстрого и качественного результата, т.к. получая обратную связь, мы можем и должны делать продукт лучше. Когда у вас релиз раз в год, ваша обратная связь очень медленная, вы вынуждены проводить хотя бы коридорное тестирование, с надеждой что оно совпадёт с реальностью и пытаетесь исправить явные проблемы в конце релиза. А потом ждёте ещё год реальных отзывов от пользователей и клиентов.
А если мы все так при оценке расписали и оценили разве мы не получили весь цикл планирования водопада?
Получили. Хороший водопад и хороший аджайл в целом не отличаются. Просто у аджайла рекомендации про спринты в 2 недели, а водопад обычно имеет цикл больше.
Да, у всех будут свои реализации обоих этих процессов (т.е. каждая организация немного по своему будет делать), но принципиальной разницы я, как участник процесса, не замечал.
Если мы говорим про аджайл-подход, то это автоматически ведёт всех нас к контрактам Time & materials. Потому что с аджайлом подписываться под Fixed price с его фиксированным содержанием и временем - ну такое. Честный ответ будет такой:
Пока работы не начаты - сложно сказать, сколько это займёт времени. Только очень примерно.
После пары спринтов уже реально делать прогноз по времени, но это будет не дата, а диапазон.
Соответственно, заказчик должен определиться с ограничением: бюджет, время или содержание. Один из этих трёх параметров будет не фиксированный.
Конечно если речь не идёт про условно типовой сайт с не сильно большой кастомизацией под желания и процессы заказчика. Там можно наловчиться и на Fixed price. Просто закладывать риски неопределённости в сроки и цену.
По сути, вы сейчас описали все то, что до людей пытался донести Джефф Сазерленд, создавая Scrum. А не то, что они захотели в нем увидеть.
Жаль плюсануть не могу, карму слили опять не пойму за что, ну да ладно..
Согласен по всем пунктам, в таком окружении работать намного приятнее и эффективнее. Есть проблема - ты всегда знаешь к кому обратиться, никто тебя не дергает каждый день с отчетом, не надо на все эти "нытинги" убивать по несколько часов своего времени (да, эти "короткие" ежедневные совещания, чаще всего выглядят как часовая нудятина, на которой большая часть присутствующих пытается или поработать беспалевно или откровенно подремывает). Нет массы всех этих бессмысленных дурацких ритуалов , нет нервотрепки с постоянной нехваткой времени и попытками запилить фичу к бессмысленно, с потолка, поставленному дедлайну. Приходишь на работу, и просто работаешь, это ли не счастье?
Сдаю поляну [...] веди отчетность, планируй, размечай, снимай контрольные точки
Плохая поляна. Смысл методологии в том, чтобы объяснить как планировать и так далее.
А так ваш ответ сводится к "чтобы управлять людьми управляй людьми".
(по остальным пунктам можно было бы аналогично пройтись, но не вижу смысла, а этот самый показательный)
да вот нифига, это про то, как организовывать людей. Планирование вытекает из правильной организации всегда и собирается как бы по кусочкам. При правильной организации труда вам люди принесут на блюдечке готовый план, и задача скрам-мастера будет положить этот на бумагу, ну или на доску, как кому удобнее. Формат планирования в виде канбан доски - тоже не новый, к вашему сведению продавцы примерно так планируют свои сделки с клиентами, и у них это называется по другому (не вижу смысла описывать, извините), и применяется много где. Есть плюсы и минусы у этого формата, он не всегда подходит даже для простых мероприятий, не говоря уже о сложных.
Я вижу в ИТ индустрии определенные сложности именно в организации работ и в управлении людьми. Всем подавай "кулеры с печенками". А следуя данной "поляне" можно организовать практически любую работу, включая ИТ
да вот нифига, это про то, как организовывать людей.
Что "это"?
При правильной организации труда вам люди принесут на блюдечке готовый план
Вы под "правильной организацией труда" понимаете "у меня есть человек, который мне принесет готовый план"? Потому что иначе у людей, занятых разной работой, не обязательно есть достаточно информации, чтобы составить сквозной план этой работы.
А следуя данной "поляне" можно организовать практически любую работу, включая ИТ
Проблема этой "поляны" - в отличие от методологии - в том, что ей нельзя научиться. Это набор "по понятиям".
Ну и да. Вы начали с "не понимаю, в чем сложность", а потом выдали набор пунктов, где первый же - сложен в реализации.
SCRUM - это. Это методология управления проектами, а не методика планирования
Если вам сложно быть личным примером, тогда и руководить браться не стоит)))
SCRUM - это. Это методология управления проектами, а не методика планирования
Обратите внимание, что я нигде конкретно про скрам не писал. Я писал про отличие методологии (не важно какой) от "управлять людьми легко, вот я делаю так и так, делайте так же".
Если вам сложно быть личным примером, тогда и руководить браться не стоит)))
То есть все-таки в том, чтобы организовать работу людей, есть сложность?..
Вероятно дело в том, что на складе требования не меняются по два раза в день, и если заказчик просит доставить холодильники, то он после этого не удивляется, что вы привезли холодильники а не космолеты) Просто в IT другие риски, для борьбы с этими рисками и придумывают всякие гибкие методологии, которые на деле сводятся к "мы не знаем, куда можно наступать, а где мины лежат, поэтому будем двигаться мелкими шажками и постоянно рефлексировать над полученным опытом". As simple as that. Внедрение этих методологий людьми, не понимающими, как они работают и почему, часто превращается в карго-культ, чем вызывает ненависть рядового персонала и гневные посты в интернетах)
Всё понятно кроме предпоследнего пункта, а именно: "я делал в понедельник в 10 и в пятницу в 16 ". Неужели так много могло произойти за выходные? На моём текущем месте совещание проходит обычно по утрам вторника. Постановка задач за неделю и в понедельник есть время подготовиться к совещанию и подтянуть хвосты с прошедшей недели.
А я вот возьму и поблагодарю. Да, прописные истины, но вы их емко описали по пунктам. Личный опыт подсказывал такое же, но в слова не ложился.
Зачем?
Зачем при всеобщей гонке и конкуренции учить людей методологии:), эффективной методологии
Тут как в старом анекдоте про врачей, отец и сын
Сын приходит к отцу и говорит, я вылечил пациента, которого ты лечил 20 лет
Отец отвечает: Он нас кормил
Но самое интересное большинство и учится не хочет:) Можно же просто выучить слова, повторять их и иметь профит
В чем сложность организовать работу людей (если ты их сам подобрал и сам мотивируешь), я не понимаю
Хехе. Первый считает второго м...аком из-за политических взглядов. Второй на всех обиженный, что они не разделяют его политические взгляды. Третий достал четвёртую своими шуточками. Первый и второй задалбывают третьего переписыванием документации, потому что она им не нравится (она и правда хреновая, да). Четвёртая ссорится с пятой, потому что пятая считает себя более профессиональной на проекте. Шестой позитивный, все его любят, кроме второго, потому что шестой не разделяет его политические взгляды и т.д. Действительно, в чём сложность организовать работу команды живых людей? :)
Agile противоположен каскадной модели
Это как посмотреть. Отчетная единица в каскаде - все задачи. В скрам - пакеты задач "спринты". В канбан - 1 задача. Суть выбора в требуемой атомарности, остальное бантики.
На самом деле аджайл - это очень маленький водопад, потому что вам нужно всё то же самое, но часто.
Поэтому противоположен - неправда. И это ещё один минус автору текста.
Именно. Но адепты не признаются, водопадо-мастерами быть невыгодно.
Я работал с парой сертифицированных скрам-мастеров и ещё от пары слышал про сами курсы сертификации.
В целом я хз, кто занимается этой работой в водопаде - это куча менеджерской работы, вида "провести встречу, остановить спор уходящий в сторону от темы обсуждения, назначить (и провести) встречу с соседней командой, всяческие ретро". Кто-то эту работу делать должен, а как его назвать - мне лично не жалко, пусть будет скрам-мастер.
Проблема в том, что при частых итерациях у вас коммуникаций в целом становится больше, чаще и они должны быть оперативными и короткими. И вроде как за все эти коммуникации (как внешние так и внутренние) в итоге "отвечает" скрам-мастер. Мне роль не до конца понятна =)
может быть водопадом, а может и просто набором задач без зависимостей, и это удобно
Аджайл противоположен водопаду не потому, что оно большое или маленькое, а потому, что только в аджайле можно сделать фигню (да и описание может быть такой же фигней в 1 строчку), и переделать её в следующем спринте, потому что "общение и гибкость дороже договоренностей" (вольная цитата из манифеста); водопад же - это про конечность и финальность сделки с момента подписания ТЗ.
Поэтому задача ставится точно, деливерится точно, как описана, принимается точно, как описана, и никому не важно, несёт ли она к концу этого бизнес-ценность или нет.
Поэтому для водопада, даже мельчайшая задача ставится с макетами, описаниями, формулами и всем необходимым.
Не соглашусь. Делать фигню можно и там и там.
Люди и на водопаде уточняют требования, показывают промежуточные результаты заказчику и прочее-прочее. Да, при стабильных задачах можно этим пренебречь (пришла вам задача вида "с 1 января меняется формат взаимодействия с партнёром на такой то" -- никакой скрам вам не нужен, делайте водопадом спокойно), проблема больше в том, что бизнес теперь хочет быстро результаты. И вот ровно тот же водопад втиснутый в 2-недели спринта даст ровно те же результаты, что и аджайл.
Не стал дочитывать. Если вы убегаете от "церемоний" и вместо работы оптимизируете уход от работы -- вам никакой способ работы не поможет, ни ватерфолл, ни аджайл, ни какой-нибудь лесс или что там ещё существует.
Работал в проектах с лютым скрамом и это напоминало собрания по продаже гербалайфа. В гербалайфе и вообще mlm рассказ про продаваемый продукт занимает 5% времени, рассказ о том, как его продавать - 95%. Так и в скраме церемонии становились важнее того, что, собственно, делаем.
Так и в скраме церемонии становились важнее того, что, собственно, делаем.
Так это же первейший пункт Agile Manifesto! "Processes and tools over individuals and interactions"! \s
Есть один момент - именно у скрама в гайде написано, что если вы делаете что-то не по гайду, то у вас не скрам =)
Аджайл в целом более гибок, да.
Так правильно написано, если вы не следуете методологии, то у вас не она. Всё ведь там просто и расжёвано. Бери и делай.
Обычно всё упирается в бизнес, который рушит процессы, иногда обоснованно, иногда нет. Либо в разработчиках которые сопротивляются изменениям. Хотя им-то зачастую надо радоваться, тебя на N дней не будут трогать, сиди себе да работай, кайф же.
В крупных компаниях под микросервисы это в целом хорошо ложится. В маленьких в принципе не должно быть проблем.
Скрам мастер неслабо так загрузился, когда я сообщил ему, что скрам явно противоречит и противоположен эджайлу =)
Любая методика в конце концов возводится в абсолют и становится постулатом веры. Реализация и водопада и аджайла по факту идёт плохо, криво и неумело, по шаблонам. А успех в IT достигается только там, где небольшая команда имеет полную самостоятельность и автономию в своих действиях а аджайл это будет или водопад совсем не важно.
прямо ПОЛНУЮ??? Без дедлайнов и с анлимитед бюджетом??? Это где такое существует???
Есть места, где нет менеджеров-идиотов, они предпочитают заниматься своим менеджментом, дедлайнами и бюджетом где то далеко не напрягая мозг подобной херней разработчикам
Для меня scrum - это способ создать хорошее по с нулевой командой, которая даже никогда не работала в команде; с владельцем продукта, который никогда не был владельцем продукта. Вы можете слепо следовать инструкциям и у вас что-то получится. Чтоб получить хороший результат нужно следовать инструкциям обдуманно.
Как и любой "язык", scrum адаптируется под вас. Владелец продукта (возможно совместно с мастером и командой) шлифует книжные процессы и это нормально. И всегда будут ситуации, которые не встраиваются в идеальный процесс. И умение руководителей - это способность с этой ситуацией справиться. Если руководитель не имеет богатого опыта, то он будет работать по книжке и это нормально.
Оценка и "ритуал оценки" - это собрание на котором вы можете обратить внимание на отклонение. Если кто то задачи не может или дает очень большую оценку, то это сигнал как минимум поговорить о задаче. И на этом собрании команды вы можете задать вопросы, которые помогут вам с оценкой и улучшить качество постановки задачи. И оценки даются интуитивно, никто не запрещает так давать оценки задачам.
Про отсутствие скрам мастера или владельца продукта. Все в команде должны быть взаимозаменяемы. Это даже в манифесте прописано. Взаимозаменяемость среди тех специалистов полноценную я не встречала (очень ограничено), а вот роли между собой мы вполне могли менять.
Выбрать правильную методологию и адаптировать ее под свою команду - это задача руководителя. И да на некоторые проекты не ложится идеи scrum, некоторые должны работать по водопаду, а кто-то работает по Extreme programming (XP).
Встречал только хорошие реализации Scrum - прозрачные процессы, команды самодостаточны и организованы, гарантированная доставка ценности, можно измерять производительность спринтов.
Бывает карго-культ, который скрамом не назовешь. Игры в planning poker и burndown-диаграммы. :))
Любая статья про аджайл/скрам/что угодно гибкое начинается с Бабы Яги - ужасов каскадной модели, которую так же называют Waterfall. Каскадную модель описал Винстон Ройс в своей статье 1970 года как возможную на первый взгляд модель разработки, которая на самом деле НЕ существует и НЕ работает. Но продавцы гербалайфа адажйла с тех пор используют "соломенное чучело" для более эффективной продажи своего подхода. Как-будто без этого аджайл ни кто не купит.
В эпоху капитализма востребованность (и косвенно вытекающий из неё теоретически возможный заработок) всё-таки не измеряется единицами "кто-то" и "никто".
Работал в разных конторах и с водопадом, скрамом, скрамбаном, и канбаном. И настоящим, и называемым таковым. Везде были свои причины, суть которых указал в комментарии выше. No two companies are alike.
активного копипастинга из ChatGPT
Сильно сказано - активный копипастинг!
Scrum — это Agile-система управления проектами
Не правда. Фреймворк Scrum появился гораздо раньше, чем был задуман и опубликован Agile-манифест (в начале 90-х). Таким образом, Скрам никакого отношения к философии аджайл не имеет.
Agile итеративен
Строго говоря, аджайл-манифест не предписывает вообще никакого процесса (кроме короткой рекомендации отдавать ПО заказчику почаще). Но это лишь рекомендация, а их там больше десятка.
Scrum поломан
С основным посылом статьи согласен, но беда в том, что автор вообще ничего не сказал нового. Ну да, вода - мокрая, скрам - ужасен, жизнь - тлен.
Помню очень плохую историю с внедрением скрама, у нас митинги стали занимать половину рабочего времени, от чего все дико уставали и накапливалось раздражение, там все было как в скраме из статьи. Покер планирования, рубашки, длинные грумминги, ретро, созвоны с другими командами. Такое ощущение, что на нас пытались опробовать вообще все методики из скрама. Дошло даже до оценок сколько реального времени каждая задача заняла.
Как итог, треть команды уволилось, мне повезло, я догадался уйти в отпуск, а как вернулся из него, то этих скрам мастеров выгнали нафиг.
Никогда не понимал в чем у линейных разрабов проблема с митингами на пол спринта. Тебе дают кучу свободного времени, еще и платят за это. Сиди, решай литкод / играй в игры / работай на второй работе / ешь / любое действие рядом с компом. А если немного подумать, то можно четко определить, где тебе надо говорить / не надо говорить и просто такие созвоны принимать и уходить куда надо или вообще на телефон фоном просто присоединиться
Если человек реально хочет делать дело, то такие бесконечные митинги вредят делу и раздражают. В этом и есть противоречие, с одной стороны хотят проактивного чела, который бизнес понимает, софт-скилами обладает, да и вообще горит желанием приносить пользу. С другой стороны такого человека начинают мариновать митингами, бюрократией и всякой прочей раздражающей фигней.
Это хорошо, если помитинговали, время на митинг списали и дальше работают в обычном режиме. А еще бывает когда требуют результат и сроки, а работать не дают. Митингами в том числе. Внедряют всякие мега методики, оптимизации, контроли, коучинг, личные цели, командные цели, план развития, контрольный лист исполнения контрольного листа и все такое прочее. Такое ведь тоже бывает.
Если человек хочет делать дело, то ему явно не в корпорат. Пожалуйста, есть стартапы, меньше созвонов / больше действий. Есть фриланс, совсем без созвонов. Есть свой бизнес, вообще как хочешь, так и делаешь. Не секрет, что в больших компаниях ( да и не очень больших, но уже и не стартапах) много созвонов и чем дальше, тем больше. В корпорате люди либо сидят тихо на зп, либо строят карьеру и тут правила игры какие есть, не хочешь быть говорящей / слушающей головой - не повысят.
Если бы не ложное противопоставление Agile Waterfall…
Если найден баг, то его без проблем закидывают на программиста, который фиксит его в том же спринте в основном, переносы на другие спринты бывают, конечно. Не понятно откуда у сочинителя статьи взялась проблема с якобы перекладыванием ответственности за баги.
который фиксит его в том же спринте
Откуда в спринте берется время на незапланированные задачи? Добавляете что-то в середине спринта, что-то надо выкинуть) Есть еще проблема что менеджеру/начальнику/заказчику понравится менять спринт на ходу. Типа починили же баг, вот есть срочная хотелка. Так что "без проблем" тут явно не обойтись.
Очередное подтверждение факта, что любую здравую идею можно превратить в УГ бестолковой реализацией.
Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.
Это в каком веке автор написал оригинальную статью? Смотреть нужно на https://scrumguides.org/index.html. А теперь настоящая цитата с отсылкой к источнику:
Scrum — легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.
Определение Scrum из Руководство по Scrum. Могу только лишний раз заметить, что не стоит слепо верить всему, что на Хабре пишут/переводят некоторые — все нужно перепроверять в источниках.
Церемонии
Scrum-команда должна следовать некоторым церемониям.
Примечание: мне никогда не нравился этот религиозный термин, используемый для описания подобных совещаний, но что уж есть.
А действительно, когда он это писал? 18 октября? Видимо, писал по памяти, а она, порой, как известно, подруга ненадежная) Нет там никаких церемоний, есть события (events). Ищем там же раздел События Scrum.
Ежедневные совещания — ежедневные КОРОТКИЕ совещания (примерно 15 минут), на которых маленькая команда разработчиков (примерно 3-7 человек) обсуждает свой прогресс и выделяет мешающие двигаться дальше проблемы, не вдаваясь в подробности. Это время, в которое можно попросить Алису устроить отдельное совещание о проблеме кэширования на стороне сервера и спросить Боба о том, почему параметр даты является строкой, а не временем Unix.
Ну и чушь (как автор просил называть ?) Вот такие товарищи сначала ничего не поняли, а потом вещают что это плохой способ работы) Знаете зачем Daily Scrum? Да, формально каждый должен ответить на три вопроса, однако спрашивать Боба о типах данных не нужно. Вы можете и обычно так и происходит, после Daily Scrum устроить любые беседы по обсуждению типов данных, но после. Daily Scrum — это не только апдейт для коллег и источник информации о проблемах для Scrum Master, это (о чем многие не догадываются) один из способов культивирования самоорганизующейся команды. Самоорганизующаяся команда — это одна из основ и часто вы должны задать себе вопрос: если команда не может сама организоваться и провести Daily Scrum так, как это ожидается, то как она вообще станет самоорганизующейся? У кого-то это сечас вызвало жуткий зуд)
Это отдельные личности или группы, определённые в Scrum:
Стейкхолдеры — это заинтересованные лица, они хотят быть информированными, участвующими, они получают прибыль от продукта, чем бы ни был «продукт» в вашей компании. Да, при желании определение «продукта» можно растянуть на что угодно. Это могут быть конечные пользователи, другие команды и даже другие бизнесы.
Теперь я точно уверен — да, автор изучал Scrum в прошлом веке) Нет там никаких стейкхолдеров, есть только три роли)
Планирование, вне зависимости от инструментария, занимает кучу времени, и в результате вы получаете заранее установленные задачи, измеряемые в сторипоинтах. Эти поинты, которые должны помочь в понимании сложности конкретной задачи, вместо этого используются для измерения времени.
Опять чушь) В сторипоинтах User Stories, а задачи, которые реализуют конкретную User Story — их скоуп определяется так, чтобы занимать не больше одного рабочего дня, то они, фактически, измеряются в длительности по времени, нет никаких сторипоинтов у задач)
Представим возможную ситуацию: ни владельца продукта, ни Scrum-мастера нет в офисе. Один на больничном, второй в отпуске. Будет ли ваша команда продолжать участвовать в ежедневных совещаниях? Сомневаюсь.
А теперь перечитайте выше — если команда не может сама организовать такое простое событие, как она будет вообще самоорганизовываться? Если никак, то потом и будут появляться такие авторы, которые несут эту чушь, скрывая свою ненависть за шуточными высказываниями.
Scrum - для производства, а не для разработки нового.
При разработке важна бесконечная итеративность, а результат всегда непрдсказуем.
В agile/scrum я вижу очень значимый плюс - все, что не успели переносится в другую итерацию, и все счастливы. но увы у нас это не работает. А про нежелание брать сложные задачи - это особенность большинства людей, поэтому задачи надо раздавать в соответствии с должностями и умениями, мониторить прогресс и помогать, если надо. Как-то работала в команде с программистом, который, несмотря на приоритеты, сначала всегда фиксил лёгкие баги, а потом при приближении к релизу оставалась куча хороших багов, заассайненных на него, и их приходилось разгребать всем вместе в срочном порядке и с переработками. И ПМ эту ситуацию знал, даже устанавливал специально для него приоритеты, но программист особо не менял свое поведение, и где можно действовал по своей старой схеме. Поэтому мое мнение, какую бы хорошую методологию не придумали, какие бы классные не были ПМ, скрам-мастер, тим- и техлиды, все равно найдутся либо недовольные, либо пытающиеся как-то все это обойти люди. А про метрики эффективности - к сожалению большинство ПМов нормально их не анализируют, тут только в каждом случае разбираться, что не так. "Неэффективность" кстати и на мелких задачах может случаться часто, потому что недооценили или пропустили что-то, а человек вместо того, чтобы идти разбираться и заводить новую задачу, подумал "да ладно сейчас я быстро" и не получилось.
Персональная статистика проектов показала, что на проекте со Scrum-ом более низкий уровень здравого смысла, более высокий уровень какого-то бреда и более высокий уровень прогнивания фирмы. Наиболее здоровые проекты на мой взгляд, это проекты с диктатурой сильного и влиятельного Fullstack программиста архитектора. Которому хватает влияния и полномочий продвигать правильные решения и блокировать всякий бред.
Особая удача, если этот диктатор футстек продвигает скрам и учит других брать на себя обязательства
Наиболее здоровые проекты на мой взгляд, это проекты с диктатурой сильного и влиятельного Fullstack программиста архитектора. Которому хватает влияния и полномочий продвигать правильные решения и блокировать всякий бред.
И причем тут вообще Scrum или его отсутствие?) А когда диктует один человек, то и решения получаются однобокие, один никогда не будет знать все и принимать идеальные решения, другое дело когда в Scrum Team три сеньора собрались и решили как сделать лучше и нафиг диктатуру.
Первый шаг к возможному улучшению - начать платить за результаты спринта.
Тогда и команда начнёт улучшаться самостоятельно, чтобы больше заработать, и помогать друг-другу будут и избавляться от слабых и токсичных, и процессы упрощать и т.д.
ни в коем случае нельзя так делать
во первых согласование спринта затянется на недели
во вторых надо писать очень подробные пояснения почему мы не виноваты что прод упал после нашего спринта
в третьих менеджмент не глядя будет рубить эти премии по любому косяку...не разбираясь правомерно или нет
Тогда и команда начнёт улучшаться самостоятельно,
дада, давайте еще коллективную ответственность внесем, ведь то что вы предлагаете это и есть
10 человек пахали как лошади, а 11-й человек запорол спринт потому что простудился, все остались без денег. (добавить форсмажор в исключения? отлично, будет дежурный больной который каждый раз когда чтото не так будет болеть и спасать зарплату)
внезапно я в некотором роде это всё видел, правда не в ИТ, этому дежурному васе-стрелочнику все скидывались на премию которой его официально решали каждый раз за постоянные провалы (которые по договоренности на него вешали)
Затянули согласование, значит делаем это не эффективно, не получаем денег. Думаем как улучшиться в следующем спринте.
Также уверен, что много адекватных топов или стейкхолдеров и косяк одного поймут и заплатят. Ну а 11ый ставится на карандаш. Косячит из спринта в спринт, когда сама его подтянет или заменит, т.к. не готова постоянно нести за него "коллективную ответственность"
На мой взгляд нужно исходить из основной цели - это заработать денег. Crum - это лишь один из инструментов (или фреймворков) как это сделать более эффективно команде разработки. Если вы его используете, чтобы наладить работу, а не заработать - вы его не правильно используете.
Команда важнее процессов и всё такое доброе - нужно правильно использовать, а не прикрываться этим.
Затянули согласование, значит делаем это не эффективно, не получаем денег. Думаем как улучшиться в следующем спринте.
я тупо уволюсь и пойду туда где деньги платят за разработку, а не построение коммунизма, а вы там дальше играйте в саморегуляцию
Также уверен, что много адекватных топов или стейкхолдеров и косяк одного поймут и заплатят.
категорически не уверен, меня разок перевели в другой департамент только за то что я отправил таску на согласование в СБ потому что у меня было подозрение что она вызовет нарушение безопасности перс.данных, из-за чего просрочился спринт.
Ко мне пришел целый руководитель департамента с жалобой что у него срывается КПИ по релизам, а я крайний и вообще какого чёрта я творю (дырка в безопасности это другой департамент (куда я и пошел), а у него релизы..)... и меня перевели к другим.. это на секундочку забугорная известная крупная контора была
Если вы его используете, чтобы наладить работу, а не заработать - вы его не правильно используете.
я в компании работаю чтобы продукт создавать который компании приносит денег, а не чтобы команда где я работаю и я сам заработали денег. Это вещи не связанные друг с другом иногда вообще
Команда важнее процессов и всё такое доброе - нужно правильно использовать
Это мантра для HR-ов и скраммастеров, всё сразу заканчивается когда режут бюджет, лайофом рубанут сразу независимо от процессов и доброты.
у нас одним махом сократили всех оутстафферов, человек 50 (и меня в том числе), некоторых прям сразу после очередной сходки на тему "как мы ценим наших сотрудников и повышаем эффективнось"
Если в компании есть не слушающие, дикие или отбитые на голову - надо сразу уходить. Полностью согласен и поддерживаю с этим.
Ну и к сожалению от диких закидонов руководителей тоже увы никто не застрахован. Но на моей практике хорошие и эффективные команды носят на руках и заливают их какими только можно благами, лишь бы они продолжали и дальше также работать. И тот же адекватный руководитель это понимает, т.к. по результаты его команды оценивают его эффективность.
Но на моей практике хорошие и эффективные команды носят на руках и заливают их какими только можно благами
Решение о сокращении обычно принимают выше непосредственного руководства
мне вот весной списки пришли уже даже с фамилиями и датой увольнения...кое как одного человека отстоял...и то его всёравно перевели (ну хоть не уволили), потому что результаты результатами, а бюджет важнее
причем контора вполне себе адекватная
Кстати, статья - огнище! Автору огромное спасибо за описание работы "русского" скрама.
Скрам ужасен уже тем, что там просто "разработчики". Техлиды, аналитики, тестировщики - нет, авторы скрама об этом не слышали.
Так, а ужасного из этого что?
Developers оно просто потому, что там вся команда, все участники которые производят продукт. Туда же можно (если нужно команде) добавлять юриста, безопасника, кого вам нужно. И все они работают в рамках скрама одинаково, скрам не говорит что у какого-то участника developers есть дополнительные обязательства.
Ну как минимум два разных набора ролей выходит. Один как в книжке по скраму написано, другой как в жизни.
И обычно мнение техлида несколько важнее, чем мнение джуна. А в рамках скрама, оба они одинаковые "девелоперы".
Так, а какая разница, техлид ты или джун?
Вы должны спланировать спринт, выполнить задачи на спринте, выпустить релиз, показать демо.
Техлид и джун в этих всех активностях выполняют свою работу как умеют. Техлид в теории лучше справляется, джун учится у опытных коллег. Когда вы проводите какой-нибудь PBR для понимания как делать сложную задачу, джун как раз получает от техлида полезную информацию, уточняет как сделать хорошо.
Какая часть процесса спринта требует разных активностей от техлида и джуна то?
А с аналитиками и тестировщиками как быть? Вроде обычно сначала аналитик пишет ТЗ задачи, потом программист задачу выполняет, потом тестировщик тестирует. И как это согласовать с идеей, что все участники команды во время спринта работают только над задачами спринта? Чем будет заниматься аналитик в конце спринта?
Можно разные варианты использовать:
Писать другое ТЗ в конце спринта. Ну т.е. фича1 написана, фича2 в работе у аналитика.
Общаться с разработчиком тестировщиком и кем угодно ещё, уточняя мутные моменты. Разработка уже может быть запущена.
Прорабатывать с тестировщиком тест-кейсы или что-то ещё вокруг нового ТЗ.
Аналогично у других ролей - если для них есть хоть какая-то работа -- можно ею заниматься в "свободное" время.
И ещё момент - не обязательно загружать каждого члена команды на 100%. Главное сделать то, что вы запланировали, вам за это и платят.
Насколько я понял суть этой религии, подразумевается что нет там никаких тестировщиков, аналитиков, девопсов и прочих, есть просто сферический разработчик в вакууме, который во все это умеет и все делает на отлично, сразу, с первой попытки.
Весь этот скрам это по факту про запиливание фич, но в реальности так никогда не бывает, что-бы все только и делали одни фичи.
Например как-то во все эти спринты и прочие приседания очень плохо укладывается работа с багами, а их может быть просто дохрена, особенно в условиях искусственно созданной нервотрепки с дедлайном к демо, когда все запиливается на костылях, лишь бы успеть и не облажаться.
Вообще никак не учитывается то, что часто возникают проблемы с инфраструктурой, которую надо развертывать, поддерживать, чинить при падениях,
Вообще игнорируется возможность всяких авралов, когда вся команда бросается на амбразуру падающего прода..
Да много что адепты предпочитают не замечать, и потом рассказывать что мол - это у вас аджайл просто неправильный такой, неидеальный, потому и работает все через..
Нет, вы неправильно поняли. Есть все участники, необходимые для реализации фичей. Обычно есть и аналитик, и разработчик, и тестировщик. Если нужно - можно добавлять любых других людей в команду (выше я уже писал про юриста и безопасника), хоть массажиста, если он позволяет и помогает выпускать вам качественные релизы.
Работа с багами должна быть вашей рядовой работой на спринте. Должна проходить весь стандартный цикл, как и фича. Т.е. вы должны планировать фикс багов, исправлять их и тестировать, релизить. Для срочных багов это может быть вне спринта (не привязано к нему), тут есть разные подходы, расписывать лень, но в целом проблем это не вызывает.
Демо с костылями лишь бы не облажаться - очень плохой подход. Если у вас такой - обсудите это на ретро со всеми участниками команды. Демо должно быть того, что вы сделали. Не каждое демо (не каждый спринт) вам есть что показать, возможно на спринте было написано ТЗ, составлены тест-кейсы, а разработчики исправляли техдолг и срочные баги.
Для всех вещей которые вы называете проблемами и авралами как раз аджайл и лучше. Когда у вас релиз раз в год (условно) - у вас будут проблемы и с деплоем, и с срочным закрытием последних найденных критичных багов, и с падающим после такого релиза продом. Когда у вас каждые 2 недели релиз (а какие-нибудь вк или фейсбук релизятся намного чаще, судя по статьям), вы со временем отлаживаете процедуру релиза, вы вынуждены это сделать. Ваш деплой должен быть быть простым и стабильным, в некоторых ситуациях у вас ещё и откат релизов простой и стабильных. Когда релизы частые, срочные баги в целом исключение, потому что вы выкатываете очень маленькие изменения, в них сложнее допустить критичную ошибку. Да, всё ещё можно, это всё ещё будет случаться, но у вас есть стабильная инфраструктура и стабильные релизы, вы исправите ошибку оперативно и выкатите её.
Как боженька сказал!
Вы озвучили все мои мысли по этому поводу! Спасибо!
Другими словами:
Если вы нихрена не понимаете в разработке и реальных процессах, которые происходят у вас в команде, то что бы ты ни делал, хоть по скраму, хоть нет - получится говно. А если вы внимательно следите за процессами, понимаете суть ваших управленческих решений, и ставите результат во главу угла, то что бы у вас не получилось, будет гораздо лучше, чем в первом варианте.
Большинство проблем реального скрама в формальных размерах спринтов. Одна неделя, две недели, даже месяц это всё слишком формальные оценки времени которые порождают много формальной бюрократии. Привяжитесь к версиями релизов/срокам релиза:
Вместо формальных еженедельных планирований и формальных отчётов кто что сделал за неделю у вас будут нормальные "живые" планирования следующего релиза.
У всех возникнет чёткая картина того что надо сделать чтобы получить результат. Результат(!!!), а не формальный отчёт о сделанных за неделю задачах. Сходите, прямо спросите у бизнеса, им результат нужен или отчёты о сделанных за неделю задачах (только спрашивайте у бизнеса, а у не наёмного менеджмента).
Пропадут все еженедельные переносы задач. Задача нужна к релизу? Ну и делай её до релиза. Размер и дробление задач перестают быть краеугольным камнем
Стори поинты конечно надо оставить, но только как предварительную оценку сделанную самим разработчиком. По закрытию задачи можно вписывать реальную оценку
Тут конечно некоторые менеджеры возмутятся: а как нам видеть прогресс? А как нам оценивать эффективность сотрудников? Да так же как и обычно, по субъективной внутренней оценке скорости/качества/вовлечённости. Конечно менеджеру чтобы так работать надо "быть в теме", быть достаточно квалифицированным и держать руку на пульсе проекта, а не появляться только на планированиях спринта. Если вы так не можете то welcome в отделы продаж и колценты, там формальные оценки любят.
Scrum ужасен