Re: [agile-ukraine] Re: проблема с беклогом, у кого какие советы

По ощущениям стейкхолдеры не знают чего хотят. 

Будем им помогать.

16 января 2012 г. 13:41 пользователь Antuan Mark <maryukhnenko@gmail.com> написал:

А хотя бы по вашим ощущениям, стейкхолдеры сами то знают чего хотят?
Или они в творческом поиске и их видение постоянно диаметрально
меняется?
Если так, то выдавливание из них бэклога ничем Вам не поможет! Это
будет временный бэклог, который потом опять придется менять.
И так каждый раз. Это вэйст еще тот будет.
Тогда нужно им помочь понять, что нужно ИМ. Как один из вариантов -
стори маппинг, как предложил Леша.

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

On Jan 16, 3:40 am, Kostya Shein <kostya.sh...@gmail.com> wrote:
> Уже месяц НАСТАИВАЮ на заполнении беклога. Пока добились того что провели
> демо по всей сисстеме и записали пожелания и доработки (насобирали на
> короткий спринт-багфикс). Но все еще нет новых фич.
>
> Система сейчас находится в состоянии когда "админка" сделана и основные
> юзкейсы уже проходят. Но никто не знает как система должна выглядеть
> снаружи. Видать не хотят платить UX специалистам а самим не удается
> придумать.
>
> Заказчик убежал к стейкхолдерам и обещал вернуться с фичами....ждем...и
> напоминаем.
>
> 13 января 2012 г. 15:23 пользователь Borys Lebeda

> <borys.leb...@gmail.com>написал:

>
>
>
>
>
>
>
> > Если честно я этим давно занимаюсь и знаю это задача, которая обычно
> > становится чьей-то ПОСТОЯННОЙ ОБЯЗАННОСТЬЮ.
>
> > Как правило люди очень боятся показать свою некомпетентность, если он
> > раскажут команде, что именно хотят сделать. Визит к заказчику (Сергей
> > Евтушенко предложил) чаще всего помогает, но основное - нужно, что бы
> > скрам-мастер (на практике член команды) всё время следил за состоянием
> > беклога и НАСТАИВАЛ, что бы заказчик исправлял выявленые недочёты.
> > Онсайт это безусловно проще.
>
> > Если он боится браться за сложные задачи - Напугайте его сильнее
> > перспективой, что эта сложная задача будет решаться только через месяц
> > или вообще не решится!
>

> > 2012/1/13 Kostya Shein <kostya.sh...@gmail.com>:

> > > И как "заставить" заказчика создать таки нормальный беклог?
>
> > > Не мелочный и не абстрактный.
> > > 1. Мелочный - беклог состоящий из задач-исправлений на существующий
> > > функционал
> > > 2. Абстрактный - диаграмы связей с другими системами.
>
> > > И первый и второй варианты уже были.
> > > При первом задачи создавались ради задач - изменения без объяснения
> > зачем и
> > > кому нужно.
> > > При втором диаграмы разваливались при первой же попытке понять зачем и
> > кому
> > > нужно.
>
> > > Есть какое-то ощущение что заказчик боится браться за сложные бизнес
> > задачи
> > > и создает видимость работы для стейкхолдеров. Может не разбирается в
> > вопросе
> > > и не хочет этого показать стейкхолдерам. Может еще что-то...где-то очень
> > > "наверху".
>
> > > 12 января 2012 г. 21:03 пользователь Alexey Krivitsky

> > > <alexeykrivit...@gmail.com> написал:

>
> > >> В моем понимании:
> > >> - портфолио-менеджмент: процесс решений на уровне корпорации о
> > >> приоритезации проектов (20'000 футов над проектами)
> > >> - продукт-менеджмент: решения на уровне проекта о том, какой функционал
> > и
> > >> когда выпускать (5'000 футов)
>
> > >> Так как мы смотрим на ситуацию Кости с уровня океана наверх (с уровня
> > >> команды) - мы точно не знаем, где там сверху что поломано. Может на
> > 5'000, а
> > >> может и на 20'000 футах.
>
> > >> Но чинить-то мы будем снизу, так как это то место, где мы есть. А значит
> > >> нам в принцине неважно где наверху не так. Важно, чтобы волна нашего
> > >> процесса срезонировала и дошла до нужного уровня.
>
> > >> Сорри на метафоризмы и имхо.
>
> > >> Кри
>

> > >> 2012/1/12 Serhiy Yevtushenko <syevtushe...@gmail.com>

>
> > >>> Я понимаю под портфолио менеджментом процесс решения о том, какие
> > проекты
> > >>> делаются, а какие не делаются вообще (в смысло Johanna Rothmans
> > "Manage your
> > >>> project portfolio". Уровень проектов при этом может быть абсолютно
> > разным.
> > >>> Отсутвие такого процесса приводит к серьезным проблем. По сути своей,
> > это
> > >>> принятие решение делать что-то (и выделение ресурсов), не делать
> > чего-то
> > >>> вообще, или запарковать решение до следующего пересмотра, и еффективное
> > >>> управление имеющейся емкостью команды.
>
> > >>> Задача продакт менеджмента - решать, какие вещи с точки зрения продукта
> > >>> должны быть сделаны, и окупяться ли они, их приоритизация.
>
> > >>> Сергей
>

> > >>> 12 января 2012 г. 9:44 пользователь Sergii Malyi <serg.m...@gmail.com>

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

> > >>>> 2012/1/11 Serhiy Yevtushenko <syevtushe...@gmail.com>

>
> > >>>>> По описанию ситуация выглядит:
>
> > >>>>> Есть бизнес процессы заказчика
> > >>>>> Есть старая система, работающая по этим процессам
> > >>>>> У пользователей есть пожелания - пожелания долго не удовлетворяются -
> > >>>>> поэтому идет постоянная борьба кто громче крикнет\кто запросит свои
> > фичи
> > >>>>> выше
> > >>>>> Понимания бизнес процессов заказчика у команды нет
> > >>>>> Понимания тех проблем, которые решаются бизнесом, нет
> > >>>>> Есть еще ощущение, что все проблемы пытаются решить за один релиз
> > >>>>> Нет\Не хватает коммуникации между стейкхолдерами и командой
>
> > >>>>> Возможные идеи для лечения:
>
> > >>>>> портфолио менеджмент - то есть, принятие решений на стороне
> > заказчика,
> > >>>>> какие задачи должны делаться, а какие не должны, и доведение тех
> > фич, по
> > >>>>> которым принято решение делать, до конца. Тут проблема в том, что
> > текущий ПО
> > >>>>> по описанию его не выполняет.
>
> > >>>>> построение модели предметной области (если есть возможность,
> > совместно
> > >>>>> с бизнесом) - чтобы понимать, как заказчик зарабатывает деньги
>
> > >>>>> вовлечение комманд в демо со стейкхолдерами
>
> > >>>>> визиты членов команды к заказчику чтобы понимать, как работают люди
> > на
> > >>>>> стороне заказчика\реальные пользователи
>
> > >>>>> Сергей Евтушенко
>
> > >>>>> 11 января 2012 г. 17:38 пользователь Nataliya Trenina

> > >>>>> <nat.tren...@gmail.com> написал:

>
> > >>>>>> Костя, привет.
>
> > >>>>>> Подскажи, есть ли еще какие-то причины редкого выпуска релизов,
> > кроме
> > >>>>>> изменений в беклоге? Если да, что это - на твой взгляд?
>
> > >>>>>> Наташа
>
> > >>>>>> 11 января 2012 г. 17:37 пользователь Kostya Shein
>

> ...
>
> read more >>

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/

To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-ukraine@googlegroups.com
To unsubscribe send email to agile-ukraine+unsubscribe@googlegroups.com

--
-- Костя

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-ukraine@googlegroups.com
To unsubscribe send email to agile-ukraine+unsubscribe@googlegroups.com