Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в 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. Список полей в таблице пишется ручками, в жире, а потом копипастится в конфлюенс. В джире всегда будет более актуальная детализированная информация, потому что работа идет непосредственно в жире, а вики — это справка. А вот те же апи методы — документация по ним вполне может копипастится из того же постмана (поля, хотя б, и структура) =)
Опыт написания этого поста как раз вышел из работы в стартапе, и применим к стартапам - это я знаю точно =) Стартапе в 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. Список полей в таблице пишется ручками, в жире, а потом копипастится в конфлюенс. В джире всегда будет более актуальная детализированная информация, потому что работа идет непосредственно в жире, а вики — это справка. А вот те же апи методы — документация по ним вполне может копипастится из того же постмана (поля, хотя б, и структура) =)
Если это был эпик с историями — то оно переносится такой же структурой в проект реализации =)