Комментарии 54
Мы начинаем митинги в 9 утра.
Поразило до глубины души :)
А что есть в этой статье такого, что уже стопицот раз не было разжевано на хабре?
Каждый опыт уникален, не так ли?
Несмотря на то что статья про «реальный опыт» больше всего похоже на некий скрам в вакууме.
И что будет если этот разработчик уволится или заболеет? Вы прекратите разработку этого модуля?
Первый раз слышу чтобы заказчик так понимающе относился к проблемам разработки. Из моего опыта они и слышать не хотят о сдвиге уже запланированных задач и предлагают использовать внутренние резервы или магию увеличения количества часов в сутках.
Резюмируя:
Мне слабо верится что это действительно реальный опыт и у вас все так хорошо как вы описали.
Но если это действительно так, то конечно завидую :)
Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт.
И что будет если этот разработчик уволится или заболеет? Вы прекратите разработку этого модуля?
Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
Первый раз слышу чтобы заказчик так понимающе относился к проблемам разработки. Из моего опыта они и слышать не хотят о сдвиге уже запланированных задач и предлагают использовать внутренние резервы или магию увеличения количества часов в сутках.
Резюмируя:
Мне слабо верится что это действительно реальный опыт и у вас все так хорошо как вы описали.
Но если это действительно так, то конечно завидую :)
Ну это проблема уже команды, которая не может пояснить заказчику, что она не можеть взять в итерацию больше обещанного. У нас тоже такое правило есть, но оно не распространяется на хотфиксы, которые прилетают со статусом «аааа, всё упало» и команда не может их не взять, если это угрожает стабильности продукта. У каждой команды есть свой менеджер который отвечает за часть продукта и уже он заворачивает все «хотелки» выше стоящих людей, а если не заворачивает, то берёт ответственность на себя, за то что, его команда не выпустила обещанный функционал в срок. В остальном же, задачи по улучшению и не критическим багам легко двигаются в следующюю итерацию или вообще в беклог. Так что всё возможно.
Заказчик вообще с разработчиками разговаривать не должен. Только с Product owner-ом. А там уж его задача объяснить, что «успеем мы либо это либо то»
По поводу срочных багфиксов — лично товарищ Сазэрленд советовал всегда оставлять в спринте буфер 10-20% времени для таких вот случаев. Но все-равно, проходят они только через Product owner-а.
По поводу срочных багфиксов — лично товарищ Сазэрленд советовал всегда оставлять в спринте буфер 10-20% времени для таких вот случаев. Но все-равно, проходят они только через Product owner-а.
Напрямую заказчик с разработчиками и не общается, просто из моего опыта Product owner это человек который играет на стороне заказчика а не команды. И обычно он старается максимально выполнить хотелки заказчика иногда в ушерб команде. Хотя я надеюсь что просто мне не очень повезло попасть в такой проект.
Конечно Product owner играет на стороне заказчика. Дело в том, что никто не в праве давить на команду. Команда берет задачи у Product owner-а а не Product owner дает задачи. Кроме того очень важно, что это всегда один человек. Он хоть и на стороне заказчика, но будет глупо себя чувствовать сказав вчера, что фича А — суперважна, и придя сегодня с фичей Б ))
Но реальная жизнь конечно отличается от теории ))
Большинство проблем скрама от того, что руководство продолжает использовать иерархическую модель, микроменеджмент и т.д. Я бы вообще поставил это первым условием для внедрения скрама — «Руководство компании/подразделения действительно понимает что это такое».
Обычно то все думают, что это какая-то девелоперская фишка чтобы работать в 2 паза быстрее. А это ведь технология управления а не разработки.
Но реальная жизнь конечно отличается от теории ))
Большинство проблем скрама от того, что руководство продолжает использовать иерархическую модель, микроменеджмент и т.д. Я бы вообще поставил это первым условием для внедрения скрама — «Руководство компании/подразделения действительно понимает что это такое».
Обычно то все думают, что это какая-то девелоперская фишка чтобы работать в 2 паза быстрее. А это ведь технология управления а не разработки.
Можно я задам вопрос: а что происходит, когда команда не хочет делать что-то, что хочет PO?
РО выстраивает бэк-лог, в нем задачи имеют приоритеты.
Если команда регулярно игнорирует самую приоритетную историю, и не дает внятного объяснения причины, значит команда не справляется со своими обязанностями )) Все-таки команда не решает что брать а что не брать, она решает сколько взять а сколько оставить для следующего спринта.
Если же причины на то есть, по РО их игнорирует — значит с ним что-то не так. В любом случае судить кому-то вышестоящему.
Если команда регулярно игнорирует самую приоритетную историю, и не дает внятного объяснения причины, значит команда не справляется со своими обязанностями )) Все-таки команда не решает что брать а что не брать, она решает сколько взять а сколько оставить для следующего спринта.
Если же причины на то есть, по РО их игнорирует — значит с ним что-то не так. В любом случае судить кому-то вышестоящему.
Не регулярно. Для того, чтобы запороть длинный и сложный эпик достаточно одного места (issue на 1 sp), в отношении которого будет «я его не успел сделать, у меня были более важные (читай, технически интересные) вещи, чем сидеть и уныло кодить 30 чекбоксов в JS».
Мы, собственно, от модели «каждый берёт себе на реализацию то, что хочет» и отходим, потому что оказывалось, что часть вещей из недели в неделю лежат несделанными.
Сейчас картинка другая: «кто хочет делать Х?». То есть хоть кто-то на митинге должен взяться. А дальше там уже команда сама решает кто будет, кто нет.
Мы, собственно, от модели «каждый берёт себе на реализацию то, что хочет» и отходим, потому что оказывалось, что часть вещей из недели в неделю лежат несделанными.
Сейчас картинка другая: «кто хочет делать Х?». То есть хоть кто-то на митинге должен взяться. А дальше там уже команда сама решает кто будет, кто нет.
Хаа… начну из далека ))
В чем соль скрама? Почему он быстрее даже при разработке тех же самых фич теми же самыми девелоперами? Многие думают, что суть в митингах и совместном обсуждении, или в том, что команды наконец стали кросс-функциональными, некоторые вообще назовут девелоперские практики их ХР.
Мое мнение: соль, главная цель и суть — переключение сознания с индивидуального на командное. Нет больше ничего личного ни личных тасков, ни личных проблем ни личного успеха. Только командное. Команда берет себе юзер-стори, команда ответственна за ее выполнение.
Обосрался один девелопер — обосралась вся команда. С другой стороны, если обосралась твоя команда — обосрался и ты, даже если ты сделал «свои таски» супер быстро и качественно.
И как следствие — команда осталась без бонуса — ты тоже его не увидишь, даже если ты вообще теоретически не мог помочь Васе, т.к. он пишет на С++ а ты — РНР-шник.
Возвращаясь к вашему сообщению. Конечно не может быть «каждый берет» и «кто хочет делать». Вопрос звучит так (грубо говоря)
— Эй, команда!!! Мы успеем сделать истории А, В, С за это спринт?
— Успеем!
— Зашибись! Давайте теперь обсудим детали, как именно (и уже здесь распределяем кто что может делать)
Истории\команда должны быть такими, чтобы ВСЯ команда работала над одной историей одновременно и только по ее окончанию переключалась на следующую.
В чем соль скрама? Почему он быстрее даже при разработке тех же самых фич теми же самыми девелоперами? Многие думают, что суть в митингах и совместном обсуждении, или в том, что команды наконец стали кросс-функциональными, некоторые вообще назовут девелоперские практики их ХР.
Мое мнение: соль, главная цель и суть — переключение сознания с индивидуального на командное. Нет больше ничего личного ни личных тасков, ни личных проблем ни личного успеха. Только командное. Команда берет себе юзер-стори, команда ответственна за ее выполнение.
Обосрался один девелопер — обосралась вся команда. С другой стороны, если обосралась твоя команда — обосрался и ты, даже если ты сделал «свои таски» супер быстро и качественно.
И как следствие — команда осталась без бонуса — ты тоже его не увидишь, даже если ты вообще теоретически не мог помочь Васе, т.к. он пишет на С++ а ты — РНР-шник.
Возвращаясь к вашему сообщению. Конечно не может быть «каждый берет» и «кто хочет делать». Вопрос звучит так (грубо говоря)
— Эй, команда!!! Мы успеем сделать истории А, В, С за это спринт?
— Успеем!
— Зашибись! Давайте теперь обсудим детали, как именно (и уже здесь распределяем кто что может делать)
Истории\команда должны быть такими, чтобы ВСЯ команда работала над одной историей одновременно и только по ее окончанию переключалась на следующую.
Совсем другое представление, да…
Для меня scrum — это чёткое планирование времени сотрудников. Программист имеет право послать любого с любой задачей, если она не была обсуждена, или, при должной настоийчивости запрашивающего, получить индульгенцию на этот спринт, и виноват будет вопрошающий.
С другой стороны, PO имеет точные сроки реализации фичи, явный план разработки.
Программисты же со своей стороны могут влиять на процесс и адекватно и явно (!) реализовывать технический долг, который может быть реализован в гармонии с процессом разработки (то есть в моменты, когда развитие ПО это позволяет).
Коллективная же ответственность, как мне кажется, большое зло. Особенно в ситуации, когда проект очень большой и подразумевающий специализацию. Коллективная ответственность в России ведёт к колхозу и безответственности.
Для меня scrum — это чёткое планирование времени сотрудников. Программист имеет право послать любого с любой задачей, если она не была обсуждена, или, при должной настоийчивости запрашивающего, получить индульгенцию на этот спринт, и виноват будет вопрошающий.
С другой стороны, PO имеет точные сроки реализации фичи, явный план разработки.
Программисты же со своей стороны могут влиять на процесс и адекватно и явно (!) реализовывать технический долг, который может быть реализован в гармонии с процессом разработки (то есть в моменты, когда развитие ПО это позволяет).
Коллективная же ответственность, как мне кажется, большое зло. Особенно в ситуации, когда проект очень большой и подразумевающий специализацию. Коллективная ответственность в России ведёт к колхозу и безответственности.
Ну, скажем так, это вообще большая тема для дискуссии — на сколько реализуема коллективная ответственность, что из нее получается в российской реальности и т.д.
Может у нас никто не умеет обращаться с ответственностью именно потому, что у нас никто не умеет ее давать? Всмысле, что ответственность то у все давать любят а вот свободу — не очень. Это как в воспитании детей, одни контролируют каждый шаг «не дай бог что случится», другие даже не смотрят на ребенка, говоря «сам никогда и не научится пока сам не упадет, не ушибется не обожгется».
Но все же с моей точки зрения скрам это когда:
— девелоперы сами планируют свое время
— РО не имеет сроки а получает сроки от девелоперов. Если дедлайн ближе — значит нужно уменьшать функциональность (при неизменности команды)
Не зря одним из ярких пунктов в теории скрама — отсутствие тимлидера.
По поводу «послать любого» — для девелопера вообще никого не существует кроме РО и его коллег-девелоперов. Так что посылать просто должно быть некого ))
Вобщем пора отделять мух от котлет. С одной стороны у нас теория и «как по идее должно быть» с другой стороны практика и реальные условия внедрения. Но на мой вопрос «а что в скраме является необходимым требованием, а чем можно пренебречь есть ли гибкость в его теории» ответ был — «Если что-то написано в сркам-гайд, значит так и должно быть, нарушили условия — не получите обещанного прироста производительности».
Хотя, даже «неправильные» реализации скрама по некоторым данным позволяют выполнять задачи на 50-70% быстрее. «Настоящий» скрам обещает как-бы 200-300%, но я пока не увижу — не поверю ))
Может у нас никто не умеет обращаться с ответственностью именно потому, что у нас никто не умеет ее давать? Всмысле, что ответственность то у все давать любят а вот свободу — не очень. Это как в воспитании детей, одни контролируют каждый шаг «не дай бог что случится», другие даже не смотрят на ребенка, говоря «сам никогда и не научится пока сам не упадет, не ушибется не обожгется».
Но все же с моей точки зрения скрам это когда:
— девелоперы сами планируют свое время
— РО не имеет сроки а получает сроки от девелоперов. Если дедлайн ближе — значит нужно уменьшать функциональность (при неизменности команды)
Не зря одним из ярких пунктов в теории скрама — отсутствие тимлидера.
По поводу «послать любого» — для девелопера вообще никого не существует кроме РО и его коллег-девелоперов. Так что посылать просто должно быть некого ))
Вобщем пора отделять мух от котлет. С одной стороны у нас теория и «как по идее должно быть» с другой стороны практика и реальные условия внедрения. Но на мой вопрос «а что в скраме является необходимым требованием, а чем можно пренебречь есть ли гибкость в его теории» ответ был — «Если что-то написано в сркам-гайд, значит так и должно быть, нарушили условия — не получите обещанного прироста производительности».
Хотя, даже «неправильные» реализации скрама по некоторым данным позволяют выполнять задачи на 50-70% быстрее. «Настоящий» скрам обещает как-бы 200-300%, но я пока не увижу — не поверю ))
Ну, в моём случае я просто спрашиваю «сколько вам нужно на то, чтобы сделать „вот это“». А дальше исходя из этого определяется, сколько issue из какого эпика делается в этот спринт.
Нужно сказать, что у нас есть ещё одна специфика, о которой не любят писать. А именно — проектов больше, чем программистов. Таким образом, «вся команда живёт и дышит этой программой» не получается, а получается именно «скедулинг программистов между эпиками разных проектов».
Кстати, есть ещё одна проблема. Скрам предполагает, что итоговым носителем знаний является программист. Другими словами, программист лучше всех остальных знает, как это работает.
А теперь добавьте нашу специфику (инфраструктурные сервисы). Уверены, что программисты лучше сисадминов знают, как именно происходит разбивка диска в исталляторе в LVM в разных видах дистрибутивов? А ведь это важный вопрос при решении как именно кормить оные инсталляторы файлом с ответами (точнее, как его генерировать, как создавать и хранить).
А учить всех программистов всем тонкостям проектов… И зачем нам столько сисадминов, да ещё без опыта работы (сисадмином)?
Нужно сказать, что у нас есть ещё одна специфика, о которой не любят писать. А именно — проектов больше, чем программистов. Таким образом, «вся команда живёт и дышит этой программой» не получается, а получается именно «скедулинг программистов между эпиками разных проектов».
Кстати, есть ещё одна проблема. Скрам предполагает, что итоговым носителем знаний является программист. Другими словами, программист лучше всех остальных знает, как это работает.
А теперь добавьте нашу специфику (инфраструктурные сервисы). Уверены, что программисты лучше сисадминов знают, как именно происходит разбивка диска в исталляторе в LVM в разных видах дистрибутивов? А ведь это важный вопрос при решении как именно кормить оные инсталляторы файлом с ответами (точнее, как его генерировать, как создавать и хранить).
А учить всех программистов всем тонкостям проектов… И зачем нам столько сисадминов, да ещё без опыта работы (сисадмином)?
Ну про знания программистов, я не помню чтобы прям так жестко было. Наоборот постоянно упоминается о том, что нужно работать над распространением знаний между членами команд и разными командами.
С другой стороны скрам говорит, что команда должна уметь справляться с задачей самостоятельно. Т.е. если для выполнения какой-то задачи вот реально нужен сисадмин — значит он должен быть в команде. Хотябы частично.
Если для выполнения задачи требуются какие-то ресурсы или знания извне — я бы включал это в «definition of ready» для user-story. Например если в команде нету UI-дизайнеров, значит все необходимые элементы должны быть предоставлены вместе с задачей. Если требуется какая-то спецификация, разъяснение и т.д. о том, о чем команда понятия не имеет — значит задача не начинается до тех пор, пока соотв. люди эти артефакты не предоставят. Соотв. запрос команда может озвучить РО во время груминг-митинга.
Ну и никто не отменял «пойти спросить» когда команда сталкивается с вопросом вне ее компетенции.
С другой стороны скрам говорит, что команда должна уметь справляться с задачей самостоятельно. Т.е. если для выполнения какой-то задачи вот реально нужен сисадмин — значит он должен быть в команде. Хотябы частично.
Если для выполнения задачи требуются какие-то ресурсы или знания извне — я бы включал это в «definition of ready» для user-story. Например если в команде нету UI-дизайнеров, значит все необходимые элементы должны быть предоставлены вместе с задачей. Если требуется какая-то спецификация, разъяснение и т.д. о том, о чем команда понятия не имеет — значит задача не начинается до тех пор, пока соотв. люди эти артефакты не предоставят. Соотв. запрос команда может озвучить РО во время груминг-митинга.
Ну и никто не отменял «пойти спросить» когда команда сталкивается с вопросом вне ее компетенции.
Ну тут такая проблема, что если сделать всю сисадминскую часть, то в большинстве задач программистам остаётся просто это всё вместе связать кодом.
Звучит так, как-будто у вас слишком много программистов и слишком мало сисадминов ))
Если от сисадмина в задаче больше толку, чем от программиста — значит он там действительно главную роль играть должен.
Если от сисадмина в задаче больше толку, чем от программиста — значит он там действительно главную роль играть должен.
Просто связать все вместе кодом — такая же работа, как и сделать всю сисадминскую часть.
>потому что оказывалось, что часть вещей из недели в неделю лежат несделанными.
То есть PO ставил фичам приоритет все выше и выше, а команда упорно продолжлала делать менее приоритетные задачи? Жесть какая.
То есть PO ставил фичам приоритет все выше и выше, а команда упорно продолжлала делать менее приоритетные задачи? Жесть какая.
Так вот я и спрашиваю, как соотносятся желания команды что-то не делать с желанием PO что-то видеть сделанным.
У вас есть скрам-мастер? Тогда он должен поймать момент «я сделал X, но беру Z, а не Y, потому что так хочу» и напомнить разработчику про приоритеты.
Команда — наемные работники. Делать то, что на самом верху по приоритету — их прямая обязанность, они именно за это деньги получают. Иначе это не скрам, а анархия — каждый делает только то, что ему хочется.
Команда — наемные работники. Делать то, что на самом верху по приоритету — их прямая обязанность, они именно за это деньги получают. Иначе это не скрам, а анархия — каждый делает только то, что ему хочется.
Нам повезло, так получилось, что команда и PO не находятся по разные стороны баррикад. Они сражаются на одной стороне. Задачу обсуждают все и выигрывают, как правило, аргументы. Но у PO есть привилегия, бремя ответственности — выбирать решения между множеством предложенных.
В любом проекте есть гик-вкусное (то, что повышает самооценку) и нудятина, которую кто-то всё равно должен делать. Мне кажется, правильное планирование должно создавать такие условия, чтобы нудятину не оставляли «на потом». Потому что обычно «нудятина» это как раз техническая реализация бизнес-логики (которая не имеет никакого отношения ни к технике, ни к логике), и без которой самые офигенные технические решения не имеют никакого business value,
Испольузем скрам. Я работаю (де-факто) как PO, но у меня несколько иная модель. Я пишу эпики и статьи к ним, а так же детально расписываю как их сделать (с высоты полёта epic'а). Это подвергается design review (неформальному обсуждению как это реально всё-таки делать будем) с командой.
На митинг выносятся уже готовые story для реализации. Смежные story назначаются на одного-двух человек, чтобы сохраняли поток.
При этом:
1) всё-таки не можем избавиться от дедлоков — это когда, например, серверная часть не готова, а человеку в JS больше делать нечего.
2) Плохо сочетается с code review, который может делаться дольше спринта. Что делать пока что думаем.
3) Т.к. issue завязаны в один эпик, то невыполнение хотя бы одного issue приводит к тому, что epic (читай, user story) не выполняется. Вроде бы «почти», но всё ещё нет. В результате у нас ни разу не было, чтобы эпик был выкачен в продакт за неделю работы.
Пока продолжаем отлаживать процесс…
На митинг выносятся уже готовые story для реализации. Смежные story назначаются на одного-двух человек, чтобы сохраняли поток.
При этом:
1) всё-таки не можем избавиться от дедлоков — это когда, например, серверная часть не готова, а человеку в JS больше делать нечего.
2) Плохо сочетается с code review, который может делаться дольше спринта. Что делать пока что думаем.
3) Т.к. issue завязаны в один эпик, то невыполнение хотя бы одного issue приводит к тому, что epic (читай, user story) не выполняется. Вроде бы «почти», но всё ещё нет. В результате у нас ни разу не было, чтобы эпик был выкачен в продакт за неделю работы.
Пока продолжаем отлаживать процесс…
А что происходит если из-за неверного планирования для некоторого сотрудника спринт по факту завершился раньше чем через две недели? Ему делают новый мини спринт? Или же он просто ждет остальных?
Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи.
Это противоречит крайне полезному принципу коллективного владения кода.
Для этого необходимо написать тесты, в которых будет детально описано то, что считать достижением требования. Просто говоря, в них описано то, на какую кнопку нажать, и что при этом получится. В команде тесты пишут аналитики.
Здесь речь идет о функциональных требованиях или об автоматизированных тестах? Расскажите подробнее.
Кодом владеют все и каждый может заменить другого. Но глубина владения кодом у каждого разная. И есть один, кто в данный момент владеет модулем. Его глубина погружения в детали выше всех. Значит он аргументированно может лучше оценить разработку. Если ему сильно кто — то возражает и говорит, что сделает быстрее, его ответ, как правило, простой:«Делай».
Выше речь шла, конечно о функциональных требованиях. Аналитики описывает их, и часто вместе с остальной командой и PO. В них описывается результат, который надо предъявить в конце спринта.
Выше речь шла, конечно о функциональных требованиях. Аналитики описывает их, и часто вместе с остальной командой и PO. В них описывается результат, который надо предъявить в конце спринта.
Обычно в конце спринта сдача происходит в виде демонстрации работающего кода, а не рассказа о том, кто что сделал/не сделал. Почему у вас только рассказы? Почему отказались от демо?
Видимо я не правильно выразился. Происходит демонстрация функциональных требований, которые были описаны аналитиками и взяты разработчиками в работу. И тут же происходит анализ и, если надо, корректировка требований на следующий спринт. Это все сопровождается рассказом программиста:«Я на этом спринте реализовывал вот эту задачу» Идет демонстрация и одновременное обсуждение.
Митинги проводить желательно стоя...Митинг? А как насчёт утренней забастовки?
Вы как то мимо темы…
А, по-моему, прямо в тему.
Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня.
Слепое следование методологии разработки к добру не приводит. По личному опыту скажу, что два дня на планирование — это черезвычайный перебор. Один час — максимум.
Слепое следование методологии разработки к добру не приводит. По личному опыту скажу, что два дня на планирование — это черезвычайный перебор. Один час — максимум.
Кроме скрама что-то пробовали? Постоянно сталкиваюсь с тем, что скрам оказывается слишком тяжелым фреймворком для небольших команд, и с него радостно слезают на что-нибудь менее формальное.
— в конце спринта отдаете протестированный продук?
— тестеры имеют возможность протестировать все разработанные фичи в рамках одного тестового цикла, а не по частям?
— отдаете продукт в пятницу в 4, а когда начинаете последний тестовый цикл? У девелоперов есть возможность пофиксить баги, напйденные тестерами, до 4:00 вечера пятницы?
— тестеры имеют возможность протестировать все разработанные фичи в рамках одного тестового цикла, а не по частям?
— отдаете продукт в пятницу в 4, а когда начинаете последний тестовый цикл? У девелоперов есть возможность пофиксить баги, напйденные тестерами, до 4:00 вечера пятницы?
Тоже перехожу на scrum с водопада.
Спасибо за интересную статью и не менее интересные комментарии.
Теоретические моменты все понятны, но наблюдая за реальным опытом команд возникает ощущение «мой скрам лучше твоего».
Пока не видел ни одной команды, которая работала бы в полном соответствии со «стандартом», поэтому можно говорить именно о выстраивании процесса на основе scrum и в данном случае, реальный опыт крайне полезен для сравнения и понимания.
Некоторые вопросы (интересует именно реальный опыт команд), которые возникают, при попытке примерить процесс на себя:
— Насколько плотно у вас заказчик вовлечен в процесс? Присутствует ли он при обсуждении и сдаче спринтов?
— Как вписывается в процесс ревью кода и тестирование? В долгосрочном проекте фичу нельзя считать законченной, пока она не протестирована и ее код не принят.
— Есть ли у кого-то еще опыт разработки по TDD в рамках scum? Здесь говорится, что тесты пишут аналитики и до старта спринта. Мне кажется, что спринт — это целостная единица, в течении которой должны быть выполнены все работы по user story, а тесты должен писать сам разработчик. Или в рамках user story создается несколько задач (написать тест, запрограммировать, протестировать,..) и каждая из них может браться в разный спринт? Как же тогда демонстрировать такие задачи? Мне кажется, будут возникать те же проблемы, что и при водопаде — проблемы вслывают в самом конце, в результате чего и получаем 90% + еще 90% работы.
— Есть ли у кого-то личный опыт ведения процесса через Redmine? Используются ли какие-то плагины (можете посоветовать) или процесс ведется на доске, а задачи в Redmine?
— Есть ли реально практикующие недельные спринты? У меня такое же ощущение, что недели для полного цикла (постановка задачи, покрытие тестами, программирование, тестирование) мало, согласен в этом вопросе с автором, но часто вижу упоминания именно о недельных спринтах.
— Как у вас реализуется тестирование? Тестируется весь спринт целиком по завершении или каждый таск отдельно?
— Часто слышу, что брать в спринт больше задач, чем можно реально сделать — это нормально. В принципе, смысл в этом есть. Или же лучше брать меньше, но зато делать все в срок? Но как тогда быть с требованием не менять состав спринта в течение его разработки?
Спасибо за интересную статью и не менее интересные комментарии.
Теоретические моменты все понятны, но наблюдая за реальным опытом команд возникает ощущение «мой скрам лучше твоего».
Пока не видел ни одной команды, которая работала бы в полном соответствии со «стандартом», поэтому можно говорить именно о выстраивании процесса на основе scrum и в данном случае, реальный опыт крайне полезен для сравнения и понимания.
Некоторые вопросы (интересует именно реальный опыт команд), которые возникают, при попытке примерить процесс на себя:
— Насколько плотно у вас заказчик вовлечен в процесс? Присутствует ли он при обсуждении и сдаче спринтов?
— Как вписывается в процесс ревью кода и тестирование? В долгосрочном проекте фичу нельзя считать законченной, пока она не протестирована и ее код не принят.
— Есть ли у кого-то еще опыт разработки по TDD в рамках scum? Здесь говорится, что тесты пишут аналитики и до старта спринта. Мне кажется, что спринт — это целостная единица, в течении которой должны быть выполнены все работы по user story, а тесты должен писать сам разработчик. Или в рамках user story создается несколько задач (написать тест, запрограммировать, протестировать,..) и каждая из них может браться в разный спринт? Как же тогда демонстрировать такие задачи? Мне кажется, будут возникать те же проблемы, что и при водопаде — проблемы вслывают в самом конце, в результате чего и получаем 90% + еще 90% работы.
— Есть ли у кого-то личный опыт ведения процесса через Redmine? Используются ли какие-то плагины (можете посоветовать) или процесс ведется на доске, а задачи в Redmine?
— Есть ли реально практикующие недельные спринты? У меня такое же ощущение, что недели для полного цикла (постановка задачи, покрытие тестами, программирование, тестирование) мало, согласен в этом вопросе с автором, но часто вижу упоминания именно о недельных спринтах.
— Как у вас реализуется тестирование? Тестируется весь спринт целиком по завершении или каждый таск отдельно?
— Часто слышу, что брать в спринт больше задач, чем можно реально сделать — это нормально. В принципе, смысл в этом есть. Или же лучше брать меньше, но зато делать все в срок? Но как тогда быть с требованием не менять состав спринта в течение его разработки?
коэффициент, который называется производительностью команды
У нас это коэффициент называется фокус фактор и туда учитывается не только производительность команды, так же учитывается время на устранение аварий по действующим проектам.
Но, если вернуться к коэффициенту производительности команды, как вы его считаете?
У нас это коэффициент называется фокус фактор и туда учитывается не только производительность команды, так же учитывается время на устранение аварий по действующим проектам.
Но, если вернуться к коэффициенту производительности команды, как вы его считаете?
По Scrum у нас есть подробный кейс, где мы говорим про наш опыт и фишки, вроде «Рыбного четверга». Предлагаю обсуждать в комментариях. www.carrotquest.io/blog/kak-organizovat-rabotu-komandy-opyt-metodologii-scrum-v-carrot-quest
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum — реальный опыт работы по методологии