Analysis paralysis: как бороться
Alexey Krivitsky
Что бы вы посоветовали или сделали, будучи в команде, где происходят чрезмерно долгие обсуждения дизайна нового приложения и согласие по этому вопросу достигается с трудом.
В науке это похоже называется Analysis_paralysis и может быть вызвано Big_Design_Up_Front.
Интересуют сугубо практические советы.
Спасибо
Alexey
sergiy.movchan
--
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-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
--
...dali bude...
Artjom Serdyuk
подходящее предложение.
On 15 дек, 00:27, Alexey Krivitsky <alexeykrivit...@gmail.com> wrote:
> Привет!
>
> Что бы вы посоветовали или сделали, будучи в команде, где происходят
> чрезмерно долгие обсуждения дизайна нового приложения и согласие по этому
> вопросу достигается с трудом.
>
> В науке это похоже называется
> Analysis_paralysis<http://en.wikipedia.org/wiki/Analysis_paralysis>и
> может быть вызвано
> Big_Design_Up_Front <http://en.wikipedia.org/wiki/Big_Design_Up_Front>.
>
> Интересуют *сугубо практические *советы.
>
> Спасибо
> Alexey
Alimenkou Nikolay
такое, что дизайн движется ну очень медленно. Я всегда считаю что это
недобрый знак, но вот причину понять можно только из контекста:
- Может очень мало знаний о доменной области
- Может в команде есть несколько лидеров и они не могут найти
взаимопонимания
- Может просто никто не хочет на себя брать ответственность за решение
- У команды нету опыта построения подобных систем
.....
Дай немного больше контекста и я думаю что получишь много интересных
советов.
On 15 Грд, 01:23, "sergiy.movchan" <sergiy.movc...@gmail.com> wrote:
> надо уточнить:
> 1. не могут сойтись на диаметрально противоположных подходах или долго
> копаются в деталях, но курс уже выбрали?
> 2. в команде все имеют одинаковый вес и у всех своё мнение? никто не может
> аргументированно показать, что его вариант лучше?
>
> 2009/12/15 Alexey Krivitsky <alexeykrivit...@gmail.com>
>
>
>
>
>
> > Привет!
>
> > Что бы вы посоветовали или сделали, будучи в команде, где происходят
> > чрезмерно долгие обсуждения дизайна нового приложения и согласие по этому
> > вопросу достигается с трудом.
>
> > В науке это похоже называется Analysis_paralysis<http://en.wikipedia.org/wiki/Analysis_paralysis>и может быть вызвано
> > Big_Design_Up_Front <http://en.wikipedia.org/wiki/Big_Design_Up_Front>.
>
> > Интересуют *сугубо практические *советы.
>
> > Спасибо
> > Alexey
>
> > --
> > 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-...@googlegroups.com
> > To unsubscribe send email to agile-ukrain...@googlegroups.com<agile-ukraine%2Bunsubscribe@goog legroups.com>
>
> --
> ...dali bude...
Alexey Tigarev
> Что бы вы посоветовали или сделали, будучи в команде, где происходят
> чрезмерно долгие обсуждения дизайна нового приложения и согласие по этому
> вопросу достигается с трудом.
Таймбокс на принятие решения. Это может быть реализовано в виде таска
"дизайн", estimate на который одновременно является и мерой времени,
которое мы согласны потратить на это в течение итерации.
Если решения дальше нет, всё отдаётся на откуп человеку или паре,
которая возьмёт на себя соответствующие таски.
При этом даём команде понять, что если в дальнейшей работе новый
("плохо продуманный") дизайн вызовет проблемы, всегда можно будет
отрефакторить. Команда должна понимать, что время на рефакторинг ей в
случае чего дадут и ошибка, которую она сделает во время Small Design
UpFront - не будет фатальной, и этот дизайн не придётся с собой тащить
до конца.
Если есть несколько вариантов дизайна - можно сделать таски для так
называемых architectural spikes - пробных решений. Это превращает
паралич в действие, хотя бы и "пробное".
Здесь важно умение команды делать рефакторинг (а значит, и писать
юнит-тесты) - когда люди понимают, что код может быть пластичным и
ничего не высечено из камня - гораздо легче остановиться в некоторый
момент на каком-то достаточно хорошем (не идеальном) решении. Т.е.
появляется Courage (ценность XP).
--
С уважением, Алексей Тигарев
<ti...@nlp.od.ua> Jabber: ti...@jabber.od.ua Skype: t__gra
Как программисту стать фрилансером и заработать первую $1000 на oDesk:
http://freelance-start.com/earn-first-1000-on-odesk
Vova Oros
Прямо сразу на секретаре, бухгалтере, рекрутерах и жене. На завтра
договориться с целевыми пользователями.
Если под дизайном понимаем архитектуру - то выделяем все альтернативы,
которые смогут заработать и выбираем самую простую. Если простых
несколько - бросаем монетку. Выбор обьясняем цитатами из книги по ХР -
"наипростейшая штука которая заработает".
Так думаю.
Андрей Бибичев
третьей стороны:
- когда не можем договориться по какому-то вопросу, начинаем
обсуждать, кто бы нам мог с этим помочь
- важно, чтобы этот кто-то был одобрен обеими сторонами
"противостоящих" точек зрения, т.е. все согласились, что да - с ним
разумно и полезно посоветоваться
- это может быть очень опытный и умный чувак из соседнего проекта или
даже из другой компании, кого вы уважаете
- обычно такой находится
- дальше всё обсуждается вместе с ним и его точка зрения и его
подсказки помогают найти золотую середину
- но это должна быть именно консультация, т.е. вы сами в итоге должны
принять совместное решение, так как вам с этим решением жить, а вовсе
не этому гуру
- кстати, зачастую в результате таких совместных обсуждений рождается
какое-то третье решение... :)
Если это по каким-то причинам не срабатывает (например, не нашли к
кому обратиться), то, как написал Alexey Tigarev, - architectural
spikes
Практика показывает, что в большинстве случаев такие холивары по
поводу дизайна не так важны - можно выбрать любое из решений и успешно
реализовать с ним проект. Это связано с тем, что холивары возникают
там, где основную роль играют вопросы вкуса и личных пристрастий, а
вовсе не объективные ограничения. Т.е. здесь важно не стопориться и
переливать из пустого в порожнее, а именно идти дальше. Можно
договориться с менеджером и/или PO, чтобы он чуть-чуть поднажал на
команду и попросил соответствующую функциональность как можно быстрее
с очень жестким и важным дидлайном - это поможет команде найти самый
простой и эффективный путь, а не витать в облаках архитектуры :)
Igor Khotin
Все очень просто - когда обсуждение затягивается, нужно сворачивать
дискуссиии,
брать в руки клавиатуры и начинать кодить прототип(ы), выбирая самые
простые
пути реализации :)
Подобное затягивание вполне естественно, так как вначале проекта мы
редко обладаем
полной информацией чтобы чётко вырисовать архитектуру будущего
приложения.
Стоя лицом к неопределённости мы пытаемся разобраться во всём
подробнее,
нарисовать бизнес процессы, диаграммы классов и т.п. Как результат -
бесконечные
споры по поводу больших и малых архитектурных решений. Такие дискуссии
могут
продолжатся очень долго и к общей идее можно так и не прийти -
информации ведь
недостаёт, и каждый отражает задачу на свой собственный опыт.
Возможно всё упирается в страх завязнуть в спагетти-коде если не
структурировать
всё с самого начала. И опасениях того, что рефакторинг и поддержка
будут стоит очень дорого.
Поэтому для прототипа можно рекомендовать какой-нибудь скриптовый
язык чтобы ускорить
появление работающей версии. Когда будет рабочая версия - многие
спортные вопросы
отпадут сами собой, так как будет видно какая идея сработала, а какая
- нет.
С уважением,
Игорь Хотинь
On Dec 15, 12:27 am, Alexey Krivitsky <alexeykrivit...@gmail.com>
wrote:
> Привет!
>
> Что бы вы посоветовали или сделали, будучи в команде, где происходят
> чрезмерно долгие обсуждения дизайна нового приложения и согласие по этому
> вопросу достигается с трудом.
>
> В науке это похоже называется
Alexey Tigarev
используют evolutionary prototyping, то есть прототип со временем
(путём рефакторинга) становится рабочим кодом, а не выбрасывается.
Если же писать на другом языке (скриптовом), то рефакторинг
превращается в переписывание и прототип надо выбросить.
Впрочем, если скриптовый язык embedd'ится в основной язык,
используемый в проекте - куски кода на разных языках могут некоторое
время сосуществовать (скажем, Jython и Java).
И ещё хочу отметить, что prototyping и architectural spikes - это не
совсем одно и то же. Prototyping больше относится к инженерии
требований, чем к архитектуре - т.е. дёшево делаем прототип и получаем
обратную связь от заказчика. В architectural spike мы получаем
обратную связь от самого дизайна - нравится он нам или нет, удобно ли
с ним работать.
В связи с этим при использовании другого языка для architectural
spikes желательно не ударяться в использование возможностей
вспомогательного языка, которых нет в основном. Скажем, не
использовать питоновские метаклассы, так как их нет в Java :)
2009/12/15 Igor Khotin <chaos...@gmail.com>:
Artem Marchenko
Как тут уже упоминали, правильный ответ, конечно же, "it depends" и
иногда действительно имеет смысл обсуждать подольше :)
Если принять, что случился действительно именно paralysis и команду
надо выводить из этого, то в моей практике практически универсальным
лекарством было донести до команды, что "что-то" нужно сделать до
конца очень скоро (скажем, за месяц или за пару недель). Фокус на
близком дедлайне почти автоматически обрывает чрезмерные беседы и
команда начинает действовать.
А вот найти/объяснить что именно и почему именно неободимо сделать
быстро (так сказать, создать "sense of urgency"), это уже и есть
непосредственно задача коуча. В моей практике работали вещи вроде
"менеджменту надо показать что-то на встрече через месяц иначе проект
может подвергнуться риску закрытия. Чтож делать, раз менеджмент
понимает только работающую демку и не в состоянии въехать в наши
грандиозные планы", "давайте построим прототип и посмотрим" и даже
"хм, раз обе идеи хороши, давайте попробуем построить обе и выберем
более устойчивую/быструю и т.д.". Разумеется, во всех случаях это был
не обман, а просто обращение внимания на вещи, которые находились вне
обычного поля внимания команды.
С уважением,
Артём.
On Dec 15, 12:27 am, Alexey Krivitsky <alexeykrivit...@gmail.com>
wrote:
> Привет!
>
> Что бы вы посоветовали или сделали, будучи в команде, где происходят
> чрезмерно долгие обсуждения дизайна нового приложения и согласие по этому
> вопросу достигается с трудом.
>
> В науке это похоже называется
> Analysis_paralysis<http://en.wikipedia.org/wiki/Analysis_paralysis>и
> может быть вызвано
> Big_Design_Up_Front <http://en.wikipedia.org/wiki/Big_Design_Up_Front>.
>
> Интересуют *сугубо практические *советы.
>
> Спасибо
> Alexey
Alexey Krivitsky
Больше деталей подкинуть не смогу, но даже на таком уровне абстрагирования от ситуации, уверен, что это полезно.
Подводя итог, у нас вышло следующее (порядок списка произвольный):
1. использовать протокол "Decider" для принятия решений
2. ввести таймбокс на принятие решения
- можно добавить как таску "дизайн"
3. всё отдаётся на откуп человеку или паре, которая возьмёт на себя соответствующие таски
4. выделяем все альтернативы, из которых выбираем самую простую
- если простых несколько - бросаем монетку
- в большинстве случаев такие холивары по поводу дизайна не так важны - можно выбрать любое из решений и успешно реализовать с ним проект
5. architectural spikes - пробных решений
- аджайлисты чаще используют evolutionary prototyping
6. сворачивать дискуссиии и начинать кодить прототип(ы)
- throwavay prototyping тоже хорошая вещь
- использовать скриптовый язык, чтобы ускорить появление работающей версии
7. немедленный юзер тест (если под дизайном понимаем внешний вид)
8. привлекаем "внешних экспертов" или третью сторону
9. донести "sense of urgency"
- объяснить что именно и почему именно неободимо сделать быстро, задача коуча
А вот и майд-меп
Леша
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
Artjom Serdyuk
практически одно и то же.
Я бы заменил "быстро выбрать решение" на "облегчить принятие
решения".
On Dec 16, 12:45 am, Alexey Krivitsky <alexeykrivit...@gmail.com>
wrote:
> Всем спасибо за штурм! Можем!
>
> Больше деталей подкинуть не смогу, но даже на таком уровне абстрагирования
> от ситуации, уверен, что это полезно.
>
> Подводя итог, у нас вышло следующее (порядок списка произвольный):
>
> 1. использовать *протокол "Decider" *для принятия решений
>
> 2. ввести *таймбокс на принятие решения
> * - можно добавить как таску "дизайн"
>
> 3. всё отдаётся *на откуп человеку *или паре, которая возьмёт на себя
> соответствующие таски
>
> 4. выделяем все *альтернативы*, из которых выбираем *самую простую*
> - если простых несколько - бросаем монетку
> - в большинстве случаев такие холивары по поводу дизайна не так важны -
> можно выбрать любое из решений и успешно реализовать с ним проект
>
> 5. architectural *spikes* - пробных решений
> - аджайлисты чаще используют evolutionary prototyping
>
> 6. сворачивать дискуссиии и начинать *кодить прототип(ы)*
> - throwavay prototyping тоже хорошая вещь
> - использовать скриптовый язык, чтобы ускорить появление работающей версии
>
> 7. немедленный *юзер тест* (если под дизайном понимаем внешний вид)
>
> 8. привлекаем* "внешних экспертов"* или третью сторону
>
> 9. донести *"sense of urgency"
> *- объяснить что именно и почему именно неободимо сделать быстро, задача
> коуча
>
> А вот и майд-меп<http://www.xmind.net/share/krivitsky/treat-analysis-paralysis/>
>
> Леша
>
> 2009/12/16 Artem Marchenko <artem.marche...@gmail.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-...@googlegroups.com
> > To unsubscribe send email to agile-ukrain...@googlegroups.com<agile-ukraine%2Bunsu...@googlegroups.com>
Alexey Krivitsky
1) ограничить время и там думать как выбрать
2) кидать на пальцах, чтоб выбрать сразу
Но согласен - очень близкие. Не суть важно на самом деле.
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
Borys Lebeda
А после встречи как гора с плеч:
Х: А как мы будем делать плагины для SmartViewer?
Z: Ты же слышал, Джон сказал, что пока обойдётся без плагинов ...
Y: Так мы будем пользоваться DataSet или NHibernate для прототипа?
Z: Билл сказал, что надо сразу начинать с NHibernate.
--
Borys L.
Alexey Krivitsky
Лёша
Borys Lebeda
--
Borys L.