Pull to refresh

Comments 157

«Вбросить» допустим получилось. Но ясности не внесло. Очень не хватает определений «цели спринта», роли скрам-мастера и PO. Потому что без них некоторые Ваши утверждения весьма и весьма спорные. Например, СМ по ванильному определению — facilitator. Обслуживать коммуникацию — это его ключевая обязанность. А это значит в том числе «забивать встречи в календаре» и соблюдать их регламент в рамках процесса.
Прежде всего, спасибо за комментарий!
Цель как раз и была «вбросить», или просто, чтобы люди призадумались, что всё не просто так и не стоит «верить слухам» ;-), а многое можно почерпнуть из уже имеющихся общедоступных источников.
Я намеренно не стал растолковывать весь Скрам-гайд, а только дал «для затравочки».
Вам конкретно отвечу:
1. Цель спринта (беру из русской версии документа, хотя рекомендую пользоваться английской, как первоисточником): «Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта.»
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
Скрам-мастер — это лидер-слуга для Скрам-Команды. Людям вне команды он помогает понять, что из их взаимодействий со Скрам-командой полезно, а что нет. Скрам-мастер помогает изменить эти взаимодействия так, чтобы они максимально увеличивали ценность, которую создает Скрам-команда.
3. Product Owner (Владелец Продукта): Владелец Продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Способы достижения максимальной ценности могут различаться и зависят от самих организаций, Скрам-команд и конкретных людей.
Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта.

Как я уже написал в статье, одна из целей — это показать, что прежде чем давать какие-либо вольные интерпретации ролям и зонам ответственности, необходимо детально ознакомиться с первоисточником.
Что такое «ванильное определение», я не знаю но, подозреваю, что это частично то, о чём я писал: секретарь, прислуга, психолог. Вот как раз НЕТ!
В идеале СМ в части работы с командой стремиться создать из неё самоорганизующуюся команду и, опять же таки в идеале, команда должна научиться обходиться без него (без СМ).
Могу ещё много писать, но не буду :-), чтобы не написать коммент размером со статью :-)
Всегда готов пообщаться в оффлайне на эти темы!
«Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.

Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.
«Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.

В принципе можно посмотреть в гайде, включая обязанности СМ для PO, DevTeam и Организации. В общем там не только фасилитация.
Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.

В целом согласен с вами. Если уже не особо требуется команде, то пора ему подумать дальше, как расти, так как есть куда.
Как в тему! Как раз читаю Scrum Guide, есть вопрос по понятию «scrum-команда». Я так понял, что она должна быть компактной (замкнутой и ограниченной), чтобы работа над артефактами итерации зависила только от неё. Как в таком случае быть с дизайнерами, которые в большинстве случаев представляют собой другой отдел?
Несколько раз упомяналось, что в команде есть всего одна роль — разработчик. Как тогда тестировать и деплоить? В общем случае этим могут (или должны) заниматься другие люди.
По Скрам-команде: должна быть кросс-функциональной и самоорганизующейся.
То, что вы, скорее всего, имеете в виду — это про кросс-функциональность (не следует путать со взаимозаменяемостью). То есть когда в команде присутствуют все необходимые компетенции для создания продукта от начала и до конца и, соответственно, она не зависела бы от компетенций извне.
В вашем случае необходимо договариваться и брать дизайнера в Скрам-команду, что, скорее всего, уже будет вопросом на уровне Организации и трансформации соответственно.
В Скрам-команде всего три роли: PO, SM и Development Team. Грубо говоря, «разработчик» (developer) в Scrum Team — это тот, кто непосредственно выполняет работу «руками» :-), например, кодит, тестит, организует маркетинговые компании и т.д. Короче не только о программерах идёт речь :-)
UFO just landed and posted this here

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

UFO just landed and posted this here

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

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

Если выясняется, что задача не может быть взята до выполнения каких-то внешних для команды (в вашем случае дизайнерских) задач, то создаётся запрос (или задача) на ПО
(мобильная версия не позволяет редактировать)
… создается задача для другой команды. И на неё ставится ссылка. А дальше ваш ПО и ПО другой команды разбираются с приоритетами
Судя по вашим комментариям вы очень даже в теме ;-)
Есть ещё такая штука как критерии INVEST, DOR (Definition Of Ready). Если вам интересно, то почитайте.
DOR — это то, что, например, про задачи внешнего вендора, от которых зависит ваша команда. Но фишка в том, чтобы не увлекаться DOR везде и всюду, так как перебор ведёт в неуместный Waterfall (я не против Waterfall, подчёркиваю «неуместный» в случае выбранного Agile-подхода).
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
В статье рассказывается нам, глупым, до сих пор не понимающим зачем стендапы, что 40 минут-то это конечно перебор и надо всего 15 (не считая времени на подготовку перед и возврат в работу после).
А всё равно непонятно, чем встречи в таком формате лучше например общего чата, где в реальном времени можно общаться, а не ждать 15-минутки следующего дня. Ну и прогресс опять же в реалтайме видно по чату и по коммитам с тикетами. Зачем эта ежедневная ритуальная клоунада с "что делал что сделано какие проблемы"? Нет ответа.
Хотя бы для того, что бы выдёргивать людей из зоны комфорта и заставлять общаться с командой. Есть определённый тип людей, которые днями могут сидеть над банальной проблемой и никого не спросить как её лучше решать. А на стендапах такое часто всплывает раньше, чем несколько дней.
А есть определенный тип людей, который бы спокойно и продуктивно поработал в зоне комфорта и не дергался бы лишний раз.
днями могут сидеть
Тупо сидеть, уставившись в одну точку, или разбираться, изучать материал, искать варианты решения, разносторонне развиваться в процессе, в конце концов? Почему вы думаете, что это в конечном итоге будет менее полезно, чем если кто-то сразу ткнет в привычный ему вариант решения?
Отсутствие стендапов не подразумевает отсутствия общения. Общение в цифровом мире штука гораздо более многогранная, от тех же групповых чатов, до просмотров чужих коммитов, код-ревью. Была бы заинтересованность в общении, если человеку пофиг, ему и стендап не поможет.
Слушайте, эти люди сидят рядом, а не в стране эльфов. Не все команды имеют шикарную возможность выбирать одно CV из 20 сениорских, многим приходится брать всех подряд, кого не взяли компании покруче. И вот среди таких, поверьте, очень многих надо строить на стендапах, что бы не закапывались в своих песочницах и не тупили днями над проблемами, которые решаются за пару часов.
Вы выдали ключевую фразу, которую я «подрежу» слегка:
Была бы заинтересованность
.
Смена методологии очень часто заставляет выйти наружу реальную заинтересованность (читай производительность, эффективность и т.п.) человека в работе. И скорее именно это уже не нравится человеку, а не «гибкость» той или иной методологии.
1. Глупыми я никого здесь не считаю.
2. Если 15-минутки идут ежедневно и в целом всё ок (все понимают для чего у них Скрам), то ненужно к ним готовиться.
3. События (обязательные встречи, если в общем) в Скрам не отменяют других встреч и прочего общения членов команды.
4. Про «клоунаду». Формат Daily Scrum может определить сама команда. Важно получить информацию по статусу движения к цели спринта и есть ли какие проблемы с этим.
В целом, если команда только начинает свой путь в Agile/Scrum, то лучше просто следовать гайду (видимо это подразумевается под «ритуалами»). Дальше, по мере того, как будет больше опыта и понимания фреймворка, всё должно стать проще. На самом деле в статье я вскользь упомянул про «сюхари» (можно посмотреть Вики) — это, на мой взгляд, как раз на данную тему.

Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.
Очень часто возникает ситуация, когда просматривая коммит коллеги, который, по моему мнению, делает там что-то не то, предлагаю ему решение, которое сам знаю. Сразу предлагаю, не ожидая следующего дня и ритуальной сходки, понимаете? Более того, даже работа с 9 до 18 с пн по пт, это пережиток прошлого, люди всегда онлайн, всегда доступны, не надо всех собирать в одном месте, чтобы донести информацию или взаимодействовать друг с другом.
Вот я здесь оставил информацию, с ней в ближайшие часы ознакомится пара десятков человек, мне не надо их ждать, собирать где-то, тратить их время, отвлекать от чего-то важного, когда им будет удобно они зайдут и прочитают (сейчас читаете), возможно даже как-то отреагируют. Вот так это работает в 21 веке.
сколько времени надо тратить, чтобы мониторить все коммиты коллег? А если он не хочет «пушить в общий репо, пока не причешу историю коммитов»?

В общем случае стендапы достаточно показательны для определения зрелости команды. Если все процессы идут как надо, если члены команды проактивны, если цели понятны, то даже 15 минут будет много. Просто шанс оттранслировать в команду происходящие прямо сейчас процессы.
Простое сообщение вида «Делаю задачу Х, столкнулся с проблемой Y, Z обещал показать как она решалась раньше» занимает 20-30 секунд, а тот, кто хочет побольше узнать о проблеме Y может просто подойти после стендапа и послушать, а что, а как.
Вам ведь никто не запрещает за пределами ежедневного скрама общаться по разным вещам. 15 минутами не ограничивается общение, это подразумевает, что у вас есть 15 минут на команду, чтобы рассказать статусы с точки зрения общей перспективы текущего спринт. То есть можно заострить внимание на какие-то важные проблемы, но самое важное, держать в курсе всех не о том, какой код и комиты вы делаете, а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.
Послушайте, у меня в сутках 24 часа, а вы хотите украсть из них 30 минут (стендап + подготовка и время на возврат к работе). Мне жалко, жизнь не вечная.
а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.
Давайте я когда сделаю, вам сразу сообщу, так не лучше будет? И если проблемы возникнут сообщу, сразу. А если вы ждете пока я что-то сделаю, чтобы свою часть начать, тоже можем договориться. Не обязательно всем собираться в кружок, да ещё каждый день.

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

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

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

У нас просто график условно гибкий, люди подтягиваются на работу в первой половине дня до обеда включительно, поэтому стендап проводится днем, чтобы все были на месте.
У нас эту проблему решили переносом стендапа в отдельный канал в слаке. Да, личное присутствие важно, но мы вообще-то все равно в одном офисе и нужно сильно постараться чтобы друг друга не увидеть, так что это не такая большая проблема. Зато все, кому нужно, могут прочитать текущий статус, более того, есть история этого статуса что тоже неплохо, но при этом никто не отрывается от работы в неудобное время — пришел, составил план на день, проверил что сделано за предыдущий день — и написал.
Я понимаю, что есть люди, которые предпочитают такой режим, и в нем работают вполне успешно. Но на мой взгляд, когда речь идёт о большом проекте, где работает команда из большого количества людей, и кроме такой команды есть ещё другие команды и им надо синхронизироваться и так далее, то это бывает очень полезным и важным. Скрам — это не лекарство от всех бед, есть много методологий и они работают не хуже. Просто если процесс поставлен правильно, то обычно понятно, зачем в данном случае используется такая методология итеративная.
Одна из важных причин, почему так же используется Скрам — это прогноз и оценка, планирование. Я понимаю, что такие вещи могут не интересовать простого разработчика, но с точки зрения продукта — это важно, потому что это деньги. Чем более точное планирование, тем больше денег сохранит бизнес (в общем случаеъ есть много специфики от области бизнеса). Например, если разработка ведётся итерациями и все это мониторится, собираются метрики, то спустя какое-то время можно сказать, на какой капасити команда может 100% отрабатывать, и вы будете удивлены, на сколько точно такие «предсказания» работают. Но это при условии корректной интерпретации и применения методологии. Если коверкать понимание методологии, то лучше делать без неё. У меня есть опыт работы в компаниях, где использовали скрам, потому что надо бы, и от этого процесс страдал. И наоборот, работал там, где процесс поставлен грамотно, и разница видна очень сильно.
Я не призываю использовать скрам. Потому что он не всегда подходит, есть много причин его не использовать, в зависимости от многих факторов. Но нередко правильное применение скрама наводит правильный порядок и упрощает разработку продукта.
Вы можете привести хоть какие-нибудь цифры, позволяющие сравнить состояние «до» и «после» внедрения скрам?
Так я даже не против мониторинга, метрик, вот этого всего. Могу в конце дня (в начале, в середине) отписываться в систему контроля о прогрессе работы и проблемах, пусть заинтересованные лица мониторят. Проблему вижу именно в ежедневных ритуальных плясках в хороводе. Ну это как сейчас в 21 веке по мобильному телефону позвонить, застать человека в совершенно неожиданном месте вроде туалета, пообщаться («алё! алё! слышно меня? эс как доллар!»), потом ещё забыть половину сказанного, вместо того чтобы сообщение написать в мессенджер.
UFO just landed and posted this here
Я как раз от крупных компаний и отталкивался ;-) и прекрасно знаю, что в первую очередь СМ это почему-то психолог/психиатр/психоаналитик :-)
Согласен с вами, что карго-культ, который в итоге получается, ничего кроме негатива не вызывает.
Об этом в том числе я и писал.
Я смотрю на комментарии и понимаю, что многие восприняли мою статью, как оду Скраму, как к призыв к тотальному переходу на него. На самом деле это не так, но каждому я не собираюсь это доказывать.
Эта статья на «задуматься», а не «мы все в Скрам!».
UFO just landed and posted this here
UFO just landed and posted this here
Верно в отношении того, что на Daily проблемы не обсуждаем, а обозначаем.
Насчёт их решения не понял, почему теряется день. Если проблема важная, то никто не мешает её обсудить сразу после Daily. В общем вопрос организации своей работы, в частности, вопрос приоритизации.
UFO just landed and posted this here
Но ведь это никак не связанно с собственно дейли. Точно такие же проблемы будут и без него.
UFO just landed and posted this here
Ок, связанно. Но в этом есть совершенно определенный смысл: составить список проблем перед тем как начать их решать. Если человек с которым вам нуно решить проблему не в состоянии задержаться после дейли и дейли — это единственное время когда его можно поймать, то проблема не в дейли. Если у вас нет возможности заронировать переговорку вне дейли — проблема тоже не в дейли. А вот если у вас нет возможности на дейли высказать свою проблему потому что все отведенное время все решают проблему того кто начал первым — вот тут уже проблема именно самого дейли. Так чем собственно такое решение для 15 минутного митинга плохо то?
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой

Ну, тогда этот кто-то просто по факту обращается к коллегам, в общий чат, например — он же сам понимает, что тупит над решением. После первого-второго такого скрытого случая ему объяснят, что если ты тупишь, то обратиться к коллегам — не зазорно.
Зачем тут ежедневные летучки?
Столь лаконичный тезис сразу рождает вопросы:
1. Кому не нужен?
и
2. Когда не нужен?
никому и никогда не нужен
Если команде нужен скрам-мастер, значит пора сменить команду
1. Если команда хочет работать по Скрам, значит СМ ей нужен.
2. Если команда работает не по Скрам, СМ ей не нужен.
Вроде основные ситуации разобрали.
развелось вас, болтунов и лоботрясов. менеджеров не хватает чтоли?
назови как-нидь еще тогда «НЕДОКРАМ», пойдет название? или тебе надо простыню текста еще написать, как правильно жить по «НЕДОКРАМ»у?
ПС: не просите только уточнять: «каких именно не хватает?, когда они не нужны?»…
При первом знакомстве, на мой взгляд, неправильно хамить.
Подобное отношение, как у вас, встречал и довольно часто. Не назвал бы его высокоэффективным.
А просить, или оправдываться перед вами и не собирался, так как в данном случае это всё равно что «бисер перед...» (дальше наверное известно).
называю вещи своими именами.
есть что ответить по сути? чем отличается СМ от менеджера, кроме того что он прочитал портянку текста об скраме?
Вам нечем, потому что, исходя из своего опыта (очень большого кстати), это бессмысленно. Потому что начинать надо издалека, минимум, с 90-х.
Но здесь это будет потерей времени.
опять слова-слова…
я думаю все все поняли.
Вы похожи на Свидетеля Скрама. Вам показалось, что вы поняли все, но на самом деле, вам кто-то продал мысль о том, что некие модели управления могут заменить лидера. И вот такие недолидеры, которые боялись брать на себя ответственность, потому что они хреновые лидеры и все просирали, придумали как её(ответственность) размазать по куче людей. И в случае чего сказать — это не я говно, а команда. Я то все по скраму делал…
Вы ошибаетесь, мне никто ничего не продавал.
Что касается ответственности, то в итоге она на PO, например. Он отвечает перед стейкхолдерами. Так что, как минимум, одного ответственного отыскали.
Если вы делите PO и DevTeam, то это уже не команда (то есть не та самая Scrum Team).
По скраму команда самоогранизуемая, и вот когда стекхолдеры спросят с PO за просраный дедлайн, тот в лучших традициях, скажет — «команда сработала не так, а я что?? Я то все по скраму делал, а вот Вася с Петей в скрам не верят вот и все пошло по п… не так».
Вот как так получилось? Вроде на русском написал, но как то не очень похоже на русский.
Это про частые реалии и здесь я спорить не буду. Те, про кого вы написали — это не PO и, соответственно, это не команда. Есть ещё одна схожая ветвь, когда без стейкхолдеров «типа PO» начинает в конце спринта неприятно удивляться результату, выданному DevTeam. И это тоже не PO и не команда.
Но не только в книжках, но и в жизни я встречал и работал с командами, которые были единым целым — Scrum Team. Там, в общем-то было без сюрпризов и без «размываний» и прочих «размазываний» ответственности.
В одном из своих комментов я уже ссылался на одно интервью, где речь шла о совсем других компетенциях (более высокого уровня), когда идёшь в гибкие методологии.
Скажите честно, это были вполне коммуникабельные профессионалы своего дела? могли они также эффективно работать без скрама? Дал ли скрам стабильный прирост эффективности хотя бы 20% на протяжении года или двух? Было ли это экономически оправдано? То есть, дополнительное время которое уходит на планирование в рамках команды, ретроспективы, митинги, демонстрации помноженное на стоимость человеко-часа, оно приносит экономический эффект для этих продуктов? ну и про реалии тоже не стоит забывать в вашем ответе
Я считаю, что даже специалистам высокого класса можно было бы извлечь пользу из гибких методологий.
В ваших сообщениях чувствуется «боль потери времени на совещания». Это может быть вызвано тем, что:
1. Может Скрам в принципе не подходит для вас (Скрам — не серебряная пуля).
2. Может нет реального понимания, как правильно проводить эти совещания. Нет «того СМ», который должен был объяснить, что к чему.
Одна из интересных вещей, которую я в своё время открыл в Скрам — это то, что оказывается в нём тоже есть планирование :-) Причём даже посерьёзнее в некоторых моментах, чем в старом добром Waterfall.
Ещё раз: я не склоняю всех к сожительству Скраму. Просто то, что часто называют Скрамом, как правило, таковым не является.
боль вы мою почувствовали, и её я не скрывал, но на ответы мои вы так и не ответили. Но я буду надеяться и ждать
1. Были вполне себе профессиональные работники.
2. В другой сфере деятельности, скорее всего могли бы. В той, где я это наблюдал, со Скрамом было эффективнее.
3. В процессе сбора статистики и пока она в плюсе.
4. См. п. 3.
5. Планирование по Скрам в наших реалиях позволяет сэкономить очень много времени, а значит и денег.
И тут выходит на первый план отчётность, которая показывает наглядно (на графиках), что и петя и вася в последние скажем 10 спринтов деливерят нормально (не хуже других в команде), а проблема в другом. Например, скоуп гораздо больше продуктивности команды и тренд непопадания проекта в дедлайн был виден ещё 6 спринтов назад.

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

Возможность делать оценку производительности, предсказывать готовность фич (с точностью примерно в 2 спринта) — это то, за что так любит скрам руководство.
Как показывает практика, когда фокус внимания смещается с «побольше сторипонинтов закрыть» на «сделать нормальный сервис/продукт», начинают возникать вопросы «а так ли нам нужно все то, что мы делаем», «а не пора ли озаботиться тем, будет ли оно выдерживать нагрузку», «а почему у нас задачи по исправлению багов в функционале Х делаются в три раза дольше, чем добавление нового функционала в проекте У». И что еще важнее, эти вопросы начинают обсуждаться.
Если есть нормальный QA или как вы этих людей называете, то такие вопросы должны задаваться в любом варианте работы команды. Но вот в скраме с их сторипоинтами и спринтами вещи вроде:
а почему у нас задачи по исправлению багов в функционале Х делаются в три раза дольше, чем добавление нового функционала в проекте У

отследить обычно проще. Хотя бы потому уже что такая статистика в принципе собирается.
UFO just landed and posted this here
А где вы в моем комментарии увидели что скрам помогает ответить на вопрос «почему»? Я написал о том, что он помогает эту проблему в принципе увидеть.
UFO just landed and posted this here

Трудные будни продажи scrum master… Понимаю, сочувствую.

еще понравилось
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.


короче, работает работу.
если б он еще массаж делал — шеи разминал, или там… чай разносил, больше пользы бы было.
Скрам — это как ритуальные танцы шаманов для вызова дождя. Один шаман потанцует — и дождь идёт. А другой потанцует — и дождь не идёт. Это, наверное, потому, что второй неверно потанцевал?

Если в хорошем проекте взять и выбросить, ну я не знаю, тимлида или сервер с базой данных — проекту станет плохо и это будет видно сразу. Если же в хорошем проекте взять и выбросить скрам-мастера, то не изменится ровным счётом ничего: и тимлид и сервер с базой данных продолжат работать. Как в том анекдоте, что простуда проходит за неделю, если лечить, и за 7 дней, если не лечить.
Всё хорошо в меру. Когда скрамом и аджайлом подменяется работа — тогда плохо. Когда они используются как инструменты (с максимальной эффективностью) — тогда хорошо. В любом случае, это зависит от команды и менеджмента, ибо нельзя техническими средствами решить организационные проблемы. А при хорошем менеджменте и эти костыльки будут работать не хуже прочих…
Зашел в комментарии, чтобы увидеть «ответку» — альтернативную методологию «Пиши код бл..». Полностью вот здесь
На самом деле, какие в скраме есть неплохие вещи, главное вовремя включать голову и чтобы это не перерастало в культ ради культа.
+1!
Плюсом было бы, чтобы это не _навязывалось_ вообще везде. В команде развития ИТ инфраструктуры, например.

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

что б это не стало карго культом как раз и нужен скрам мастер.

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

UFO just landed and posted this here

Фокус в том, что выгнать "неправильного" скрам-мастера может только настоящая скрам-команда. А если у нас просто клоунада с таким же названием, то и мастер соотвествующий, и выгнать его не получится.

tangro, Ermit, maxzh83, geher,
Да, отчасти про это и статья.
Я, ровно как и создатели Скрам, не считаю Скрам серебряной пулей. Всему есть своё применение. Я также абсолютно не призываю «натягивать сову на глобус» (то есть использовать всем только Скрам).
Речь о том, что не вникнув в суть чего-либо (в данном случае был выбран Скрам, а вообще можно к чему угодно применять) начинается череда незаслуженных оценок, негатива и пр.
В этом то и беда. Такие вещи хорошо работают когда все понимают за чем это и единогласно пришли к выводу, что надо это внедрять. Скрам подразумевает личную вовлеченность каждого члена команды в процесс, тут нет места «мне сказали делать — я делаю». Каждый должен осознавать, что он делает и как его деятельность помогает достижении поставленной цели. Это другой уровень ответственности. А сейчас получается, что «все бегут и мы бежим».
Да, так и есть.
В одном интервью очень правильно заметили, что гибкие методологии требуют более высокого уровня компетенции, проектной и профессиональной дисциплины. В ином случае получаем хаос, потерю контроля, а, значит, и денег.
а хорошая методология гарантировала бы приемлемые результаты и для обычного уровня компетенции и дисциплины
«мне сказали делать — я делаю», это результат того, что «мы все решили — ваше дело сделать, кто не согласен может уходить»
Не совсем, это нормальная ситуация в типичной иерархической структуре, где начинающий разработчик еще не в состоянии качественно декомпозировать задачу и ему дают ограниченный круг задач и его ответственность минимальна. Скрам же подразумевает равную ответственность каждого члена команды разработки и близкий уровень «скилов». Только тогда такая команда будет эффективной, справедливости ради, такая команда профессионалов будет эффективна при использовании любой методологии. Но для скрама это необходимо, в противном случае «слабое» звено команды будет постоянно вываливаться из процесса.
Да, это так. Но я два года жил под скрамом и мой опыт — практический. Никогда (слышите — никогда) я не стал бы использовать скрам на этапе проектирования. :) А вот на этапе отладки и рефакторинга — да, это годная методика.
Офис. С утра офисные сотрудники в спешке передвигают мебель с места на
место, выравнивают все по сантиметру, компасу и т. д.
Посредине всего этого хаотичного движения стоит старенькая уборщица в
обнимку со шваброй, испуганно смотрит на все это действо и бормочет про
себя:«Только помыла, сейчас все опять затопчут, уроды».
Стояла долго смотрела на все это, потом спрашивает:
— Милые, а что вы тут делаете? Переезжаете?
— Да нет, бабуля, мы сейчас мебель по фен-шую передвинем и у нас сразу
продажи взлетят до небес.
— Сынки, я тут давно уже работаю, еще до революции полы в этом здании
мыла. Так вот, до революции тут был публичный дом. Так там, когда касса
падала, кровати не двигали — там сразу бл**ей меняли.
Да, последний абзац довольно ходовой и в наше время :-)
Но, пожалуй, всё это больше про «Скрам, как карго-культ», что лично я абсолютно неприемлю и считаю, что подобный подход в основном и бросает тень на фреймворк.
Я учавствовал в нескольких командах работающих по скраму. Проходил тренинги по скраму от скрамтека. Ничего кроме ритуалов не увидел.
Зачем нужен дейли митинг? Он только ест время. Все тупо сидят и перечисляют что они делали. Никакой практической ценности это не может нести даже теоретически. Только отвлекает всех от работы.
Все эти ужимки и приседания в виде планопокеров, митингов и прочего говна немогут заставить человека работать если он не хочет.
Если подумать, то все сводится, условно, к задачам в джире.
Человек берет задачу в джире и делает ее, например, 3 дня. Он делал бы эту задачу те же 3 дня и без аджайла. Без всех этих оценок и прочей пустой траты времени. И за неделю он сделат к примеру 7 задач. Есть аджайл или нет.
В 98м году писали софт на дельфях. По понедельникам встречались с заказчиком, смотрели что сделано, планировали следующую неделю и делали. Никто это не называл никакими модными словами. Все работали. Не выдумывали этой дичи с планпокерами и прочими приседаниями.
Не заставляли людей заниматься херней называя это фреймворками…

В общем все, что я видел успешного про аджайл, можно охарактеризовать любимой фразой Шелдона из сериала теория большого взрыва — «После того не означает в следствии того».
UFO just landed and posted this here
UFO just landed and posted this here

Любопытно, это только среди новообращённых скруммастеров популярна мантра — если у вас скрум не работает, значит вы используете не скрум и только бросаете на скрум тень? Никогда не слышал, чтобы условные "отвертко-мастера" на заявление, что не получается вкручивать отвёрткой гвозди заявляли, что всё получается, просто вы на самом деле использовали не отвёртку, поэтому нечего бросать на отвёртку тень, ею вполне можно закручивать гвозди!

Не знаю, что там с новообращёнными, но настоящие СМ свои ошибки признавать могут (да, я и такое видел). В каждом случае, почему Скрам не работает разбираться надо. Может его вообще не стоит в конкретном случае использовать (повторюсь, что я не за то чтобы Скрамом затыкать все дыры)?
Более того, знают текущее состояние команды, и у них обязательно есть план по тому, как команде двигаться дальше.
Я вас уверяю, что у большинства скептиков округлятся глаза при вопросах про метрики.
Начнут рассуждать, что сейчас всё хорошо, и будет обязательно лучше.
Беда вот только цифр обычно от них не допросишься…
В каждом случае, почему Скрам не работает разбираться надо.

Почему не работает? Как-то там работает. Если достаточно долго мучаться, то и отверткой можно вкрутить гвоздь. Но зачем?


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

А что не так с метриками?


Беда вот только цифр обычно от них не допросишься…

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

Если достаточно долго мучаться, то и отверткой можно вкрутить гвоздь. Но зачем?

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

Так обычный «ненастоящий шотландец» или как там.
Любые «гибкие» способы разработки или управления вызывают у меня мигрень. Напрогибались. У меня не безумно сложные проекты были и размеры рабочей группы в 3 — 4 человека, но и в них любая «гибкость» вела к мгновенному неконтролируемому увеличению энтропии.

Возможны ли scrum и прочая имитация бурной работы в, например, аэрокосмической инженерии? Не возможны — и слава Богу! Иначе Лунная программа так бы и не началась! В аэрокосмической инженерии невозможно на этапе финальной сборки ракеты сказать конструктору: «а увеличь-ка число её пассажиров на 5 человек, вам же не сложно? у вас же масштабируемая архитектура?»

А в программной инженерии у заказчика требования по 5 раз в месяц меняются. И проекты зависают на месяцы или выпускаются сырыми! И сие не нормально! Требования нужно зафиксировать в проекте и не менять — а любое изменение, не заложеннное в нынешней архитектуре — новый проект, новые расчёты и новый заказ. Ну и сроки, конечно, приблизятся к срокам в аэрокосмической инженерии, но, оно и к лучшему — ибо и качество вполне возможно приблизится.

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

Разные проекты — разные подходы. Это нормально, гибкие методологии не везде будут работать или не на всем жизненном цикле продукта. Тут в другой статье поднималась похожая тема: https://habr.com/post/422327/#comment_19073275.


Выпускается MVP и далее на не него наращивается функционал ну или не наращивается — зависит от того, как прошел пилотный запуск. Это удобно когда по сути сам не знаешь что делаешь, но есть идея. Когда есть полное понимание, то можно и без гибких методологий обойтись.


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


Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом [Гибкая методология разработки].
Все же сранивать негибкость железячных и программных технологий не очень верно.
Негибкость железячных технологий пошла им на пользу!
И да и нет. В части продумыания наперед — да, но это сопряжено с увеличенными (по сравнению с софтом) сроками. Так что все как в золотом правиле механики.
А может кто-нибудь из сторонников SCRUM привести измеренные цифры роста эффективности разработки при его применении?
Кто сказал что у скрама цель повысить эффективность? Цели несколько иные. Это в том числе методология работы со стейкхолдерами. В нашей команде это первое, чем помог скрам. Обозначил capacity команды и дал возможность заставить стейкхолдеров расставлять приоритеты по ограниченному ресурсу.
А без scrum'а stakeholder'ы не поймут, что команда в 5 человек не может выполнить работу сотни?
Они даже между собой не могут договориться о функционале. SPM — хороший способ заставить их хотя бы между собой поговорить, заодно расставив приоритеты поверх капасити.
Project manager концентрирует и координирует обсуждение функционала. Скрам тут при чем?
PMу (а в скраме это другая роль), надо оперировать какими-то KPI, что бы планировать / обосновывать ёмкость команды. Да это можно делать и не по скраму, а хоть в канбане, но у канбана свои грабли. Тут, как правильно написали, серебряной пули нет. Мой пойнт — не надо на скрам смотреть лишь с позиции программиста, так действительно непонятно на фига оно всё надо.
надо оперировать какими-то KPI, что бы планировать / обосновывать ёмкость команды.

Сами разработчики могут дать ETA. Как иначе? Данные по-любому с потолка ПМами не берутся. Только опять же — при чем тут скрам…
Скрам, в моем его понимании (а я ни разу не специалист), дает статистику для корректировки таких прогнозов. Потому что у разработчика может быть плохой день, он может забыть сколько именно он делал похожую задачу, он может быть загружен чем-то еще и это даст эффект на прогноз (банальное якорение присуще человеческому мозгу в целом и здесь оно точно также сыграет роль). Но когда есть статистика, то есть возможность скорректировать прогноз и получить более точную оценку. Я уверен что собрать ее можно и другими методиками и срам помимо этой статистики дает что-то еще, но как минимум есть вот это.
Нет цели повысить эффективность??? Я Вам не верю…
Такая цель есть и даже прописана явно. Посмотрите как должны проходить ретро-митинги.

Рост эффективности измеряется в приросте стори-поинтов и бизнес value за каждый спринт.
UFO just landed and posted this here
UFO just landed and posted this here
Скрам — это, скажем так, одна из реализаций Agile.
Agile использует итеративную модель.
Полагаю, что отличий здесь не стоит искать.
Неужели есть профессиональные программисты которые серьезно воспринимают SCRUM?
Как я (и не только я) уже здесь писал, Скрам и вообще гибкий подход — это про ВЫСОКОпрофессиональных программистов и сотрудников в принципе.
Уровень организации труда (дисциплина, саморганизация и т.д.) должен быть на порядок выше, чем при более традиционных подходах. Иначе это хаос, негодование, потеря времени и денег.
Какое у вас самомнение…
Уровень организации труда (дисциплина, саморганизация и т.д.) должен быть на порядок выше, чем при более традиционных подходах

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

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

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

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

Скрам — он не про ИТ.
Скрам — он про бизнес.

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


Здесь ничего про ИТ. Только про бизнес.
Про то, как бизнесу в условиях неопределенности, выводить на рынок и развивать определенные продукты (не любые продукты).

И чтобы итшнику работать по скрам, он должен стать частью бизнеса. Быть его (бизнеса) неотъемлемой частью. Думать бизнес-ориентированно, планировать бизнес-ориентированно, оценивать бизнес-ориентированно.

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

И при этом нет правых и не правых.
Есть разные подходы к ведению бизнеса. Скрам — один из.
Это реально не про ИТ, это про безответственность бизнеса. Менять ТЗ на ходу. Объявив это нормальным.

Речь не про изменение ТЗ на ходу. Когда есть конкретное ТЗ, то нет места скраму. Это две разные модели. Если работать по ТЗ (в идеальном мире), то заказчик выдает определенный набор требования, команда оценивает и называет срок и сумму. В указанный срок заказчик приходит и ему отдают готовый протестированный продукт. Т.е. фактически покупается конечный продукт, в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки.


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


Это если применительно к ИТ.

… в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки
об этом я собственно и написал. У бизнеса появляется сценарий, когда он может ни за что не отвечать! Сейчас хочу так, завтра — эдак, но мы это обзовём новым словом «скрум» и будем парить мозг команде разработчиков перманентно и без конечных сроков!
ЗЫ И главное — без ответственных за сорванные сроки проекта в целом. Потому как … Ну, Вы поняли?
Бизнесу не выгодно бесконечно развивать продукт, если он провальный, а в случае если он успешный и постоянно развивается, то команда разработки имеет постоянный доход. Если команде разработки надоело поддерживать продукт она может закончить работу на любом спринте.
Понимаете, вы уже сейчас делите: «вот бизнес, а вот мы, ит». В скраме нет деления бизнес/ит. Есть только команда, которая отвечает за продукт. Когда это выполняется, начинается скрам. Все остальное — дейли, ретро, сторипойнты и т.д. — это лишь атрибуты, которые могут иметь ту или иную форму.

Очевидно, что бы это (отсутствия деления на бизнес/ит) произошло в организации, у которой уже есть длинный бекграунд, нужны тектонические изменения на всех уровнях.
UFO just landed and posted this here
PO, SM и Dev. T — все вместе скрам-команда. Это выделение ролей в процессе, но не разделение бизнес/не бизнес.
UFO just landed and posted this here
PO ответственен за правильный беклог. Он не навязывает стресс по его burnout. Это как раз роль SM. Но по факту PO и SM часто одно и то же лицо.
И все таки они команда.
А что у нас команда? Группа лиц объединенных одной целью.
В случае скрам-команды — объединенные целью создания и развития продукта.

В целом, я согласен, что настоящему итшнику крайне сложно разделять бизнес-ориентированные ценности, итшник стремится к построению идеального мира, где 1+1=2.
Но мир неидеален, и 1+1 не всегда =2.

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

Нуу, каждый делает свои выводы. У вас такие. У меня несколько другие.
Мне они (ваши выводы) тоже не нравятся.

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

Мне больше нравится:
Хороший итшник с высоким уровнем саморефлексии создает больше ценности и потому больше востребован рынком, чем просто хороший итшник.

Неправильно вас понял первый раз, спасибо.

Так вот, главным документом по Скрам является «The Scrum Guide», написанный в соавторстве Кеном Швабером и Джеффом Сазерлендом, доступный на многих языках, включая русский.
На мой взгляд, для того, чтобы получить базовые знания по Скрам и, впоследствии не засорять своё сознание всевозможными неверно истолкованными дополнениями к Скрам, требуется всего два основных компонента: желание и вдумчивое прочтение «The Scrum Guide», причём не один раз.

Согласен, что это приходится читать не один раз. Но не потому, что это такая классная вещь, что её стоило бы перечитать, а потому что она ужасно написана, и понять её с первого раза решительно невозможно. Постоянные упоминания неразъясненных терминов с ссылкой на что-то впереди. Обычное описание практически чего угодно там выглядит так (цитатаиз первого же абзаца документа):
Это Руководство содержит описание Скрама, оно рассказывает о ролях, событиях, артефактах(2) и правилах фреймворка.
и сноска
2 Подробнее об артефактах будет рассказано на стр.16

И так постоянно, чтобы целиком не заваливать цитатами вот просто сноски с первых пяти страниц:
2 Подробнее об артефактах будет рассказано на стр.16

6 Подробнее о Критериях Готовности будет рассказано на стр.19.

7 Подробнее о Цели Спринта будет рассказано на стр.13

8 Подробнее о Бэклоге Продукта будет рассказано на стр.16.

Это совершенно невозможно читать последовательно. Почему люди, которые учат других людей создавать качественный продукт, не могут создать качественный читаемый 25-страничный документ?

Потому что цели такой не ставилось. Завтра, типа, соберемся, обсудим и исправим.

SCRUM по сути, если отбросить словесную шелуху, это элементарный micro management обёрнутый в набор ритуалов. Лучший ли это способ разрабатывать программное обспечение?

Интересно было бы почитать отклики компаний, ОТКАЗАВШИХСЯ от Скрам. Что-то вроде «мы отказались от Скрам и повысили эффективность на 20%!» Или «вместо того, чтобы вкладываться в Скрам, мы вложились в повышение комфорта разработчиков, и теперь люди бегут не о нас, а к нам»… ))
Все это напоминает сказку Андерсена «Новое Платье Короля».
Гибкая разработка и SCRUM не синонимы.
SCRUM паразитирует на понятии гибкой разработки.

Спасибо всем кто потратит немного времени и в 2-3-4 предложениях напишет какая модель управления в их компании работает лучше чем scrum и почему.

Спасибо, надеюсь еще парочку историй найду.


p.s.
Очень интересное видео про менеджеров и техлидов, отчеты которые пишут менеджеры команды не отвечающие за свой продукт итд.

Напоминает басню Крылова «Квартет» — тут надо архитектуру продукта лечить, а не программистов пересаживать.

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

Нет никакого четкого определения что такое Scrum, существует только куча разных толкований от Scrum-евагелистов.

Scrum это очередная бизнес-религия, созданная для того, чтобы такие сертифицированные балаболы как автор статьи могли паразитировать на бизнесе и балаболить за зарплату, по факту занимаясь пинанием всех известных органов

Поделитесь, пожалуйста, историями успеха — что работает и как правильно выбрать метадологию\процесс людям в начале пути?

Следуйте правилу: неправильная архитектура продукта не лечится правильной методологией.

Что есть архитектура продукта?
UFO just landed and posted this here
Без daily meeting это уже извините не SCRUM.
А кто сказал что для SCRUM нужны умные программисты?
Нужны заменяемые с предсказуемой продуктивностью (пусть и небольшой).

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

Здесь писали в коментах, что часто именно слабое руководство хотят заменить методологией, и первое что гуглиться Agile и Scrum, ну и потом коучи с процентами эффективности приходят.

И внедряют, по итогу руководство как было слабое так и осталось, а команда не готова с Scrum, вывод — Scrum/Agile не работают. Начинается поиск косяков метолодогии.

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

Любая методология это инструмент и не более, не палочка-выручалочка, сначала голова потом Scrum (Mozg).
Sign up to leave a comment.

Articles