Менеджмент Scrum-проекта: не слишком ли часто мы отступаем от правил

Статья написана в соавторстве c Алексеем Мелентьевым.

Привет, давайте знакомиться. Мы — Алексей Мелентьев, Senior QA и Senior Team Lead с 10-летним опытом в IT, и Анастасия Мазур, Project Manager и Business Analyst, в IT 4 года. Примерно по три года работаем в компании DataArt, методологией Scrum и ее практическим применением интересуемся давно.

О Scrum написано так много, что никаких открытых вопросов об этом методе управления проектами, кажется, оставаться не должно. Но все ли понимают, что этот Scrum представляет собой на практике, как его внедрять и без чего он не получится? Считаем, задуматься об этом полезно всем, кто интересуется современными методиками разработки, а уж тем более тем, кто работает в проектах, претендующих на использование Scrum. Особенно проджект-менеджерам и тимлидам, которые руководят командами в таких проектах.

Чтобы разобраться, мы собрали десяток наиболее характерных вопросов о Scrum и провели опрос среди коллег, работающих в разных проектах и командах, с разными заказчиками и технологиями. Мы не пытались собрать репрезентативную выборку, и главной темой в статье будет не статистика ответов. Мы постарались выявить проблемные точки, проще говоря, самые распространенные ошибки в представлениях о Scrum-методах.

Сразу оговоримся, что мы ни в коем случае не беремся оценивать целесообразность самого Scrum-подхода или эффективность его применения в отдельных командах. Речь пойдет исключительно о распространенных случаях несоответствия теории и практики, а также представлений самих IT-специалистов об этом методе. Думаем, всем, кто сам работает по Scrum, наш материал поможет проверить базовые настройки.

Иллюстрация Алины Самолюк

Команды без Scrum-мастера

Около 70 % опрошенных ответили, что в их команде нет Scrum-мастера. Это бесспорный антирекорд нашего опроса. Впрочем, для аутсорсинговых проектов результат, пожалуй, выглядит предсказуемым: не так уж просто продать заказчику специалиста, задача которого только следить за процессом. По крайней мере именно так чаще всего выглядит Scrum-мастер в глазах заказчика.

Конечно, в командах, исповедующих Scrum, есть проджект-менеджеры и тимлиды. Так ли важно, если никого из них официально Scrum-мастером не называют? Пожалуй, нет, если PM или TL не забывает об основной задаче — обслуживании интересов команды. Служить тем, кто занимается разработкой и тестированием продукта, важнее и сложнее, чем управлять или руководить ими. К сожалению, немало менеджеров и лидов несут свои звания с излишней гордостью. Те, кто не до конца понимает свою роль, обычно считают, что они пусть и немного, но все-таки важнее остальных членов команды.

Эта на первый взгляд безобидная и скорее психологическая проблема ведет к другой, более практического характера. Мы с удивлением обнаружили, что в подавляющем большинстве проектов последнее слово остается за менеджером проекта, тимлидом, продакт-оунером, но только не за командой. Здесь мы видим прямое противоречие с принципами Scrum, согласно которым именно команда должна решать, кто и что будет делать, а затем совместно нести полную ответственность за ход и результаты работы. Scrum-мастер или тот, кто выполняет его роль, всего лишь организует процесс, помогая принять правильное решение, а затем качественно и в срок справиться с задачами, которые коллеги (при его равном участии) поставили сами себе.

Почти каждому из нас хотя бы раз приходилось работать в такой команде, где PM продавливает свою точку зрения, а когда приходится отвечать за провалы или отложенные сроки, ищет крайних. Вместо того чтобы понять, что нет правых и виноватых, а есть команда. И либо она смогла с твоей помощью выстроить процесс и быть эффективной, либо нет.

Работа без планирования

Всего лишь 12 % опрошенных ответили, что пользуются техниками планирования, такими как Planning Poker. Еще 45 % заявили, что проводят командное планирование без применения каких-либо техник, а целых 43 % признались, что командного планирования не проводят вовсе, доверяя этот этап работы проджект-менеджеру или тимлиду.

Нам эти данные кажутся удручающими. Как команда может нести ответственность за то, о чем ее не спрашивали? Как PM или TL может знать все подводные камни дизайна, разработки и тестирования?

Да, планирование — это, возможно, не самое интересное занятие. Процесс бывает сложным, может продолжаться долго, причем порой кажется, что время, потраченное на него, просто потеряно. Но эта часть не менее важна, чем написание кода или, скажем, подготовка вайрфреймов. Но этому нужно учиться. Планирование — ключ к комфорту вашего заказчика и команды. Именно грамотная подготовка предотвращает «пожары»: работу в ночь перед релизом или по выходным, потому что «мы опять не успеваем».

Стоит признать, мы ни разу не видели проект, в котором абсолютно все прошло по изначально утвержденному плану. Но это не значит, что к этому невозможно приблизиться и не стоит стремиться. Если вы научитесь трезво оценивать объем работы, который ваша команда способна выполнить за спринт, процесс улучшится и жить станет легче. Вы сами удивитесь насколько.

Еще до DataArt Настя работала в проекте, где планирование и оценки делали только Dev Lead и Project Мanager, не советуясь с теми, кто непосредственно будет выполнять задания. Как результат — либо сроки срывались и приходилось объясняться с заказчиком, либо разработчики тайно овертаймили, чувствуя свою вину за то, что не успевают. Хотя дедлайнов они сами не устанавливали. После этого все поняли, что подход был в корне неправильный и участвовать в планировании должны все.

Жизнь без стори-поинтов

От проблем планирования плавно переходим к следующей ошибке. Всего лишь 35 % опрошенных пользуются стори-поинтами, остальные предпочитают оценивать задачи в часах.

Пожалуй, каждый, кто работал по Scrum-методу, когда-то возмущался: «Кому нужны эти стори-поинты?» Этот период в карьере длится ровно до тех пор, пока не попадешь в проект, где они тебе действительно помогут. Story points позволяют правильно оценивать объем работы, которую команда успевает сделать за спринт.

В чем разница с оценкой в часах? В том, что стори-поинты помогают отвязаться от привычных «Я выполню эту задачу за 10 часов. А я протестирую ее за 5» и оценивать сложность задачи в целом, основываясь на опыте. Потому что оказывается, что 10 часов на разработку плюс 5 часов на тестирование не гарантируют выполнения задачи за 15 часов. Часть времени тратится на коммуникацию, на уточнения всевозможных деталей, на погуглить, попить кофе и тому подобное. Возможно, задача еще и не пройдет тестирование с первого или второго раза и потребует доработки. Возможно, найдутся неточности в требованиях.

И таких «возможно» в каждом проекте великое множество. Именно благодаря стори-поинтам можно абстрагироваться от мелочей и оценить сложность задачи в целом. Они помогают трезво взглянуть на объем задач, который ваша команда успевает выполнить за спринт. А ведь в итоге важен как раз объем работы, а не время, потраченное на нее.

Рост команды без границ

Около 35 % опрошенных ответили, что их команда насчитывает более 10 человек. Нам и самим приходилось работать в команде 40+ специалистов. Результат предельно предсказуем: дейлики по часу, ретроспективы на 10 с лишним часов... Как мы до такого докатились, спросите вы? Очень просто!

Сначала нас было не больше десяти, потом мы начали расти, но и представить не могли, что нас когда-нибудь станет больше 15. А зря! Стоило вовремя задуматься о том, чтобы разбить команду на подпроекты, чего и вам желаем. Если видите, что команда разрастается, а ежедневные созвоны хоть немного затягиваются, не откладывайте — прикиньте, не пора ли вам разделиться.

В нашем случае на одном из дейликов мы просто осознали, что так дальше длиться не может, и начали перебирать варианты, как быть дальше. В итоге мы разбились на подкоманды. У каждой команды были свои лиды, которые ходили на созвон своей подкоманды и на лидовский созвон. Результат: дейлики стали укладываться в 30 минут, а их эффективность выросла в разы.

Работа без созвонов? Созвоны без коллег?

Мы все знаем распространенные «церемонии» в Scrum: ежедневные созвоны, планирование, ретро, демо и так далее. Но, к сожалению, многие команды пренебрегают всеми или некоторыми собраниями.

Ежедневные стендапы проводят многие, хотя даже их иногда считают лишней тратой времени. Когда-то давно Настя работала в нераспределенной команде, где решили сэкономить 15–20 минут на отказе от каких-то стендапов: «Мы же в одной комнате сидим, зачем нам лишний раз собираться?» В итоге на расспросы формата «А когда будет готово?» или «Уже готово?» уходило по три часа в день. Так что коллеги опять начали собираться за чашкой кофе по утрам, чтобы быстренько обсудить актуальные задачи и проблемы на нашем пути.

Однако, когда команда большая, соответствовать регламенту в 15 минут сложно. Часто люди начинают обсуждать детали конкретной задачи и созвон превращается в балаган. Принцип золотой середины требует говорить по существу и быстро — так, чтобы уложиться в отведенное время.

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

Еще чаще игнорируют ретро. Менее 50 % опрошенных не проводят ретроспективу и ревью спринта, потому что считают это лишней тратой времени.

Но сам факт проведения ретро не решает все проблемы. Некоторые команды проводят его, но не делают никаких заметок и action items. А если и делают, то у многих они остаются без внимания. Хорошо — назначать ответственных или исполнителей для всех action items, а каждое очередное ретро начинать с анализа того, что было записано на предыдущем.

Мы уверены, что ретро — это классная штука, благодаря которой можно посмотреть назад и проанализировать свои ошибки, только нужно приложить немного усилий, чтобы оно было действительно эффективным.

Спринт без ясной цели

Многие знают, что бэклог спринта менять нельзя. И да и нет. Но почему так сложно?

Представьте, что в ходе спринта вы должны построить одноэтажный дом. В середине спринта говорят, что нужно изменить цвет занавесок в гостиной этого дома с синего на зеленый. Но ведь бэклог нельзя изменить!

Самое главное — не бэклог спринта, а его цель. Если было решено, что нужно построить дом — это та цель, к которой вы стремитесь. Изменение цвета занавесок никак не повлияет на успех вашего спринта, если дом будет построен. Оказалось, что нужны зеленые? Если это возможно, почему бы и нет. Конечно, я не говорю о ситуации, когда вместо одного этажа вдруг потребовалось два, да еще и гараж в подвале, о котором изначально речи не было. Такое обновления требований, возможно, даже потребует остановки спринта и переоценки всех изменений. Однако в любом случае главное — понимать, каковы будут последствия внесения новых требований.

В одном из первых серьезных проектов Леши заказчик очень любил менять цели, увидев какие-то новые фичи на конференциях. Он немедленно требовал таких же, и его не волновало, что сотрудники работают совсем над другим. Как говорится, желание заказчика — закон. Нужно срочно? Срочно переключаемся. Потом выяснялось, что новая задача влечет изменения не только фронта, но логики на бэкенде. «Но раз мы начали делать изменения на бэкенде, не добавить ли нам еще вот такую фичу?» — спрашивает заказчик. Результат — релиз увидел только третью версию сайта на год позже запланированного.

Недостижимый идеал

В идеальном Scrum-проекте все участники должны быть многофункциональными. К сожалению, пока настолько универсальных команд мы не встречали. Догадываемся почему: человек не может уметь делать все. В нашем мире нет супергероев, даже человек типа «и швец и жнец» (пусть даже без музыкальных способностей) — большая редкость. Невозможно одинаково успешно развиваться во всех направлениях, потому-то и возникает специализация и «зоны профессиональной ответственности».

Четкое разделение обязанностей позволяет наладить параллельные процессы. Возможно, вы смотрели фильм «Основатель» про создателей сети McDonald’s. Братья Макдональды придумали, как выстроить производственную цепочку с большим количеством людей, где каждый делает свою работу: жарит котлеты, нарезает овощи, наливает напитки или пробивает заказ на кассе. Это стало залогом скорости производства без потери качества: на каждом этапе за него отвечает сотрудник, досконально знающий свой участок работы.

Это не защитит вас от сбоев на 100 %, но это ближе к реальности, чем мечта о коллегах, которые могут в любой момент выступать в роли разработчика, тестировщика или аналитика. Хотя если вы работаете или работали в такой многофункциональной команде, то, пожалуйста, поделитесь опытом в комментариях! Нам очень интересно.

Выводы, или Мораль без морализаторства

  1. Теория — это хорошо, но каждый проект уникален и иногда требует особого подхода. В то же время с теорией время от времени необходимо сверяться. Если вы претендуете на применение Scrum-методологии, но последовательно отказываетесь от ее элементов, заявленных как необходимые, рано или поздно придется признать, что у вас не Scrum-проект.
  2. Успешный и идеальный — это не синонимы. Идеальных Scrum-команд в аутсорсинге, по нашим наблюдениям, просто нет. Вряд ли кому-то удастся убедить заказчика оплатить все процессы, без которых идеалом называться не получится. Но само по себе это не разрушит вашего проекта: вы можете делать успешные релизы, приближаясь к методологии вашей мечты в рамках утвержденного бюджета. Главное — не только плыть по течению, но и сверяться с проложенным курсом.
  3. Не бойтесь импровизировать, ведь менеджмент проекта — сложный процесс, и в каждом случае к задачам придется подстраиваться. Действовать строго по инструкции не выйдет, а уж гибкие методы точно не предполагают догматизма. Важно лишь не идти на поводу у собственного мозга, выдающего за адаптацию методологии отказ от регулярного планирования или обязательного созвона. Действуя в угоду сиюминутному комфорту, мы порой создаем себе серьезные проблемы в будущем.

Подстраиваясь под обстоятельства, не забывайте о специальной литературе, лучших практиках и собственном опыте — подводных камнях, на которые нас иногда повторно несет.

Литературы по Scrum, конечно, много, но ниже мы решили оставить немного классики, которая поможет понять, как правильно построить процесс:

👍НравитсяПонравилось8
В избранноеВ избранном3
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


Лучшие комментарии пропустить

Я много где за много лет работал, пока на одной из топовых украинских галер меня не аутстафнули в германскую галеру размером в несколько раз больше моей. И я увидел чёткий скрам орднунг в исполнении расовых немцев.
Впервые я увидел, что созвоны занимают РОВНО 15 минут и скрам мастер следит сцуко за секундной стрелкой. Впервые увидел все церемонии как по книжке. Правильную и регулярную работу с бэклогом.
Стоит отметить, что это единственный проект, в котором я принимал участие, который был сдан заказчику чётко в срок.
В украинских галерах меня больше всего поражает менеджмент, считающий себя умнее людей, разработавших эту методологию. Ну конечно, те умники в своих книжках жизни не нюхали, куда им?
И да, стоит отметить, что правильный скрам по всем канонам — это очень и очень дорого.
Но не каждый менеджер может объяснить заказчику, почему без правильного каноничного скрама будет по итогам ещё дороже.
И на последок — первое и главное, что я спрашиваю у менеджмента на любых собеседованиях, это не про продукт, не про его целевую аудиторию, миссию и прочую шелуху для продажников. Это про процесс разработки. Как именно у них реализован скрам. Если в рассказе нет слов «бэклог», «мэинтейним», «продакт оунер», то там ручное управление разработкой и изменение требований на 180° по щелчку пальцев собственника. И вы всегда будете не успевать к релизу, а значит, всегда будете плохим работником, привет, синдром самозванца и темы про выгорание.

122 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

В общем, что можно сказать... За деревьями и леса не видно. Scrum — это всего лишь некий фреймворк, который вам помогает что-то и как-то организовать. В данном случае разработку и поставку кастомеру ПО. Как это будет организовываться — кастомеру вообще, по большому, счету не должно быть интересно. Ему важно за какой срок и за какой бюджет это будет сделано, ключевой момент — качественно. Если нравится что-то кастомизивароть в процессе — то лучше взять Kanban. Но для долговременных проектов, особенно, медицинских — Scrum вообще не подходит. Как-то в одной компании у нас был день, посвященный анализу все процессов разработки. О очень понравилось сравнение долгоиграющих проектов с объяснением поездки на Северный полюс. Как в данном случае поможет Agile вообще и Scrum в частности? Так что давайте будем честны — Scrum пытаются использовать без должного понимания, но просто потому что модно.

Planning poker — это НЕ техника планирования. Это инструментальное оценки. Иными словами, инструмент для синхронизации представления членов команды о сложности (размере) задачи.

Все бы в этой статье было почти хорошо. Только выбросить слово проект. Скрам предназначен не для управления проектами, а для разработки продуктов. Причём в условиях комплексного домена или иными словами, когда наша разработка производится в условиях «wicked problems»: мы не знает, насколько успешен будет ли наш продукт, можно ли его реализовать технически и понравится ли он пользователям. Скрам позволяет управлять этими рисками.
Никаких проектов в нем отродясь не было.

Только выбросить слово проект. Скрам предназначен не для управления проектами,

Продукт он только для его собственника. Для участника команды — это просто комплексная техническая задача на работе. То есть, проект.

Не важно. Между проектом и продуктом большая разница. Погуглите какая.

Проект — процесс. Продукт — результат.
Наёмный работник имеет дело с процессом, для него это проект. Собственник имеет эксклюзивные права на результат, для него это продукт.
Исполнитель не имеет никаких имущественных прав на результаты своего труда — для него это просто проект. Он ничего не потеряет, если продукт провалится в продажах по какой-либо причине.

Он ничего не потеряет, если продукт провалится в продажах по какой-либо причине.

Это распространенное заблуждение. Это тоже что сказать что всю ответственность за сражение несет — исключительно генерал. И никому не интересно что солдата в ходе сражения — убьют. И так что вы теряете если продукт провалился в продажах — время (самый дорогой ресурс), наверняка любые карьерные перспективы на текущем месте работы (вашего шефа не повысят и он не повысит вас), вынуждены будете идти на рынок (внешний или внутри компании) в поисках работы, наверняка — потеря экспертизы как доменной так возможно и хард, необходимость переквалификации, репутация — участвовал в провальном проекте (имеет значение для нанимателя). В общем как не крути вам даже еще хуже получится чем клиенту, который потерял в основном только деньги. Так что имеет смысл думать дважды перед тем как ввязывается в очень рисковое мероприятие. Может кончится овертаймами без конца, изучением невостребованных рынком фреймверков и языков программирования и т.п., а потом полным провалом.

И так что вы теряете если продукт провалился в продажах — время (самый дорогой ресурс)

Которое работнику оплачено в соответствии с контрактом.

наверняка любые карьерные перспективы на текущем месте работы

Какие карьерные перспективы, зачем?

вынуждены будете идти на рынок (внешний или внутри компании

Почему «вынужден»? Это нормальный процесс миграции между проектами.

наверняка — потеря экспертизы как доменной

Не существует в мобайле никакой доменной экспертизы.

В общем как не крути вам даже еще хуже получится чем клиенту, который потерял в основном только деньги.

Клиент потеряет все деньги, вложенные в проект. Программист просто сменит проект и не заметит ничего.

Может кончится овертаймами без конца

Можно сразу уволиться и найти другое место на те же деньги за неделю.

изучением невостребованных рынком фреймверков и языков программирования

Можно просто не идти на позицию, где они есть. При текущем изобилии вакансий в этом нет необходимости.

Проект — временное мероприятия для достижения результата. В том числе и разработки продукта. В нашем IT устоявшейся термин «проект», применяется даже в организациях без проектной организации труда. Обычно означает договор с клиентом по которому работает группа специалистов, этот договор от лица аутсурсинговой/аутстафинговый компании — ведёт «проектный менеджер». Откровенно говоря — это не проектная организация труда вообще. Сами проекты организуются и управляются заказчиком — потому что у них есть цели которых требуется достичь, тогда как у аутсурса единственная цель — взять с заказчика деньги за почасовую работу. В рамках разработки продукта — могот быть проекты, например выпуск каждой major версии можно организовать как проект — и вот тут Scrum блестяще подходит, проверено на практике.

Скрам предназначен не для управления проектами, а для разработки продуктов.

Вы не могли бы, пожалуйста, указать, где в Scrum guide или ещё в каком-либо авторитетном источнике это написано.

Я много где за много лет работал, пока на одной из топовых украинских галер меня не аутстафнули в германскую галеру размером в несколько раз больше моей. И я увидел чёткий скрам орднунг в исполнении расовых немцев.
Впервые я увидел, что созвоны занимают РОВНО 15 минут и скрам мастер следит сцуко за секундной стрелкой. Впервые увидел все церемонии как по книжке. Правильную и регулярную работу с бэклогом.
Стоит отметить, что это единственный проект, в котором я принимал участие, который был сдан заказчику чётко в срок.
В украинских галерах меня больше всего поражает менеджмент, считающий себя умнее людей, разработавших эту методологию. Ну конечно, те умники в своих книжках жизни не нюхали, куда им?
И да, стоит отметить, что правильный скрам по всем канонам — это очень и очень дорого.
Но не каждый менеджер может объяснить заказчику, почему без правильного каноничного скрама будет по итогам ещё дороже.
И на последок — первое и главное, что я спрашиваю у менеджмента на любых собеседованиях, это не про продукт, не про его целевую аудиторию, миссию и прочую шелуху для продажников. Это про процесс разработки. Как именно у них реализован скрам. Если в рассказе нет слов «бэклог», «мэинтейним», «продакт оунер», то там ручное управление разработкой и изменение требований на 180° по щелчку пальцев собственника. И вы всегда будете не успевать к релизу, а значит, всегда будете плохим работником, привет, синдром самозванца и темы про выгорание.

все так.

а опорное в вашем сообщении

Х орднунг в исполнении расовых немцев

и

Х по всем канонам — это очень и очень дорого

утрировано
замените Х на что угодно, хоть на RUP, хоть на FDD(Feature driven development), хоть на ...
будет тот же результат.

немцы и очень дорого — решающие факторы, а не X

Совершенно полностью согласен.

Как именно у них реализован скрам.

Скажите, пожалуйста, а что Вы делаете, если у них был не скрам?

Просто желаю хорошего дня.
Зачем тратить время на вакансию, в которой я всё равно себя не проявлю?
В скраме от разработчика требуется участвовать в митингах, читать User Story и делать как написано в acceptance criteria. Ничего сверх этого я делать не умею и не собираюсь.

Скажите, пожалуйста, я правильно понимаю, что если на проекте не используется Скрам, то вы не будете принимать участие в проекте? То есть если Скрам вдруг по какой-то причине перестанут использовать, то вы больше не будете работать разработчиком программного обеспечения?

я правильно понимаю, что если на проекте не используется Скрам,

На данный момент — да.

То есть если Скрам вдруг по какой-то причине перестанут использовать, то вы больше не будете работать разработчиком программного обеспечения?

Если ему найдут адекватную замену, которая не будет создавать дополнительных обязанностей для роли разработчика программного обеспечения, буду работать с ней.
Если от разработчиков будут требовать что-то ещё, то это будет говорить о том, что рынок разработки программного обеспечения насытился, компания может себе позволить перебирать кандидатами, кандидату приходится соглашаться с тем, что предлагают. Обычно такое сопровождается также и снижением зарплат и ухудшением условий работы. Это говорит о признаках отмирания профессии и заставит однозначно задуматься о её смене.
Если что, я уже так 2 профессии поменял.

Понятно, спасибо большое за ответ. Очень многое проясняет.
Конечно, Скрам очень удобен для разработчиков отсутствием индивидуальной отвественности за сделанное. И если будут попытки вернуть таковую ответственность обратно, понятное дело, что сильно не всех это устроит.

Почему же нет индивидуальной ответсвенности?

Насколько я понимаю, по определению Скрама. На спринт комитится вся команда, целиком. Если команда не справилась со спринтом — это общая ответственность. Велосити меряется для всей команды в целом. В общем, типичный бригадный подряд. Можно, конечно, внутри команды потом устраивать разборки, кто что не так сделал, но об этом Скрам ничего не говорит, как я понимаю.

Ну это в том числе и означает — что если коллега застрял над чем то в ходе спринта — то команда ему поможет, а не станет потирать руки радуюсь что у кого то случилось горе.

Eсли вся команда будет помогать одному человеку, то скорее всего вся команда не успеет доделать свои задачи, т.к. в «идеальном» спринте каждый загружен ровно настолько, насколько он может потянуть. И выпадание даже половины рабочего дня значит что что-то будет не доделано.

Скрам очень удобен для разработчиков отсутствием индивидуальной отвественности за сделанное

Как это?
Она очень даже есть. В скраме хорошо виден перфоманс каждого в каждом спринте. Если разработчик не тянет темп команды, от него быстро избавляются. Какая ещё ответственность нужна?
Ответственность за успех продукта на рынке разработчик не может и не должен нести ни при какой методологии. Это задача собственника и маркетологов

В скраме хорошо виден перфоманс каждого в каждом спринте.

Вы не могли бы рассказать об этом поподробнее, пожалуйста. Какой именно инструмент Скрама позволяет хорошо видеть перформанс каждого.

Какой именно инструмент Скрама позволяет хорошо видеть перформанс каждого

Количество сторипоинтов закрытых каждым за спринт.

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

Первое. Никто индивидуально тикетов не «закрывает». User story — пишут, уточняют требования, оценивают, разрабатывают, тестируют, разворачивают и т.д. конкретный флоу зависит от команды и проекта. Посему каждая тикет это результат командной работы. Аналогично как в футболе, бейсболе, волейболе и прочих командных видах спорта. Вся команда или выигрывает или проигрывает — и никому не интересно если «Роналду» забил гол при счёте в 1-10. Второе — планирование как раз и применяется чтобы знать какие задачи будут в спине. Скарам как раз и запрещает (в теории по крайней мере) изменять список задач в спринте. Если стало ясно что то что делается в спринт — вдруг больше не нужно — спринт досрочно закрывается и начинается новый.

Виктор, Вы не со мной спорьте, Вы Станиславу лучше ответьте. Это Станислав, не я, написал про измерение индивидуальной велосити, и, более того, про организационные выводы на основании этих измерений.

То есть, если кто-то закрыл одну стори на пять поинтов, а другой закрыл пять на единицу, то можно считать, что у этих двух людей перформанс одинаковый, правильно?

В данной ситуации это уже на усмотрение лида, кому какие стори давать на имплементацию. Если джун закрыл 5 сторей по 1 сторипоинту — он норм джун. Если условный сениор закрыл одну сторю на 5 сторипоинтов — он норм сениор. Как-то так.

Я бы очень попросил ответить на те вопросы, которые я задал, а не на какие-то другие вопросы. Давайте ещё раз. На вопрос про способ измерения индивидуального перформанса Вы писали

Количество сторипоинтов закрытых каждым за спринт.

Был задан вопрос

То есть, если кто-то закрыл одну стори на пять поинтов, а другой закрыл пять на единицу, то можно считать, что у этих двух людей перформанс одинаковый, правильно?

Варианты ответов: «да, правильно», «нет, неправильно». С возможным последующим пояснением.

Варианты ответов: «да, правильно», «нет, неправильно». С возможным последующим пояснением.

Да, правильно. Велосити будет оценена в привязке к тайтлу. Чем больше сторипоинтов было в каждом закрытом таске, тем условно выше грейд девелопера.

Отлично, спасибо за ответ.
То есть не просто сумма велосити, а ещё и распределение по задачам играет роль. Понятно.

Что вы несёте ? В скраме как не где персональная ответственность за зделанное — причем как сделанное лично, так и результат работы команды в целом. Более того скрам стимулирует от команды достижение результатов.

Виктор, держите себя в руках, пожалуйста.
Про ответственность команды в целом вполне понятно, как это работает в Скраме. Объясните, пожалуйста, как в Скраме реализуется личная отвественность разработчиков.

Впервые я увидел, что созвоны занимают РОВНО 15 минут и скрам мастер следит сцуко за секундной стрелкой.

У них всегда продолжительность митинга 15 минут, не больше и не меньше? Для немцев это не удивительно. Но что-то у меня возникают подозрения, что в таком случае эти митинги просто «для галочки», потому что так написано в книжке.

А если все быстро отрапортовались, то можно ли митинг сократить, не стоять 15 минут, а закончить на 13-й? Или обязательно нужно, чтобы было 15?

А что делать, если нужно больше времени — скажем, какую-то возникшую проблему обсудить? Что тогда делает SCRUM-мастер — просто прерывает митинг по истечении 15 минут, или можно еще продолжить до 16 минут, а то и до 17?

У нас так было в одном голландском министерстве — все точно по инструкции, со всеми церемониями, митингами и ритуалами, просто загляденье. Одна беда — разработка шла раза в 2-3 медленнее, чем в среднем по индустрии.

Исходя из моего опыта, в большинстве случаев эти обязательные ежедневные митинги вообще можно отменить. И проводить их только тогда, когда это действительно нужно.

А что делать, если нужно больше времени — скажем, какую-то возникшую проблему обсудить? Что тогда делает SCRUM-мастер — просто прерывает митинг по истечении 15 минут, или можно еще продолжить до 16 минут, а то и до 17?

В этом случае планируется отдельный митинг с участием тех, кого это касается. Десяти людям из команды слушать обсуждение технических деталей какого-то сервиса полчаса — это бездарная трата времени и сил команды.

все точно по инструкции, со всеми церемониями, митингами и ритуалами, просто загляденье. Одна беда — разработка шла раза в 2-3 медленнее, чем в среднем по индустрии.

Может и чуть медленнее, зато релизы точно в срок, багов практически нет и овертаймов — тоже.

Ну. в министерстве на некоторых проектах отставание от первоначального графика было в полгода :-)

На проекте, на котором работал я, отставания не было. Наверное, потому, что вело его не министерство и он не был государственным, то есть, делался нормально и компетентными людьми.
К примеру, я мог, благодаря адекватному планированию, сделать работу по фичам за 2-3 дня 2-3 недельного спринта. И потратить остальное время на ревью существующего кода, работу с техническим долгом, полировкой решений, да и просто чаю у окна попить.

Я вважаю, що досить добре знаю SCRUM, і весь біль цієї статті розумію і відчуваю. Особливо ніяк мені не забудеться як одна львівська «галера» найняла пафосного київського делівері директора з московською освітою і він став нам, ефектно розмахуючи руками, розповідати про те, що а давайте ми будемо сторіпоїнт вважати людиноднем. Ще й там само, як не з його подачі так з благословення, бізнес-аналітик став скрам-мастером і продакт-овнером — це при живій PM-ці! Це при тому що в Скрамі всього три ролі — SM, PO, Team.
Особисто для мене головне в оцінці в сторіпоінтах те, що добре організована команда може колективно братися за конкретні тікати і досягати кращого результату ніж індивідуальний. Тому що сторіпоїнт це квант team velocity, командної швидкості і від персоналії він не залежить хоча б тому, що є вираженням колективного зусилля з розробки+тестування+можливих фіксів.

Ще один момент, який ви тут забули — проблеми з формуванням і пріоритизацією беклогу, які виливаються в добавки в беклог спринта вже після пленінгу. На практиці причиною цього є хаотичність дій вищого менеджменту і продуктової сторони настільки, що під ударом опиняється навіть засадниче право тімки у спринті працювати виключно з обраним спрінт беклогом.

І ще зазначу — як би добре ти не знав SCRUM, а для тебе, якщо ти не Скрам-мастер за основною спеціалізацією, це не основний скілл, тому завжди є сенс послухати грамотного Agile-коача (в нас зараз у Лондоні крутезний поляк то драйвить). Проблема в тому, що на одного грамотного троє балаболів...

Ще один момент, який ви тут забули — проблеми з формуванням і пріоритизацією беклогу, які виливаються в добавки в беклог спринта вже після пленінгу.

Трохи розповіли про це, але більше з точки зону «Спринт без цілей». Але з вашим коментарем згодна, іноді причиною розмазування цілей може буди якраз хаос с пріоритетами.

Особисто для мене головне в оцінці в сторіпоінтах те, що добре організована команда...

Добре організована команда може працювати за скрамом, рупом, кристал або яким завгодно процесом. Скажіть, будь ласка, що робити, коли команда не є такою, что добро організована? Що робити відповідно до положень скраму?

Скрам надає для цього механізми регулярного, можна сказати, живого зворотного зв’язку. Правда, він сам по собі голий як Реакт, його потрібно обвішувати хорошими практиками, для чого і буває потрібен SM або навіть коач. Бо ретро то ретро, але ми часто самі не уявляємо, як ми можемо перебудувати процес і взаємодію, щоб це більше відповідало нашим цілям, сприяло власне організації команди.
Організована команда виникає не відразу і притирається з процесом теж не відразу, це поступовий процес, просто в ітеративному циклі він простіше контролюється, ніж у безперервному потоці.

Формування команди взагалі то окремий вид діяльності, дисципліна і називається тімбілдінгом.

Скрам надає для цього механізми регулярного, можна сказати, живого зворотного зв’язку.

Скажіть, будь ласка, я правильно розумію, що досить зворотного зв’язку для отримання добре організованої команди?

Правда, він сам по собі голий як Реакт, його потрібно обвішувати хорошими практиками

Скажіть, будь ласка, де саме в Scrum guide згадують, що процес ще потрібно чимось обвішувати, щоб він працював? Сазерленд начебто досить чітко пише, що процес уже цілком хороший і нічого більше не треба.

Організована команда виникає не відразу і притирається з процесом теж не відразу, це поступовий процес, просто в ітеративному циклі він простіше контролюється, ніж у безперервному потоці.

Не дуже зрозуміло, ким і як процес контролюється? Можливо, є якісь метрики, щоб вимірювати, як йде процес організації? І, скажімо, якісь рецепти, що робити, якщо процес таки не йде?

Скажіть, будь ласка, я правильно розумію, що досить зворотного зв’язку для отримання добре організованої команди?

www.cloudflight.io/...​ds/2020/02/behaviours.png

ИМХО «правоверный» SCRUM возможен, начиная с уровня S3. На уровнях ниже можно научить команду выполнять ритуалы скрама, но ритуалы не принесут нужного эффекта без должной инициативы и самоорганизации.

без должной инициативы и самоорганизации.

а при должных инициативе и самоорганизации встанет вопрос — так на кой тогда «скрам»?

как, забыл кто, с авторитетов сказал:
из инструментов для ведения проектов вам достаточно электронной таблицы для трекинга задач/багов и вики для документации.
остальное будет кодом, или комментариями в нем.

но инициатовность и самоорганизация в дефиците и у самих менеджеров. поэтому там тоже начальник начальника моего начальника

все мы — люди. по большей части не инициативные и разгильдяи :)

Скажіть, будь ласка, а ви просто цікавитесь, чи з чимось звіряєтесь, щоб потім сказати, що все фігня, ти не знаєш скрам?
Співбесіди проводити я і сам мастак, тільки тут з відчуттям сенсу діалогу як такого в мене проблема. What for?

Я щиро хочу розібратися, мій інтерес лежить в практичній площині.
Область дослідження — феномен Скраму у сучасній розробці. Хочеться зрозуміти, як процес з досить вузькою областю застосування та без чітко описаних шляхів досягнення результату став таким популярним.
В рамках даних бесід звіряюся зі Scrum guide як з авторитетним описом канонів. Готовий звірятися з книгами Сазерленда та Швабера, Сазерленда читав майже все, Швабера готовий читати, якщо буде потрібно.
Мотивація дослідження — починаючи з деякого моменту часу стало дуже важко знайти в Україні нормального ПМа, який знаається на управлінні розробкою. Моя гіпотеза полягає в тому, що релігійна захопленість Скрамом заважає неофітам осягати управління як науку. Як з цим боротися, зараз незрозуміло, тому вивчаю поки. Дана стаття і коментарі до неї є чудовою нагодою отримати безпосередній доступ до людей, які сповідують Скрам (це термін зі статті, ні в якому разі не хочу нікого образити).
Вибачте, будь ласка, якщо Вас зачепили питання. Якщо не хочете, відповідати не обов’язково.

1. Обратная связь необходима, но не достаточна. Но точно важна.
2. В скрам гайде так и сказано, что есть дополнительные инструменты и практики, которые можно и нужно использовать.
3. Метрики в EBM guide на сайте scrum.org

1. Ну то есть, недостаточна. А что же ещё нужно?
2. Но ничего не сказано про то, что это за инструменты и практики. Этакая каша из топора. То есть мы обещаем, что будет просто, смотрите, гайд какой маленький, да вот незадача, чтобы этим можно было пользоваться, нужно освоить ещё много неназванных источников информации. Хотелось бы увидеть полное системное описание Скрама. Скажите, пожалуйста, такое можно увидеть?
3. Вы не могли бы, пожалуйста, объяснить, как именно измерить способность к инновациям, например? Дабы можно было измерять раз в квартал и понимать, улучшается или нет. Кроме того, вопрос ещё был, что делать, если не возникает организованная команда, несмотря на все усилия команды. Приведенный Вами документ не даёт ответа на этот вопрос, или, если и даёт, делает это в крайне завуалированной форме. Не могли бы Вы, как Скрам мастер, прояснить эти вопросы.
Заранее спасибо.

Конечно, в командах, исповедующих Scrum, есть проджект-менеджеры и тимлиды.

Совершенно непонятно, кто такие проджект-менеджеры в скрам-команде. Не могли бы авторы прояснить этот вопрос, желательно со ссылками на Scrum guide?

Product Owner — он и есть лицо финансово отвечающее за проект и достижение им целей. Тоесть управляющий — manager. Реально такой человек (лицо принимающее решение) есть всегда. В общем — кто платит тот и главный как обычно. Есть правда ситуации когда в команде есть — Product Owner — но это на поверку бизнес аналист, контрагент и т.п. — тоесть человек который никаких финансовых вопросов полномочий решать не имеет. Тогда как настоящий менеджер — якобы «супервайзит».

Product Owner — он и есть лицо финансово отвечающее

а финансы тут при чем??

давайте разбираться в этих ролях, которые, есно, могут совмещаться одним человеком:
— проджект менеджер это тот кто отвечает за проект как вид деятельности.

Проект — предпринятие с определёнными датами начала и завершения, предпринятое для создания продукта или услуги (сервиса) в соответствии с заданными ресурсами и требованиями (ISO/IEC/IEEE 15288:2008 Systems and software engineering — System life cycle processes; ISO/IEC 15939:2007 Systems and software engineering — Measurement proces
Проект — совокупность мероприятий для разработки нового продукта или улучшения существующего продукта (ISO/IEC 26514 Systems and software engineering — Requirements for designers and — developers of user documentation)

— продакт овнер отвечает за продукт (иногда употребляют тоже самое слово — проект), за его целостность, сбалансированость, знает business value фич, выставляет приоритеты их реализаций, согласовывает требования и т.п.

и вопрос правильный — если взять идеальный аджайл:
Люди и взаимодействие важнее процессов(проджект менеджер занят тем что следит за их правильностью) и инструментов
Работающий продукт(за него отвечает продакт овнер) важнее исчерпывающей документации

то проектная деятельность в нем рулится сама. а продакт овнер — все равно нужен

а финансы тут при чем??

«Хліб усьому голова». Возможно вы опишите как можно отвечать за достижение целей проекта (согласно PM Book временного мероприятия для достижения результата) — не имея рычагов управления? Если цели проекта — это продукт, вот вам и ответ кто принимает решения в процессе. Даже при строительстве Беламор-каналла или Колизея — зеков и рабов кормить нужно было, аналогично организовывать конвоиров и надзирателей. Не считая логистики с производством и доставкой строй материалов и всего необходимого. Так что все намного проще чем кажется «No money, no honey», и просто из практики — до того как подключается человек принимающий финансовые решения никакие вопросы не решаются. Scrum Muster — вообще другие вопросы призван решить в гибком процессе, а конкретно посредник балансирующий интересы сторон (Свиней и Куриц), известную проблему продавца и покупателя — " Покупать — дорого, продавать — дешево". Это осуществляется через введение процесса — т.е. рядя стандартных процедур (практик). Как то — постановка целей, оценка сложностей и объемов работ, выявление и управление рисков , контроль исполнения и т.д. Скрам мастер следит чтобы все процессы применялись и исполнялись.

Вы путаете ответственности, задачи, с методами их достижения.
Так можно ещё вспомнить и о кондиционерах в офисе, без которых продуктивность упадёт. И стоянку для авто возле офиса, без которой програмисты будут тратить время и нервы чтобы поставить свое авто за три квартала.

Финансы не при чем, потому в команде энтузиастов стартаперов, живущих на накопленное, в кредит или зарплату супруга(и) все так же будет нужен продакт овнер, какие-то процессы и т.д.

Рычаги ж управления — обычно не финансовые, даже когда работают за деньги.

Оставьте эти наивности о деньгах как мотиваторе джунам — заплатите мне больше я стану умней и опытней и буду работать продуктивней и эффективней!

Мысленный эксперимент — давайте начнём платить всей команде в два раза больше, но посадим её в подвал без кондиционеров, в доме под снос, с туалетом на улице.

Так что, важнее для продуктивности окажется ?

Вы в другом топике кажется писали про приход к компании «пушного зверя» если у нее начались проблемы с финансами ? Чем проект в этом случае отличается ?

Ну вы и сравнили, компанию и проект. Вы действительно не понимаете что это никак не связанные вещи? Тогда начинайте с чтения википедии. Извините, неинтересно цитировать эти базовые термины

Проект и продукт не одно и тоже. От слова совсем.

Внимательно посмотрел в Scrum Guide, нигде не нашёл про финансы в описании роли Product Owner. Вы не могли бы уточнить, пожалуйста, откуда информация про финансовую ответственность?
Ещё, если я правильно понял, Вы хотите сказать, что проджект-менеджер — это и есть Product Owner. Скажите, пожалуйста, зачем, как Вам представляется, люди изобретают новое название должности, если есть вполне себе готовое, прямо из канона?

scrumguides.org/...​-guide.html#product-owner The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. — ключевое is accountable — подотчетный. Смотрим толковый словарь — slovar.cc/rus/tolk/82317.html
1. Выдаваемый с условием последующего отчета о расходовании ( о деньгах ) .
2.Обязанный отчитываться ( в своей работе, действиях, расходовании средств и т.п. )

Надеюсь убедил, Product Owner — в Scrum человек прямо ответственный за финансирование. Если в каком то проекте — это не так, значит роли в нем определены не правильно. Скорее всего там и вообще Fragile со «спиралью». О чем и все статья.

А программист отчитывается о том за что деньги получает. Значит тоже это его роль — учитывать выделенные на него деньги и отвечать за их расходование — просидел на ютьюбе два часа,...

Глянул в гугл, а то надо же какая новость про обязанности продакта...
Первая ж попавшаяся
Product Owner: 7 ключевых обязанностей
vc.ru/...​-klyuchevyh-obyazannostey

Нет, простите, совсем не убедили.
Не стоит сначала переводить термин, а потом смотреть на его значение. Можно сразу посмотреть на значение: dictionary.cambridge.org/...​onary/english/accountable. По сути, accountable это completely responsible. То есть, The Product owner is completely responsible for maximizing value of the product. То есть отвечает за максимизацию пользы от продукта. Что в рамках Скрама звучит весьма разумно.
Но по-прежнему непонятно, откуда следует, что Product Owner отвечает за финансы. Возможно, вам удастся найти что-то из Швабера или Сазерленда, где они об этом пишет. Из Scrum guide пока совсем не видна связь между Product Owner и финансами.

Константин, спасибо за комментарий. Мы как раз хотели больше рассказать о реалиях в наших проектах. А реалии таковы, что у многих в «Скраме» появляются проджект-менеджеры, а не скрам мастера. И это часто выливается в микроконтроль членов команды со стороны человека, стоящего «наверху», чем в помощь от скрам-мастера и самоорганизацию команды разработки.

А как Вы думаете, Анастасия, почему реалии таковы, что появляются проджект-менеджеры? Есть же Scrum guide, там всё понятно написано, как Вам кажется, почему вдруг появляются проджект-менеджеры?

Простите, что встряю в эту ветку, но очень уж хочется поделиться одной причиной, которую встречал в своей практике: «Потому что должен быть кто-то один, кто отвечает за проект».

И, Product Owner на эту роль не подходит, т.к. чаще всего находится со стороны заказчика.

Именно, Дмитрий, спасибо, я именно к этому и веду! Заказчика вообще не интересует, Scrum там, или что угодно ещё, его интересует сколько стоит, когда будет готово, и с кого спрашивать.
Пытался, чтобы люди сами догадались и написали :) Но спасибо большое за помощь, так мысль будет донесена горазно быстрее и понятнее.

Константин, мы этот факт не отрицаем. Большинство людей в нашей стране (как и я, собственно) работает в аутсорсе или аутстаффе и сталкивается с такой ситуацией. Но в этом случае, как по мне, стоит вообще подумать о целесообразности использования Scrum, когда есть четкие ограничения, сроки и оценки. Scrum — это больше про то, когда заказчик вовлечен в процесс в роли Product Owner

Scrum — это больше про то, когда заказчик вовлечен в процесс в роли Product Owner

Что в аутсорсе встречается совсем не редко

Все же больше в аутстаффе. Ну и я не говорю, что прям везде заказчики не включены в процесс. Заказчики разные, проекты тоже.

Scrum — это больше про то, когда заказчик вовлечен в процесс в роли Product Owner

Не совсем очевидно, откуда следует, что если заказчик демонстрирует признаки вовлечённости в роль Product Owner, то отсюда непременно следует Scrum. Было много случаев работы, когда заказчик ну вот прямо эталонный Product Owner по скраму, а на стороне исполнителя нет никакого Скрама, и всё прекрасно работает.
То есть скрам не является необходимым. И при этом, поскольку Скрам не гарантирует успех, он не является достаточным. То есть это просто некоторый нишевый подход, имеющий строго определённые показания к применению. Но при этом его пихают везде, где можно и где нельзя.

...стоит вообще подумать о целесообразности использования Scrum...

Вот тут согласен полностью.
Хочется в целом понять, откуда такая увлечённость Скрамом, буквально на уровне религии. Даже в статье исползуется слово «исповедующий», команда, исповедующая Scrum. Понятно, зачем это Шваберу с Сазерлендом, они на этом деньги зарабатывают, но зачем это остальным?
Причём болезнь зашла настолько далеко, что бывает, что люди кроме Скрама и Канбана ничего не знают вообще. Не читали PMBOK, не читали Бека, не слышали о Кобурне. Начиная с определённого момента времени стало очень тяжело найти вменяемого ПМа, который не пугается термина earner value analysis и умеет работать с людьми. И это печалит.

Заказчика вообще не интересует, Scrum там, или что угодно ещё, его интересует сколько стоит, когда будет готово, и с кого спрашивать

Не всегда. Бывают заказчики, которые сами хотят работать по скраму и активно участвуют в процессе.

С другой стороны, вопрос «с кого спрашивать» волнует не только заказчика, но и внутренний менеджмент компании.

Его станет это интересовать как только от проектов они перейдут к продуктовый разработке.

Не могли бы Вы развернуть тезис, пожалуйста. Что именно станет интересовать, и, главное, почему.

И, Product Owner на эту роль не подходит, т.к. чаще всего находится со стороны заказчика.

очень правильная тонкость!

продакт обязан быть на стороне исполнителя, а не заказчика :)
а со стороны заказчика — вице-продакт :)

Потому что заказчик обычно — не умеет разрабатывать программные продукты.
то есть — ни формулировать требования, ни анализировать их, ни выбирать архитектурные решения, ни просто — код писать.

а когда продакт, архитект, БА и т.п. на строне заказчика, то исполнитель тогда
атусорсер/аутстафер

Ну вот по-разному. Если это аутсорс — да, если аутстафф — не совсем. Я сейчас работаю в смешанной команде и у нас прям вперемешку наши люди и люди со стороны заказчика, даже без четкого разделения «я заказчик, ты исполнитель»

то есть — ни формулировать требования, ни анализировать их,

Product Owner — это, в первую очередь, тот, кто наделён полномочиями принимать решения по scope и приоритетам. Анализ и докуметирование требований — вторичны, и могут быть делегированы помощнику со стороны исполнителя.

Согласен со многими вещами в статье, думаю, многим полезно будет прочесть.

В идеальном Scrum-проекте все участники должны быть многофункциональными.

Вот эту фразу часто встречаю, но она же совсем не про это. Она не про то, что каждый должен уметь в разработку, UI, UX, бизнес анализ, инрфаструктуру. Она про то. что команда сама без дополнительной помощи может выполнить цель спринта. То есть в команде есть все необходимые навыки

Для большого и долгосрочного проекта кросс-функциональные команды не подходят.

типичная фраза из статей о кросс-функциональных команадах.

Имеется в виду — что команде не нужны командиры на каждый чих. Они могут самостоятельно выполнять всю работу, и если нужно самостоятельно связаться с пользователями системы и решить все вопросы. В условиях аутсурсинга и тем более аутсафинга, почти что полностью невыполнимое требование из за особенностей бизнеса. Скажем некая команда в «СНГ» пишет софт для заказчика в Великобритании. Этот софт используют в колл-центре. Сам кол центр — это третья компания из Индии. Без контрагентов на стороне заказчика — разработчики вообще слепо-глухо-немые. Никаких прямых контактов между пользователями и разработчиками физически быть не может.

Имеется в виду — что команде не нужны командиры на каждый чих

я в курсе что имеется ввиду.
откуда только такое количество митингов и потребность в тимлидах и пиэмах берется, для таких самостоятельных :)

Они могут самостоятельно выполнять всю работу,

бывают такие команды конечно, что могут.

но обычно — не могут :)
средний программист даже ТЗ не в состоянии написать, не говоря о том чтобы собрать требования.

Скажем

и везде будет прослойка менеджмента.

Никаких прямых контактов между пользователями и разработчиками физически быть не может.

именно.
то есть — прямого общения исполнителя и потребителя — не будет.
а это общение — краеугольный камень для аджайла.

а раз такое общение невзоможно — то никакая команда самостоятельно не может выпустить фичу.
только по спущенным сверху спекам, ТЗ, и т.д. — что превращает разработку в «водопад» или иную итеративную.

В условиях аутсурсинга и тем более аутсафинга, почти что полностью невыполнимое требование из за особенностей бизнеса

именно.
поэтому там и не может быть аджайла, и от скрама там — копыта с хвостом.

Почти со всем согласен, только один нюанс — часто в состав команды включают БА, который является полноценным участником команды и тогда нет проблемы по ТЗ и требованиям которые приходят «не из команды». Естественно, в услувиях аутсорса-аутстаффа — редко выполнимо.

часто в состав команды включают БА

согласен, тогда такая команда может претендовать на звание кроссфункциональной.

вообще ж, речь не об абсолютной невозможности.
и бирюзовые команды существуют, и кроссфункциональные команды, и T-shaped специалисты

речь о том что в большинстве случаев — этого всего или частями нет, не было и не будет :)

а бирочка — у нас Скрам — да, будет. хорошо если просто бирочка, без обслуживаия этого карго культа

В общем результаты опросов которые провели авторы только подтверждают результаты исследований которые провели NASA. Пытаясь понять почему введение agile не приносит результата в большой части команд, тогда как в других напротив к внушительные результаты — выяснилось что в тех командах где результата нет — никакого agile тоже нет. Там только декларируется что есть гибкие методологии — а на самом деле другие процессы, как правило бюрократические с откровенной тиранией. В итоге это назвали Fragile (липовый agile) также известен термин ScrumBan или Срам. По итогу ввели методику оценки проектов чтобы отделять настоящие гибкие методологии от фальшивки habr.com/ru/post/436866 и
Из моей практики большая часть команд «работающих по Scrum» — в лучшем случае работают по водопадному подходу с диаграммой Ганта. А как правило вообще по «ляп ляп и в продакшн». Причем изменить процесс может фактически только профессионалы из специальных организаций или отделов вроде PMO. Причем смысла работать с рядовыми исполнителями сразу нет — на гибкие методологии должно пойти начальство. Иначе толку не будет никакого.

По итогу ввели методику оценки проектов чтобы отделять настоящие гибкие методологии

Ключевые признаки, что проект не очень гибкий — типичные признаки основной массы айти проектов :)

я их свожу короче так:
Аджайл — не работает если есть истинно одно из двух:
1. Заказчики не могут по нем работать
2. Программисты не могут по нем работать

А так в большинстве случаев соблюдаются оба условия, то все проще
Аджайл — не работает.

а в аутсорсе — так наверное все 90% проектов — напрочь не аджайловые.

По статистике во всем IT — 75% не гибкие подходы, включая FANNG-и т т.д. Если руководитель не понимает как оценивать проекты по стоимости в гибких подходах — будет галера которая для моды будет заявлять что работает по гибкой методологии. Но ходить на тренинги руководству самим в западло и они поэтому посылают туда: программистов, аналистов и тестировщиков — а потом в работе все равно все по старому. Надо ещё учесть что половина — вообще не планирует работу даже через диаграмму Ганта. Просто есть распорядка — " закончить к Декабрю до Черной Пятницы«. И погонщики плетьми будут гнать всех в шею и овертаймы, даже если такой объем физически выполнить текущими силами невозможно. А под конец ещё и увеличат команду в двое понимая что никак не успеть. А тут вдруг «закон Брукса» ... В общем это уже к топику про «некомпетентность в ИТ».

По статистике во всем IT — 75% не гибкие подзоды

«и вы говорите»

включая FANNG-и

там то как раз он и встречается не чаще чем в аутсорсе :)

Надо ещё учесть что половина — вообще не планирует работу даже через диаграмму Ганта.

и правильно делают. она вообще не годится для айти проектов.
еще и точно — не из мира аджайл :D

По статистике во всем IT — 75% не гибкие подходы, включая FANNG-и т т.д.

Все просто боятся себе признаться в том, что аджайл вообще и скрам в частности ложатся далеко не на каждый проект и не на каждую компанию. При этом это давно превратилось в обязательный культ, который насаждается среди нижнего и среднего звена. В итоге на словах все добрые скрамиане, а на деле забиваем на ретро (а почему не забить если основные проблемы снаружи команды и повлиять на это никак нельзя?) и оцениваем задачи в часах (а почему бы не оценивать если бизнесу интересно когда будет готово, а не сколько там сторипоинтов?).
Но, должен сказать, что при всем моем аджайл-скептицизме работающие примеры я видел. Не рассматриваю свой опыт как что-то статистически значимое, но моя личная статистика совпадает с озвученной выше: 25% это аджайл и работает, 75% это имитация вкусного борща.

почему не забить если основные проблемы снаружи команды и повлиять на это никак нельзя?

И при этом мы никогда не узнаем о проблемах внутри команды, которые легко могут похоронить проект, т.к. убрав ретроспективу, забрали у команды право голоса.

и оцениваем задачи в часах (а почему бы не оценивать если бизнесу интересно когда будет готово, а не сколько там сторипоинтов?).

Вот это — моё любимое.
А потом разработчики у нас «плохие», потому что не укладываются ни в какие сроки. Даже в те, что начальство сверху спустило — они же самые точные, ведь начальство же самое умное и всё знает.
Дальше начинается поиск священного Грааля — труъ Сениора на рынке труда, который просто придёт и всё сделает одной левой.
А когда находим, кидаем его на проект без бэклога, ставим задачи устно и с удивлением выясняем, что он самозванец и перформит хуже нашего самого слабого джуна.

Согласен 100%. Почему-то многие берут из SCRUM какой-то кусочек и потом жалуются что он «не работает».
Даже в этой статье ничего не говорится о роли Product Owner которому организация должна отдавать 100% контроля над проектом, что происходит мягко говоря не всегда. А без настоящего Product Owner это уже совсем не SCRUM.
То есть — наличие и соблюдение всех церемоний совсем не означает что это SCRUM

без настоящего Product Owner это уже совсем не SCRUM.

без Product Owner — всегда беда и тяготы, при любом способе разработки

а когда он есть, и толков, то становится пофик, скрам, lean или «водопад»

при наличии продакта — разработку уже ничем не испортишь.
разве что — сверхнизким бюджетом :)

при наличии продакта — разработку уже ничем не испортишь.

Изи. Продакту достаточно ставить задачи устно.

Продакту достаточно ставить задачи устно

ораторским приемом — доведение до абсурда — надо уметь пользоваться.
а то выйдет демагогия:
а если продакт есть и молчит?

но вы продолжайте конечно. искренняя демагогия — это среди коллег которые должны бы уметь мыслить — вполне массовое явление :)

доведение до абсурда

Это не абсурд. Это реальные кейсы, которым я был свидетелем.
И главное, человек потом искренне не понимал, почему произнесённое им за 10 минут не было воплощено в точности в коде по истечению 2-х недель. Ну как это, ты с первого раза не запомнил, что я говорил? А почему не записывал за мной?

Это реальные кейсы, которым я был свидетелем.

а я был свидетелем, многократно что программисты с лычками не в состоянии прочесть написанное.
И?

А почему не записывал за мной?

если у них было положено записывать, то надо было — записывать.
у меня буквально 10 минут минимитинг был.
у нас принято — записывать.
я записывал, сразу себе в викидпад, во время разговора. что показалось невнятным — переспросил.
И?

я не знаю что там в вашем случае было. да и к теме об ответственностях и ценности продакта — ни ваш, ни мой случаи не имеют отношения.

если у них было положено записывать, то надо было — записывать.

Им надо — пусть они и записывают.

да и к теме об ответственностях и ценности продакта — ни ваш, ни мой случаи не имеют отношения.

Продакт оунер, о деятельности которого не остаётся письменных свидетельств, по факту — не существует. И к сожалению, не все кто себя называют продакт оунерами это понимают.

Им надо — пусть и дискутируют с тем кому не надо.

Тем более демагогом

Да даже с церемониями есть большой вопрос. Например когда зозвон по статусам задачь в ходе которого отслеживают что проект в диаграмме Ганта идет по намеченному плану (двигают джира тикеты по борде) — называют daily stand up. Но это вообще ничего общего не имеет с stand up-ом, и вообще с командной работой над проектом. В таком «стандапе» даже тупо молчать можно — если на тебе тикетов не за асайнено (скажем все сделал, и до релиза в беклоге больше ничего нет, за самоуправство вроде закрытие тех депта — еще и выговор схватишь).

Кстати, да, хороший момент. Мы больше смотрели на это все со своей колокольни, но вы верно подметили насчет PO. К сожалению, такая «власть» — это редкость

При этом PO должны быть реально оунерами. А не прокладкой между владельцами бизнеса и гребцами, которая ничего не решает, а играет роль передаточного звена (хорошо если без эффекта испорченного телефона).

также известен термин ScrumBan

Давайте не путать ScrumBut (он же ScrumButt, он же «скрамно») с вполне себе рабочей методологией ScrumBan, в которой взято лучшее из Scrum и Kanban.

цитата: Первое, чем встречает Cкрам гайд (вернее, технически, это одна из последних в нем строчек) — невероятная жесткость, прямо противоречащая agile-принципам. Прекрасно помню абзац:

«...Детальное описание фреймворка представлено в рамках этого Руководства. Роли, артефакты, правила и события Скрама не подлежат изменению. Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом. Скрам существует только в качестве цельного фреймворка, но он может вмещать в себя другие техники, методологии и практики.»

ЧЕРНАЯ КНИГА СКРАМ
pmjournal.ru/...​ysy/chernaya-kniga-skram

Кратко:
Скрам — это та дохлая лошадь на которой пытаются скакать.

Те кто это почувствали, а целей то надо достигать, потому и слезли с нее — и попали в нарушители-богохульники:

Думаем, всем, кто сам работает по Scrum,

Стратоплан подкаст: про гибкие методологии (S2020E02) SCRUM — AGILE — LESS — SAFE и куда все идет
www.youtube.com/watch?v=D_XBtLP2wDk

Те кто это почувствали, а целей то надо достигать, потому и слезли с нее

Не совсем понимаю как следование SCRUM противоречит достижению целей.
Видел много команд, которые:
— не следуют SCRUM и достигают целей
— следуют SCRUM и достигают целей
— не следуют SCRUM и НЕ достигают целей
Область применения SCRUM — между полной определенностью и хаосом, и не подходит всем-всем-всем. Но сказать что это «дохлая лошадь» — тоже не могу, потому что своими глазами видел живых.
По поводу отношения Ивана С. — я его безумно уважаю как хорошего РМ-а, но не не вижу особой логики в том что он потратил (инвестировал) много времени-денег на обучение РМ и почему-то считает что понимание SCRUM этого не требует (имхо).

Не совсем понимаю как следование SCRUM противоречит достижению целей.

он не противоречит достижению целей.
он просто не работает, либо ему невозможно создать условия, чтобы работал как в книжке написано.
поэтому ему и не следуют, а выковыривают из него, и много другого то что приживается

а тех кто

следуют SCRUM

 я не встречал ни в жизни ни на доу.
говорят конечно что следуют :)
бирочка такая есть, вот и «следуют».
если сказать вслух что нет такой бирочки — могут предать анафеме.

По поводу отношения Ивана С.

если б это было мнение только его, то я бы его не приводил.

библиография о том что SCRUMу не следуют, потому что он не работает — огромна. за последние лет 15 обчитался, и обхоливарился :)

но как всегда — есть реалии, действительность, а есть теория, мода, иллюзии, веровования в серебряную пулю, и прочая.
поэтому принято закрывать глаза, и продолжать петь мантру, «идея то красивая!»

Вы говорите что не работает потому что не видели работающего, а я видел работающий, по книжке. И что делать дальше? Я вам могу поверить, а вы мне?

а я видел работающий, по книжке

Scrum Master — конечно видит работающий

я говорю потому что много думал и расспрашивал — так отчего ж не работает?
что в самой идее «коммунизма», «скрама», «...», не так, что эта красота и простота нежизнеспособна?
при этом вера — прочнее в нее некуда, и паствы все прибывает.

И что делать дальше?

кому?

Я вам могу поверить, а вы мне?

не надо мне верить.
все есть в интернете.

я всего лишь бросаю зацепки, для начала избавления от иллюзии.
с чего можно начинать раскручивать тему.
тому, кому интересно разобраться в вопросе.

но большинству да, неинтересно, хотя бы потому что они все равно ничего не смогут изменить глобально. но главное — за это денег не заплатят :)
и придется играть в эту игру и дальше — «у нас Скрам, и он — работает!»

но, будет меньше уходить ресурсов на участие в этой игре.
забыл, как она именем одного психолога называется
ну когда никто не хотел ехать в зоопарк, но каждый сказал — да, я хочу поехать — и все поехали

Могу конечно ошибаться, но похоже на случай когда вы фильтруете информацию и выбираете только то что соответсвует вашей точке зрения, начисто отметая все что ей противоречит. Я читал и смотрел многое из того о чем вы говорите и почти во всех таких случаях могу понять — почему не работает (а иногда и не может-должно работать), при этом я пытаюсь в своих командах сделать так чтобы работало, проверяя себя и команду через обратную связь и чек-листы.
Проекты при этом выполняются успешно, так что цели мы тоже достигаем.
То о чем вы говорите — мне знакомо, и думаю что может быть связано со спецификой местного аутсорса когда вешают табличку SCRUM и думают что этого достаточно. Если вы в жизни не встречали нормального SCRUM который я видел в основном в продуктовых команиях — вас никто не сможет убедить что такие есть. Если SCRUM не идет со стороны топ-менеджмента — то его и не будет, это 100%.
Видимо вы и другие люди как раз сталкиваются с такими примерами (тоже видел и работал).
Могу еще сказать что видел PM-ов разной степени успешности которые никогда не читали PMBOK, но как по мне это не значит что PM как дисциплина не работает.

но похоже на случай когда вы фильтруете информацию

да, фильтрую.
смотрю сноски, противопоказания, и т.д.

давайте чуть отстаренно, о том как я фильтрую.

а массово смотрят на достижения об успехе.
классический пример:
все смотрят и рукоплещут — стартап Х взлетел!
а я смотрю на статистику, по разным оценкам от 95% до 97% дальше первого раунда не доживают. и, смекаю себе — так это всего лишь те что попали в эту статистику. а сколько умерло не успев попасть?

почти во всех таких случаях могу понять — почему не работает

конечно. в каждом случае будут конкретные причины, которые, наверное, можно было и вполне устранить.

вопрос в другом, что есть нормальным — смерть стартапа или успех?

Проекты при этом выполняются успешно, так что цели мы тоже достигаем.

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

вы такой информации публично не предоставите, даже если и знаете ее :)

так что вот он — второй фильтр: а возможен ли другой ответ?
ну знаете, как вопрос о вопросе
если на данный вопрос нельзя отвечать по другому — то зачем его вообще задавать?

при этом я пытаюсь в своих командах сделать так чтобы работало

а это — вообще не имеет отношения к работоспособности Скрам.
вы можете быть очень талантливым и трудолбивым человеком, и из говна сделать конфетку.
гуано код можно писать и на С++, а классный на PHP, и т.п.

Если вы в жизни не встречали нормального SCRUM который я видел в основном в продуктовых команиях

вот, уже кое-что. указано эмпирическое ограничение для «нормального SCRUM» — «в основном в продуктовых команиях»

думаем дальше — а почему так? что такого в самом SCRUM что он «в основном в продуктовых компаниях»?
обычно — не думаем. а списываем все на невежество, неграмотность, и т.д ну то есть чтобы не думать а удовлетвориться ответом заглушкой.

Вася плохо работает потому что — ленив!
и все хорошо, ответ типа есть :)

Если SCRUM не идет со стороны топ-менеджмента — то его и не будет, это 100%.

о, вот второе интересное эмпирическое наблюдение.

читаем мой пост dou.ua/...​ment/?from=slider#2074769

Видимо вы и другие люди как раз сталкиваются с такими примерами (тоже видел и работал).

далее, о «и выбираете только то что соответсвует вашей точке зрения»

я как раз — отталкиваюсь от таких примеров, потому что давний фанат — аджайл :) просто потому что мне нравится работать по этим принципам. понимаете в чем прикол — я собственно фанат аджайл, и знаю и когда он превращает в хаос разработку, и чем его подпереть, и когда он — карго культ.

Могу еще сказать что видел PM-ов разной степени успешности которые никогда не читали PMBOK, но как по мне это не значит что PM как дисциплина не работает.

полностью согласен.

и о том рядом писал, и те кто не читали ничего кроме хайповых статей по Скрам — живут по «водопаду», ну свято уверены что у них Скрам, потому что у них есть вот такой его атрибут, такой и эдакий. и потому что — достигают своих целей.
значит у нас — Скрам!

а когда начинаешь выяснять, а чего ж из Скрама у вас нет вот этого, того и такого — и получаешь ответ — ну-у-у-у, мы пробовали, полная ерунда получается. почему? мы старались, но потому и потому.

и эти ответы публично мало кто даст. потому что за такое признание в своей неспособности реализовать ортодоксальный Скрам — будут заплеваны тусовкой. причем такими же «неспособными» даже больше, чем евангелистами :)

вот так я фильтрую :)
учитываю — вероятности скрытого, недосказанного, ошибки выжившего, подверженность «давлению общественного мнения» и т.п.

Scrum Master — конечно видит работающий

 Да всякий видит работающий. Ключевая особенность когда понятно что скрам заработал — людям самим нравится работать. Они вкалывают как сто китайцев без внешних пиндюлей и т.п. Только сначала, конечно, когда ставится процесс — бывает все и конфликт обязательно будет на второй фазе. Обязательно заказчик/начальник будет жостко препятствовать — либо устраивать «срам» где совсем другой процесс так будет называться. Либо вообще — требовать уволить скрам мастера и т.д. и всем прямо заявлять, с пеной у рта — что это не работает и туфта, и вообще хватит разрешать молодым играться. Многим людям родом из прошлого столетия это бьет в мозг, весь их предыдущий опыт говорит что так не бывает и не может быть. Потом вдруг начинает получаться, все начинают учится на собственных ошибках и т.д. ну и в конце релиз.

что скрам заработал — людям самим нравится работать

а если скрама нет — то людям не может нравиться работать?

всем прямо заявлять, с пеной у рта — что это не работает и туфта

если я правильно понимаю это аргумент на все случаи жизни
«это потому что вы не умеете X готовить!»
?

ну типа — а чего Java? а это потому что ниасиляторы С++ кругом.
а Go почему? а потому что и Джаву уже не могут осилить.

Потом вдруг начинает получаться

а это аргумент
Если долго мучиться — то что-нибудь получится?

ну и в конце релиз.

да, без скрама релиз никак не получить....

Потом вдруг начинает получаться

Скажите, пожалуйста, что делать, если не начинает получаться? И заказчик не против, и начальник, а не идёт, и всё. Что делать, к кому обращаться?

Выполнять процедуры так же как и на тренингах. Ввести DoD, DoR, создать список пользователей системы и шаблоны пользовательских историй. Не брать неподготовленные (не отвечающие DoR и DoD критериям) user story в спринт. Ввести planing и estimation poker либо на всю команду если она без специализации (например frontend, backend) либо 3Amigo. Вести статистику, вычислять Velocity и Capacity, не брать в спринт работы больше чем физически можно выполнить. Проводить daily stand up не по тикетам — а по людям, где каждый отвечает на три вопроса — что он делал, что сделал и что будет делать. Следить за временем — максимум 4-ре минуты, останавливать если обсуждение идёт слишком долго и созывать 3Amigo по прицендентам. Проводить ретроспективы, записывать action point-ы и назначать ответственных за их исполнение. По идее все. Из практики: ещё на DoD, DoR и планингах — где вы говорите «нет эта история не определена и мы ее не можем оценить» или «вот эти истории в спринт взять не можем, потому что физически не сможем закончить такой спринт» — вот тут вы и увидите как заказчик «не против».

Скажите, пожалуйста, я правильно понимаю, что утверждается, что если выполнять все шаги, как Вы описали, то всё начнёт работать автоматически?

«Автоматически» — это вы о процессе по которому работают люди. Тут нет автоматики. Работать начнет — но это будет стоить существенных усилий и нервов. Далеко не все захотят в самом деле работать по такому процессу, не все захотят смирится с фактом что проект скорее всего займет существенно больший срок и бюджет чем планировалось. Что придется отказаться от части функциональности, придется ставить приоритеты, и нельзя будет ставить всему максимальный приоритет и т.д. В общем нет пока процессов организации труда которые работают сами по себе.

В общем нет пока процессов организации труда которые работают сами по себе.

Вот поэтому если я вижу, что в команде продукт выше процесса, предпочитаю с ней дела не иметь.

В общем нет пока процессов организации труда которые работают сами по себе.

Скажите, пожалуйста, а кто в Скраме отвечает за то, чтобы процесс работал?

Так ведь специальный человек есть — Scrum master «хозяин толкучки» o_O.

Посмотрите, пожалуйста, внимательно на отвественность Скрам мастера в Scrum Guide. Отвечает он только за

all Scrum events take place and are positive, productive, and kept within the timebox.

Остальное он только helping, coaching и facilitating. То есть помогает, не более того.
На всякий случай напишу отдельным тезисом: согласно Scrum Guide Скрам мастер не отвечает за правильность процесса. Я надеюсь, разница между «помогает» и «отвечает» Вам понятна.
Буду рад, если меня кто-нибудь переубедит со ссылками на источники.

А при чем тут Стори Поинты к Скрам фреймворку?

Так уж вышло, что Стори Поинты для многих стали считаться неотъемлемой частью скрама. Но да, прямого отношения здесь, конечно, нет, согласна с вами

Как всегда, интересно и полезно, от Николая Алименкова www.youtube.com/watch?v=vk6dl7-3B5I

и, собственно, упомянутая статья Кона, также будет полезна www.mountaingoatsoftware.com/...​oints-for-sprint-planning

I don’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term. It would be appropriate for a team to say „We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, „We have an average velocity of 20 story points so we will finish in the next sprint.” It doesn’t work that way.

Подписаться на комментарии