Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
>>Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.
Серьезно? Это же один из самых ненавистных и осмеиваемых моментов в работе менеджеров/начальников.
Серьезно? Это же один из самых ненавистных и осмеиваемых моментов в работе менеджеров/начальников.
Нужность standup'ов где-то посерединке.
Если вокруг болото, каждый что-то пилит из своих соображений и общей цели нет и не предвидится, то они не нужны.
Наоборот, если все уже спроектированно и что делать понятно на месяц вперед, то они опять же не нужны.
А вот если есть командная работа, но нет возможности все спроектировать (не хватает квалификации или не ясны внешнеие требования) то scrum самое оно.
Если вокруг болото, каждый что-то пилит из своих соображений и общей цели нет и не предвидится, то они не нужны.
Наоборот, если все уже спроектированно и что делать понятно на месяц вперед, то они опять же не нужны.
А вот если есть командная работа, но нет возможности все спроектировать (не хватает квалификации или не ясны внешнеие требования) то scrum самое оно.
Ежедневные пятиминутные митинги это хорошо, если:
1. Действительно 5 минут;
2. Количество людей не очень большое.
1. Действительно 5 минут;
2. Количество людей не очень большое.
Первому подходу даже название придумали — ScrumBan.
А про боль — это признак что надо что то лечить: либо в нашей работе мы делаем что то не так (например нам скучно на стендапах, потому что мы не работаем командно, а работаем индивидуально), либо что то менять надо в процессах: стандартные не подходят, либо мы их не так поняли, либо…
В общем в любом случае надо над болями работать на ретроспективе.
А про боль — это признак что надо что то лечить: либо в нашей работе мы делаем что то не так (например нам скучно на стендапах, потому что мы не работаем командно, а работаем индивидуально), либо что то менять надо в процессах: стандартные не подходят, либо мы их не так поняли, либо…
В общем в любом случае надо над болями работать на ретроспективе.
Второй подход — это уже не спринт, а релиз.
Daily meeting реально помогает, но только если команда дейсвительно небольшая(4-6 человек) и он действительно идет не более 5-10 минут.
Основная ценность daily meeting для моей команды состоит в том, что я могу оперативно выявлять возникшие проблемы. Бывает сидит человек, копается в каком-то фреймворке/библиотеке. Ему кажется что вот-вот, еще чуть-чуть и все заработает… И так минул день… Хотя реально там нужно подтянуть какой-то сторонний пакет, дописать две строчки кода и все, проблема решена.
И да, как говорили выше, daily meeting хороши, если они действительно 5 минут. Если время за 5 минут выходит, тогда нужно уже отдельно с человеком садиться и разбираться что у него не так.
P.S.: управляю командой из 4 человек, все на 100% удаленке.
Основная ценность daily meeting для моей команды состоит в том, что я могу оперативно выявлять возникшие проблемы. Бывает сидит человек, копается в каком-то фреймворке/библиотеке. Ему кажется что вот-вот, еще чуть-чуть и все заработает… И так минул день… Хотя реально там нужно подтянуть какой-то сторонний пакет, дописать две строчки кода и все, проблема решена.
И да, как говорили выше, daily meeting хороши, если они действительно 5 минут. Если время за 5 минут выходит, тогда нужно уже отдельно с человеком садиться и разбираться что у него не так.
P.S.: управляю командой из 4 человек, все на 100% удаленке.
Может быть я и «бунтарь», но пусть митингами занимаются менеджеры. В маленькой компании, где нет менеджеров как таковых — это нормально, сидя за рабочим столом пообщаться по проекту, что сделано, что предстоит сделать. Иначе это затягивается каждый раз на неопределенное время, которое может быть потрачено на разработку. Я как интроверто-программист не совсем люблю выступать. Имхо.
>> Так вот, демо — это хороший шанс узнать, что нового появляется в продукте.
Лучше сделать вики, где будут описываться все фичи и исправления добавленные в проект, это позволит вернуться к их прочтению и корректировке в дальнейшем. Ну и, допустим, если необходимо держать команду в курсе, то лучше 5-минутные митинги заменить на 5-минутное прочтение обновлений вики, зато это будет сделано в комфортное время для каждого.
>> Так вот, демо — это хороший шанс узнать, что нового появляется в продукте.
Лучше сделать вики, где будут описываться все фичи и исправления добавленные в проект, это позволит вернуться к их прочтению и корректировке в дальнейшем. Ну и, допустим, если необходимо держать команду в курсе, то лучше 5-минутные митинги заменить на 5-минутное прочтение обновлений вики, зато это будет сделано в комфортное время для каждого.
>>Может быть я и «бунтарь», но пусть митингами занимаются менеджеры.
В скраме нет менеджеров. В скраме все решает комманда, и если комманда решает что то не брать в спринт, то это не берется в спринт. В скарме есть скрам мастер, который должен защищать команду от давления со стороны менеджеров.
Если в скраме появляется менеджер, то всегда получается waterfall со стендапами
А демо, это способо показать, что собственно комманда нарешала и сделала по факту. Не на бумаге (вики), а в жизни и со всеми багами которые вылезли прямо во время демо
В скраме нет менеджеров. В скраме все решает комманда, и если комманда решает что то не брать в спринт, то это не берется в спринт. В скарме есть скрам мастер, который должен защищать команду от давления со стороны менеджеров.
Если в скраме появляется менеджер, то всегда получается waterfall со стендапами
А демо, это способо показать, что собственно комманда нарешала и сделала по факту. Не на бумаге (вики), а в жизни и со всеми багами которые вылезли прямо во время демо
У меня к scram'у двоякое отношение. Я работал в команде где ввели scram около года назад. Вроде бы все правильно и качество продукта должно было подняться, но к сожалению, по-моему мнению, качество ухудшилось. ТЗ более не продумывались так глубоко как до введения sram'a, вплоть до того что на демо-митинге выяснялось что разработка отдельных фич шла совсем не в том направлении. Документация стала вестись кое-как (если вообще велась).
Я считаю что srum это неплохая методология, но иногда команда начинает терять из виду общую картину. Что к сожалению чревато.
Я считаю что srum это неплохая методология, но иногда команда начинает терять из виду общую картину. Что к сожалению чревато.
У вас какие-то безумно длинные итерации. Месячный спринт подразумевает что за месяц объем работ не изменится, а значит лишается та самая гибкость методологии. Я не прав?
Скрам это хороший инструмент. Он не работает там где его не правильно поняли и не правильно используют.
Причина зачем нужны дейли — синхронизация и микропланирование. Мало кто делает дейли до конца и заканчивают только синхронизацией сами не понимая зачем. Регулярно звучат комментарии «по борде видно кто чо делает». Это так. Но правильный флоу дейли это проговорить структурировано о состоянии задач в прогрессе и о следующих планах и скорректировать эти планы конкретно на месте. Когда собрана вся команда, это сделать проще нежели решать через чат или через скайп. Эти 5-10 минут себя окупают, получается с глазу на глаз все согласовать на сегодня-завтра намного быстрее. Плюс, важна неформальная обстановка. Я предпочитаю проводить дейли на улице, благо офис позволяет и мы на 2м этаже а улица выходит в наш собственный дворик со столиком. В любое время года на улице хорошо. Жопе, спине и голове легче нежели ютится в каких то проходах или переговорках где витает атмосфера бюрократии.
Основная фишка скрама это команда>клиент&менеджер. Скрам дает команде картбланш. Команда имеет право решить что она будет делать и делать это так что бы ни кто их не трогал ровно спринт. Какие то новые вбросы, дедлайны? Пошли к черту. Что то надо поправить срочно на продакшене? Пошли к черту, нанимайте сапорт или девопс.
Самая главная фишка без которой не работает скрам вообще это Difinition of Done. У команды должен он быть. Команда выпустит фичи за спринт те которые она успеет и те которые будут на 100% соответстовать DoD. Они будут закончены, они будут протестированы, код будет отрефакторен, задокументирован, и готов как полноценный инкремент. Команда в конец спринта представляет конкретный инкремент готового функционала, а всё что в прогрессе остается в отдельных ветках. Всё.
Дальше уже право заказчика или менеджера интегрировать инкремент на продакшн или ждать новый. Базовыми метриками менеджер легко вычисляет скорость команды. Что потрачено у каждого 40ч, а задач поделано с оценками сумарно на 20ч, итого скорость 20ч или 50% от номинала. С каждым спринтом эта цифра будет стабилизироватся и будет отличное понимание Велосити. С ним уже можно работать, воспитывать людей или менять или добавлять кого то еще в команду, докручивать процессы, искать причины такого велосити. Вот где компетентность менеджера.
Чаще всего я вижу, что менеджеры пытаются быть сразу скрам мастерами и внешними менеджерами. Они начинают внутри спринта устраивать свое подобие вотерфола и классики, начинать вкидывать по ходу спринта еще задач потому что клиент ему на почту написал и в скайп продублировал. И это превращается уже не в скрам а в *скрамНО.
Беда скрама в том что его не правильно готовят. И не там применяют. И тем более, команда не готова к скраму, она не обучена по нему работать, и одни процессы скрама подменяются какими то похожими издалека подобиями. Если люди не могут понять истинной пользы и сути дейли, при этом активно скрамясь то я боюсь предположить как делаются оставшиеся скрам активности.
На ретроспективе наверное менеджер всем в лоб по очереди задает вопросы «Артём, что у нас на этом спринте было хорошо а что плохо?» и получает ответ «Ээээм, ну х%1 его знает».
Причина зачем нужны дейли — синхронизация и микропланирование. Мало кто делает дейли до конца и заканчивают только синхронизацией сами не понимая зачем. Регулярно звучат комментарии «по борде видно кто чо делает». Это так. Но правильный флоу дейли это проговорить структурировано о состоянии задач в прогрессе и о следующих планах и скорректировать эти планы конкретно на месте. Когда собрана вся команда, это сделать проще нежели решать через чат или через скайп. Эти 5-10 минут себя окупают, получается с глазу на глаз все согласовать на сегодня-завтра намного быстрее. Плюс, важна неформальная обстановка. Я предпочитаю проводить дейли на улице, благо офис позволяет и мы на 2м этаже а улица выходит в наш собственный дворик со столиком. В любое время года на улице хорошо. Жопе, спине и голове легче нежели ютится в каких то проходах или переговорках где витает атмосфера бюрократии.
Основная фишка скрама это команда>клиент&менеджер. Скрам дает команде картбланш. Команда имеет право решить что она будет делать и делать это так что бы ни кто их не трогал ровно спринт. Какие то новые вбросы, дедлайны? Пошли к черту. Что то надо поправить срочно на продакшене? Пошли к черту, нанимайте сапорт или девопс.
Самая главная фишка без которой не работает скрам вообще это Difinition of Done. У команды должен он быть. Команда выпустит фичи за спринт те которые она успеет и те которые будут на 100% соответстовать DoD. Они будут закончены, они будут протестированы, код будет отрефакторен, задокументирован, и готов как полноценный инкремент. Команда в конец спринта представляет конкретный инкремент готового функционала, а всё что в прогрессе остается в отдельных ветках. Всё.
Дальше уже право заказчика или менеджера интегрировать инкремент на продакшн или ждать новый. Базовыми метриками менеджер легко вычисляет скорость команды. Что потрачено у каждого 40ч, а задач поделано с оценками сумарно на 20ч, итого скорость 20ч или 50% от номинала. С каждым спринтом эта цифра будет стабилизироватся и будет отличное понимание Велосити. С ним уже можно работать, воспитывать людей или менять или добавлять кого то еще в команду, докручивать процессы, искать причины такого велосити. Вот где компетентность менеджера.
Чаще всего я вижу, что менеджеры пытаются быть сразу скрам мастерами и внешними менеджерами. Они начинают внутри спринта устраивать свое подобие вотерфола и классики, начинать вкидывать по ходу спринта еще задач потому что клиент ему на почту написал и в скайп продублировал. И это превращается уже не в скрам а в *скрамНО.
Беда скрама в том что его не правильно готовят. И не там применяют. И тем более, команда не готова к скраму, она не обучена по нему работать, и одни процессы скрама подменяются какими то похожими издалека подобиями. Если люди не могут понять истинной пользы и сути дейли, при этом активно скрамясь то я боюсь предположить как делаются оставшиеся скрам активности.
На ретроспективе наверное менеджер всем в лоб по очереди задает вопросы «Артём, что у нас на этом спринте было хорошо а что плохо?» и получает ответ «Ээээм, ну х%1 его знает».
Всё верно. Я обычно добавляю «скрам придумывали не идиоты, и многие мелочи существуют в нём неспроста».
Тут важный момент, что если userstory удовлетворяет Definition of Done, то команда сама должна понять как сделать «непрописанные мелочи» правильно и эффективно, именно на её экспертизу и рассчитывается. Но, к сожалению, ответственность на себя брать люди не всегда хотят, а тогда уже ни скрамом, ни эджайлом не пахнет.
Мы много жаловались на то, что в задачах не было прописано всё до мелочей
Тут важный момент, что если userstory удовлетворяет Definition of Done, то команда сама должна понять как сделать «непрописанные мелочи» правильно и эффективно, именно на её экспертизу и рассчитывается. Но, к сожалению, ответственность на себя брать люди не всегда хотят, а тогда уже ни скрамом, ни эджайлом не пахнет.
Зачем эти пятиминутки; зачем рассказывать то, что я делал вчера или что я буду делать сегодня, если это отражено в задачнике (условная Jira)?
Введите ежедневные пятиминутные митинги — они нужны не только вам для понимания ситуации в проекте, но и участникам команды.
Тут просто обязана быть эта фотка
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum. Взгляд программиста