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

Если все задачи сначала идут через дизайн пакетом, потом через разработку пакетом, потом через тестирование пакетом - это вотерфолл

А если рассматриватькадый элемент бэклога как минипроект, то ...

А если рассматриватькадый элемент бэклога как минипроект, то ...

Интересно было бы послушать только.. я боюсь публичных выступлений, когда много слушателей.. максимум на 10-15 чел.. больше-теряюсь:-/

👋 Всем привет! 30 мая мы собираемся провести митап о ретроспективе в офисе HFLabs. Планируется живой разговор, обмен опытом и граблями. Ретроспектива — полезный инструмент для улучшения процессов и роста команды разработки. Но часто получается, что из раза в раз обсуждаются одни и те же проблемы, а лучше не становится. В конечном итоге люди задаются вопросом: «А зачем нам вообще нужно тратить время на ретроспективы?» Если вы проводите или участвуете в ретроспективах и когда-нибудь задавались похожим вопросом, то мы приглашаем обменяться опытом на митапе о ретроспективах. С нас — пицца и кофе, с вас — истории успеха и провала. Проводить митап будет Миша Берёзин, он занимается развитием «Единого клиента» HFLabs. Все вопросы можно задать ему в личку — @mikeberezin. Встреча будет проходить 30 мая с 18:00 до 20:00 в офисе HFLabs по адресу Москва, Турчанинов переулок, д. 6 стр. 2, БЦ «Крымский мост» (https://goo.gl/kyxp1b). ✅ Условие участия — рассказ на 5-10 минут о том, как ретроспектива проходит в вашей компании. ✅ Записаться: https://clck.ru/DM22r

а вы запись случайно не будете делать? было бы интересно посмотреть

Хз. Мы более-менее большие проекты всеравно стараемся прорабатывать до позадач, чтобы понимать их объём и потенциальную стоимость. А против того, чтобы запускать 3 проекта одновременно есть аргумент - конечный результат от хотябы одного из них будет получен примерно через тот промежуток времени, который займёт сумма времени по всем трём проектам. Выполняя же их последовательно, можно получать результат гораздо раньше. Если они примерно одинаковы по ценности, то, как обычно, лучше начать с самого короткого.

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

Денис, добрый день! А почему не сделать планирование, показать в project charter'e pros и cons от каждого проекта, посчитать TCO и прочий выхлоп и отдать руководству? У нас обычно так делают.

Вся фишка в том, что планирование нужно делать на основании чего-то, так же? У нас есть product prospective от нашего PO. Но получается нам нужно еще задизайнить каждый проект, что бы понять у какого лучшее соотношение трудозатрат / бенефита для продукта.

Тут мне кажется не обязательно планировать, эстимации нужны

Да, надо. Но необязательно думаю снизу вверх все планировать, оцените поверху, экспертно.

Ну сложность вроде как понятно - посчитали трудозатраты. А полезность - это всегда деньги. У вас в конторе есть отдел, типа маркетологов, кто может примерно предсказать потенциальный выхлоп от каждого проекта? Дальше смотрим какой проект принесёт раньше и больше. Если такой будет. Если одни будут раньше, а другие больше, то вопрос уже на что более заточена контора - на более ранние, но меньшие деньги, или на бОльшие но попозже. В общем, без контекста трудновато мне лично здесь что-то фантазировать :)

С этим вообще не понятно. Для всех все 3 проекта новые и проекты большие. Пока я могу сказать "экспертно" что каждый из них что-то в райное 2-3 месяца. Но такая детализация не устраивает, что бы закомитится на 3 месяца работы.

А сколько времени на проработку есть? Обычно у нас ПМ который в теме делает подобный расчет за 1-2 дня но для типовых проектов. А для нетиповых - ну 3-5 дней наверное. Почему бы не выделить одного ПМа на работу над этим - раз у неделю боард с рассмотрением результаов, на третью неделю - принятие решения.

Ограничение по времени нет. Но выглядит, что нам нужно где-то 2-3 недели на декомпозицию и проектирование. И огромным минусом идет то, что мы еще по-видимому коммитимся на ту архитектуру, которую придумаем сейчас.

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

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

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

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

Можно и без этого. Делаем экспертно оценку, прикидывая сколько ресурсов занимали похожие задачи. Накидываем на риски 100-150%. В итоге в среднем по компании обычно оценка получается, если опыт есть у архов\пмов\etc

Можно и без этого. Делаем экспертно оценку, прикидывая сколько ресурсов занимали похожие задачи. Накидываем на риски 100-150%. В итоге в среднем по компании обычно оценка получается, если опыт есть у архов\пмов\etc

Проблема с примерными эстимейтами в том, что они всегда катили, когда был один проект и нужно бьло его запланировать. Но тут нужно выбрать между ними. А если у тебя оценки по типу 2-4 месяца каждый проект, то оно не катит.

Тогда попробуйте с другой стороны зайти. Какой выхлоп проектов? Какой приоритет внутри? Понятно например, что для клиентов проект приоритетнее чем внедрение внутренней системы багтрекинга новой (хотя не всегда). Есть ли какие то нестоимостные критерии (занять нишу на рынке новую, кто то из менеджмента С-левела будет поддерживать один из проектов, откладывание проекта приведет к убыткам и т.д.),

сделать "нулевой" спринт для "въезжания" и дальнейшей более адекватной оценки, если продукт новый, те же две недели уйдут, если мы берем двухнедельный спринт

"Люди и взаимодействие важнее процессов и инструментов"

Коллеги, спасибо за пищу для размышлений. Прошу простить, сразу в одном сообщении трудно дать весь контекст. Теперь, когда увидел мысли аудитории, могу немного добавить: 1. У заказчика особая ситуация. Скрам был выбран неспроста. Предметная область довольно изведанная, но они на пороге небольшой внутренней революции в плане "мы 30 лет жили по одной схеме, но в современном мире она уже не эффективна и энд-юзеры страдают, а конкуренты не дремлют - надо меняться". Это естественно, что меняться они хотят постепенно, и что много рисков, и что нужно изобрести что-то совершенно другое - поэтому скрам. 2. Примерно в течение года в компании заказчика происходят внутренние перестроения, увольнения, наймы нужных специалистов - вобщем активно идет траснформация. Да, она не проходит безболезненно, но изменения идут. Недавно буквально сложился какой-никакой вектор/вижн, от которого можно оттолкнуться. Недавно появились несколько РО (по разным направлениям), и да, я понимаю что в идеале должен быть один РО, но у них там без scaled POs ну совсем никак (по крайней мере сейчас). До этого был довольно ощутимый информационный вакуум. 3. На команду, как я вижу, оказали влияние следующие вещи: - вышеупомянутый информационный вакуум (как следствие неопределенности, перетрубаций и метаний внутри орг структуры заказчика) - "эффективный" менеджмент, в том смысле что "ребята, где бэклог на 2 спринта вперед?" (в отсутствии нормальных РО и хоть какого-то вектора), т.е. с нас продолжали требовать то, что мы по сути дать не могли ну никак 4. Сейчас ситуация критическая. Скрам-мастер стоит в позиции "хватит это терпеть, за год ничего не сделали - давайте нам быстро все требования на стол". Конфликт. Увещевания на тему "ну вот сейчас же появился вектор и хоть какой-то скоуп" пока ни к чему не приводят. Гайки затягиваются, обвиняются все, кроме команды - "нам не дали архиктектуры, ВА плохо работают с заказчиком, все кругом козлы а мы хорошие". Что делать?

Угу, я был всеми руками за. Но наверху так не хотят - говорят все важные, вы только скажите где по-быстрее и что без факапов. Мне со своей стороны хочется сказать, ну они все блин сложные :)

ну оно так и будет, я там отписался 2-3 недели будем вьезжать

Коллеги, привет. А есть среди вас руководители, у кого уже есть команда(ы) разработки, кто работает по Scrum, но чувствует что явно есть какие-то пробуксовки; что что-то идёт не совсем так, как хотелось бы; что что-то явно стоит улучшить? Провожу небольшое исследование в рамках саморазвития, хотел бы пообщаться с вами, чтобы понять вашу проблематику лучше. Отвечать лучше в ЛС. Тут можем потеряться.

Пока перевел как "Замечание! Уточнение элементов не производится отдельно [Владельцем Продукта](product-owner.html) или группой бизнес-аналитики, это может привести к [потерям](../principles/lean-thinking.html) и искажению информации. Именно команда делает эту работу, и не подмножество команды, а вся команда, поскольку правила Скрам запрещают подгруппы, предназначенные для определенной работы, например, для анализа или тестирования. "

Коллеги, привет. Знаю, что утром в ПН этот чат #2 по полярность, после чата с поиском работы. Поэтому вдруг вы пропустили моё сооьщение, а оно может быть вам интересно 🤗

в целом мне нормально, я бы уточнил, что могут привести к потерям < каким именно >

Я сейчас дальше перевожу статью про LESS Sprint planing. Если кому интересно, буду перевод кидать сюда. Интересно услышать ваше мнение.