Многогобеклоговость

Здесь мы обсуждаем вопросы совместной работы в команде и с командами (Scrum, Kanban, TOC и прочий Lean)
Ответить
Аватара пользователя
Serge
Сообщения: 7
Зарегистрирован: Вт июл 07, 2015 9:56 pm
Контактная информация:

Многогобеклоговость

Сообщение Serge »

Добрый день!
Давно хотел задать ворпос, но наконец-то дошли руки.

У нас в компании исторически сложилась 2х беклоговость. Есть люди спринта, которые из спринт-беклога работают, а есть люди на пейджере - 24/7 поддержка нашего продукта в проде. Если серваки упадут или юзер попадет на 500/404/и т.п. - тогда этот человек-пейджер побежит все чинить. Т.к. это может произойти в любое время, то на него не рассчитывают на планинге. Но чтобы он наносил пользу в штиль, он починяет задачи из 2го беклого - технический долг убирает. Честно говоря, у того пейджера 2 беклога - пейджерный и долговой, но это уже не суть. Педжером бывают все девелоперы, посменно.

Но 2 беклога это еще куда ни шло. В нашей команде придумали больше!

Есть еще беклог для недо-историй (у которых нет подзадач, или нечеткие зависимости, или неполные спеки, или т.п.) - в этом беклоге работает кто-то из спринтовых людей, добавляя больше инфы в истории и готовя задачу к попаданию в продакт-беклог, из которого ее можно брать уже в спринт. 1 история - 1 чел. Этот (эти) избранный(е) чел. работает(ют) сразу из 2 беклогов - спринтового и недо-исторного.

Потом есть еще другие беклоги (для QA, для багов), но они рудиментрарные - отходят на нет и сливаются с продакт/спринт.

Итого:
* продакт и спринт (из верхушки продакт)
* тех. долг.
* пейджер (потенциально может быть смержен с тех. долг.)
* недо-истории

Все это приводит к тому, что мы часто плывем по swim lanes. Слишком ли это плохо? И как это можно улучшить?

Но больше меня волнует то, что 1 чел ВСЕГДА на пейджере, и когда кто-то уходит в отпуск или заболевает, то мы можем скатиться до 1-2 чел на спринт-беклог (в одну неделю у нас даже 0.5 людей было на спринт). Может нам скрам вовсе не подходит при таком раскладе и проще перейти на канбан или еще чего похлеще?

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Многогобеклоговость

Сообщение Максим Дорофеев »

Есть у меня такое ощущение, что нужно в итоге оставить только ОДИН беклог :)
Дежурному по пейджеру только лишь дается право бросить ту задачу, которой он занимается, чтобы побежать и начать все чинить.

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

Есть у меня еще одно ощущение... В попытке прийти к одному беклогу наружу всплывет ряд неприятных особенностей как ребят из команы, так и окружающих людей. Да? ;)

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

Аватара пользователя
Serge
Сообщения: 7
Зарегистрирован: Вт июл 07, 2015 9:56 pm
Контактная информация:

Re: Многогобеклоговость

Сообщение Serge »

cartmendum писал(а): Есть у меня еще одно ощущение... В попытке прийти к одному беклогу наружу всплывет ряд неприятных особенностей как ребят из команы, так и окружающих людей. Да? ;)

Ну типа там менеджер орет, когда что-то продалбывается или ребятам хочется делать только понятное и не нравится ковыряться в собственном же говнокоде... Похоже?..
Да, наш случай. Хоть я и недолго в команде, но уже начал чувствовать это. Вся грязная работа (говнокод - тех долг (код не особо пахнет и не особо сложный, скорее старый/чужой)) и баги продуктива (пейджер) - отправляются на откуп человека-пейджера. Но частенько, он вовлекается в спринтовую работу (планнинги, эстимейты, и т.п., что противоречит начальным договоренностям, что он гребет только свои беклоги, но "куда дется - нужен же его инпут"). Это приводит к тому, что тех. долг откладывается в дальний ящик. Еще был момент, когда пропихивали таск из тех. долга в спринт, но тогда начальник сильно волновался, т.к. спринт не давал бизнес-велью, а если таск по причине зависимостей от других команд стопорился вовсе - то и того пуще.

Еще у нас недавно казус случится: оказалось, что начальник потерял веру в нас и стал микро-менеджить, т.к. мы не можем сами разгрести все наваливающееся сверху. Он доволен, что показал силу (отменил скрам (until further notice), накидал миллион тасков в спринт, назначил исполнителей и назвал это канбаном). Команда демотивировалась. Все взволновавшиеся получили мгновенный отрицательный фидбек. Причем это произошло на след. день после ретро, где ничего не предвещало беды. Ждем развития событий.
cartmendum писал(а): Есть у меня такое ощущение, что нужно в итоге оставить только ОДИН беклог :)
Да, мы все того же мнения, включая начальника, но по странным стечениям обстоятельств и расходящимися предположениями/ожиданиями, беклоги все не уменьшаются.
cartmendum писал(а):Если я правильно понял, то в команде у вас 4-5 человек. Для такой команды 4 беклог - это очень много и излишне все усложняет.
Да, 3 дева, 1 тестер + 1 новый дев и 1 новый тестер. 4 чела покинули команду около 3 мес назад.

Аватара пользователя
Максим Дорофеев
Site Admin
Сообщения: 1980
Зарегистрирован: Вс июн 28, 2015 1:56 pm
Контактная информация:

Re: Многогобеклоговость

Сообщение Максим Дорофеев »

Ну вот... По факту много беклогов - это симптом более глубинных проблем. А начальник, скорее всего, не в вас разочаровался (это редко происходит незаметно и резко), скорее всего ему его руководство довольно сильно присунуло за вас. И тут явно без скрама с 4-мя беклогами не обошлось :)

Поговорили бы с ним об этом при случае...

Кстати, а чья была идея наплодить столько беклогов?

Аватара пользователя
dron
Сообщения: 43
Зарегистрирован: Вт июн 30, 2015 5:22 pm

Re: Многогобеклоговость

Сообщение dron »

У нас немного другая проблема. У нас в проекте только разработчиков человек 30. Несколько команд.
У нас конечно есть глобальная цель. Но так сложилось, что приоритеты у каждой команды свои.
И это уже вызывает проблемы в том случае, если между командами возникают точки соприкосновения.
Надо помочь, но у нас свой приоритет. А они заблочились...

Поэтому на мой взгляд беклог вообще должен быть один. Один на всю компанию. :)
@Serge: В принципе нет ничего плохого, если недопонятые задачи просто пыляться в беклоге. Они вовсе не обязательно должны быть проработаны. Если приходит заказчик и слезно просит - ну ок, давайте разбираться. На планировании например... Можно взять задачу в спринт (то есть посвятить ей некоторое время) чтобы прояснить некоторые моменты, которые на планировании невозможно прояснить.

comm
Сообщения: 44
Зарегистрирован: Вт окт 06, 2015 12:32 pm
Откуда: Saint-Peterburg, RU
Контактная информация:

Re: Многогобеклоговость

Сообщение comm »

@dron Самый простой способ разрулить приоритеты беклогов, это жестко согласовать приоритеты проектов.
Если проект приоритетный, то ВСЯ компания работает ТОЛЬКО на это проект.

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

Таким образом, можно придти к
* ресурсное планирование
* управление рисками
* оценка проекта по ИСР
и другим хорошим штукам описанным в PMBoK.

только один минус в этом: появится налог налогом на организацию проекта.

@Serge Зачем пихать в беклог то что не является элементом работы которую можно выполнить?

Для таких недо историй лучше использовать Вики потму что:
* информация накапливается
* пока лежит она обдумывается
* что-то дописывается.
* к ней можно всегда вернуться так как она лежит в структурированном правильном виде.
* в статью можно дописать архитектруное решение
* статью можно обсудить.
* когда информация созревает она становится задачей и уходит в беклог.

Однако есть особенность в том, что нужно отходить от практике "я делаю только что в задаче" к практике "ок я поработал над задачей, надо подумать над стартегией, не написать ли мне что0-то в вики?"

то есть хождение в базу знаний должно быть регулярным, потмоу что это и будет тем самым "непрерывным улучшением " которое лежит в основе Kanban, TQM, Lean и Agile.

Касательно тех долга, зачем его вообще отдельно трекать? Это тоже самое что делать новые линии цветных карточек на Kanban производестве (см книжку Цель) , Вы не должны накапливать технический долг, если вы его накопите то проценты по нему вас накроют. В филофии TQM такие задачи вы должны делать в первую очередь и соовтестветственно нужно резервировать время в спринте.

Например:
70% - спринта - достижение целей
30% - поддержка

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

Более хорошо это рассказано в книже Голдрадтта и Кокса "Цель" http://www.ozon.ru/context/detail/id/26 ... tner=sbase
С уважением, Алексей Васильев. http://bipulse.ru

Ответить