О методологии Scrum
Scrum является одной из разновидностей гибких методологий Agile и позволяет быстро реагировать на изменяющиеся внешние требования. В Scrum основными понятиями являются итерация и спринт. Весь рабочий процесс разбивается на временные отрезки, которые называются итерация. В итерацию входит планирование, непосредственная разработка (спринт) и тестирование. Итерация имеет жесткие временные ограничения. Таким образом, Scrum ориентирован в первую очередь на сроки выполнения задач.
О процессе
Давайте теперь рассмотрим как именно был реализован Scrum внутри нашей команды. Сначала мы окинем весь процесс общим взглядом, а потом рассмотрим каждый этап подробно. Каждая итерация у нас длилась один месяц. Начиналась она с планирования и оценки задач, затем шел спринт, во время которого проводились ежедневные пятиминутки и прочие митинги по необходимости. По окончанию разработки была демонстрация нового функционала и ретроспектива.
Планирование
Все начиналось с того, что Product manager создавал список задач на основе целей продукта и отзывов пользователей. Затем из этого списка он выбирал первоочередные задачи и отдавал нам на оценку. Этот список был немного больше, чем мы реально могли сделать за месяц на тот случай если вдруг случится чудо. Мы много жаловались на то, что в задачах не было прописано всё до мелочей. Но сейчас, я могу сказать точно, что ни в одной другой команде я еще не видел такого качественного оформления задач от PM.
Далее, команде предстояло оценить каждую задачу и по оценкам понять, что войдет в предстоящий спринт. Про оценивание надо рассказать подробнее. На первых этапах оценивали так: тимлидер назначал каждую задачу на каждого разработчика и разработчик давал оценку. Если оценка разработчика сильно отличалась от ожиданий, то пытались разобраться в причине расхождений и корректировали либо оценку либо задачу. Это занимало много времени у тимлидера, а он всегда стремился сделать систему самостоятельной, что привело в итоге к использованию Planning-poker’а. Каждый разработчик оценивал все задачи команды на предстоящий спринт, а затем тимлидер вычислял среднюю оценку на каждую задачу. Минусом такого подхода было то, что оценку давали разработчики разных уровней и если потом задача попадала новичку, то конечно он делал задачу дольше этой оценки. Пытались вводить коэффициенты по каждому разработчику, но это еще больше все усложняло. В итоге, потом, с приходом новой системы стимулирования вообще отказались от индивидуальной оценки задач, но об этом будет чуть ниже.
После того, как все задачи были оценены, выбирались все задачи по приоритету, которые укладывались в длину спринта и начинался процесс разработки. После этого момента ничего нового PM уже добавить не мог в список до окончания итерации.
Пятиминутка
Процесс разработки был самым длительным в итерации. В это время ежедневно по утрам проводилась пятиминутка. У нас он назывался stand up митинг. Все вставали в кружок и каждый рассказывал, что он делал вчера и что собирается делать сегодня.
Целью этого митинга была синхронизация задач между участниками команды и выявление возникших проблем. Помимо этого был еще психологический момент. Если человек утром давал обещание перед командой что-то сделать, то ему уже труднее было не сдержать это обещание. У участников команды было очень разное отношение к этому митингу. Были так называемые “солдаты” — люди, которые понимали суть митинга, приходили и по-солдатски докладывали обстановку. Были и “бунтари” — люди, которые никак не хотели отрываться от мониторов и стоять в круге со всеми. Но большинство относилось к этому спокойно, как к части работы.
Спринт
Интересной особенностью нашей разработки было то, что наш тимлидер был категорически против разделения на специальности. То есть программист должен был уметь сделать любую задачу или починить баг за другим программистом. Этот подход достаточно спорный и если хотите — его можно обсудить в комментариях…
В качестве планировщика задач мы использовали систему Target Process. По началу у нас не было настоящей доски, только список задач в этой системе. Позже появилась доска, но она не была центральной частью процесса и пятиминутные митинги не строились вокруг нее. Скорее это было просто визуальное представление, где находится задача на отрезке спринта.
Поскольку тимлидеру надо было как-то отслеживать успевает программист внутри своей задачи или нет, то у нас была практика отчетов о потраченном времени на каждую задачу и помимо этого, каждый день программист должен был обновлять у задачи оценку — сколько времени по его мнению осталось потратить на эту задачу.
На основе этих данных руководство строило burndown диаграммы, по которым можно было увидеть успеваем мы или нет.
Ревью кода мы проводили в специальной программе Code Collaborator. При отправке кода на ревью можно было назначить только одного ревьюера и любое количество обозревателей. Только ревьюер решал можно коммитить данный код или нет. Комментарии обозревателей носили только рекомендательный характер. Интересно, что если член команды не был в списке обозревателей и ревьюеров, то он даже посмотреть не мог этот код.
Демо
После того, как все задачи были сделаны и протестированы наступало время митинга под названием “Демо”. На этом митинге собирались все участники команды от дизайнеров до отдела технической документации и смотрели выступления разработчиков.
Каждый разработчик на большом экране показывал, что он сделал за текущий спринт. Особенно эффектно это выглядело у frontend разработчиков, но и backend разработчики открывали на экран консоль и показывали новый крутой API запрос.
Польза от этого митинга в том, что во время пятиминуток обычно люди рассказывают, что они что-то делают, но потом редко кто-то из команды видит результат, так как каждый варится в своем наборе задач. Так вот, демо — это хороший шанс узнать, что нового появляется в продукте. Демо поднимает общий боевой дух и дает ощущение, что наш корабль плывет, а не стоит на месте.
А еще есть и побочный эффект. Нередко бывало такое, что во время демо случались казусы и что-то шло не так или придумывались новые интересные кейсы поведения и поэтому команда тестирования всегда уходила с полным блокнотиком багов.
Ретроспектива
Ретроспектива — это митинг, который проводится после завершения итерации с целью выявить текущие проблемы и улучшить процесс на будущее. В нашей команде этот митинг назывался Post mortem. Наш тимлидер хотел, чтобы этот митинг проходил в максимально расслабленной атмосфере, поэтому мы покупали пиво и закуску, садились за стол, отмечали окончание итерации и заодно обсуждали кому что понравилось в прошедшей итерации и что не понравилось. Равнодушных в команде почти не было, поэтому это застолье обычно было очень жарким и долгим. Product manager жаловался на программистов, что задачи не сделаны в срок, тестировщики жаловались на программистов, что слишком поздно отдаются задачи в тестирование и они не успевают их проверить до окончания итерации. А программисты жаловались, что задачи приходят не продуманными и приходится много времени тратить на продумывание специфических ситуаций.
В какой-то момент мы заметили, что на каждой ретроспективе жалуемся на одно и то же и решили записывать все моменты. Потом мы поняли, что на каждой ретроспективе мы записываем одно и тоже. Тогда мы решили не просто записывать, а назначать решение каждой проблемы на конкретного человека и он на следующей ретроспективе должен был отчитаться. Потом мы поняли, что пока все отчитаются, пока запишут новые проблемы — времени выпить уже не остается и решили отделить ретроспективу от пьянки. После этого стало уже не так интересно и ретроспектива превратилась в сухой неинтересный митинг.
От себя могу отметить, что ретроспектива помимо своего основного значения несет очень важный момент — психологическую разрядку. Это время, когда человек совершенно безнаказанно может высказать все, что у него накопилось за месяц и продолжить спокойно работать. Несмотря на явную агрессию во время митинга, после его окончания команда становилась каждый раз еще более сплоченной.
Прочие мероприятия
Еще у нас был митинг “one and one”. Раз в две недели тимлидер разговаривал с каждым членом команды, где тот мог сказать всё то, что нельзя сказать на ретроспективе.
Были и неофициальные мероприятия за пределами офиса. Например два раза в год мы ездили командой на шашлыки.
Стимулирование
В жизни любой команды есть начальный период, когда все полны энтузиазма и работа кипит, но если команда в одном и том же составе работает несколько лет, то наступает период спада производительности. И тут дело не только в том, что накапливается усталость, но и в том, что продукт становится сложнее и больше времени тратится на его поддержку и расширение.
Когда наш тимлидер увидел, что у команды наступил именно такой момент он решил сильно поменять весь процесс и ввести дополнительное стимулирование. Основная его идея была в том, что перестает существовать понятие программист и член команды. Команда становится минимальной неделимой единицей. В конце каждой итерации команда определяет какой набор задач она берет на себя на следующий спринт. И выполняет эти задачи. Если задачи выполнены и протестированы за два дня до окончания спринта, то команда может использовать эти оставшиеся дни по своему усмотрению. Хоть даже не ходить на работу. К сожалению финансово простимулировать нас тимлидер не мог, поэтому поощрение выражалось свободным временем.
Схема выглядела вот так:
| 22 дня | |||
| 10 дней | 8 дней | 2 дня | 2 дня |
| разработка | тестирование и багфиксинг | оценка | отдых |
Отсюда видно, что два дня в месяц мы не занимались программированием. Весь отдел собирался в конференц-зале. Мы брали все задачи, которые нам предоставлял менеджмент и пытались рассмотреть все сложные моменты и дать оценку по каждой задаче.
Могу сказать, что идея оказалась провальной. Мы всего один раз смогли заработать эти поощрительные два дня. Оценки на задачи давались очень завышенные и на каждое действие создавался отдельный митинг с участием всей команды, т.к. все боялись не успеть и потерять поощрительные два дня. Завышенные оценки приводили к расслабленности во время реализации этих задач, а куча митингов мешала сосредоточится на программировании и в итоге общая производительность отдела упала. К этому моменту команда уже понимала, что нужно сделать шаг назад и вернуться к прежней системе, но не успела. Отдел закрыли по независящим от команды причинам.
Заключение
Несмотря на провал с введением системы стимулирования до этого эксперимента вышеописанная методология в течение нескольких лет давала превосходные результаты, команда показывала высокую скорость работы и продукт развивался очень быстро. В качестве заключения, я бы хотел дать несколько советов начинающим тимлидерам.
- Обязательно изучите разные методологии управления проектами и не бойтесь экспериментировать.
- Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.
- Обязательно разговаривайте с подчиненными. Станьте для них вторым отцом. Пусть у них не будет секретов ни от вас, ни от команды. Ретроспективы и one&one прекрасно для этого подходят. А алкоголь может вам в этом немного помочь.
- Введите “Демо”. Команда постоянно должна видеть как продукт развивается.
- Не вводите слишком много митингов и ограничений. Сложный процесс мешает эффективной работе.
Комментарии (23)
gizur
08.05.2016 16:54+6Ежедневные пятиминутные митинги это хорошо, если:
1. Действительно 5 минут;
2. Количество людей не очень большое.billyevans
13.05.2016 00:383. Все примерно в одном часовом поясе, а не на 8 часов разницы.
4. Нет людей, кто приходит в офис к 7ми часам.
sentyaev
08.05.2016 22:40+4За мои 10 лет работы я ни разу не видел работающего скрама. Всегда была боль.
Для себя отметил два подхода которые работают:
1. Деплоим на прод фичи по мере готовности.
2. Берем задачи на спринт (примерно), и спринт заканчивается тогда, когда все сделано, т.е. не привязываемся к какой-то конкретной дате (понятно, что если что-то занимает слишком много времени, это можно отложить).
tupikoff
09.05.2016 04:50+1Первому подходу даже название придумали — ScrumBan.
А про боль — это признак что надо что то лечить: либо в нашей работе мы делаем что то не так (например нам скучно на стендапах, потому что мы не работаем командно, а работаем индивидуально), либо что то менять надо в процессах: стандартные не подходят, либо мы их не так поняли, либо…
В общем в любом случае надо над болями работать на ретроспективе.sentyaev
10.05.2016 16:43Первому подходу даже название придумали — ScrumBan.
Скорее Continuous delivery или Сontinuous deployment.
А про боль — это признак что надо что то лечить
Боль была по причине того, что «процесс» ставился во главе, а результат не интересовал.
Я не против Scrum'a, я считаю его хорошей методологией. Просто я часто видел как его применяли неправильно.
Например нет смысла применять скрам для проекта из 10 человек, слишком большой оверхед.
DmitryMironov
10.05.2016 13:02Второй подход — это уже не спринт, а релиз.
sentyaev
10.05.2016 15:34Так в результате каждого спринта должен быть релиз. Иначе зачем вводить Scrum?
Т.к. без рабочего продукта на каждой итерации мы получим «водопад».DmitryMironov
10.05.2016 16:42Поставка после каждого спринта != Релиз.
Релиз может включать задачи на несколько спринтов. Это логический набор новых фич или исправлений.sentyaev
10.05.2016 16:47Прошу прощения, я только сейчас понял, что вы имели ввиду под словом «релиз».
Просто никогда не занимался разработкой с «релизами», всегда либо после спринта на прод, либо сделал фичу — на прод.
Правда ваша.
kumaxim
09.05.2016 04:50Daily meeting реально помогает, но только если команда дейсвительно небольшая(4-6 человек) и он действительно идет не более 5-10 минут.
Основная ценность daily meeting для моей команды состоит в том, что я могу оперативно выявлять возникшие проблемы. Бывает сидит человек, копается в каком-то фреймворке/библиотеке. Ему кажется что вот-вот, еще чуть-чуть и все заработает… И так минул день… Хотя реально там нужно подтянуть какой-то сторонний пакет, дописать две строчки кода и все, проблема решена.
И да, как говорили выше, daily meeting хороши, если они действительно 5 минут. Если время за 5 минут выходит, тогда нужно уже отдельно с человеком садиться и разбираться что у него не так.
P.S.: управляю командой из 4 человек, все на 100% удаленке.RainM
09.05.2016 23:28такие ежедневные митинги подходят для задач, которые можно хоть в какой-то мере прогнозировать. Если же просто анализ проблемы может занимать от часов до недель, мне кажется (по опыту), такие митинги бесполезны, особенное, если в команде сильна специализация.
mendler
09.05.2016 04:51+1Может быть я и «бунтарь», но пусть митингами занимаются менеджеры. В маленькой компании, где нет менеджеров как таковых — это нормально, сидя за рабочим столом пообщаться по проекту, что сделано, что предстоит сделать. Иначе это затягивается каждый раз на неопределенное время, которое может быть потрачено на разработку. Я как интроверто-программист не совсем люблю выступать. Имхо.
>> Так вот, демо — это хороший шанс узнать, что нового появляется в продукте.
Лучше сделать вики, где будут описываться все фичи и исправления добавленные в проект, это позволит вернуться к их прочтению и корректировке в дальнейшем. Ну и, допустим, если необходимо держать команду в курсе, то лучше 5-минутные митинги заменить на 5-минутное прочтение обновлений вики, зато это будет сделано в комфортное время для каждого.khabib
09.05.2016 21:20+1>>Может быть я и «бунтарь», но пусть митингами занимаются менеджеры.
В скраме нет менеджеров. В скраме все решает комманда, и если комманда решает что то не брать в спринт, то это не берется в спринт. В скарме есть скрам мастер, который должен защищать команду от давления со стороны менеджеров.
Если в скраме появляется менеджер, то всегда получается waterfall со стендапами
А демо, это способо показать, что собственно комманда нарешала и сделала по факту. Не на бумаге (вики), а в жизни и со всеми багами которые вылезли прямо во время демо
al_bandy
10.05.2016 13:02+1У меня к scram'у двоякое отношение. Я работал в команде где ввели scram около года назад. Вроде бы все правильно и качество продукта должно было подняться, но к сожалению, по-моему мнению, качество ухудшилось. ТЗ более не продумывались так глубоко как до введения sram'a, вплоть до того что на демо-митинге выяснялось что разработка отдельных фич шла совсем не в том направлении. Документация стала вестись кое-как (если вообще велась).
Я считаю что srum это неплохая методология, но иногда команда начинает терять из виду общую картину. Что к сожалению чревато.
gmelnikov
12.05.2016 13:21У вас какие-то безумно длинные итерации. Месячный спринт подразумевает что за месяц объем работ не изменится, а значит лишается та самая гибкость методологии. Я не прав?
Mirantus
12.05.2016 14:35Мы делали продукт, который выпускался релизами. В среднем релиз происходил пару раз в год, поэтому месячные итерации были достаточно гибкими.
uamarshall
12.05.2016 23:49+3Скрам это хороший инструмент. Он не работает там где его не правильно поняли и не правильно используют.
Причина зачем нужны дейли — синхронизация и микропланирование. Мало кто делает дейли до конца и заканчивают только синхронизацией сами не понимая зачем. Регулярно звучат комментарии «по борде видно кто чо делает». Это так. Но правильный флоу дейли это проговорить структурировано о состоянии задач в прогрессе и о следующих планах и скорректировать эти планы конкретно на месте. Когда собрана вся команда, это сделать проще нежели решать через чат или через скайп. Эти 5-10 минут себя окупают, получается с глазу на глаз все согласовать на сегодня-завтра намного быстрее. Плюс, важна неформальная обстановка. Я предпочитаю проводить дейли на улице, благо офис позволяет и мы на 2м этаже а улица выходит в наш собственный дворик со столиком. В любое время года на улице хорошо. Жопе, спине и голове легче нежели ютится в каких то проходах или переговорках где витает атмосфера бюрократии.
Основная фишка скрама это команда>клиент&менеджер. Скрам дает команде картбланш. Команда имеет право решить что она будет делать и делать это так что бы ни кто их не трогал ровно спринт. Какие то новые вбросы, дедлайны? Пошли к черту. Что то надо поправить срочно на продакшене? Пошли к черту, нанимайте сапорт или девопс.
Самая главная фишка без которой не работает скрам вообще это Difinition of Done. У команды должен он быть. Команда выпустит фичи за спринт те которые она успеет и те которые будут на 100% соответстовать DoD. Они будут закончены, они будут протестированы, код будет отрефакторен, задокументирован, и готов как полноценный инкремент. Команда в конец спринта представляет конкретный инкремент готового функционала, а всё что в прогрессе остается в отдельных ветках. Всё.
Дальше уже право заказчика или менеджера интегрировать инкремент на продакшн или ждать новый. Базовыми метриками менеджер легко вычисляет скорость команды. Что потрачено у каждого 40ч, а задач поделано с оценками сумарно на 20ч, итого скорость 20ч или 50% от номинала. С каждым спринтом эта цифра будет стабилизироватся и будет отличное понимание Велосити. С ним уже можно работать, воспитывать людей или менять или добавлять кого то еще в команду, докручивать процессы, искать причины такого велосити. Вот где компетентность менеджера.
Чаще всего я вижу, что менеджеры пытаются быть сразу скрам мастерами и внешними менеджерами. Они начинают внутри спринта устраивать свое подобие вотерфола и классики, начинать вкидывать по ходу спринта еще задач потому что клиент ему на почту написал и в скайп продублировал. И это превращается уже не в скрам а в *скрамНО.
Беда скрама в том что его не правильно готовят. И не там применяют. И тем более, команда не готова к скраму, она не обучена по нему работать, и одни процессы скрама подменяются какими то похожими издалека подобиями. Если люди не могут понять истинной пользы и сути дейли, при этом активно скрамясь то я боюсь предположить как делаются оставшиеся скрам активности.
На ретроспективе наверное менеджер всем в лоб по очереди задает вопросы «Артём, что у нас на этом спринте было хорошо а что плохо?» и получает ответ «Ээээм, ну х%1 его знает».vabue
13.05.2016 13:35+1Всё верно. Я обычно добавляю «скрам придумывали не идиоты, и многие мелочи существуют в нём неспроста».
Мы много жаловались на то, что в задачах не было прописано всё до мелочей
Тут важный момент, что если userstory удовлетворяет Definition of Done, то команда сама должна понять как сделать «непрописанные мелочи» правильно и эффективно, именно на её экспертизу и рассчитывается. Но, к сожалению, ответственность на себя брать люди не всегда хотят, а тогда уже ни скрамом, ни эджайлом не пахнет.
TITnet
13.05.2016 09:55-1Зачем эти пятиминутки; зачем рассказывать то, что я делал вчера или что я буду делать сегодня, если это отражено в задачнике (условная Jira)?
Liquidos
08.05.2016 06:26+2>>Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.
Серьезно? Это же один из самых ненавистных и осмеиваемых моментов в работе менеджеров/начальников.iivvaall
09.05.2016 04:48Нужность standup'ов где-то посерединке.
Если вокруг болото, каждый что-то пилит из своих соображений и общей цели нет и не предвидится, то они не нужны.
Наоборот, если все уже спроектированно и что делать понятно на месяц вперед, то они опять же не нужны.
А вот если есть командная работа, но нет возможности все спроектировать (не хватает квалификации или не ясны внешнеие требования) то scrum самое оно.
Aingis
09.05.2016 12:21А вот если есть командная работа, но нет возможности все спроектировать (не хватает квалификации или не ясны внешнеие требования) то scrum самое оно.
В таком варианте выходит на первый план другая проблема: невозможность точной оценки сложности (и сроков выполнения) задач, потому что они принимают случайный характер опять же из-за неясности требований. В итоге или спринты не сходятся, или в конце спринтов разработчики ничего не делают.
Да, можно брать задачи из следующей очереди или помогать остальным, но кому это надо, когда и так всё хорошо? Суровым интровертам вообще сложно предложить кому-то свою помощь, а кому-то, наоборот, сказать, что нужна помощь. Да и тестировщики говорят, что им помощь не нужна, потому что разработчики больше мешать будут.
gizur
08.05.2016 16:54+6Ежедневные пятиминутные митинги это хорошо, если:
1. Действительно 5 минут;
2. Количество людей не очень большое.billyevans
13.05.2016 00:383. Все примерно в одном часовом поясе, а не на 8 часов разницы.
4. Нет людей, кто приходит в офис к 7ми часам.
sentyaev
08.05.2016 22:40+4За мои 10 лет работы я ни разу не видел работающего скрама. Всегда была боль.
Для себя отметил два подхода которые работают:
1. Деплоим на прод фичи по мере готовности.
2. Берем задачи на спринт (примерно), и спринт заканчивается тогда, когда все сделано, т.е. не привязываемся к какой-то конкретной дате (понятно, что если что-то занимает слишком много времени, это можно отложить).tupikoff
09.05.2016 04:50+1Первому подходу даже название придумали — ScrumBan.
А про боль — это признак что надо что то лечить: либо в нашей работе мы делаем что то не так (например нам скучно на стендапах, потому что мы не работаем командно, а работаем индивидуально), либо что то менять надо в процессах: стандартные не подходят, либо мы их не так поняли, либо…
В общем в любом случае надо над болями работать на ретроспективе.sentyaev
10.05.2016 16:43Первому подходу даже название придумали — ScrumBan.
Скорее Continuous delivery или Сontinuous deployment.
А про боль — это признак что надо что то лечить
Боль была по причине того, что «процесс» ставился во главе, а результат не интересовал.
Я не против Scrum'a, я считаю его хорошей методологией. Просто я часто видел как его применяли неправильно.
Например нет смысла применять скрам для проекта из 10 человек, слишком большой оверхед.
DmitryMironov
10.05.2016 13:02Второй подход — это уже не спринт, а релиз.
sentyaev
10.05.2016 15:34Так в результате каждого спринта должен быть релиз. Иначе зачем вводить Scrum?
Т.к. без рабочего продукта на каждой итерации мы получим «водопад».DmitryMironov
10.05.2016 16:42Поставка после каждого спринта != Релиз.
Релиз может включать задачи на несколько спринтов. Это логический набор новых фич или исправлений.sentyaev
10.05.2016 16:47Прошу прощения, я только сейчас понял, что вы имели ввиду под словом «релиз».
Просто никогда не занимался разработкой с «релизами», всегда либо после спринта на прод, либо сделал фичу — на прод.
Правда ваша.
kumaxim
09.05.2016 04:50Daily meeting реально помогает, но только если команда дейсвительно небольшая(4-6 человек) и он действительно идет не более 5-10 минут.
Основная ценность daily meeting для моей команды состоит в том, что я могу оперативно выявлять возникшие проблемы. Бывает сидит человек, копается в каком-то фреймворке/библиотеке. Ему кажется что вот-вот, еще чуть-чуть и все заработает… И так минул день… Хотя реально там нужно подтянуть какой-то сторонний пакет, дописать две строчки кода и все, проблема решена.
И да, как говорили выше, daily meeting хороши, если они действительно 5 минут. Если время за 5 минут выходит, тогда нужно уже отдельно с человеком садиться и разбираться что у него не так.
P.S.: управляю командой из 4 человек, все на 100% удаленке.RainM
09.05.2016 23:28такие ежедневные митинги подходят для задач, которые можно хоть в какой-то мере прогнозировать. Если же просто анализ проблемы может занимать от часов до недель, мне кажется (по опыту), такие митинги бесполезны, особенное, если в команде сильна специализация.
mendler
09.05.2016 04:51+1Может быть я и «бунтарь», но пусть митингами занимаются менеджеры. В маленькой компании, где нет менеджеров как таковых — это нормально, сидя за рабочим столом пообщаться по проекту, что сделано, что предстоит сделать. Иначе это затягивается каждый раз на неопределенное время, которое может быть потрачено на разработку. Я как интроверто-программист не совсем люблю выступать. Имхо.
>> Так вот, демо — это хороший шанс узнать, что нового появляется в продукте.
Лучше сделать вики, где будут описываться все фичи и исправления добавленные в проект, это позволит вернуться к их прочтению и корректировке в дальнейшем. Ну и, допустим, если необходимо держать команду в курсе, то лучше 5-минутные митинги заменить на 5-минутное прочтение обновлений вики, зато это будет сделано в комфортное время для каждого.khabib
09.05.2016 21:20+1>>Может быть я и «бунтарь», но пусть митингами занимаются менеджеры.
В скраме нет менеджеров. В скраме все решает комманда, и если комманда решает что то не брать в спринт, то это не берется в спринт. В скарме есть скрам мастер, который должен защищать команду от давления со стороны менеджеров.
Если в скраме появляется менеджер, то всегда получается waterfall со стендапами
А демо, это способо показать, что собственно комманда нарешала и сделала по факту. Не на бумаге (вики), а в жизни и со всеми багами которые вылезли прямо во время демо
al_bandy
10.05.2016 13:02+1У меня к scram'у двоякое отношение. Я работал в команде где ввели scram около года назад. Вроде бы все правильно и качество продукта должно было подняться, но к сожалению, по-моему мнению, качество ухудшилось. ТЗ более не продумывались так глубоко как до введения sram'a, вплоть до того что на демо-митинге выяснялось что разработка отдельных фич шла совсем не в том направлении. Документация стала вестись кое-как (если вообще велась).
Я считаю что srum это неплохая методология, но иногда команда начинает терять из виду общую картину. Что к сожалению чревато.
gmelnikov
12.05.2016 13:21У вас какие-то безумно длинные итерации. Месячный спринт подразумевает что за месяц объем работ не изменится, а значит лишается та самая гибкость методологии. Я не прав?
Mirantus
12.05.2016 14:35Мы делали продукт, который выпускался релизами. В среднем релиз происходил пару раз в год, поэтому месячные итерации были достаточно гибкими.
uamarshall
12.05.2016 23:49+3Скрам это хороший инструмент. Он не работает там где его не правильно поняли и не правильно используют.
Причина зачем нужны дейли — синхронизация и микропланирование. Мало кто делает дейли до конца и заканчивают только синхронизацией сами не понимая зачем. Регулярно звучат комментарии «по борде видно кто чо делает». Это так. Но правильный флоу дейли это проговорить структурировано о состоянии задач в прогрессе и о следующих планах и скорректировать эти планы конкретно на месте. Когда собрана вся команда, это сделать проще нежели решать через чат или через скайп. Эти 5-10 минут себя окупают, получается с глазу на глаз все согласовать на сегодня-завтра намного быстрее. Плюс, важна неформальная обстановка. Я предпочитаю проводить дейли на улице, благо офис позволяет и мы на 2м этаже а улица выходит в наш собственный дворик со столиком. В любое время года на улице хорошо. Жопе, спине и голове легче нежели ютится в каких то проходах или переговорках где витает атмосфера бюрократии.
Основная фишка скрама это команда>клиент&менеджер. Скрам дает команде картбланш. Команда имеет право решить что она будет делать и делать это так что бы ни кто их не трогал ровно спринт. Какие то новые вбросы, дедлайны? Пошли к черту. Что то надо поправить срочно на продакшене? Пошли к черту, нанимайте сапорт или девопс.
Самая главная фишка без которой не работает скрам вообще это Difinition of Done. У команды должен он быть. Команда выпустит фичи за спринт те которые она успеет и те которые будут на 100% соответстовать DoD. Они будут закончены, они будут протестированы, код будет отрефакторен, задокументирован, и готов как полноценный инкремент. Команда в конец спринта представляет конкретный инкремент готового функционала, а всё что в прогрессе остается в отдельных ветках. Всё.
Дальше уже право заказчика или менеджера интегрировать инкремент на продакшн или ждать новый. Базовыми метриками менеджер легко вычисляет скорость команды. Что потрачено у каждого 40ч, а задач поделано с оценками сумарно на 20ч, итого скорость 20ч или 50% от номинала. С каждым спринтом эта цифра будет стабилизироватся и будет отличное понимание Велосити. С ним уже можно работать, воспитывать людей или менять или добавлять кого то еще в команду, докручивать процессы, искать причины такого велосити. Вот где компетентность менеджера.
Чаще всего я вижу, что менеджеры пытаются быть сразу скрам мастерами и внешними менеджерами. Они начинают внутри спринта устраивать свое подобие вотерфола и классики, начинать вкидывать по ходу спринта еще задач потому что клиент ему на почту написал и в скайп продублировал. И это превращается уже не в скрам а в *скрамНО.
Беда скрама в том что его не правильно готовят. И не там применяют. И тем более, команда не готова к скраму, она не обучена по нему работать, и одни процессы скрама подменяются какими то похожими издалека подобиями. Если люди не могут понять истинной пользы и сути дейли, при этом активно скрамясь то я боюсь предположить как делаются оставшиеся скрам активности.
На ретроспективе наверное менеджер всем в лоб по очереди задает вопросы «Артём, что у нас на этом спринте было хорошо а что плохо?» и получает ответ «Ээээм, ну х%1 его знает».vabue
13.05.2016 13:35Всё верно. Я обычно добавляю «скрам придумывали не идиоты, и многие мелочи существуют в нём неспроста».
Мы много жаловались на то, что в задачах не было прописано всё до мелочей
Тут важный момент, что если userstory удовлетворяет Definition of Done, то команда сама должна понять как сделать «непрописанные мелочи» правильно и эффективно, именно на её экспертизу и рассчитывается. Но, к сожалению, ответственность на себя брать люди не всегда хотят, а тогда уже ни скрамом, ни эджайлом не пахнет.
sentyaev
16.05.2016 12:57Пятиминутки — зачем? Все и так на борде, с комментами.
DOD — попытка прикрыться от плохих user story.
Велосити — плохие user story сложно оценить, вот и ошибаемся все время, но нужно же как-то объяснить это заказчику.
И да, проблема не в скраме.
TITnet
13.05.2016 09:55-1Зачем эти пятиминутки; зачем рассказывать то, что я делал вчера или что я буду делать сегодня, если это отражено в задачнике (условная Jira)?
Liquidos
>>Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.
Серьезно? Это же один из самых ненавистных и осмеиваемых моментов в работе менеджеров/начальников.
iivvaall
Нужность standup'ов где-то посерединке.
Если вокруг болото, каждый что-то пилит из своих соображений и общей цели нет и не предвидится, то они не нужны.
Наоборот, если все уже спроектированно и что делать понятно на месяц вперед, то они опять же не нужны.
А вот если есть командная работа, но нет возможности все спроектировать (не хватает квалификации или не ясны внешнеие требования) то scrum самое оно.
Aingis
Да, можно брать задачи из следующей очереди или помогать остальным, но кому это надо, когда и так всё хорошо? Суровым интровертам вообще сложно предложить кому-то свою помощь, а кому-то, наоборот, сказать, что нужна помощь. Да и тестировщики говорят, что им помощь не нужна, потому что разработчики больше мешать будут.