Черная книга Скрам ("Scrum black book") - ложные и реальные ожидания от Скрам.

Выступление на Infostart Event 2018
Ссылка на книгу: scrumblackbook.pmlead.ru
2:39 Черная книга Скрам - о чем это?
3:31 Скрам гайд не вполне соответствует Agile manifest - в чем здесь проблема)
7:31 Полезная функциональность - почему нельзя построить мост по Скрам
10:33 Пролема прогнозирования сроков в Скрам
18:34 Недостижимая кросс-функциональность
24:32 Сколько времени в Скрам уходит на планирвоание (и почему так много)
28:44 Другие проблемы с использованием Скрам
29:39 Черная книга Скрам - где скачать
Ссылка на оригинальное видео: • Доклад IE2018 | Иван С... и на сайт конференции: infostart.ru
Ссылка на книгу: scrumblackbook.pmlead.ru

[@Cloud-Storage]

Очень крутое выступление, спасибо! 👍

[@eugenerfrfzhfpybwf6174]

Четко разъяснил про роли и кроссфункциональность

[@ivanivanov7456]

Большое спасибо за видео! Раскрыло глаза))

[@redfoxie3054]

Спасибо за видео! Кстати, хочется тоже пару мыслей добавить, что происходит в реальности: когда я слушала видео-курс по скраму от PMI, там еще вещали, что если разработчики перерабатывают, то это уже тоже вылет из скрама, но поскольку , как вы правильно заметили, много времени уходит на митинги, ребята частенько приходят на работу раньше, чтобы просто спокойно поработать + митинги, в итоге, они могут потратить на всё провсё больше 8ч, что в каком-то смысле тоже овертайм, а значит опять а-ля скрам. Когда некоторые пытаются решить вопрос с митингами (делают раз неделю), и например в рабочем чате решают , то это опять не скрам (ибо выкинут ежедневный стэндап). Другая сторона медали: это гибкий график работы, и чтобы были все на месте для ежедневного стэндапа, нужно определенное время, желательно не посередине (и смысла нет в середине раб дня и вылетают разработчики из потока). Ну и наиважнейшая вещь да - это команда. Пока она сформируется (на психологическом уровне) нужно тоже время, а если спринт идет, то....тут и проблемы с велосити, что вы говорили, атмосферой в команде и плечом. Это тоже стоит иметь ввиду.

[@user-ue4pr5ig2h]

Ставлю класс. Очень интересное выступление. Спасибо!

[@nikitachursin3584]

Скрам безусловно накладывает кучу ограничений, которые в реальности мешают. Сама формулировка "... но это уже будет не Скрам" - это просто ужас. Но, в принципе, непринципиально, как это называется. За кроссфункциональность - моё почтение. Мне запись скинул товарищ, со словами "ты был прав насчет кроссфункциональности". Но рассказ про планирование, сроки и про недельные спринты - это профанация. Вот почему: 1. Сроки и планирование. Скрам, и если брать шире - Agile движение в целом, это про разработку софта в меняющемся мире. Требования могут меняться. Может быть не всё из того, что хотели изначально, реально необходимо в конечном продукте. А если мы берём и фиксируем требования, дескать, "только так и никак иначе, вот те крест" - зачем вообще скрам? Скрам, безусловно, не лучший выход в такой ситуации, но неплохой. 2. То что вы на планирование недельного спринта тратите 10% от этого самого спринта, а потом еще столько же на ревью и ретро - это ужасно, но это ваши проблемы. Обсудите на своём 3х часовом ретро (благо времени достаточно), почему вы столько времени расходуете на него и как вам это время сократить. Мы планируемся за 30 минут, на ревью еще 30 минут, на ретро 30-60 минут.

[@MrZabmax]

Есть 3 вида управления: Функциональный Проектный Процессный Scrum это про управление процессом. В процессе команда зачастую кроссфункциональная и там нет сроков окончания, потому он и процесс. Поэтому сравнивать одно с другим неуместно.

[@sergeilavrentev7468]

Спасибо за выступление и книгу. Что скажете по поводу SAFe (scaled agile framework)??? Вроде есть планирование, mvp, место архитектуре...

[@Kolenkalegend]

Спасибо!

[@Dimka267]

Скрамгайд от ноября 2020, раздел Scrum theory: Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed. То есть полнота достигается на уровне всей команды, пример Ивана с разными ролями актуален не только на практике, но даже на уровне теории.

[@9Corvinus]

Прочитал книгу, посмотрел видео: Пока опущу претензии к жесткости фреймворка, 1 что заметил: 1) Картинка с машиной из скейтборда. Ну это ж бред по Scrum, как раз-таки верхняя вполне себе в духе этого подхода (ну почти), а вот нижняя - ну просто бред, по нижней ветке, цель заказчика была поставлена как передвижение из пункта А в пункт Б и проектная команда создала кучу MVP, которые не подходили, потому что цель была понята неполно, у того же Сазерленда в книге есть пример с фотоаппаратом от эппл, когда они сделали 3 вида линз, всунули их в некий mock-фотоапппарат (если не ошибаюсь это была старая модель или модель другой фирмы) и представили фокус-группам и другим стейкхолдерам, в результате выбрали наиболее удачную. Еще там было о выборе корпуса и что, если вовлечь заказчика - вы можете получить обратную связь и заняться полезными изменениями быстрее, получить на них аксептанс, ну например, что вот такая форма кнопки спуска вкупе с остальными общими размерами удобна и будет принята за основу, теперь попробуйте запихать все железо, которым вы еще не занимались в этот форм-фактор. Мне прям интересно, где адепты скрама со скейтами сидят и чего они хотят от этого подхода вообще. (P.S. PMI классный и не противоречит SCRUM и спасибо за бесплатный курс) 2) И касаемо подхода к тому, когда SCRUM вообще можно применять, я подглядел уже неплохое объяснение - en.wikipedia.org/wiki/Cynefin_framework?fbclid=IwAR0GI8s7JP0zqSdPMQncsVTzJuIDOJEd2xj4gA-xcGkyJI4XnfJCgcwsfuU. Когда домен Complex, Scrum подходит. В случае большой неопределенности требований, в целом это не противоречит вашим словам, но это более общая конструкция, чем *там где много UI/UX*. Хотя зачастую это именно так. 3) Об оценке сроков... Скрам не поднимает этот вопрос, но не отвергает этого подхода. В той же книге Сазерленда да и всегда в реальной жизни какой-то устав проекта, вехи проекта и конечная дата дэдлайна в любом случае существует. И все что вы делаете по скраму либо успеет к дэдлайну, либо провалится. Скрам не запрещает анализа общих сроков и привлечения доп. специалистов для этого. А стори пойнты это метод анализа сториз из готового бэклога продукта на конкретном спринт плэннинг. По задумке Джефа Сазерленда скрам-подходи именно что быстрее должен закончить. За счет чего? Ну по сути за счет более частого планирования и траты на это больше времени. Скрам-подход подразумевает, что вы планируете детально только то, что вы видите в ближайшей перспективе и хорошо работаете после этого. (Честно говоря в PMI я не видел ни одного противоречия, если честно). Ну и быстрее команда работает, потому что это команда, она в стадии перформинг, потому что у нас супер-команда и она разгоняется, да. А если кого-то не в команде не устраивает производительность кого-либо, это должно выходить как impedance для команды. И здесь очень большой простор для психологии. Насчет падений постоянно велосити... Скрамбан с ограничением потока in progress весьма неплохо помогает понять а много ли препятствий и надо ли с этим что-то делать. В общем ретро это очень важно. 4) С кросс-функциональностью не вижу каких-то прям больших проблем, но тут ок, у меня не было такого опыта. У меня никогда все всё не умели, но они могли делать работу целиком, да, там были простои. Но тут можно обратиться к исследования, которое я видел в TEDx о прокрастинации. Инновационные идеи появляются тогда, когда есть время отпустить проблему, пустить его в подкорку мозга, заняться чем-то левым (но ключевой момент недолго) и затем у него щелкает и идея реально новая. В скрам-команде я кстати не вижу смысла в работе аналитика в команде, мб я не прав, но аналитики должны работать на PO, что кстати решает следующую проблему идеального PO, которого не существует в реальной жизни. Команда вместе с QA, PO на этапе плэннинга определяет какие определяет что они будут делать и какие критерии приемки, а затем это доходит до ревью. Ну и да, вы об этом сказали дальше, я пока нашел именно такой способ. К слову с тем, что нет ролей кроме девелопера не согласен, это не следует из гайда. Из гайда следует, что скрам не определяет никаких иных ролей. Разница ключевая, в понимании, которое обозначили вы - у вас не agile) А вот во втором случае-таки он. Ведь гайд это набор рекоммендаций, к которому нужно многое добавлять и не бояться гибко подойти. Это всё размышления вслух, а не упрек, ведь ваш посыл в том, чтобы разрекламированный подход не пихался где ни попадя без должного понимания и это я очень ценю и одобряю всем сердцем. Спасибо за вашу работу.

[@user-ov1bh2dz1x]

Спасибо за объемные структурированные размышления! По пунктам 1, 3 в целом согласен (с оговорками, не будут тут многословен). По пункту 2 - фремворк Кеневин, на мой взгляд, очень переоценен (и его немного "в лоб" трактуют, а оттого излишне много записывают в "у нас запутанная система, значит нам Скрам. Но в нем очень хорошее рациональное ядро (на самом деле дело не в запутанности, а в компетентности), опираясь на которое можно действительно эффективно подбирать подход (Скрам-Не Скрам и им подобные). В пункте 4 - ну да, тут весь вопрос в практическом опыте (у кого какой). В целом именно так - аналитика пытаются вынут на уровень product owner-а, тестирование сделать настолько автоматизированным, на сколько можно (собственно agile сильно стммулировал развитие автотестов), но если ролей больше и специализация уже - все, неизбежно, сильно запутывается. По ролям проблема гайда - ему нельзя противоречить (об этом в начале презентации), а в самом гайде .явный акцент на "никаких других ролей в команде разработки, кроме разработчик" (оттого и вынимают аналитика на уровень "product owner"). На практике все, конечно, дорабатывают Скрам под себя (и это "ок", с точки зрения здравого смысла). Но тут главное, дорабатывая не наплодить внутренних ролей и передачи задач, излишних внутренних зависимостей другим словом. Субъективно - мне нравится, как справляется с этим Scrumban (и не нравится классический Скрам, описанный в гайде). И действительно, об умении решать именно такие проблемы я и говорю :) Еще раз спасибо за подробный комент! :)

[@triyp4529]

Шикарно

[@lemtugov]

пару комментариев по поводу кросс-функциональности и планирования: *"кросс-функциональность"* (вариант когда не все умеют всё) согласен, что простой это плохо, особенно когда согласно скраму нельзя людей занимать другими проектами. НО: - на самом деле передача активности от одних экспертов другим (аналитик разработчик ... тестировщик) не идет по такому сценарию: "вышел неожиданно, передал активность другому и сразу ушёл в закат отдыхать".Т.е. на самом деле пики активностей заползают друг на друга краями (overlaps) и, понятно, что Иван для нагрядности скорее показывал проблему, но все же обычно во время спринта активность эксперта как правило продолжается еще после передачи другому эксперту (уточнения, детализации, обсуждения и т.п.). Конечно, пики активности у экспертов разные, и простои имеются, но скорее всего не такие большие как 1/3 спринта. (ну или это явный сигнал, что со спринтом что-то не так) Самое страшное, что для менеджера сложно в такой ситуации понять сколько реально делается работа и за сколько могла бы быть сделана/кого пнуть/ а что если просто кому-то лень? Собственно эта неопределенность мешает жить, потому что менеджер получает деньги за устранение неопределенностей. И тут пока основная для меня проблема - в скраме нет менеджера в понимании проектного управления, оно все как-то само. - 100% нагрузки 100% времени никто не общал, видимо простои это то, что приходится принимать как данность в любой методологии. Соответственно тут надо корректировать длительност спринта / количество или время появления нужных специалистов (учитывая косяк с velocity)/ подбирать соответствующих экспертов, которые тянут в нескольких областях, пока не появится необходимость в отдельном эксперте по этому вопросу. Кстати, подождите, что скрам говорит по поводу набора/изменения/стимуляции команды? *Относительно планирования:* Согласен, что времени на планирование тратится не меньше, и собственно никто не обещает более быстрого выполнения работ по сравнению с другими подходами. Вопрос на сколько это планирование полезно для заказчика. Якобы "пока вы планируете и уточняете невыполененные планы, мы планируем конкретно по нужному куску, который можем вот сейчас реализовать". С точки зрения "потерь", мы эффективнее. Мы работаем "полезную" работу. Прошу поправить если, не прав. Огроменное спасибо за материал в книге и видео.

[@Selihovkin]

Приветствую! Отличный и содержательный комментарий, спасибо! 1. Про передачу работу - конечно, я сильно упростил и утрировал сценарий. Важно передать суть - при таком разделении ролей возникают провисы (не полной бездействие, но вынужденный простой части команды). 2. Скрам отталкивается о того, что команда профессиональная, сплоченная, самомотивированная (или вы можете ее тако сделать). В этом случае действительно - совершенно непонятно "зачем тут менеджер". В противоположной ситуации возникают сложности (в том числе те, которые вы обозначили как "понять кого пнуть". В идеале характер задачи, людей ее решающих и климаты среди них должен такие вопросы исключать (в докладе говорил вскользь - увы, обычная ситуация не идеальна). 3. По поводу шустрости и вообще - к сожалению, это одна из корневых идей скрам (которая не всегда и не обязательно работает. "Согласен, что времени на планирование тратится не меньше, и собственно никто не обещает более быстрого выполнения работ по сравнению с другими подходами." К сожалению, обещает и еще как. Сам Сазерленд (соавтор Скрам гайда) в своей книге, которая прямо так и называется "Scrum: The Art of Doing Twice the Work in Half the Time". Если бы не обещали - вопросов такого рода бы не было. Еще раз, спасибо за конструктив!

[@Denys_Ivanov.]

Спасибо :)

[@KanalmaKanalma-nl9mm]

Если проект прописан до мелочей, то конечно зачем здесь скрам? Но если тут выпускается кусочками продукт и заказчик с самого начала согласен на жертвы такого рода, то вперед. Вы сделаете именно то, что нужно заказчику и главное если анализировать каждый релиз и следить за показателями. По поводу кроссфункцилнальности могу согласиться с тем, что хренос два сразу получится соборать такую команду, где все всё умеют, если только потратить на девелоперов кучу бабла на то, чтобы схантить их. А после попробуй их склеить, чтобы они сработались. Ведь культура есть стратегию на завтрак. Если они профи высшего уровня, но не подходят культуре в целом, то зачем эти профи вообще нужны. Или можно вырастить такую команду, но уйдет не мало лет. А потом вырастишь такую команду и по дороге сханят кого-нибудь и накрылась твоя кроссфункциональность. Тут важно чтобы команда могла реализовать то,что от нее требует заказчик. По поводу времени, которое уходит на планировании, да много, но самое главное что каждый раз это время сокращается. Тут важно правильно фасилитировать процесс во время планирования. Не уходить в детали. Возможно я влюблен в скрам, не судите строго) спасибо за видео, очень полезные вопросы, аж голова загудела)

[@maximmatyash1796]

Скрам Гайд 2020 стал немного «гибче» в некоторых вопросах, может к редакции 2220 года все проблемы будут устранены 😊

[@KirillBon]

Какая методология, и за счет чего главное, может обеспечить 100% загрузку? Например, хотя бы постоянную загрузку тестировщиков? Работал я в организации, которая придерживалась классического ватерфола. Проект выглядел примерно так 1.5 месяца дизайн 3 месяца кодирование 1.5 месяца тестирования. Чтобы тестировщики 4.5 месяца не сидели без дела, их пытались занять на других проектах. Если бы других проектов не было, им бы пришлось курить бамбук. Надеюсь автор жив-здоров и сможет ответить.

[@Selihovkin]

Современные методологии как правило нацелены на то чтобы "делать то что надо бизнесу/заказчику и с эффективной скоростью". Они в меньшей степени ориентированы на "загрузить тестировщиков работой. Однако 4,5 месяца простоя это в любом случае аномалия. :) Если работаете по PMI и в первые месяцы проекта вовлечение тестировщиков не предполагается (это не всегда так, но может быть и так) - скорее всего тестировщиков вовлекут в другие проекты на это время. При использовании Скрам например многое зависит от того как организован спринт, команда и вообще что именно разрабатываете. Где-то тестировщикам буквально "есть работа" с первых дней (пишут тест-кейсы, прорабатывают сценарии); в других случаях (определенные продукты, крупные спринты - тестировщиков выносят "из спринта" и вовлекают только по его окончании, но называть это хорошей практикой я бы не стал).

[@danilaskomorokh242]

Все не плохо. Но некоторые моменты меня смущают. Например толкование одного примера. Картинка про мвп (скейт-... - автомобиль) говорит нам что заказчику нужно движение, но не средство передвижения. Не нужно её так буквально воспринимать, она скорее для образного представления. Что бы заказчику было понятно что ехать можно будет уже скоро. А со временем функционал и удобство будет улучшено. Конечно же это моё субъективное мнение.

[@Selihovkin]

Спасибо. Я в выступлении говор о том, что не нужно заказчику который пришел за автомобилем предлагать "движение". Если я заказываю суп в ресторане, не нужно мне приносить сперва воду из ручья и неочищенный лук как MVP. Я подожду и возьму именно готовый суп, соответствующий лучшим стандартам индустрии. Много раз придя в автосалон вы соглашались первый месяц попользовать скейтом? Есть проекты (продукты) реализация которых может и должна идти с частой поставкой пригодных к использованию результатов. Но есть и такие, где такая поставка невозможна (бессмысленна). Картинка со скейтом это хорошо на мой взгляд отражает. Кстати, в индустрии на этот счет тоже более-менее давно сложился консенсус. Например, обратите внимание на эту картинку: altkomsoftware.pl/wp-content/uploads/minimum-vliable-product.png

[@danilaskomorokh242]

@@Selihovkin спасибо за ответ. Теперь я понял о чем вы. Я в голове держу такие ориентиры: Если заказчик приходит с конкретными бизнес-требованиями и спецификаций то скрам не используем. Если заказчик: "хочу того - не знаю чего" - тогда используем. Пс. Кстати на картинке по ссылке заказчику не нужна машина как раз. А нужно что бы она ехала.

[@Selihovkin]

@@danilaskomorokh242 но не нужно делать движение через скейт (заказчику нужно ехать и именно в машине, не на скейте) :) По ориентирам - да, вполне :)

[@danilaskomorokh242]

@@Selihovkin так ну вот начинается =) В целом мы про одно и то же говорим только разными словами. Я прояснил для себя то что не понял в книге. Спасибо за ваш труд.

[@ignatmarkin2287]

Строительство моста по СКРАМ возможно, но нужно помнить, что СКРАМ не для выполнения понятной задачи, а для поиска решения пользовательской задачи (перебраться на другой берег). И после 1-2 спринта ее нужно решить. Как это сделать за 2 спринта? Варианты: 1)паромная переправа (для людей и машин) 2)навести понтонный мост (для людей и машин) 3)натянуть троссы и повесить веревочный мост (для людей). Дальше нужна Обратная связь от пользователей, на основе которой выбираем параметры и моста и приступаем к его изготовлению. Причем сначала сделать опоры (да, возможно несколько спринтов инремент продукта для пользователя будет неработоспособным, зато можно будет показывать это реальным пользователям, затем ввести 1 полосу в строй, а дальше и вторую нарастить (или сэкономить, поняв что хватает одной - спроса нет). А еще попутной узнав, что сам мост бесполезен, пока мы не построили дорогу до моста, о которой почему-то не подумали в начале проекта, а еще сделать обновление яндекс-карт и гугл-карт, иначе люди не едут, т.к. не знают что мост появился. Т.е. СКРАМ смотрит ШИРЕ, чем просто выполнение "проекта".

[@Selihovkin]

Подсвечу только один аспект (с вашего позволения, не буду описывать их все, например тот факт что "с нуля" пармоная переправа тоже далеко не всегда организуется за спринт и т.п.). То что вы приводите в качестве примера - классическая подмена понятий. С тем же успехом мы моем сказать, что для того чтобы строить "мост по скрам" нам нужно на первых порах предложить пользоваться объездным шоссе, чтобы перебраться на другой берег. Вероятно, если бы я предложил в качетве примера "строительство многоэтажного дома" по Скрам - мне бы предложили на первом этапе раздать жильцам палатки и "собрать ползенюу обратную связь от пользователей". Ни пармоная переправа, ни объездное шоссе, ни палатки не являются MVP в истинном смысле этого слова. Из паромной переправы не строится мост. А люди заказавшие мост (или многоэтажный дом) вовсе не просят решить их проблему любым доступным способам. Они имеют ввиду вплоне конкретный результат. Грубо говоря "дольщику" не нужна от вас платка. Не нужны сваи. Ему нужна квартира именно такая, какая описана в рекламном буклете. И именно спустя тот срок, который обещан в рекламной кампании. Подментять постановку задачи ("тебе не нужен мост, тебе нужно на тот берег, я включу в бюджет паромную переправу на ранних стадиях") во многих случаях, реально - далеко не лучшая идея ;) Поэтому многие задачи нельзя "сделать по Скрам". Это нормально. Скрам не всесильный способ решения проблем. А достаточно узко заточенный ремворк. Невозможность сделать ограниченную функциональность, которая будет раельно переиспользоваться на более поздних стадиях развития продукта - одно из широко известных противопоказаний применения Скрам.

[@tarvolok]

Редкие выступления, когда скрам говорит практик.

[@knasonov]

А не коуч!)

[@user-vz9ex7hj3j]

По умозаключениям автора и его тезисам очевидно что автор вообще не понимает Скрам (его область применения и какую проблему он решает). В скраме нет стори поинтов, скрам не строит мосты. Модель Кеневина и Скрам гайд вам в помощь

[@Selihovkin]

Умозаключение у вас неправильное. А вот совет посмотреть на Кеневин ферймворк неплохой. Добавлю ссылку на свое видео: kzbin.info/www/bejne/np-QdnV7nJJpb8k