*Scrum (Скрам (сущ.)) — это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью.
Почему я решил написать эту статью
Очень часто в рабочей среде, на просторах интернета и на собеседованиях можно услышать, например, вот такое:
«С этим Скрамом столько встреч! Когда работать то?!»;Цель данной статьи показать, что тот негатив, который всё ещё большим потоком льётся в сторону Скрама, на самом деле к нему не относится, и проблему нужно искать в другом месте.
«Хорошо, пусть это будет хоть Скрам, хоть Срам, только отвалите и дайте мне писать код!»;
«У нас тоже этот Скрам навязали, вообще непонятно для чего»;
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
«Скрам-мастер вообще шут какой-то, ему бы всё хороводы водить, вместо управления проектом!»;
«Да, Скрам мы использовали: главное, что ретроспективы проводили».
Далее я хотел бы рассказать о типичных случаях, откуда берут своё начало эти проблемы.
Сам я являюсь сертифицированным (scrum.org) в области Скрам сотрудником одной большой организации из финансового сектора (не «зелёной», если что). В настоящее время у нас не Скрам, но мы движемся в эту сторону, и лично у меня есть видение зачем и как мы будем это делать и дальше.
На самом деле увлечение гибкими методологиями и Скрамом в частности пришло ко мне не так давно, но на мой взгляд, важно не «как давно», а «насколько качественно и осознанно».
И чем больше погружаешься в эту тему, тем больше понимаешь, что данный фреймворк является мощным «инструментом», и тем печальнее каждый раз, встречать фразы и отзывы, приведённые в начале статьи, которые, как правило, являются свидетельством неуклюжих попыток перехода на Скрам.
Почему попыток, да ещё и неуклюжих: потому что не осознали, для чего вообще весь этот Скрам, да и Agile в принципе, и остановились чуть ранее, чем в самом начале перехода.
Компании, которые понимают, для чего нужен Скрам и как его использовать, на мой взгляд, не такое уж и частое явление в нашей стране.
Невидимую для многих мощь Скрама можно в какой-то степени сравнить с мощью Экселя: на вид всё довольно просто, а если покопаться…
Тем не менее, я не считаю Скрам серебряной пулей, ровно как и его создатели (ссылку на статью, которая вышла недавно в одном авторитетном издании здесь приводить не буду), да и это уже тема для отдельной статьи.
1. «Навязали»
На мой взгляд одна из главных причин, по которой Скрам вызывает такое неприятие — это когда его просто «спустили сверху» в ходе трансформации организации. И проблема здесь в том, как именно проходила трансформация:
- Осознавал ли менеджмент, для чего он собирается идти в гибкие методологии и Скрам в частности?
- Как до сотрудников донесли информацию о необходимости трансформации, и почему в этом помогут гибкие методологии и Скрам в частности?
- Как осуществили поддержку сотрудников в условиях трансформации, проводилось ли качественное обучение, аттестация и помощь в запуске команд?
Очень частая история, когда компании трансформируются, просто потому что это «модно».
В итоге что-то хорошее вряд ли получается, и возникающий ропот, впоследствии перетекает в волну негатива.
В этом плане мне понравилась одна фраза в тему: «In traditional companies, traditional managers organize traditional transformations.»
Однако, буду с вами честен: когда нам впервые «занесли» Agile/Scrum/Kanban, то именно про Скрам я как раз исходно думал, как о какой-то фигне с бесконечными встречами. Изменения в моём отношении к нему пришли после того, как в одном очень крутом проекте я сам себе задал вопрос: «А что если...?».
2. Гадание на Скрам по фотографии
Ещё одна причина негодования и даже какой-то озлобленности на Скрам — это его неверная интерпретация, связанная, в первую очередь с тем, откуда мы черпаем знания по нему. В результате, например, имеем «чайные церемонии», или «ритуалы жертвоприношения» вместо «событий».
Не исключаю также наличие раскольников, которые спорят о том, стоять на Ежедневном Скраме (Daily Scrum) кругом, квадратом, или какой-либо другой фигурой. Если кругом, то передавать слово по часовой стрелке, против, или как-то ещё.
При этом полностью отсутствует понимание того, для чего в Скраме существуют эти пресловутые обязательные встречи (события), которых, кстати, по пальцам одной руки пересчитать.
Глядя на огромный поток информации в сети, создаётся впечатление, что многие просто не знают, что является первоисточником и где черпать базовые знания по фреймворку.
Так вот, главным документом по Скрам является «The Scrum Guide», написанный в соавторстве Кеном Швабером и Джеффом Сазерлендом, доступный на многих языках, включая русский.
На мой взгляд, для того, чтобы получить базовые знания по Скрам и, впоследствии не засорять своё сознание всевозможными неверно истолкованными дополнениями к Скрам, требуется всего два основных компонента: желание и вдумчивое прочтение «The Scrum Guide», причём не один раз. Документ этот довольно компактный — менее двадцати страниц, осилить можно.
Что касается тренингов скажу коротко: будьте осторожны! В рамках этой статьи никого рекламировать не буду, но считаю, что «правильными тренингами» по этой теме в нашей стране можно доверять всего одной-двум компаниям.
3.«Толкование» некоторых разделов Scrum Guide и не только
В контексте того, сколько однотипных обсуждений в сети ходит относительно Скрам попробую заострить на них внимание и изложить моё понимание в соответствии со Скрам-гайдом и опытом.
Скрам является…
Выделю две из трёх характеристик: простым для понимания и трудным для совершенного овладения.
Некоторые думают, что здесь есть противоречие.
Спринт
В данном подразделе я намеренно поставлю несколько вопросов, которые, возможно, заставят вас задуматься и переосмыслить свой подход к фреймворку.
- В чём на ваш взгляд смысл называть фиксированные во времени интервалы работы Спринтами? Например, может проще каждые две недели просто отправлять отчёт о проделанной работе?
- Если вы в процессе перехода на Скрам, то какой длины вы выбрали Спринт? Когда я задавал этот вопрос, то чаще всего встречал удивлённый взгляд и следом ответ: «Стандартный — 2 недели».
- Почему вы выбрали Спринт такой длины?
- Почему не рекомендуется устанавливать длину Спринта более месяца?
Кто-то может не поверить, но ответы на эти вопросы есть в Скрам-гайде.
4. Daily Scrum (Ежедневный Скрам)
Одна из самых дискуссионных тем — Daily Scrum, он же Daily Standup Meeting, он же Ежедневный Скрам, или просто «Постояшка».
Вы можете мне не поверить, но у этого события есть фиксированное время проведения (time-box) — не более 15 минут, вне зависимости от длины Спринта.
Команда сама определяет формат встречи. А самое важное в этой пятнадцатиминутке — это понять статус продвижения к Цели Спринта.
Теперь вопросы на засыпку: многие ли из вас знают, что такое Цель Спринта? Многие ли из вас умеют её сформулировать? А кто вообще их формулирует?
В подавляющем большинстве случаев негодуют от Скрам именно из-за своего незнания и непонимания, для необходимо именно это событие под названием Daily Scrum.
Это не отчётная встреча! В тех встречах, которые я часто наблюдаю, не хватает разве что сообщений о том, сколько раз человек попил кофе, чай, воду, а также сходил в туалет. А «не более 15 минут» может и на полтора часа растянуться.
Ещё раз: Daily Scrum — это про движение к Цели Спринта!
Осознав только эту часть Скрама, вы, на мой взгляд, сможете совершить значительный прорыв.
И ещё ремарка, которая для многих становится открытием, Daily Scrum — это событие, в котором может принимать участие (заметьте, «принимать участие» и «постоять рядом, послушать» — это разные вещи) только Development Team (Команда Разработки)! Даже Scrum Master (Скрам-мастер) и Product Owner (Владелец Продукта), если они не являются по совместительству членами Development Team, непосредственного участия в этой встрече не принимают!
5. Скрам-мастер — это не Менеджер Проекта и не прислуга
Другая весьма распространённая тема: Скрам-мастер (SM) = Менеджер Проекта (Project Manager, PM).
Вы можете найти кучу статей на тему SM vs. PM.
Выделю основное:
- Скрам-мастер несёт ответственность за продвижение и поддержку Скрама в соответствии со Скрам-гайдом.
- Основные заблуждения про Скрам-мастера:
- Скрам-мастер НЕ управляет проектом;
- Скрам-мастер НЕ управляет командой (кого взять, кого убрать);
- Скрам-мастера не выбирают по принципу самого опытного, или долгоработающего сотрудника компании;
- Скрам-мастер НЕ является секретарём команды, “забивающим встречки”.
- В обязанности Скрам-мастера НЕ входит доставка пиццы по пятницам (любимая тема на тренингах), стирка носков и глажка шнурков Владельцу Продукта, или членам Команды разработки.
Зоны ответственности Скрам-мастера также изложены в Скрам-гайде.
В завершение этого раздела могу ещё несколько тем вбросить, для самостоятельной проработки, если кому интересно:
- Scrum, как карго-культ vs. Scrum и сюхари.
- Product Owner — это менеджер продукта, а не проекта, или команды. Здесь же PO vs. PM.
- Product Owner и Scrum Master в одном флаконе.
- Главное в Scrum — Ретроспектива, или встречал почти вот так: Scrum = Ретроспектива (а вот ретроспектива чего — это уже другой вопрос)!
- ...
Назрело в свете того, что по работе встречается, в комментариях, в том числе и на Хабре.
Скрам — это Кен Швабер, Джеф Сазерленд и их Scrum Guide. Смотрите End Note.
Скрам — это то, что в Скрам-гайде, а не то, что вы привыкли называть у себя в компании.
У нас тоже пока ещё не Скрам, но мы это понимаем, признаём и знаем, как двигаться к нему. Причём мы также понимаем, что двигаться туда точно надо, так как это действительно может принести огромную пользу организации.
Подводим итоги
Если приведёнными выше заметками я хоть кого-то сподвигнул задуматься и переосмыслить, что же всё-таки такое этот Scrum, да гибкие методологии в целом, то буду считать, что цели я достиг!
Вода камень точит и, возможно, в недалёком будущем мы уже не так часто как сейчас будем слышать “Вы очень увлеклись этим Скрамом, а исходя из результатов такой-то команды (использующей по факту СкрамНО) не стоит этого делать”.
Всем спасибо за внимание и буду рад вашим комментариям и замечаниям!
Ссылки
www.scrumguides.org/index.html
Комментарии (148)
eugenvz Автор
23.09.2018 12:25-2Прежде всего, спасибо за комментарий!
Цель как раз и была «вбросить», или просто, чтобы люди призадумались, что всё не просто так и не стоит «верить слухам» ;-), а многое можно почерпнуть из уже имеющихся общедоступных источников.
Я намеренно не стал растолковывать весь Скрам-гайд, а только дал «для затравочки».
Вам конкретно отвечу:
1. Цель спринта (беру из русской версии документа, хотя рекомендую пользоваться английской, как первоисточником): «Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта.»
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
Скрам-мастер — это лидер-слуга для Скрам-Команды. Людям вне команды он помогает понять, что из их взаимодействий со Скрам-командой полезно, а что нет. Скрам-мастер помогает изменить эти взаимодействия так, чтобы они максимально увеличивали ценность, которую создает Скрам-команда.
3. Product Owner (Владелец Продукта): Владелец Продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Способы достижения максимальной ценности могут различаться и зависят от самих организации?, Скрам-команд и конкретных людей.
Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта.
Как я уже написал в статье, одна из целей — это показать, что прежде чем давать какие-либо вольные интерпретации ролям и зонам ответственности, необходимо детально ознакомиться с первоисточником.
Что такое «ванильное определение», я не знаю но, подозреваю, что это частично то, о чём я писал: секретарь, прислуга, психолог. Вот как раз НЕТ!
В идеале СМ в части работы с командой стремиться создать из неё самоорганизующуюся команду и, опять же таки в идеале, команда должна научиться обходиться без него (без СМ).
Могу ещё много писать, но не буду :-), чтобы не написать коммент размером со статью :-)
Всегда готов пообщаться в оффлайне на эти темы!fcoder
23.09.2018 14:28«Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.
Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.eugenvz Автор
23.09.2018 15:23-1«Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.
В принципе можно посмотреть в гайде, включая обязанности СМ для PO, DevTeam и Организации. В общем там не только фасилитация.
Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.
В целом согласен с вами. Если уже не особо требуется команде, то пора ему подумать дальше, как расти, так как есть куда.
TyVik
23.09.2018 13:30Как в тему! Как раз читаю Scrum Guide, есть вопрос по понятию «scrum-команда». Я так понял, что она должна быть компактной (замкнутой и ограниченной), чтобы работа над артефактами итерации зависила только от неё. Как в таком случае быть с дизайнерами, которые в большинстве случаев представляют собой другой отдел?
Несколько раз упомяналось, что в команде есть всего одна роль — разработчик. Как тогда тестировать и деплоить? В общем случае этим могут (или должны) заниматься другие люди.eugenvz Автор
23.09.2018 14:26-1По Скрам-команде: должна быть кросс-функциональной и самоорганизующейся.
То, что вы, скорее всего, имеете в виду — это про кросс-функциональность (не следует путать со взаимозаменяемостью). То есть когда в команде присутствуют все необходимые компетенции для создания продукта от начала и до конца и, соответственно, она не зависела бы от компетенций извне.
В вашем случае необходимо договариваться и брать дизайнера в Скрам-команду, что, скорее всего, уже будет вопросом на уровне Организации и трансформации соответственно.
В Скрам-команде всего три роли: PO, SM и Development Team. Грубо говоря, «разработчик» (developer) в Scrum Team — это тот, кто непосредственно выполняет работу «руками» :-), например, кодит, тестит, организует маркетинговые компании и т.д. Короче не только о программерах идёт речь :-)staticlab
23.09.2018 23:33Непонятна формулировка из The Scrum Guide:
Скрам-мастер предоставляет услуги Команде Разработки:
— коучит Команду Разработки быть самоорганизующейся и кросс-функциональнойЯ могу представить себе коучинг по самоорганизации. Но что вкладывается в понятие коучинга для обеспечения кросс-функциональности команды?
— Нам нужно разработать интерфейс для нашего приложения, но у нас нет дизайнера!
— Но вы же кросс-функциональная команда!
… И пулемёт застрочил вновь.Hokum
23.09.2018 23:39Значит необходима внешняя косультация или внешний исполнитель, если это необходимо на постоянной основе, то нужно брать дизайнера в команду на постоянной основе. Кросс-функциональность — это не про то, что каждый "и швец, и жнец, и на дуде игрец". Это про то, то в команде есть отдельно "швец", отдельно "жнец" и отдельно "на дуде игрец".
staticlab
24.09.2018 00:03Да, определение кросс-функциональности понятно. Непонятна роль скрам-мастера в решении это проблемы. То есть он «обучает» команду, чтобы та сама просила у своей компании и PO себе дизайнера?
Hokum
24.09.2018 08:59Да, так это предполагается по The Scrum Guide. СМ — это штатный консультант-наблюдатель за процессом. Если команда отклонилась от цели и не проводит daily, он может подойти и сказать, что у вас тут какая-то фигня начинает происходить, вы отклонились от цели спринта, но повлиять ни на что он не может.
fcoder
23.09.2018 14:37Каждая задача перед тем как попасть в спринт должна пройти обсуждение (где уточняются детали, оценивается) и планирование (где определяется готовность для взятия в спринт).
Если выясняется, что задача не может быть взята до выполнения каких-то внешних для команды (в вашем случае дизайнерских) задач, то создаётся запрос (или задача) на ПОfcoder
23.09.2018 14:39(мобильная версия не позволяет редактировать)
… создается задача для другой команды. И на неё ставится ссылка. А дальше ваш ПО и ПО другой команды разбираются с приоритетамиeugenvz Автор
23.09.2018 15:27-1Судя по вашим комментариям вы очень даже в теме ;-)
Есть ещё такая штука как критерии INVEST, DOR (Definition Of Ready). Если вам интересно, то почитайте.
DOR — это то, что, например, про задачи внешнего вендора, от которых зависит ваша команда. Но фишка в том, чтобы не увлекаться DOR везде и всюду, так как перебор ведёт в неуместный Waterfall (я не против Waterfall, подчёркиваю «неуместный» в случае выбранного Agile-подхода).
dipsy
23.09.2018 14:24+4«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
В статье рассказывается нам, глупым, до сих пор не понимающим зачем стендапы, что 40 минут-то это конечно перебор и надо всего 15 (не считая времени на подготовку перед и возврат в работу после).
А всё равно непонятно, чем встречи в таком формате лучше например общего чата, где в реальном времени можно общаться, а не ждать 15-минутки следующего дня. Ну и прогресс опять же в реалтайме видно по чату и по коммитам с тикетами. Зачем эта ежедневная ритуальная клоунада с "что делал что сделано какие проблемы"? Нет ответа.usego
23.09.2018 15:29-1Хотя бы для того, что бы выдёргивать людей из зоны комфорта и заставлять общаться с командой. Есть определённый тип людей, которые днями могут сидеть над банальной проблемой и никого не спросить как её лучше решать. А на стендапах такое часто всплывает раньше, чем несколько дней.
dipsy
23.09.2018 17:13+2А есть определенный тип людей, который бы спокойно и продуктивно поработал в зоне комфорта и не дергался бы лишний раз.
днями могут сидеть
Тупо сидеть, уставившись в одну точку, или разбираться, изучать материал, искать варианты решения, разносторонне развиваться в процессе, в конце концов? Почему вы думаете, что это в конечном итоге будет менее полезно, чем если кто-то сразу ткнет в привычный ему вариант решения?
Отсутствие стендапов не подразумевает отсутствия общения. Общение в цифровом мире штука гораздо более многогранная, от тех же групповых чатов, до просмотров чужих коммитов, код-ревью. Была бы заинтересованность в общении, если человеку пофиг, ему и стендап не поможет.usego
23.09.2018 17:59-1Слушайте, эти люди сидят рядом, а не в стране эльфов. Не все команды имеют шикарную возможность выбирать одно CV из 20 сениорских, многим приходится брать всех подряд, кого не взяли компании покруче. И вот среди таких, поверьте, очень многих надо строить на стендапах, что бы не закапывались в своих песочницах и не тупили днями над проблемами, которые решаются за пару часов.
eugenvz Автор
23.09.2018 18:17-1Вы выдали ключевую фразу, которую я «подрежу» слегка:
Была бы заинтересованность
.
Смена методологии очень часто заставляет выйти наружу реальную заинтересованность (читай производительность, эффективность и т.п.) человека в работе. И скорее именно это уже не нравится человеку, а не «гибкость» той или иной методологии.
eugenvz Автор
23.09.2018 15:34-21. Глупыми я никого здесь не считаю.
2. Если 15-минутки идут ежедневно и в целом всё ок (все понимают для чего у них Скрам), то ненужно к ним готовиться.
3. События (обязательные встречи, если в общем) в Скрам не отменяют других встреч и прочего общения членов команды.
4. Про «клоунаду». Формат Daily Scrum может определить сама команда. Важно получить информацию по статусу движения к цели спринта и есть ли какие проблемы с этим.
В целом, если команда только начинает свой путь в Agile/Scrum, то лучше просто следовать гайду (видимо это подразумевается под «ритуалами»). Дальше, по мере того, как будет больше опыта и понимания фреймворка, всё должно стать проще. На самом деле в статье я вскользь упомянул про «сюхари» (можно посмотреть Вики) — это, на мой взгляд, как раз на данную тему.
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.dipsy
23.09.2018 17:27+3Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.
Очень часто возникает ситуация, когда просматривая коммит коллеги, который, по моему мнению, делает там что-то не то, предлагаю ему решение, которое сам знаю. Сразу предлагаю, не ожидая следующего дня и ритуальной сходки, понимаете? Более того, даже работа с 9 до 18 с пн по пт, это пережиток прошлого, люди всегда онлайн, всегда доступны, не надо всех собирать в одном месте, чтобы донести информацию или взаимодействовать друг с другом.
Вот я здесь оставил информацию, с ней в ближайшие часы ознакомится пара десятков человек, мне не надо их ждать, собирать где-то, тратить их время, отвлекать от чего-то важного, когда им будет удобно они зайдут и прочитают (сейчас читаете), возможно даже как-то отреагируют. Вот так это работает в 21 веке.nekt
24.09.2018 02:09сколько времени надо тратить, чтобы мониторить все коммиты коллег? А если он не хочет «пушить в общий репо, пока не причешу историю коммитов»?
В общем случае стендапы достаточно показательны для определения зрелости команды. Если все процессы идут как надо, если члены команды проактивны, если цели понятны, то даже 15 минут будет много. Просто шанс оттранслировать в команду происходящие прямо сейчас процессы.
Простое сообщение вида «Делаю задачу Х, столкнулся с проблемой Y, Z обещал показать как она решалась раньше» занимает 20-30 секунд, а тот, кто хочет побольше узнать о проблеме Y может просто подойти после стендапа и послушать, а что, а как.
eignatik
24.09.2018 19:15Вам ведь никто не запрещает за пределами ежедневного скрама общаться по разным вещам. 15 минутами не ограничивается общение, это подразумевает, что у вас есть 15 минут на команду, чтобы рассказать статусы с точки зрения общей перспективы текущего спринт. То есть можно заострить внимание на какие-то важные проблемы, но самое важное, держать в курсе всех не о том, какой код и комиты вы делаете, а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.
dipsy
24.09.2018 19:24Послушайте, у меня в сутках 24 часа, а вы хотите украсть из них 30 минут (стендап + подготовка и время на возврат к работе). Мне жалко, жизнь не вечная.
а что с точки зрения прогресса по задаче вы сделали, и как это влияет на прогресс в спринте.
Давайте я когда сделаю, вам сразу сообщу, так не лучше будет? И если проблемы возникнут сообщу, сразу. А если вы ждете пока я что-то сделаю, чтобы свою часть начать, тоже можем договориться. Не обязательно всем собираться в кружок, да ещё каждый день.time2rfc
24.09.2018 21:01Простите за мой вопрос, не хотел вас обидеть, скорее лучше понять позицию.
А вы на работе 8 часов от звонка до звонка работаете не покладая рук и не отвлекаясь ?
eignatik
24.09.2018 22:22Я понимаю, что есть люди, которые предпочитают такой режим, и в нем работают вполне успешно. Но на мой взгляд, когда речь идёт о большом проекте, где работает команда из большого количества людей, и кроме такой команды есть ещё другие команды и им надо синхронизироваться и так далее, то это бывает очень полезным и важным. Скрам — это не лекарство от всех бед, есть много методологий и они работают не хуже. Просто если процесс поставлен правильно, то обычно понятно, зачем в данном случае используется такая методология итеративная.
Одна из важных причин, почему так же используется Скрам — это прогноз и оценка, планирование. Я понимаю, что такие вещи могут не интересовать простого разработчика, но с точки зрения продукта — это важно, потому что это деньги. Чем более точное планирование, тем больше денег сохранит бизнес (в общем случаеъ есть много специфики от области бизнеса). Например, если разработка ведётся итерациями и все это мониторится, собираются метрики, то спустя какое-то время можно сказать, на какой капасити команда может 100% отрабатывать, и вы будете удивлены, на сколько точно такие «предсказания» работают. Но это при условии корректной интерпретации и применения методологии. Если коверкать понимание методологии, то лучше делать без неё. У меня есть опыт работы в компаниях, где использовали скрам, потому что надо бы, и от этого процесс страдал. И наоборот, работал там, где процесс поставлен грамотно, и разница видна очень сильно.
Я не призываю использовать скрам. Потому что он не всегда подходит, есть много причин его не использовать, в зависимости от многих факторов. Но нередко правильное применение скрама наводит правильный порядок и упрощает разработку продукта.
gennayo
25.09.2018 06:14Вы можете привести хоть какие-нибудь цифры, позволяющие сравнить состояние «до» и «после» внедрения скрам?
staticlab
23.09.2018 21:28+2Про «клоунаду»
видимо это подразумевается под «ритуалами»Вы, скорее всего, не в теме. Дело в том, что в крупных компаниях роль скрам-мастера отождествляется с коучингом, и такие «скрам-мастера» начинают на скрам-событиях (да и не только) проводить разнообразные психологические активности и тимбилдинги. Эти активности буквально и выглядят как хороводы, клоунада и прочий детский сад, а занимают часто несколько часов. Естественно, что приводит это к резко отрицательному эффекту. Попытки жаловаться начальству как правило ни к чему не приводят: «Ну какие же это хороводы? Это аджайл.»
eugenvz Автор
23.09.2018 21:39Я как раз от крупных компаний и отталкивался ;-) и прекрасно знаю, что в первую очередь СМ это почему-то психолог/психиатр/психоаналитик :-)
Согласен с вами, что карго-культ, который в итоге получается, ничего кроме негатива не вызывает.
Об этом в том числе я и писал.
Я смотрю на комментарии и понимаю, что многие восприняли мою статью, как оду Скраму, как к призыв к тотальному переходу на него. На самом деле это не так, но каждому я не собираюсь это доказывать.
Эта статья на «задуматься», а не «мы все в Скрам!».staticlab
23.09.2018 21:46+1и прекрасно знаю, что в первую очередь СМ это почему-то психолог/психиатр/психоаналитик
Я бы не ставил психиатра и психоаналитика в этот ряд. Всё-таки они имеют дело с гораздо более серьёзными проблемами.
Разработчики не любят упоминание Скрама потому, что его часто просто спускают сверху вместе с СМ, и за этим термином часто скрываются как раз-таки вышеописанные карго-культы.
staticlab
23.09.2018 21:58а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой
Но, что характерно, обсуждать решение этой проблемы на Daily нельзя. Нужно искать отдельное время. А если проблема требует участия в обсуждении более двух человек или даже всей команды разработки, то планировать отдельное совещание, которое может случиться даже не сегодня. В результате выпадает как минимум день.
eugenvz Автор
23.09.2018 22:06Верно в отношении того, что на Daily проблемы не обсуждаем, а обозначаем.
Насчёт их решения не понял, почему теряется день. Если проблема важная, то никто не мешает её обсудить сразу после Daily. В общем вопрос организации своей работы, в частности, вопрос приоритизации.staticlab
24.09.2018 11:05Насчёт их решения не понял, почему теряется день.
Потому что для совместного мероприятия требуется, чтобы все были свободны, т.е. ни у кого не было никаких других встреч. В крупных компаниях это очень часто не так: кто-то из коллег может быть на занятии по английскому, другом тренинге, на собеседовании, уйти на обед… Или же банально могут быть заняты все переговорки.
MacIn
24.09.2018 02:17Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой
Ну, тогда этот кто-то просто по факту обращается к коллегам, в общий чат, например — он же сам понимает, что тупит над решением. После первого-второго такого скрытого случая ему объяснят, что если ты тупишь, то обратиться к коллегам — не зазорно.
Зачем тут ежедневные летучки?
reishi
23.09.2018 14:32+2Если команде нужен скрам-мастер, значит пора сменить команду
eugenvz Автор
23.09.2018 14:34-21. Если команда хочет работать по Скрам, значит СМ ей нужен.
2. Если команда работает не по Скрам, СМ ей не нужен.
Вроде основные ситуации разобрали.
Tyiler
23.09.2018 14:41развелось вас, болтунов и лоботрясов. менеджеров не хватает чтоли?
назови как-нидь еще тогда «НЕДОКРАМ», пойдет название? или тебе надо простыню текста еще написать, как правильно жить по «НЕДОКРАМ»у?
ПС: не просите только уточнять: «каких именно не хватает?, когда они не нужны?»…eugenvz Автор
23.09.2018 15:09При первом знакомстве, на мой взгляд, неправильно хамить.
Подобное отношение, как у вас, встречал и довольно часто. Не назвал бы его высокоэффективным.
А просить, или оправдываться перед вами и не собирался, так как в данном случае это всё равно что «бисер перед...» (дальше наверное известно).Tyiler
23.09.2018 15:13называю вещи своими именами.
есть что ответить по сути? чем отличается СМ от менеджера, кроме того что он прочитал портянку текста об скраме?eugenvz Автор
23.09.2018 15:15-2Вам нечем, потому что, исходя из своего опыта (очень большого кстати), это бессмысленно. Потому что начинать надо издалека, минимум, с 90-х.
Но здесь это будет потерей времени.boodda
23.09.2018 16:28Вы похожи на Свидетеля Скрама. Вам показалось, что вы поняли все, но на самом деле, вам кто-то продал мысль о том, что некие модели управления могут заменить лидера. И вот такие недолидеры, которые боялись брать на себя ответственность, потому что они хреновые лидеры и все просирали, придумали как её(ответственность) размазать по куче людей. И в случае чего сказать — это не я говно, а команда. Я то все по скраму делал…
eugenvz Автор
23.09.2018 16:34Вы ошибаетесь, мне никто ничего не продавал.
Что касается ответственности, то в итоге она на PO, например. Он отвечает перед стейкхолдерами. Так что, как минимум, одного ответственного отыскали.
Если вы делите PO и DevTeam, то это уже не команда (то есть не та самая Scrum Team).boodda
23.09.2018 17:09+1По скраму команда самоогранизуемая, и вот когда стекхолдеры спросят с PO за просраный дедлайн, тот в лучших традициях, скажет — «команда сработала не так, а я что?? Я то все по скраму делал, а вот Вася с Петей в скрам не верят вот и все пошло по п… не так».
Вот как так получилось? Вроде на русском написал, но как то не очень похоже на русский.eugenvz Автор
23.09.2018 17:31Это про частые реалии и здесь я спорить не буду. Те, про кого вы написали — это не PO и, соответственно, это не команда. Есть ещё одна схожая ветвь, когда без стейкхолдеров «типа PO» начинает в конце спринта неприятно удивляться результату, выданному DevTeam. И это тоже не PO и не команда.
Но не только в книжках, но и в жизни я встречал и работал с командами, которые были единым целым — Scrum Team. Там, в общем-то было без сюрпризов и без «размываний» и прочих «размазываний» ответственности.
В одном из своих комментов я уже ссылался на одно интервью, где речь шла о совсем других компетенциях (более высокого уровня), когда идёшь в гибкие методологии.boodda
23.09.2018 18:14+1Скажите честно, это были вполне коммуникабельные профессионалы своего дела? могли они также эффективно работать без скрама? Дал ли скрам стабильный прирост эффективности хотя бы 20% на протяжении года или двух? Было ли это экономически оправдано? То есть, дополнительное время которое уходит на планирование в рамках команды, ретроспективы, митинги, демонстрации помноженное на стоимость человеко-часа, оно приносит экономический эффект для этих продуктов? ну и про реалии тоже не стоит забывать в вашем ответе
eugenvz Автор
23.09.2018 18:49+1Я считаю, что даже специалистам высокого класса можно было бы извлечь пользу из гибких методологий.
В ваших сообщениях чувствуется «боль потери времени на совещания». Это может быть вызвано тем, что:
1. Может Скрам в принципе не подходит для вас (Скрам — не серебряная пуля).
2. Может нет реального понимания, как правильно проводить эти совещания. Нет «того СМ», который должен был объяснить, что к чему.
Одна из интересных вещей, которую я в своё время открыл в Скрам — это то, что оказывается в нём тоже есть планирование :-) Причём даже посерьёзнее в некоторых моментах, чем в старом добром Waterfall.
Ещё раз: я не склоняю всех ксожительствуСкраму. Просто то, что часто называют Скрамом, как правило, таковым не является.boodda
23.09.2018 19:26боль вы мою почувствовали, и её я не скрывал, но на ответы мои вы так и не ответили. Но я буду надеяться и ждать
eugenvz Автор
23.09.2018 19:341. Были вполне себе профессиональные работники.
2. В другой сфере деятельности, скорее всего могли бы. В той, где я это наблюдал, со Скрамом было эффективнее.
3. В процессе сбора статистики и пока она в плюсе.
4. См. п. 3.
5. Планирование по Скрам в наших реалиях позволяет сэкономить очень много времени, а значит и денег.
fcoder
23.09.2018 19:01И тут выходит на первый план отчётность, которая показывает наглядно (на графиках), что и петя и вася в последние скажем 10 спринтов деливерят нормально (не хуже других в команде), а проблема в другом. Например, скоуп гораздо больше продуктивности команды и тренд непопадания проекта в дедлайн был виден ещё 6 спринтов назад.
На роли рядового участника команды возможно даже вполне получится работать «не веря» в скрам, если честно отвечать на вопросы по оценке задач, репортить статусы и учавствовать в ретро.
Возможность делать оценку производительности, предсказывать готовность фич (с точностью примерно в 2 спринта) — это то, за что так любит скрам руководство.nekt
24.09.2018 02:15Как показывает практика, когда фокус внимания смещается с «побольше сторипонинтов закрыть» на «сделать нормальный сервис/продукт», начинают возникать вопросы «а так ли нам нужно все то, что мы делаем», «а не пора ли озаботиться тем, будет ли оно выдерживать нагрузку», «а почему у нас задачи по исправлению багов в функционале Х делаются в три раза дольше, чем добавление нового функционала в проекте У». И что еще важнее, эти вопросы начинают обсуждаться.
dimm_ddr
24.09.2018 16:19Если есть нормальный QA или как вы этих людей называете, то такие вопросы должны задаваться в любом варианте работы команды. Но вот в скраме с их сторипоинтами и спринтами вещи вроде:
а почему у нас задачи по исправлению багов в функционале Х делаются в три раза дольше, чем добавление нового функционала в проекте У
отследить обычно проще. Хотя бы потому уже что такая статистика в принципе собирается.
staticlab
24.09.2018 17:09+1чем отличается СМ от менеджера
Тем, что менеджер по определению кем-то руководит, а СМ — ни за что не отвечает.
Tyiler
23.09.2018 15:04+5еще понравилось
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
короче, работает работу.
если б он еще массаж делал — шеи разминал, или там… чай разносил, больше пользы бы было.
tangro
23.09.2018 15:22+6Скрам — это как ритуальные танцы шаманов для вызова дождя. Один шаман потанцует — и дождь идёт. А другой потанцует — и дождь не идёт. Это, наверное, потому, что второй неверно потанцевал?
Если в хорошем проекте взять и выбросить, ну я не знаю, тимлида или сервер с базой данных — проекту станет плохо и это будет видно сразу. Если же в хорошем проекте взять и выбросить скрам-мастера, то не изменится ровным счётом ничего: и тимлид и сервер с базой данных продолжат работать. Как в том анекдоте, что простуда проходит за неделю, если лечить, и за 7 дней, если не лечить.
Ermit
23.09.2018 15:24+2Всё хорошо в меру. Когда скрамом и аджайлом подменяется работа — тогда плохо. Когда они используются как инструменты (с максимальной эффективностью) — тогда хорошо. В любом случае, это зависит от команды и менеджмента, ибо нельзя техническими средствами решить организационные проблемы. А при хорошем менеджменте и эти костыльки будут работать не хуже прочих…
maxzh83
23.09.2018 15:29+2Зашел в комментарии, чтобы увидеть «ответку» — альтернативную методологию «Пиши код бл..». Полностью вот здесь
На самом деле, какие в скраме есть неплохие вещи, главное вовремя включать голову и чтобы это не перерастало в культ ради культа.DikSoft
24.09.2018 08:57+1!
Плюсом было бы, чтобы это не _навязывалось_ вообще везде. В команде развития ИТ инфраструктуры, например.
geher
23.09.2018 15:50+3У меня вся эта клоунада вокруг технологий органзации работы навевает следующие мысли.
Команда разработчиков должна выбирать не модную технологию, а ту, что удобна именно этой команде.
Иначе почти гарантированно получается карго-культ со всеми его негативными последствиями.
Самое "веселое" бывает, когда какая-то команда создает для себя удобную систему, потом этой системе дают звучное название, рекламу, внедряют направо и на лево, не задумываясь, а подходит ли оно данной конкретной команде. А потом со всех сторон идут негативные отзывы.
Похоже, что именно это и произошло со скрамом, давно превратившимся из всего лишь одной из многих систем организации работы в команде в какой-то бессмысленный культ.
И попытка "вернуться к истокам" уже ничего особо не дает, поскольку культ сформировался именно в том виде, который сейчас имеем.
Amokmorg
23.09.2018 22:07что б это не стало карго культом как раз и нужен скрам мастер.
geher
23.09.2018 22:49А если этот скрам мастер (со всеми бумажками) является частью или даже основанием карго культа?
Ну да конечно, теперь мы знаем, что он не настоящий скрам мастер.
Только непонятно, как это знание может помочь.staticlab
23.09.2018 23:12+1Судя по принципам Манифеста Agile:
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.ответственная команда должна выгнать такого «скрам-мастера» и работать дальше самостоятельно. Иначе это будет не Agile.
geher
25.09.2018 21:49Фокус в том, что выгнать "неправильного" скрам-мастера может только настоящая скрам-команда. А если у нас просто клоунада с таким же названием, то и мастер соотвествующий, и выгнать его не получится.
eugenvz Автор
23.09.2018 16:01+1tangro, Ermit, maxzh83, geher,
Да, отчасти про это и статья.
Я, ровно как и создатели Скрам, не считаю Скрам серебряной пулей. Всему есть своё применение. Я также абсолютно не призываю «натягивать сову на глобус» (то есть использовать всем только Скрам).
Речь о том, что не вникнув в суть чего-либо (в данном случае был выбран Скрам, а вообще можно к чему угодно применять) начинается череда незаслуженных оценок, негатива и пр.Hokum
23.09.2018 16:14+1В этом то и беда. Такие вещи хорошо работают когда все понимают за чем это и единогласно пришли к выводу, что надо это внедрять. Скрам подразумевает личную вовлеченность каждого члена команды в процесс, тут нет места «мне сказали делать — я делаю». Каждый должен осознавать, что он делает и как его деятельность помогает достижении поставленной цели. Это другой уровень ответственности. А сейчас получается, что «все бегут и мы бежим».
eugenvz Автор
23.09.2018 16:19Да, так и есть.
В одном интервью очень правильно заметили, что гибкие методологии требуют более высокого уровня компетенции, проектной и профессиональной дисциплины. В ином случае получаем хаос, потерю контроля, а, значит, и денег.tangro
24.09.2018 11:04а хорошая методология гарантировала бы приемлемые результаты и для обычного уровня компетенции и дисциплины
boodda
23.09.2018 18:21«мне сказали делать — я делаю», это результат того, что «мы все решили — ваше дело сделать, кто не согласен может уходить»
Hokum
23.09.2018 18:47Не совсем, это нормальная ситуация в типичной иерархической структуре, где начинающий разработчик еще не в состоянии качественно декомпозировать задачу и ему дают ограниченный круг задач и его ответственность минимальна. Скрам же подразумевает равную ответственность каждого члена команды разработки и близкий уровень «скилов». Только тогда такая команда будет эффективной, справедливости ради, такая команда профессионалов будет эффективна при использовании любой методологии. Но для скрама это необходимо, в противном случае «слабое» звено команды будет постоянно вываливаться из процесса.
Ermit
23.09.2018 16:20+1Да, это так. Но я два года жил под скрамом и мой опыт — практический. Никогда (слышите — никогда) я не стал бы использовать скрам на этапе проектирования. :) А вот на этапе отладки и рефакторинга — да, это годная методика.
solver
23.09.2018 17:07+3Офис. С утра офисные сотрудники в спешке передвигают мебель с места на
место, выравнивают все по сантиметру, компасу и т. д.
Посредине всего этого хаотичного движения стоит старенькая уборщица в
обнимку со шваброй, испуганно смотрит на все это действо и бормочет про
себя:«Только помыла, сейчас все опять затопчут, уроды».
Стояла долго смотрела на все это, потом спрашивает:
— Милые, а что вы тут делаете? Переезжаете?
— Да нет, бабуля, мы сейчас мебель по фен-шую передвинем и у нас сразу
продажи взлетят до небес.
— Сынки, я тут давно уже работаю, еще до революции полы в этом здании
мыла. Так вот, до революции тут был публичный дом. Так там, когда касса
падала, кровати не двигали — там сразу бл**ей меняли.eugenvz Автор
23.09.2018 17:25+1Да, последний абзац довольно ходовой и в наше время :-)
Но, пожалуй, всё это больше про «Скрам, как карго-культ», что лично я абсолютно неприемлю и считаю, что подобный подход в основном и бросает тень на фреймворк.solver
23.09.2018 19:44+4Я учавствовал в нескольких командах работающих по скраму. Проходил тренинги по скраму от скрамтека. Ничего кроме ритуалов не увидел.
Зачем нужен дейли митинг? Он только ест время. Все тупо сидят и перечисляют что они делали. Никакой практической ценности это не может нести даже теоретически. Только отвлекает всех от работы.
Все эти ужимки и приседания в виде планопокеров, митингов и прочего говна немогут заставить человека работать если он не хочет.
Если подумать, то все сводится, условно, к задачам в джире.
Человек берет задачу в джире и делает ее, например, 3 дня. Он делал бы эту задачу те же 3 дня и без аджайла. Без всех этих оценок и прочей пустой траты времени. И за неделю он сделат к примеру 7 задач. Есть аджайл или нет.
В 98м году писали софт на дельфях. По понедельникам встречались с заказчиком, смотрели что сделано, планировали следующую неделю и делали. Никто это не называл никакими модными словами. Все работали. Не выдумывали этой дичи с планпокерами и прочими приседаниями.
Не заставляли людей заниматься херней называя это фреймворками…
В общем все, что я видел успешного про аджайл, можно охарактеризовать любимой фразой Шелдона из сериала теория большого взрыва — «После того не означает в следствии того».staticlab
24.09.2018 12:41Человек берет задачу в джире и делает ее, например, 3 дня. Он делал бы эту задачу те же 3 дня и без аджайла. Без всех этих оценок и прочей пустой траты времени. И за неделю он сделат к примеру 7 задач. Есть аджайл или нет.
Разница только в том, что если оценивать задачи предварительно, то есть шанс их недооценить и, соответственно, не успеть закрыть спринт. Это не покер, а самый настоящий преферанс :)
Кстати спиральная модель, судя по всему, отличается тем, что срок итерации гибкий, можно закрыть её когда команда посчитает нужным, и не страшно, если некоторые задачи при этом остались недоделанными.
В 98м году писали софт на дельфях. По понедельникам встречались с заказчиком, смотрели что сделано, планировали следующую неделю и делали. Никто это не называл никакими модными словами. Все работали. Не выдумывали этой дичи с планпокерами и прочими приседаниями.
Это просто итеративная разработка. Как мы уже выяснили ранее, Скрам — это то же самое, только с добавкой вот этой вот мишуры.
UnrealQW
23.09.2018 17:28-1Статья похоже на мысли вслух и поток сознания… Суть ее можно свести к следующим тезисам:
1. Не все вещи являются тем, чем они выглядят, хотя могут и выглядят тем, чем являются, но не факт ибо см. п.2.
2. Думайте во время работы как правильно работать ибо см. п.3.
3. Скрам-гайд — библия
avost
23.09.2018 17:49+3Любопытно, это только среди новообращённых скруммастеров популярна мантра — если у вас скрум не работает, значит вы используете не скрум и только бросаете на скрум тень? Никогда не слышал, чтобы условные "отвертко-мастера" на заявление, что не получается вкручивать отвёрткой гвозди заявляли, что всё получается, просто вы на самом деле использовали не отвёртку, поэтому нечего бросать на отвёртку тень, ею вполне можно закручивать гвозди!
eugenvz Автор
23.09.2018 18:32Не знаю, что там с новообращёнными, но настоящие СМ свои ошибки признавать могут (да, я и такое видел). В каждом случае, почему Скрам не работает разбираться надо. Может его вообще не стоит в конкретном случае использовать (повторюсь, что я не за то чтобы Скрамом затыкать все дыры)?
Более того, знают текущее состояние команды, и у них обязательно есть план по тому, как команде двигаться дальше.
Я вас уверяю, что у большинства скептиков округлятся глаза при вопросах про метрики.
Начнут рассуждать, что сейчас всё хорошо, и будет обязательно лучше.
Беда вот только цифр обычно от них не допросишься…avost
24.09.2018 17:50В каждом случае, почему Скрам не работает разбираться надо.
Почему не работает? Как-то там работает. Если достаточно долго мучаться, то и отверткой можно вкрутить гвоздь. Но зачем?
Я вас уверяю, что у большинства скептиков округлятся глаза при вопросах про метрики.
А что не так с метриками?
Беда вот только цифр обычно от них не допросишься…
Из скрам-метрик мне больше всего всего нравится "показатель счастья". Докладываю, что цифра показателя счастья от необходимости участвовать в скрам-балаганах у меня находится на отметке, — "идите в жопу, с вашим скрамом". Но это, конечно, от того, что скрам у нас "ненастоящий", вообще не скрам и я просто бросаю на скрам тень, да.
time2rfc
24.09.2018 18:01Если достаточно долго мучаться, то и отверткой можно вкрутить гвоздь. Но зачем?
А расскажите, пожалуйста, что работает? Мы думаем о возможном изменении процессов, интересен чужой позитивный опыт.
arielf
23.09.2018 19:35Любые «гибкие» способы разработки или управления вызывают у меня мигрень. Напрогибались. У меня не безумно сложные проекты были и размеры рабочей группы в 3 — 4 человека, но и в них любая «гибкость» вела к мгновенному неконтролируемому увеличению энтропии.
Возможны ли scrum и прочая имитация бурной работы в, например, аэрокосмической инженерии? Не возможны — и слава Богу! Иначе Лунная программа так бы и не началась! В аэрокосмической инженерии невозможно на этапе финальной сборки ракеты сказать конструктору: «а увеличь-ка число её пассажиров на 5 человек, вам же не сложно? у вас же масштабируемая архитектура?»
А в программной инженерии у заказчика требования по 5 раз в месяц меняются. И проекты зависают на месяцы или выпускаются сырыми! И сие не нормально! Требования нужно зафиксировать в проекте и не менять — а любое изменение, не заложеннное в нынешней архитектуре — новый проект, новые расчёты и новый заказ. Ну и сроки, конечно, приблизятся к срокам в аэрокосмической инженерии, но, оно и к лучшему — ибо и качество вполне возможно приблизится.
А щаз заказчики верят, что раз программные инженеры не тратят никакие ресурсы, кроме времени и мыслей — знач их можно прогибать на любые изменения в любое время! Нельзя!usego
23.09.2018 21:53Скрам и прочий agile появился именно из-за реалий жизни, что все требования невозможно заложить заранее. Но начинать проекты без планирования вообще, типа у нас скрам, по ходу дела разберёмся — это другая крайность.
arielf
23.09.2018 23:15+2И в аэрокосмической инженерии невозможно всё заложить сразу. Но стараются — и на старте никому не стукнет в голову попросить впихнуть в ракету ещё пару человек. А причина — кажущаяся заказчику низкая цена и лёгкость изменений в программе. А Срам появился как попытка заказчика оправдать свою некомпетентность.
Hokum
23.09.2018 23:33-1Разные проекты — разные подходы. Это нормально, гибкие методологии не везде будут работать или не на всем жизненном цикле продукта. Тут в другой статье поднималась похожая тема: https://habr.com/post/422327/#comment_19073275.
Выпускается MVP и далее на не него наращивается функционал ну или не наращивается — зависит от того, как прошел пилотный запуск. Это удобно когда по сути сам не знаешь что делаешь, но есть идея. Когда есть полное понимание, то можно и без гибких методологий обойтись.
Это все работает когда есть возможность сформировать небольшие кросс-функциональные команды (до 9 человек), если команды большие, то скрам, да и прочие гибкие методологии работать не будут, это должен быть сверхвысокий уровень самоорганизации у каждого отдельного члена команды, чтобы это не скатилось в неразбериху и хаос. Кстати русскоязычная википедия согласна с этим:
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с управлением ими комбинированным (либеральным и демократическим) методом [Гибкая методология разработки].
MacIn
24.09.2018 02:43Все же сранивать негибкость железячных и программных технологий не очень верно.
gennayo
23.09.2018 19:45А может кто-нибудь из сторонников SCRUM привести измеренные цифры роста эффективности разработки при его применении?
usego
23.09.2018 22:00+2Кто сказал что у скрама цель повысить эффективность? Цели несколько иные. Это в том числе методология работы со стейкхолдерами. В нашей команде это первое, чем помог скрам. Обозначил capacity команды и дал возможность заставить стейкхолдеров расставлять приоритеты по ограниченному ресурсу.
MacIn
24.09.2018 02:55+1А без scrum'а stakeholder'ы не поймут, что команда в 5 человек не может выполнить работу сотни?
usego
24.09.2018 10:33Они даже между собой не могут договориться о функционале. SPM — хороший способ заставить их хотя бы между собой поговорить, заодно расставив приоритеты поверх капасити.
MacIn
24.09.2018 14:13Project manager концентрирует и координирует обсуждение функционала. Скрам тут при чем?
usego
24.09.2018 15:06PMу (а в скраме это другая роль), надо оперировать какими-то KPI, что бы планировать / обосновывать ёмкость команды. Да это можно делать и не по скраму, а хоть в канбане, но у канбана свои грабли. Тут, как правильно написали, серебряной пули нет. Мой пойнт — не надо на скрам смотреть лишь с позиции программиста, так действительно непонятно на фига оно всё надо.
MacIn
24.09.2018 18:02надо оперировать какими-то KPI, что бы планировать / обосновывать ёмкость команды.
Сами разработчики могут дать ETA. Как иначе? Данные по-любому с потолка ПМами не берутся. Только опять же — при чем тут скрам…
НАСТОЯЩИЙ СКРАМ НИКОГДА НЕ БЫЛ ПОСТРОЕН!staticlab
23.09.2018 21:40Скажите, а всё-таки, в чём отличие Скрама от итеративной и спиральной моделей разработки? Почему на всех лекциях по Аджайлу упоминается только каскадная модель (она же Waterfall), которую не рекомендовал использовать даже впервые упомянувший о ней в 1970 году Уинстон Ройс, рекомендовавший итеративную модель?
eugenvz Автор
23.09.2018 22:13-1Скрам — это, скажем так, одна из реализаций Agile.
Agile использует итеративную модель.
Полагаю, что отличий здесь не стоит искать.
vladimir123456
23.09.2018 22:13Неужели есть профессиональные программисты которые серьезно воспринимают SCRUM?
eugenvz Автор
23.09.2018 22:16-1Как я (и не только я) уже здесь писал, Скрам и вообще гибкий подход — это про ВЫСОКОпрофессиональных программистов и сотрудников в принципе.
Уровень организации труда (дисциплина, саморганизация и т.д.) должен быть на порядок выше, чем при более традиционных подходах. Иначе это хаос, негодование, потеря времени и денег.MacIn
24.09.2018 03:25+2Уровень организации труда (дисциплина, саморганизация и т.д.) должен быть на порядок выше, чем при более традиционных подходах
Традиционных — это каких именно? И ведь мы говорим НЕ о методологиях, верно? Вы сами написали, что scrum — вариация итерационной методологии.
nekt
24.09.2018 02:25-1Хотелось бы кинуть камень в скрам — это управленческий фреймворк в первую очередь. И он очень не близок технарям, которые привыкли брать и делать, а потом страдать от изменившихся требований. Одно время я скептически относился к скраму, однако, если удается завести нормальный гибкий процесс, то как минимум работа становится приятнее.
Какие-то технические практики, которые по сути своей тоже agile можно выцепить из книг про экстремальное программирование, из практик девопсинга — они все про то, как быть более гибким в разработке, не привязываясь к методологиям управления проектами.
vladimir123456
24.09.2018 08:58-2SCRUM — это религия, нужно постоянно совершенствоваться изучая дарованный сверху манифест, где буквально все расписано — когда встречаться, о чем говорить… Очень полезно читать статьи просветленных последователей SCRUMA, как их жизнь изменилась после того как они обрели веру. Есть и наказание для тех кто не соблюдает всех заповедей — неминуемый крах проекта.
DikSoft
24.09.2018 12:13Очень точно подмечено. И как и любая религия, эта штука не решает проблемы а тупо их подменяет на разговоры о вечном и правильном. Пресекая любые обсуждения себя, любимой.
ggo
24.09.2018 10:44+1Ребята… технари… ит-шники…
Скрам — он не про ИТ.
Скрам — он про бизнес.
это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью.
Здесь ничего про ИТ. Только про бизнес.
Про то, как бизнесу в условиях неопределенности, выводить на рынок и развивать определенные продукты (не любые продукты).
И чтобы итшнику работать по скрам, он должен стать частью бизнеса. Быть его (бизнеса) неотъемлемой частью. Думать бизнес-ориентированно, планировать бизнес-ориентированно, оценивать бизнес-ориентированно.
Очевидно, такое подходит не всем ит-шникам. Не все разделяют ценность бизнес-ориентирования. И тогда возникает, то что здесь в комментариях красочно живописано.
И при этом нет правых и не правых.
Есть разные подходы к ведению бизнеса. Скрам — один из.DikSoft
24.09.2018 12:21Это реально не про ИТ, это про безответственность бизнеса. Менять ТЗ на ходу. Объявив это нормальным.
Hokum
24.09.2018 14:00Речь не про изменение ТЗ на ходу. Когда есть конкретное ТЗ, то нет места скраму. Это две разные модели. Если работать по ТЗ (в идеальном мире), то заказчик выдает определенный набор требования, команда оценивает и называет срок и сумму. В указанный срок заказчик приходит и ему отдают готовый протестированный продукт. Т.е. фактически покупается конечный продукт, в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки.
Он выдвигает набор требований, какое-то подмножество наиболее актуальных реализуется и отдается заказчику на использование, команда начинает работу над следующим набором. В процессе использования у заказчика появляются новые требования, новые запросы и так далее, пока заказчику не надоест улучшать/переделывать продукт.
Это если применительно к ИТ.
DikSoft
24.09.2018 14:05… в случае гибких методологий, заказчик покупает не продукт как таковой, а время команды разработки
об этом я собственно и написал. У бизнеса появляется сценарий, когда он может ни за что не отвечать! Сейчас хочу так, завтра — эдак, но мы это обзовём новым словом «скрум» и будем парить мозг команде разработчиков перманентно и без конечных сроков!
ЗЫ И главное — без ответственных за сорванные сроки проекта в целом. Потому как … Ну, Вы поняли?Hokum
24.09.2018 14:17Бизнесу не выгодно бесконечно развивать продукт, если он провальный, а в случае если он успешный и постоянно развивается, то команда разработки имеет постоянный доход. Если команде разработки надоело поддерживать продукт она может закончить работу на любом спринте.
ggo
24.09.2018 14:57Понимаете, вы уже сейчас делите: «вот бизнес, а вот мы, ит». В скраме нет деления бизнес/ит. Есть только команда, которая отвечает за продукт. Когда это выполняется, начинается скрам. Все остальное — дейли, ретро, сторипойнты и т.д. — это лишь атрибуты, которые могут иметь ту или иную форму.
Очевидно, что бы это (отсутствия деления на бизнес/ит) произошло в организации, у которой уже есть длинный бекграунд, нужны тектонические изменения на всех уровнях.staticlab
24.09.2018 15:40В скраме нет деления бизнес/ит. Есть только команда, которая отвечает за продукт.
Так есть же. Команда разработки отдельно, PO и SM — отдельно.
Hokum
24.09.2018 17:09PO, SM и Dev. T — все вместе скрам-команда. Это выделение ролей в процессе, но не разделение бизнес/не бизнес.
staticlab
24.09.2018 17:22+1Если PO не будет отражать текущие хотелки бизнеса в бэклоге, то команда будет делать совсем другой продукт, который бизнесу не нужен. Таким образом PO представляет продуктовые интересы бизнеса. Фактически PO и DT находятся в диалектическом противоречии. SM же здесь играет лишь вспомогательную роль.
usego
24.09.2018 19:24PO ответственен за правильный беклог. Он не навязывает стресс по его burnout. Это как раз роль SM. Но по факту PO и SM часто одно и то же лицо.
ggo
24.09.2018 20:00И все таки они команда.
А что у нас команда? Группа лиц объединенных одной целью.
В случае скрам-команды — объединенные целью создания и развития продукта.
В целом, я согласен, что настоящему итшнику крайне сложно разделять бизнес-ориентированные ценности, итшник стремится к построению идеального мира, где 1+1=2.
Но мир неидеален, и 1+1 не всегда =2.time2rfc
24.09.2018 21:07Простите но это ксенофобия, если я люблю и развиваться, и пробывать новые технологии но понимаю за что мне платят деньги — я не настоящий ITшник?
По вашему описанию получаеться, что настоящий Itшник это не приспособленный к внешнему миру человек. Возможно я вас не правильно понял, тогда извините.
UnhappyPanda
24.09.2018 12:01Так вот, главным документом по Скрам является «The Scrum Guide», написанный в соавторстве Кеном Швабером и Джеффом Сазерлендом, доступный на многих языках, включая русский.
На мой взгляд, для того, чтобы получить базовые знания по Скрам и, впоследствии не засорять своё сознание всевозможными неверно истолкованными дополнениями к Скрам, требуется всего два основных компонента: желание и вдумчивое прочтение «The Scrum Guide», причём не один раз.
Согласен, что это приходится читать не один раз. Но не потому, что это такая классная вещь, что её стоило бы перечитать, а потому что она ужасно написана, и понять её с первого раза решительно невозможно. Постоянные упоминания неразъясненных терминов с ссылкой на что-то впереди. Обычное описание практически чего угодно там выглядит так (цитатаиз первого же абзаца документа):
Это Руководство содержит описание Скрама, оно рассказывает о ролях, событиях, артефактах(2) и правилах фреймворка.
и сноска2 Подробнее об артефактах будет рассказано на стр.16
И так постоянно, чтобы целиком не заваливать цитатами вот просто сноски с первых пяти страниц:
2 Подробнее об артефактах будет рассказано на стр.16
6 Подробнее о Критериях Готовности будет рассказано на стр.19.
7 Подробнее о Цели Спринта будет рассказано на стр.13
8 Подробнее о Бэклоге Продукта будет рассказано на стр.16.
Это совершенно невозможно читать последовательно. Почему люди, которые учат других людей создавать качественный продукт, не могут создать качественный читаемый 25-страничный документ?
DikSoft
24.09.2018 12:14Потому что цели такой не ставилось. Завтра, типа, соберемся, обсудим и исправим.
vladimir123456
24.09.2018 12:42SCRUM по сути, если отбросить словесную шелуху, это элементарный micro management обёрнутый в набор ритуалов. Лучший ли это способ разрабатывать программное обспечение?
mSnus
24.09.2018 12:53Интересно было бы почитать отклики компаний, ОТКАЗАВШИХСЯ от Скрам. Что-то вроде «мы отказались от Скрам и повысили эффективность на 20%!» Или «вместо того, чтобы вкладываться в Скрам, мы вложились в повышение комфорта разработчиков, и теперь люди бегут не о нас, а к нам»… ))
vladimir123456
24.09.2018 13:38Гибкая разработка и SCRUM не синонимы.
SCRUM паразитирует на понятии гибкой разработки.
time2rfc
24.09.2018 14:01Спасибо всем кто потратит немного времени и в 2-3-4 предложениях напишет какая модель управления в их компании работает лучше чем scrum и почему.
solver
24.09.2018 16:23time2rfc
24.09.2018 16:42Спасибо, надеюсь еще парочку историй найду.
p.s.
Очень интересное видео про менеджеров и техлидов, отчеты которые пишут менеджеры команды не отвечающие за свой продукт итд.vladimir123456
24.09.2018 19:56Напоминает басню Крылова «Квартет» — тут надо архитектуру продукта лечить, а не программистов пересаживать.
Praporshik_Zadov
24.09.2018 18:14Судя по живости обсуждения Scrum на хабре становится таким же популярным, как и новости про криптовалюты.
ilitaexperta
24.09.2018 18:29Очередное
Это не Scrum плохой, просто у вас его неправильно реализовали
Я знаю как делать правильный Scrum, пока конечно же не сделал, но я двигаюсь к этому!
Нет никакого четкого определения что такое Scrum, существует только куча разных толкований от Scrum-евагелистов.
Scrum это очередная бизнес-религия, созданная для того, чтобы такие сертифицированные балаболы как автор статьи могли паразитировать на бизнесе и балаболить за зарплату, по факту занимаясь пинанием всех известных органовtime2rfc
24.09.2018 18:39Поделитесь, пожалуйста, историями успеха — что работает и как правильно выбрать метадологию\процесс людям в начале пути?
vladimir123456
24.09.2018 20:20Следуйте правилу: неправильная архитектура продукта не лечится правильной методологией.
eugene_bb
24.09.2018 20:48+1Лично мне нравится аджайл и считаю что для большинства проектов (не для всех) он приносит больше пользы, чем вреда (для конечного результата, а не для конкретного работника).
По моему наблюдению, чем слабее менеджмент (PO/PM/team lead/tech lead) и сильнее команда, тем больше выгоды. Если же менеджмент сильный, то всё случится не зависимо от методологии и команда будет подобрана сильная и сроки соблюдаться. Ну а если и команда и менеджмент так себе, то как было сказано выше, «как не садитесь, а в музыканты не годитесь».
Но daily meeting и т.п. ритуалы из скрама, конечно могут принести больше вреда чем пользы.
У нас например самый никчёмный программист был звездой daily meeting, он так рассказывал про успехи и борьбу с проблемами, что становилось завидно какой интересной жизнью человек живёт. А самый умный, наоборот, не блистал на митингах. Все конечно понимали что к чему, но мораль страдала.
А когда пригласили на митинг по поводу увольнения того умного программиста, я чуть не прифигел. Оказывается VP который иногда участвовал в подобных daily meeting-ах, составил себе собственное мнение.
А статья (как и многие другие) и особенно комментарии автора, являются антирекламой методологии.
vladimir123456
24.09.2018 22:39Без daily meeting это уже извините не SCRUM.
А кто сказал что для SCRUM нужны умные программисты?
Нужны заменяемые с предсказуемой продуктивностью (пусть и небольшой).
V-core
25.09.2018 10:14Неудачи, постигающие внедренцев Скрам, на мой взгляд, базируются на неготовности организации принять этот процесс ввиду общего не высокого уровня зрелости процессов управления.
В то время, когда внутри организации, в принципе не воспитана зрелость управления хотя бы проектами, попытки внедрять гибкие методологии, требующие на порядок иной зрелости приводят к тому самому карго-культу.
demet
26.09.2018 10:20Не раз встречаюсь с мнением, что при слабом руководстве вырастает сильная команда если внутри есть тимлид.
Здесь писали в коментах, что часто именно слабое руководство хотят заменить методологией, и первое что гуглиться Agile и Scrum, ну и потом коучи с процентами эффективности приходят.
И внедряют, по итогу руководство как было слабое так и осталось, а команда не готова с Scrum, вывод — Scrum/Agile не работают. Начинается поиск косяков метолодогии.
Имхо внедрять нужно на уровне тимлида и при слабом руководстве этого тимлида выделить.
Любая методология это инструмент и не более, не палочка-выручалочка, сначала голова потом Scrum (Mozg).
fcoder
«Вбросить» допустим получилось. Но ясности не внесло. Очень не хватает определений «цели спринта», роли скрам-мастера и PO. Потому что без них некоторые Ваши утверждения весьма и весьма спорные. Например, СМ по ванильному определению — facilitator. Обслуживать коммуникацию — это его ключевая обязанность. А это значит в том числе «забивать встречи в календаре» и соблюдать их регламент в рамках процесса.