Комментарии 157
Цель как раз и была «вбросить», или просто, чтобы люди призадумались, что всё не просто так и не стоит «верить слухам» ;-), а многое можно почерпнуть из уже имеющихся общедоступных источников.
Я намеренно не стал растолковывать весь Скрам-гайд, а только дал «для затравочки».
Вам конкретно отвечу:
1. Цель спринта (беру из русской версии документа, хотя рекомендую пользоваться английской, как первоисточником): «Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта.»
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
Скрам-мастер — это лидер-слуга для Скрам-Команды. Людям вне команды он помогает понять, что из их взаимодействий со Скрам-командой полезно, а что нет. Скрам-мастер помогает изменить эти взаимодействия так, чтобы они максимально увеличивали ценность, которую создает Скрам-команда.
3. Product Owner (Владелец Продукта): Владелец Продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Способы достижения максимальной ценности могут различаться и зависят от самих организаций, Скрам-команд и конкретных людей.
Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта.
Как я уже написал в статье, одна из целей — это показать, что прежде чем давать какие-либо вольные интерпретации ролям и зонам ответственности, необходимо детально ознакомиться с первоисточником.
Что такое «ванильное определение», я не знаю но, подозреваю, что это частично то, о чём я писал: секретарь, прислуга, психолог. Вот как раз НЕТ!
В идеале СМ в части работы с командой стремиться создать из неё самоорганизующуюся команду и, опять же таки в идеале, команда должна научиться обходиться без него (без СМ).
Могу ещё много писать, но не буду :-), чтобы не написать коммент размером со статью :-)
Всегда готов пообщаться в оффлайне на эти темы!
Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.
«Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.
В принципе можно посмотреть в гайде, включая обязанности СМ для PO, DevTeam и Организации. В общем там не только фасилитация.
Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.
В целом согласен с вами. Если уже не особо требуется команде, то пора ему подумать дальше, как расти, так как есть куда.
Несколько раз упомяналось, что в команде есть всего одна роль — разработчик. Как тогда тестировать и деплоить? В общем случае этим могут (или должны) заниматься другие люди.
То, что вы, скорее всего, имеете в виду — это про кросс-функциональность (не следует путать со взаимозаменяемостью). То есть когда в команде присутствуют все необходимые компетенции для создания продукта от начала и до конца и, соответственно, она не зависела бы от компетенций извне.
В вашем случае необходимо договариваться и брать дизайнера в Скрам-команду, что, скорее всего, уже будет вопросом на уровне Организации и трансформации соответственно.
В Скрам-команде всего три роли: PO, SM и Development Team. Грубо говоря, «разработчик» (developer) в Scrum Team — это тот, кто непосредственно выполняет работу «руками» :-), например, кодит, тестит, организует маркетинговые компании и т.д. Короче не только о программерах идёт речь :-)
Значит необходима внешняя косультация или внешний исполнитель, если это необходимо на постоянной основе, то нужно брать дизайнера в команду на постоянной основе. Кросс-функциональность — это не про то, что каждый "и швец, и жнец, и на дуде игрец". Это про то, то в команде есть отдельно "швец", отдельно "жнец" и отдельно "на дуде игрец".
Да, так это предполагается по The Scrum Guide. СМ — это штатный консультант-наблюдатель за процессом. Если команда отклонилась от цели и не проводит daily, он может подойти и сказать, что у вас тут какая-то фигня начинает происходить, вы отклонились от цели спринта, но повлиять ни на что он не может.
Если выясняется, что задача не может быть взята до выполнения каких-то внешних для команды (в вашем случае дизайнерских) задач, то создаётся запрос (или задача) на ПО
… создается задача для другой команды. И на неё ставится ссылка. А дальше ваш ПО и ПО другой команды разбираются с приоритетами
Есть ещё такая штука как критерии INVEST, DOR (Definition Of Ready). Если вам интересно, то почитайте.
DOR — это то, что, например, про задачи внешнего вендора, от которых зависит ваша команда. Но фишка в том, чтобы не увлекаться DOR везде и всюду, так как перебор ведёт в неуместный Waterfall (я не против Waterfall, подчёркиваю «неуместный» в случае выбранного Agile-подхода).
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»В статье рассказывается нам, глупым, до сих пор не понимающим зачем стендапы, что 40 минут-то это конечно перебор и надо всего 15 (не считая времени на подготовку перед и возврат в работу после).
А всё равно непонятно, чем встречи в таком формате лучше например общего чата, где в реальном времени можно общаться, а не ждать 15-минутки следующего дня. Ну и прогресс опять же в реалтайме видно по чату и по коммитам с тикетами. Зачем эта ежедневная ритуальная клоунада с "что делал что сделано какие проблемы"? Нет ответа.
днями могут сидетьТупо сидеть, уставившись в одну точку, или разбираться, изучать материал, искать варианты решения, разносторонне развиваться в процессе, в конце концов? Почему вы думаете, что это в конечном итоге будет менее полезно, чем если кто-то сразу ткнет в привычный ему вариант решения?
Отсутствие стендапов не подразумевает отсутствия общения. Общение в цифровом мире штука гораздо более многогранная, от тех же групповых чатов, до просмотров чужих коммитов, код-ревью. Была бы заинтересованность в общении, если человеку пофиг, ему и стендап не поможет.
Была бы заинтересованность.
Смена методологии очень часто заставляет выйти наружу реальную заинтересованность (читай производительность, эффективность и т.п.) человека в работе. И скорее именно это уже не нравится человеку, а не «гибкость» той или иной методологии.
2. Если 15-минутки идут ежедневно и в целом всё ок (все понимают для чего у них Скрам), то ненужно к ним готовиться.
3. События (обязательные встречи, если в общем) в Скрам не отменяют других встреч и прочего общения членов команды.
4. Про «клоунаду». Формат Daily Scrum может определить сама команда. Важно получить информацию по статусу движения к цели спринта и есть ли какие проблемы с этим.
В целом, если команда только начинает свой путь в Agile/Scrum, то лучше просто следовать гайду (видимо это подразумевается под «ритуалами»). Дальше, по мере того, как будет больше опыта и понимания фреймворка, всё должно стать проще. На самом деле в статье я вскользь упомянул про «сюхари» (можно посмотреть Вики) — это, на мой взгляд, как раз на данную тему.
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.Очень часто возникает ситуация, когда просматривая коммит коллеги, который, по моему мнению, делает там что-то не то, предлагаю ему решение, которое сам знаю. Сразу предлагаю, не ожидая следующего дня и ритуальной сходки, понимаете? Более того, даже работа с 9 до 18 с пн по пт, это пережиток прошлого, люди всегда онлайн, всегда доступны, не надо всех собирать в одном месте, чтобы донести информацию или взаимодействовать друг с другом.
Вот я здесь оставил информацию, с ней в ближайшие часы ознакомится пара десятков человек, мне не надо их ждать, собирать где-то, тратить их время, отвлекать от чего-то важного, когда им будет удобно они зайдут и прочитают (сейчас читаете), возможно даже как-то отреагируют. Вот так это работает в 21 веке.
В общем случае стендапы достаточно показательны для определения зрелости команды. Если все процессы идут как надо, если члены команды проактивны, если цели понятны, то даже 15 минут будет много. Просто шанс оттранслировать в команду происходящие прямо сейчас процессы.
Простое сообщение вида «Делаю задачу Х, столкнулся с проблемой Y, Z обещал показать как она решалась раньше» занимает 20-30 секунд, а тот, кто хочет побольше узнать о проблеме Y может просто подойти после стендапа и послушать, а что, а как.
а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.Давайте я когда сделаю, вам сразу сообщу, так не лучше будет? И если проблемы возникнут сообщу, сразу. А если вы ждете пока я что-то сделаю, чтобы свою часть начать, тоже можем договориться. Не обязательно всем собираться в кружок, да ещё каждый день.
Простите за мой вопрос, не хотел вас обидеть, скорее лучше понять позицию.
А вы на работе 8 часов от звонка до звонка работаете не покладая рук и не отвлекаясь ?
Плановые отвлечения вроде обеда или стендапа тоже мешают, ты как-то под них пытаешься подстроиться, а незадолго до «часа х» уже возникает некоторое состояние ожидания, которое не позволяет глубоко сосредоточиться, вообщем хотелось бы их по максимуму сократить.
В этом плюс регулярности встреч.
С утра мы проводим стендап и я знаю что в тот день меня больше не потревожат.
Одна из важных причин, почему так же используется Скрам — это прогноз и оценка, планирование. Я понимаю, что такие вещи могут не интересовать простого разработчика, но с точки зрения продукта — это важно, потому что это деньги. Чем более точное планирование, тем больше денег сохранит бизнес (в общем случаеъ есть много специфики от области бизнеса). Например, если разработка ведётся итерациями и все это мониторится, собираются метрики, то спустя какое-то время можно сказать, на какой капасити команда может 100% отрабатывать, и вы будете удивлены, на сколько точно такие «предсказания» работают. Но это при условии корректной интерпретации и применения методологии. Если коверкать понимание методологии, то лучше делать без неё. У меня есть опыт работы в компаниях, где использовали скрам, потому что надо бы, и от этого процесс страдал. И наоборот, работал там, где процесс поставлен грамотно, и разница видна очень сильно.
Я не призываю использовать скрам. Потому что он не всегда подходит, есть много причин его не использовать, в зависимости от многих факторов. Но нередко правильное применение скрама наводит правильный порядок и упрощает разработку продукта.
Согласен с вами, что карго-культ, который в итоге получается, ничего кроме негатива не вызывает.
Об этом в том числе я и писал.
Я смотрю на комментарии и понимаю, что многие восприняли мою статью, как оду Скраму, как к призыв к тотальному переходу на него. На самом деле это не так, но каждому я не собираюсь это доказывать.
Эта статья на «задуматься», а не «мы все в Скрам!».
Насчёт их решения не понял, почему теряется день. Если проблема важная, то никто не мешает её обсудить сразу после Daily. В общем вопрос организации своей работы, в частности, вопрос приоритизации.
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой
Ну, тогда этот кто-то просто по факту обращается к коллегам, в общий чат, например — он же сам понимает, что тупит над решением. После первого-второго такого скрытого случая ему объяснят, что если ты тупишь, то обратиться к коллегам — не зазорно.
Зачем тут ежедневные летучки?
2. Если команда работает не по Скрам, СМ ей не нужен.
Вроде основные ситуации разобрали.
назови как-нидь еще тогда «НЕДОКРАМ», пойдет название? или тебе надо простыню текста еще написать, как правильно жить по «НЕДОКРАМ»у?
ПС: не просите только уточнять: «каких именно не хватает?, когда они не нужны?»…
Подобное отношение, как у вас, встречал и довольно часто. Не назвал бы его высокоэффективным.
А просить, или оправдываться перед вами и не собирался, так как в данном случае это всё равно что «бисер перед...» (дальше наверное известно).
есть что ответить по сути? чем отличается СМ от менеджера, кроме того что он прочитал портянку текста об скраме?
Но здесь это будет потерей времени.
я думаю все все поняли.
Что касается ответственности, то в итоге она на PO, например. Он отвечает перед стейкхолдерами. Так что, как минимум, одного ответственного отыскали.
Если вы делите PO и DevTeam, то это уже не команда (то есть не та самая Scrum Team).
Вот как так получилось? Вроде на русском написал, но как то не очень похоже на русский.
Но не только в книжках, но и в жизни я встречал и работал с командами, которые были единым целым — Scrum Team. Там, в общем-то было без сюрпризов и без «размываний» и прочих «размазываний» ответственности.
В одном из своих комментов я уже ссылался на одно интервью, где речь шла о совсем других компетенциях (более высокого уровня), когда идёшь в гибкие методологии.
В ваших сообщениях чувствуется «боль потери времени на совещания». Это может быть вызвано тем, что:
1. Может Скрам в принципе не подходит для вас (Скрам — не серебряная пуля).
2. Может нет реального понимания, как правильно проводить эти совещания. Нет «того СМ», который должен был объяснить, что к чему.
Одна из интересных вещей, которую я в своё время открыл в Скрам — это то, что оказывается в нём тоже есть планирование :-) Причём даже посерьёзнее в некоторых моментах, чем в старом добром Waterfall.
Ещё раз: я не склоняю всех к
2. В другой сфере деятельности, скорее всего могли бы. В той, где я это наблюдал, со Скрамом было эффективнее.
3. В процессе сбора статистики и пока она в плюсе.
4. См. п. 3.
5. Планирование по Скрам в наших реалиях позволяет сэкономить очень много времени, а значит и денег.
На роли рядового участника команды возможно даже вполне получится работать «не веря» в скрам, если честно отвечать на вопросы по оценке задач, репортить статусы и учавствовать в ретро.
Возможность делать оценку производительности, предсказывать готовность фич (с точностью примерно в 2 спринта) — это то, за что так любит скрам руководство.
а почему у нас задачи по исправлению багов в функционале Х делаются в три раза дольше, чем добавление нового функционала в проекте У
отследить обычно проще. Хотя бы потому уже что такая статистика в принципе собирается.
Трудные будни продажи scrum master… Понимаю, сочувствую.
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
короче, работает работу.
если б он еще массаж делал — шеи разминал, или там… чай разносил, больше пользы бы было.
Если в хорошем проекте взять и выбросить, ну я не знаю, тимлида или сервер с базой данных — проекту станет плохо и это будет видно сразу. Если же в хорошем проекте взять и выбросить скрам-мастера, то не изменится ровным счётом ничего: и тимлид и сервер с базой данных продолжат работать. Как в том анекдоте, что простуда проходит за неделю, если лечить, и за 7 дней, если не лечить.
У меня вся эта клоунада вокруг технологий органзации работы навевает следующие мысли.
Команда разработчиков должна выбирать не модную технологию, а ту, что удобна именно этой команде.
Иначе почти гарантированно получается карго-культ со всеми его негативными последствиями.
Самое "веселое" бывает, когда какая-то команда создает для себя удобную систему, потом этой системе дают звучное название, рекламу, внедряют направо и на лево, не задумываясь, а подходит ли оно данной конкретной команде. А потом со всех сторон идут негативные отзывы.
Похоже, что именно это и произошло со скрамом, давно превратившимся из всего лишь одной из многих систем организации работы в команде в какой-то бессмысленный культ.
И попытка "вернуться к истокам" уже ничего особо не дает, поскольку культ сформировался именно в том виде, который сейчас имеем.
А если этот скрам мастер (со всеми бумажками) является частью или даже основанием карго культа?
Ну да конечно, теперь мы знаем, что он не настоящий скрам мастер.
Только непонятно, как это знание может помочь.
Да, отчасти про это и статья.
Я, ровно как и создатели Скрам, не считаю Скрам серебряной пулей. Всему есть своё применение. Я также абсолютно не призываю «натягивать сову на глобус» (то есть использовать всем только Скрам).
Речь о том, что не вникнув в суть чего-либо (в данном случае был выбран Скрам, а вообще можно к чему угодно применять) начинается череда незаслуженных оценок, негатива и пр.
В одном интервью очень правильно заметили, что гибкие методологии требуют более высокого уровня компетенции, проектной и профессиональной дисциплины. В ином случае получаем хаос, потерю контроля, а, значит, и денег.
место, выравнивают все по сантиметру, компасу и т. д.
Посредине всего этого хаотичного движения стоит старенькая уборщица в
обнимку со шваброй, испуганно смотрит на все это действо и бормочет про
себя:«Только помыла, сейчас все опять затопчут, уроды».
Стояла долго смотрела на все это, потом спрашивает:
— Милые, а что вы тут делаете? Переезжаете?
— Да нет, бабуля, мы сейчас мебель по фен-шую передвинем и у нас сразу
продажи взлетят до небес.
— Сынки, я тут давно уже работаю, еще до революции полы в этом здании
мыла. Так вот, до революции тут был публичный дом. Так там, когда касса
падала, кровати не двигали — там сразу бл**ей меняли.
Но, пожалуй, всё это больше про «Скрам, как карго-культ», что лично я абсолютно неприемлю и считаю, что подобный подход в основном и бросает тень на фреймворк.
Зачем нужен дейли митинг? Он только ест время. Все тупо сидят и перечисляют что они делали. Никакой практической ценности это не может нести даже теоретически. Только отвлекает всех от работы.
Все эти ужимки и приседания в виде планопокеров, митингов и прочего говна немогут заставить человека работать если он не хочет.
Если подумать, то все сводится, условно, к задачам в джире.
Человек берет задачу в джире и делает ее, например, 3 дня. Он делал бы эту задачу те же 3 дня и без аджайла. Без всех этих оценок и прочей пустой траты времени. И за неделю он сделат к примеру 7 задач. Есть аджайл или нет.
В 98м году писали софт на дельфях. По понедельникам встречались с заказчиком, смотрели что сделано, планировали следующую неделю и делали. Никто это не называл никакими модными словами. Все работали. Не выдумывали этой дичи с планпокерами и прочими приседаниями.
Не заставляли людей заниматься херней называя это фреймворками…
В общем все, что я видел успешного про аджайл, можно охарактеризовать любимой фразой Шелдона из сериала теория большого взрыва — «После того не означает в следствии того».
Любопытно, это только среди новообращённых скруммастеров популярна мантра — если у вас скрум не работает, значит вы используете не скрум и только бросаете на скрум тень? Никогда не слышал, чтобы условные "отвертко-мастера" на заявление, что не получается вкручивать отвёрткой гвозди заявляли, что всё получается, просто вы на самом деле использовали не отвёртку, поэтому нечего бросать на отвёртку тень, ею вполне можно закручивать гвозди!
Более того, знают текущее состояние команды, и у них обязательно есть план по тому, как команде двигаться дальше.
Я вас уверяю, что у большинства скептиков округлятся глаза при вопросах про метрики.
Начнут рассуждать, что сейчас всё хорошо, и будет обязательно лучше.
Беда вот только цифр обычно от них не допросишься…
В каждом случае, почему Скрам не работает разбираться надо.
Почему не работает? Как-то там работает. Если достаточно долго мучаться, то и отверткой можно вкрутить гвоздь. Но зачем?
Я вас уверяю, что у большинства скептиков округлятся глаза при вопросах про метрики.
А что не так с метриками?
Беда вот только цифр обычно от них не допросишься…
Из скрам-метрик мне больше всего всего нравится "показатель счастья". Докладываю, что цифра показателя счастья от необходимости участвовать в скрам-балаганах у меня находится на отметке, — "идите в жопу, с вашим скрамом". Но это, конечно, от того, что скрам у нас "ненастоящий", вообще не скрам и я просто бросаю на скрам тень, да.
Возможны ли scrum и прочая имитация бурной работы в, например, аэрокосмической инженерии? Не возможны — и слава Богу! Иначе Лунная программа так бы и не началась! В аэрокосмической инженерии невозможно на этапе финальной сборки ракеты сказать конструктору: «а увеличь-ка число её пассажиров на 5 человек, вам же не сложно? у вас же масштабируемая архитектура?»
А в программной инженерии у заказчика требования по 5 раз в месяц меняются. И проекты зависают на месяцы или выпускаются сырыми! И сие не нормально! Требования нужно зафиксировать в проекте и не менять — а любое изменение, не заложеннное в нынешней архитектуре — новый проект, новые расчёты и новый заказ. Ну и сроки, конечно, приблизятся к срокам в аэрокосмической инженерии, но, оно и к лучшему — ибо и качество вполне возможно приблизится.
А щаз заказчики верят, что раз программные инженеры не тратят никакие ресурсы, кроме времени и мыслей — знач их можно прогибать на любые изменения в любое время! Нельзя!
Разные проекты — разные подходы. Это нормально, гибкие методологии не везде будут работать или не на всем жизненном цикле продукта. Тут в другой статье поднималась похожая тема: https://habr.com/post/422327/#comment_19073275.
Выпускается MVP и далее на не него наращивается функционал ну или не наращивается — зависит от того, как прошел пилотный запуск. Это удобно когда по сути сам не знаешь что делаешь, но есть идея. Когда есть полное понимание, то можно и без гибких методологий обойтись.
Это все работает когда есть возможность сформировать небольшие кросс-функциональные команды (до 9 человек), если команды большие, то скрам, да и прочие гибкие методологии работать не будут, это должен быть сверхвысокий уровень самоорганизации у каждого отдельного члена команды, чтобы это не скатилось в неразбериху и хаос. Кстати русскоязычная википедия согласна с этим:
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом [Гибкая методология разработки].
надо оперировать какими-то KPI, что бы планировать / обосновывать ёмкость команды.
Сами разработчики могут дать ETA. Как иначе? Данные по-любому с потолка ПМами не берутся. Только опять же — при чем тут скрам…
Уровень организации труда (дисциплина, саморганизация и т.д.) должен быть на порядок выше, чем при более традиционных подходах. Иначе это хаос, негодование, потеря времени и денег.
Какие-то технические практики, которые по сути своей тоже agile можно выцепить из книг про экстремальное программирование, из практик девопсинга — они все про то, как быть более гибким в разработке, не привязываясь к методологиям управления проектами.
SCRUM — это религия, нужно постоянно совершенствоваться изучая дарованный сверху манифест, где буквально все расписано — когда встречаться, о чем говорить… Очень полезно читать статьи просветленных последователей SCRUMA, как их жизнь изменилась после того как они обрели веру. Есть и наказание для тех кто не соблюдает всех заповедей — неминуемый крах проекта.
Скрам — он не про ИТ.
Скрам — он про бизнес.
это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью.
Здесь ничего про ИТ. Только про бизнес.
Про то, как бизнесу в условиях неопределенности, выводить на рынок и развивать определенные продукты (не любые продукты).
И чтобы итшнику работать по скрам, он должен стать частью бизнеса. Быть его (бизнеса) неотъемлемой частью. Думать бизнес-ориентированно, планировать бизнес-ориентированно, оценивать бизнес-ориентированно.
Очевидно, такое подходит не всем ит-шникам. Не все разделяют ценность бизнес-ориентирования. И тогда возникает, то что здесь в комментариях красочно живописано.
И при этом нет правых и не правых.
Есть разные подходы к ведению бизнеса. Скрам — один из.
Речь не про изменение ТЗ на ходу. Когда есть конкретное ТЗ, то нет места скраму. Это две разные модели. Если работать по ТЗ (в идеальном мире), то заказчик выдает определенный набор требования, команда оценивает и называет срок и сумму. В указанный срок заказчик приходит и ему отдают готовый протестированный продукт. Т.е. фактически покупается конечный продукт, в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки.
Он выдвигает набор требований, какое-то подмножество наиболее актуальных реализуется и отдается заказчику на использование, команда начинает работу над следующим набором. В процессе использования у заказчика появляются новые требования, новые запросы и так далее, пока заказчику не надоест улучшать/переделывать продукт.
Это если применительно к ИТ.
… в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработкиоб этом я собственно и написал. У бизнеса появляется сценарий, когда он может ни за что не отвечать! Сейчас хочу так, завтра — эдак, но мы это обзовём новым словом «скрум» и будем парить мозг команде разработчиков перманентно и без конечных сроков!
ЗЫ И главное — без ответственных за сорванные сроки проекта в целом. Потому как … Ну, Вы поняли?
Очевидно, что бы это (отсутствия деления на бизнес/ит) произошло в организации, у которой уже есть длинный бекграунд, нужны тектонические изменения на всех уровнях.
комментарий удален
А что у нас команда? Группа лиц объединенных одной целью.
В случае скрам-команды — объединенные целью создания и развития продукта.
В целом, я согласен, что настоящему итшнику крайне сложно разделять бизнес-ориентированные ценности, итшник стремится к построению идеального мира, где 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 обёрнутый в набор ритуалов. Лучший ли это способ разрабатывать программное обспечение?
SCRUM паразитирует на понятии гибкой разработки.
Спасибо всем кто потратит немного времени и в 2-3-4 предложениях напишет какая модель управления в их компании работает лучше чем scrum и почему.
Это не Scrum плохой, просто у вас его неправильно реализовали
Я знаю как делать правильный Scrum, пока конечно же не сделал, но я двигаюсь к этому!
Нет никакого четкого определения что такое Scrum, существует только куча разных толкований от Scrum-евагелистов.
Scrum это очередная бизнес-религия, созданная для того, чтобы такие сертифицированные балаболы как автор статьи могли паразитировать на бизнесе и балаболить за зарплату, по факту занимаясь пинанием всех известных органов
Следуйте правилу: неправильная архитектура продукта не лечится правильной методологией.
А кто сказал что для SCRUM нужны умные программисты?
Нужны заменяемые с предсказуемой продуктивностью (пусть и небольшой).
В то время, когда внутри организации, в принципе не воспитана зрелость управления хотя бы проектами, попытки внедрять гибкие методологии, требующие на порядок иной зрелости приводят к тому самому карго-культу.
Здесь писали в коментах, что часто именно слабое руководство хотят заменить методологией, и первое что гуглиться Agile и Scrum, ну и потом коучи с процентами эффективности приходят.
И внедряют, по итогу руководство как было слабое так и осталось, а команда не готова с Scrum, вывод — Scrum/Agile не работают. Начинается поиск косяков метолодогии.
Имхо внедрять нужно на уровне тимлида и при слабом руководстве этого тимлида выделить.
Любая методология это инструмент и не более, не палочка-выручалочка, сначала голова потом Scrum (Mozg).
А был ли Scrum*?