Комментарии 59
Жаль картинки не в одном стиле :)
В остальном было интересно освежить в памяти
Спасибо за замечание! Учту в следующей статье
И про разрешение добавлять задачи в течение спринта тоже интересно было бы подробнее прочитать, я и не знал что внесли изменения, интересно когда и чем мотивировали
Ссылка на скрам гайд: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
--
Но так, я с тобой согласен. Когда готовился к PSM был удивлен, когда в тестировании был вопрос на эту тему. Этот момент на самом деле был один из решающих в том, чтобы написать эту статью
обязательные регулярные дейли-созвоны в одно и то же время (по утрам как правило) - это по факту основная и самая прoтивнaя особенность скрама.. абсолютно бессмысленное действо, сколько бы ни рисуй табличек и не описывай пользы.
все созвоны командой - должны быть или по необходимости, или по точкам необходимой синхронизации. и один день - ну очевидно, абсолютно никак не может рассинхронизовать людей, делающих свое дело. это полный бpeд. интервал общей синхронизации должен быть соизмерим с некорректным путем работ, который в самом неверном раскладе самого непонимающего участника команды может случайно образоваться. и это точно не один рабочий день, когда у всех есть мозги.
а необходимость в этом только у проджект-менеджеров, чтоб ощущать свою ежедневную "работу". и для суетливых тимлидов.
не человек для методологии, но методология для человека. если бы эти дейлики были бы просто по желанию кофе-брейк да по общаться и возможно что-то сообщить при желании (хотя чаты для этого есть всегда) - вопросов бы не было.
PS. про то что, некоторым нужно утром подольше поспать, чтоб быть продуктивными и что такая "гибкая" методология не дает нормально это сделать - молчу.
Спасибо за комментарий!
Если смотреть по Scrum Guid, то там говорится, что Daily нужны только разработчикам для того, чтобы понимать как идете к цели спринта. Может кто-то встал в тупик и на дэйлике об этом скажет и кто-то сможет помочь.
Меня он на самом деле много раз выручал. Всегда в голову приходит случай, когда увидел, что функционал не корректно работает. Хотел его поправить и сказал об этом на дэйли. Оказалось, что другой разработчик делает связанный функционал и поправит этот баг во время ее решения. И за счет этого я не потратил время на решения данного функционала.
Ещё один плюс регулярных встреч (хотя это и не совсем соответствует принципам Scrum, но всё же) заключается в том, что в небольшой компании бизнес может часто запрашивать сроки и статусы. И в таких случаях можно предложить им: «Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
Может кто-то встал в тупик
Имхо, нужно просто зафиксировать в команде, что если ты как разработчик понимаешь, что встал в тупик, то напиши в чат команды. Может ответят и не сразу, но наверняка раньше следующего дейлика.
Оказалось, что другой разработчик делает связанный функционал
Исходно неправильное распределение задач по команде? Здесь также работает принцип, наткнулся на что-то – отпиши в чат команды, когда у других будет возможность посмотреть, они ответят. Результатом будет либо "кто-то другой уже решает эту проблему" либо новая задача в план либо другой набор инструкций что делать с этим.
Нужно по максимуму использовать возможности асинхронного общения.
Ещё один плюс регулярных встреч (хотя это и не совсем соответствует принципам Scrum, но всё же) заключается в том, что в небольшой компании бизнес может часто запрашивать сроки и статусы.
Для отслеживания статуса задач существуют таск-трекеры а-ля JIRA, с широким набором возможностей. Вместо того, чтобы заставлять всех подстраиваться под ежедневный созвон/встречу, где примерно 80% коммуникаций бесполезна с точки зрения бизнеса (имхо), стоит делать упор на то, чтобы команда своевременно обновляла статусы по задачам и давала обратную связь, особенно если возникают непредвиденные сложности.
P.S.
«Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
Так всё равно не бывает практически никогда, потому что появляются какие-то срочные вопросы, когда дейлик этого дня уже давно позади, а до следующего вопрос не терпит.
Когда в команде 2 - 3 человека и на ту же неделю 2 - 3 крупных задачи на всех - можно и чатом обойтись. Когда 7 - 10 человек - уже сложнее. Во-первых - не все читают и вчитываются. Срабатывает фактор - ой, там уже вроде ответили и какой-то диалог идёт, значит уже решают вопрос. Во-вторых - если ты занят, много других более срочных вопросов, погружен в работу, ты не будешь сидеть и перечитывать чат, если там +100500 сообщений за полчаса. Плюс когда на неделю не 2-3 крупных задачи - тут да, смысла нет дёргать каждый день с вопросами, что в работе и как там. А когда они мелкие и их штук 15?
А-ля Jira - давайте будем честны - не все сразу же фиксируют там инфу о наличии блокера, в первую очередь сидят и тратят ещё какое-то время на выяснение причин и попытки решить проблему.
Вобщем, на мой взгляд, вы отметаете человеческий фактор.
Я тот человек, который каждый день проводит те самые, ненавистные вам утренние звонки)) Если вопросов, замечаний, комментариев нет - то звонок заканчивается быстро.
А чаты.. Конечно удобно для истории, и что беседа может быть рамазана во времени, но у меня в моменте может быть по 10 чатов, где идёт активные беседы и сотни сообщений. Опять же, ввиду специфики работы, я сижу и или в конце дня все перечитываю, или утром (что бы быть в курсе.
Опять же, на практике моей команды - мы многие вопросы решаем (или находим путь решения) именно через ежедневные звонки.
Вообще странно говорить о том, что если вопрос задан в чате, то на него не смотрят и не отвечают, а если то же самое задано при встречи 10 человек, то все бросятся на него отвечать, а те кому это вообще не нужно будут внимательно внимать ответу, переваривать ненужную информацию или вежливо сидеть в стороне.
Конечно, если в рабочем чате рассказывать про погоду, поход в кино и обсуждение книг, то наверное там будет "100500" сообщений которые занятой разработчик не будет читать (вместе с теми, что "по делу").
Чисто моё видение вопроса.
А-ля Jira - давайте будем честны - не все сразу же фиксируют там инфу о наличии блокера, в первую очередь сидят и тратят ещё какое-то время на выяснение причин и попытки решить проблему.
Вот как раз за соблюдением этого должно следить ответственное за команду лицо и напоминать о необходимости соблюдения регламента, пока это не дойдёт до автоматизма.
Срабатывает фактор - ой, там уже вроде ответили и какой-то диалог идёт, значит уже решают вопрос.
Ничего страшного в этом не вижу, до момента X, когда станет ясно, что для решения вопроса нужны именно Вы, всё равно пройдёт меньше времени, чем до следующего дейлика.
Во-вторых - если ты занят, много других более срочных вопросов, погружен в работу, ты не будешь сидеть и перечитывать чат, если там +100500 сообщений за полчаса.
В этом и прелесть асинхронного общения, нет необходимости всегда перечитывать всё. Полчаса должно быть достаточно, чтобы выяснить кто именно нужен для решения проблемы и этого человека тегнут в чате, и только в этом случае, ему необходимо будет прочитать часть сообщений до, чтобы войти в контекст проблемы.
Я тот человек, который каждый день проводит те самые, ненавистные вам утренние звонки)) Если вопросов, замечаний, комментариев нет - то звонок заканчивается быстро.
Я тоже человек, который каждый день тратит время на такие звонки, и хорошо, если звонок укладывается в 20-25 минут.
В этом и прелесть асинхронного общения, нет необходимости всегда перечитывать всё. Полчаса должно быть достаточно, чтобы выяснить кто именно нужен для решения проблемы и этого человека тегнут в чате, и только в этом случае, ему необходимо будет прочитать часть сообщений до, чтобы войти в контекст проблемы.
прокатывает, если реально все заинтересованные и нужные лица находятся в одном чате и хоть как-то отслеживают тему дискуссии (хотя бы по-диагонали)
Вы все равно пытаетесь исключить человеческий фактор. Плюс полностью ассинхронное общение увеличивает вероятность того, что нужная/полезная информация дойдет до всей команды. А если уходить в приватные чаты, что бы не спамить в общем - опять по 50 чатов на каждую тему.
Если команда работает слажено (без краткого пересказа Войны и мир на тему "как я провел вчерашний день"), то 15 минут утреннего звонка более чем достаточно озвучить блоки, проблемы и быстро определить и свести тех, кто может помочь в том или ином вопросе. Тут уточню, что 15 минут - это если у тебя не 30 человек на звонке. Плюс если команда распределенная в разных часовых поясах - сиди и жди, пока найдется тот, кто к твоим 6 вечера только приступает работать и еще пойдет почитает все.
Чаты тоже не все сидят читают. И почту тоже (тут тоже недавно много кто написал - "какой смысл читать почту? кому надо - и в личку напишут". Или начинается - не видел/не прочитал/не обратил внимание.
Если у команды множество разных задач, не сильно связанных друг с другом - утренние звонки помогают оставаться в курсе событий. Ну а если вся команда работает над задачей "измени цвет кнопки" - тут конечно смысла собиратся каждый день нет.
Вы все равно пытаетесь исключить человеческий фактор.
Исключить его невозможно, но можно неплохо снизить, путём выработки определённых процессов в команде и не добавляя головной боли тем членам команды, которые итак вполне самостоятельны.
Если команда работает слажено (без краткого пересказа Войны и мир на тему "как я провел вчерашний день"), то 15 минут утреннего звонка более чем достаточно озвучить блоки, проблемы и быстро определить и свести тех, кто может помочь в том или ином вопросе.
Ну, это ведь тоже человеческий фактор, к которому буквально всю команду принуждают.
Чаты тоже не все сидят читают. И почту тоже (тут тоже недавно много кто написал - "какой смысл читать почту? кому надо - и в личку напишут". Или начинается - не видел/не прочитал/не обратил внимание.
Это решается установленным в команде регламентом. Условно: нужно проверять чаты/почту не реже чем раз в 1 час (или 2). За соблюдением регламента может следить как вся команда, так и ответственный за неё. Да будут ситуации, когда кто-то прошляпил, но через некоторое время уже вырабатывается автоматизм в таких вопросах.
В чём проблема выработать у себя привычку проверять чаты раз в час или два?
Что касается вопроса: не все сидят читают чат постоянно, то, как я уже писал ранее:
Ничего страшного в этом не вижу, до момента X, когда станет ясно, что для решения вопроса нужны именно Вы, всё равно пройдёт меньше времени, чем до следующего дейлика.
Полчаса должно быть достаточно, чтобы выяснить кто именно нужен для решения проблемы и этого человека тегнут в чате, и только в этом случае, ему необходимо будет прочитать часть сообщений до, чтобы войти в контекст проблемы.
Другими словами, если для решения проблемы нужны именно Вы, а Вы в этот момент НЕ читаете чат, то остальная команда так или иначе призовёт Вас в чат, и произойдёт это, почти наверняка, раньше следующего дейлика.
Если у команды множество разных задач, не сильно связанных друг с другом - утренние звонки помогают оставаться в курсе событий. Ну а если вся команда работает над задачей "измени цвет кнопки" - тут конечно смысла собиратся каждый день нет.
Как насчёт ситуации, когда в команде есть участники, которые выполняют связанные с остальной командой задачи, но ситуативно. А в остальное время, у таких участников вообще нет необходимости погружаться в детали того, чем занимается остальная команда. Любители scrum во все поля требуют в такой ситуации обязательного присутствия таких участников на дейликах и все прочих мероприятиях связанных scrum.
Если разработчик чувствует, что увяз в коде, то почему он просто не может сообщить об этом сразу? Зачем для этого нужен ежедневный созвон?
Тут скорее вопрос в том, что порой ты можешь не понять, что завис
И придя на Дэйли ты скажешь «я продолжаю трудится над этой фичой»
В этот момент команда может спросить «а почему так долго?»
И ты уже расскажешь и в этот момент может кто нибудь помочь
—
Можно сказать, что за этим должен следить проджект, но в скрам командах считается, что его нет и команда сама следит за статусами
Потому что на самом деле по Scrum Guide там обсуждают impediments. А impediment это препятствие на пути к цели которое не может быть устранено только силами команды.
То что можно решить силами команды - отдано на откуп команде, в рамках автономии команды и конечно же решается сразу. Скрам ничем не противоречит здравому смыслу, это его вольные интерпретации огромным количеством Scrum Master - часто противоречат :-(
А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема.
Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд. Другое дело, что скрам имеет смысл только для слабых команд, которые еще не умеют в автономность и самостоятельность.
А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема.
Потому что daily это встреча для инспекции текущего состояния releasable increment и того что мешает полностью достичь цели.
Никто не сказал что их нельзя решить вне daily, но если они есть daily - это крайний момент для такого действия. Последний рубеж обороны для того чтобы увидеть наличие внешней зависимости (что исключительная ситуация для Scrum team, она ж по определению cross-functional, то есть обладает всеми знаниями и навыками для достижения цели).
Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд.
Скрам как раз для автономных команд. :-) Для слабых команд - предсказательный процесс, менеджмент и делегация исполнения, а не принятия решения. Собственно в статье такой и описан - набор мини-водопадов. То что поставка инкрементальна и итеративна - не делает ее Agile. У каждой коровы есть вымя, но то что имеет вымя - не обязательно корова :-)
ChatOps кстати прекрасный вариант работы, но тут надо учитывать что ChatOps из другой оперы, это уже не эмпирические процессы, это триаж по Cynefin, зона хаоса.
Вот зачем вы вводите народ в заблуждение?
Daily дословно нужен для инспекции того насколько УЖЕ достигнута цель спринта. Если вы к ней все еще идете то весь daily это “цель все еще никак не достигнута, вообще на ноль процентов, и у нас есть impediment - мы продолжаем делать водопад зачем-то обзывая его скрамом”.
То что вам написали выше - это как раз признак очень хороший того что там скрам с такими дейли и не пахнет. Людям которые действительно каждый день фиксируют приближение и есть что показать уже работающее - вот тем daily еще как интересен, они его сами организуют. А если там обсуждается как мы следуем планам и как мы ударно трудимся - то это именно то что выше и описали - бесполезная трата времени отвлекающая людей от чего-нибудь полезного и нужная только менеджерам и скрам-мастеру и только для того чтобы ощутить свою нужность :-)
Не совсем понимаю понимаю почему я сказал что то другое
Я описал пример, когда разработчик говорит о статусе своей задачи, который явно отображает статус выполнения цели
Статус задачи с точки зрения daily может быть одним из двух
Результат уже соответствует definition of done (готово)
Результат еще не соответствует definition of done (не готово)
Варианта готово на 50% тут нету, или да или нет.
Но на самом деле в скраме в принципе нету понятия задача и этому есть объяснение. Весь скрам-гайд начинается со слов “легковесный фреймворк для решения сложных задач в сложных окружениях”
Сложный (курим Cynefin, часть материалов по подготовке к PSM2) - это означает что нельзя оценить/понять/предсказать через разделение целого на части. А задача - это как раз инструмент декомпозиции - то есть анализа путем разделения целого на части!
Так а дальше все просто:
или у вас можно сделать план через декомпозицию, и можно инспектировать следование плану, а значит предсказывать достижение цели, но тогда у вас не сложная система, и вы скрам используете не там и не так как он задуман
или у вас сложная система или сложное окружение, и тогда вы сами себя обманываете проверяя следование плану, потому что ни понять целое через части, ни предсказать вы по определению не можете.
Тут весь секрет в самом начале SG, в понятии сложности ради которой Скрам, эмпирическом методе на котором основывается скрам, и трех колоннах.
Короче классическая проблема познания - три вопроса - зачем, что и как. Первые два сложные, третий простой, и большинство не парится первыми двумя и фокусируется на третьем, как в вашей статье
Если захотите реально узнать - есть прекрасная статья, из списка материалов по подготовке к PSM2/PSM3 Кристина Вервейса из Либераторов (Liberators) - “Что такое сложность и на фига вам на самом деле скрам”. Можно найти на их medium, или если проще на русском - я ее переводил для habr еще лет несколько назад.
Спасибо за замечание и за материалы!
Со своей стороны могу только добавить, что мой пример из комментария основан из практики разработки. И тут как раз вопрос в том, что SCRUM это только фундамент для работы, а дальше каждая компания адаптирует его под себя. Мне, видимо, повезло и я попадал в команды, в которых не вставал вопрос, что такое дэйлики и зачем они нужны. Мы синхронизировали работу и понимали на каком мы этапе и кому с чем можно помочь.
Но Ваши материалы почитаю, звучит интересно
Daily дословно нужен для инспекции того насколько УЖЕ достигнута цель спринта.
А можно узнать откуда вы взяли такое определение дэйли? В командах где я работал по скраму дейли вообще не использовали для подобной "инспекцит". Или вообще для отчётов о том что уже сделано.
Только для обсуждение актуальных проблем/блокеров.
В Scrum Guide однако
The purpose of Daily Scrum is to inspect progress toward Sprint Goal.
Обсуждение проблем/блокеров это скорее всего была реализация только третьей части рекомендованной структуры Daily которая была в SG до 2020 года, ну там где три вопроса:
Что уже сделано
Что еще надо сделать
Что у нас за преграды на пути к достижению цели
При разработке SG 2020 оставлять эти вопросы или нет было одним из самых горячих споров, и в итоге склонились к тому что большинство команд не правильно понимает вопросы про сделано/еще сделать подменяя их “чему уже делали” и “что еще будем делать” - то есть инспекция занятости, а не результатов, поскольку народ вольно интерпретировал термин done, хотя он четко определен - done это то что соответствует definition of done, а значит может быть частью releasable increment.
The purpose of Daily Scrum is to inspect progress toward Sprint Goal.
И там же дальше:
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
То есть фокус именно на том что ещё осталось сделать. Что уже сделано, а в особенности что сделано за последний день, в общем-то никого особо интересовать не должно. И грубо говоря если у вас нет проблем/блокеров и всё идёт по изначальному/последнему плану, то что вы хотите обсуждать?
И в таких случаях можно предложить им: «Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
На мой взгляд очень плохая идея. Потому что таким образом у вас дейли превратится в "отчёт перед начальством". Что полностью убивает идею дейли.
По хорошему во время спринта бизнес вообще не должен лезть в дела команы. Для бизнеса есть презентация/сдача задач в конце спринта.
Да, согласен, поэтому написал "если будут вопросы". Подразумевая, чтобы скрам мастер следил за тем, чтобы бизнес не "прописался" на дэйликах
На мой взгляд даже если у бизнеса есть вопросы, то им не место на дэйли.
Один из основных приколов скрама как раз и заключается в том что бизнес "отгораживается" от команды и не лезет в её дела. У бизнеса есть "интерфейс" в лице ПО. У него есть презентация в конце спринта. И на этом в общем-то всё.
И бизнес тоже должен научиться работать по правилам скрама. Иначе нет никакого смысла этот самый скрам вводить. Более того по моему мнению то, что бизнес не готов придерживаться правил, как раз таки и является самой частой причиной провала скрама.
Да, согласен, ты прав
Кстати нет, ПО отвечает за то что:
У команды есть бэклог
Бэклог состоит из PMI размером не более спринта и упорядочен по приносимой ценности
Работа берется только из бэклога
Причем он именно accountable - ему порвут жопу если этого нету, это ничего не говорит о том что разработчики не могут это делать. Более того - не в самом SG, но в материалах из вменяемых источников (рекомендованных например для подготовки к экзаменам или в книгах авторов скрама) - настоятельно рекомендуется их вовлекать.
Причина по которой бизнеса нет на daily - focus. Команда работает в сложной среде, то есть изучает сложную проблему через серию экспериментов, и вмешательство бизнеса в эксперимент - искажает результаты, то есть мы ни фига не узнаем, сложности не снижаем.
Так что причин у бизнеса лезть в дейли может быть две
Нет доверия команде через предыдущий успешный опыт или прозрачность того что происходит (смотрим обязанности Scrum Master, там прямо про отвечает за transparency) - потому что мы доверяем или тому что уже работало или там где понимаем что происходит.
Или цикл спринта слишком длинный выбран для текущей сложности системы, и цели/вводные данные меняются быстрее чем мы их инспектируем через цикл planning-review. И если даже неделя недостаточно коротко - то мы не зоне сложности, мы в хаосе.
А строится Scrum на предпосылке что у нас таки сложность, а не хаос - то есть время учиться у нас есть. Потому что если нету - то нам нужен не эмпирический метод, а триаж, с еще более коротким циклом, там уже часами исчисляется, как описано например в у Ким в “Настольной книге DevOps”
О ещё одна статья про скрам. Сколько их уже написано, но люди все ещё не дошли до идеи "заказчику/пользователю не нужны релизы, ему продукт целиком нужен" фичи сами по себе не имеют ценности, часть продукта не имеет ценности.
Вот вам нужна машина. Не ходовая, не корпус, не двигатель от машины, не "пока ногами двигаться надо", не "в следующем релизе будет гидроусилок и сиденье вместо табуретки". Машина нужна целиком, вся. Никакие промежуточные фазы никого не интересуют. Продукт должен поставляться готовый у целевому назначению.
Но если посмотреть с другой стороны, а как разрабатывалась машина? Она же появилась не сразу
В начале сделали Ford T. Отличный автомобиль. мотор заводится в ручную, кабина деревянная. Усилитель? Не, не нужен.
Начали продавать. Продали какое-то количество.
Дальше внедрили стартер, чтоб руками не заводить и таким образом открыли доступ женщинам водить.
Потом поставили усилители, чтобы улучшить комфорт.
Поэтому тут вопрос задачи. Если вы хотите сделать машину с усилителем, стартером и т.п., то вы делаете ее целиком. (Если смотреть по матрце стэйси, то это можно отнести к простой системе)
Но вот если ваша задача выйти с новым, инновационным продуктом, то без проб и ошибок не сделать хороший продукт.
Продолжая пример с автомобилями. Вот Wolkswagen вложил несколько миллиардов в электромобили. Зачем? Чтобы разработать платформу, проработать эргономику и т.п. Прошло немного времени и оказалось, что все же электромобили не факт, что будущее. И вот вопрос: а можно ли сделать прототип, без платформы и проверить, а нужно ли вообще это делать. А только после этого тратить миллиард на платформу?! И вот тут Agile помог бы потратить меньше денег, чтобы в начале проверить, а потом уже вкладываться в понятный маршрут
Статья не про скрам, а про то как большинство (не)понимают скрама поскольку первую, самую важную часть пропускают и фокусируются как при помощи прикольных новых названий построить старый добрый процесс как привыкли.
Да и читают скрам-гайд явно не глазами. Для начала в скраме нет ничего про релизы, есть про releasable increment. Релиз это всегда решение заказчика, а дело команды каждый раз отдавать заказчику то что технически пригодно к постановке на прод, если заказчик решит что функционала уже достаточно.
А вот ситуация в которой 20 процентов функционала уже можно запускать, потому что 80 процентов потребностей уже покрыто и на системе можно зарабатывать уже сейчас - ничем не противоречит ни опыту, ни здравому смыслу, ни потребностям заказчика.
Так вот колесо вполне себе должно быть и на самом деле на производстве является releasable increment - его можно взять и использовать прямо сейчас, а не ждать пока вся машина не будет собрана чтобы проверить что колесо тоже ничего. :-) Да и любая нормальная команда по хорошему отлаживает каждый кусок продукт до prod grade не дожидаясь финального тестирования, чтобы сделать и уже не возвращаться. А кто этого не делает, тому увы и скрам не помогает.
Да, я с вами согласен на счет релизов.
Но в статье я нигде не писал про релиз. Наоборот я подчеркнул, что инкремент - не значит релиз
Если говорить о статье - то в принципе я уже сказал - у вас прекрасно исполненное описание ответа на вопрос как в отрыве от что и зачем.
В отрыве настолько что некоторые вещи оказываются собственной противоположностью тому что они есть в SG, а какие-то оставляют такой простор для интерпретации что прям ой.
Проведите мысленный эксперимент - задайте себе вопрос чем описанная вами система отличается от итеративной и инкрементальной поставки, которые существовали задолго до появления Scrum, например в Rational Unified Process. А отличие есть, не стоило бы трудов придумывать новые названия для того же, не те люди придумывали Scrum чтобы перелицевать старое знакомое просто лишь бы было свое.
А это отличие - в том что RUP это предсказательный метод, основанный на декомпозиции и плане, пусть и реализуемом итеративно и с инкрементальной поставкой. А Scrum - это цепочка экспериментов по снижению сложности, которая не дает возможности сделать декомпозицию и написать требования и план.
Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один раз
Важно помнить, что Increment - не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз
Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один раз
Важно помнить, что Increment - не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз
Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
В больших проектах скрам скорее мешает, чем помогает. У себя в команде мы реализовали очень важное улучшение по скраму - уволили скрам-мастера и отменили ретро (но таки иногда собираемся по необходимости с пивом). И работа стала намного эффективнее.
на самом деле у меня есть ровно зеркальный пример. Мы внедрили скрам и смогли в 3 раза сократить lead time)
Но в любом случае, фрэимворк - решение команды. Если он ей мешает, то он ей не нужен
Скрам фреймворк для решения сложных проблем в сложных окружениях. Это цитата из самого начала. При отсутствии сложности (причем в строгом научном понимании - когда проблему нельзя решить путем разделения ее на меньшие, то есть через декомпозицию) - скрам действительно на фиг не нужен, есть другие, более эффективные способы работы.
Если ваш скрам мастер был не знаком с cynefin подходом от IBM и пихал скрам не потому что он реально нужен, а потому что можно - то все правильно сделали :-)
Хотя забавно - ретро как раз мало имеет отношения к сложности, это кусок пришедший туда из Lean и пути постоянного улучшения (Gemba Kaizen). Возможно для проекта ваш процесс и был идеальным и улучшать его - растрачивать деньги, но инженерия без развития - это медленная смерть, так что предположу что на самом деле вы просто делаете continuous improvement просто другим способом.
Благодарю за подробный разбор, и инфографика очень информативная
Какая нелепая утопия! Это случайно не марксисты изобрели? Где вы найдёте 10 абсолютно взаимозаменяемых неамбициозных людей с одинаковым уровнем навыков и подавленным базовым инстинктом собственности? Да ещё с разными зарплатами внутри команды. Кто определяет что инкремент не окажется декрементом со стратегический точки зрения? Откуда в скраме такая непоколебимая уверенность в приближении к светлому будущему на каждом небольшом этапе при отсутствии чёткого представления о конечной функциональности продукта на начальных этапах?
Agile наоборот говорит о том, что нужны амбиции. Потому что если в обычных компаниях все за разработчика решают менеджеры, то в Agile разработчик является ключевым человеком. (Но да, я часто приходил в компании и слышал «а мне удобно, задачу дали, а я работаю. А как там планируют, это их проблемы»
Ценность инкремета определяется на Sprint Review Product Owner и стэйкхолдерами, что указано в статье
В скрам не сказано, что не нужна цель. Просто ее нужно всегда проверять. Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь
Никогда не думал, что программисты отупеют настолько, что, с одной стороны, нужна будет специальная методика для пинания их под зад, а с другой стороны они сами согласятся на это. Мда.
О, спасибо огромное за статью.
Не то, чтоб я прочел что-то новое, но хорошо структурированного с вашими добавками материала достаточно, чтоб натолкнуть на кое-какие мысли.
Так вот:
У меня складывается ощущение, что бизнес не понимает одной хитрой вещи: далеко не всегда то, что делается - поиск нового".
Часто бизнес не готов комититься и не согласен на сроки: "нет, нет, нет, нет - мы хотим сегодня! Нет, нет, нет, нет - мы хотим сейчас!"
Понятно, что в идеальном мире задача ПО и СМ отгородить команду, но, возможно, не следует слепо внедрять методологии вообще на всем ландшафте?
Вот - эксплуатация. Какое количество там нового? Зачем там скрум или эджайд?
Вот - поставка (внедряем клиенту) - ну.. ок, можно сказать что тут есть элементы, которые можно натянуть.
Все эти методы, увы, они действительно не решают вопросы сложность vs хаос. Считается, что хаос как-то рассосётся сам. Но, увы, он не рассасывается.
Есть идеи?
На самом деле Вы правы. Поэтому команды часто делят на "продуктовые" и "сервисные".
В "продуктовых" часто есть смысл в Scrum и Agile, просто потому что это либо разработка нового, либо задает темп разработки
А вот в "сервисных" (то что ты говорил экслуатация и поставка) лучше использовать канбан. Сделать доску, поставить WIP лимиты и просто наглядно смотреть за тем, как идут задачи.
И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
Доска - это все таки про канбан. И на самом деле в разработке to do, in progress, done мало, по крайней мере по моей практике
На счет эффективности и как она считается. Приведу картинку из SAFe, в которой они как раз пытаются объяснить в чем плюс гибкой методологии
Т.е. при обычной (справа) waterfall модели, ты будешь разрабатывать долго и не факт, что это то, что нужно пользователю (plan)
А вот за счет Agile и постоянных проверок, ты сможешь не отходить сильно от того, что нужно пользователю и за счет этого быть эффективнее.
Я писал пример в статье на эту тему, что за счет иттераций и взаимодействий с PO мы смогли сократить время разработки за счет того, что не стали делать лишние вещи, а быстро проверили гипотезу
Поэтому обычно, когда говорят о повышении скорости, то смотрят через эту призму.
--
А ретро, как сказали выше, есть не только в Scrum. И оно просто позволяет учится на своих ошибках, а не закапывать их в стол, как часто происходит в разработке
"Доска - это про канбан" это не так. Доска лишь отражение процессов принятых в команде, а не отдельный инструмент который живет своей жизнь. Тут по скраму, а тут по канбану. Конечно мало 3 поля, ведь команда и ее процессы не перестроены под скрам. Да и не скрам это, про то и говорю.
В плане эффективности тут график показывает, что релизиться чаще, получать чаще фидбек от юзеров и пересматривать бэклог по результатам фидбека полезнее чем релизиться долго. Это решается путем декомпозиции и девопс процессов, которые позволяют релизиться часто. Скрам тут вообще не нужен для этого.
Эффективность в скраме как раз достигается за счет взаимодействия команды. Для интереса вбей в ютуб что такое скрам в регби и посмотри как это выглядит. Ведь фреймворк назвали как раз в честь этого элемента игры. Вы либо толпой перебороли соперника (решили задачу), либо нет. Поэтому таска или не делается, или в процессе, или уже готова. Нет состояния, что один толкает, а другие потолкают попозже.
Не совсем понятно взаимодействие группы внутри этапа разработки. Если все вместе отвечают за один продукт, но при этом есть специалисты в одной области и в другой. Все друг от друга зависят и у всех разная скорость решения задач. Один не успел свою часть сделать, а другие не могут продолжить из-за него. Что в таком случае делать?
По Scrum все же считается, что каждый член команды может быть взаимозаменяем.
На практике такое бывает редко, поэтому лучше всего на уровне планирования предусмотреть риски и подумать как их можно избежать
В любом случае стоит на ретро обсудить причины, почему не успел сделать и как в будущем можно не допустить таких ошибок
Если каждый член команды делает все, то как рассчитывать тогда зарплату? Фактически в этой схеме получается, что один может перерабатывать, а другой наоборот отбрасывать все сложные задачи и выполнять только легкие не напрягаясь. Внутри группы возникает неравенство. Не бывает так, чтоб все люди выполняли все функции одинаково и хорошо.
Стране нужны герои, ***да рожает скрам-мастеров...
Разбираемся в Scrum: Руководство с картинками и примерами