Однако примите во внимание, что дальнейшее рассмотрение JIRA, как инструмента управления проектами, основывается на Agile Scrum Board. В конце спринта проводится еще одна встреча — ретроспектива. Команда встречается, велосити это чтобы проговорить свою работу над спринтом, выделить хорошее и плохое. Интересно, что встреча иногда проходит как за обсуждением тактики, так и за простым общением за пиццей. Scrum «пришел» в Watsons, когда в компании начала работать маркетинг-директором Юлия Пузырева.
Как учитывать отпуск в планировании?
Теперь бизнес гораздо больше готов к изменениям и гибким подходам к разработке чем 10 лет назад. Поэтому и требования к этой роли сильно изменились. В этой статье я упомяну только ТОП качества и навыки, без которых для меня данная роль особо не представляет ценности и становится предметом шуток и подколов коллег.
Agile Project Management with Scrum
Но мне не раз приходилось ставить процесс тестирования на проекте с нуля, а также много-много раз консультировать компании по вопросам тестирования и проводить тренинги на эту тему. Очень часто у команды есть регулярные задачи по поддержке, консультированию и т.д. И очень важно на планировании сделать их видимыми и учесть при планировании спринта, чтобы не оказаться в ситуации, что вы весь спринт были чрезвычайно заняты, но вот задачи спринта не были сделаны. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит.
Ролі та відповідальності у Scrum
ИМХО проблема разных срамов — это когда абсолютно другие, причем ещё и кривые процессы называют скрамом, т.е. Когда возникает — мной подмечено что это связанно с не ИТ менеджерами в ИТ. Настаивает клиент на своем менеджере, а менеджер до того управляла продавцами и мерчами в офлайн магазине, прошла курсы скрама. В итоге чертишо — а не процесс, но даже не в этом дело не понимает менеджер как делать софтверные проекты что для этого нужно и т.д. На самом деле, я люблю скрам — это классный фреймворк для командного решения сложных технических проблем.
На какие метрики обратить внимание SM
В команде интернет-магазина экстраверту приходится работать с интровертом, иногда им сложно найти общий язык. Тогда в зависимости от сложившейся ситуации на помощь приходят остальные члены команды, либо им дают время разобраться в конфликте самим. Слаженная устоявшаяся команда выполняет от 75 до 90% задач за спринт, а на первых спринтах, когда члены команды еще не привыкли работать друг с другом, этот коэффициент может быть ниже. Коэффициент станет выше, когда команда научится планировать и распределять свои ресурсы. Инкремент презентуется командой в конце каждого спринта на специальной встрече — демонстрации.
- История, которой присвоено значение 2, должна быть вдвое больше истории со значением 1 и соответствовать двум третям истории со значением 3.
- Не всегда долгие технические дискуссии помогают дать оценку точнее.
- Если работа отдела связана с ежедневным выполнением срочных задач вне планирования, эта методика им не подойдет.
- Планировать со 100% точностью командам тяжело, если не сказать нереально, и при загрузках команд больше, чем их среднестатистическая velocity обязательства вряд ли будут выполнены.
И я решил поделиться своей историей по этому поводу. Сами Agile, Scrum, Kanban, XP, Lean тут вовсе ни при чем, я по-прежнему считаю эти подходы к разработке самыми современными и правильными. Возможно, кто-то тоже заметил определенные изменения в самой Agile тусовке и разделит мое мнение. Потому что у других итеративно-инкрементальных методологий были плохие пиарщики.
Потом нужно оценить, как на трудозатраты повлияет риск. Для этого стоит озвучить риски и оценить их влияение. Например, больше стори поинтов стоит присвоить элементу с более высокой степенью риска, особенно если он потребует выполнить больший объем работы, а не элементу, с которым проблемы менее вероятны.
» и отлаженных процессов, для работы с метриками важен контекст. Например, если смотреть исключительно на скорость (Velocity), в отрыве от других данных, это не дает ничего, кроме статистики. Возможно, Product Owner без обсуждения с командой с половины спринта захотел убрать часть задач и дополнить спринт другими. Если он это делает, это отразится на диаграмме. Нужно понять то, насколько растет Definition of Done его команды. Если вы следуете практикам Kanban, выберите Kanban Board.
Оптимизировать процесс тестирования с использованием подходов, которые будут применимы в нужном контексте проекта. Если вы не делаете оценки в стиле Agile, то в тестировании вы полагаетесь сугубо на интуицию и попытки обезопасить себя буферами времени. В Agile команде вы не оцениваете тестирование как активность, вместо этого вы оцениваете насколько сложно/долго команде сделать ДО КРИТЕРИЯ ГОТОВНОСТИ определенную функцию продукта. А кто и как в команде будет что делать вас мало интересует. Тестирование должно оставаться в рамках каждой задачи, а не быть отдельной фазой в этом процессе. Посмотрите в материалах выступлений мой старый доклад “QA в Agile”.
Каждый день проводятся встречи — daily, где команда обсуждает дневную работу над проектом. Посреди спринта опять встреча — storytelling, подведение итогов между этапами работы. Работа команды над проектом начинается со встречи команды для планирования спринта с product owner — это вроде как начальник проекта, но отчитываться ему нужно только в конце проделанной работы.
Но применять его стоит только если вы уж так неточно делаете оценки и хотите выделить несколько спринтов на адаптацию. Для этого на митинге по планированию выделите 80% задач, для которых вы на 100% уверены в готовности к концу спринта. Оставшиеся 20% задач будут вашим буфером на случай неудачного стечения обстоятельств. Но тем буфером, о котором будет знать заказчик и который вы сможете обсудить на ретроспективе. Последний тип буфера (у Тима он упоминается первым) – время на погрешность в оценках.
С fixed price, как таковым, у скрама проблем нет — он под это вполне заточен. Ещё хуже, когда считаешь, что её можно применить онтосительно реальной жизни без напильника. С другой стороны замечания тратящих рабочее время на комментирование статей на ДОУ тимлидов верны. Я не уверен, что успех легковесных методологий можно так сильно привязывать к Скраму. До украинских реалий XP, например, добрался намного раньше.