Scrum. Взгляд программиста

>>Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.

Серьезно? Это же один из самых ненавистных и осмеиваемых моментов в работе менеджеров/начальников.

Ежедневные пятиминутные митинги это хорошо, если:
1. Действительно 5 минут;
2. Количество людей не очень большое.

Daily meeting реально помогает, но только если команда дейсвительно небольшая(4-6 человек) и он действительно идет не более 5-10 минут.

Основная ценность daily meeting для моей команды состоит в том, что я могу оперативно выявлять возникшие проблемы. Бывает сидит человек, копается в каком-то фреймворке/библиотеке. Ему кажется что вот-вот, еще чуть-чуть и все заработает… И так минул день… Хотя реально там нужно подтянуть какой-то сторонний пакет, дописать две строчки кода и все, проблема решена.

И да, как говорили выше, daily meeting хороши, если они действительно 5 минут. Если время за 5 минут выходит, тогда нужно уже отдельно с человеком садиться и разбираться что у него не так.

P.S.: управляю командой из 4 человек, все на 100% удаленке.

Может быть я и «бунтарь», но пусть митингами занимаются менеджеры. В маленькой компании, где нет менеджеров как таковых — это нормально, сидя за рабочим столом пообщаться по проекту, что сделано, что предстоит сделать. Иначе это затягивается каждый раз на неопределенное время, которое может быть потрачено на разработку. Я как интроверто-программист не совсем люблю выступать. Имхо.

>> Так вот, демо — это хороший шанс узнать, что нового появляется в продукте.

Лучше сделать вики, где будут описываться все фичи и исправления добавленные в проект, это позволит вернуться к их прочтению и корректировке в дальнейшем. Ну и, допустим, если необходимо держать команду в курсе, то лучше 5-минутные митинги заменить на 5-минутное прочтение обновлений вики, зато это будет сделано в комфортное время для каждого.

У меня к scram'у двоякое отношение. Я работал в команде где ввели scram около года назад. Вроде бы все правильно и качество продукта должно было подняться, но к сожалению, по-моему мнению, качество ухудшилось. ТЗ более не продумывались так глубоко как до введения sram'a,  вплоть до того что на демо-митинге выяснялось что разработка отдельных фич шла совсем не в том направлении. Документация стала вестись кое-как (если вообще велась).

Я считаю что srum это неплохая методология, но иногда команда начинает терять из виду общую картину. Что к сожалению чревато.

У вас какие-то безумно длинные итерации. Месячный спринт подразумевает что за месяц объем работ не изменится, а значит лишается та самая гибкость методологии. Я не прав?

Скрам это хороший инструмент. Он не работает там где его не правильно поняли и не правильно используют.

Причина зачем нужны дейли — синхронизация и микропланирование. Мало кто делает дейли до конца и заканчивают только синхронизацией сами не понимая зачем. Регулярно звучат комментарии «по борде видно кто чо делает». Это так. Но правильный флоу дейли это проговорить структурировано о состоянии задач в прогрессе и о следующих планах и скорректировать эти планы конкретно на месте. Когда собрана вся команда, это сделать проще нежели решать через чат или через скайп. Эти 5-10 минут себя окупают, получается с глазу на глаз все согласовать на сегодня-завтра намного быстрее. Плюс, важна неформальная обстановка. Я предпочитаю проводить дейли на улице, благо офис позволяет и мы на 2м этаже а улица выходит в наш собственный дворик со столиком. В любое время года на улице хорошо. Жопе, спине и голове легче нежели ютится в каких то проходах или переговорках где витает атмосфера бюрократии.

Основная фишка скрама это команда>клиент&менеджер. Скрам дает команде картбланш. Команда имеет право решить что она будет делать и делать это так что бы ни кто их не трогал ровно спринт. Какие то новые вбросы, дедлайны? Пошли к черту. Что то надо поправить срочно на продакшене? Пошли к черту, нанимайте сапорт или девопс.

Самая главная фишка без которой не работает скрам вообще это Difinition of Done. У команды должен он быть. Команда выпустит фичи за спринт те которые она успеет и те которые будут на 100% соответстовать DoD. Они будут закончены, они будут протестированы, код будет отрефакторен, задокументирован, и готов как полноценный инкремент. Команда в конец спринта представляет конкретный инкремент готового функционала, а всё что в прогрессе остается в отдельных ветках. Всё.

Дальше уже право заказчика или менеджера интегрировать инкремент на продакшн или ждать новый. Базовыми метриками менеджер легко вычисляет скорость команды. Что потрачено у каждого 40ч, а задач поделано с оценками сумарно на 20ч, итого скорость 20ч или 50% от номинала. С каждым спринтом эта цифра будет стабилизироватся и будет отличное понимание Велосити. С ним уже можно работать, воспитывать людей или менять или добавлять кого то еще в команду, докручивать процессы, искать причины такого велосити. Вот где компетентность менеджера.

Чаще всего я вижу, что менеджеры пытаются быть сразу скрам мастерами и внешними менеджерами. Они начинают внутри спринта устраивать свое подобие вотерфола и классики, начинать вкидывать по ходу спринта еще задач потому что клиент ему на почту написал и в скайп продублировал. И это превращается уже не в скрам а в *скрамНО.

Беда скрама в том что его не правильно готовят. И не там применяют. И тем более, команда не готова к скраму, она не обучена по нему работать, и одни процессы скрама подменяются какими то похожими издалека подобиями. Если люди не могут понять истинной пользы и сути дейли, при этом активно скрамясь то я боюсь предположить как делаются оставшиеся скрам активности.

На ретроспективе наверное менеджер всем в лоб по очереди задает вопросы «Артём, что у нас на этом спринте было хорошо а что плохо?» и получает ответ «Ээээм, ну х%1 его знает».

Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.