Comments 23
> Из-за подчеркнутой важности этого элемента скрама, мы всегда его использовали. Но из-за того, что мы не понимали смысла, мы придумывали ужасные цели. Обычно мы просто упрощали процесс выбора цели, задавая негласное правило, брать целью выпуск очередного релиза или реализацию какой-то очередной жирной спринтовой фичи. От этого усиливалось ощущение бесполезности цели, а то и ее вреда.
ПОЧЕМУ нужно выключать мозг и следовать за «серебряными пулями», вместо того чтобы немного подумать и придти к логичным выводам.
ПОЧЕМУ нужно выключать мозг и следовать за «серебряными пулями», вместо того чтобы немного подумать и придти к логичным выводам.
- ПОЧЕМУ нужна цель спринта?
Можно пару хороших примеров целей спринта? А то за отрицанием (не делайте релиз целью) я не могу разглядеть что такое хорошая цель.
Продуктовые цели:
- Повысить конверсию на 5%;
- Вывести продукт на рынок B2C.
Такая цель может висеть несколько спринтов подряд, до тех пор пока не будет достигнута.
Техническая цель:
- Делать ровно столько, сколько нужно для готовности спринтовой фичи, не закладываясь на будущее;
- Завершить спринт без хвостов.
Техническими целями лучше не злоупотреблять. Ставить их нужно только для командного решения наболевших проблем
Приведите, пожалуйста, примеры правильно поставленных целей спринта из вашего опыта.
>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель
В корне неверное суждение. Командообразующий элемент это подбор праивльных людей в команду и организациея иерархии и ролей в команде.
>2.ПОЧЕМУ нужно отправлять письмо с объявлением старта спринта всем заинтересованным лицам и членам команды?
Какой-то бюррократический оверхед. Заинтересованные лица как правило знают место, где можно посмотреть текущее состояние, плюс спросить у лида или еше кого либо. Пункт для имитации бурной дятельности.
Вообще метрика только в одних SP попытка объять обним показателем эффективность работы, сомнительная затея. Можно на это потратить кучу времени, но не получить результата.
>Если у кого-нибудь из команды возникает проблема, угрожающая срывом сроков спринта, то она сразу вскрывается и решается совместными усилиями.
Это работает и без скрама при адекватном руководстве, при неадекватном проблему можно вскрывать каждый раз.
Мне вообще скрам напоминает: «Организация рабочего процесса для чайников» в желте-черной обложке. В реальности все сложнее и учитывать приходится многие факторы. Тот же DM Daily Meeting обыкновенная оперативка перед работой, быстро поговорили у кого что и как и поехали работать.
Статья попахивает «скрам головного мозга».
В корне неверное суждение. Командообразующий элемент это подбор праивльных людей в команду и организациея иерархии и ролей в команде.
>2.ПОЧЕМУ нужно отправлять письмо с объявлением старта спринта всем заинтересованным лицам и членам команды?
Какой-то бюррократический оверхед. Заинтересованные лица как правило знают место, где можно посмотреть текущее состояние, плюс спросить у лида или еше кого либо. Пункт для имитации бурной дятельности.
Вообще метрика только в одних SP попытка объять обним показателем эффективность работы, сомнительная затея. Можно на это потратить кучу времени, но не получить результата.
>Если у кого-нибудь из команды возникает проблема, угрожающая срывом сроков спринта, то она сразу вскрывается и решается совместными усилиями.
Это работает и без скрама при адекватном руководстве, при неадекватном проблему можно вскрывать каждый раз.
Мне вообще скрам напоминает: «Организация рабочего процесса для чайников» в желте-черной обложке. В реальности все сложнее и учитывать приходится многие факторы. Тот же DM Daily Meeting обыкновенная оперативка перед работой, быстро поговорили у кого что и как и поехали работать.
Статья попахивает «скрам головного мозга».
Эти методологии разработки натянуты за уши и не везде подходят.
Вы не написали, что и на чем программируете.
1. Цели может и не быть. Ну или цель сделать то, что хочет заказчик. Но это наличие цели ради самого факта наличия цели.
>Задачи нарезаны таким образом, чтобы результат работы одного члена команды был использован другим членом команды в другом спринте.
А как их нужно резать? Чтобы результаты работы одного члена команды использовал тот же член команды?
Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует.
Как это можно обойти?
>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель — это то к чему стремится каждый из членов команды в течении спринта и это то что важно для всей команды в целом.
У каждого члена может быть своя цель…
2. Бюрократия
3. Та какой ритм? Как это все считается? Сферический конь в вакууме.
> Например, на график может повлиять постоянное изменение объема незапланированных задач, от спринта к спринту.
И что тут такого?
Баги-то фиксить нужно.
>Эта проблема в свою очередь может быть причиной срыва сроков спринта.
Дались Вам те сроки спринта.
>Также график производительности команды полезен при определении объема задач на спринт на основе метода вчерашней погоды.
Это все сферический конь в вакууме.
4. Что вообще такое ритм и производительность.
Провал ритма — это команда сидит и забила на работу? :)
5. Это ненужная вещь.
О проблеме нужно сообщать в задаче сразу, а не ждать DSM!
6.
> Во-первых, делая готовый продукт в конце спринта, команда избавляется от хвостов.
Заливайте в мастер готовые фичи и будет вам готовый продукт в любой момент!
> Новый спринт начинается с чистого листа, с новыми пользовательскими историями.
Не всегда успевают протестировать прошлый спринт в течение прошлого спринта!
>В-третьих, не приходится выпиливать куски кода для пользовательской истории, которая была наполовину реализована один или несколько спринтов назад и сильно упала в приоритете или совсем потеряла актуальность.
А если она была реализована полностью?
То как быть с выпиливанием?
Да и зачем ее выпиливыть, если хранить ее в отдельной ветке?
Ее в мастере и быть не должно.
Скрам вроде бы гибкая методология, но она никакая не гибкая.
Вы не написали, что и на чем программируете.
1. Цели может и не быть. Ну или цель сделать то, что хочет заказчик. Но это наличие цели ради самого факта наличия цели.
>Задачи нарезаны таким образом, чтобы результат работы одного члена команды был использован другим членом команды в другом спринте.
А как их нужно резать? Чтобы результаты работы одного члена команды использовал тот же член команды?
Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует.
Как это можно обойти?
>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель — это то к чему стремится каждый из членов команды в течении спринта и это то что важно для всей команды в целом.
У каждого члена может быть своя цель…
2. Бюрократия
3. Та какой ритм? Как это все считается? Сферический конь в вакууме.
> Например, на график может повлиять постоянное изменение объема незапланированных задач, от спринта к спринту.
И что тут такого?
Баги-то фиксить нужно.
>Эта проблема в свою очередь может быть причиной срыва сроков спринта.
Дались Вам те сроки спринта.
>Также график производительности команды полезен при определении объема задач на спринт на основе метода вчерашней погоды.
Это все сферический конь в вакууме.
4. Что вообще такое ритм и производительность.
Провал ритма — это команда сидит и забила на работу? :)
5. Это ненужная вещь.
О проблеме нужно сообщать в задаче сразу, а не ждать DSM!
6.
> Во-первых, делая готовый продукт в конце спринта, команда избавляется от хвостов.
Заливайте в мастер готовые фичи и будет вам готовый продукт в любой момент!
> Новый спринт начинается с чистого листа, с новыми пользовательскими историями.
Не всегда успевают протестировать прошлый спринт в течение прошлого спринта!
>В-третьих, не приходится выпиливать куски кода для пользовательской истории, которая была наполовину реализована один или несколько спринтов назад и сильно упала в приоритете или совсем потеряла актуальность.
А если она была реализована полностью?
То как быть с выпиливанием?
Да и зачем ее выпиливыть, если хранить ее в отдельной ветке?
Ее в мастере и быть не должно.
Скрам вроде бы гибкая методология, но она никакая не гибкая.
Вы правы. Скрам хорошо работает только в продуктовой и инхаус разработке. В других случаях лучше канбан или что-нибуть из каскадо-водопада
> Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует. Как это можно обойти?
Если взять 3 недельный спринт, то можно успеть написать API и клиента в одном спринте.
Если взять 3 недельный спринт, то можно успеть написать API и клиента в одном спринте.
> У каждого члена может быть своя цель
Может, но это уже не скрам
Может, но это уже не скрам
Так ведь скрам-тренеры и напирают на то, что надо следовать букве этого скрама, а мы вам продадим свои услуги, чтобы ему ещё более лучше следовать. В любой методологии есть здравый смысл, но когда его возводят в ранг истины в первой инстанции, то проблемы искать надо в самой компании — команде, менеджменте.
Гибкая она, только если знать где гнуть. Скрам это контракт (как программный интерфейс) между тремя сторонами — ПМ, Заказчиком и Инженерами. Реализация этого контракта зависит от много чего. Как и в программировании — хорошее API может быть плохо реализовано. На тренингах этому, к сожалению, этому не учат, а занимаются разбором этого самого интерфейса. Пообщайтесь с кем-то у кого скрам работает — взглянете на это по-другому. Если хотите — спрашивайте в личку.
Уж не знаю, дело во мне, или все эти методологии разработки — на самом деле жалкие попытки впихнуть разработку в прокрустово ложе бюрократии, но я пока что признаю только эту методологию, самую простую и понятную.
А у меня команде не было DSM, и была отличная «синхронизация». Когда у тебя в команде 3 человека и один QA которые в постоянном контакте, а не одни социопаты, то все отлично.
А вот еще помню к нам приезжал Zibsun и говорил что нынче не надо оценивать таски в часах, хотя за несколько лет до этого говорил другое, этож аджайл, куда повернешь туда и поплывет
А вот еще помню к нам приезжал Zibsun и говорил что нынче не надо оценивать таски в часах, хотя за несколько лет до этого говорил другое, этож аджайл, куда повернешь туда и поплывет
этож аджайл, куда повернешь туда и поплывет
Как раз об этом моя статья. Нельзя бездумно перекраивать Agile процесс!
Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: "А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity..." и остальные ему: "Давай, давай, давай".
Правила скрама более продуманны, чем может показаться на первый взгляд.
тем не менее команда нисколько не пострадала, а решение не было бездумным, мы просто выкинули раздражающий и отвлекающий фактор. каждый день мы были вынуждены слушать все, что и так знали. кстати ретроспектива отправилась в ту же топку. скрам ли это после таких изменений? я не знаю, но хуже точно не стало.
>бездумно
бездумно вообще ничего делать нельзя ))
>Правила скрама более продуманны, чем может показаться на первый взгляд.
я знаю насоклько они продуманы, у меня была возможность увидеть как работает та или иная вещь в других командах, и все же посмею утверждать, что они не универсальны, иначе это превращается в серебряную пулю
>Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: «А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity...» и остальные ему: «Давай, давай, давай».
вообще примерно так и было ))
>бездумно
бездумно вообще ничего делать нельзя ))
>Правила скрама более продуманны, чем может показаться на первый взгляд.
я знаю насоклько они продуманы, у меня была возможность увидеть как работает та или иная вещь в других командах, и все же посмею утверждать, что они не универсальны, иначе это превращается в серебряную пулю
>Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: «А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity...» и остальные ему: «Давай, давай, давай».
вообще примерно так и было ))
Sign up to leave a comment.
Ломай меня полностью… разве это про Scrum?