Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Признаться, я не по почувствовал, что это личный опыт — больше похоже на конспект книги или тренинга.
Это какой-то тиражируемый опыт внедрения Скрама в разных компаниях? И каждый раз мы приходим как технарь? При наличии компетенций, знаний и практического опыта внедрения скрама?
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
Скрам-мастер — это лидер, а не менеджер. И рычагами влияния он должен пользоваться как лидер.
Да ладно? Вот так прямо скрам-мастер начал распределять задачи в команде?
Да, и если уж вы решили внедрять скрам самостоятельно, в дополнение к чтению книг и просмотру курсов:
В небольших компаниях(до 50 человек) я предпочитаю идти вплоть до директора.
Это какой-то тиражируемый опыт внедрения Скрама в разных компаниях? И каждый раз мы приходим как технарь? При наличии компетенций, знаний и практического опыта внедрения скрама?
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
скрам-мастер — это менеджер
Скрам-мастер — это лидер, а не менеджер. И рычагами влияния он должен пользоваться как лидер.
И на одном из стендапов этот техлид заявляет, что он занимается задачей с низким приоритетом, хотя по доске видно, что есть задачи и поважнее в спринте. Согласно правилам, вы должны попросить его переключиться на более приоритетную задачу.
Да ладно? Вот так прямо скрам-мастер начал распределять задачи в команде?
Да, и если уж вы решили внедрять скрам самостоятельно, в дополнение к чтению книг и просмотру курсов:
- прочтите скрам-гайд на www.scrum.org
- примите его буквально
- как минимум, пройдите пробные экзамены на www.scrum.org (причем, для всех ролей!)
- убедитесь, что у вас есть нужные компетенции
- найдите чек-лист по внедрению скрама
Да, это личный опыт. Внедрял скрам как технарь в двух компаниях. В первой наделал много ошибок, потом исправлял, набил шишки. Во второй, где работаю по сей день, внедрил скрам вполне успешно, уже более трех лет несколько команд работает.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Лидер и скрам-мастер понятия не взаимоисключающие, непонятно почему вы так отреагировали. И уж тем более непонятно ваше удивление, что скрам-мастер следит за тем, чтобы задачи в спринте выполнялись в порядке их проритета. Приоритет, если что, определяет product owner.
По поводу scrum.org, «примите его буквально» и про чеклист. Это всё хорошо до первого внедрения. Все команды разные и vanilla-scrum заходит не у всех. Точнее, почти ни у кого не заходит, особенно если вы не Асхат Уразбаев, а простой разработчик.
Вы просто обязаны учитывать эти детали если хотите внедрить процесс, а не остаться наедине со своим чек-листом.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Лидер и скрам-мастер понятия не взаимоисключающие, непонятно почему вы так отреагировали. И уж тем более непонятно ваше удивление, что скрам-мастер следит за тем, чтобы задачи в спринте выполнялись в порядке их проритета. Приоритет, если что, определяет product owner.
По поводу scrum.org, «примите его буквально» и про чеклист. Это всё хорошо до первого внедрения. Все команды разные и vanilla-scrum заходит не у всех. Точнее, почти ни у кого не заходит, особенно если вы не Асхат Уразбаев, а простой разработчик.
Вы просто обязаны учитывать эти детали если хотите внедрить процесс, а не остаться наедине со своим чек-листом.
В первой наделал много ошибок, потом исправлял, набил шишки. Во второй, где работаю по сей день, внедрил скрам вполне успешно...
Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать. С моей точки зрения, было бы гораздо интереснее и полезнее.
Product Owner — это роль в скраме, которую часто берут на себя существующие проектные менеджеры.
Можно ссылочку на такого рода исследования?
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.
У меня нет оснований сомневаться, что Вы успешно внедрили скрам в своей компании.
Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики. Вероятно, у них тоже не зашел vanilla-scrum… Но наверняка есть все ритуалы, чтобы считать скрам внедренным.
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним
это конечно хорошо, но не всегда компания продуктовая. В out-source/out-stuff Project Manager может никак не влиять на видение продукта. И в таких проектах запросто может не быть отдельного Product Owner`а. Да и в продуктовой компании порою нету ни PO ни BA (как правило в мелких по размеру компаниях). В таких случаях, как раз возможно принятие роли PO каким-то PM`ом так как скорее всего именно он общаеться с клиентом/маркетом/бизнесом. В етом нет ничего плохого.
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?
Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.
Смысл моего ответа в том, что этот человек уже есть в компании на момент внедрения скрама. Не важно какая у него должность в трудовой, хоть генеральный директор. В реальности нужно чтобы этот человек отвечал за продукт, грамотно формулировал User Story и выполнял другие обязанности по отношению к команде. Если он видит продукт не так, как хочет заказчик — процесс это вскроет большим количеством переделок на следующих спринтах.
Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики
Распространенная ошибка, да. Практически все скрам-мастера самоучки через это прошли. Прямо нарушается принцип, что команда должна быть способной выдавать законченный business value.
Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать.
Статей таких тысячи, полезность их примерно как у книги «Мой опыт воспитания ребенка», повторяться не хотелось. Не зря Scrum предпочитают называть framework'ом, а не методологией: принципы одни, а тонкий тюнинг у всех свой.
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама.
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама.
Отлично, если Вы ее достигли (с точки зрения читателей).
Я просто обозначил свой интерес и обратил внимание на пару моментов:
1. Ваша интерпретация Скрама отличается от канонической версии (которая изложена в Скрам Гайде). Это включает понимание ролей и взаимодействия между ними в Скрам-команде.
2. Большое внимание уделено тому, как «продать» Скрам менеджменту, но очень мало внимание уделяется команде (только про преодоление сопротивления). Если проблемы, обозначенные в начале, были решены, команда должна быть счастлива. Разве нет?
Предлагаю сходу не слушать Scrum консультантов и прочих паразитирующих на профессии людей :) а для начала посмотреть всего лишь одно выступление одного из людей который стоял у истоков Agile и связанных с ним практик. После него уже можно покупать книги и зарываться в это дело с головой. Этого выступления целиком и полностью будет достаточно для разработчика, чтобы понять зачем это все, откуда пришло, куда движется, какие проблемы решает и как с этим жить. Выступление длинное и не целиком посвящено Agile, но рекомендую не мотать и прослушать от начала до конца, уверяю, вы откроете для себя много чего интересного:
www.youtube.com/watch?v=ecIWPzGEbFc («Uncle» Bob Martin — «The Future of Programming»)
Автору же статьи огромный плюс за старания. Сам сейчас решаю такую же проблему. И это не так легко как рисуют всякие коучи.
www.youtube.com/watch?v=ecIWPzGEbFc («Uncle» Bob Martin — «The Future of Programming»)
Автору же статьи огромный плюс за старания. Сам сейчас решаю такую же проблему. И это не так легко как рисуют всякие коучи.
Предлагаю сходу не слушать Scrum консультантов и прочих паразитирующих на профессии людей
На всякий случай, я не отношусь к консультантам, но понимаю, как они позволяют экономить время и деньги, избегая «детских» ошибок и разочарования (конечно, речь идет о достойных).
Если Ваша компания готова спонсировать эксперименты по внедрению Скрама своими силами (или любые другие) — отлично!
Много знаете спортсменов-профессионалов, которые обходятся без тренера? А любители вполне себе могут.
P.S.
Видео и в самом деле интересное, спасибо за ссылку.
Я не пытался ни кого задеть или оскорбить. Тем более лично. Так что если вы восприняли это на свой счет, прошу прощения. Я лишь хотел сказать что из Agile сделали нехилый бизнес, с целью заработка денег а не налаживания процессов. Бессмысленный и беспощадный.
Как итог часть людей забыли, что эти методики создали программисты для программистов. Часть об этом не знают до сих пор и постоянно наступают на одни и те жа грабли, меняя коучей и консультантов но так и не добиваясь успеха.
Кстати зачастую именно команда может быть не готова к Agile. Квалификация разработчиков не позволяет просто на просто. И тут ни какой коуч не поможет. К слову с такими командами только нормально настроенная Waterfall модель позволяет делать хоть какое то ПО.
А еще бывает к Agile не готов менеджмент и заказчики, в таком случае опять таки ни какой коуч не поможет, если конечно он не облает безграничным даром убеждения и неимоверной харизмой, а так же готов гарантировать успех рублем.
Как итог часть людей забыли, что эти методики создали программисты для программистов. Часть об этом не знают до сих пор и постоянно наступают на одни и те жа грабли, меняя коучей и консультантов но так и не добиваясь успеха.
Кстати зачастую именно команда может быть не готова к Agile. Квалификация разработчиков не позволяет просто на просто. И тут ни какой коуч не поможет. К слову с такими командами только нормально настроенная Waterfall модель позволяет делать хоть какое то ПО.
А еще бывает к Agile не готов менеджмент и заказчики, в таком случае опять таки ни какой коуч не поможет, если конечно он не облает безграничным даром убеждения и неимоверной харизмой, а так же готов гарантировать успех рублем.
Являюсь руководителем группы разработки ПО в одной «закрытой» компании.
К Scrum и Agile пришел еще в году так 2011, но получается, что наступил на грабли. В моей группе единомышленников не оказалось или почти не оказалось. Полгода пободавшись с коллегами, чётко для себя уяснил, что если не привязать ту же диаграмму сгорания к конечной з/п, то хоть объясняй, хоть нет, но при отсутствии энтузиазма со стороны конкретных разработчиков (именно энтузиазма в части тратить свое время на обязательные техпроцессы по Scrum и Agile) двигаться вперед по этим технологиям невозможно… Сам пришел к выводу, что требовать работать по технологии могу, но это в каком-то роде не правомочно, а при отсутствии «горящих глаз» продолжать не было смысла.
Бесконечно сожалею об этом, но поделать ничего не в силах.
К Scrum и Agile пришел еще в году так 2011, но получается, что наступил на грабли. В моей группе единомышленников не оказалось или почти не оказалось. Полгода пободавшись с коллегами, чётко для себя уяснил, что если не привязать ту же диаграмму сгорания к конечной з/п, то хоть объясняй, хоть нет, но при отсутствии энтузиазма со стороны конкретных разработчиков (именно энтузиазма в части тратить свое время на обязательные техпроцессы по Scrum и Agile) двигаться вперед по этим технологиям невозможно… Сам пришел к выводу, что требовать работать по технологии могу, но это в каком-то роде не правомочно, а при отсутствии «горящих глаз» продолжать не было смысла.
Бесконечно сожалею об этом, но поделать ничего не в силах.
Самых большая ошибка — пытаться натянуть скрам там, где он не нужен. «Закрытая» компания на гос. заказе? Монопольная отрасль? Не рыночные отношения с заказчиком? Скрам такому бизнесу больше навредит.
А уж привязывать берндаун к запрплате — это верный способ замотивировать команду на обман, но никак не на эффективность.
А уж привязывать берндаун к запрплате — это верный способ замотивировать команду на обман, но никак не на эффективность.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Внедрение Scrum'a технарем: реальный опыт, подводные камни, tips&tricks