Комментарии 16
Удивительно, адекватная статья про scrum без всякого бреда, хотя первое впечатление по заголовкам было обратным.
Смысл заголовка статьи правда так и остался для меня тайной.
И Agile — набор ценностей и принципов, а не тактик. Тактика это всё же нечто, что можно применить будучи беспринципным и с ценностями насекомого.
Смысл заголовка статьи правда так и остался для меня тайной.
И Agile — набор ценностей и принципов, а не тактик. Тактика это всё же нечто, что можно применить будучи беспринципным и с ценностями насекомого.
Спасибо за комментарий. К сожалению на ваше замечание я смогу ответить не раньше пятницы. В вопросах есть много интересных тем которые хотелось бы проработать со скрам мастерами прежде чем давать личный ответ. Прошу прощения за задержку.
Прошу прощения что тянул с ответом.
Говоря что Agile это набор тактик я не имел в виду нравственную оценку идей Agile.
Ценности Agile, например то что работающее приложение важнее исчерпывающей документации,
позволяют принять решение в конкретной тактической ситуации. Вложиться и исправить проблемы
с тем что приложение хронически крешится вместо того что бы расписывать сотни воркэранудов.
При этом можно придумать миллионы вариантов процессов которые содержать в себе ценности Agile,
но совсем не похожи друг на друга и работают совершенно по разному для разных команд.
Можно найти разнообразие статей предлагающих разные Agile процессы, многие из них являются
описанием плохо реализованного Scrum из опыта конкретной компании. Такой подход может быть и сработал для авторов статьи, но нет причин что бы он сработал у вас.
Scrum не единственный подход к разработке. Но противопоставлять ему Agile неправильно.
Шилдик Agile вешают на все товары подряд, так что нужно быть очень внимательным в выборе производителя
что бы получить качественный продукт.
Говоря что Agile это набор тактик я не имел в виду нравственную оценку идей Agile.
Ценности Agile, например то что работающее приложение важнее исчерпывающей документации,
позволяют принять решение в конкретной тактической ситуации. Вложиться и исправить проблемы
с тем что приложение хронически крешится вместо того что бы расписывать сотни воркэранудов.
При этом можно придумать миллионы вариантов процессов которые содержать в себе ценности Agile,
но совсем не похожи друг на друга и работают совершенно по разному для разных команд.
Можно найти разнообразие статей предлагающих разные Agile процессы, многие из них являются
описанием плохо реализованного Scrum из опыта конкретной компании. Такой подход может быть и сработал для авторов статьи, но нет причин что бы он сработал у вас.
Scrum не единственный подход к разработке. Но противопоставлять ему Agile неправильно.
Шилдик Agile вешают на все товары подряд, так что нужно быть очень внимательным в выборе производителя
что бы получить качественный продукт.
НЛО прилетело и опубликовало эту надпись здесь
Прошу прощения что долго не отвечал, надеюсь мой ответ все еще будет полезен.
Вы указали большое количество организационных проблем,
пытаться спорить по каждому из пунктов думаю нет смысла — каждая гипотетическая ситуация возможна.
Ситуация когда разработка работает по «Scrum», при этом бизнес продолжает отношения с разработкой
по старому «В реальной жизни», «А по факту» и т.д. на самом деле складывается достаточно часто.
И это большая проблема.
Я бы посоветовал вам прочитать мою предыдущую статью в которой я пытаюсь предостеречь от внедрения Scrum только в разработке, без договоренности об изменении подхода к работе с бизнесом.
В описанной вами ситуации подход «пиши код!» действительно может оказаться наиболее эффективным,
просто потому что он соответствует ожиданиям бизнеса от разработки.
Вы указали большое количество организационных проблем,
пытаться спорить по каждому из пунктов думаю нет смысла — каждая гипотетическая ситуация возможна.
Ситуация когда разработка работает по «Scrum», при этом бизнес продолжает отношения с разработкой
по старому «В реальной жизни», «А по факту» и т.д. на самом деле складывается достаточно часто.
И это большая проблема.
Я бы посоветовал вам прочитать мою предыдущую статью в которой я пытаюсь предостеречь от внедрения Scrum только в разработке, без договоренности об изменении подхода к работе с бизнесом.
В описанной вами ситуации подход «пиши код!» действительно может оказаться наиболее эффективным,
просто потому что он соответствует ожиданиям бизнеса от разработки.
Все элементы Scrum задуманы взаимно дополнять и поддерживать друг друга. При этом они не дублируются. В Scrum нет запаса прочности. По этому все, что описано в Scrum Guide обязательно к реализации, из Scrum нельзя ничего выбрасывать. Но можно и нужно расширять.
Я люблю скрам. Но тут звучит так, как будто скрам создали боги.
Если делать «без головы» — то на скрам ниодну команду по-нормальному перевести не получится, даже имея продукт овнеров в одной комнате с вами на стэндапе. Более того, команда должна быть готовой.
Нужно чётко понимать что для чего. Поэтому, не вижу чего-то страшного в отхождении от канонов.
У нас, например, каждый день скрам мастером на Стэнд Ап выбирается кто-то с команды путём бросания кубика. До стэндапа — прессует QA команду, чтобы она всё до-проверяла, что не успела и перевесила что-нибудь в done. Этот человек подключается к митингу с Америкой, полностью ведёт сам стэндап, подводит итог дня (озвучивает сколько поинтов сделано), высылает follow-up в котором вкратце кто что сказал + burn-down чарт. Это плохо? Всё это вышло эволюционно, и, от части, требование продукт овнеров.
Большое спасибо за комментарий и прошу прощения за задержку с ответом.
1. Конечно Scrum создали не боги, но его создали умные люди с обширным жизненным опытом.
За 20 лет существования Scrum он был достаточно глубоко продуман и сбалансирован.
2. Конечно в Scrum нужно «делать с головой», Scrum Guide очень сложен. Кроме того Scrum Guide
это не готовое решение, а способ его получить.
3. «ничего страшного в отхождении от канонов» — вот тут нужно быть очень аккуратным,
это тонкий лед который может треснуть и вы провалитесь в ледяную воду.
4. то что вы выбираете «скрам мастера» перед стендапом, на самом деле не противоречит Scrum,
поскольку Scrum Master не обязан сам организовывать что либо, он должен обеспечить организацию.
Если вы пришли к тому что игра с кубиком для вас подходит, отлично.
Правда называть человека проводящего дейли «скрам мастером» неправильно — это подмена понятий.
5. «прессует QA команду» — я уверен что ваши отношения с QA на самом деле хорошие,
вы просто выбрали неудачную формулировку. Тем не менее тут есть большая проблема.
Наверняка тестирование является обязательной частью вашего процесса,
необходимым шагом что бы выполнить работу. Из того что вы сформулировали кажется
что либо QA не входят в вашу команду, либо формально входят но на самом деле живут отдельной
от программистов жизнью. Так часто бывает. И то и другое плохо для разработки в целом,
поскольку в таком случае не имеете возможность довести работу до конца в рамках Scrum команды.
6. То что вы отчитываетесь о прогрессе каждый день тоже имеет свои подводные камни.
Организация работы в рамках спринта это полностью ответственность Development Team,
и в нее никто не должен вмешиваться (механизм влияния на команду это Review).
Описанный вами подход ведет к следующим проблемам:
а) микроменеджмент команды вместо самоорганизации
б) ежедневное изменение планов вместо движения к цели (какая у вас цель спринта?)
Возможно вашей команде следует добиться большей самостоятельности,
но конечно я могу ошибаться.
1. Конечно Scrum создали не боги, но его создали умные люди с обширным жизненным опытом.
За 20 лет существования Scrum он был достаточно глубоко продуман и сбалансирован.
2. Конечно в Scrum нужно «делать с головой», Scrum Guide очень сложен. Кроме того Scrum Guide
это не готовое решение, а способ его получить.
3. «ничего страшного в отхождении от канонов» — вот тут нужно быть очень аккуратным,
это тонкий лед который может треснуть и вы провалитесь в ледяную воду.
4. то что вы выбираете «скрам мастера» перед стендапом, на самом деле не противоречит Scrum,
поскольку Scrum Master не обязан сам организовывать что либо, он должен обеспечить организацию.
Если вы пришли к тому что игра с кубиком для вас подходит, отлично.
Правда называть человека проводящего дейли «скрам мастером» неправильно — это подмена понятий.
5. «прессует QA команду» — я уверен что ваши отношения с QA на самом деле хорошие,
вы просто выбрали неудачную формулировку. Тем не менее тут есть большая проблема.
Наверняка тестирование является обязательной частью вашего процесса,
необходимым шагом что бы выполнить работу. Из того что вы сформулировали кажется
что либо QA не входят в вашу команду, либо формально входят но на самом деле живут отдельной
от программистов жизнью. Так часто бывает. И то и другое плохо для разработки в целом,
поскольку в таком случае не имеете возможность довести работу до конца в рамках Scrum команды.
6. То что вы отчитываетесь о прогрессе каждый день тоже имеет свои подводные камни.
Организация работы в рамках спринта это полностью ответственность Development Team,
и в нее никто не должен вмешиваться (механизм влияния на команду это Review).
Описанный вами подход ведет к следующим проблемам:
а) микроменеджмент команды вместо самоорганизации
б) ежедневное изменение планов вместо движения к цели (какая у вас цель спринта?)
Возможно вашей команде следует добиться большей самостоятельности,
но конечно я могу ошибаться.
>В Scrum нет Demo
Вранье! Есть там demo, более того оно необходимо, для демонстрации той части продукта, которая был сделана во время спринта. Именно ёё ждут заказчики, т.к. для них это ВАЖНО! Demo делается для обратной связи.
>Команда
Scrum команда подбирается таким образом, чтобы не было необходимости брать кого-то со стороны, все участники которые заняты в разработке продукта, они находятся в команде, может частично, но они есть и они рядом.
Review — обсуждение процесса
>Scrum-мастер
Это не человек, это роль. В scrum лишь говорится что эта роль не должна пересекаться с ролью product owner'a. По своей сути это менджер модератор, без особых прав.
Изначально я скептически относился к скраму. О нем слишком много говорят, а работают как всегда. После треннигов я кардинально поменял мнение. Scrum это всего лишь фрейморв и набор каких-то правил. Он не сделает из глупого управленца умного и не повысит квалификацию разработчиков. Прежде чем применять scrum надо точно понимать что он вписывается в условия работы. Люди почему-то называют scrum, ведение jira, стояние у доски и прочий карго культ, забывая что конечным результатом является продукт.
Scrum очень умело приподнесли слабому менеджменту в виде «серебряной пули», мол онрешит все ваши проблемы. Люди бездумно кинулись его внедрять: без понимания контекста, особенностей бизнес процесса и собственно самого scrum. Например команда из 10 человек, включая оунеров, разработчиков, тестировщиков и т.д. делает продукт, они что на столько глупы что не могут договориться между собой? Они делают какую-то космическую ракету в которой все до запятой должно соотвествовать спецификации, а под спецификацией 3 года физ-мат расчетов?
Современная разработка ПО скорее напоминает бригаду по ремонту квартиры, нежели, чем наукоемкое и высокоточное производство.
Отдельно я бы вынес софтверных гигантов, у которых процесс создания ПО по сложности близок к производственным на уровне завода
.
Качественный продукт делает талантливая команда, а не процес.
Вранье! Есть там demo, более того оно необходимо, для демонстрации той части продукта, которая был сделана во время спринта. Именно ёё ждут заказчики, т.к. для них это ВАЖНО! Demo делается для обратной связи.
>Команда
Scrum команда подбирается таким образом, чтобы не было необходимости брать кого-то со стороны, все участники которые заняты в разработке продукта, они находятся в команде, может частично, но они есть и они рядом.
Review — обсуждение процесса
>Scrum-мастер
Это не человек, это роль. В scrum лишь говорится что эта роль не должна пересекаться с ролью product owner'a. По своей сути это менджер модератор, без особых прав.
Изначально я скептически относился к скраму. О нем слишком много говорят, а работают как всегда. После треннигов я кардинально поменял мнение. Scrum это всего лишь фрейморв и набор каких-то правил. Он не сделает из глупого управленца умного и не повысит квалификацию разработчиков. Прежде чем применять scrum надо точно понимать что он вписывается в условия работы. Люди почему-то называют scrum, ведение jira, стояние у доски и прочий карго культ, забывая что конечным результатом является продукт.
Scrum очень умело приподнесли слабому менеджменту в виде «серебряной пули», мол онрешит все ваши проблемы. Люди бездумно кинулись его внедрять: без понимания контекста, особенностей бизнес процесса и собственно самого scrum. Например команда из 10 человек, включая оунеров, разработчиков, тестировщиков и т.д. делает продукт, они что на столько глупы что не могут договориться между собой? Они делают какую-то космическую ракету в которой все до запятой должно соотвествовать спецификации, а под спецификацией 3 года физ-мат расчетов?
Современная разработка ПО скорее напоминает бригаду по ремонту квартиры, нежели, чем наукоемкое и высокоточное производство.
Отдельно я бы вынес софтверных гигантов, у которых процесс создания ПО по сложности близок к производственным на уровне завода
.
Качественный продукт делает талантливая команда, а не процес.
Как показывает практика, корректный процесс как раз позволяет нивелировать раздолбайство команды :)
На старте, гениальная команда выйграет. это факт, Но через время методичная команда, работающая «по процессу» выигрывает у гениев, поскольку накладные расходы на коммуникацию, координацию и устранение «а хто эта сделал ?!» никто не отменял.
В этом отношение review, проведенной корректно — очень полезно и служит этим «великим уравнителем».
На старте, гениальная команда выйграет. это факт, Но через время методичная команда, работающая «по процессу» выигрывает у гениев, поскольку накладные расходы на коммуникацию, координацию и устранение «а хто эта сделал ?!» никто не отменял.
В этом отношение review, проведенной корректно — очень полезно и служит этим «великим уравнителем».
Очень часто вижу как скрам интепретируется разными авторами по разному и каждый раз далеко от реальности. Сам практикую скрам уже более двух лет и нареканий на него еще не было. Очень качественный фреймворк, при чем даже в условиях фикс прайса и вотерфола. Не понимаю почему скрам часто мешают с agile и путают принципы и практики. Для примера, в скраме самое главное это прозрачность процесса, и своевременность в принятии решений и поднятию проблем. Каждую неделю все в курсе всех событий, всегда актуален план на неделю и представление о следующих неделях. Вот и весь его профит. Считаю его идеальным фреймворком в первую очередь — КОММУНИКАЦИЙ. Не более того. Управление разработкой и скрам лежат в разных плоскостях. Тот же скрам использую для управления документированием проекта, его ресёрчем, дизайном. Главное это прозрачность в планировании, исполнении, произведению выводов. Прекрасный процесс
tldr; — Правильный скрам хорошо, а неправильный — плохо.
Отличная статья! Автору респект!
Одно только замечание, хоть и некоторые активности скрама могут быть возложены на разработчиков, но скрам мастер не должен быть членом команды. Это принципиальный момент и последствиями будут как раз таки «забивание» на скрам практики, когда будет не хватать времени, которого всегда не хватает.
Спасибо за отличную статью! Такие статьи помогают в работе с коллегами.
Одно только замечание, хоть и некоторые активности скрама могут быть возложены на разработчиков, но скрам мастер не должен быть членом команды. Это принципиальный момент и последствиями будут как раз таки «забивание» на скрам практики, когда будет не хватать времени, которого всегда не хватает.
Спасибо за отличную статью! Такие статьи помогают в работе с коллегами.
Прошу прощения что тянул с ответом.
Конечно вы имели в виду что Scrum Master не должен быть частью именно Development Team,
а в Scrum Team он само собой входит.
Да, с ролью Scrum Mater есть сложность. Но из своего опыта я не могу ни согласиться с вами ни опровергнуть.
С одной стороны если Scrum Master является частью Development Team:
1. Хорошо — он вовлечен в процесс и отлично понимает все его тонкости. Главное, команда воспринимает его как равного.
2. Плохо — он может быть завален работой по разработке и не сможет исполнять роль мастера должным образом.
3. Плохо — если в команде возникнут проблемы касающиеся именно его работы, ему сложно будет беспристрастно разобрать такую ситуацию с командой и найти решение.
С другой стороны, если Scrum Master это работа на полный день:
1. Хорошо — что Scrum Master имеет достаточно времени выполнять свою роль.
2. Хорошо — что позиция Scrum Master независимая и он может без лишних эмоций разбирать любые конфликты.
3. Плохо — что он не вовлечен в реальный рабочий процесс. Это отделяет его от команды. Как офицер который командует рядовыми из бункера.
Вероятно оба подхода имеют право на жизнь, и нужно просто постараться получить максимум
от конкретной сложившейся ситуации а не пытаться искать недостижимый идеал на рынке труда.
Хотя чем черт не шутит, вдруг повезет.
Конечно вы имели в виду что Scrum Master не должен быть частью именно Development Team,
а в Scrum Team он само собой входит.
Да, с ролью Scrum Mater есть сложность. Но из своего опыта я не могу ни согласиться с вами ни опровергнуть.
С одной стороны если Scrum Master является частью Development Team:
1. Хорошо — он вовлечен в процесс и отлично понимает все его тонкости. Главное, команда воспринимает его как равного.
2. Плохо — он может быть завален работой по разработке и не сможет исполнять роль мастера должным образом.
3. Плохо — если в команде возникнут проблемы касающиеся именно его работы, ему сложно будет беспристрастно разобрать такую ситуацию с командой и найти решение.
С другой стороны, если Scrum Master это работа на полный день:
1. Хорошо — что Scrum Master имеет достаточно времени выполнять свою роль.
2. Хорошо — что позиция Scrum Master независимая и он может без лишних эмоций разбирать любые конфликты.
3. Плохо — что он не вовлечен в реальный рабочий процесс. Это отделяет его от команды. Как офицер который командует рядовыми из бункера.
Вероятно оба подхода имеют право на жизнь, и нужно просто постараться получить максимум
от конкретной сложившейся ситуации а не пытаться искать недостижимый идеал на рынке труда.
Хотя чем черт не шутит, вдруг повезет.
По Scrum у нас есть подробный кейс, где мы говорим про наш опыт и фишки, вроде «Рыбного четверга». Предлагаю обсуждать в комментариях. www.carrotquest.io/blog/kak-organizovat-rabotu-komandy-opyt-metodologii-scrum-v-carrot-quest
Если дизайнер Иннокентий нарисовал отличный дизайн, но команда не смогла его реализовать и зарелизить — это провал команды в целом и каждого участника в команды в частности. Иннокентий, вместо того чтобы пенять на JavaScript и QA, что те медленно работают, должен задуматься: может быть, он может изменить что-то в своей работе, чтобы в следующий раз команда добилась результата
Где был какой-нить начальник? Почему дизайнер и программист не взаимодействуют? Я наконец понял смысл всех продаванов скрама, аджайила и т.д.
Они берут стандартную проблему, решение которой уже давным давно есть, заявляют что это проблема и в рамках фреймворка мы ее решаем.
В реальности более менее общительный лид, зная что делается что-то сложное усилит над этой фичой контроль, вот и все! и не надо никаких скрамов и аджайлов.
Зафакапленая работа это косяк кривого менеджмента! (P.S. но он тоже имеет права на обшибку, но его ошибки как правило дороже)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Худой Scrum лучше доброго Agile