Вот примерно эту история я каждый раз вспоминаю про регламенты :) Мне кажется намного лучше работает мессадж СЕО / ГД о том, как он видит культуру компании, а дальше дело за руководителями на местах. А садиться и писать регламент для всех имхо штука сомнительная

Регламенты как и код могут и должны изменяться, адаптироваться.

Это в рамках agile-философии

на практике-то... :)

Ну огурец все же на стыке. На месте разработчика я бы тоже пугался. Вы ему и аналитику и саппорт задачи накидали

угу. Вот это и называется "корпо-мышление", "не моя работа - делать не буду". Кто, кроме автора, лучше знает критические точки проверки сервиса? У кого доступ к данным и инфре для синхронизации UAT с продом? Кто, кроме QA, должен интегрально следить за качеством? Но он же, блин, девелопер, а не опс, а QA у нас такой QA...

Но можно, конечно, потратить 15-20 часов аналитика, чтобы он сначала потратил 3 часа девелопера, потом написал доку, потом согласовал...

При росте масштаба всегда возникают новые процессы, которых нет в маленьких командах. Как их обычно решают?

По поводу докер - я недавно гуглил себя инструмент для простых смертных для управления инфраструктурой - его нет. DevOps это очень сложно ;/

Не смотрел в сторону last.backend?

По поводу докер - я недавно гуглил себя инструмент для простых смертных для управления инфраструктурой - его нет. DevOps это очень сложно ;/

Прям совсем нет? А как же rancher, photon?

После heroku хочется чтоб совсем был минимум влезаний в консоль

https://jujucharms.com - вот такую штуку смотрел давно, но я так понял массово она не взлетела

поручи штатному девопсу

/me убегает и прячется

у нас от девопса в команде только философия :D

это шутка :-)

наймите админа чо

Не, в священной книге там было четко написано, 11. Не нанимай админов. Стерлось со временем.

Но можно, конечно, потратить 15-20 часов аналитика, чтобы он сначала потратил 3 часа девелопера, потом написал доку, потом согласовал...

У разраба же совсем другие задачи, ему сложнее перестроиться и решить эту задачу. Его так и на тестирование рразработанного посадить можно. Как де кросс-функциональность?

Не, в священной книге там было четко написано, 11. Не нанимай админов. Стерлось со временем.

а тогда наймите админа который знает что такое девопс ))

Вы рискуете запустить второй раунд обсуждения DevOps!

У разраба же совсем другие задачи, ему сложнее перестроиться и решить эту задачу. Его так и на тестирование рразработанного посадить можно. Как де кросс-функциональность?

алярма! девелопер должен проверять, что он девелопит! :) кросс-функциональность - это как раз про "не стыдиться сделать кусок нужной и важной работы, хотя и не своей" :) другое дело, что тратить часы девелопера на функциональные тесты дорого, и лучше так не делать, если есть возможность.

Вы рискуете запустить второй раунд обсуждения DevOps!

это я могу ))

обертку вокруг кукумбера (spec_helper.rb, например), или там вагрантфайл какой-нибудь не каждый же участник команды пишет? делает кто-то один, потом по мере необходимости и желания любой может туда коммиттить. со всеми девопс-штучками тот же подход, только компонент этот не на десяток строк, а чуть крупнее

алярма! девелопер должен проверять, что он девелопит! :) кросс-функциональность - это как раз про "не стыдиться сделать кусок нужной и важной работы, хотя и не своей" :) другое дело, что тратить часы девелопера на функциональные тесты дорого, и лучше так не делать, если есть возможность.

кросс-функциональность - это же "в команде есть все необходимые компетенции", а не "все всё умеют"

алярма! девелопер должен проверять, что он девелопит! :) кросс-функциональность - это как раз про "не стыдиться сделать кусок нужной и важной работы, хотя и не своей" :) другое дело, что тратить часы девелопера на функциональные тесты дорого, и лучше так не делать, если есть возможность.

Это называется человек-оркестр, а не кросс-функциональная команда :)

https://www.youtube.com/watch?v=UADD1fB3lIE у нас тут недавно был повтор этой игры, и меня прям порадовало. И тут как раз видно что если есть ограничение то пока другие простаивают они могут заниматься теми же тестами и документацией

Это называется человек-оркестр, а не кросс-функциональная команда :)

это называется "культура разработки" и минимизация TTM. Можно 80% девелопить и 20% - писать доки/помогать и т.д. Процентное соотношение зависит от продукта и состава команды.

заведи фичу (которая скоро станет эпиком 😜 ) "As a developer I want to spin up new environment easily", потом следующую фичу-эпик "As a developer I want to detect when my app goes down". а скоро и начнешь всем говорить "у нас девопс" :-)

Иначе все на свете затыкается советом "наймите еще чувака на эту роль" (организуйте себе bus-factor и потратьте деньги собственника еще быстрее).

а уже нужны или нет подобные фичи (и за их цену) -- виднее владельцу и команде, а не кому то еще

подумалось, сколько человекчасов сожжено на обсуждение этой темы)) помножим на рейт теперь ;)

подумалось, сколько человекчасов сожжено на обсуждение этой темы)) помножим на рейт теперь ;)

как человеку, свободному от оклада с обязательными часами присутствия, можно мне не чувствовать себя виноватой? :)

У меня, кстати, есть вопрос. Что вы делаете, если в команде недостаток компетенций? Например, нет аналитика, QA, админа? Сапорта? Скоуп продукта/проекта, необходимость в коммуникациях при этом не меняется. Мой личный опыт и опыт лидов моих команд на консалтинге - про то, что затыкают собой (часто, особенно маленькие) /уговаривают команду (реже). Ну, либо ходят по корпорату кругами и говорят "не шмог... нет QA.... дайте ресурсов" (иногда правда:)) Как у вас?

затыкаем собой

Затыкаем))

затыкаем и жалуемся, озвучиваем риски, предлагаем кандидатов

а что с основной работой при этом происходит? ну то есть PrM-у и проджекту нужно время на свои основные обязанности + всякие стратегические размышления :)

Провал))))

Коллеги, всем привет! Я тут собираюсь за праздники подготовить тему к ближайшему АДу, и, учитывая последние горячие обсуждения здесь, в соседних группах и на митапах, думаю здесь очень подходящая аудитория, чтобы задать вопрос. Собственно, о чем бы вы хотели послушать доклад на конференции?) Хочется сделать доклад интересным и востребованным) О чем я знаю и есть опыт: "православный" скрам (почти любые аспекты), работа со скрамом в маленькой компании (про масштабирование рассказывать не буду, ибо реального опыта нету), канбан в маркетинге (и вообще агилизация маркетологов) ну и всякие глубинные темы из этих трех. Есть какие-нибудь пожелания? Особенно интересно услышать людей, которые пойдут на АД, либо будут смотреть записи потом =)

Канбан в маркетинге!

С рисками и классами сервисов!

Канбан в маркетинге!

без смс и регистрации своими руками

Вот по идее, в православном Скраме - инновации продукт коллективного труда. Но я что-то не могу вспомнить ни одной инновации, которая была создана коллективно.

Скорее инновация принадлежит PO, а команда ищет способы её реализовать.

по идее, у PO есть вижн но будем честны, даже в самых инновационных продуктах – создатели обычно постфактум признаются, что многие идеи были сгенерены командой)

А вот где?

ну кто там у нас икона продукта?)) вон Джобс на историческом интервью с Гейтсем говорил, что "у меня просто классные люди работают, я тут не причем" понятно, что все это слова, но в каждой шутке доля шутки

агилизация маркетологов без смс :)

скрам говорит, что создание инновационного продукта – результат деятельности команды кто конкретно придумал инновацию – не так важно)

Почему меня это волнует - коллектив должен поощрять в этом случае индивидуальный эксперимент

А тут заказчик не команда

По сути да, по факту - носитель vision и это пропАгандируется. И тогда скрам сразу заменяется на growth team :)

У кого тут есть команды роста?

А тут заказчик не команда

стопэ

как так?

Команда не является заказчиком

Она может идти в бэклог, но бэклог принадлежит PO

А инновация это результат эксперимента, то есть чтобы реально понять будет ли ВАУ эффект - надо пушить, а не с PO согласовывать

Инновации же в хаосе рождаются, в хаосе - действие первично

Кароче могу подвести к тому, что скрам душит реальные инновации таким образом. Тыдыщ

Конечно можно сказать, что давайте сделаем капасити на личные эксперименты команды... :]

Но это дорога сами знаете куда

Если использовать термин growth team, то в каспере есть growth teams, в битриксе, вообще если команда участвует в наполнении бэклога и форсайтит, то это туда :)

А они чего-нибудь про себя рассказывают?

обычно в маленьких командах growth team можно называть = маркетинг+продакт+активные ребята (типа лидов с производства и из сапорта)

У Ильи Кузнецова на Agile Days 2015 был доклад. Он называет это "команда пиратов". Правда, из Каспера он ушел уже.

Да в теории там все понятно - собрали веселых ребят в компании (серьезно), они генерят идеи - мы их проверяем и смотрим на изменение метрик

посмотрю, спасибо

Затык наступает на месте "мы их проверяем и смотрим на изменение метрик" :)))

Илья Кузнецов я так понимаю продолжил свой подход в телекоме

Затык какой, технологический?

в "активных ребятах" должны быть те, кто быстро лепит :)

По идее вписать growth team в скрам - выглядит логично, но вот с точки зрени ритуалов и процесса работы с PO* вроде противоречие есть.

Затык какой, технологический?

когда как. Чаще организационный - слота на разбазаривание людей на эксперименты обычно нет, аналитика не собирается и решение о наборе метрик никто нормально принять не может. Аналитиков продуктовых тоже... Нет связи с оунером бизнеса и критериев, когда результат эксперимента ок.

Да ну-у-у, опять взяли какой-то большой бизнес, где попытались в рамках существующих ограничений запускать то, что по задумке создано все ограничения сразу ломать :)

Нет в большом бизнесе гибкости, н е т у

когда как. Чаще организационный - слота на разбазаривание людей на эксперименты обычно нет, аналитика не собирается и решение о наборе метрик никто нормально принять не может. Аналитиков продуктовых тоже... Нет связи с оунером бизнеса и критериев, когда результат эксперимента ок.

Постоянно такое

Чаще всего компания четко понимает какой функционал надо запустить примерно на год вперед. Времени на эксперименты просто нет.

Ресурсов тоже.

Чаще всего компания четко понимает какой функционал надо запустить примерно на год вперед. Времени на эксперименты просто нет.

Угу. "Что тут думать, трясти надо" :)

Слушайте, ну "я тебя слепила из того что было, а что было то и запустила" это не про growth team %))