Комментарии 18
Фиксированные спринты.
Редко получается закрыть спринт вовремя так, чтобы все было сделано.

Скрам не требует обязательно успеть сделать и закрыть все задачи-стори. К этому стремятся, но это не самоцель.

Разнообразные митинги.
… проводятся для галочки и больше утомляют, чем приносят пользу.

вы просто не разобрались зачем они нужны и для кого. ничего страшного )
Да вроде как раз требует, тайм-боксинг спринтов — важная часть скрама.
Правда там скорее позиционируется что цель спринта должна быть достигнута, а не таски закрыты, вы это имели в виду?

На счёт митингов, с одной стороны согласен что «не разобрались», с другой, очень много кто «не разобрался», что тоже может быть неким провалом то ли в методологии то ли в описании, если все бьются об один и тот же угол, может его надо как-то спилить.
Скрам не требует обязательно успеть сделать и закрыть все задачи-стори. К этому стремятся, но это не самоцель.

В классическом скраме незавершенный вовремя спринт рассматривается как фейл и на ретроспективе обсуждается как такого не допустить в будущем.
Команда конец спринта рассматривает как дедлайн, даже если за его нарушение ничего не предусмотрено, а дедлайн это стресс.
вы просто не разобрались зачем они нужны и для кого. ничего страшного )

Я допускаю, что мог не разобраться )
Мы проводим дейли-митинги ежедневно и ретроспективы у нас есть, но все же я призываю всегда проверять, что любые встречи несут пользу, а не проводятся потому что «здесь так принято»
Мне кажется ключевое "мы не собираем релиз, а катим каждую задачу/фичу по отдельности"
Не каждый проект или технологический стек может себе это позволить.
Отличная статья, спасибо.
да, это наша особенность, по началу казалось дико, но со временем ощутил преимущества )
«Логировать время по каждой задаче, не менее 75% рабочего времени» — это какие-то этапы не учитываются, например: вёрстка, тестирование?
Лог времени в часах или каких-нибудь «попугаях»?
Задачи вы оцениваете предварительно?
В трудозатраты записывается всё на что было потрачено время, разная деятельность просто маркируется типом работ (разработка, тестироварние, исследования и т.п.)
Оценка в фактических часах с точностью до получаса.
Предварительно оценка дается если ее просят, на постоянной основе оценка не проводится так как нет спроса на нее.

Немного не понятно по поводу не фиксированных спринтов. Т.е. пока все задачи не сделаны — спринт не закрывается? А если осталась продолжительная, линейная задача. Что в этом случае делает оставшаяся часть команды?
возможно я неточно выразился, нефиксированные спринты = нет дедлайна для всей команды.
есть приоритезированный список задач на неделю-две, по мере его разгребания накидываются новые с нужным приоритетом.
Интересный подход, однако есть несколько вопросов:
1) Сколько человек в команде разработчиков? Как бы вы оценивали данный подход на командах от 10-15 человек?
2) Как происходит деплой? Если я правильно понял, то каждый чуть ли не самостоятельно создает релизную сборку, верно?
1) Мы придерживаемся правила «две пиццы» в размерах команд, то есть если команда не может перекусить двумя пиццами, то ее размер слишком большой. С большими командами не приходилось работать, но кажется, что от 10 человек естественным образом образуется две подкоманды.

2) Деплой полностью автоматизирован, если разработчик готов выкатить фичу, то он просто навешивает тег на мастер и пушит его. Дальше гитлаб сделает все сам, главное следить за логами, сентри и т.п.
Вот вопрос, как быть если над таской(стикер на доске) могут вести работу сразу два человека(допустим клиентщик и серверист). Как правильно провести декомпозицию? На сабтаски бить не по феншую. В общем не могу понять, может кто подскажет?
Я не вижу проблему в сабтасках.
Также могут быть отдельные таски и выставлены отношения blocked by в них.

при таких колонках не получится параллелить backend с frontend. IMHO, сабтаски лучше

Тогда вопрос, а что давать аналитику на анализ, и тестировщику на тест? Тоже делать сабтаски? Или таску? Если таску, то что делать с сабтасками по окончании работ с ними? P.S это не вопросы с подковыркой, просто пытаюсь понять как это делают более опытные коллеги.
Сабтаски закрываются как только сделаются, задача переходит в тестирование если все сабтаски закрыты.
Тут нет правильных/неправильных подходов, главное понять какой статус мы хотим отображать на доске и как это поможет управлять проектом.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

14 июня 2007

Местоположение

Россия

Численность

501–1 000 человек

Дата регистрации

27 декабря 2019

Блог на Хабре