кто-нить работает по scrum'у?
Пока такие, но у меня пока мало практики.
Я работаю.
Впечатления самые положительные. Одна проблема - SCRUM хорошо работает только когда нет дедлайнов. Как только бизнес начинает диктовать сроки - скраму приходит хана.
Впечатления самые положительные. Одна проблема - SCRUM хорошо работает только когда нет дедлайнов. Как только бизнес начинает диктовать сроки - скраму приходит хана.
какая у вас продолжительность одного спринта, сколько человек в команде?
команд много, в среднем размер команды - 4-5 человек, спринт обычно неделя, редко - 2 недели
Одна проблема - SCRUM хорошо работает только когда нет дедлайновв каких проектах нет дедлайнов? как можно что-то планировать без сроков? можно подробнее осветить тему?
Сроки могут появляться в результате анализа возможностей команды (примерно оцениваем сложность задач, необходимых для релиза, и таким образом оцениваем срок релиза. А еще сроки могут появляться в связи с бизнес-потребностями (предстоящая конференция, отчет перед инвесторами, IPO и тд и тп и тогда, вне зависимости от реальных возможностей команд, список задач, которые надо решить к релизу, формируется именно исходя из потребностей мероприятия, и сроки тоже привязаны к мероприятию. И тут очевидно скрам мгновенно исчезает, начинается кодерство "лишь бы успеть".
спасибо
я очень плохо ориентируюсь в скраме, но разве короткие спринты (неделя) не позволяют грамотно подстраиваться под новые требования (IPO, конференции и тд не так уж внезапно появляются) ? ведь суть agile именно в возможности адаптироваться к изменяющимся условиям (и срокам в том числе)
кстати, рефакторинг меня тоже интересует - он является целью спринта ? судя по вики в плане отражены лишь юзерские запросы, то бишь конкретная функциональность. или на рефакторинг просто поправка сроков идет? кто у вас такой добрый и выделяет время на рефакторинг ?:)
я очень плохо ориентируюсь в скраме, но разве короткие спринты (неделя) не позволяют грамотно подстраиваться под новые требования (IPO, конференции и тд не так уж внезапно появляются) ? ведь суть agile именно в возможности адаптироваться к изменяющимся условиям (и срокам в том числе)
кстати, рефакторинг меня тоже интересует - он является целью спринта ? судя по вики в плане отражены лишь юзерские запросы, то бишь конкретная функциональность. или на рефакторинг просто поправка сроков идет? кто у вас такой добрый и выделяет время на рефакторинг ?:)
Проблема заключается в основном в том, что в условиях цейтнота начальство просто не хочет знать реальных оценок, которые может выдать им команда. Потому что они примерно представляют себе, что успеть, вообще говоря, обычно нереально. Поэтому они ставят сроки сами, сильно их занижая, а это уже совсем не скрам. И команда работает вечерами/в выходные, команде некогда проводить скрам-мероприятия, некогда рефакторить, и качество принимаемых решений оставляет желать лучшего (грубо говоря, ставятся "костыли", лишь бы работало к дедлайну). Это перестает быть скрамом. Если бы руководство продолжало придерживаться скрама, код был бы лучше, но успели бы меньше.
Насчет рефакторинга. Обычно у команд, работающих по скраму, есть такой коэффициент, который называется "фокус-фактор". Он описывает, какой процент рабочего времени команда способна посвятить именно написанию кода в рамках задач спринта. Обычно он бывает 0.5-0.7, что означает, что из 8 рабочих часов человек непосредственно программированию по своим задачам посвящает 4-5,5 часов. Остальное - решение рабочих вопросов, анализ, проектирование, чай-кофе-покурить, рефакторинг и прочее.
Кроме того, на планировании команда может сказать владельцу продукта, что данная задача за собой повлечет рефакторинг уже сделанного кода (например, чтобы заюзать имеющийся код, или сменить архитектуру). Тогда время на задачу увеличивается. Либо можно в данном спринте сделать задачу быстро, а на следующий спринт вбросить задачу по рефакторингу обеих задач (старой и новой).
Насчет рефакторинга. Обычно у команд, работающих по скраму, есть такой коэффициент, который называется "фокус-фактор". Он описывает, какой процент рабочего времени команда способна посвятить именно написанию кода в рамках задач спринта. Обычно он бывает 0.5-0.7, что означает, что из 8 рабочих часов человек непосредственно программированию по своим задачам посвящает 4-5,5 часов. Остальное - решение рабочих вопросов, анализ, проектирование, чай-кофе-покурить, рефакторинг и прочее.
Кроме того, на планировании команда может сказать владельцу продукта, что данная задача за собой повлечет рефакторинг уже сделанного кода (например, чтобы заюзать имеющийся код, или сменить архитектуру). Тогда время на задачу увеличивается. Либо можно в данном спринте сделать задачу быстро, а на следующий спринт вбросить задачу по рефакторингу обеих задач (старой и новой).
Работаем. Если вкратце: Скрум - это современная схема развода заказчиков на бесконечный бюджет. Недаром все разработчики очень любят Скрум.
Проблема заключается в основном в том, что в условиях цейтнота начальство просто не хочет знать реальных оценок, которые может выдать им команда. Потому что они примерно представляют себе, что успеть, вообще говоря, обычно нереально. Поэтому они ставят сроки сами, сильно их занижая, а это уже совсем не скрам.значит, проблема не в скраме, а в начальстве?
мне интересно послушать про скрам, какие плюсы и минусы люди встречают в жизни при следовании данной методологии, какие отступления от методологии делают для достижения бизнес-сроков\качества.
финишный спурт перед релизом - обычная (возможно, порочная) практика во многих конторах. по своей конторе сужу - люди, который пашут все лето с переработками увольняются после релиза в большом количестве, перегорают. у нас начальство идет на жертвы - отрезают фичи, все к этому привыкли. Поэтому, возможно, дело не в процессе, а в компромиссах между людьми.
зы: меня пригласили в компанию со скрамом, а я с ним не знаком. вот расширяю кругозор =)
я не ТС
для себя как для разработчика я решил, что работа в скраме гораздо приятнее, чем обычная разработка. я даже на курсы скрам-мастеров ходил и получил сертификат 
за 25 штук который?
ты сам организуешь процесс или ты на курсы для саморазвития ходил?
ты сам организуешь процесс или ты на курсы для саморазвития ходил?
могу сам организовать
Как только бизнес начинает диктовать сроки — скраму приходит хана.Я, конечно, в секте агилистов не состоял, но разве бывает бизнес без сроков?
да, это так называемый SERIOUS BUSINESS!
>>Я, конечно, в секте агилистов не состоял, но разве бывает бизнес без сроков?
Есть пул задач, а точнее пул сетов задач. Команда говорит какие сеты(проекты) сколько займут примерно времени, после чего выбирает исходя из ограничений следующий "сет" из пула и декомпозирует его, оценивая уже более подробно.
То есть команда говорит за какое время может предоставить решение, а начальство исходя из этого может принять решение, что надо может быть урезать функционал или отложить вовсе сет, если все необходимое сделать не успеваем.
Если необходимого доверия команде нет и не ожидается, тогда и скраму места нет.
Есть пул задач, а точнее пул сетов задач. Команда говорит какие сеты(проекты) сколько займут примерно времени, после чего выбирает исходя из ограничений следующий "сет" из пула и декомпозирует его, оценивая уже более подробно.
То есть команда говорит за какое время может предоставить решение, а начальство исходя из этого может принять решение, что надо может быть урезать функционал или отложить вовсе сет, если все необходимое сделать не успеваем.
Если необходимого доверия команде нет и не ожидается, тогда и скраму места нет.
А без всяких умных слов разве не понятно, что если ставится задача и команда говорит, что будет делать её 2 месяца, а надо сделать за месяц, то нужно функционал урезать?
Без доверия вообще не получится работать.
Без доверия вообще не получится работать.
Девелоперам понятно и без умных слов, руководству непонятно даже с умными словами.
ну тут уже нужно придумывать что делать — нанимать сотрудников, фрилансеров, работать без выходных (но такое не делается более одного раза самое простое — сказать что всё будет, а потом запросить дополнительно сроки / бюджет.
А без всяких умных слов разве не понятно, что если ставится задача и команда говорит, что будет делать её 2 месяца, а надо сделать за месяц, то нужно функционал урезать?Разница в том, что в одном случае команда говорит что успеет сделать, а в другом начальство говорит что команда должна успеть.
Насчет доверия - полно таких контор, причем не только в случае аутсорса. Вопрос только в том о каком уровне доверия речь.
Подпишусь под всеми твоими словами.
Было три попытки реализвать нормальный скрум. Через определённое время (пол-года примерно) начальство начинало ставить невозможные сроки и вообще всячески давить, и система разваливалась.
Лично я для себя решил что это из-за явного нежелания бизнес-руководства тратить время на рефакторинг и "вообще слишком вы много болтаете. Вы должны код писать под наши бизнес задачи".
Ещё убийцей скрума является "любитель попиздеть на ретроспективе" Кто знает тот поймёт
Было три попытки реализвать нормальный скрум. Через определённое время (пол-года примерно) начальство начинало ставить невозможные сроки и вообще всячески давить, и система разваливалась.
Лично я для себя решил что это из-за явного нежелания бизнес-руководства тратить время на рефакторинг и "вообще слишком вы много болтаете. Вы должны код писать под наши бизнес задачи".
Ещё убийцей скрума является "любитель попиздеть на ретроспективе"
Кто знает тот поймётБыло три попытки реализвать нормальный скрум.и на чем вы остановились? каким образом взяли процесс в узду?:)
Я неправильно выразился. Имел ввиду что процесс шёл нормально и успешно, но в опредлеённый момент скрум разваливался из-за требований бизнес-руководства
понял
в общем, из всего сказанного попробую сделать для себя выводы: впечатления положительные от процесса. то есть есть предсказуемость прогресса, есть обратный контакт с клиентом, есть тесное взаимоотношение между членами команды, все в курсе всего происходящего, адаптация (хотя и запоздалая) к измененным требованиям. однако процесс не позволяет выполнить больше задач за одно и то же время видимо, это и раздражает руководство
однако я не понимаю фундаментальных вещей - что же от процесса ждут? какие-то гарантии по каким критериям? качесвтенное планирование? отсутствие регрессий (скрам ничего не гарантирует)? имплемент большого числа фич? больше денег получить? меньше времени потратить на реализацию и побольше на болтовню?
в общем, из всего сказанного попробую сделать для себя выводы: впечатления положительные от процесса. то есть есть предсказуемость прогресса, есть обратный контакт с клиентом, есть тесное взаимоотношение между членами команды, все в курсе всего происходящего, адаптация (хотя и запоздалая) к измененным требованиям. однако процесс не позволяет выполнить больше задач за одно и то же время
видимо, это и раздражает руководствооднако я не понимаю фундаментальных вещей - что же от процесса ждут? какие-то гарантии по каким критериям? качесвтенное планирование? отсутствие регрессий (скрам ничего не гарантирует)? имплемент большого числа фич? больше денег получить? меньше времени потратить на реализацию и побольше на болтовню?
Вообще, на мой взгляд, скрам - технология разработки придуманная программистам и для программистов.
Потому как:
1) Удобно. Ты сам назначаешь срок, выбираешь себе задачу.
2) Комфортно. Ты совсем абстрагирован от заказчика. Он не влияет на тебя вообще в спринте.
3) Можно быстро отпинывать начальство показывая ему графики и двигающиеся листочки
4) Можно и нужно рефакторить в своё удовольствие
Потому как:
1) Удобно. Ты сам назначаешь срок, выбираешь себе задачу.
2) Комфортно. Ты совсем абстрагирован от заказчика. Он не влияет на тебя вообще в спринте.
3) Можно быстро отпинывать начальство показывая ему графики и двигающиеся листочки
4) Можно и нужно рефакторить в своё удовольствие
что же от процесса ждут?
Что в скраме удобно для "заказчика"-Product Owner'a - что скрам позволяет гибко изменять скоуп девелопмента, позволяя раз в итерацию (спринт) поставлять завершенные кусочки продукта, имеющие business value. При налаженной процедуре ежедневных сборок это позволяет раз в итерацию иметь полностью работающий продукт, и с бОльшей функциональностью, чем после предыдущей итерации. То есть теоретически можно остановиться после каждого очередного спринта, имея продукт, который готов к поставке конечному заказчику. Причем какой именно скоуп будет готов к какому числу - можно довольно хорошо предсказать, следя за динамикой итогов итераций.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
Проблемы начинаются, когда высшее руководство ломает скрам, ставя требования типа "быстро, качественно и дешево", которые, как известно, в каждый момент времени выполнимы не больше, чем на две трети. Надо понимать, что никакой процесс этих требований с должной надежностью не обеспечит, и скрам не исключение.
Если руководство принимает скрам и работает "в нем", то при появлении дедлайнов оно
1) либо останавливает девелопмент (до того, как готовы все запланированные фичи, при этом несделанными остаются самые низкоприоритетные фичи)
2) либо сдвигает дедлайн в будущее, если какие-то из еще не сделанных фич обязательно должны войти в поставку
Третий вариант, о котором тут пишут ("успеть больше за те же сроки") по сути означает
1) либо жертвование качеством, что выражается сокращении реальных сроков выполнения фичи по сравнению с запланированными, за счет вырезания рефакторинга, ненаписания юнит тестов, сокращения тестирования и т.п.
2) либо сверхурочные, общий burnout команды, что тоже в какой-то момент приводит к жертвованию качеством
В любом случае, третий вариант - это уже не скрам.
В общем, это все уже было озвучено так или иначе, скрам - просто один из процессов разработки (вообще говоря, чего угодно, не только программных продуктов). Имеет много плюсов в современном мире, но все-таки не волшебный.
2) Комфортно. Ты совсем абстрагирован от заказчика. Он не влияет на тебя вообще в спринте.Нас учили, что Скрам-мастер все-таки может менять скоуп спринта по ходу самого спринта, но это считается исключительным случаем. Например, принять решение резко оборвать разработку одной фичи и накинуться на другую, если приоритеты заказчика неожиданно поменялись.
В этом случае заказчик как бы все-таки влияет на команду, но опосредованно, через скрам мастера.
В любом случае, третий вариант - это уже не скрам.спасибо, это очень полезно, что подразумевается под скрамом, а что выбивается из него
не очень ясно по поводу инкремента продукта после спринта. ведь бывает, что требования настолько меняются, что уже сделанное приходится выкидывать. есть ли кто-то, кто берет ответственность за непродуктивный девелопмент? бывает, что при обсуждение видится один вариант развития. после имплемента приходит понимание, что надо наоборот сделать. а еще это часто всплывает в процессе девелопмента. можно ли тогда в течение спринта затребовать изменение требований?
ведь бывает, что требования настолько меняются, что уже сделанное приходится выкидывать. есть ли кто-то, кто берет ответственность за непродуктивный девелопмент?Не очень поняла, если требования поменял заказчик, то девелопмент как-то рука не поворачивается назвать непродуктивным. Если идет разработка, а заказчик говорит "хочу по-другому", то это как раз пример того, как скрам мастер может по ходу итерации изменить скоуп. В любом случае, до этого момента "внешнего изменения требований" продукт максимально близок к состоянию готового к поставке, с некоторым процентом содержания запланированных фич.
Если изменение требований внутреннее и очень существенное, например, сами поняли, что сделать так, как хотелось раньше, не получится и надо делать по-другому, то... Как я понимаю, это опять же не совсем штатная ситуация, команда должна дать об этом знать скрам мастеру и он примет решение, как именно уложить изменение курса в остаток этой и следующую итерацию. Например, остаток этой посвятить исследованию нового подхода (proof of concept, pilot а начиная со следующей уже пытаться снова делать готовый кусочек, но по новому плану. Мне кажется, общего рецепта, что именно он сделает, тут нет - все зависит от конкретной команды и продукта.
Конечный итог этой ситуации - "сдвиг" от запланированного графика девелопмента в сторону опоздания. Что можно делать в этом случае- см. мой пост выше :)
Если же такие внутренние изменения курса часты, то это, мне кажется, признак либо большой нестабильности продукта, либо глубокого незнания его членами команды... Тогда тоже можно подгонять под процедуру скрама следующие цели на итерацию: провести исследование, сделать pilot. Это по сути стабилизация продукта-команды, которае не приведет к поставке готового кусочка за одну итерацию, но, со временем, начнет приводить.
Если внутренние изменения курса небольшие, то, мне кажется, они как раз являются обычным делом, но они и не вызывают быльших изменений в планах - конечной цели итерации должно быть можно достичь и с небольшими изменениями в тонкостях реализации, о которых никому извне знать и не надо.
Важно: никогда не нужно планировать 100% итерации. Обычно советуют планировать ~70%, остальное как раз уходит на небольшие погрешности в эстимациях.
есть ли кто-то, кто берет ответственность за непродуктивный девелопмент?да, это скрам мастер.
можно ли тогда в течение спринта затребовать изменение требований?если совсем не получается сделать то, что просил заказчик, то это забота Product Owner'а - договориться с ним о новых условиях.
если имеется в виду, что не получается выполнить цель итерации - ну, это тоже дело житейское. у нас, например, процент успешно завершенных задач в каждую итерацию далеко не 100% :)
От членов команды процесс на самом деле требует одного:
каждый день на daily scrum meeting уметь отвечать, успевают ли они завершить задачу, взятую в итерацию, и если нет, то что мешает.
Скрам мастер это все слушает и, по необходимости, корректирует курс.
Если, например, становится понятно, что все задачи итерации команда выполнить не успевает, то он напоминает, какие из них наиболее приоритетные, и все команда переключается на них. Цель всегда такая: к концу итерации иметь максимальное число полностью сделанных задач-"фич". Команда сама вольна распределять между ними усилия. То есть иметь одну завершенную фичу к концу итерации лучше, чем три "почти сделанных". Потому что в первом случае готова 1 фича, во втором - 0.
Ну, надо сказать, я сама этот подход с трудом принимаю. Иногда (чаще всего!) кажется, что гораздо проще работать параллельно над несколькими задачами, в эту итерацию не завершить ни одной, зато в следующую завершить все. Но это опасный подход, потому что может мне кажется, что я в следующей все завершу, а на самом деле - нет. С точки зрения предсказуемости разработки всегда лучше избегать мультитаскинга и концентрироваться на чем-то одном. Как в масштабах одного человека, так и в масштабах команды.
Насколько будут "иметь" за недоделанные задачи - у каждого по-своему, наверное. Мне кажется мудрым, когда никто не "имеет" вовсе, а учитывает предыдущие ошибки при планировании следующих итераций. А главное, помогает команде их осознать и учитывать. Для того и нужна ретроспектива.
Очень многое зависит от скрам мастера короче. Потому что сама команда обычно ленится следить за соблюдением процесса и скатывается во всякие "подобия скрама", в которых основные атрибуты скрама не выполняются (например, перестают проводить дейли-скрамы или занимаются мультитаскингом, или каждый занимается своим кусочком, вместо того, чтобы всем накинуться на одну задачу и доделать ее к концу итерации).
Короче, из того, что я перечислила, довольно много моментов, которые не нравятся, а раздражают девелоперов :) И, если их предоставить самим себе, они будут пытаться скатиться в привычные рельсы программирования так, как удобно каждому из них. Но если есть понимание, зачем это все нужно в общей картине, остальное - имхо, дело привычки. Пинки скрам мастера в этом плане помогают.
что подразумевается под скрамом, а что выбивается из негоКак пример: одним из атрибутов скрама является то, что команда сама определяет сроки разработки с учетом всех вещей, которые, в ее понимании, необходимы для здорового продукта: рефакторинг, юнит тесты, прочие тесты и т.д. Эти сроки, конечно, могут подлежать обсуждению с Продукт Оунером и корректироваться в связи с требованиями "сверху". Например, эта фича нужна всего для одного заказчика, поэтому мы там реализуем самую общую функциональность и проведем самое общее тестирование, в итоге на фичу планируется меньше времени, чем изначально. Но в любом случае это диалог с командой и команда, исходя из требований Продукт Оунера, сама определяет, сколько времени ей нужно, чтобы покрыть эти требования.
Если кто-то (руководство) навязывает команде свои сроки - атрибут не выполняется, следовательно, это уже не скрам.
Полный список атрибутов выложу, когда приду домой (с)
спасибо за подробные ответы
буду вникать
буду вникать
спасибо за подробные ответыАга, спасибо. Я узнал что оказывается я скрам-мастер!
Ага, спасибо. Я узнал что оказывается я скрам-мастер!Угу, а через год еще одно умное слово вспомнят или придумают. И обязательно сертифицируют!
сделал сегодня реюзбл burn-down diagram.
Подложка-пробковая доска. На ней два листа миллиметровки (одного в ширину не хватило). Приколоты пинами.
Белые кругляши внизу - из картона из под упаковки от мак-мини. (на самом деле просто гладкий картон). На них маркерами для доски можно писать числа месяца. Кругляши тоже реюзаются. Легко стереть и написать другое число.
Изначально проблема была какая? Путаница с выходными. Кругляшами отметил начало и конец спринта, а также начало каждой недели.
Для рисования графиков используются проводки от четырехжильного телефонного кабеля (в офисе нашелся моток, доставшийся по наследству от колцентра).
Наматываются вокруг пинов и отлично держатся. Тут решает пробковая доска - в ней пины крепко стоят и не болтаются.
К концу черного проводка приделан грузик. В итоге можем удобно смотреть какой сегодня день спринта считай от начала, какое число и какой день недели (для этого нужно посчитать количество клеток до ближайшего белого кругляша).
Минусы: (нашей команде эти ограничения не мешают)
максимальная продолжительность спринта три недели.
Максимальное количество скорепоинтов 35. Но можно рядом другую шкалу нарисовать - более мелкую.
В данный момент диаграмма отображает то состояние, в котором она будет находиться утром в понедельник.
Подложка-пробковая доска. На ней два листа миллиметровки (одного в ширину не хватило). Приколоты пинами.
Белые кругляши внизу - из картона из под упаковки от мак-мини. (на самом деле просто гладкий картон). На них маркерами для доски можно писать числа месяца. Кругляши тоже реюзаются. Легко стереть и написать другое число.
Изначально проблема была какая? Путаница с выходными. Кругляшами отметил начало и конец спринта, а также начало каждой недели.
Для рисования графиков используются проводки от четырехжильного телефонного кабеля (в офисе нашелся моток, доставшийся по наследству от колцентра).
Наматываются вокруг пинов и отлично держатся. Тут решает пробковая доска - в ней пины крепко стоят и не болтаются.
К концу черного проводка приделан грузик. В итоге можем удобно смотреть какой сегодня день спринта считай от начала, какое число и какой день недели (для этого нужно посчитать количество клеток до ближайшего белого кругляша).
Минусы: (нашей команде эти ограничения не мешают)
максимальная продолжительность спринта три недели.
Максимальное количество скорепоинтов 35. Но можно рядом другую шкалу нарисовать - более мелкую.
В данный момент диаграмма отображает то состояние, в котором она будет находиться утром в понедельник.
а я все собираюсь поставить отдельный здоровый монитор под эту штуку
монитор не катит. пины же очень круто перетыкать. и отдыхать от компов!
это сравнимо с переклеиванием тикетов! правда мы отказались от этого. тоже прикалываем их булавками
ну изначально в левой колонке - на листочек с задачей мы их приклеиваем, но когда передвигаем их направо, то уже прикалываем. как-то хреново они переклеиваются. может стикеры есть более качественные. хз
это сравнимо с переклеиванием тикетов! правда мы отказались от этого. тоже прикалываем их булавками
ну изначально в левой колонке - на листочек с задачей мы их приклеиваем, но когда передвигаем их направо, то уже прикалываем. как-то хреново они переклеиваются. может стикеры есть более качественные. хз
сегодня был на тренинге от scrumtreka с Сергеем Дмитриевым, завтра второй день.
зы: треть аудитории составляли девелоперы из яндекса (человек 6-7 говорят, что 2 месяца практикуют, собираются углубляться, 2-3 из интелла
зы: треть аудитории составляли девелоперы из яндекса (человек 6-7 говорят, что 2 месяца практикуют, собираются углубляться, 2-3 из интелла
сегодня был на тренингекруто, я тоже хочу
что-то цена на сайте кусается
что-то цена на сайте кусаетсяну что-то мне подсказывает, что за свои кровные туда никто и не идёт
ну а так-то там всё на высшем уровне, хороший обед, неизмеримое число печенек, конфеток)
но таких денег, конечно, не стоит
хотя, я так понимаю, день работы этого мужика очень не хреново оплачивается, коачит по всему свету
ну вот, сегодня в полку scrum-мастеров прибыло
задавайте вопросы, какие есть, пообсуждаем с пылу с жару)
задавайте вопросы, какие есть, пообсуждаем с пылу с жару)
задавайте вопросы2 или 3 недели?
разрешены ли хиханьки-хаханьки на ретроспективе?
если графики начинают сильно болтаться между 2 и 3 неделью, следует ли отсюда, что лучше все же 2 недели? или с опытом грамотное планирование придет и графики придут в норму? жира с плагином - УГ или вполне не тормозит?:)
надо делать scrum ради команды, так как ей удобнее, она должна сама всё определять, быть самоорганизованной
"хиханьки-хаханьки" конечно, в разумных пределах, должен же народ расслабляться и создавать дружекскую обстановку в Команде
по поводу 2 и 3 неделей, я так понимаю, что речь идёт о Burndown диаграмме, дак вот, тут встречный вопрос - как вы отмечаете прогресс по user story или по tasks?
конечно, всё придёт с опытом, хорошо бы к 5-7 спринту)
по поводу джиры - если команда не распределённая, то лучше отказаться от всяких тулзов, использовать карточки и доску, выше был отличный вариант, который я думаю взять за основу
"хиханьки-хаханьки" конечно, в разумных пределах, должен же народ расслабляться и создавать дружекскую обстановку в Команде
по поводу 2 и 3 неделей, я так понимаю, что речь идёт о Burndown диаграмме, дак вот, тут встречный вопрос - как вы отмечаете прогресс по user story или по tasks?
конечно, всё придёт с опытом, хорошо бы к 5-7 спринту)
по поводу джиры - если команда не распределённая, то лучше отказаться от всяких тулзов, использовать карточки и доску, выше был отличный вариант, который я думаю взять за основу
"хиханьки-хаханьки" конечно, в разумных пределах, должен же народ расслабляться и создавать дружекскую обстановку в Команденашли где расслабляться, но ок
по поводу 2 и 3 неделей, я так понимаю, что речь идёт о Burndown диаграмме, дак вот, тут встречный вопрос - как вы отмечаете прогресс по user story или по tasks?хз, я новичок. меня в первый спринт в пнд запишут
конечно, всё придёт с опытом, хорошо бы к 5-7 спринту)уже 11 спринт
по поводу джиры - если команда не распределённая, то лучше отказаться от всяких тулзов, использовать карточки и доску, выше был отличный вариант, который я думаю взять за основу[/quote]распределенная. просто на первый взгляд жира тормозит сильно
нашли где расслабляться, но окну это зависит от уровня команды Shu-Ha-Ri, вообще на становление команды уходит примерно полгода (если никого не забирать и не добавлять).
уже 11 спринтесли веб-проект, лучше 2 недели, но если команда не научилась планировать к 11 спринту - вопросов возникает масса, либо её часто мешают (что можно судить по тому, что тебя подключают к 12ому спринту либо люди просто не понимают, что делают в полном спектре. Как у вас работает Product Owner?
если веб-проект, лучше 2 недели, но если команда не научилась планировать к 11 спринту - вопросов возникает масса, либо её часто мешают (что можно судить по тому, что тебя подключают к 12ому спринту либо люди просто не понимают, что делают в полном спектре. Как у вас работает Product Owner?вообще это зона ответственности как раз скрам-мастера, он не может подтолкнуть команду к самоорганизованности, стоит задаться вопросами:
"почему мы не укладываемся, из-за чего такое шатание на третьей неделе?"
"а не удобней ли нам будет сделать спринты по 2 недели?"
"не стоит ли нам делать более пессимистичный оценки?"
вообще сделаю предположение, что Burndown у вас провисает из-за того, что вы меряете task'ами, а не user story'ями, в этом случае в первую очередь делаются лёгкие таски, что естественно укладывается в срок, а когда начинаются сложные - всё виснет, отмечайте завершённость не тасков, а фичей, тогда будете видеть реальную картину (ведь даже если по фиче готовы 99 тасков из 100, то она не готова и не имее бизнес-ценности)
ну это зависит от уровня команды Shu-Ha-Ri, вообще на становление команды уходит примерно полгода (если никого не забирать и не добавлять).что за странная команда? не надо меня интеллектом давить!
если веб-проект, лучше 2 недели, но если команда не научилась планировать к 11 спринту - вопросов возникает масса, либо её часто мешают (что можно судить по тому, что тебя подключают к 12ому спринту либо люди просто не понимают, что делают в полном спектре.не веб. ну у меня и возник вопрос, но уверяют, что "практика показала, что 3 недели - это супер, а 2 недели - не супер"
Как у вас работает Product Owner?к сожалению, пока не в курсе кто это и что он делает
поживем - увидим
спасибо
возможно тут подойдёт практика из kanbana - ограничить число фичь в In Progress, скажем, две - тогда пока они не будут добиты - за новые команда не возьмётся
не веб. ну у меня и возник вопрос, но уверяют, что "практика показала, что 3 недели - это супер, а 2 недели - не супер"по-моемому, в вашем случае практика как раз показывает обратное
Оставить комментарий
Happysad
поделитесь впечатлениями