Pull to refresh

Comments 24

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

Серьезно? Это же один из самых ненавистных и осмеиваемых моментов в работе менеджеров/начальников.
Нужность standup'ов где-то посерединке.

Если вокруг болото, каждый что-то пилит из своих соображений и общей цели нет и не предвидится, то они не нужны.

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

А вот если есть командная работа, но нет возможности все спроектировать (не хватает квалификации или не ясны внешнеие требования) то scrum самое оно.
UFO landed and left these words here
Ежедневные пятиминутные митинги это хорошо, если:
1. Действительно 5 минут;
2. Количество людей не очень большое.
3. Все примерно в одном часовом поясе, а не на 8 часов разницы.
4. Нет людей, кто приходит в офис к 7ми часам.
UFO landed and left these words here
Первому подходу даже название придумали — ScrumBan.

А про боль — это признак что надо что то лечить: либо в нашей работе мы делаем что то не так (например нам скучно на стендапах, потому что мы не работаем командно, а работаем индивидуально), либо что то менять надо в процессах: стандартные не подходят, либо мы их не так поняли, либо…
В общем в любом случае надо над болями работать на ретроспективе.
UFO landed and left these words here
Второй подход — это уже не спринт, а релиз.
UFO landed and left these words here
Поставка после каждого спринта != Релиз.
Релиз может включать задачи на несколько спринтов. Это логический набор новых фич или исправлений.
UFO landed and left these words here
Daily meeting реально помогает, но только если команда дейсвительно небольшая(4-6 человек) и он действительно идет не более 5-10 минут.

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

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

P.S.: управляю командой из 4 человек, все на 100% удаленке.
такие ежедневные митинги подходят для задач, которые можно хоть в какой-то мере прогнозировать. Если же просто анализ проблемы может занимать от часов до недель, мне кажется (по опыту), такие митинги бесполезны, особенное, если в команде сильна специализация.
Может быть я и «бунтарь», но пусть митингами занимаются менеджеры. В маленькой компании, где нет менеджеров как таковых — это нормально, сидя за рабочим столом пообщаться по проекту, что сделано, что предстоит сделать. Иначе это затягивается каждый раз на неопределенное время, которое может быть потрачено на разработку. Я как интроверто-программист не совсем люблю выступать. Имхо.

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

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

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

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

Я считаю что srum это неплохая методология, но иногда команда начинает терять из виду общую картину. Что к сожалению чревато.
У вас какие-то безумно длинные итерации. Месячный спринт подразумевает что за месяц объем работ не изменится, а значит лишается та самая гибкость методологии. Я не прав?
Мы делали продукт, который выпускался релизами. В среднем релиз происходил пару раз в год, поэтому месячные итерации были достаточно гибкими.
Скрам это хороший инструмент. Он не работает там где его не правильно поняли и не правильно используют.

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

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

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

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

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

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

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

Тут важный момент, что если userstory удовлетворяет Definition of Done, то команда сама должна понять как сделать «непрописанные мелочи» правильно и эффективно, именно на её экспертизу и рассчитывается. Но, к сожалению, ответственность на себя брать люди не всегда хотят, а тогда уже ни скрамом, ни эджайлом не пахнет.
UFO landed and left these words here
Зачем эти пятиминутки; зачем рассказывать то, что я делал вчера или что я буду делать сегодня, если это отражено в задачнике (условная Jira)?
Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.

Тут просто обязана быть эта фотка

image
image
image

Only those users with full accounts are able to leave comments. Log in, please.