Титаническая и кропотливая работа) насколько активно те же топы или другой менеджмент пользуется самими дешами? Если активно, то это в рамках каких-то каденций или самостоятельно по необходимости?
Все верно, именно поэтому стори поинты хороши когда вам надо выровняться.
Но для квартальных и далее планирований стори поинты часто неточны. В том пункте мы говорим про кросс-командную работу - чтобы запланироваться толпой команд вместе, и вовремя выйти в прод. Так как все используют SP по-разному, надежность прогнозов когда именно та или иная команда сделает свой кусок работы низкая.
Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в Series B, с ~$780kk valuation, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.
Спасибо Станислав, мы с вами прекрасно знаем как в стартапе прекрасно работается с отказоустойчивой архитектурой и какие ресурсы были выделены в этом конкретном примере. В условиях ограниченного бюджета и конкретных штатных единиц более подходящим и управляемым оперировать в рамках описанной выше таксономии. Безусловно, вы как более опытный специалист и с опытом внедрения ITIL-а, как более мачурного фреймворка имеете обширный опыт в работе с инцидентами. Было бы здорово поработать с вами в будущем.
Это подмножество обычны метрикик реагирования на сбои, но если у вас есть конкретная NOC-команда - то она может отвечать и работать в рамках этих конкретных метрик. То есть именно они те самые предметные владельцы Response, Acknowledge, Assemble. А не кто-то еще. Это скорее особенность и KPI при такой таксономии отделов.
О, тож удобная вещь, все никак не доберусь.
Про приватность карточки — удобно звучит. Правда я бы сделал видимой карточку для всех по мере того как ребята добавляют их, но у всех все своё. Надо заценить.
о, супер, попробую.
У трелло самая большая загвоздка в том, что теперь тарифы не разрешают безлимитных досок для команд — и надо делать подписку в рамках atlassian suite.
Пробовал лично, в качестве рабочего инструмента нет. Мне вообще не очень понравилось как он работает (У меня — нестабильно, как и ringcentral, blue jeans).
Как я писал, нам актуально лочиться на экосистему Atlassian :)
1. Исторически сложилось, что в штатах больше FE, в РФ больше BE девелоперов. И хоть относительный фулстек был и там и там (.net), но для некоторых фич нужна была экспертиза бэкэнда тут в РФ.
2. Есть проекты с архитектурной т.з. требующие обоих сторон океана. Но, тут надо понимать, что domain область, то есть складская логистика и продакты у нас в штатах, и за прояснением вещей в нутре проекта надо их тыркать постоянно.
Конфигурация команд сейчас
— 2xFullstack RU на пожаротушение всякое;
— 2xFE, 1xBA, 1xQA US + 3xBE, 1xQA, 1xPM RU на один гигантский проект;
— ну и 1xFE, 1xBA US + 1xBE, 1xBA, 1xPM RU;
В общем, без взаимодействия никак. Но и без постоянной коммуникации можно работать продуктивно, и в распределенных командах.
3. При необходимости, можно делать географически распиленные команды, но пока найм сотрудников и его политика этого не позволяет, да и безумно много передачи знаний требуется меж континентов =)
Если вы про design sprints (могу ошибаться, ибо с принципом design thinking знаком постольку-поскольку), то все же мы отличаемся от него именно в сторону практичности/формализации.
То есть если в design thinking idea -> prototype -> test (именно в customer value формате), то у нас idea -> approve -> requirements + (prototype -> mockup -> design). То есть мы не пробуем разные идеи, а скорее реализовываем достаточно конкретные вещи, которые не надо уж прямо тестировать на пользователях (в оснвном).
User Story пишутся в соответствующем типе тикетов в жире.
4. Да, общая докментация тоже лежит в Confluence, но — там она периодически пополняется blog post'aми коллег, которые что-то где-то перепиливают. Вообще писать блог посты время от времени просят всех, ибо это показывает изменения в организации и порождает срачики в комментах, что мы все на работе любим =)
5. Если касаться фич и как оно должно работать, и кто обновляет как калькуляции в системе работают — иногда они устаревают. По мере того, как мы замечаем проблемы и расхождения с реалиями — документация поправляется. Если документ устарел — он не удаляется, а для ретроспективы остается, и в шапке пишется что более актуальная версия — вот она (и ссылка). Документации море, и что-то через сито просачивается, и становится неактуальным. Порой клиенты и партнеры по интеграциям на это тыкают. Вообще в конце видяшки из предыдущего пункта я об этом с гоготом рассказываю =)
6. Список полей в таблице пишется ручками, в жире, а потом копипастится в конфлюенс. В джире всегда будет более актуальная детализированная информация, потому что работа идет непосредственно в жире, а вики — это справка. А вот те же апи методы — документация по ним вполне может копипастится из того же постмана (поля, хотя б, и структура) =)
спасибо, незаметил :)
Спасибо за интересную статью.
Титаническая и кропотливая работа) насколько активно те же топы или другой менеджмент пользуется самими дешами? Если активно, то это в рамках каких-то каденций или самостоятельно по необходимости?
Наверное, если экстраполировать, он не работает эффективно для абсолютного большинства.
Я согласен с тем, что инструмент не самый простой, и поэтому на масштабе при отсутствии людей которые поддержат процесс он работает плохо.
Все верно, именно поэтому стори поинты хороши когда вам надо выровняться.
Но для квартальных и далее планирований стори поинты часто неточны. В том пункте мы говорим про кросс-командную работу - чтобы запланироваться толпой команд вместе, и вовремя выйти в прод. Так как все используют SP по-разному, надежность прогнозов когда именно та или иная команда сделает свой кусок работы низкая.
Я к тому чтобы не прогнозировать через SP.
Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в Series B, с ~$780kk valuation, в финтех рынке ЛАТАМа.
Глубины не предполагалось, потому что это только про знакомство с подходом. Оно скорее про то, чтобы задуматься и, возможно, попробовать у себя почелленджить. Для меня этот калькулятор - самый базовый инструмент, чтобы просто сделать быструю диагностику дел в компании.
Так и есть, команда целиком и полностью смотрит 24/7 на алерты, графики, и чат с саппортом. Эта команда под ключ которая этим и занимается.
Спасибо Станислав, мы с вами прекрасно знаем как в стартапе прекрасно работается с отказоустойчивой архитектурой и какие ресурсы были выделены в этом конкретном примере. В условиях ограниченного бюджета и конкретных штатных единиц более подходящим и управляемым оперировать в рамках описанной выше таксономии. Безусловно, вы как более опытный специалист и с опытом внедрения ITIL-а, как более мачурного фреймворка имеете обширный опыт в работе с инцидентами. Было бы здорово поработать с вами в будущем.
Это подмножество обычны метрикик реагирования на сбои, но если у вас есть конкретная NOC-команда - то она может отвечать и работать в рамках этих конкретных метрик. То есть именно они те самые предметные владельцы Response, Acknowledge, Assemble. А не кто-то еще. Это скорее особенность и KPI при такой таксономии отделов.
Про приватность карточки — удобно звучит. Правда я бы сделал видимой карточку для всех по мере того как ребята добавляют их, но у всех все своё. Надо заценить.
У трелло самая большая загвоздка в том, что теперь тарифы не разрешают безлимитных досок для команд — и надо делать подписку в рамках atlassian suite.
Как я писал, нам актуально лочиться на экосистему Atlassian :)
и еще политика компании сейчас именно страйд =)
2. Есть проекты с архитектурной т.з. требующие обоих сторон океана. Но, тут надо понимать, что domain область, то есть складская логистика и продакты у нас в штатах, и за прояснением вещей в нутре проекта надо их тыркать постоянно.
Конфигурация команд сейчас
— 2xFullstack RU на пожаротушение всякое;
— 2xFE, 1xBA, 1xQA US + 3xBE, 1xQA, 1xPM RU на один гигантский проект;
— ну и 1xFE, 1xBA US + 1xBE, 1xBA, 1xPM RU;
В общем, без взаимодействия никак. Но и без постоянной коммуникации можно работать продуктивно, и в распределенных командах.
3. При необходимости, можно делать географически распиленные команды, но пока найм сотрудников и его политика этого не позволяет, да и безумно много передачи знаний требуется меж континентов =)
То есть если в design thinking idea -> prototype -> test (именно в customer value формате), то у нас idea -> approve -> requirements + (prototype -> mockup -> design). То есть мы не пробуем разные идеи, а скорее реализовываем достаточно конкретные вещи, которые не надо уж прямо тестировать на пользователях (в оснвном).
— www.slideshare.net/mobile/LuxoftAgilePractice/user-story-canvas
— nomad8.com/acceptance_criteria
— www.romanpichler.com/blog/10-tips-writing-good-user-stories
— www.mountaingoatsoftware.com/agile/user-stories
— www.mountaingoatsoftware.com/uploads/documents/adding-detail-to-user-stories.pdf
— www.modernanalyst.com/Resources/Articles/tabid/115/ID/4903/5-Common-User-Story-Mistakes.aspx
3. High-level описание фичи пишется в confluence article, которая связана с эпиком 1 к 1. Мы тут как раз на последнем митапе кратко про цикл документооборота в confluence разговаривали.
User Story пишутся в соответствующем типе тикетов в жире.
4. Да, общая докментация тоже лежит в Confluence, но — там она периодически пополняется blog post'aми коллег, которые что-то где-то перепиливают. Вообще писать блог посты время от времени просят всех, ибо это показывает изменения в организации и порождает срачики в комментах, что мы все на работе любим =)
5. Если касаться фич и как оно должно работать, и кто обновляет как калькуляции в системе работают — иногда они устаревают. По мере того, как мы замечаем проблемы и расхождения с реалиями — документация поправляется. Если документ устарел — он не удаляется, а для ретроспективы остается, и в шапке пишется что более актуальная версия — вот она (и ссылка). Документации море, и что-то через сито просачивается, и становится неактуальным. Порой клиенты и партнеры по интеграциям на это тыкают. Вообще в конце видяшки из предыдущего пункта я об этом с гоготом рассказываю =)
6. Список полей в таблице пишется ручками, в жире, а потом копипастится в конфлюенс. В джире всегда будет более актуальная детализированная информация, потому что работа идет непосредственно в жире, а вики — это справка. А вот те же апи методы — документация по ним вполне может копипастится из того же постмана (поля, хотя б, и структура) =)
Если это был эпик с историями — то оно переносится такой же структурой в проект реализации =)