Scrum, один из наиболее популярных фреймворков для управления проектами, часто вызывает множество вопросов и разногласий по поводу своего применения. В процессе своей работы я неоднократно сталкивался с тем, что разные люди по-разному понимают и интерпретируют Scrum. Это побудило меня создать статью, которая поможет быстрее разобраться в его основах и особенностях.
В данной статье я постарался изложить основные принципы Scrum, опираясь на Scrum Guide, и дополнить их своими личными наблюдениями и опытом. Я включил множество иллюстраций и примеров из практики, чтобы сделать материал более понятным и полезным. Надеюсь, что эта статья станет ценным ресурсом для тех, кто хочет глубже понять и эффективно использовать Scrum в своей работе.
Определение Scrum
Scrum — это гибкий фреймворк, который помогает людям, командам и организациям достигать успеха в решении сложных задач за счет адаптивного способа решения за.
В формате “цитат” я буду во время статьи делить своим мнением.
Важно выделить, что Scrum — это не свод правил, по которому вы должны работать, это только фреймворк, который описывает принципы, как может работать команда в случаях, когда ей нужно всегда проверять, делает она то, что нужно, или нет.
“Фреймворк описывает начальную заготовку и свод инструкций, которые упрощают достижение конечной цели: каркас корабля и фундамент дома достроить проще, чем собирать с нуля.” (данное описание взято с сайта Яндекс Практикума)
Также важно отметить, что при внедрении Scrum в компанию не рекомендуется менять названия мероприятий и инструментов. Дело в том, что это может сбить с толку ваших коллег и затруднить процесс их адаптации. Преимущества Scrum заключаются в том, что существует Scrum Guide, который позволяет быстро и эффективно погрузить сотрудников в процессы. Благодаря этому вам не придётся тратить время на создание собственной документации.
Ниже вы увидите изображение, которое часто встречается при работе со Scrum:
На них описаны все основные мероприятия, которые позволяет создать гибкую среду, в которой:
Product Owner упорядочивает работу по решению комплексной проблемы в Product Backlog.
Scrum Team в ходе Sprint превращает выбранную работу в Increment, несущий ценность.
Scrum Team и заинтересованные лица инспектируют результаты и вносят правки для следующего Sprint.
Повторяет.
Ценности Scrum
Ценности Scrum лучше всего иллюстрирует изображение, представленное ниже:
Scrum команда
Основная единица Scrum — небольшая команда людей (до 10 человек).
Scrum команда состоит из:
одного Scrum Master,
одного Product Owner,
Developers.
Внутри Scrum Team нет подкоманд и иерархий. Это сплоченное объединение профессионалов, в любой момент времени сфокусированных на одной цели.
Scrum команды являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint. Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
Scrum Team достаточно маленькая, чтобы оставаться проворной, и достаточно большая, чтобы выполнять значительную работу в течение Sprint — состоит не более чем из 10 человек.
Если Scrum Teams становятся слишком большими, участникам следует рассмотреть возможность реорганизации в несколько сплоченных Scrum Teams, каждая из которых сфокусирована на одном и том же продукте. Следовательно, у них должна быть та же Product Goal, тот же Product Backlog, тот же Product Owner.
Вся Scrum команда несет ответственность за создание ценного, полезного Increment в каждом Sprint.
Важно помнить, что Increment - не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Developers
Developers — это люди в Scrum команде, которые причастны к созданию любого аспекта готового к использованию Increment в каждом Sprint.
Product Owner
Product Owner несет ответственность за максимизацию ценности продукта, получаемого в результате работы Scrum Team.
Scrum Master
Scrum Master несет ответственность за применение Scrum в соответствии с Руководством по Scrum. Они делают это, помогая всем понять теорию и практики Scrum, как внутри Scrum Team, так и в организации.
Важно понимать, что scrum-мастер – это не просто менеджер, который указывает, как нужно работать. Это человек, который обучает команду и помогает ей работать по методологии scrum, устраняя все препятствия на пути. На самом деле, он даже не должен участвовать в мероприятиях. Например, он не обязан ходить на Daily. Его задача только научить команду укладываться в 15 минут, а затем команда может работать самостоятельно.
Ответственности ролей
Для удобства можно свести обязанности всех ролей в одну таблицу:
Developers |
Product Owner |
Scrum Master для команды |
Scrum Master для Product Owner |
Scrum Master для организаци |
|---|---|---|---|---|
создание плана на Sprint — Sprint Backlog; |
разрабатывает и точно коммуницирует Product Goal; |
коучит участников команды в части самоуправления и кросс-функциональности; |
помогает находить техники эффективного определения Product Goal и управления Product |
|
Backlog; |
направляет, обучает и коучит организацию в применении Scrum; |
|||
стремление к качеству посредством соблюдения DoD (definition of done); |
создает и четко объясняет элементы Product Backlog; |
помогает Scrum Team фокусироваться на создании Increments с высокой ценностью, |
||
соответствующих DoD; |
помогает Scrum Team осознать необходимость четких и лаконичных элементов Product |
|||
Backlog; |
планирует переход на Scrum и консультирует по вопросам применения Scrum в рамках |
|||
организации; |
||||
ежедневную адаптацию своего плана для достижения Sprint Goal (Daily); |
упорядочивает элементы Product Backlog; |
способствует устранению препятствий, мешающих прогрессу Scrum Team; |
помогает применять эмпирическое планирование продукта в комплексной среде; |
помогает сотрудникам и заинтересованным лицам понять и применять эмпирический |
подход к комплексной работе; а также, |
||||
взаимную подотчетность друг перед другом как профессионалами. |
обеспечивает прозрачность, доступность и понимание Product Backlog. |
убеждается в том, что все события Scrum происходят, позитивны, продуктивны и не |
||
выходят за рамки ограничений по времени. |
фасилитирует взаимодействие с заинтересованными лицами по запросу или при |
|||
необходимости. |
устраняет барьеры между заинтересованными лицами и Scrum Teams. |
Кратко данную таблицу можно представить с помощью такого рисунка:
События Scrum
Sprint — это контейнер для всех остальных событий.
Каждое событие в Scrum специально спроектированы для обеспечения необходимой прозрачности.
Неспособность проводить какое либо из событий Scrum в соответствии с описанием приводит к потере возможностей для инспекции и адаптации.
Sprint
Sprints — это пульс Scrum, где идеи превращаются в ценность.
Цель: |
Вся работа, необходимая для достижения Product Goal, включая события Sprint Planning, Daily Scrum, Sprint Review и Sprint Retrospective, выполняется в рамках Sprints. |
|---|---|
Участники: |
Developers, Product Owner, Scrum Master |
Timebox |
|
(время проведения) |
до 1 месяца |
В ходе мероприятия: |
• не вносятся изменения, которые могут поставить под угрозу Sprint Goal; |
• не снижается качество; |
|
• Product Backlog уточняется по мере необходимости; а также, |
|
• по мере появления новых знаний содержание работы может быть уточнено и |
|
пересмотрено с Product Owner. |
|
Ограничения: |
Sprint может быть отменен, если Sprint Goal потеряла актуальность. Только Product Owner имеет право отменить Sprint |
Результат: |
Готовый инкремент (не обязательно релиз) |
Sprint Planning
Sprint Planning инициирует Sprint, планируя работу, которую необходимо выполнить в этом Sprint.
Цель: |
Постановка Spring Goal и планирование Spring Backlog, который команда должна будет сделать для реализации инкремента |
|---|---|
Участники: |
Developers, Product Owner |
Timebox (время проведения) |
до 8 часов (при спринте 1 месяц) |
В ходе мероприятия: |
Участники должны ответить на основные вопросы: |
• почему этот Sprint ценен? |
|
• что может быть готово в этом Sprint? |
|
• как будет выполняться выбранная работа? |
|
Результат: |
Spring Goal |
Spring Backlog |
Мне кажется, что это одно из самых обсуждаемых мероприятий в Scrum, потому что многие разработчики не понимаю зачем оно нужно и считают, что порой нельзя оценить задачу, ведь в ней могут быть много неизвестных.
Мне на практике для планирования помогло несколько вещей:
1. Лучше оценивать задачи относительно других задач. Я в своей практике выбираю выполненные задачи, у которых известно время выполнения, и предлагаю сравнивать относительно них. Это позволяет чуть точнее оценить задачу. (Важное замечание: это работает при условии, если задача полностью понятна)
2. Внедрите DoR и не берите задачи в разработку, которые не проработаны до конца
3. Если все таки нужно брать задачу, в которой много неизвестных, то создайте задачу для исследования. Сделайте прототип. Покажите его Product Owner и стэйкхолдерам и затем если все понятно переходите на полноценную разработку функционала. (Это также сочетается со вторым пунктом, так как прототипы можно считать DoR для разработки)
Пример из практики
Однажды нам потребовалось создать функционал, который позволил бы пользователям фильтровать результаты запросов по определённым правилам. Первое, что пришло нам в голову, — это создать текстовый запрос, похожий на SQL или JQL. Для этого нам нужно было бы подключить Antler, чтобы работать со сложными вложенностями в запросе (скобочки и т.п.) Однако мы никогда раньше не работали с этим инструментом, и он выглядел довольно сложно. Поэтому мы решили создать небольшой прототип с базовыми функциями без сложных структур. Мы показали его Product Owner.
Он посмотрел и сказал: «Но пользователи же не будут всё это писать вручную. Давайте сделаем визуальный конструктор запросов». За следующий спринт мы создали несколько макетов и продемонстрировали их. Product Owner внёс небольшие комментарии, но в целом его всё устроило. Затем мы реализовали прототип за спринт, показали его, и Product Owner окончательно одобрил функционал.
После выпуска версии заказчику он тоже оценил, что такой вариант удобен. В итоге мы не потратили много времени на внедрение Antler и, благодаря итерациям, смогли понять, что именно нужно заказчику. Можно сказать, что Product Owner не прописал задачу правильно, но нужно понимать, что он тоже человек и не всегда может предугадать все варианты реализации.
Daily Scrum
Daily Scrum — это 15-минутное событие, которое позволяет команде каждый день проверять прогресс выполнения Sping Backlog.
Цель: |
Инспекция прогресса в достижении Sprint Goal, адаптация Sprint Backlog по мере необходимости, корректировка запланированной предстоящей работы. |
|---|---|
Участники: |
Developers |
Timebox (время проведения) |
до 15 минут |
В ходе мероприятия: |
Developers определяют прогресс выполнения Sping Backlog |
Результат: |
Spring GoalSpring Backlog |
Небольшое замечание: стоит обратить внимание, что в этом событии не обязательно должен участвовать Scrum Master. На данном мероприятии его задача — научить команду проводить самостоятельно и укладываться в отведенное время.
Многие разработчики считаю, что данное мероприятие не нужно и просто отнимает время. Но не забывайте, что в во время Sprint вся команда отвечает за Increment, а не один человек. Поэтому Daily и должны позволять команде понять статусы по задачам и определить нужна ли кому-то помощь в реализации.
Sprint Review
Цель: |
Инспекция результата Sprint и выявление возможностей для адаптации.Scrum Team представляет результаты своей работы ключевым заинтересованным лицам, иобсуждает прогресс в достижении Product Goal. |
|---|---|
Участники: |
Developers, Product Owner, заинтересованные люди (stakeholders) |
Timebox (время проведения) |
до 4 часов (при спринте 1 месяц) |
В ходе мероприятия: |
Во время события Scrum Team и заинтересованные лица анализируют, что было достигнуто в ходеSprint, и что изменилось в их окружении. |
Результат: |
На основе проанализированной информации участники совместно решают, что делать дальше. Product Backlog также может быть скорректирован с учетом новых возможностей. |
В Scrum Guid отдельно отмечено, что Sprint Review - это не просто демонстрация инкремента. Это в первую очередь обсуждения чего добилась команда и куда нужно идти дальше.
Sprint Retrospective
Цель: |
Запланировать повышение качества и эффективности |
|---|---|
Участники: |
Developers, Product Owner, Scrum Master |
Timebox (время проведения) |
до 3 часов (при спринте 1 месяц) |
В ходе мероприятия: |
Участники Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами они |
столкнулись, и как эти проблемы были (или не были) решены. |
|
Результат: |
Предположения, которые сбили Scrum Team с пути, и исследуется их происхождение. |
Ретроспектива является последним мероприятием в спринте и обозначает его завершение.
Интересно, что ретро - это то, что не делают чаще всего в компаниях.
Возможно, это и хорошо, так как не тратится время разработчиков. Но.. ретро - в первую очередь инструмент обучения, который позволяет команде понять, что пошло не так во время спринта и что можно улучшить в следующем.
Для того, чтобы команда полюбила использовать данный инструмент важно, чтобы было видно что изменилось после него.
На своей практике мы за 4 месяца устранили больше 20 проблем и уменьшили LeadTime на 30% за счет проведения ретро внутри команды.
Артефакты Scrum
Артефакты Scrum иллюстрируют работу или ценность. Они созданы так, чтобы максимально чётко отражать важную информацию. Это позволяет всем, кто с ними знакомится, иметь общее представление о ситуации и действовать на его основе.
Для каждого артефакта есть определенная цель, для которой он реализуется. Это позволяет понять в какую сторону идет разработка и достигнута ли ее цел.
Связи артефактов и целей представлены в таблице:
Артефакт |
Цель |
|---|---|
Product Backlog |
Product Goal |
Spring Backlog |
Spring Goal |
Increment |
DoD (определение готовности) |
Product Backlog
Product Backlog — это список задач, которые необходимо выполнить для улучшения продукта. Он упорядочен и постоянно обновляется. Этот список — единственный источник работы для Scrum Team.
Также должен постоянно проводится процесс Gruming Backlog (актуализации бэклога), когда задачи в бэклоге продукта должны описывать подробнее, декомпозироваться до уровня спринта, а лишние задачи удаляться.
Ответственность за Product Backlog лежит на Product Owner. Он отвечает за наполнение и приоритезацию задач.
Product Goal
Product Goal — это долгосрочный ожидаемый результат Scrum Team. Они должны достичь одной цели (или отказаться от нее), прежде чем приступить к следующей.
Product Goal входит в состав Product Backlog. Остальная часть бэклога продукта появляется, чтобы определить, «что» будет способствовать достижению Product Goal.
Sprint Backlog
Sprint Backlog — это план, который команда разработчиков создаёт для себя. Он представляет собой понятное и актуальное описание работы, которую команда планирует выполнить в течение спринта для достижения цели спринта. Поэтому в течение спринта Sprint Backlog обновляется по мере получения новой информации. В нём должно быть достаточно подробностей, чтобы команда могла отслеживать свой прогресс во время ежедневных собраний (Daily Scrum).
Sprint Backlog состоит из:
Sprint Goal - почему нужен данный инкремент,
набора выбранных на Sprint элементов Product Backlog - что нужно сделать для реализации инкремента
осуществимого плана действий по поставке Increment - как реализовать инкремент.
Sprint Goal
Sprint Goal — это единственная цель на спринт. Хотя разработчики и стремятся достичь этой цели, она также даёт им гибкость в выборе конкретных задач, необходимых для её выполнения. Sprint Goal помогает сохранять связность и фокусировку, побуждая команду Scrum работать вместе, а не над отдельными инициативами.
Sprint Goal создаётся во время планирования спринта и затем добавляется в список задач на спринт (Sprint Backlog). Разработчики помнят о Sprint Goal, работая над задачами спринта.
Отдельно отмечу абзац из манифеста: ” Если работа не соответствует ожиданиям, они (developers) взаимодействуют с Product Owner, чтобы пересмотреть содержание Sprint Backlog в рамках Sprint, не изменяя Sprint Goal.”
Increment
Increment — это конкретная ступенька к достижению Product Goal.
Каждый инкремент дополняет все предыдущие. Они проходят тщательную проверку, чтобы гарантировать, что все инкременты будут работать вместе. Чтобы быть ценным, инкремент должен быть полезным и пригодным для использования.
В течение одного спринта можно создать несколько инкрементов.
Итоговые инкременты демонстрируются на Sprint Review, что способствует развитию эмпирического подхода.
Отдельно выделю абзац, который мне показался интересным: ”Однако инкремент может быть предоставлен заинтересованным сторонам ещё до завершения спринта. Важно понимать, что Sprint Review не является единственным моментом для предоставления ценности.”
DoD (Определение готовности)
DoD (Определение готовности) — это формальное описание состояния Increment, при котором он соответствует требованиям качества, предъявляемым продукту.
Определение готовности обеспечивает прозрачность, предоставляя всем единое общее понимание того, какая работа была выполнена в рамках Increment.
Если элемент Product Backlog не соответствует определению готовности, его нельзя выпускать или даже показывать на Sprint Review. Вместо этого он возвращается в Product Backlog для дальнейшего рассмотрения.
Если определение готовности для Increment является частью единых стандартов организации, все Scrum Teams должны использовать его в качестве необходимого минимума. Если оно не определено стандартами организации, то Scrum Team должна создать определение готовности, подходящее поставляемому продукту.
Разработчики должны строго придерживаться определения готовности. Если несколько команд Scrum работают над общим продуктом, они должны совместно создать и соблюдать одно и то же определение готовности.
Заключение
Изучение и внедрение Scrum может показаться сложным на первых порах из-за множества нюансов и разнообразных интерпретаций. Однако, опираясь на фундаментальные принципы Scrum Guide и постоянно обучаясь можно значительно улучшить этот процесс.
В данной статье я постарался объединить теоретические аспекты с практическими иллюстрациями, чтобы сделать понимание Scrum более доступным.
Надеюсь, что предоставленная информация поможет вам глубже разобраться в сути этого фреймворка и успешно применить его в своих проектах. Помните, что ключ к эффективному использованию Scrum – это не только знание теории, но и постоянное стремление к улучшению и адаптации под конкретные условия вашей команды и проекта.
Комментарии (51)
dmproger
28.06.2024 12:03обязательные регулярные дейли-созвоны в одно и то же время (по утрам как правило) - это по факту основная и самая прoтивнaя особенность скрама.. абсолютно бессмысленное действо, сколько бы ни рисуй табличек и не описывай пользы.
все созвоны командой - должны быть или по необходимости, или по точкам необходимой синхронизации. и один день - ну очевидно, абсолютно никак не может рассинхронизовать людей, делающих свое дело. это полный бpeд. интервал общей синхронизации должен быть соизмерим с некорректным путем работ, который в самом неверном раскладе самого непонимающего участника команды может случайно образоваться. и это точно не один рабочий день, когда у всех есть мозги.
а необходимость в этом только у проджект-менеджеров, чтоб ощущать свою ежедневную "работу". и для суетливых тимлидов.
не человек для методологии, но методология для человека. если бы эти дейлики были бы просто по желанию кофе-брейк да по общаться и возможно что-то сообщить при желании (хотя чаты для этого есть всегда) - вопросов бы не было.
PS. про то что, некоторым нужно утром подольше поспать, чтоб быть продуктивными и что такая "гибкая" методология не дает нормально это сделать - молчу.
art241111 Автор
28.06.2024 12:03Спасибо за комментарий!
Если смотреть по Scrum Guid, то там говорится, что Daily нужны только разработчикам для того, чтобы понимать как идете к цели спринта. Может кто-то встал в тупик и на дэйлике об этом скажет и кто-то сможет помочь.
Меня он на самом деле много раз выручал. Всегда в голову приходит случай, когда увидел, что функционал не корректно работает. Хотел его поправить и сказал об этом на дэйли. Оказалось, что другой разработчик делает связанный функционал и поправит этот баг во время ее решения. И за счет этого я не потратил время на решения данного функционала.
Ещё один плюс регулярных встреч (хотя это и не совсем соответствует принципам Scrum, но всё же) заключается в том, что в небольшой компании бизнес может часто запрашивать сроки и статусы. И в таких случаях можно предложить им: «Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
doctorw
28.06.2024 12:03Может кто-то встал в тупик
Имхо, нужно просто зафиксировать в команде, что если ты как разработчик понимаешь, что встал в тупик, то напиши в чат команды. Может ответят и не сразу, но наверняка раньше следующего дейлика.
Оказалось, что другой разработчик делает связанный функционал
Исходно неправильное распределение задач по команде? Здесь также работает принцип, наткнулся на что-то – отпиши в чат команды, когда у других будет возможность посмотреть, они ответят. Результатом будет либо "кто-то другой уже решает эту проблему" либо новая задача в план либо другой набор инструкций что делать с этим.
Нужно по максимуму использовать возможности асинхронного общения.
Ещё один плюс регулярных встреч (хотя это и не совсем соответствует принципам Scrum, но всё же) заключается в том, что в небольшой компании бизнес может часто запрашивать сроки и статусы.
Для отслеживания статуса задач существуют таск-трекеры а-ля JIRA, с широким набором возможностей. Вместо того, чтобы заставлять всех подстраиваться под ежедневный созвон/встречу, где примерно 80% коммуникаций бесполезна с точки зрения бизнеса (имхо), стоит делать упор на то, чтобы команда своевременно обновляла статусы по задачам и давала обратную связь, особенно если возникают непредвиденные сложности.
P.S.
«Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
Так всё равно не бывает практически никогда, потому что появляются какие-то срочные вопросы, когда дейлик этого дня уже давно позади, а до следующего вопрос не терпит.
zuekliza
28.06.2024 12:03+1Когда в команде 2 - 3 человека и на ту же неделю 2 - 3 крупных задачи на всех - можно и чатом обойтись. Когда 7 - 10 человек - уже сложнее. Во-первых - не все читают и вчитываются. Срабатывает фактор - ой, там уже вроде ответили и какой-то диалог идёт, значит уже решают вопрос. Во-вторых - если ты занят, много других более срочных вопросов, погружен в работу, ты не будешь сидеть и перечитывать чат, если там +100500 сообщений за полчаса. Плюс когда на неделю не 2-3 крупных задачи - тут да, смысла нет дёргать каждый день с вопросами, что в работе и как там. А когда они мелкие и их штук 15?
А-ля Jira - давайте будем честны - не все сразу же фиксируют там инфу о наличии блокера, в первую очередь сидят и тратят ещё какое-то время на выяснение причин и попытки решить проблему.
Вобщем, на мой взгляд, вы отметаете человеческий фактор.
Я тот человек, который каждый день проводит те самые, ненавистные вам утренние звонки)) Если вопросов, замечаний, комментариев нет - то звонок заканчивается быстро.
А чаты.. Конечно удобно для истории, и что беседа может быть рамазана во времени, но у меня в моменте может быть по 10 чатов, где идёт активные беседы и сотни сообщений. Опять же, ввиду специфики работы, я сижу и или в конце дня все перечитываю, или утром (что бы быть в курсе.
Опять же, на практике моей команды - мы многие вопросы решаем (или находим путь решения) именно через ежедневные звонки.
PAL_habr
28.06.2024 12:03Вообще странно говорить о том, что если вопрос задан в чате, то на него не смотрят и не отвечают, а если то же самое задано при встречи 10 человек, то все бросятся на него отвечать, а те кому это вообще не нужно будут внимательно внимать ответу, переваривать ненужную информацию или вежливо сидеть в стороне.
Конечно, если в рабочем чате рассказывать про погоду, поход в кино и обсуждение книг, то наверное там будет "100500" сообщений которые занятой разработчик не будет читать (вместе с теми, что "по делу").
Чисто моё видение вопроса.
Kanut
28.06.2024 12:03Вопрос заданный в чате может быть проигнорировае отдельными людьми. Просто потому что они долгое время чем-то заняты и не читают чат.
Или надо всех обязать регулярно его читать?
doctorw
28.06.2024 12:03А-ля Jira - давайте будем честны - не все сразу же фиксируют там инфу о наличии блокера, в первую очередь сидят и тратят ещё какое-то время на выяснение причин и попытки решить проблему.
Вот как раз за соблюдением этого должно следить ответственное за команду лицо и напоминать о необходимости соблюдения регламента, пока это не дойдёт до автоматизма.
Срабатывает фактор - ой, там уже вроде ответили и какой-то диалог идёт, значит уже решают вопрос.
Ничего страшного в этом не вижу, до момента X, когда станет ясно, что для решения вопроса нужны именно Вы, всё равно пройдёт меньше времени, чем до следующего дейлика.
Во-вторых - если ты занят, много других более срочных вопросов, погружен в работу, ты не будешь сидеть и перечитывать чат, если там +100500 сообщений за полчаса.
В этом и прелесть асинхронного общения, нет необходимости всегда перечитывать всё. Полчаса должно быть достаточно, чтобы выяснить кто именно нужен для решения проблемы и этого человека тегнут в чате, и только в этом случае, ему необходимо будет прочитать часть сообщений до, чтобы войти в контекст проблемы.
Я тот человек, который каждый день проводит те самые, ненавистные вам утренние звонки)) Если вопросов, замечаний, комментариев нет - то звонок заканчивается быстро.
Я тоже человек, который каждый день тратит время на такие звонки, и хорошо, если звонок укладывается в 20-25 минут.
segment
28.06.2024 12:03+1Если разработчик чувствует, что увяз в коде, то почему он просто не может сообщить об этом сразу? Зачем для этого нужен ежедневный созвон?
art241111 Автор
28.06.2024 12:03+1Тут скорее вопрос в том, что порой ты можешь не понять, что завис
И придя на Дэйли ты скажешь «я продолжаю трудится над этой фичой»
В этот момент команда может спросить «а почему так долго?»
И ты уже расскажешь и в этот момент может кто нибудь помочь
—
Можно сказать, что за этим должен следить проджект, но в скрам командах считается, что его нет и команда сама следит за статусами
doctorw
28.06.2024 12:03По опыту могу сказать, что когда в команде начинают спрашивать "а почему так долго" это уже очень поздно и куча времени потрачена зря.
ngekht
28.06.2024 12:03Потому что на самом деле по Scrum Guide там обсуждают impediments. А impediment это препятствие на пути к цели которое не может быть устранено только силами команды.
То что можно решить силами команды - отдано на откуп команде, в рамках автономии команды и конечно же решается сразу. Скрам ничем не противоречит здравому смыслу, это его вольные интерпретации огромным количеством Scrum Master - часто противоречат :-(
ngekht
28.06.2024 12:03+2Вот зачем вы вводите народ в заблуждение?
Daily дословно нужен для инспекции того насколько УЖЕ достигнута цель спринта. Если вы к ней все еще идете то весь daily это “цель все еще никак не достигнута, вообще на ноль процентов, и у нас есть impediment - мы продолжаем делать водопад зачем-то обзывая его скрамом”.
То что вам написали выше - это как раз признак очень хороший того что там скрам с такими дейли и не пахнет. Людям которые действительно каждый день фиксируют приближение и есть что показать уже работающее - вот тем daily еще как интересен, они его сами организуют. А если там обсуждается как мы следуем планам и как мы ударно трудимся - то это именно то что выше и описали - бесполезная трата времени отвлекающая людей от чего-нибудь полезного и нужная только менеджерам и скрам-мастеру и только для того чтобы ощутить свою нужность :-)
art241111 Автор
28.06.2024 12:03Не совсем понимаю понимаю почему я сказал что то другое
Я описал пример, когда разработчик говорит о статусе своей задачи, который явно отображает статус выполнения цели
ngekht
28.06.2024 12:03Статус задачи с точки зрения daily может быть одним из двух
Результат уже соответствует definition of done (готово)
Результат еще не соответствует definition of done (не готово)
Варианта готово на 50% тут нету, или да или нет.
Но на самом деле в скраме в принципе нету понятия задача и этому есть объяснение. Весь скрам-гайд начинается со слов “легковесный фреймворк для решения сложных задач в сложных окружениях”
Сложный (курим Cynefin, часть материалов по подготовке к PSM2) - это означает что нельзя оценить/понять/предсказать через разделение целого на части. А задача - это как раз инструмент декомпозиции - то есть анализа путем разделения целого на части!
Так а дальше все просто:
или у вас можно сделать план через декомпозицию, и можно инспектировать следование плану, а значит предсказывать достижение цели, но тогда у вас не сложная система, и вы скрам используете не там и не так как он задуман
или у вас сложная система или сложное окружение, и тогда вы сами себя обманываете проверяя следование плану, потому что ни понять целое через части, ни предсказать вы по определению не можете.
Тут весь секрет в самом начале SG, в понятии сложности ради которой Скрам, эмпирическом методе на котором основывается скрам, и трех колоннах.
Короче классическая проблема познания - три вопроса - зачем, что и как. Первые два сложные, третий простой, и большинство не парится первыми двумя и фокусируется на третьем, как в вашей статье
Если захотите реально узнать - есть прекрасная статья, из списка материалов по подготовке к PSM2/PSM3 Кристина Вервейса из Либераторов (Liberators) - “Что такое сложность и на фига вам на самом деле скрам”. Можно найти на их medium, или если проще на русском - я ее переводил для habr еще лет несколько назад.
art241111 Автор
28.06.2024 12:03Спасибо за замечание и за материалы!
Со своей стороны могу только добавить, что мой пример из комментария основан из практики разработки. И тут как раз вопрос в том, что SCRUM это только фундамент для работы, а дальше каждая компания адаптирует его под себя. Мне, видимо, повезло и я попадал в команды, в которых не вставал вопрос, что такое дэйлики и зачем они нужны. Мы синхронизировали работу и понимали на каком мы этапе и кому с чем можно помочь.
Но Ваши материалы почитаю, звучит интересно
Kanut
28.06.2024 12:03Daily дословно нужен для инспекции того насколько УЖЕ достигнута цель спринта.
А можно узнать откуда вы взяли такое определение дэйли? В командах где я работал по скраму дейли вообще не использовали для подобной "инспекцит". Или вообще для отчётов о том что уже сделано.
Только для обсуждение актуальных проблем/блокеров.
ngekht
28.06.2024 12:03В 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.
Kanut
28.06.2024 12:03The 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.
То есть фокус именно на том что ещё осталось сделать. Что уже сделано, а в особенности что сделано за последний день, в общем-то никого особо интересовать не должно. И грубо говоря если у вас нет проблем/блокеров и всё идёт по изначальному/последнему плану, то что вы хотите обсуждать?
Kanut
28.06.2024 12:03+1И в таких случаях можно предложить им: «Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
На мой взгляд очень плохая идея. Потому что таким образом у вас дейли превратится в "отчёт перед начальством". Что полностью убивает идею дейли.
По хорошему во время спринта бизнес вообще не должен лезть в дела команы. Для бизнеса есть презентация/сдача задач в конце спринта.
art241111 Автор
28.06.2024 12:03Да, согласен, поэтому написал "если будут вопросы". Подразумевая, чтобы скрам мастер следил за тем, чтобы бизнес не "прописался" на дэйликах
Kanut
28.06.2024 12:03На мой взгляд даже если у бизнеса есть вопросы, то им не место на дэйли.
Один из основных приколов скрама как раз и заключается в том что бизнес "отгораживается" от команды и не лезет в её дела. У бизнеса есть "интерфейс" в лице ПО. У него есть презентация в конце спринта. И на этом в общем-то всё.
И бизнес тоже должен научиться работать по правилам скрама. Иначе нет никакого смысла этот самый скрам вводить. Более того по моему мнению то, что бизнес не готов придерживаться правил, как раз таки и является самой частой причиной провала скрама.
ngekht
28.06.2024 12:03Кстати нет, ПО отвечает за то что:
У команды есть бэклог
Бэклог состоит из PMI размером не более спринта и упорядочен по приносимой ценности
Работа берется только из бэклога
Причем он именно accountable - ему порвут жопу если этого нету, это ничего не говорит о том что разработчики не могут это делать. Более того - не в самом SG, но в материалах из вменяемых источников (рекомендованных например для подготовки к экзаменам или в книгах авторов скрама) - настоятельно рекомендуется их вовлекать.
Причина по которой бизнеса нет на daily - focus. Команда работает в сложной среде, то есть изучает сложную проблему через серию экспериментов, и вмешательство бизнеса в эксперимент - искажает результаты, то есть мы ни фига не узнаем, сложности не снижаем.
Так что причин у бизнеса лезть в дейли может быть две
Нет доверия команде через предыдущий успешный опыт или прозрачность того что происходит (смотрим обязанности Scrum Master, там прямо про отвечает за transparency) - потому что мы доверяем или тому что уже работало или там где понимаем что происходит.
Или цикл спринта слишком длинный выбран для текущей сложности системы, и цели/вводные данные меняются быстрее чем мы их инспектируем через цикл planning-review. И если даже неделя недостаточно коротко - то мы не зоне сложности, мы в хаосе.
А строится Scrum на предпосылке что у нас таки сложность, а не хаос - то есть время учиться у нас есть. Потому что если нету - то нам нужен не эмпирический метод, а триаж, с еще более коротким циклом, там уже часами исчисляется, как описано например в у Ким в “Настольной книге DevOps”
Kanut
28.06.2024 12:03Кстати нет, ПО отвечает за то что:
Ок, я может быть не совсем правильно сформулировал. ПО не должен отвечать на вопросы бизнеса во время спринта.
Он служит "интерфейсом" в том смысле что он собирает/он обсуждает с бизнесом requirements. По крайней мере других вариантов лично я не встречал.
ManGegenMann
28.06.2024 12:03+3О ещё одна статья про скрам. Сколько их уже написано, но люди все ещё не дошли до идеи "заказчику/пользователю не нужны релизы, ему продукт целиком нужен" фичи сами по себе не имеют ценности, часть продукта не имеет ценности.
Вот вам нужна машина. Не ходовая, не корпус, не двигатель от машины, не "пока ногами двигаться надо", не "в следующем релизе будет гидроусилок и сиденье вместо табуретки". Машина нужна целиком, вся. Никакие промежуточные фазы никого не интересуют. Продукт должен поставляться готовый у целевому назначению.
art241111 Автор
28.06.2024 12:03Но если посмотреть с другой стороны, а как разрабатывалась машина? Она же появилась не сразу
В начале сделали Ford T. Отличный автомобиль. мотор заводится в ручную, кабина деревянная. Усилитель? Не, не нужен.
Начали продавать. Продали какое-то количество.
Дальше внедрили стартер, чтоб руками не заводить и таким образом открыли доступ женщинам водить.
Потом поставили усилители, чтобы улучшить комфорт.Поэтому тут вопрос задачи. Если вы хотите сделать машину с усилителем, стартером и т.п., то вы делаете ее целиком. (Если смотреть по матрце стэйси, то это можно отнести к простой системе)
Но вот если ваша задача выйти с новым, инновационным продуктом, то без проб и ошибок не сделать хороший продукт.
Продолжая пример с автомобилями. Вот Wolkswagen вложил несколько миллиардов в электромобили. Зачем? Чтобы разработать платформу, проработать эргономику и т.п. Прошло немного времени и оказалось, что все же электромобили не факт, что будущее. И вот вопрос: а можно ли сделать прототип, без платформы и проверить, а нужно ли вообще это делать. А только после этого тратить миллиард на платформу?! И вот тут Agile помог бы потратить меньше денег, чтобы в начале проверить, а потом уже вкладываться в понятный маршрут
ngekht
28.06.2024 12:03Статья не про скрам, а про то как большинство (не)понимают скрама поскольку первую, самую важную часть пропускают и фокусируются как при помощи прикольных новых названий построить старый добрый процесс как привыкли.
Да и читают скрам-гайд явно не глазами. Для начала в скраме нет ничего про релизы, есть про releasable increment. Релиз это всегда решение заказчика, а дело команды каждый раз отдавать заказчику то что технически пригодно к постановке на прод, если заказчик решит что функционала уже достаточно.
А вот ситуация в которой 20 процентов функционала уже можно запускать, потому что 80 процентов потребностей уже покрыто и на системе можно зарабатывать уже сейчас - ничем не противоречит ни опыту, ни здравому смыслу, ни потребностям заказчика.
Так вот колесо вполне себе должно быть и на самом деле на производстве является releasable increment - его можно взять и использовать прямо сейчас, а не ждать пока вся машина не будет собрана чтобы проверить что колесо тоже ничего. :-) Да и любая нормальная команда по хорошему отлаживает каждый кусок продукт до prod grade не дожидаясь финального тестирования, чтобы сделать и уже не возвращаться. А кто этого не делает, тому увы и скрам не помогает.
art241111 Автор
28.06.2024 12:03Да, я с вами согласен на счет релизов.
Но в статье я нигде не писал про релиз. Наоборот я подчеркнул, что инкремент - не значит релиз
ngekht
28.06.2024 12:03Если говорить о статье - то в принципе я уже сказал - у вас прекрасно исполненное описание ответа на вопрос как в отрыве от что и зачем.
В отрыве настолько что некоторые вещи оказываются собственной противоположностью тому что они есть в SG, а какие-то оставляют такой простор для интерпретации что прям ой.
Проведите мысленный эксперимент - задайте себе вопрос чем описанная вами система отличается от итеративной и инкрементальной поставки, которые существовали задолго до появления Scrum, например в Rational Unified Process. А отличие есть, не стоило бы трудов придумывать новые названия для того же, не те люди придумывали Scrum чтобы перелицевать старое знакомое просто лишь бы было свое.
А это отличие - в том что RUP это предсказательный метод, основанный на декомпозиции и плане, пусть и реализуемом итеративно и с инкрементальной поставкой. А Scrum - это цепочка экспериментов по снижению сложности, которая не дает возможности сделать декомпозицию и написать требования и план.
art241111 Автор
28.06.2024 12:03Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один разВажно помнить, что Increment - не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз
Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
art241111 Автор
28.06.2024 12:03Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один разВажно помнить, что Increment - не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз
Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
Explorus
28.06.2024 12:03+4В больших проектах скрам скорее мешает, чем помогает. У себя в команде мы реализовали очень важное улучшение по скраму - уволили скрам-мастера и отменили ретро (но таки иногда собираемся по необходимости с пивом). И работа стала намного эффективнее.
art241111 Автор
28.06.2024 12:03на самом деле у меня есть ровно зеркальный пример. Мы внедрили скрам и смогли в 3 раза сократить lead time)
Но в любом случае, фрэимворк - решение команды. Если он ей мешает, то он ей не нужен
dph
28.06.2024 12:03А какие еще варианты кроме скрама рассматривали?
И что именно внедрили - скрам или скрамбат?art241111 Автор
28.06.2024 12:03В тот момент сильно ничего не рассматривали. У компании был путь к scrum, поэтому мы спорить не стали
Внедрили больше scrum. Из канбана ничего не брали кроме доски)
ngekht
28.06.2024 12:03+2Скрам фреймворк для решения сложных проблем в сложных окружениях. Это цитата из самого начала. При отсутствии сложности (причем в строгом научном понимании - когда проблему нельзя решить путем разделения ее на меньшие, то есть через декомпозицию) - скрам действительно на фиг не нужен, есть другие, более эффективные способы работы.
Если ваш скрам мастер был не знаком с cynefin подходом от IBM и пихал скрам не потому что он реально нужен, а потому что можно - то все правильно сделали :-)
Хотя забавно - ретро как раз мало имеет отношения к сложности, это кусок пришедший туда из Lean и пути постоянного улучшения (Gemba Kaizen). Возможно для проекта ваш процесс и был идеальным и улучшать его - растрачивать деньги, но инженерия без развития - это медленная смерть, так что предположу что на самом деле вы просто делаете continuous improvement просто другим способом.
sheshanaag
28.06.2024 12:03Какая нелепая утопия! Это случайно не марксисты изобрели? Где вы найдёте 10 абсолютно взаимозаменяемых неамбициозных людей с одинаковым уровнем навыков и подавленным базовым инстинктом собственности? Да ещё с разными зарплатами внутри команды. Кто определяет что инкремент не окажется декрементом со стратегический точки зрения? Откуда в скраме такая непоколебимая уверенность в приближении к светлому будущему на каждом небольшом этапе при отсутствии чёткого представления о конечной функциональности продукта на начальных этапах?
art241111 Автор
28.06.2024 12:03Agile наоборот говорит о том, что нужны амбиции. Потому что если в обычных компаниях все за разработчика решают менеджеры, то в Agile разработчик является ключевым человеком. (Но да, я часто приходил в компании и слышал «а мне удобно, задачу дали, а я работаю. А как там планируют, это их проблемы»
Ценность инкремета определяется на Sprint Review Product Owner и стэйкхолдерами, что указано в статье
В скрам не сказано, что не нужна цель. Просто ее нужно всегда проверять. Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь
syrus_the_virus
28.06.2024 12:03Никогда не думал, что программисты отупеют настолько, что, с одной стороны, нужна будет специальная методика для пинания их под зад, а с другой стороны они сами согласятся на это. Мда.
art241111 Автор
28.06.2024 12:03вы всегда работаете по методике. В любой компании есть бизнес процесс выстроенные годами
Поэтому это просто одна из идей как можно выстроить процессы так, чтобы разработчик мог принимать решения и при этом компания шла к своей цели постепенно и проверяла все идеи
HellKaim
28.06.2024 12:03О, спасибо огромное за статью.
Не то, чтоб я прочел что-то новое, но хорошо структурированного с вашими добавками материала достаточно, чтоб натолкнуть на кое-какие мысли.
Так вот:
У меня складывается ощущение, что бизнес не понимает одной хитрой вещи: далеко не всегда то, что делается - поиск нового".
Часто бизнес не готов комититься и не согласен на сроки: "нет, нет, нет, нет - мы хотим сегодня! Нет, нет, нет, нет - мы хотим сейчас!"
Понятно, что в идеальном мире задача ПО и СМ отгородить команду, но, возможно, не следует слепо внедрять методологии вообще на всем ландшафте?
Вот - эксплуатация. Какое количество там нового? Зачем там скрум или эджайд?
Вот - поставка (внедряем клиенту) - ну.. ок, можно сказать что тут есть элементы, которые можно натянуть.
Все эти методы, увы, они действительно не решают вопросы сложность vs хаос. Считается, что хаос как-то рассосётся сам. Но, увы, он не рассасывается.
Есть идеи?
art241111 Автор
28.06.2024 12:03На самом деле Вы правы. Поэтому команды часто делят на "продуктовые" и "сервисные".
В "продуктовых" часто есть смысл в Scrum и Agile, просто потому что это либо разработка нового, либо задает темп разработки
А вот в "сервисных" (то что ты говорил экслуатация и поставка) лучше использовать канбан. Сделать доску, поставить WIP лимиты и просто наглядно смотреть за тем, как идут задачи.
MaGogSG
28.06.2024 12:03И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
MaGogSG
28.06.2024 12:03И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
art241111 Автор
28.06.2024 12:03Доска - это все таки про канбан. И на самом деле в разработке to do, in progress, done мало, по крайней мере по моей практике
На счет эффективности и как она считается. Приведу картинку из SAFe, в которой они как раз пытаются объяснить в чем плюс гибкой методологии
Т.е. при обычной (справа) waterfall модели, ты будешь разрабатывать долго и не факт, что это то, что нужно пользователю (plan)
А вот за счет Agile и постоянных проверок, ты сможешь не отходить сильно от того, что нужно пользователю и за счет этого быть эффективнее.
Я писал пример в статье на эту тему, что за счет иттераций и взаимодействий с PO мы смогли сократить время разработки за счет того, что не стали делать лишние вещи, а быстро проверили гипотезу
Поэтому обычно, когда говорят о повышении скорости, то смотрят через эту призму.
--
А ретро, как сказали выше, есть не только в Scrum. И оно просто позволяет учится на своих ошибках, а не закапывать их в стол, как часто происходит в разработке
MaGogSG
28.06.2024 12:03"Доска - это про канбан" это не так. Доска лишь отражение процессов принятых в команде, а не отдельный инструмент который живет своей жизнь. Тут по скраму, а тут по канбану. Конечно мало 3 поля, ведь команда и ее процессы не перестроены под скрам. Да и не скрам это, про то и говорю.
В плане эффективности тут график показывает, что релизиться чаще, получать чаще фидбек от юзеров и пересматривать бэклог по результатам фидбека полезнее чем релизиться долго. Это решается путем декомпозиции и девопс процессов, которые позволяют релизиться часто. Скрам тут вообще не нужен для этого.
Эффективность в скраме как раз достигается за счет взаимодействия команды. Для интереса вбей в ютуб что такое скрам в регби и посмотри как это выглядит. Ведь фреймворк назвали как раз в честь этого элемента игры. Вы либо толпой перебороли соперника (решили задачу), либо нет. Поэтому таска или не делается, или в процессе, или уже готова. Нет состояния, что один толкает, а другие потолкают попозже.
Ivnika
Жаль картинки не в одном стиле :)
В остальном было интересно освежить в памяти
art241111 Автор
Спасибо за замечание! Учту в следующей статье
Ivnika
И про разрешение добавлять задачи в течение спринта тоже интересно было бы подробнее прочитать, я и не знал что внесли изменения, интересно когда и чем мотивировали
art241111 Автор
Ссылка на скрам гайд: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
--
Но так, я с тобой согласен. Когда готовился к PSM был удивлен, когда в тестировании был вопрос на эту тему. Этот момент на самом деле был один из решающих в том, чтобы написать эту статью