Организованное программирование

Всем привет Это подкаст Организованное программирование Я Кирилл Мокевнин его ведущий Сегодня у меня новый формат а точнее сегодня дебаты Это формат не новый но формат новый то как мы его проводим А у меня сегодня приглашённые гости которые будут спорить между собой Я буду сидеть в сторонке и смотреть на это и тихо хихикахать в микрофон А тема сегодняшнего обсуждения у нас Скрам А почему мы взяли эту тему Она близка в принципе всем разработчикам Скрам долгое время был супер популярен Э целая индустрия развилась вокруг него Все хотели скрам везде его использовали внедряли Потом как обычно бывает любая технология любая концепция начинает находить своих противников А разделились на разные лагеря И в конечном итоге сейчас где-то есть где-то нет кто-то за кто-то против Есть люди которые регулярно пишут что от этого страдают Есть люди которые регулярно пишут что без этого жить невозможно И вот сегодня мы хотим спустя много лет я думаю что это не первые дебаты по скраму да но всё-таки последнее время вряд ли вы их много видели мы м попробуем так сказать ретроспективно посмотреть на происходящее и поспорить на тему того во что это в итоге превратилось А делаю я это вместе с ребятами с Машей и Сашей надо было сказать и Сашей и Машей правильно да а которые собственно с согласились я так подозреваю с большим уровнем переживания поучаствовать в этом значит шоу И ребят давайте с вами познакомимся Маш начинаем с тебя Пожалуйста представься пару слов про себя Расскажи Луч Всё пару слов закончено Да доживю А в IT работаю с 2008 ээ работала сначала мануальным тестировщиком потом была тесли домом и в общем как-то так через скраммастера там инженеринг-менеджера дошла дол коуча хотя не знаю а где я остановилась на инженеринг-менеджере или на agile коуче потому что главное приносить счастье людям которые страдают от скрама как раз вот в целом-то наверное всё Так ну я Саша у меня инженерный опыт от российских ибиктеков до компаний поменьше и собственного стартапа на коленке В общем последние годы больше в менеджменте Вот сейчас Тихлит Тимлит команды в ФНТЕК стартапе Ну в общем люблю создавать человеческие процессы для людей Не скрам Да я же не сказал кто с какой стороны но я думаю потому как вы представились это более-менее понятно Я бы знаешь наверное с чего начал Тут вот есть интересная дилемма потому что с одной стороны 100% если не договориться о понятиях да то когда мы будем говорить мы можем говорить совершенно по-разному одних и тех же вещах потому что разные предпосылки Хкст - это не только платформа но и большое сообщество В нашей Telegram-группе более 8.000 человек: новички наставники и опытные разработчики Группа особенно полезна тем кто делает первые шаги в программировании и осваивает веб-разработку Здесь можно задать вопрос получить помощь обсудить выбор технологий и просто пообщаться с теми кто учится и развивается вместе с вами Присоединяйтесь ссылка под видео Я бы знаете наверное что тогда попросил вначале чтобы сильно в это не углубляться мы потратим буквально сейчас 5-7 минут на то чтобы каждый из вас сказал что для вас такое скрам То есть типа какую проблему вообще это решает и кому это нужно А и Маш давай мы с тебя начнём потому что ты этим профессионально занимаешься Скрам - это фреймворк На самом деле на этом моменте я закончу цитировать Скрамгайд Для меня Скрам в первую очередь - это те ценности и те принципы которыми он руководствуется Да понятно что там есть и ивенты есть и роли но дело в том что вот это вот всё как раз все там э практические внедрялки скрама да они нужны для того чтобы обеспечить выполнение ценностей и принципов И вот здесь вот это важно да там итеративность понятна да там свои бэклоги не бэклоги но основное - это вот именно ценности и принципы потому что как чаще всего я встречаюсь со случаями когда скрам не работает это как раз когда мы внедрили какие-то практики да мы внедрили там а ретроспективу мы внедрили там не знаю daily мы внедрили планирование но оно всё Всё идёт непонятно как и непонятно зачем и непонятно куда И это потому что людям на самом деле не донесли вообще зачем это всё надо Поэтому вот я здесь в первую очередь основываюсь на этом Да понятно что нам нужны и планирования нам нужны ретроспективы но опять же а в скран гайде ничего не сказано как их там надо проводить да и вариантов целая куча То есть есть цель у каждого ивента и мы соответственно а-э там есть участники и мы должны каким-то образом это организовать В этом сложности заключается Но если понимать на самом деле чего мы преследуем да какими ценностями мы руководствуемся и ради чего мы это делаем чтобы обеспечить опять же там прозрачность инспекцию адаптацию чтобы и выжить в этом мире и чтобы а адаптироваться быстрее под изменения и чтобы заказчик наш был довольнее и пользователи чтобы были довольнее и нам самим чтобы работалось лучше Вот тогда э все в общем-то ивенты они абсолютно спокойно подстраиваются Но начинают как правило к сожалению не с этого начинают как раз с того что давайте мы быстренько запилим сейчас планирование оно идёт с натягом результатов примерно никаких таких Ну всё скрам не работает давайте до свидания То есть для меня скрам в первую очередь это вот основополагающие ценности и принципы То есть грубо говоря для того чтобы Скрам с чем-то сравнивать нужно нужно наверное представить а что если бы его не было То есть почему вдруг он понадобился Потому что не совсем понятно из того что ты сказал То есть что вот у нас не было скрама и мы страдали он появился и мы решили какую-то проблему да Э здесь ну наверное большую такую лекционную часть не буду зачитывать но вкратце А изначально вообще никаких там подходов к разработке не было Был один разработчик ему пришла идея и он сидел там запилил да что-то Ничего на рынке нет все рады счастливой появился какой-то там чат-месенджер Мог пилить он его там 2-3-5 лет в одно лицо И было хорошо Потом началась разработка под рынок В какой-то момент возникли несколько проблем То есть первое - это долгий цикл разработки самой да То есть мы начали не успевать за рынком а появилась потому что конкуренция там в определённых нишах Ну в любой нише на самом деле появляется конкуренция как только эта ниша создаётся Вот А либо мы не успеваем а конкуренты нас опережают по каким-либо причинам не знаю там потому что у нас 200 человек а у них 1.000 и каким-то образом они быстрее это сделали А либо это просто уже никому не интересно то есть мы делали делали продукт он стал неинтересен мы потеряли свою аудиторию А либо вот та ситуация с которой я на самом деле в своё время столкнулась у меня был опыт работы вот в таких вот затяжных а процессах тоже Это когда мы выпускаем продукт а продукт оказывается сильно косячным Хотя с требованиями вроде бы всё нормально разработку по-другому сделать не смогла но и в итоге у нас не очень получается сделать то что мы хотели Вот И исходя из этого там было несколько а итераций подходов к тому как организовать процесс А ну и вот наверное последнее из того что человечество придумало - это как раз скран Но он больше а как а один из фреймворков входящих в ну вообще йл появился после Скрама да Вот А он ориентирован как раз на пользователя и на заказчика И по большому счёту а он решает проблему довольства людей тем продуктом что мы делаем Ну и эффективность тоже организации Плюс так как это итерационный процесс да но итерактивность - это опять же там не про скрам то есть она до этого появилась итерационный процесс и до него были Это не вот новшество которое в Скрам появилось Вот А за счёт итерактивности опять же мы и в том числе решаем проблему вот с этим отставанием от рынка и там никому не нужными продуктами за счёт сбора обратной связи Вот как-то так Саш мне кажется тут не нормально фактура накинута да чтобы можно было уже начинать делать Да я записывал записывал такое Ну наверное да мы в начале просто согласимся О'кей Я сначала думал сейчас всё расскажет и я такой: "А будет вообще скучнота Мы вообще не спорим" Мы с тобой про одно и то же просто с друг с двух сторон То есть да Скрам типа такой фреймворк Вот за тебя выбрали инструкцию за тебя выбрали инструменты вот дали инструкцию Я вот согласен что вот про принципы ценности про которые все забывают про области применимости которые никто не описывает вот где скрам нужно применять Нет ребят это вот нужно продавать Поэтому ни одного продукту скоп где инструмент этот применяется давать не будут потому что его нужно продавать гораздо шире Вот А не знаю на самом деле как бы ну фактуры много то есть да можно рассказывать что вот скрам продают как а но на самом деле в скрамгайде ничего прожаile не написано Я бы сказал что точно ли это Ажаile нужно ли его продавать как Ажаile процессы менее важны чем у нас то как у нас мы работаем как бы это может быть противоречит тому что написано а вжал манифесте Ну вот вот эти вот все моменты вот которые я не знаю как разделить а то как люди и консультанты продают Скрам то где он нужен и там где он работает И это вот все какие-то все три разные области такие И везде мы умудряемся накосячить внедрить скрам там где не надо понять его не так и сделать неправильно И да поддаться ве Саша расскажи про свои кейсы да потому что я так понимаю что у тебя же боль своя какая-то есть То есть очень интересно послушать Пусть это будут даже там если копнём разные причины но интересно вот как боль какая у тебя от этого Чёрт у меня нет боли Мне правда не пришибли с крамом Мне не пришибли с крамом Я аэ знал э я слышал много историй а я иногда помогал как-то их разруливать но они случались не со мной А единственная история когда а которая случилась вот проскрам со мной - это когда у нас была такой среднего размера а компании а достаточно прошаренные менеджеры разработки И у нас было что-то канбаноподобное И к нам пришёл коуч и он сказал: "У вас будет скрам" А мы сказали: "Нет потому что мы прошаренные" И работать по скраму не будем И продолжили работать по канбану Ну никто нас не кусал Сейчас прямо в холируй иду Давай Смотри канбан на самом деле ну последнее позиционирование канбана - это не отдельный вид процессов То есть если скрам - это фреймворк который говорит: "Вот тебе ивенты вот тебе роли а а вот тебе соответственно артефакты" да то и и ты можешь работать так то канбан тебе говорит о том как ты можешь улучшаться То есть канбан - это метод который позволяет улучшаться Канбан в вакууме не существует То есть у вас должен быть уже какой-то процесс Это может быть абсолютно спокойно там ну не скрам А если там у вас нет этих ролей если у вас там ну просто другие роли у вас допустим был какой-то итеративный процесс да может быть не с фиксированными итерациями как Скрам этого требует да там не 2-3 недели а вот условно там ну в этот раз мы поставимся через 3 недели в следующий раз там через четыре а вот сейчас по готовности там мы поставимся там через день через 2 дня О'кей Но у вас так или иначе всё равно есть какой-то итеративный процесс вот на который вы уже накручиваете весь вот этот вот канбан да Виплимиты вот эти все чтобы у вас быстрее пошло дело чтобы простоев там не было Э вы там накручиваете там ту же самую прозрачность ну потому что без неё и виплимиты там бесполезны и так далее То есть да о'кей То есть ну вы всё равно работали по какому-то процессу не по скраму О'кей И мне я просто к чему придираюсь да к тому что мы работали по канбану Ребят канбан - это то что я сказал канбаноподобное Да я сказал канбаноподобное потому что я как раз тоже знаю этот нюанс И у меня как раз главный комбонист ну не знаю в России Лёша Пименов если считать его самым известным Вот он как бы а слушайте а Скрамбан сравнивать некорректно Это вообще разные штуки Одно про э как э работать ну там с каком-то созданием по а другое там про создание нехрупких организаций Это вообще разные штуки Но мы сейчас как-то общаемся и да пытаемся такие потому что люди как бы по наитию говорят: "Мы работаем по скраму мы работаем по джайлу мы по канбану" То есть нам приходится следовать каким-то не знаю неправильным терминам и как-то выживать в этом Это грустно мне кажется Это кстати может быть достаточно скучный разговор для разработчиков Это вот это вот пусть консультанты вот с этим со всем этим разбираются Да я завершу наверное да Я просто сама вот эти вот то что называют обычно канбаном я предпочитаю называть поточной разработкой по готовности как бы Ну о'кей Нет нет жёстких итераций Вот Аэ по поводу а того э что пришёл к вам коуч и сказал: "Давай давайте скра" А вот здесь на самом деле то что я встречаю опять же да э много видела там и продажников и людей которые работают в звании л коуча Аа если ты не знаешь ничего кроме ты будешь продавать это Ну одна сторона да А с другой стороны если ты не можешь разобраться в том что есть ты будешь продавать то что тебе известно Ну опять же самый распиаренный скрам И вот здесь про коучей наверное и вообще про людей которые начинают там какие-то трансформации не трансформации приходят такие: "Всё давайте скрам нет давайте не скрам а давайте там не знаю если масштабирование давайте сей" У меня вопрос: а почему сейф Почему не Less Почему не Nexus Почему не Spotify Ну потому что самый распиаренный потому что в сейф кучу бабок в маркетинг вложено его все покупают Ну вот так это и продаётся а в итоге люди страдают Да И это если тебе так честно ответили я просто не знаю звезду героя ему дам за честность потому что распиарены Но никто же не сознается Мало кто сознается да А страдают в итоге разработчики Поэтому а если уж ругать коучей давайте их ругать до конца Прежде чем ты приходишь и начинаешь говорить что ребята вам точно нужен сейф Блин проведи хотя бы аудит поговори с людьми за с теми кто в поле пашет с э теми кто владеет этой организацией Насколько э вообще дела в полях как обстоят да и насколько люди э сверху готовы Ещё же что происходит Вот я про ценности не зря начала да А с чем я сталкиваюсь Что скрам почему он продаётся и почему он не взлетает Потому что приходят э например консультанты и говорят: "Ой а давайте мы у вас в командах сделаем скрам Глядите как всё классно будет" Раз в 3 недели раз в 2 недели вы будете поставляться будет бомба огонь всё командочки будут вы всё будете видеть что надо Да ничего не надо просто вот пустите нас мы в командах сделаем А потом начинаешь упираться в то что в организации ценности которые необходимы для внедрения Скрама не поддерживаются аэ даже там ну вплоть до до уровня топ-менеджмента Начинаешь про э там про ту же самую там прозрачность да они говорят: "А мы тут при чём?" И получается разрыв ценностей между верхушкой и командами И команды оказываются без поддержки То есть с одной стороны руководство сказало: "Да давайте нам скрам" Почему Да потому что нам самим ничего делать не надо нам самим меняться не надо А в командах так это не взлетает Для того чтобы скрам начал работать эти ценности они должны работать на уровне всей организации начиная сверху и заканчивая низом И вот этого как раз нет Ну и потом да понятно у нас начинаются боли да когда команды такие сходили на ретроспективу допустим им это зашло а они поняли что да глядите мы можем влиять на то что у нас происходит Ну мы на самом деле можем принимать какие-то решения по улучшению да а можем там э решать какие-то проблемы Но потом с каким-то временем команда доходит до того что понимает что у них проблемы такого уровня которые нужно уже эскалировать и чтобы решил кто-то другой Часто встречаюсь например с проблемой опять же межкомандного взаимодействия да То есть вот мы в команде всё порешали одна команда работает всё у неё налажено Как только начинаются зависимости от внешнего межкомандные взаимодействие у нас тут появляется руководитель проекта приходит к другому руководителю Другой руководитель говорит: "Слушай у меня там свои задачи у меня свой объём работ у меня всё очень срочно мы не успеваем как бы ну мы не будем это делать" Что получаем в итоге Демотивацию разработчиков которые работают по там по тому же скраму да например Это не работает потому что мы вроде сделали поставку поставить продукт мы не можем или у нас постоянные затыки мы берём мы даже не можем в спринт взять потому что у нас зависимость внешняя и не факт что мы её разролим О'кей Руководство выше руководителя проекта начинает играться в ситуацию когда: "Ой ребят ну вы там сами как-нибудь решите" Но вот на самом деле он прав И это же руководство начнёт спрашивать с того менеджера который отказывается и у него выбора не будет он будет отказываться И вот тут вот начинает всё прямо ломаться очень сильно И да мы приходим к тому что скрам не работает Опять же почему Потому что поддержки реальной нет и как бы целеустремлённости нет Но страдают разработчики страдают тестировщики потому что начал делать на полпути остановилась например да а мне там нужно не знаю провести пришла какая-то задача мне нужно договориться с другими людьми там об интеграции или просто там понять как это работает Мне нужно привлечь э там человека из другой команды а я не могу Ну в итоге я в спринт эту задачу взять не могу Или я взял задачу в спринт я за неё отвечаю Я очень ответственный человек я бьюсь у меня нервозы что я не успеваю у меня ничего не получается я начинаю это эскалировать эскалирование не работает Ну в итоге да ну ну и как бы и зачем это всё да Лучше бы мы работали а по принципу вот э когда-нибудь мы там договоримся поставим дату какую-нибудь да и когда-нибудь мы это сделаем Ну да я искренне соболезную и разработчикам и тестировщики с этим же сталкиваются с тем же самым там интеграционным тестирование сплош и рядом когда одна команда сделала договорились делать даже там в одном спринте например а одна команда сделала вторая и не сделала В итоге что мы теперь историю закрыть не можем Ну в итоге мы что теперь спринт завалили А мы-то причём как бы да Другая же команда начинаешь это поднимать а и опять же упираешься во что Не в людей которые в полях работают а в руководство И как оно к этому относится Вот это очень печально Да я тут думаю могут ли как это вырулить такие это не знаю волшебные люди с лидерством которые такие инженеры в одной команде такие синьоры такие м ну надо договориться типа да у нас есть какие-то глупые процессы там что-то там с с этими спрентами но нам нужно всё-таки пойти договориться мы же за правое дело Вот Но думаю что да иногда конечно абсолютно согласен с тем что вот когда не выровненная вот эта штука по всей вертикали как бы ну случается грустно Ну и естественно вот есть у нас фреймворк вот к нему инструкция там гайд он вроде такая коротенькая штучка такая ну там можно сдать там тест да там пройти первую ступень вторую ступень я не сдавал поэтому ну слышал я слышал от мне Петрович напел Вот А вдруг тут оказывается что чтобы этот инструмент внедрить тебе нужен ещё очень высокооплачимый высококлассный специалист правильно А ещё чтобы у него всё получилось тебе нужно ему дать некоторый картбланш что у нас тут есть какое-то изменение вот ценностей культуры и вот оно вот ещё как-то должно вывести а что-то что-то не вывозится Слушай на самом деле вот я бы не сказала что везде прямо нужны вот так вот коучи правильно

Потому что скрам не нужен А вот про скрам я не про скрам я не уверена что он не нужен да на самом деле я могу сказать точно где вот я не вижу э- что нужен скрам Это если ты работаешь в команде поддержки потому что у тебя если прилетают от пользователей заявки да э есть какая-то небольшая разработка но плюс ещё поддержка и по поддержке очень много очень сложно спланировать спринт Ну вот просто из-за этого да там у тебя какая-то цель спринта то есть вроде как можно можно конечно там натянуть сову на глобус оставить какой-то гэп в капасите Э то есть ну например там вот мы забиваем сейчас нашими задачами там 30% спринта да потому что на 70 нам скорее всего прилетит что-то от пользователя И цель мы ставим вот по этим 30% Цель спринта закрыть задача спринта да но это уже как бы не совсем проскрам да потому что вот у нас же там планирование ещё что-то вот начинается вот это натягивание совый на глобус Ну о'кей тогда давайте скажем что хорошо да мы работаем итеративно а-а но у нас как бы ну не скрам потому что планирование нарушается да у нас есть ретроспектива но ретроспектива опять же если вспомним это про инспекцию и адаптацию Ну то есть её можно внедрить в абсолютно любой другой процесс не обязательно в скрам Синхронизации вот эти дейли да там в чём суть очень важная для меня в том что это перестаёт быть статусом для заказчика И вот то что как раз ты сказал что там типа ребята сами разрулят ребята могут сами разрулить но если опять же мы говорим про то что у нас есть привычка что у нас есть руководитель проекта который за всё за всех решает который в принципе ну не очень сильно заинтересован в том чтобы люди в команде росли и именно в принятии решений там в разруливании ну потому что он иначе работу потеряет Ну как бы если за него будут решать всё зачем нужен он да Страх такой есть может быть у людей Вот то понятно есть там люди которые не научились Хотела пример привести насчёт того что коучи наверное и не нужны да и в общем-то и руководители проектов кстати тоже И менеджеры один менеджер на 100 с лишним человек вполне достаточно как в Гугле да Там всех инженерингменеджер да этот менеджер чтобы подбивать зарплату и в общем вот такими делами заниматься Я э работала в Тефль потом пришла как раз в компанию Exellent Services она тогда называлась И вот там в рамках аккаунта у нас был один человек он был у нас тогда руководителем проекта и он очень сильно топил за скрам а сам читал сам развивался У него нет и никогда не было никаких там сертификаций ничего но он очень реально много там и смотрел и нам рассказывал И он нам вот как раз все эти вещи и доносил И по большому счёту а то через что я вот впервые прошла то есть представляете я пришла там из вот этих классических моделей где я была там тестировщиком у меня был лид у нас был руководитель проекта всё они решали И в какой-то момент вот на проекте с нашим руководителем проекта мы остаёмся без него потому что на другом проекте случился пожар и его просто в один день забрали туда Мы такие сидим: "Так а что мы делать будем А куда же мы без тебя родненький Пусти нас к себе возьми Не надо не на не оставляй нас маленьких деточек Ты куда ж мы там все тридцатилетние сороколетние да неспособные детятки А в итоге ничего справились на самом деле потому что как оказалось скрам работает Вот как ни странно у нас на самом деле То есть ну это же не про скрам но да но это про людей И это про то что гляди это про то как человек нас научил работать без него по сути но мы не догадывались что мы без него можем работать И дальше как раз вот аккаунт рос у нас не было на аккаунте у нас было порядка двадцати проектов У нас не было ни одного руководителя проекта Аккаунт рос аккаунт развивался проекты между собой были взаимосвязаны Не вот прямо сильно но взаимосвязи там были То есть это одна платформа на которой просто разные скажем так продуктики ну для разных э направлений там пользователь Вот И э соответственно вот он у нас в итоге стал инженеринг-менеджером Там была я как следящий за тестировщиками и помогающий по процессам был ещё один человек также по разработчикам и по аналитикам И этого было достаточно И мы сами внутри выстраивали процессы То есть вот он нам показал он нам объяснил и дальше мы сами без кого-либо абсолютно спокойно и знаешь счастливо жили Честно эта должность не назывался коуч Эта должность не называлась коуч Я прол коучий тогда вообще в жизни не слышал Причём мы пытались нанять да причём мы пытались нанять скраммастера к нам Я лично вот собеседовала с ним как раз я не знаю ну сколько-то собеседований мы провели там может 10-20 порядков В итоге потом разочаровались сказали что блин нафига нам скрамастера У нас ребята такие молодцы мы сами можем То есть у нас по сути даже выделенных скраммастеров не было У нас на одном проекте например аналитик был за скраммастера на другом проекте мы шарили э вот на моём проекте конкретно на котором я работала я была тогда тест-лидом А например я проводила ретроспективы а Техлит у нас проводил дейлики а аналитик у нас проводил планирование и нам не нужен был больше никто С заказчиком мы общались все вопросы какие-то возникали Ну наверное если только вот по найму людей да тогда мы ходили к вот нашему инженеринг-менеджеру и говорили что смотри и то это была наша задача прийти к нему и каким-то образом показать что да нам на самом деле там нужен ещё один тестировщик И в итоге это свелось даже в каких-то моментах к тому что мы и заказчику сами продавали это же что приходили к заказчику и говорили: "Слушай нам нужен ещё один тестировщик" Вот согласуешь не согласуешь А согласование бюджет уже уходили к нему Не было скраммастеров не было ЙЛ коуч но Скрам вот там конкретно работал Ну может быть работал бы и не Скрам мы не знаем Вот я бы хотел кстати вернуться что вот вот ты сказала вот про как раз границы применист Крама И вот я вот с этим прямо согласен Вот там где нет поддержки Единственное что а это же очень узкая история У нас вообще говоря ну все разработчики что что-то разрабатывают мы не разрабатываем там типа 2 месяца и потом всё там с чистого листа Мы должны заниматься поддержкой У нас поддержка есть всегда Поэтому я бы сказал здесь мм вот может быть скрам вот первые 2 месяца разработки когда у нас ноль пользователей показать что-то продак там Хорошо отлично Ну дальше Поддержка Привет как бы у нас свои приоритеты меняются нам нужно перестраивать процесс Очень узкая реальная граница вот эта вот И вот второе сейчас то что хотел добавить это вот э про вот то что ты упомянула в дальнейшей истории про аккаунтов У вас же как раз была вот эта автономность самостоятельность команды То есть вот это вот другая фича ну как бы ценностей скрама про которые мы забываем Типа когда мы говорим что у нас есть команда она команда разработки Вот мы добавляем туда тестировщиков а уже у тебя не все разработчики И вот тут начинается людям как бы тоже больно почему-то А в начале спринта там у тебя например есть без системные аналитики они должны страдать потому что быстро всё даже нужно сделать чтобы отдать разработчикам А в конце спринтать тестировщики страдают потому что нужно срочно всё выкатить а в другое время у них задач нет Потому что у нас скрам Угу Зачем А смотри смотри сейчас То есть это неправильное применение Вот не делайте так Вот там скраб не надо Давай сейчас Да по очереди Поддержка для меня Поддержка - это скорее когда большая часть прямо обращения от пользователей и очень редкие изменения потому что то что ну то что ты говоришь да понятно что мы там пилим пилим пилим продукт потом мы выходим в продакшн и у нас получается одна ветка - это продолжение развития продукта Это вот то что от нам от бизнеса прилетает что я хочу ещё вот эту фичу хочу вот эту фичу а вот эту фичу переделаете Вот так А вторая - это когда пользователи начинают продуктом нашим пользоваться и от них ещё какие-то проблемы прилетают Блин сейчас в контрактование уйду не знаю насколько это вообще будет опять же интересно людям да А попробую как бы чуть-чуть только контрактование вид контракта задействовать А вот соответственно в зависимости от того какое у тебя контрактование то есть если у тебя например есть жёсткие слеи а да то есть ну у тебя отдельно контракт на сопровождение отдельно контракт на развитие и ты должен и там успеть и тут успеть но у тебя либо тогда ты делаешь э как вариант да у тебя команда развития идёт всё ещё по скраму ты разделяешь просто делаешь команду развития и команду сопровождения и они просто синхронизируются между собой Это один вариант Вот Аэ другой вариант либо если у тебя это одна команда но тут скорее всего да имеет смысл уйти от скрама потому что тебе постоянно чтобы уложиться в эти слэ нужно будет перелопачивать состав спринта а это ну уже нехорошо Состав спринта может меняться Ну да это другая другое заблуждение которое люди фиксируют состав спринта и такие он может если не меняется при этом цель спринта и задачи которые убираются или добавляются они со идут всё ещё в соответствии с целью спринта Но теперь смотри у тебя одна цель спринта тебе прилетает что-то от пользователей Насколько вероятно что это совпадёт с целью спринта Поэтому я и говорю здесь уже начинается как бы такая игра что вроде скрам вроде не скрам да Не скрам тут я согласна И значит э вот как раз тот вариант в котором мы жили у нас э заказчик был достаточно лоялен тому что приходит от пользователей Пользователи ну по крайней мере вот у нас они были внутренними на нашем на нашей части продукта да и с ними можно было договориться то есть и мы просто закладывали там их проблемы на самом деле в следующий спринт Вот если такое возможно ну там как дефекты как ошибки как технический там долг если это на самом деле было техническим долгом да ну мы понимали в итоге что да вот это вот не работает так как они хотят потому что там это ну костыль у нас тут здесь всё было нормально То есть даже если ты можешь договориться заказчикам об этом то в принципе можно Но ещё раз вот здесь наверное стоит уточнить у нас было очень мало заявок от наших пользователей То есть там буквально может быть это было их штук там пять-шесть в месяц Когда они валятся тысячами эта схема не сработает То есть у нас всё-таки там было больше развития да Но если ты сделал качественный продукт и то что хотел от тебя пользователей пользователь то скорее всего заявок именно от пользователей что ой что-то не работает наверное у тебя будет мало как бы скрам вот это вот предполагает Поэтому в принципе он тоже может быть распространён на поддержку на лайтовую поддержку Если ты закапываешься в поддержке то скрам работать не Понятно да То есть должны добавляться в спринт задачи которые не как это не мешают выполнению цели спринта И вот у меня всё время вот с этими правилами да у меня вот с этими правилами такое как бы всегда то есть мы всегда должны задумываться о'кей типа а вот вот эта вот саппортовая таска она вот сейчас она может быть челове очень важная мы можем терять пользователей но вот она не бьётся с целью спринта О'кей типа мы должны её отложить на потом Почему То есть вообще кажется вот каком-то итеративной разработке: "О'кей может быть я сокращаю итерации до одного дня?" И такие говорят: "Давайте мы каждый каждый день будем перепланировать" Но вообще говоря типа а давайте каждый день задумываться что мы делаем что-то самое важное Вот у нас на столе какая-то критическая проблема от пользователей и у нас могут уйти люди А с другой стороны оно противоречит целеспринта Ну она важная Вот здесь костов де стоимость задержки очень большая А вот здесь вот ну как бы тоже важно мы обещали нашему любимому продакту да поэтому я говорю: "Вот в поддержку я бы пошла наверное в поточку" То есть в в активную поддержку такую да Либо на самом деле если мы понимаем что э там вот это важно о'кей ещё раз говорю люди читерствуют но тогда говорите что да у нас просто итеративная разработка и мы используем определённые ивенты из скрама у нас роли из скрама но это не скрам Ну потому что мы чему противоречи то есть это вот вопрос терминологии И вот эту адаптацию команды тоже часто достаточно болезненно проходят Потому что пока ты сидишь у себя там в вакууме что-то делаешь у тебя всё хорошо-хорошо а потом бабас вторая смена и к тебе пришли пользователи с их проблемами и ты такой: "Ё-моё а как мне жить?" Ну о'кей ребят ну вы можете оставить итерации но тогда понимаете что вы идёте не по скрам и что-то может не работать Ведь фишка-то в чём ещё Что какие-то моменты можно обойти да То есть почему например там а daily должен быть 15 минут почему не 20 Ну потому что фокус теряется О'кей Если мы готовы идти на 20 минут значит мы идём на тот риск что у нас фокус теряется Если нам нужно запихнуть задачу спринт ну о'кей мы понимаем что мы нарушаем риски какие профиты какие но давайте не будем называть это скрам Да бог с ним В целом-то у нас итерации сохраняются 2 недели Да но мы говорим о том что Ага а вот сейчас теперь мы можем поставить и должны ставить не только через 2 недели вот этому пользователю его критичный дефект а как только он был готов и бросаем всё и бежим туда да То есть у нас приоритеты резко меняются И тогда вот этот вот принцип того что там команда уходит в себя там на 2-3 недели её никто не трогает он нарушается Мы понимаем что у нас тут стрессняк что у нас на самом деле может быть ещё и подход к брончеванию нужно переделать да Ну в зависимости там от того в каких ветках То есть нам нужно срочно там какую-то ветку взять это изменение вкинуть потом обратно потом там из другой ветки куда-то взять потом это ещё на проме всё проверить и так далее и тому подобное да О'кей Но то есть мы идём по тому пути что мы создаём в команде нервозность Сможет команда с этой нервозностью жить Не сможет она жить А что лучше А может быть есть другие варианты Ну тогда да тогда хорошо тогда пересматриваем Может нам Скрам не нужен По поводу аналитиков разработчиков и тестировщиков То что команда разработки Очень забавно на самом деле да это было формулировано как developвеelмент team и все понимали что это именно разработчики Я кстати э раньше с этим часто сталкивалась сейчас реже но сейчас была удивлена Команда разработки - это не только разработчики то есть это не только программисты Так команда разработки это и аналитики то есть ну в нашем случае это аналитики разработчики тестировщики И то что ты говоришь что вот в начале спринта там аналитик должен быстренько что-то сделать да потом там разработчик должен что-то сделать потом тестировщик ещё в конце спринта успеть и все в панике Все в панике Если посмотреть немножко по-другому почему аналитики должны успевать в спринте Глядя идея скрама какая У тебя есть человек владелец продукта который очень хорошо знает что ему надо Он в первый день спринта приходит к команде говорит: "Ребят смотрите я хочу вот это" И планирование - это та встреча где команда задаёт ему вопросы и э понимает вообще можем мы это сделать не можем мы это сделать и как мы это будем делать То есть все требования выясняются во время планирования по большому счёту и понимание того как это будет реализовано тоже во время планирования Если команда понимает что там есть какие-то вопросы на которые владелец продукта сейчас ответить не может владелец продукта уходит задача там в спринт не попадает да он там говорит: "Приходите через 2 недели" да Ну или через 2 недели или на самом деле здесь нет же такого То есть в зависимости от того какой вопрос да То есть он может уйти и сказать: "Так ребят я там завтра вернусь" Да Либо мы вот эту задачу возьмём либо вот эту задачу возьмём То есть ну там в зависимости от то есть берём сейчас вот так Если я возвращаюсь то мы выкидываем вот эту Берём вот эту Это всё про цель спринта опять же да может быть синхронизировано абсолютно спокойно но как бы приоритеты вот у этих двух задач То есть это это нормально С другой стороны э команда может сказать: "Блин мы не знаем как это технически реализовать" Да поэтому мы берём Ну есть такие задачи типа спайков они называются это вот задача на инвестицию вообще как это реализовать какими инструментами вообще возможно или невозможно да И тогда команда потом возвращается к владельцу продукта и тоже также говорит что ну сорян и тогда там да либо там в этот же спринт но тут вот редко уже да либо в следующий спринт О'кей потому что там и стоимость может быть такая что владелец скажет что вообще не надо Есть аналитики Вот кто такие аналитики Аналитики по сути это голос того же самого владельца продукта Там где владелец продукта недоступен это такой вот чит-код да по скраму А нет у нас допустим доступного владельца продукта который может там приходить к нам на планирование и быть с нами 247 Поэтому ему нужен прокси который будет с нами 24х7 И вот этими проксями являются как раз наши родные аналитики которые сидят у нас в командах И задача этих аналитиков по сути она вылетает из рамок спринта потому что они как проксивладельцы продукта должны прийти к нам на планирование и сказать что хочет владелец продукта и ответить нам на все наши вопросы Хорошо Но если не отвечают то как бы извините до следующей недели до следующего спринта Если не отвечают у тебя ситуация точно такая же Ты даёшь ему условно там день до конца дня То есть как ты работаешь с владельцем продукта также ты работаешь и с аналитиками И вот попытки впихнуть аналитиков разработчиков и тестировщиков в один спринт А слушай удавалось на самом деле вот э не мой опыт просто да ну видела так краем глаза Вот Но удавалось в одном единственном случае У остальных этого ни разу не получилось Особенно если особенно если команда требует что аналитики должны там написать документацию там какие-нибудь схемки составить ещё там и так далее и тому подобное То есть вот впихнуть в спринт это не получается Но кстати вот здесь я бы не сказала что это прямо нарушение потому что опять же да вот этот вот весь аst часть она выходит за рамки спринта То есть вот это вот вообще нужно нам эту фичу делать не нужно нам эту фичу делать а как она будет там архитектурные какие-то изыски и так далее С другой стороны если аналитики вдруг на стороне заказчика то это вообще ништяк Если архитектор у нас в команде да например и архитектор ещё нагружен какими-то задачами там а опять же там по разработке ну может быть да то у него получается часть работ в спринте а часть работ - это вот там вот с владельцем продукта и с аналитиком да выяснение вообще что что хотите-то да и зачем вам это надо можем мы это сделать или не можем Ну потому что архитектура - это тоже капстриму И получается что часть людей из команды они вроде одной ногой в спринте а другой ногой они вообще не в спринте Вот им наверное сложнее То есть не так сложно мне кажется работать в спринтах разработчикам и тестировщиком как аналитикам потому что вот здесь шаблоны у людей рвутся То есть с одной стороны вроде мы в команде да мы ходим там на те же самые дейлики ну потому что мы же часть команды да и вроде бы у нас спринт и это командный спринт а мы в команде но у нас-то вообще цель какая-то другая мы там сидим и что-то делаем Ну да шаблоны рвутся э но с этим просто нужно жить Это не про это не про неприменимость Скрама Он вот так работает Это та как бы его специфика которую тоже нужно понимать Ну тестировщики в конце спринта офигевают да На самом деле нет Опять же как построить тестирование Ну мы на самом деле я понимаю что очень много вопросов в смысле как построить вот это как построить то потому что очень много вещей из того что ты упомянул там например одна команда заблочена другой командой О'кей мы тут думаем типа о'кей типа это были независимые команды типа может быть если мы в часто упираемся мы что-то не так сделали там с нашей архитектурой глобально и как-то не так поделили почему у нас вот такие зависимости появляются Плюс ещё там вспомним какой-нибудь закон о конвее в котором ну как люди общаются вот как так архитектура у нас и сложилась Ну да Вот И как бы вот поэтому я не знаю мы конечно можем вынести архитектуру в обстримы типа вот какие-то магические люди там что-то решат до этого но я не знаю может быть у меня всегда был не такой э первоклассный э инженерный не знаю состав но всегда было такое: "А мы не можем все вопросы решить на планировании." Вот Либо мы должны очень прямо сильно упереться не знаю там пару дней потратить на resarch и тогда мы придём готовыми с вопросами по планированию Но тогда вопрос: а зачем так делать если мы можем уже просто если эта задача нужна давайте её просто сделаем Вот как как рождался канбан люди перестали задавать вопросы сколько это будет стоить Давайте просто это всё сделаем если это нужно Ну там вопрос ещё да как когда мы это сделаем да Ну когда мы это сделаем это может быть важным вопросом действительно Не знаю когда к нам как к стартапу приходит банк какой-нибудь там большой и говорит: "Когда Я не буду им затирать по про новымейтes про то как мы работаем Из с канбана им нужна будет дата" Да Смотри по поводу того что там можем не можем На самом деле вот я удивляюсь почему на самом деле в Скрамгайде этого нет Есть же такая тема как refinement очень хорошая штука И это периодическое пересматривание бэклога да и его пересматривать как по крайней мере опять же тут вот весь скрам блин это про то как мы организовали свою работу Если я тупо возьму скрамгай вот так вот по бумажке пойду у меня ничего не получится Для того чтобы запилить нормальный скрам мне нужно понимать базовый принцип управления проект проектного управления не продуктового а проектного да мне нужно понимать динамику команды образования при этом И мне нужно на самом деле очень хорошо понимать сам процесс разработки вообще из чего он состоит И если я вот это вот на собственной шкуре не почувствовала не испытала не прошла через все болячки возможные и невозможные да то никакой мне скрамгайд не поможет Ну слишком мало Всячески поддерживаю Описать в нём всё всё что нужно ни у кого сил не хватит Вот если б мы менеджеры вот это всё изучали возможно скрама было бы меньше Скрам говот не нужен был бы да Нам не потребовался бы скрам Слушай скран на самом деле бы потребовался я думаю всё-таки Ну потому что ценности там хорошие и там вот именно те ценности который очень часто не хватает и читает там тот же самый тамбук до седьмой версии буквально да а даже шестую в которой они приложением сделали вот такую тоненькую книжечку там А значит вот я его когда читала и думала: "Ну блин ребят ну вот у вас читал сам PMБО?" Нет не не представляешь что это такое Да нет я представляю что это такое но не читал Ну в общем вот условно там есть этапы да и у тебя вот входные бумажки на этап вот что-то происходит на этапе вот выходные бумажки с этапа и вот так вот всё расписано Ребят вот спасибо конечно за бумажки но мне это никакого понимания не даёт вообще как мне с командой-то жить да В седьмом ПМОке они прямо уже начали там и про каденции и про то как менеджер должен себя вести какие-то такие более этические моменты начали со задавать И я начала говорить о том что вот берёшь шестой ПЕМБ берёшь седьмой Пенбук читаешь оба и понимаешь вообще как надо управлять проектом Очень хорошие дополнение Шестая версия к седьмой версии Ну может быть они и не зря на самом деле сейчас объединились вот в конце года PMI и хотя там в общем вроде как с деньгами это связано то что там у кого-то денег э стало не хватать поэтому вынуждены были объединиться Посмотрим к чему это приведёт Тоже кстати интересно Так вот а значит э в продолжении что-то ещё хотела сказать Заговорилась про про то что скрам не работает Давай я пока накину Вот кстати вот а потому что из того что я услышал А подожди я вспомнила про про тестирование да протестирование я всё-таки хотела сказать а ещё один чит-код Почему это не больно Но я была тестировщиком и а я вижу когда люди приходят из там не с крамы да они такие: "Так ну сейчас значит мы вот эту историю протестировали эту протестировали это протестировали а нам на регресс надо в конце неделю из двухнедельного спринта" И опять вот тот же самый руководитель мой любимый когда я начинала работать я тоже пришла из Утерфола да и я говорю: "Ну вот а вот здесь у меня будет регресс" Он такой: "Нарегресс тебе на двухнедельный спринт 1 час без автоматизации" Я такая: "Э

То есть вот ну вот говорит мы делаем код фриз в начале последнего рабочего дня Там самый последний это у нас были там уже демо и ретроспектива Ну там начало дня потом демо ретроспектива" А вот предпоследнего получается да там условно если в пятницу заканчивали в четверг вот он говорит: "Вот тебе значит в начале этого дня 1 час" Такая: И на самом деле у Всё очень легко делается Просто регрессию нужно вносить в каждую историю И регресс нужен не полный как это привыкли делать э опять же многие тест-менеджеры которые не сильно привыкли экономить время ресурсы и задумываться об эффективности А регресс нужно проводить с умом Только то что может быть задето Угу Мне кажется тут как раз и и никакой боли да почти А мне кажется тут как раз затронуло важный момент который кажется очень часто делают такую ошибку что говорят: "Вот хорошо у нас крамка коден закончилась и вот здесь мы должны зарелизиться" Но вообще-то вы можете зарелизиться в начале в середине на 3/4 на 5/6 То есть вот вот вот эта вот блокировка на том что релиз в конце спринта это вот даёт такой удар просто по техническому ну вот состоянию того насколько разработчики думают про качество кода насколько вот все остальные процессы завязаны на вот эти вот каденции но вот почему-то мы попадаем вот в это ошибку что ну вот релиз в конце спринта да Нет релиз каждый день по пятницам вечером особенно Слушай ну смотри на самом деле да насчёт релиз в конце спринта я тут однажды столкнулась когда значит разговариваю там с разговаривала с коллегой сйл коучем тоже Я говорю прямо в Скрамгайде написано: потенциально готовый к поставке продукт должен быть в конце спринта такой: "Нет мы должны ставиться вот ну прямо вот вот вот чуть ли там не во время ретроспективы потому что вот у нас же деморетроспектива и мы" Я говорю: "Нет где это сказано?" В конце должен быть готовый продукт Я говорю: "Нет в Скрамгайде этого не сказано" И это опять же там да про коучи насколько они нам нужны Вот не нужен тот Agile коуч который не умеет читать чёрным по белому Неважно на каком языке: на своём родном русском на английском Может ему не понравилось то что написано белым по чёрному Если ему не понравилось значит он что-то не понимает в этой жизни Ну это же не Библия Ну да это не Библия Но на самом деле вот если задуматься опять же да у тебя проходит демо заказчик говорит: "Слушайте вот здесь вот на самом деле на кнопке шрифт не тот не критично абсолютно но глаз дёргаться будет у пользователей" Ребят мы вот с этим шрифтом ставиться не можем Всё работает всё идеально Ну и в итоге что мы признаём спринт неуспешным Ну наверное нет Наверное мы скажем: "О'кей давай мы там э в понедельник шрифт исправим в понедельник вечером выкатим" Хорошо если в понедельник вечером Не через не через спринт Ну ну не не через Ну тут слушай ну блин шрифт поправить я думаю что не критично Нет А если релизы раз в неделю У релизы ээ на самом деле у тебя команда уходит в себя То есть вот у тебя готово что-то к поставки вот до тех пор пока тебе отмашку не дали что мне это надо да Ээ куда-то ты сидишь и не дёргаешься У нас э мы ставили следующим образом То есть после демо например ну у нас потенциально готовый к поставке продукт Мы его проте был значит def environment тест envirймен потом интеграционная потом значит при для приёмки бизнесовое окружение потом пром уже Вот мы выкатывались тестировались на Да да мы тестировались на тесте Потом у нас значит регресс вот этот вот в конце э спринта уже был на интеграционном А и на нём же мы показывали демо Нам потом заказчик говорил что например там ребят э мы прошлую функциональность ещё не протестировали то есть мы спринт закрыли они ещё с прошлого спринта то есть вот 2 недели там 2 недели и они вот с тех двух недель ещё всё не протестировали То есть там ещё вообще на пром не ушло Они говорят: "Вот нам там ещё например там 3 дня нужно протестировать вот ту функциональность" То есть вот сегодня пятница давайте вы нам в среду на бизнесовое окружение выкатите вот вот эту вот вот эту версию а ту версию вы нам выкатите на про там ещё через условно 2 дня То есть поставки на разные окружения они могут ну идти в разное время Никто ж этому не мешает да Но вопрос не знаю тут опять же к этим дефиниition of Ну то есть команда разработки задачи сделана но она не на проме Оно ж Оно ж где оно где Она задача задача не закрыта Хорошо А если будет фидбэк мы опять вернёмся к этому То есть вот эти вот разрывы на самом деле вот длиной недели 2 недели это же всё всё что убивает вот все те процессы которые мы пытались сптимизировать Мы хотели поставляться быстро но мы поставляемся медленней О'кей мы можем понимать это быстро Ты поставляешься каждые 2 недели да А смотри то что ты сейчас говоришь а имеет место быть на самом деле смотря что тебе важно мы оптимизируем cycleта то есть это время от а момента начала разработки до момента завершения задачи Вот здесь definition of мы свою работу сделали Да но я бы сказала это скучно Мы её а мы её показали вам А у тебя же есть то есть вот то что ты говоришь там комментарии прилетят от заказчика да или от пользователя Мы ребят вам честно показали на демо всё как работает да Вот вот у нас были критерии приёмки ваша acceptтност критерия то есть то как должна работать эта функциональность мы вам показали вы попросили нас там ещё пару-тройку сценариев показать да помимо того что мы запланировали мы показали мы всё обсудили мы вам рассказали да вы сказали: "Всё ок всё норм всё ребят значит мы свою работу сделали" Ну по большому счёту вот наш definition of done и всё остальное да мы вам выкатим Вы можете найти ошибки Эти ошибки могут быть связаны как с конфигурацией окружения может быть может быть просто какие-то хотелки а проблемы там с данными конкретно на вашем окружении Хорошо ребят приходите к нам с обратной связью но уже в виде отдельных каких-то задач да в виде дефектов в виде там changeрекревестов в виде чего угодно Но суть в том что вот вы уже сказали своё око и вот здесь вот definition of И вот это вот по сути cycle time да То есть ну наша работа по задаче завершена Дальше для нас начинаются новые задачи Очень часто пытаются почему-то cycle time продлить до лит тайма который идёт как раз до момента поставки с вот он считается с момента создания задачи до момента поставки И это другое время абсолютно И вот здесь если cycle time мы можем сократить да за счёт того что мы на планировании все поняли что там как делать мы там друг с другом коммуницируем мы там друг другу помогаем да вот ещё что-то мы сокращаем cycle time атайм вот это вот начало хвоста это то пока из бэклок задача дойдёт до планирования до команды зависит от заказчика в том числе да как он там нам будет требования быстро объяснять ээ сколько раз он их менять будет в конце концов Вот И вот последний хвост он тоже в очень многом особенно в Энтерпрайсе он как раз зависит тоже от заказчика Сколько контуров нам надо пройти до этого 10 20 30 да сами мы ставимся да И вот здесь если мы хотим говорить про сокращение литайма его тоже можно уменьшить но нужно понимать что это уже опять же то есть вот cycle time - это работа с командой Вот чистый внутряк то как мы организовали свои процессы Leadта - это уже работа и с смежными командами и с заказчиком и с там инфраструктурщиками которые тоже да а может быть там вообще где-то ибшники у нас там появляются почему-то в хвосте вот этого процесса да вот то как мы вот это всё договариваемся И получается что да как раз бизнес он не всегда видит профит вот в этом моменте потому что мы про это вообще забываем Потому что возвращаясь в начало там да с чего я начала вы сейчас нам в командочках-то всё сделаете и у нас счастье-то будет Не будет ребят Ну не будет потому что тут ещё вот чего такое Но мне кажется да я смотрю я согласен про enterprise мир да это такая своя своя ипостась мне кажется Я смотрю э со своей призмы больше в сторону продуктовой разработки И мне кажется всегда будет гораздо интереснее мерить то время от того как мы получили первую информацию от клиента что вообще нам что-то надо от идеи до фидбка клиента по этой идее потому что кажется ровно это штука которая конвертируется в деньги А мы хотим деньги а мы хотим очень много денег Вот И поэтому а вот вот и lead time и cycle time вот это вот всё очень для нас важно но вот вот вот эта вот кажется штука вот там для например для продуктовой разработки например кажется очень критически важна Мы не знаем как её померить о'кей Но мы можем как-то попытаться и думать глобально о том что да конечно мы сокращаем все наши составляющие вот этого тайма но вообще-то говоря нам нужно бы делать вот долгосрочно вот этот цикл поменьше потому что краткосрочно-то мы можем что-то там быстро там на коленке нафигачить а как бы долгосрочно мы же хотим долгосрочный продукт Ну если хотим не долгосрочный другие правила На это есть ретроспектива на которой можно задуматься о том чтобы сделать долгосрочного По поводу продуктовой разработки Если это какой-то отдельный продукт или отдельные продукты независящие друг от друга тогда имеет смысл поточка конечно же Ну с у тебя зависимостей нет внешних То есть вот с в чём фишка Скрама ещё В том что он с одной стороны плохо с внешними зависимостями работает а с другой стороны наоборот хорошо типа устрани зависимости тогда начни работу Да Ну смотри то есть вот например продуктовики с которыми я встречалась то есть у них было прямо два продукта Одна команда компания оно делала два разных продукта Первый - это про конвертирование видео видеоконвертер у них был там то есть даунлоудер на сайте и так далее А второе то что они делали - это плеер для телефонов проигрывание музыки там затягивание с Ютуба видео вот вот эту вот историю Абсолютно два разных продукта никак не связанные между собой И в общем-то ничего им не мешало И они очень успешно кстати вот по поточке работали Они там прямо раскуривали очень долго лин смотрели там на все эти вейсты что как убирали вообще полностью все вейсты практически И ребята очень классные Мне прямо очень это радостно было с ними тоже сотрудничать Вот А с другой стороны даже если ты в продуктовая компания да и у тебя есть несколько связанных продуктов которым вот кровь из носа релизится нужно вместе и ты понимаешь что архитектура вот она и должна быть такой да то есть ты не можешь её ну никак растащить Ну не знаю бывают такие случаи Знаю не уверен Вот Ну сейчас э сейчас например у меня одна из компаний с которыми я там общалась да у них сейчас есть несколько разных продуктов и они говорят: "А нам для того чтобы соответствовать там определённым каким-то требованиям там стандартов российских законодательств ещё чего-то нужно чтобы это был единый продукт." Вот И раньше мы работали вот маленькими командочками у нас было счастье а сейчас мы такие: "Блин нам надо это всё сынтегрировать нам надо это всё объединить и нужно синхронизировать команды." И вот здесь как раз вот этот вот масштабированный скрам да лесы всякие там сейфы нексусы и так далее и так далее Потому что если каждая команда будет работать в поточке ну ребята замучаются Особенно если ещё и скорость нарастить что там несколько чекинов в день да и не дай бог к релизу готовый продукт каждый день да Ну вот по крайней мере у тех ребят вот с которыми я работала да которые в поточке работали они реально релизились каждый день А вот теперь представь что у тебя там здоровый продукт и каждая команда что-то каждый день делает Ну а тебе это надо р собрать себе ну замучаешься Поэтому вот там да там скрам Других вариантов именно масштабирования Почему скрам Ну скрам именно масштабированный да То есть тут уже неважно там какой именно там safe lessт и так далее Вот А но почему скрам Потому что опять же ну он наиболее подходит вот к этому масштабированию А большие проекты из нескольких продуктов масштабировать без того же самого скрама их сложнее То есть там всё равно начинается бардак Без скрама именно опять же с точки зрения не только там ивентов и так далее да но ещё и с точки зрения ценностей Если в одном проекте у нас бардак он будет тянуть вообще всё что угодно Поэтому прозрачность у всех должна быть одинаковая там интенсивность одинаковая правила одинаковые и так далее и тому подобное Можно мне ценности без всего остального Заверните пожалуйста заверните пожалуйста мне ценности без всего остального А чем тебе всё остальное это не нравится Всё остальное - это один из вариантов реализации принципов принципов эмпирического процесса разработки То есть э зачем нужен эмпирический процесс Ну потому что всё меняется Это это опять же вот про гибкость про ту же самую но тебе нужно как-то подстраиваться под ситуацию И мы берём что да мы считаем что мы умеем подстраиваться под ситуацию когда мы понимаем что у нас происходит когда мы регулярно смотрим на это и когда мы регулярно адаптируем Хорошо Вот Вот вообще ни с этим ни с одним из этих не спорю Ну так а все ивенты про это Все ивенты Скрама они про это Понимаешь Дели скрам Мы смотрим на доску понимаем что у нас происходит Если мы понимаем что кому-то нужна помощь у кого-то какая-то задача зависла да а или мы где-то не успеваем где-то нужно там немножко поднажать вот мы посмотрели вот мы проинспектировали вот мы садаптировали свои действия на ближайшие 24 часа Вот тебе дейли пожалуйста Отлично А если это в конце дня блокировка произошла то мы не ждём следующего дня Мы не ждём Дейли чтобы сказать что у нас есть проблема Нет мы ждём Мы прокоммуницировали раньше А если мы прокоммуницировали раньше что у нас есть проблема а зачем нам тогда специальная Деля для этого С ты говоришь про блокеры Я говорю не совсем про блокеры Вот ты сидишь и мучаешься день и у тебя не получается Вот ты пришёл на Дели говоришь: "Ребят вот у меня не получается У тебя у тебя ещё вагон мыслей как это можно попробовать?" Конечно То есть для тебя для тебя это норма Ты день промучился ты ещё 3 дня на это убьёшь Тебе в радость ты там сидишь что-то изучаешь понимаешь Но ты приходишь в команду говоришь: "Ребят вот я за вчера ничего не сделал но я блин столько всего там узнал я столько всего прочитал" и тебя команда такая: "Подожди-ка" Угу Давай сделать давай сядем вместе Да Вот вот про это понимаешь Или там тестировщики например тебе говорят что ребят мы думали что мы успеем но у нас вчера возник блокер один второй третий и мы из-за этого потеряли кучу времени Мы понимаем что мы не успеваем протестировать Есть кто-нибудь кто может нам помочь там не знаю аналитик какой-нибудь да скажет: "Да я готов помочь" То есть блокер - это ты решаешь если у тебя блокер ты его решаешь по факту Понятно что ну как бы ну было бы странно если бы ты сидел и блокер ждал на следующего делика да Но последствия этого блокера они могут быть таковы что их всё равно ещё решать нужно будет И вот это уже ждёт Делика вполне себе И ты это делаешь Планирование ну про то же самое Ты посмотрел что у тебя было сделано там на демо на ретроспективе запланировал половина спринта переехала на новый спринт Вот если половина спринта переехала на новый спринт значит вы опять не умеете его готовить Да мы плохо оцениваем Мы плохо оцениваем И вот вопрос вот типа нам нужно пинать разработчиков Ну ладно не пинать ведь это же пинать пинать пинать А вот сказали что м вот когда привлетает что-то внезапное но типа у нас нервозность Не знаю у меня нервозность была когда я у нас была без храма когда я не успевал что-то сделать к концу недели И это было каждую неделю И я такой: "Господи что со мной не так Я плохо планирую я уже на три умножаю а оно всё равно не работает И вот вот вот нет вот этого иногда щелчка типа а вот а что действительно нужно делать Вот типа я плохой инженер и мне нужно лучше или нет давайте мы будем делать Planн Pocker и тогда типа это будет всё совместно типа вот коллективное размазывание а оценки Или вот мы скажем: "О'кей ну мы работаем по-другому Мы думаем про то как быть быстрее но мы не пинаем себя за то что мы как бы опоздали должны были в пятницу а сделали в понедельник потому что это всё равно надо Это всё равно надо до тех пор пока тебя сроки не спрашивают Смотри сам Бичевани точно не поможет Э плохой разработчик или неплохой а можно думать бесконечно Планинг покер тоже ведь может не помочь на самом деле Это не панацея Ты можешь оценивать хоть в хоть в сторипоинтах хоть в человека часах Что нам делать лучше чтобы попадать в спринт Вот я не знаю Это прям термин респектипективу про провести Ага Прямо вот провести ретроспективы Я как раз тут у себя в канале планировала пост на тему "Скрам не работает" И вот этот пост такой спойлер Я тебе подкину идеи Да Да Но сейчас заспойлерю Пост будет про то что как раз вот скрам не работает Ребят проведите ретроспективу если у вас скрам не работает Ретроспектива - это один из ивентов скрама Вы часто говорят что у нас ретроспектива не работает Ой скрам не работает Ретроспектива вообще отстой Но скрам у нас не работает Блин проведите ретроспективу разберитесь Слушай что сделать Ну давай я могу конечно сейчас там за хрустальным шаром сходить да А прикинуться коучинг который вот так вот сразу решит все проблемы просто да такую таблетку даст Нет панацея Но если у вас это из раза в раз из раза в раз но тогда имеет смысл вот что точно да Это посмотреть если у вас есть какие-то там оценки если это на самом деле болит да то посмотреть где вы не укладываетесь по каким причинам Может быть вы начнёте с того что хотя бы комментарии писать начнёте чтобы анализ провести Всё так Всё так В смысле мы не можем выписывать диагноз без того как бы ну мы как как-то какие-то симптомы должны понять да Я могу сказать решение но оценивайте в сторипоинтах Ну я я же как бы я вот сейчас тебе сказала я ушла что с меня как бы взятки гладки да Да Люди потом 2 месяца мучились такие маечки выбирали да И и я про это и говорю что плох тот скрамастер плох тот Джайл Коуч который просто приходит в команду и такой: "О скрам нет не не будет так работать" Ну потому что сначала разобраться надо да И прежде чем вот это вот всё внедрять то есть пример опять же из моей практики был: руководство хотелось скра Ну о'кей хорошо могу умею практикую Пришла я в команду Команда 40 человек Ну ладно сейчас попилим сделаем масштабированный на маленьком участочке да там будет две три-четыре команды Ну сколько получится всё будет хорошо Я посмотрела на людей и поняла что там люди работают на проекте Кто кто 10% кто 20% кто 30 в лучшем случае 70 Я говорю: "Ну о'кей хорошо А скрам нужно везде" Я говорю: "Хорошо на всех проектах нужно скрам да вот на которых вот эти вот люди работают" Он говорит: "Да" Я говорю: "Хорошо 10% человек занят на 10ти проектах 15 минут в день человек будет на скрамах Человек работать будет человек работать не будет" То есть прежде чем вообще что-то начинать да нужно понять вообще с чем мы имеем дело Это уже становится третьим вопросом вообще нужен нам скрам или не нужен Потому что если мы за счёт скрама хотели получить эффективность какую-то а может быть нам просто людей заосайнить полностью на проекты и это даст уже фокусировку людей это даст уже концентрацию их и может быть этой производительности будет достаточно Ну как бы вот Ну да давайте просто вот тупо что видим везде скрам внедрять Ну нет я против такого подхода Категорически против такого подхода Ну я бы добавил то же самое про менеджеров И как бы не только Джал Коуч и скраммастера внедряют скрам ещё и мы иногда приходим То есть это про всех Это про всех Всем привет Всем менеджерам Ну вообще да Если ты прочитала скрамгайд но не понимаешь принцип проектного управления у тебя не получится Помимо скрама тебе всё равно нужно управление рисками Метрики которые предлагаются стандартно идущие вот так вот в комплекте с Скрам это вот burnчарt Они тебе мало чем помогут Ну они помогут но тебе ещё нужно кучу метрик И ты должен разбираться в метриках Ты должен понимать что у тебя с командой происходит Ты должен понимать в принципе ээ там как команду организовывать да Если ты этого не понимаешь блин ну ну не суйся лучше наверное И тут неважно уже на самом деле что ты делаешь Скрам не скрам у тебя всё равно выйдет примерно одно и то же От чего люди будут страдать Что-то выйдет Как-то наша индустрия всё-таки живёт но так в тумане В тумане Вот это просто к тому что я опять возвращаюсь А да я могу говорить там Ажаile Коучани нужны или что скраму нужен вот достаточно дорогой специалист который должен знать не только Скрам Привет Всем обучаться Всем менеджерам обучаться Всем сеньорам переходящим в менеджеры обучаться Да наверное да Всё это было к тому что так как Маша упомянула много чего что нужно читать что добавляет опять к тому что нам нужен какой-то очень высококлассный специалист который может быть менеджером может быть коучем который много чего прочитал и про командоо образование и про риски и про projectт-менеджмент и продакт-менеджмент и много чего И да нам нужно такое образование которое когда мы становимся менеджерами мы становимся ими из синьоров Ну да при этом выделенные менеджеры не нужны айлile coучи не нужны никто не нужен но как-то нужно обучиться Вот я сейчас просто думаю а на самом деле вот мы много на самом деле что проговорили А что люди из это вынесут Да давай я наверное то то что точно должны люди вынести менеджеры коучи крамастера должны не только понимать знать многое но и опыт иметь в этом Ну потому что много в книжках ведь тоже чего не написано И то что я говорила да пройти через свою боль Скрам вот просто потому что вы хотите скрам не надо делать не надо не надо Скрам - это фреймворк который всё-таки нужно выбирать осознанно Не просто потому что я знаю я слышал да А почему именно он Потому что может быть даже и не он да Может быть просто итеративности там А то есть нужно ли вам на самом деле соблюдать все правила скрана есть определённые риски с их несоблюдением но в вашем случае может быть профиты от экономии на чём-то будут гораздо больше чем те риски которые вы понесёте А можно я одну вставку добавлю Давай Единственную логическую которая как будто бы здесь есть логическое несоответствие либо с этим надо разобраться А в какой-то сначала все такие скрам методология методология да в какой-то момент скрам - это фреймворк Фреймворк фреймворк да И и там есть набор базовых э блоков которые гибкие которые можно соединять и мы получаем систему под нас И знаешь что я заметил Вот во время разговора было: "А вы если вот это не используете ну тогда не называйте это скрамом Если вы так не делаете не называйте это скрамом" То есть я как бы в процессе не очень понял а то есть где вот эта вот история что вот это разрешено менять и это всё равно остаётся с крамом Это и является той частью которая является фреймворком А вот это вот нельзя менять И тогда если мы поменяли тогда у нас не скрам А вот это в скрамгайде как раз Смотри если например ты говоришь что мы например работаем итерациями да ну вот там с той же самой разработкой но у нас постоянно какие-то влетают задачи и мы их впихиваем что-то выпихиваем что-то впихиваем да но это прямо прямое нарушение того что у тебя скрам этот самый спринт извиняюсь фризится да и по сути у тебя задачи могут меняться только в рамках цели спринта Опять же то есть если это к цели не относится то ну маловероятно Если у тебя постоянная свистоплякой ты понимаешь что это надо но ты работаешь почему-то итерациями 2 недели ну 3 недели неделю без разницы вообще да ну не говори что это скрам Ну потому что ты нарушаешь одно из базовых его требований Если например у тебя нет готового инкремента ну вот ты работаешь но у тебя есть например там планирование да у тебя есть там ретроспективы ты проводишь раз в неделю но у тебя нет готового инкремента да в конце спринта Ну не называй ты это скрамом да ты молодец ты всё ещё лежишь в сторону этих самых прозрачности инспекции адаптации вот этого эмпирического процесса и так далее да Но но это не скрам ведь ну блин не скрамом единым жив человек Очень много очень много адаптаций существует И вот это вот а скрам Но ребят либо скрам либо не скрам Никто же вам не мешает взять прочитать скрамгайд сказать: "О глядите вот это нам подходит вот это нам подходит вот это нам подходит а вот это к сожалению нам не подходит" Потому что потому что потому что не потому что мы сделать сейчас не можем или потому что мы там лень да или там мы ну не понимаем а потому что реально у нас есть адекватное объяснение почему нам это не подходит в нашей ситуации Да возьмите пожалуйста кусок из него но не называйте это скрамом Зачем Ну ну давайте глядите одна из ценностей скрама честность Давайте будем честны с собой Если мы нарушаем что-то базовое из скрам гайда у нас не скрам Давайте говорить об этом честно Угу Нужно ли нам выдерживать полностью скрам Это вопрос очень хороший потому что очень много казалось бы девять страниц Ну что там можно девять страниц причём первая продажная последняя по-моему спасибошная Что там на девяти страницах можно описать Да там вон PMБО - это 1.000 страниц а там на самом деле столько написано что ты пока внедряешь ты понимаешь что блин ну это реально тяжело в определённых условиях И когда начнём быть честными сами собой может быть перестанет вот это вот натягивание СВ на глобус быть Да вот эта идея у ребят хорошая а вот эта идея у ребят нам не подходит Ну хорошо давайте придумаем что-то своё Всё Вот в этом же и вопрос Вот у нас одна часть случаев неправильного внедрения другая часть внедрения там где не надо Вот если так тяжело ну зачем Скрам Вот если он так тяжело внедряется почему скром Знаешь не каждый лёгкий путь на самом деле ведёт нас к цели О ну это же как Вы знаете вы всё делаете неправильно Вам нужен грамотный специалист Вот чтобы вот делать вот это Я я не говорю что нужен грамотный специалист Я говорю о том что нужно голову включать Это может быть не один специалист да Это это не команда слуша руководство Мы знаем мы не знаем чего мы не знаем Хорошо ну тогда пробуйте Но тогда говорите что о'кей мы вот нам вот мы посидели мы подумали нам понравилось мы хотим мы там слышали успешные какие-то кейсы мы хотим попробовать Давайте начнём пробовать начните с малого Что взлетит то взлетит что не взлетит то не взлетит Эксперименты инспекции адаптация Да да да Те же самые эксперименты инспекции адаптация И к чему вы придёте к тому вы придёте у вас будет какой-то свой процесс и вы уже будете молодцы Скрам почему хорош Потому что на самом деле он он тяжёлый да но там есть как бы уже понятные определённые вещи что делай 1 2три и у тебя должно получиться Если ты понимаешь суть этих 1 2три и понимаешь как оно должно работать то у тебя получится Вот вопрос в том что мало кто на самом деле это понимает И меня например пугают люди которые такие: "Я сейчас вам внедрю скрам я сейчас вам внедрю" Но я ни разу сам ни в скраме ни в любой ни в любом другом там а не знаю там фреймворке подходе процессе соответствующему не работал Вот такие люди меня реально пугают И я догадываюсь что таких людей очень много на рынке Потому что если ты сам на эти грабли не наступил вот эти вот все иджайльные скрамные как канбановские да ты не понимаешь где их обходить и ты как раз получишься вот тем человеком который взял скрамгайд и пошёл в тупую его реализовывать И вот тогда скрам не работает Только через опыт через больно прийти Ну на самом деле всё так всё так Вы можете сказать что да ребят мы хотим скрам Не ставьте себе это той целью ради которой нужно умирать Вот единственное что Да не надо ставить целью которую ради которой вы готовы ээ прямо вот всё там вся команда полегла зато внедрили Да да не факт понимаешь О'кей хорошо Мы хотим попробовать Да начните с дейликов Ну просто да хорошо Вот они у вас проходят Это статус для руководителя проекта или всё-таки это синхронизация Даже вот в этих вот мелочах оно прямо очень сильно различается когда команда говорит в одного человека да то есть я делал это я планирую сделать это проблем нет И когда команда начинает коммуницировать между собой это даже ощущается по-другому Когда поймёте что да вот мы хотим вот этого о'кей не работает хорошо давайте не называйте может быть это ретроспективой давайте соберёмся обсудим Вот у нас что-то вот мы делики попробовали что-то не нравится Просто проведите их там 2 недели 3 недели но попробуйте соберите возьмите одного человека который скажет: "Хорошо я вот готов да а я там почитал я посмотрел я плюс-минус понимаю как это надо" Спрашиваете обратную связь у команды ребят Вам как Зашибись Вы всё равно вы рано или вы рано или поздно доведёте до того что у вас будут адекватные дейки Да я вот в этом как раз не сомневаюсь Я не волнуюсь когда сильная команда выбрала себе скрам и стала его использовать Вот села потому что вот они сегодня выбрали скрам через год у них хватит саморефлексии выбрать что-то другое или более подходящее им Вот я волнуюсь за всех остальных кому внедрили Ну я вот сейчас накину на другую тему Вот я бы сказал что вот я сейчас о'кей я сейчас э в европейском рынке я наблюдаю угасание интереса к скраму Я просто вижу в в Линкине как одна конференция отменилась по скраму другая конференция отменилась по скраму Другой мой знакомый из Ажайл Коучи приехал и говорит что от там в Индии была большая конференция все просто в панике потому что это как будто бы прощальная конференция по скраму и больше никогда никакой не будет Почему Слушай может быть это связано с тем я не знаю на самом деле потому что я не из Европы я сижу в России да У нас тут интерес не пропадает Может быть в конце концов много говорили уже наговорились Ну хватит Это первый момент да Второй момент может быть это как-то связано с тем что PM и JILЙ объединились вот как раз в конце года двадцать четвёртого и там что-то происходит То есть в самом сообществе чего ну по крайней мере я не вижу да я там не состою вот вот в этих вот топовых прямо сообществах поэтому там по-любому какие-то движухи есть Что там происходит непонятно Может из-за этого может быть на самом деле уже просто приелась и ну хватит об этом говорить да Может быть казалось бы девять девять страниц Ну ну ну хватит уже Ну ну сколько лет уже Да да да На самом деле не взлетает Обговорили много чего что как бы там где может не взлетать что может не так Понятно как бы Вот мне кажется с одной стороны я вижу снизу со стороны разработчиков каждый первый разработчик мне говорит что он работает по аджайлу или скраму Я такой: "Ладно хорошо ну своя какая-то субъективная выборка" Вот с другой стороны действительно кажется что ну может быть действительно наигрались непонятно что другое потому что ну как канбан я сказать не могу а что тогда ещё И вот это становится интересным как бы ну пока нет на это ответа но вот просто вот какая-то вот такая информация что-то как будто бы становится менее интересным меньше людей участвуют меньше людей может подают заявок меньше билетов подаётся Ну что-то угасает Может быть нет Может на самом деле очень популярно в Америке Может быть Ещ ещё сейчас о чём подумала о том что на самом деле эта тема может загнуться ну вот честно абсолютно спокойно может загнуться потому что очень много интерпретаций разных да и вот э как я говорила не каждый даже способен насилить эти девять страниц То есть вот ты читаешь внимательно но каждое слово аккуратно внимательно читаешь просто вдумываешься в смысл думаешь: "А почему так А зачем это?" Да не каждый способен И вот эти вот начинается скрам но и их же вот этих скрам но очень много А потом в итоге у нас скрам но но мы продолбали какую-то основную часть и мы ну просто её продолбали да Мы даже не подумали о рисках мы не подумали о последствиях мы просто вот ну вот у нас вот так вот исторически сложилось В итоге кризис в итоге не взлетел в итоге там какая-то проблема всё скрам не работает Идея была хорошая реализация подвела И вот этих вот реализаций которые подводят видимо достаточно много поэтому может быть и веры в скрам мало Я на самом деле вижу отдельные там команды отдельные компании в которых на самом деле это работает зарубежные ачественных меньше в разы меньше Но так или иначе скрам вот именно прям ну такой прямо хороший скрам да без всяких вот этих вот Но а он работает И там где он работает людям приятно работать И людям приятно работать и кризисов на проектах меньше Результативность тоже есть У меня вот та компания в которой мы работали про которую я изначально рассказывала у нас несмотря на то что там было много людей и в общем-то мы особо так никогда вот там не дружили не общались то есть не было такого что у нас там какая-то культура прямо такая дружелюбность Ну то есть понятно что мы общались мы там друг друга знали мы работали да там внутри проекта общались Мы э- уже который год лет пять наверное после того как кто-то начал уходить из компании там в девятнадцатом году мы начали уходить из неё на там потому что в общем ну свои ээ моменты произошли и потихоньку компания начала разваливаться Никак не связано со скрамом если что Вот получается 5 лет уже регулярно с ребятами встречаемся и очень хорошие отношения И это вот я считаю что благодаря тому как мы работали несмотря на то что мы работали в разных проектах Я например опять же за счёт э не полностью выстроенного скрама даже да но за счёт того что я внедряла какие-то практики я из кризиса проекта вытаскивала То есть вот я приходила на проект бардак в бэклоге я такая: "О'кей хорошо организовываем бэклог начинаем его приоритизировать начинаем его громить начинаем планировать на спринты" Да тоже сначала там с ошибками планировали но начинаем работать с заказчиком вовлекаем заказчика в это начинаем звать на планирование заказчика начинаем демо проводить нормальные Не когда приходил там до меня руководитель он просто презенташку показывал что глядите аналитики сделали вот это разработчики сделали вот это а тестировщики сделали вот это Это в скрайме Ну то есть как бы аналитики сделали кусок одной какой-то задачи разработчики сделали кусок какой-то другой задачи тестировщики дотестировали наконец-то то что разработчики 3 месяца назад разработали Это вот у них скрам такой был Фу тормоза Вот я говорю: "Ребята нет так дело не пойдёт Давайте-ка мы за 2 недели" Ну там заказчик попросил говорит: "Раз 2 недели можете поставлять?" Я говорю: "Мы можем а вы успеете за нами" В общем в итоге вот заказчик не совсем стал за нами успевать Вот Но проект был выведен из кризиса да То есть то что я там успела внедрить это демо честная прямо У меня там команда в шоке была когда я сказала: "Так ребята вот ту функциональность которую вы сделали вы показываете заказчику в конце этого спринта А всё так можно было Будете показывать в конце этого спринта" Да такие: "Как в смысле?" Я говорю: "Ну вот так они там: "А давай там ну ладно давай автотесты напишем там ещё что-то ещё что-то" Первое было стрессовое но когда э заказчик увидел ну бомбически на самом деле было И это же ещё отличная сори обратная связь то что как бы разработчики видят довольного заказчика или какие-то комментарии даже если там какие-то ну там не ошибки недоработки какие-то идеи а они такие: "Вау супер заряженные поехали вперёд" Да да Заказчик до этого вообще кричал что блин я вообще не понимаю что вы тут делаете Там 6 месяцев ему не могли ничего не по не 6 месяцев ему вообще ничего не показывали Релиз не могли выкатить То есть там ну реально там чуть ли не до разрыва контракта дело доходил Очень сложные отношения были Ребята начали показывать И дело в том что заказчик как оказалось потом это вот там про метрики про управление да что заказчик мы много дефектов заводим Я говорю: "Хорошо но там порядка 30-40% что ли которые они заводили говорят: "Вообще не дефекты" Это ваши аналитики которые тестируют наш продукт не понимают как он должен работать ребят И за счёт демача подтягивать знания аналитиков У заказчика дефектов стало меньше У нас команда разгрузилась ещё и с дефектами да потому что их не надо разработчиком сидеть читать воспроизводить там анализировать вообще сидеть и думать: "А это дефект а не дефект а почему это дефект?" В общем это было классно Второй проект тоже вроде бы был про Скрам но это вот опять же там я говорю: "Почему-то нет блин бклок рефаймента в Скрамгайде" Я очень переживаю за эту тему негодую Очень полезная штука на самом деле Рекомендую как вишенку на то Я был счастлив если бы после 90 дней тикеты просто бы исчезали потому что если мы их не сделали значит уже никому не нужно Не везде так на самом деле У вас может быть но это может инструмент можно настроить Вот И второй - это у меня проект должен был выйти на новый рынок Не могли сделать MVP вовремя Ну в чём проблема В том что люди делали просто что-то Вот я вижу задачку в бэклоге вот я её возьму Вот я вижу задачку я её возьму Но там с бэклогом было лучше То есть мы его устаканили приоритизировали начали проводить планирование поняли после буквально там первых двух спринтов сколько нам ещё людей не хватает Нашли людей которые быстро смогли погрузиться в проект Благо такие нашлись Там буквально два человека не на много времени взяли Там то ли на неделю то ли на две взяли двоих То есть там не вот большой не вот критическое отставание было а выглядело так что вообще всё мы ничего не успеваем потому что там в бэклоге ребята брали просто вот из бэклога Ну есть и есть да А они брали а это вообще не MVP это вообще там не надо или ещё что-то Тоже вроде как по скраму работали вот до меня То есть понимаешь и там скрам и тут скрам но не скрам но называется скрамом И вот смотришь на такие моменты и думаешь: "Так ну конечно блин вы не будете в это верить Конечно вы в этом будете разочарованы потому что ну это не скрам но но вы это так называете Вот От таких случаев конечно печаль да И вот получается как бы не хватает получается человека который ну что-то понимает эээ ну в теме что-то понимает в разработке о том что ну ребят нужно что-то приоритизировать знаете иногда можно синхронизироваться Уж будем ли это делать мы на деликах не на деликах это мы можем о'кей разобраться потом Вот Но показывать демо получать обратную связь О а что Неужели такие циклы обратной связи работают Да правда работают но нужно же делать И нужно просто чтобы кто-то пришёл и сказал: "И будет ли это скрам или как мы?" Не скрам это уже не так важно Вот Вот здесь понимаешь здесь скорее всего эли ну вот за исключением там отдельных случаев да я на самом деле редко сталкивалась когда нужно вот это но То есть я если по уму всё делать редко нужно вот это добавление но к скраму То есть он если его прямо аккуратно хорошо сделать без всяких вот отступлений он будет работать Он гарантированно будет работать Но опять же да а если он подходит к ситуации если это вот не не вот это вот наше любимое огромное количество сопровождение да если у нас там руководство к этому готово и все понимают вообще чем это может оукнуться если мы готовы э на самом деле скрам внедрять не только в одной команде а ещё и во всех созависимых командах Если мы готовы работать с заказчиком он будет работать и от него будет профит Ну я говорю кризисы кризисные проекты выруливала за счёт даже вот просто начинания да он будет он даст огромный профит но это нужно делать всё грамотно Они так что мы назвали скрамом вот у нас есть бэклок вот ребят берите работаем с принтами 2 недели Ну блин какой-то скрам Если неделя то быстрее да Если неделя то быстрее Зафакапим конечно Вот заказчик был уверен что это скрам Ну скрам же Ну баклок же есть Джира Вот ещё скрам - это джира У нас есть джир значит у нас скрам Нет печалька ребят Джира - это вообще не скрам Джира - это инструмент который хоть скрам хоть не скрам вообще без разницы Угу Вот такие вот убеждённости что именно то есть вот у нас есть роль владельца продукта Давайте так Нет скажу нет У нас есть человек который называется владельцем продукта Ну потому что роль - это не несёт под собой ещё заодно и выполнение ролевых обязанностей да Вот А у нас есть человек которого мы называем владельцем продукта У нас есть команда значит неважно там есть скрамастер нет скрамастера да и бог бы с ним А у нас есть продукт бклок причём приоритизированный или не приоритизированный Насколько там вообще это продукт бклок и бэклок ли это вообще Непонятно Да мы работаем двухнедельными итерациями Мы с заказчиком созваниваемся каждый день что-то смотрим на доску кто-то что-то говорит мы в конце рассказываем заказчику что мы сделали Ну и фоточками там обмениваемся кто как неделю провёл Ну вот так и живём Нет не скра Нет не работает Чёрт звучало хорошо Я уже подумал что Да я уже подумал что мы обсуждаем как правильно как просто как всё как всё правильно сделать Но мы обсудили до этого что нужно вчитываться Нужно вчитываться что там написано На самом деле нужен владелец продукта И на демо нужно показывать не презентажки и и не отчёты как это тоже бывает Значит приходишь на демо и э ни команды ничего Руководитель проекта Мы за 2 недели проделали и пошёл как это отчёт значит там не знаю президенту или кому угодно там как перед защитой перед комиссией да Мы сделали 1 2 3 4 5 6 7 8 9 10 Мы молодцы Всё демо прошло Отлично Спасибо до свидания Ну вот да получается как бы вот не ловится вот эта идея То есть зачем мы это делаем Вот как бы как легко выбесить человека Вот человек же легко выбешивается уже на третий вопрос Почему там про пять мы как бы уже не говорим там просто на третьем уже хватает Ну вот зачем Для того чтобы быть более структурированными И смотри есть правила которые точно работают Мы хотим быть более эффективными мы хотим быть более продуктивными мы хотим получать лучшую связь обратную связь вот то что я в начале говорила да обратную связь от пользователей Мы хотим наладить взаимоотношения с заказчиком Мы можем либо тыкаться куда-то сами да ну и проверять сюда не сюда сюда не сюда в лабиринте идти Либо мы можем сказать что глядите у нас есть вот скрамгайд который точно работает если его грамотно внедрить и он нам подходит Вот тогда я бы лично предпочла пойти по скрамгайду Если я понимаю что скрам не работает а у меня та же самая задача эффективность довольные пользователи довольный заказчик да топом там сказать что там ещё маржинальность повысить ещё что-то вот это вот всё управляемость и так далее Я бы взяла из него наверное что-то всё-таки То есть всё равно были бы ретроспективы всё равно я бы стала внедрять там демо да Может быть я бы не стала делать дей Мы не знаем надо посмотреть надо посмотреть анализ Ну кстати что просто что интересно я с тобой не спорил Я с тобой не спорил Я задавал вопрос ему Зачем это было Это было в поддержку Это было в поддержку Типа мы спрашиваем людей то есть типа если они вот делают демо как отчёт или какие-то ещё вещи зачем Да чтобы что Зачем И вот я говорю вот как бы с третьего вопроса чтобы что как бы ну как бы любой человек начнёт беситься нормальный или со второго То что что ты ко мне пристаёшь Кто ты вообще такой Почему ты такой токсичный Ещё вопросы спрашиваешь Да кстати страшно знаешь что вот здесь а мне кажется это смена парадигмы на вот эту вот открытость и честность Потому что вот опять же возвращаясь к ценностям почему Скрам без ценности не работает Потому что а я могу сделать я могу э поделать практически любые метрики Они будут но они будут отображать ту картину которая мне там нужна как руководителю как тимледу ещё как кому угодно да И если опять же там с меня что-то спрашивают я могу в принципе любой результат ну выдать тот который мне нужно И открытости люди боятся потому что даже со стороны инженеров вот сидел какой-нибудь там я не знаю Евпатий сидел и ничего не делал Тихонечко Команда 30 человек за всеми ну не уследишь Ну сидит там что-то делает время от времени какой-то результат выдаёт Теперь представь вот этот 30 поделили наче И теперь Евпати перед всей командой каждый день говорит что он сделал И если он что-то не сделал то команда такая: "Тебе помочь?" И в патии что приходится Приходится теперь работать А и в патии за 10 лет работы вот без этого всего он не привык работать Угу Становится некомфортно Руководители а например там или команды а есть же вот это вот я хочу быть самым хорошим да Я медалист я отличник Вот этот вот синдром отличника прямо э очень сильно тоже мешает когда а ты говоришь: "Ну если у вас не получилось вот спринт идёт идёт вот так вот просто ровно ровно ровно ровно в конце спринта всё закрыли" Ты говоришь: "А как так?" Ну то есть это же проблема на самом деле потому что у вас э там неравномерно закрывает задача Это скорее всего там перегруз на тестирование как раз да вот ну если в конце одним днём всё закрывается либо что а там просто закрыли задачи а создали новые То есть задача-то не сделана а новые создали но спринт вроде закрыт да Ну хорошо же да И когда начинаешь внедрять скрам очень много вот таких вот всяких подделок И это всё вскрывается Кстати это я по-моему э пролес когда читала вот вычитала в книжке там есть пример такой что скрам - это камни на дне озера Сейчас я вот точно не скажу но суть в чём что если ты работаешь по там классической модели то озеро глубокое и ты эти камни не видишь А что делает скрам Он начинает убирать в общем-то там э всё лишнее по большому счёту оставляет только то что нужно и озеро начинает мельчать И в какой-то определённый момент начинают появляться самые крупные камни из-под воды Ты начинаешь их видеть и ты их начинаешь вычищать Озеро всё ещё продолжает мельчать мельчать мельчать и у тебя появляются менее крупные камни потом ещё менее крупные И вот появление вот этих камней - это на самом деле страшно Поэтому в эту историю и никто и не идёт потому что если сделать скрам вот так как он задумывался там будет видно абсолютно всё Но его так опять же не делают Потому что страшно Ну вот я даже бы может быть волновался о'кей не за тех людей которые там что-то ничего не делали а тут теперь всё вскроется потому что я видел ну кучу примеров когда это ну такой непростой опыт даже когда ты честно пытаешься ты честно пытаешься и может быть действительно правда правда вот сидром отличника и вот признать о'кей что а я что-то не могу Э но вот я всё время вот э вот это вот мм дихота не знаю дилемма между это проблема в процессах и я должен типа всё хорошо в этот спринт да или мы как команда всё это разберём Вот вообще говоря ну очень просто редко я вижу действительно какую-то командную работу Я не знаю я потратил кучу усилий чтобы пытаться добиться того чтобы была какая-то командная работа потому что всё что все инструменты которыми мы пользуемся они такие: "Так Джира тут один асайни один исполнитель Так никого тут больше нет" Я беру тасочку и её делаю до конца Потом перевешу на тестировщика он один пусть тестят Вот А вот это вот факт помощи он куда А потом у нас какой-нибудь перформансревью раз в полгода где ты посмотришь такие на тикеты которые ты сделал м что-то недостаточно А вот ты наверное другим помогал но кто ж тут поймёт-то И вот вот где-то мы всё время где-то подвисаем между: "А давайте мы хотим чтобы работа была командная но при этом оценивать будем заиндивидуальности" Не случаем ли ты лоуперформер какой-то Вот это мы уходим вообще конечно в сторону отго скрама но вот я наверное в целом опять согласен О'кей как бы о'кей скрам подсвечивает но наверное просто в силу того что о'кей мы сократили вот этот цикл обратной связи внутрь опять и ценности О'кей ценности и ценности в том числе KPI KPI вообще убивают много чего и много хороших начинаний KPI убивают Вот то что я говорила да что в том числе там руководство не поддерживает руководство не готово вы в командах поменяйте а мы как бы будем счастливы Ну не будете вы счастливы потому что как правильно ты и заметил да KPI тоже придётся пересмотреть А если ты пересматриваешь вот эти вот KPI по личному перфомансу ага а как мне оценивать тогда надбавку к зарплате А как мне ему премию перечислять И тут оказывается что руководители не умеют работать больше ни с чем Ну потому что просто не задавались этим вопросом Не знаю не обучены да Ага мы не обучены блин Значит так Не нет значит так не должно быть Значит команда проблема Да Нет ребят не в команде проблема Вам доу учиться наверное надо Насчёт командности тоже то что я говорила руководителю нужно знать динамику команды образования Наверное зачем нужен скрам мастер там не знаю коуч или руководитель проекта да Это может быть вообще любой неформальный лидер который ну более-менее с головой да интересуется этой темой а с опытом да который понимает что как разбирается интересуется Когда в команде на самом деле каждый сам за себя Скрам тоже не взлетит Ну потому что нужна взаимоподдержка И вот здесь как раз человек должен понимать на каком этапе команда находится какие у них там проблемы где они там их не знаю Ну там можно взять модель Такмана плюс в Атри коленсионе уже будет уже будет хороший набор а для того чтобы стартануть да разобраться в проблемах инициировать это чтобы не сидел вот ты Саш да и думал: "Блин со мной что-то не так" а не боялся сказать что ребята блин да меня задрало в конце концов вот то что я стараюсь изо всех сил лезу и ээ пытаюсь сделать тут что-то и не получается А что так можно было Ну я не понимаю Да можно нужно понимаешь Я пытаюсь разобраться у меня не получается Помогите мне разобраться почему так Да да давайте вместе Я один я вот один такой тут ээ однорукий сижу или у всех такая же проблема Я вот один не Если я один не успеваю ну помогите мне кто-нибудь понять почему я один не успеваю Как так сложилось-то Угу Но меня это беспокоит И и и понимаешь и вот здесь если а в команде каждый сам за себя там нет даже уровня доверия никакого базового то не пройдёт Ну и в скрам будет тяжело С другой стороны скрам как раз помогает команде а пройти вот эти этапы и стать командой На самом деле командой надо им просто устроить маленький большой кризис Либо развалится либо выживет Ладно это опасная тема да Вот я просто думаю что Да счёт маленького большого криса у меня есть что сказать но я думаю что это не по запись Я просто думаю что ведь Аджай Скрам вот мы сейчас обсуждаем как бы много разработчиков слушает как бы ну это вообще не самая интересная тема как бы на пути становления разработчиков Но мы не за Аджайлом пришли в профессию мы пришли делать что-то классное Вот и это как бы только потом много лет спустя может быть как бы что не только интереснее собирать системы из Кавки и кубернетисов а вот можно из Кавки и кубернетисов а ещё вокруг и людей них И а люди они такие не всегда логически предсказуемы они что-то как-то своё иногда делают и что-то не то что ты им говоришь Вот И вот это может гораздо больше система стать более интересной Но вот мне кажется вот опять я заходил уже про обучение менеджеров И вот здесь мы как бы опять в той же ээ как бы фазе что очень часто менеджерами становятся из кого Из самых крутых разработчиков Но когда ты самый крутой разговорчик а тут теперь ты внезапно должен задать много чего И ты такой джун: "Причём никто тебе не расскажет что тебе нужно знать Там ты может быть скажут: "О'кей читай PMB или там Agile Guide почитай" О он коротенький девять страниц его прочитаю Всё поехали Внедряем А теперь А теперь представь что ты работал в скрам-команде с Джуна Вот ты начинал у тебя была команда которая тебя поддерживала в развитии техническом ты с ними общался тебя подключали к задачкам каким-то сложным ты рос за счёт этого Круто же Ну джун-то наверное это надо да Дальше ты мидл тебя начинают там подключать каким-то причём ты всё это время слышишь как команда решает какие-то вопросы что команду интересуют ещё там и какие-то поставки и какие-то проблемы и какие-то процессы и ты видишь эти решения То есть нет такого что ты сидишь джуном и всё как-то работает магически Ты не понимаешь как В какой-то момент к тебе пришёл руководитель сказал: "Ты делаешь вот это ты такой" Ага Это всё для тебя прозрачно становится Ты сидишь на тех же самых ретроспективах Пускай ты сидишь как рыбка молча но ты слышишь и видишь как эти решения принимаются потому что они обсуждаются Ты можешь быть с кем-то согласен или не согласен Да может быть у тебя знания ещё не хватает но чисто по-человечески ретроспектива это про процессы Ты начинаешь погружаться в эти процессы Угу Ты начинаешь понимать как они работают С джуна у слада для менеджера Если от джуна он слышит что-то на ретроспективе это значит достаточное доверие Он не боится Да нет ну как бы это у слада Ладно даже даже да ну даже да если уж он что-то говорит это вообще бомбически Но пусть молчит Но если молчит да если вот там сомневаешься почему он молчит можно подойти спросить потом: "Слушай ты молчишь потому что у тебя ну как бы сказать нечего или ты стесняешься?" Да если он стесняется значит поддержать надо Если а мнения нет скажи: "Слушай ну ты в следующий раз там попробуй хотя бы там ну плюсануть кому-нибудь да типа я вот поддерживаю вот это или там просто скажи что ребят я мне сложно выбрать да я вот ну учусь о'кей это о'кей" понимаешь Потом он начинает расти в медла Технику-то никто же не отменял А потом он начинает расти например там в того же самого синьора брать уже на себя какие-то проведения ретроспектив брать на себя какие-то дейлики да А он уже смотрит на команду по-другому он уже понимает что Ага вот я синьор у меня тут там медлы джуны вот их надо как-то там не знаю адаптировать в команду может быть какие-то конфликты ещё что-то да Вот он начинает там не знаю там с тестировщиками какие-то процессы налаживать выстраивать вместе И когда этот

техлед он с джунов уже рос ему почитать может быть немножко осталось а опыт у него уже есть Мы ищем в стартап таких единорогов И вот и вот и и вот тогда у тебя нормальные руководители будут Но на самом деле что скрывать-то опять же да вот из этой компании с которой мы уходили у меня ребята которых я нанимала например там тестдами абсолютно спокойно уходили на руководителей проекта просто после того как они работали вот там 3-5 лет в скраме Они всё знали потому что это те ребята которые решали конфликты в проекте а там были конфликты которые решали вопросы с заказчиками отслеживали риски которые прекрасно знают как управлять бэклогом Да может быть они знают не вот все подходы на свете да и не все техники но о'кей это та теоретическая база которая достаточно легко наращивается а опыт-то уже есть и и насмотренность большая за счёт этого потому что ничего не скрыто потому что всё прозрачно И вот в этом случае скрам нужен Нет мне просто кажется что действительно что тут какой-то причино и следствие перепутано потому что ну они делают не то что в скраме они делают много чего что очень суперважно и очень супер правильно делать Но это могло быть поточно Это могло быть это то что требует скрам Хорошо Это то что требует скрам если мы правильно всё прочитали То есть ну понятно как бы очень много условий должно сложиться как бы о'кей если много условий удачно складывается все люди правильно всё прочитали всё правильно становится и мы выращиваем правильных людей команду и команду Мы мы выращиваем отличную перформящую команду и людей которые да могут самостоятельно вытащить команду чуть ли не из любого кризиса Самое главное они могут это люди которые не будут загонять команду в кризис А смотри почему скрам Потому что вот там полный набор там и взаимодействие с заказчиком да То есть если мы берём частично ну ту же самую поточку не обязательно что ты будешь взаимодействовать с заказчиком да Ну понимаешь То есть мы берём вот тот кусок когда мы просто там а планируемся каждый день там дейлики у нас есть мы демоно проводим мы иногда там проводим ретро Насколько ты взаимодействуешь с заказчиком Есть ли у тебя заказчик прямо в доступе Ну не факт Можно выкинуть планирование О'кей Ну тогда ты не умеешь планировать В скраме вот прямо заложено заложен тот минимум который очень полезен Поэтому а если ты оттуда что-то выкидываешь считай что ты ставишь себя костыль в этом плане Опять же вот не настаиваю что скран всем нужен но вот от него такой э от него такой бонус есть Всё он согласен Я тут ворвусь на этом да этапе А самое забавное что дойти до какой-то логической точки когда все такие: "Ну да вот сошлись не получается" Всегда как-то остаются все прес своём мнении Без коммерческого опыта не берут на работу а без работы нет коммерческого опыта Есть ли выход из этой ситуации Есть Коммерческий опыт - это не про работу где-то это про работу в команде над проектами у которых есть реальные пользователи а значит настоящие риски в отличие например от учебных проектов Такими проектами занимается Хесле Карьера Это место где мы объединяем начинающих разработчиков команды подключаем к продакшн-проектам и помогаем нарабатывать необходимые месяцы и годы опыта Одним из таких проектов является код Basics которым ежемесячно пользуются сотни тысяч пользователей Кстати его исходный код открытый лежит на гитхабе Это значит что вы получите не только ценный опыт но и ваш вклад легко увидеть и оценить Подключайтесь ктрь по QR-коду на экране или ссылке в описании Я ну не то чтобы надеялся я думал мало ли может быть у нас получится но нет Я вижу что коннечном итоге В смысле в конечном итог Я уже почти согласен Дадада То есть мне интересно А да ребят если я думаю что в первую очередь конечно интересном лидам а напишите пожалуйста ребят в комментариях а что вы думаете и какие-то конкретные кейсы в вашей истории когда что-то работает или не работает А это будет интересно почитать Я думаю что ребята тоже обязательно посмотрят может быть что-то напишут да Может быть будет может быть что-то там откроется новое с другой стороны которую мы здесь не разобрали Ребят вам большое спасибо что вы подключились пришли и побговорили Да спасибо Кирилл что пригласил Да спасибо Посмотрим да посмотрим как будет Ребят не забывайте подписываться на канал и комментируйте этот выпуск Будем читать будем отвечать и будем разбираться со Скрамом дальше Всем спасибо Пока