В последние годы внедрение agile-методологий в разработку ПО стало целой индустрией: по этой теме выпускается специальная литература, собираются тематические конференции, устраиваются тренинги. На рынке труда возникли совершенно новые профессии, такие как agile-коуч или скрам-мастер. Появились целые компании, которые специализируются на внедрении гибких методологий в других компаниях.
В таких условиях кажется совершенно логичным заказать внешний консалтинг и «призвать» в свою компанию профессионального скрам-мастера на несколько месяцев. И это идеальный случай, просто мечта.
В реальной жизни чаще по-другому: команда разработки давно устала от хаотично поступающих со стороны менеджмента задач, а менеджмент страдает от непрозрачности разработки, постоянных срывов сроков и низкого качества продукта. При этом высшее руководство слышать не хочет о выделении бюджета на услуги профессиональных скрам-мастеров.
В таких условиях у разработчика есть два пути: продолжать терпеть или брать инициативу в свои руки.
Я выбрал второе и сегодня расскажу об опыте внедрения скрама в компании будучи не менеджером, а техническим специалистом. Под катом реальный опыт, подводные камни и практические советы тем кто отважился.
Первое и основное: внедрение скрама разработчиком — это тяжелая и неблагодарная инициатива. Чтобы на такое решиться, у вас, как у разработчика должны быть действительно веские причины.
Вот несколько формальных признаков, свидетельствующих о том, что с процессом разработки в вашей команде что-то не то:
Все эти моменты напрямую влияют на ваш комфорт как разработчика. Если в списке выше вы отметили для себя более половины пунктов, то, возможно, вам стоит задуматься о том чтобы внедрить скрам в своей команде, потому что он реально позволяет их решить.
Если же пункты сверху вызывают у вас недоумение, а идея внедрения скрама пришла вам в результате:
то, скорее всего, вам не нужно за это браться. Просто наслаждайтесь своей работой и похвалите тех менеджеров, которые обеспечивают вам такие условия труда.
В совершенстве изучите теорию Scrum'a. Это архиважно. Я рекомендую книгу Хенрика Книберга "Scrum и XP: заметки с передовой": это очень известная Scrum-методичка которая пошагово разжевывает все моменты процесса. После её прочтения вы поймете, почему стендапы должны проводиться непременно стоя и в одно и то же время, почему нельзя забивать на демо, почему нужно оценивать задачи именно Planning Poker'ом, а не в открытую. Появится понимание как это всё связано.
Если у вас всё ещё остаются вопросы о целесообразности тех или иных практик Scrum'a — прочитайте книжку ещё раз. Если вопросы по-прежнему остаются — возможно вам не стоит браться за внедрение Scrum'a.
Найдите себе соратников среди разработчиков. Расскажите за обедом какие плюсы они получат после внедрения этого процесса. Не забудьте сказать и про обязательства, накладываемые скрамом на разработчиков.
Большинство людей готовы поддерживать благие начинания. Может найтись кто-то, кто скажет что против изменений — это нормально. Но если вы единственный в команде, кто считает что текущий процесс некомфортен для разработчиков — возможно вам не стоит браться за внедрение Scrum'a в этой команде.
Найдите соратников среди руководства. Чем более высокому руководителю вы об этом расскажите, тем выше шансы на успех.
Начните с руководителя вашего подразделения. Двигайтесь выше. В небольших компаниях(до 50 человек) я предпочитаю идти вплоть до директора. Сделайте получасовую презентацию с описанием текущего процесса и его проблем. Опишите как скрам их решает.
Большинство менеджеров должно воспринять вашу инициативу нейтрально. Но хотя бы один руководитель должен встать на вашу сторону и пообещать поддержку. Запомните этого человека, он вам о-о-очень пригодится в будущем.
Если вам не удалось привлечь на свою сторону ни одного руководителя — вам точно не стоит браться за внедрение Scrum'a в этой компании.
Явно озвучьте руководству, что скрам-мастеринг требует вашего времени и, соответственно, ваша эффективность как технаря снизится процентов на 30%. Если предыдущий шаг пройден успешно, то это воспримут адекватно. И не спешите на этом этапе просить прибавку к зарплате, вы ещё ничего не сделали, за что вам стоит платить больше.
Посмотрите ещё раз на проделанную работу. Вот на все эти разговоры, споры и выступления. Если это вам показалась сложным и это не то, чем вы хотели бы заниматься в ближайшие 6-9 месяцев — вам не стоит браться за внедрение Scrum. Потому что внедрение Scrum — это работа с людьми. Она будет отнимать у вас прилично времени и душевных сил. Первое время вам точно придется совмещать её с вашей основной, технической, деятельностью.
Это точка невозврата. Вы ещё не сломали устоявшиеся процессы. Вы ещё можете отказаться. Дальше у вас такой возможности не будет. Если вы пойдете дальше и откажитесь, то сделаете только хуже: оставите коллег со сломанным процессом, не дав ничего взамен. Таких людей все ненавидят.
Совместно с руководством выберите проект, на котором вы сформируете Scrum-команду. Идеальная команда — 4-6 кроссфункциональных разработчика. Так почти никогда не бывает, разработчики имеют свою специализацию и не хотят заниматься тестированием. Поэтому 3-4 некроссфункциональных разработчика и 1-2 тестировщика — тоже очень хорошая команда. Вы должны быть одним из этих ребят. А ещё вы теперь скрам-мастер.
Ни в коем случае не соглашайтесь на внедрение Scrum'а сразу во всей компании или в команде, в которую вы не входите — потеряете контроль.
Важный момент: добейтесь от руководства официального уведомления команды, что работа теперь ведется по скраму, а вы — скрам-мастер.
Профессиональные скрам-мастера приходят в команду с целым портфелем сервисов и плагинов, позволяющих отслеживать скрам-активность в online-трекерах. Это не ваша специализация, поэтому не заморачивайтесь на сложном инструментарии.
Напротив, используйте аналоговые инструменты: оффлайновую доску с рукописными стикерами, листки ретроспективы приколотые к ней же, burndown нарисованный маркером на соседней доске. На этапе становления скрама такие вещи даже более наглядны, чем их онлайн аналоги.
Дальнейшие шаги — это формирование бэклога, первое планирование, стендапы, демо, ретро… Здесь нет каких-то особенностей для скрам-мастера технаря, действуйте по книжке.
Но на одном я хочу остановиться подробнее: скрам-мастер — это менеджер. Теперь у вас есть определенные рычаги влияния на команду и даже на человека, который является product owner'ом в вашей команде. И вы должны(!) пользоваться этими рычагами.
Объясню на примерах.
Product owner'ом в вашей команде стал менеджер, который раньше ставил вам задачи. Теперь вы, как скрам-мастер, ставите ему задачи: поддерживать бэклог в приоритезированном состоянии, правильно формировать User Story и не докидывать в текущий спринт новых задач.
Пусть в иерархии компании этот человек стоит выше вас, рядового разработчика, но в парадигме скрама вы можете, и должны, следить чтобы этот человек выполнял свои обязанности по отношению к команде.
Вы C++ девелопер, а он — техлид C++ который ставил вам задачи до внедрения скрама. Вы оказались в одной скрам-команде. И на одном из стендапов этот техлид заявляет, что он занимается задачей с низким приоритетом, хотя по доске видно, что есть задачи и поважнее в спринте. Согласно правилам, вы должны попросить его переключиться на более приоритетную задачу. Обычно этого хватает. Но иногда это вызывает негодование у техлида: «Как это так, мой подчиненный говорит мне чем заниматься!» Нужно обладать талантом дипломатии чтобы разговаривать с позиции начальника со своим начальником. Но если вы смалодушничаете в этот момент, команда моментально почувствует нарушение правил, а значит у других членов команды появится соблазн нарушить ещё какое-нибудь правило.
Очень часто именно этот момент оказывается самым сложным для скрам-мастера технаря. Я рекомендую в такие моменты апеллировать к интересам команды и product owner'a: мало кто захочет идти против своей команды или менеджера. Эскалацию таких проблем до вышестоящего руководства используйте в самых крайних случаях.
В начале производительность команды может упасть, это нормально когда меняется процесс разработки.
Но уже через 2-3 спринта вы и другие разработчики почувствуете плюсы скрама: задачи не влетают хаотичным образом, появилась двухнедельная определенность, вся команда погружена в решение общих задач, тестирование происходит сразу после разработки.
У product owner'а появится понимание чем занята разработка и некоторая уверенность что большинство запланированных задач будет выполнено к концу спринта. Не забывайте подсвечивать это на ретро: технари склонны сгущать краски и озвучивать только проблемы.
Если у вас в команде всё хорошо, может возникнуть соблазн транслировать опыт на другие команды. Не торопитесь с этим.
Во-первых, дождитесь когда другие команды сами попросят вас внедрить у них скрам.
Во-вторых, подготовьте себе замену в первой команде и только после этого беритесь за налаживание скрама во второй. И да, вам придется перейти в эту вторую команду не только как скрам-мастер, но и как разработчик.
Будьте готовы к тому, что теперь все вопросы касательно процессов разработки в компании будут адресованы к вам и на их сопровождение придется тратить время.
Важный момент: на этом этапе, когда уже видны результаты внедрения скрама, поговорите с руководством о доплате за скрам-мастеринг. Попросить +15% к своему окладу — нормально. Объясните, что эта активность требует сил и нервов и на одном энтузиазме долго не протянуть. И это действительно так! Я видел немало скрам-мастеров технарей, чистый энтузиазм которых сменялся обидой за неоплачиваемый тяжелый труд. В итоге компания теряла и скрам-мастера и разработчика.
Это может показаться странным, но чем дольше у вас в команде комфортный процесс, тем больше недовольств поступает в ваш адрес. Так устроена человеческая психика: к хорошему мы привыкаем очень быстро и перестаем его замечать, а негатив склонны раздувать.
Через какое-то время вы услышите от членов команды, что скрам не так-то уж и хорош. Что, дескать, приходится укладываться в спринты и ходить на стендапы, что мы слишком много времени тратим на разговоры. Особенно этим грешат молодые разработчики, присоединившиеся уже после внедрения скрама и не видевшие как было раньше.
Это нормально. Просто заготовьте немного картинок с описанием как было раньше и показывайте их время от времени недовольным. Иногда к таким разговорам привлекайте product owner'а, потому что он как старший товарищ у походного костра: его рассказы о былых временах воспринимаются командой очень живо.
Вообще, менеджеры недовольны скрамом в самом начале внедрения, когда впервые сталкиваются с запретом на внесение новых задач в текущий спринт. Но уже после первого демо понимают, что преимущества процесса перевешивают это ограничение. Через несколько месяцев менеджер станет главным ценителем скрама.
Повторюсь, технари из команды частенько раздувают негатив, а менеджеры видят картинку более реалистично. Поэтому, если вы чувствуете что критиканы вас заклевали — выпейте кофе с вашим product owner'ом, он обязательно поддержит, а поддержка в такие моменты очень важна.
Но критика бывает и конструктивной. Идеально настроить скрам с нуля невозможно, поэтому постоянно прислушивайтесь к советам и примеряйте их на ваш процесс. Каждое предлагаемое изменение встречайте двумя вопросами: «Какую проблему это решит?» и «Какие проблемы это породит?»
Критично ли сдвинуть время стендапа с 10 утра на 18 вечера? Или сделать время стендапа плавающим? Что если отменить демо? Или придумать новый тип встречи?
В этом плане Scrum очень похож на программный фреймворк: вы можете вносить в него изменения, но толк от них будет только если вы понимаете цель своих изменений.
Вы должны четко осознавать как это изменение повлияет на процесс и какие дополнительные действия от вас потребует, чтобы сохранить консистентность.
Здесь нет универсального совета, но старайтесь вносить изменения в ваш процесс постепенно и не забывайте оценивать их как разработчик. Если изменение не удовлетворяет задумке, то смело откатывайте его назад.
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама. Ещё раз повторю — это активность которая ни при каких условиях не может считаться «фоновой», это вполне себе челлендж.
Надеюсь, теперь кто-то сможет лучше подготовиться к нему. А кто-то поймет что не стоит оно того и не сломает окончательно хоть как-то работающие процессы компании.
Появились вопросы или есть свой опыт? Welcome в комментарии!
В таких условиях кажется совершенно логичным заказать внешний консалтинг и «призвать» в свою компанию профессионального скрам-мастера на несколько месяцев. И это идеальный случай, просто мечта.
В реальной жизни чаще по-другому: команда разработки давно устала от хаотично поступающих со стороны менеджмента задач, а менеджмент страдает от непрозрачности разработки, постоянных срывов сроков и низкого качества продукта. При этом высшее руководство слышать не хочет о выделении бюджета на услуги профессиональных скрам-мастеров.
В таких условиях у разработчика есть два пути: продолжать терпеть или брать инициативу в свои руки.
Я выбрал второе и сегодня расскажу об опыте внедрения скрама в компании будучи не менеджером, а техническим специалистом. Под катом реальный опыт, подводные камни и практические советы тем кто отважился.
Предпосылки
Первое и основное: внедрение скрама разработчиком — это тяжелая и неблагодарная инициатива. Чтобы на такое решиться, у вас, как у разработчика должны быть действительно веские причины.
Вот несколько формальных признаков, свидетельствующих о том, что с процессом разработки в вашей команде что-то не то:
- разработчика постоянно дергают и переключают с задачи на задачу;
- задачи к разработчику поступают неравномерно, то совсем ничего нет, то завал;
- разработчики получают разрозненные задачи и не видят продукт целиком;
- собирая воедино задачи от разных разработчиков получается продукт, который работает не так как предполагалось;
- тестирование продукта оторвано от разработки, что порождает долгий цикл стабилизации продукта;
- сроки всегда горят.
Все эти моменты напрямую влияют на ваш комфорт как разработчика. Если в списке выше вы отметили для себя более половины пунктов, то, возможно, вам стоит задуматься о том чтобы внедрить скрам в своей команде, потому что он реально позволяет их решить.
Если же пункты сверху вызывают у вас недоумение, а идея внедрения скрама пришла вам в результате:
- дискуссии с приятелем из другой компании в баре;
- желания попробовать «что-нибудь новенькое»;
- скуки;
- ...
то, скорее всего, вам не нужно за это браться. Просто наслаждайтесь своей работой и похвалите тех менеджеров, которые обеспечивают вам такие условия труда.
Этап 1. Подготовка
В совершенстве изучите теорию Scrum'a. Это архиважно. Я рекомендую книгу Хенрика Книберга "Scrum и XP: заметки с передовой": это очень известная Scrum-методичка которая пошагово разжевывает все моменты процесса. После её прочтения вы поймете, почему стендапы должны проводиться непременно стоя и в одно и то же время, почему нельзя забивать на демо, почему нужно оценивать задачи именно Planning Poker'ом, а не в открытую. Появится понимание как это всё связано.
Если у вас всё ещё остаются вопросы о целесообразности тех или иных практик Scrum'a — прочитайте книжку ещё раз. Если вопросы по-прежнему остаются — возможно вам не стоит браться за внедрение Scrum'a.
Найдите себе соратников среди разработчиков. Расскажите за обедом какие плюсы они получат после внедрения этого процесса. Не забудьте сказать и про обязательства, накладываемые скрамом на разработчиков.
Большинство людей готовы поддерживать благие начинания. Может найтись кто-то, кто скажет что против изменений — это нормально. Но если вы единственный в команде, кто считает что текущий процесс некомфортен для разработчиков — возможно вам не стоит браться за внедрение Scrum'a в этой команде.
Найдите соратников среди руководства. Чем более высокому руководителю вы об этом расскажите, тем выше шансы на успех.
Начните с руководителя вашего подразделения. Двигайтесь выше. В небольших компаниях(до 50 человек) я предпочитаю идти вплоть до директора. Сделайте получасовую презентацию с описанием текущего процесса и его проблем. Опишите как скрам их решает.
Большинство менеджеров должно воспринять вашу инициативу нейтрально. Но хотя бы один руководитель должен встать на вашу сторону и пообещать поддержку. Запомните этого человека, он вам о-о-очень пригодится в будущем.
Если вам не удалось привлечь на свою сторону ни одного руководителя — вам точно не стоит браться за внедрение Scrum'a в этой компании.
Явно озвучьте руководству, что скрам-мастеринг требует вашего времени и, соответственно, ваша эффективность как технаря снизится процентов на 30%. Если предыдущий шаг пройден успешно, то это воспримут адекватно. И не спешите на этом этапе просить прибавку к зарплате, вы ещё ничего не сделали, за что вам стоит платить больше.
Посмотрите ещё раз на проделанную работу. Вот на все эти разговоры, споры и выступления. Если это вам показалась сложным и это не то, чем вы хотели бы заниматься в ближайшие 6-9 месяцев — вам не стоит браться за внедрение Scrum. Потому что внедрение Scrum — это работа с людьми. Она будет отнимать у вас прилично времени и душевных сил. Первое время вам точно придется совмещать её с вашей основной, технической, деятельностью.
Это точка невозврата. Вы ещё не сломали устоявшиеся процессы. Вы ещё можете отказаться. Дальше у вас такой возможности не будет. Если вы пойдете дальше и откажитесь, то сделаете только хуже: оставите коллег со сломанным процессом, не дав ничего взамен. Таких людей все ненавидят.
Этап 2. Внедрение
Совместно с руководством выберите проект, на котором вы сформируете Scrum-команду. Идеальная команда — 4-6 кроссфункциональных разработчика. Так почти никогда не бывает, разработчики имеют свою специализацию и не хотят заниматься тестированием. Поэтому 3-4 некроссфункциональных разработчика и 1-2 тестировщика — тоже очень хорошая команда. Вы должны быть одним из этих ребят. А ещё вы теперь скрам-мастер.
Ни в коем случае не соглашайтесь на внедрение Scrum'а сразу во всей компании или в команде, в которую вы не входите — потеряете контроль.
Важный момент: добейтесь от руководства официального уведомления команды, что работа теперь ведется по скраму, а вы — скрам-мастер.
Профессиональные скрам-мастера приходят в команду с целым портфелем сервисов и плагинов, позволяющих отслеживать скрам-активность в online-трекерах. Это не ваша специализация, поэтому не заморачивайтесь на сложном инструментарии.
Напротив, используйте аналоговые инструменты: оффлайновую доску с рукописными стикерами, листки ретроспективы приколотые к ней же, burndown нарисованный маркером на соседней доске. На этапе становления скрама такие вещи даже более наглядны, чем их онлайн аналоги.
Дальнейшие шаги — это формирование бэклога, первое планирование, стендапы, демо, ретро… Здесь нет каких-то особенностей для скрам-мастера технаря, действуйте по книжке.
Но на одном я хочу остановиться подробнее: скрам-мастер — это менеджер. Теперь у вас есть определенные рычаги влияния на команду и даже на человека, который является product owner'ом в вашей команде. И вы должны(!) пользоваться этими рычагами.
Объясню на примерах.
Пример 1
Product owner'ом в вашей команде стал менеджер, который раньше ставил вам задачи. Теперь вы, как скрам-мастер, ставите ему задачи: поддерживать бэклог в приоритезированном состоянии, правильно формировать User Story и не докидывать в текущий спринт новых задач.
Пусть в иерархии компании этот человек стоит выше вас, рядового разработчика, но в парадигме скрама вы можете, и должны, следить чтобы этот человек выполнял свои обязанности по отношению к команде.
Пример 2
Вы C++ девелопер, а он — техлид C++ который ставил вам задачи до внедрения скрама. Вы оказались в одной скрам-команде. И на одном из стендапов этот техлид заявляет, что он занимается задачей с низким приоритетом, хотя по доске видно, что есть задачи и поважнее в спринте. Согласно правилам, вы должны попросить его переключиться на более приоритетную задачу. Обычно этого хватает. Но иногда это вызывает негодование у техлида: «Как это так, мой подчиненный говорит мне чем заниматься!» Нужно обладать талантом дипломатии чтобы разговаривать с позиции начальника со своим начальником. Но если вы смалодушничаете в этот момент, команда моментально почувствует нарушение правил, а значит у других членов команды появится соблазн нарушить ещё какое-нибудь правило.
Очень часто именно этот момент оказывается самым сложным для скрам-мастера технаря. Я рекомендую в такие моменты апеллировать к интересам команды и product owner'a: мало кто захочет идти против своей команды или менеджера. Эскалацию таких проблем до вышестоящего руководства используйте в самых крайних случаях.
Этап 3. Развитие
В начале производительность команды может упасть, это нормально когда меняется процесс разработки.
Но уже через 2-3 спринта вы и другие разработчики почувствуете плюсы скрама: задачи не влетают хаотичным образом, появилась двухнедельная определенность, вся команда погружена в решение общих задач, тестирование происходит сразу после разработки.
У product owner'а появится понимание чем занята разработка и некоторая уверенность что большинство запланированных задач будет выполнено к концу спринта. Не забывайте подсвечивать это на ретро: технари склонны сгущать краски и озвучивать только проблемы.
Если у вас в команде всё хорошо, может возникнуть соблазн транслировать опыт на другие команды. Не торопитесь с этим.
Во-первых, дождитесь когда другие команды сами попросят вас внедрить у них скрам.
Во-вторых, подготовьте себе замену в первой команде и только после этого беритесь за налаживание скрама во второй. И да, вам придется перейти в эту вторую команду не только как скрам-мастер, но и как разработчик.
Будьте готовы к тому, что теперь все вопросы касательно процессов разработки в компании будут адресованы к вам и на их сопровождение придется тратить время.
Важный момент: на этом этапе, когда уже видны результаты внедрения скрама, поговорите с руководством о доплате за скрам-мастеринг. Попросить +15% к своему окладу — нормально. Объясните, что эта активность требует сил и нервов и на одном энтузиазме долго не протянуть. И это действительно так! Я видел немало скрам-мастеров технарей, чистый энтузиазм которых сменялся обидой за неоплачиваемый тяжелый труд. В итоге компания теряла и скрам-мастера и разработчика.
Этап 4. Критика
Это может показаться странным, но чем дольше у вас в команде комфортный процесс, тем больше недовольств поступает в ваш адрес. Так устроена человеческая психика: к хорошему мы привыкаем очень быстро и перестаем его замечать, а негатив склонны раздувать.
Через какое-то время вы услышите от членов команды, что скрам не так-то уж и хорош. Что, дескать, приходится укладываться в спринты и ходить на стендапы, что мы слишком много времени тратим на разговоры. Особенно этим грешат молодые разработчики, присоединившиеся уже после внедрения скрама и не видевшие как было раньше.
Это нормально. Просто заготовьте немного картинок с описанием как было раньше и показывайте их время от времени недовольным. Иногда к таким разговорам привлекайте product owner'а, потому что он как старший товарищ у походного костра: его рассказы о былых временах воспринимаются командой очень живо.
Вообще, менеджеры недовольны скрамом в самом начале внедрения, когда впервые сталкиваются с запретом на внесение новых задач в текущий спринт. Но уже после первого демо понимают, что преимущества процесса перевешивают это ограничение. Через несколько месяцев менеджер станет главным ценителем скрама.
Повторюсь, технари из команды частенько раздувают негатив, а менеджеры видят картинку более реалистично. Поэтому, если вы чувствуете что критиканы вас заклевали — выпейте кофе с вашим product owner'ом, он обязательно поддержит, а поддержка в такие моменты очень важна.
Но критика бывает и конструктивной. Идеально настроить скрам с нуля невозможно, поэтому постоянно прислушивайтесь к советам и примеряйте их на ваш процесс. Каждое предлагаемое изменение встречайте двумя вопросами: «Какую проблему это решит?» и «Какие проблемы это породит?»
Критично ли сдвинуть время стендапа с 10 утра на 18 вечера? Или сделать время стендапа плавающим? Что если отменить демо? Или придумать новый тип встречи?
В этом плане Scrum очень похож на программный фреймворк: вы можете вносить в него изменения, но толк от них будет только если вы понимаете цель своих изменений.
Вы должны четко осознавать как это изменение повлияет на процесс и какие дополнительные действия от вас потребует, чтобы сохранить консистентность.
Здесь нет универсального совета, но старайтесь вносить изменения в ваш процесс постепенно и не забывайте оценивать их как разработчик. Если изменение не удовлетворяет задумке, то смело откатывайте его назад.
Заключение
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама. Ещё раз повторю — это активность которая ни при каких условиях не может считаться «фоновой», это вполне себе челлендж.
Надеюсь, теперь кто-то сможет лучше подготовиться к нему. А кто-то поймет что не стоит оно того и не сломает окончательно хоть как-то работающие процессы компании.
Появились вопросы или есть свой опыт? Welcome в комментарии!
Комментарии (11)
DexterHD
25.01.2018 18:47Предлагаю сходу не слушать Scrum консультантов и прочих паразитирующих на профессии людей :) а для начала посмотреть всего лишь одно выступление одного из людей который стоял у истоков Agile и связанных с ним практик. После него уже можно покупать книги и зарываться в это дело с головой. Этого выступления целиком и полностью будет достаточно для разработчика, чтобы понять зачем это все, откуда пришло, куда движется, какие проблемы решает и как с этим жить. Выступление длинное и не целиком посвящено Agile, но рекомендую не мотать и прослушать от начала до конца, уверяю, вы откроете для себя много чего интересного:
www.youtube.com/watch?v=ecIWPzGEbFc («Uncle» Bob Martin — «The Future of Programming»)
Автору же статьи огромный плюс за старания. Сам сейчас решаю такую же проблему. И это не так легко как рисуют всякие коучи.
RationalBot
25.01.2018 22:18Предлагаю сходу не слушать Scrum консультантов и прочих паразитирующих на профессии людей
На всякий случай, я не отношусь к консультантам, но понимаю, как они позволяют экономить время и деньги, избегая «детских» ошибок и разочарования (конечно, речь идет о достойных).
Если Ваша компания готова спонсировать эксперименты по внедрению Скрама своими силами (или любые другие) — отлично!
Много знаете спортсменов-профессионалов, которые обходятся без тренера? А любители вполне себе могут.
P.S.
Видео и в самом деле интересное, спасибо за ссылку.DexterHD
26.01.2018 00:04Я не пытался ни кого задеть или оскорбить. Тем более лично. Так что если вы восприняли это на свой счет, прошу прощения. Я лишь хотел сказать что из Agile сделали нехилый бизнес, с целью заработка денег а не налаживания процессов. Бессмысленный и беспощадный.
Как итог часть людей забыли, что эти методики создали программисты для программистов. Часть об этом не знают до сих пор и постоянно наступают на одни и те жа грабли, меняя коучей и консультантов но так и не добиваясь успеха.
Кстати зачастую именно команда может быть не готова к Agile. Квалификация разработчиков не позволяет просто на просто. И тут ни какой коуч не поможет. К слову с такими командами только нормально настроенная Waterfall модель позволяет делать хоть какое то ПО.
А еще бывает к Agile не готов менеджмент и заказчики, в таком случае опять таки ни какой коуч не поможет, если конечно он не облает безграничным даром убеждения и неимоверной харизмой, а так же готов гарантировать успех рублем.
ajankovsky
26.01.2018 17:07Являюсь руководителем группы разработки ПО в одной «закрытой» компании.
К Scrum и Agile пришел еще в году так 2011, но получается, что наступил на грабли. В моей группе единомышленников не оказалось или почти не оказалось. Полгода пободавшись с коллегами, чётко для себя уяснил, что если не привязать ту же диаграмму сгорания к конечной з/п, то хоть объясняй, хоть нет, но при отсутствии энтузиазма со стороны конкретных разработчиков (именно энтузиазма в части тратить свое время на обязательные техпроцессы по Scrum и Agile) двигаться вперед по этим технологиям невозможно… Сам пришел к выводу, что требовать работать по технологии могу, но это в каком-то роде не правомочно, а при отсутствии «горящих глаз» продолжать не было смысла.
Бесконечно сожалею об этом, но поделать ничего не в силах.
Glazz87 Автор
28.01.2018 23:45Самых большая ошибка — пытаться натянуть скрам там, где он не нужен. «Закрытая» компания на гос. заказе? Монопольная отрасль? Не рыночные отношения с заказчиком? Скрам такому бизнесу больше навредит.
А уж привязывать берндаун к запрплате — это верный способ замотивировать команду на обман, но никак не на эффективность.
RationalBot
Признаться, я не по почувствовал, что это личный опыт — больше похоже на конспект книги или тренинга.
Это какой-то тиражируемый опыт внедрения Скрама в разных компаниях? И каждый раз мы приходим как технарь? При наличии компетенций, знаний и практического опыта внедрения скрама?
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
Скрам-мастер — это лидер, а не менеджер. И рычагами влияния он должен пользоваться как лидер.
Да ладно? Вот так прямо скрам-мастер начал распределять задачи в команде?
Да, и если уж вы решили внедрять скрам самостоятельно, в дополнение к чтению книг и просмотру курсов:
Glazz87 Автор
Да, это личный опыт. Внедрял скрам как технарь в двух компаниях. В первой наделал много ошибок, потом исправлял, набил шишки. Во второй, где работаю по сей день, внедрил скрам вполне успешно, уже более трех лет несколько команд работает.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Лидер и скрам-мастер понятия не взаимоисключающие, непонятно почему вы так отреагировали. И уж тем более непонятно ваше удивление, что скрам-мастер следит за тем, чтобы задачи в спринте выполнялись в порядке их проритета. Приоритет, если что, определяет product owner.
По поводу scrum.org, «примите его буквально» и про чеклист. Это всё хорошо до первого внедрения. Все команды разные и vanilla-scrum заходит не у всех. Точнее, почти ни у кого не заходит, особенно если вы не Асхат Уразбаев, а простой разработчик.
Вы просто обязаны учитывать эти детали если хотите внедрить процесс, а не остаться наедине со своим чек-листом.
RationalBot
Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать. С моей точки зрения, было бы гораздо интереснее и полезнее.
Можно ссылочку на такого рода исследования?
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.
У меня нет оснований сомневаться, что Вы успешно внедрили скрам в своей компании.
Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики. Вероятно, у них тоже не зашел vanilla-scrum… Но наверняка есть все ритуалы, чтобы считать скрам внедренным.
myrkoxx
это конечно хорошо, но не всегда компания продуктовая. В out-source/out-stuff Project Manager может никак не влиять на видение продукта. И в таких проектах запросто может не быть отдельного Product Owner`а. Да и в продуктовой компании порою нету ни PO ни BA (как правило в мелких по размеру компаниях). В таких случаях, как раз возможно принятие роли PO каким-то PM`ом так как скорее всего именно он общаеться с клиентом/маркетом/бизнесом. В етом нет ничего плохого.
Glazz87 Автор
Смысл моего ответа в том, что этот человек уже есть в компании на момент внедрения скрама. Не важно какая у него должность в трудовой, хоть генеральный директор. В реальности нужно чтобы этот человек отвечал за продукт, грамотно формулировал User Story и выполнял другие обязанности по отношению к команде. Если он видит продукт не так, как хочет заказчик — процесс это вскроет большим количеством переделок на следующих спринтах.
Распространенная ошибка, да. Практически все скрам-мастера самоучки через это прошли. Прямо нарушается принцип, что команда должна быть способной выдавать законченный business value.
Статей таких тысячи, полезность их примерно как у книги «Мой опыт воспитания ребенка», повторяться не хотелось. Не зря Scrum предпочитают называть framework'ом, а не методологией: принципы одни, а тонкий тюнинг у всех свой.
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама.
RationalBot
Отлично, если Вы ее достигли (с точки зрения читателей).
Я просто обозначил свой интерес и обратил внимание на пару моментов:
1. Ваша интерпретация Скрама отличается от канонической версии (которая изложена в Скрам Гайде). Это включает понимание ролей и взаимодействия между ними в Скрам-команде.
2. Большое внимание уделено тому, как «продать» Скрам менеджменту, но очень мало внимание уделяется команде (только про преодоление сопротивления). Если проблемы, обозначенные в начале, были решены, команда должна быть счастлива. Разве нет?