« Rev
@agile_ru   429
Fwd »


Pavel
итак: есть ли какой нибудь scaled-framework который можно применить в гибридной среде. т.е там, где частично - создание продуктов (в основном scrum), часть - классические проекты с проектной корп. методологией на основе PMBOK. задачи - синхронизация и отчетность руководству (да, руководство просит отчетность). цель - облегчить жизнь PO/SM/PM, чтобы все внепродуктовые и внепроектные активности (совещания, отчеты и т.д) протекали максимально безболезнено
дмитрий, давайте разделим: Если у вас несколько agile команд, которые работают по "в основном scrum", а управление портфелем/программой идет через методологию на основе PMBoK, scaling framework вам возможно не нужен. Посмотрите на Reliable Scrum на командном уровне и догоовритесь о метриках на его основе с программным уровнем, они там вполне PMBoK-совместимы. Если у вас программа/портфель с несколькоими agile-командами работающими над единым бэклогом, то можете попробовать убедить program/portfolio management использовать kanban и метрики на его основе. Они, опять же, совместимы с PMBoK
Pavel
Не надо хвататься прям вот сразу за SAFe / LeSS / Nexus / WTF - в них нет универсального ответа на вопрос "как сделать жизнь команде лучше при PMBoKовских метриках"
Grigory
Бездумно конечно не надо. А вот елемениы системы управления из сейфа можно взять. Если бы сверху все ок было, то нам и такой вопрос бы не задали.
Pavel
Из SAFe тяжело взять элементы, которые бы одновременно были совместимы со scrum и не усугубили "вотерфол".
Pavel
Вообще вопрос, какими метриками измеряют
Grigory
Из SAFe тяжело взять элементы, которые бы одновременно были совместимы со scrum и не усугубили "вотерфол".
Чей то, через art можно любые типы команд интегрировать в единый pi. Как раз команды как хотят пусть работают. Зато есть роли, понимание которых хоть как то даст надежду. Например rte. А единое планирование можно с представителями сделать, а не всей кучей
Pavel
Чей то, через art можно любые типы команд интегрировать в единый pi. Как раз команды как хотят пусть работают. Зато есть роли, понимание которых хоть как то даст надежду. Например rte. А единое планирование можно с представителями сделать, а не всей кучей
1. Через ART можно интегрировать scrum и kanban команды, причем kanban - со значительными плясками с бубном. 2. Единое планирование в SAFe на уровне ART нельзя делать "представителями команд" 3. Принципы работы команд в рамках ART внутри PI во фреймворке есть и только часть из них можно проигнорировать. 4. Роль RTE в SAFe это совсем не роль "проджект/програм менеджера"
Grigory
4 ок, остальное максимализм какой то. Если удобно, то можно все изменять.
Pavel
Изменять можно вообще все. Изменять так, чтобы было осмысленно и удобно - только если очень хорошо понимаешь, что именно менять
Max
4 ок, остальное максимализм какой то. Если удобно, то можно все изменять.
Если бы можно было все изменять, то и гибридной схемы не возникло.
Pavel
С тем же big room planning (aka PI Planning) силами представителей вообще ничего хорошего не выйдет, хотя мнгие пытаются.
Pavel
Не вйдет по той же причине, по кторой не получается на sprint planning в scrum привлекать только часть команды :)
Grigory
Методологически я за. Но я видел и вариант с менеджерами вообще. То есть Типо менеджеров по интеграции с планами зависимостей. Приходит такой на работу и весь день план херачит. Но в итоге работает.
Ivan
обожечки… форвард форварда в форварде
Ivan
и еще это прошлогодняя статья 🙈
PureFatality
и еще это прошлогодняя статья 🙈
за год многое поменялось?
Yehor
и еще это прошлогодняя статья 🙈
Доброй ночи Иван, стать на которую я сослался от 11 февраля 2018 года
Mikhail
Доброй ночи Иван, стать на которую я сослался от 11 февраля 2018 года
Егор, оригинал действительно годовой давности :) https://biz.mann-ivanov-ferber.ru/2017/03/21/vrednye-agile-sovety-10-sposobov-provalit-proekt/
Mikhail
но действительно, за год мало что поменялось
Mikhail
Доброй ночи, коллеги! Какой размер беклог итем (продукта) и нужно ли требовать его соблюдения у РО? Посмотрел сейчас в скрамгайд Элементы Бэклога Продукта, которыми будет заниматься Команда Разработки в будущем Спринте, прорабатываются так, чтобы их можно было реализовать за время одного Спринта. У нас в продуктовом беклоге встречаются элементы вида "Реализовать взаимодействие с ... по регламенту. Регламент во вложении" Работы на пару месяцев для команды. В беклоге спринта сформированном на планировании "Создание проекта в Jenkins", "переименовать пункт меню"
Pavel
У PBI - любой, в спринт можно брать только то, что можно за спринт завершить. Дробить айтемы стоит всей командой
Mikhail
У PBI - любой, в спринт можно брать только то, что можно за спринт завершить. Дробить айтемы стоит всей командой
Получается в продукт беклоге будут итемы различных уровней абстрации и один может включать в себя другие. На примере "Реализовать взаимодействие.." на планировании декомпозировали, определили итемы, оценили и добавили в беклог. Он содержит и итем уровеня эпик и таски на спринт.
Pavel
Верно
Dmitriy M.
https://www.youtube.com/watch?v=2nIntxKDHz0 нужны отзывы профессионалов, насколько это можно показывать людям для объяснения, мне как человеку не совсем в теме - понравилось, странно что так мало просмотров
Dmitriy M.
спасибо
Dmitriy M.
"пара неточностей" - на целый слайд 🙂
Кир
https://www.youtube.com/watch?v=2nIntxKDHz0 нужны отзывы профессионалов, насколько это можно показывать людям для объяснения, мне как человеку не совсем в теме - понравилось, странно что так мало просмотров
Имхо. Хотя и есть пара неточностей), но как выжимка, которая рассказывает про механизм работы, наверно одно из самых удачных которые видел.
Pavel
Ага. Только похоже авторы ролика ни разу не сажали настоящий лес
Lita
Вот здесь разобрано https://www.youtube.com/watch?v=bGQHcdUA2wg с 07:20
Хорошее выступление. Спасибо за ссылку.
Mikhail
Коллеги поделитесь статьями, видео выступлений про совмещение роадмап и аджайл! В силу специфики у нас требуют роадмап, но внутри работаем по эджайл, с заказчиками тоже.
Андрей
нет его у нас :(
Планирование исключительно внутри одной команды? Если да то может прокатить с древовидной структурой типа "реализовать интеграцию с ..." и ряд задач на которые это раздроблено. Соответственно так чтобы это можно было выполнить за спринт. Таким образом будет проведен груминг в процессе планирования. Есть минус: неопределенность будущей работы в момент планирования-груминга - это тупо пугает. Ну и такое мероприятие сбивает ритм. На практике при работе в 2+ команды над проектом это реально мешает т.к. пока грумится одна задача одной командой все остальные теряют фокус. Потеря фокуса причина большинства разговоров "очередное бесполезное собрание", "agile это много ненужной болтовни", "давайте код писать, чё мы тут сидим".
Mikhail
https://www.youtube.com/watch?v=Mp5xdAZYdPo Было на https://www.egconf.ru/ - одно из лучших выступлений, на мой взгляд
1.Видео не связанно с исходным вопросом. 2.Содержание и выводы весьма спорные. например, что роадмеп не имеет временной привязки 😳
Marina
1.Видео не связанно с исходным вопросом. 2.Содержание и выводы весьма спорные. например, что роадмеп не имеет временной привязки 😳
1. У компании agile 2. Да, спорные - поэтому это и не курс в вузе, а презентация для конференции) Про временную привязку она хорошо пояснила, что это не уровень роадмапа.
============ FALCON ============
Интересный феномен, после работы пр скраму или эджайлу остается ностальгия) Приветствую @Samulak!
Foxtrot ✙
Нет, не правда )
Daniil
Я так чувствую, что дальше нам попытаются что-то продать
Yehor
Да, кстати забыл представиться, меня зовут Егор, работаю в проектном менеджменте практически пять лет. Изучаю тонкости гибких методологий, также интересуюсь принц2 но в реальных проектах не применял еще. Немного рекламы, веду канал о проектном менеджменте https://t.me/project_management_club Когда начал искать полезные каналы для себя как менеджера, нашел очень малочисленное кол-во, возможно я как-то не так искал, буду признателен если в личку накидаете каналов, чатов.
Артём
нужно больше каналов на одну тематику с одинаковыми участниками
Yehor
нужно больше каналов на одну тематику с одинаковыми участниками
Я предполагаю, что везде разный контент поэтому почему бы и нет?
Denis
нужно больше каналов на одну тематику с одинаковыми участниками
Нужно больше сайтов про новости, ведь одного не хватает
Yuriy
Привет! Меня зовут Юрием, работаю в OZON.ru. Выполняю функцию владельца продукта. г.Москва. В подобных сообществах ищу ответы на вопросы. В оценке собственной пользы для сообщества придерживаюсь скромных оценок😊 - я 3 года в IT, работаю с аутсорсинговой командой, применяем Scrum. Про группу уже не помню как узнал. #whois
Yuriy
Привет! Интересно, как с аутсорсинговой компанией можно скрам применять? Реально интересно, у самих есть такой подрядчик, думаем как с этим жить.
команда и скрам-мастер находятся в другом городе, я тут) дайли, планирование, обзор по скайпу или хэнгаутсу. доска в tfs, бэклог веду в trello, вся документация в confluence. в целом я не чувствую особой ущербности) у всегда с собой планшет и портативная блютуз колонка, всегда их могу подключить, если надо
Yuriy
+ это аутсосорс с глубоким погружением, так сказать) они имеют, ограниченнные, но доступы к нашим окружениям, базам. Так что это почти сотрудники на удаленке
Pavel
Привет! Интересно, как с аутсорсинговой компанией можно скрам применять? Реально интересно, у самих есть такой подрядчик, думаем как с этим жить.
В целом без адаптации. Нужен Product Owner, желательно на стороне заказчика, который будет уметь в scrum и иметь полномочия для приоретизации бэклога. Ну и быть доступным команде на постоянной основе, хотя бы виртуально. PO на стороне аутсорсера тоже возможен, но в большинстве случаев он будет proxy.
Sergey
У нас внешняя команда есть, аутстафф. Предлагаю своим ее на скрам и как другие команды к общему беклогу. Народ сомневается.
Sergey
А они в километре всего сидят от нас.
Pavel
http://www.scrumneedsdesign.com/
Mikhail
Коллеги, добрый вечер. Такой вопрос, как быть в ситуации, когда на планирование приходят РП и каждый пушит свои задачи. Причем они новые! На вопрос, а где она в беклоге, а он перед глазами. Отвечают: сейчас расскажу что надо, а вы заведите.
Denis
Это скрам? Кто они, эти РП?
Mikhail
Это скрам? Кто они, эти РП?
можно брать какие то элементы скрама. Мы вроде как скрам)) но после четырех(!) РП... Это как бы представители РО))
Mikhail
по направлениям
Mikhail
такими темпами скоро на каждого члена команды свой РП будет 😄
Denis
Очень поверхностно. Это вопрос скорее, как выстроить грамотно коммуникацию и создать единую точку входа по определенным правилам
Nikita
можно брать какие то элементы скрама. Мы вроде как скрам)) но после четырех(!) РП... Это как бы представители РО))
Я правильно понимаю, что под PO вы подразумеваете product manager, а под РП классического project manager’а?
Mikhail
Я правильно понимаю, что под PO вы подразумеваете product manager, а под РП классического project manager’а?
РО product owner, РП руководитель проекта. Проекты в рамках большого продукта
Nikita
А какие функции выполняют PO и РП?
Anonymous
А какие функции выполняют PO и РП?
РО и РМ сами этого не понимают, как показывает практика
Артём
долго ли scrum осваивать?
Yehor
долго ли scrum осваивать?
Осваивать неттак уж и долго, немного важнее понять нужен ли вам именно скрам? Из него очень часто делают карго культ, по типу внедрил скрам и все наладиться, разработчики перестанут дедлайнить, владелец продукта накидывать задачи в самые неподходящий момент, все будут мотивированы и щасливы, но увы нет гарантий того, что если скрам пошел в одной компании он пойдет и у вас...
Артём
в вакансии просто написано что у них скрам). Как обычно происходит, на работе учат как им пользоваться или уже с готовыми знаниями нужно приходить? И критично ли знать скрам если он там используется?
Yehor
в вакансии просто написано что у них скрам). Как обычно происходит, на работе учат как им пользоваться или уже с готовыми знаниями нужно приходить? И критично ли знать скрам если он там используется?
Это плюс если вы знакомы с ним предварительно, но если компания серьезная со скрам мастером , то вас введут во все тонкости. А вообще прочтите книгу «Scrum. Революционный метод управления проектами» автора Джефф Сазерленд
Артём
скачал книгу, так же нашел пересказ https://habrahabr.ru/company/makeright/blog/297250/ как я понял, проект делают по типу mvp (минимально жизнеспособный продукт) и постепенно наращивают функционал работающими модулями которые готовы для использования. Из плюсов то что нет левых задач (а это всегда бывает) и то что отказываются от переработок)), хз как оно в реально жизни. В общем буду дальше читать
Daniil
Она более наукообразная и более подробная
Daniil
Первая скорее маркетинг для того, чтобы зафанатеть от идеи, а вторая - учебник
« Rev
@agile_ru   429
Fwd »