Комментарии 18
Фиксированные спринты.
Редко получается закрыть спринт вовремя так, чтобы все было сделано.
Скрам не требует обязательно успеть сделать и закрыть все задачи-стори. К этому стремятся, но это не самоцель.
Разнообразные митинги.
… проводятся для галочки и больше утомляют, чем приносят пользу.
вы просто не разобрались зачем они нужны и для кого. ничего страшного )
Да вроде как раз требует, тайм-боксинг спринтов — важная часть скрама.
Правда там скорее позиционируется что цель спринта должна быть достигнута, а не таски закрыты, вы это имели в виду?
На счёт митингов, с одной стороны согласен что «не разобрались», с другой, очень много кто «не разобрался», что тоже может быть неким провалом то ли в методологии то ли в описании, если все бьются об один и тот же угол, может его надо как-то спилить.
Правда там скорее позиционируется что цель спринта должна быть достигнута, а не таски закрыты, вы это имели в виду?
На счёт митингов, с одной стороны согласен что «не разобрались», с другой, очень много кто «не разобрался», что тоже может быть неким провалом то ли в методологии то ли в описании, если все бьются об один и тот же угол, может его надо как-то спилить.
Скрам не требует обязательно успеть сделать и закрыть все задачи-стори. К этому стремятся, но это не самоцель.
В классическом скраме незавершенный вовремя спринт рассматривается как фейл и на ретроспективе обсуждается как такого не допустить в будущем.
Команда конец спринта рассматривает как дедлайн, даже если за его нарушение ничего не предусмотрено, а дедлайн это стресс.
вы просто не разобрались зачем они нужны и для кого. ничего страшного )
Я допускаю, что мог не разобраться )
Мы проводим дейли-митинги ежедневно и ретроспективы у нас есть, но все же я призываю всегда проверять, что любые встречи несут пользу, а не проводятся потому что «здесь так принято»
Мне кажется ключевое "мы не собираем релиз, а катим каждую задачу/фичу по отдельности"
Не каждый проект или технологический стек может себе это позволить.
Отличная статья, спасибо.
Не каждый проект или технологический стек может себе это позволить.
Отличная статья, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
В трудозатраты записывается всё на что было потрачено время, разная деятельность просто маркируется типом работ (разработка, тестироварние, исследования и т.п.)
Оценка в фактических часах с точностью до получаса.
Предварительно оценка дается если ее просят, на постоянной основе оценка не проводится так как нет спроса на нее.
Оценка в фактических часах с точностью до получаса.
Предварительно оценка дается если ее просят, на постоянной основе оценка не проводится так как нет спроса на нее.
Пришли почти к такой же схеме ) Это работает
Немного не понятно по поводу не фиксированных спринтов. Т.е. пока все задачи не сделаны — спринт не закрывается? А если осталась продолжительная, линейная задача. Что в этом случае делает оставшаяся часть команды?
Интересный подход, однако есть несколько вопросов:
1) Сколько человек в команде разработчиков? Как бы вы оценивали данный подход на командах от 10-15 человек?
2) Как происходит деплой? Если я правильно понял, то каждый чуть ли не самостоятельно создает релизную сборку, верно?
1) Сколько человек в команде разработчиков? Как бы вы оценивали данный подход на командах от 10-15 человек?
2) Как происходит деплой? Если я правильно понял, то каждый чуть ли не самостоятельно создает релизную сборку, верно?
1) Мы придерживаемся правила «две пиццы» в размерах команд, то есть если команда не может перекусить двумя пиццами, то ее размер слишком большой. С большими командами не приходилось работать, но кажется, что от 10 человек естественным образом образуется две подкоманды.
2) Деплой полностью автоматизирован, если разработчик готов выкатить фичу, то он просто навешивает тег на мастер и пушит его. Дальше гитлаб сделает все сам, главное следить за логами, сентри и т.п.
2) Деплой полностью автоматизирован, если разработчик готов выкатить фичу, то он просто навешивает тег на мастер и пушит его. Дальше гитлаб сделает все сам, главное следить за логами, сентри и т.п.
Вот вопрос, как быть если над таской(стикер на доске) могут вести работу сразу два человека(допустим клиентщик и серверист). Как правильно провести декомпозицию? На сабтаски бить не по феншую. В общем не могу понять, может кто подскажет?
Я не вижу проблему в сабтасках.
Также могут быть отдельные таски и выставлены отношения blocked by в них.
Также могут быть отдельные таски и выставлены отношения blocked by в них.
Еще вариант — настроенные колонки на доске:
todo -> backend -> frontend -> testing
todo -> backend -> frontend -> testing
при таких колонках не получится параллелить backend с frontend. IMHO, сабтаски лучше
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гибкие процессы в IT команде