повтоямость результатов или эффективность конкретного проекта

[Alexey Krivitsky]

Привет всем.

Мы как-то тут обсуждали тему повторяемости результатов. Пришлось вернуться к этой теме, так как она для меня осталась нераскрытой.

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

Вступление, ход мысли и мои выводы тут

Буду рад подискутировать на эту тему.

--
Alexey Krivitsky,
Coordinator of AgileUkraine.org
Certified ScrumMaster and Practitioner
Agile coach and trainer at SCRUMguides.com
Phone: +380 50 358 92 12
Skype: alexeykrv
LinkedIn: http://www.linkedin.com/in/alexeykrivitsky

[Alexander Rivkind]

Очень хорошая тема.
Прочитал встепление и у меня сложилось ощущение, что тут собрано сразу несколько разных тем.

1. Эволюционный дизайн (горячий привет Фаулеру :) ). Серега, помнишь сколько мы его обсуждали? Хорошая статья на эту тему

http://www.artima.com/intv/evolution.html

2. Гибкая архитектура... никакая архитектура не может быть достаточно гибкой, чтобы вместить все будущие требования.

Для себя я уже давно сделал выбор. По результатам могу сказать, что подход достаточно успешный. Мы тратим достаточно много времени на построение архитектуры. И делает это не один человек. Результат - принципиальные компонентные диаграмы, диаграммы потоков данных, машины состояний, и пр. Только после этого приступаем к кодированию. Иногда архитектуру приходится менять, но никогда еще не приходилось менять ее солидно. Возможно, специфика проектов у меня такая (mission critical, high performance)...

3. Повторяемость результата. Это имхо совсем их другой оперы. Речь идет о процессе. И неважно, какой подход к дизайну выбрат. Важно, что этот подход описан, он работает, и работает одинаково на разных задачах. Но тут есть своя специфика. Иногда проект не подходит под методологию... Рекомендую

http://www.maxkir.com/sd/methyperproject_RUS.htm

4. Выпустить то, что нужно сейчас. Это довольно глобальный принцип. Он несомненно перекликается с подходом к архитектуре, но им не закачивается. Я согласен, что не надо делать функциональность, которая сегодня не нужна. Но я думаю, что в любую архитектуру нужно закладывать "разумную расширяемость". Трудно сказать, что это значит. Опытный архитектор (и программист) как правило может предугадать на 1-2 шага вперед, что может в будущем понадобиться.

Это вкратце. :)

2008/11/7 Alexey Krivitsky <alexeyk...@gmail.com>

--
Best Regards, Alik.

[Alexey Krivitsky]

Спасибо, Алик.

Темы эволюционного дизайна и повторяемости процесса на первый взгляд - несвязаны.

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

Думаю, что можно было бы использовать практику дерева текущей реальности (с которой мы практиковались в клубе) и выявить конфликт между этими двумя понятиями.

Лёша.

2008/11/7 Alexander Rivkind <alik...@gmail.com>

[Artjom Serdyuk]

Леша, при слове "эволюционный дизайн" мне приходят в голову
генетические алгоритмы для решения оптимизационных задач. Помнишь
такую штуку?

Сходимость генетических алгоритмов, если мне не изменяет память, НЕ
ХУЖЕ точных методов поиска решения. Особенно при коротких итерациях,
определённых критериях достижения цели и регулярном "встрахивании"
системы.

Не напоминает Аджайл/Скрам? ;))))

Как думаешь, можно провести параллели между генетическими алгоритмами
и эволюционным дизайном?

On Nov 8, 3:23 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> Спасибо, Алик.
>
> Темы эволюционного дизайна и повторяемости процесса на первый взгляд -
> несвязаны.
>
> Но как выяснилось из общения, люди не могут принять идею эволюционного
> дизайна, так как хотят добиться повторяемости. Повторяемость в их понимании
> исходит из проработанности предметной области (анализ требований) и
> продуманности архитектуры (дизайн). А эволюционный дизайн не может
> гарантировать результаты и тем самым не может гарантировать повторяемости.
>
> Думаю, что можно было бы использовать практику дерева текущей реальности (с
> которой мы практиковались в

> клубе<http://www.agileukraine.org/2008/10/agile-club-finding-root-causes.html>)

> и выявить конфликт между этими двумя понятиями.
>
> Лёша.
>

> 2008/11/7 Alexander Rivkind <alik1...@gmail.com>

> > 2008/11/7 Alexey Krivitsky <alexeykrivit...@gmail.com>

>
> > Привет всем.
>
> >> Мы как-то тут обсуждали тему повторяемости результатов. Пришлось вернуться
> >> к этой теме, так как она для меня осталась нераскрытой.
>
> >> Что лучше:
> >> а) быстро выпустить то, что нужно сейчас, тем самым повысив вероятность
> >> переработок потом, но получить при этом обратную связь и откорректировать
> >> курс проекта?
> >> б) либо же - разработать продуманную гибкую архитектуру, которая с
> >> большей вероятностью сможет вместить новые требования?
>

> >> <http://www.krivitsky.com/2008/11/repeatable-vs-effective.html>Вступление,
> >> ход мысли и мои выводы тут<http://www.krivitsky.com/2008/11/repeatable-vs-effective.html>

[sun]

ну, никак не похоже )))
в генетических алгоритмах есть стандартый набор приёмов, применив
которые можно достичь результата.
в agile к сожалению такого нет (

2008/11/8 Artjom Serdyuk <artem....@gmail.com>:

--
sun

[Sergiy Movchan]

а мне как раз кажется похожим.

делаем шаг, анализируем результат, если видим улучшение, то делаем (больший?) шаг в ту же сторону, а если нет, то поворачиваем. 

2008/11/8 sun <aleksey....@gmail.com>

--
...dali bude...

[sun]

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

2008/11/8 Sergiy Movchan <sergiy....@gmail.com>:

--
sun

[Alexey Krivitsky]

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

2008/11/9 sun <aleksey....@gmail.com>

[Artem Marchenko]

Привет

ИМХО, повторяемость результатов VS эффективность и evolutionary VS up-
front design - это немного разные темы, связанные не более, чем многие
другие околоagile'овские понятие.

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

Способ минимизации рисков и повышения эффективности путём повторения
процесса имеет право на существование до тех пор, пока всё копируется
не вслепую, ясны причины и вы способны отказываться от того, что не
работает и пробовать новое.

Например, жёсткое требование каждую итерацию выпускать полностью
готовый к использованию прототип может отлично работать в чисто
софтверном проекте, а повторённое в хардверно-софтверном приводить к
гигантскому расходу средств и раздуванию размера итерации до размера
цикла производства железа.

В общем, как обычно, общих решений не существует. Как максимум, общие
принципы работающие "во многих случаях", но не обязательно в вашем
конкретном случае.

Удачи!
Артём.

On Nov 7, 12:15 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> Привет всем.
>
> Мы как-то тут обсуждали тему повторяемости результатов. Пришлось вернуться к
> этой теме, так как она для меня осталась нераскрытой.
>
> Что лучше:
> а) быстро выпустить то, что нужно сейчас, тем самым повысив вероятность
> переработок потом, но получить при этом обратную связь и откорректировать
> курс проекта?
> б) либо же - разработать продуманную гибкую архитектуру, которая с большей
> вероятностью сможет вместить новые требования?
>

> <http://www.krivitsky.com/2008/11/repeatable-vs-effective.html>Вступление,

> ход мысли и мои выводы

> тут<http://www.krivitsky.com/2008/11/repeatable-vs-effective.html>

[Artjom Serdyuk]

Написал пост на три экрана а потом вытер.Не хочу лезть в
оптимизационные дебри ;))

Лучше задам вопрос: а как сравнить "хорошесть" подходов?

On Nov 8, 8:50 pm, sun <aleksey.solnt...@gmail.com> wrote:
> ну, никак не похоже )))
>

> 2008/11/8 Artjom Serdyuk <artem.serd...@gmail.com>:

[Artjom Serdyuk]

Апгрейжу ;))

Ты сказал "эволюция", я вспомнил живую природу и "генетические
алгоритмы" для решения задач оптимизации.

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

On Nov 9, 12:57 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> ребята, на каком языке вы разговариваете? я перестал понимать ;)
> если я пропустил какой-то качественный скачок в общении пока был в харькове,
> то вы, плиз, меня проапгрейдите
> .
>

> 2008/11/9 sun <aleksey.solnt...@gmail.com>

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

> > 2008/11/8 Sergiy Movchan <sergiy.movc...@gmail.com>:

> > > а мне как раз кажется похожим.
> > > делаем шаг, анализируем результат, если видим улучшение, то делаем
> > > (больший?) шаг в ту же сторону, а если нет, то поворачиваем.
>

> > > 2008/11/8 sun <aleksey.solnt...@gmail.com>

>
> > >> ну, никак не похоже )))
> > >> в генетических алгоритмах есть стандартый набор приёмов, применив
> > >> которые можно достичь результата.
> > >> в agile к сожалению такого нет (
>

> > >> 2008/11/8 Artjom Serdyuk <artem.serd...@gmail.com>:

> LinkedIn: ...
>
> read more >>

[Artjom Serdyuk]

Я отвечу на часть "эффективность vs повторяемость".

"Сначала стабилизируйте процесс, а потом улучшайте". Деминг

"Эффективность дают _процедуры_ - стандартные действия на
повторяющиеся проблемы". Адизес.

И по Адизесу, и по Демингу, правильный путь такой:
1) сделайте так, чтобы работало
2) то, что можно, выделите в процедуры
3) улучшайте.

Опять-таки, по Адизесу:
В _младенчестве_ организация "тушит пожары" - делает так, чтобы
работало "сейчас" (т.е. только п.1 из списка).
В _юности_ организация прописывает процедуры и рождает организационную
структуру со всеми вытекающими (пп. 2 и 3).

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

Т.е. если мы сейчас только тушим пожары, значит мы просто ещё не
доросли до процедур.

On Nov 7, 12:15 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> Привет всем.
>
> Мы как-то тут обсуждали тему повторяемости результатов. Пришлось вернуться к
> этой теме, так как она для меня осталась нераскрытой.
>
> Что лучше:
> а) быстро выпустить то, что нужно сейчас, тем самым повысив вероятность
> переработок потом, но получить при этом обратную связь и откорректировать
> курс проекта?
> б) либо же - разработать продуманную гибкую архитектуру, которая с большей
> вероятностью сможет вместить новые требования?
>

> <http://www.krivitsky.com/2008/11/repeatable-vs-effective.html>Вступление,

> ход мысли и мои выводы

> тут<http://www.krivitsky.com/2008/11/repeatable-vs-effective.html>

[Anton Maryukhnenko]

Ты таки не удержался и пост на три экрана разбил на три маленьких поста :)))

2008/11/10 Artjom Serdyuk <artem....@gmail.com>

--
Sincerely,
Anton Maryukhnenko

[Artjom Serdyuk]

та не, на три экрана было про оптимизацию, сходимость и т.п. ;))

On Nov 10, 2:37 pm, "Anton Maryukhnenko" <maryukhne...@gmail.com>
wrote:

> Ты таки не удержался и пост на три экрана разбил на три маленьких поста :)))
>

> 2008/11/10 Artjom Serdyuk <artem.serd...@gmail.com>

[Anton Maryukhnenko]

Если где то осталось, кинь в личку :)

2008/11/10 Artjom Serdyuk <artem....@gmail.com>

--
Sincerely,
Anton Maryukhnenko

[Artjom Serdyuk]

Спросил у ктн, которые защищались по оптимизации.

Они сказали, что "генетический алгоритм - это жест отчаяния, когда
ничего другое уже не работает. И он даёт приемлемое решение, а не
точное, и то только в том случае, когда алгоритмы скрещивания и т.п.
прописаны хорошо" (с).

Так что моя аналогия не спрацювала ;(

On Nov 9, 10:42 am, sun <aleksey.solnt...@gmail.com> wrote:
> изменить и сравнить с целевой функцией -  это главный принцип одной из
> групп методов отпимизации.
> в генетических методах нельзя сказать делаем мы маленький или большой
> шаг - мы просто что-то меняем, выборочно изменяя параметры. хочу
> подчеркнуть - выборочно.
>

> 2008/11/8 Sergiy Movchan <sergiy.movc...@gmail.com>:

>
>
>
> > а мне как раз кажется похожим.
> > делаем шаг, анализируем результат, если видим улучшение, то делаем
> > (больший?) шаг в ту же сторону, а если нет, то поворачиваем.
>

> > 2008/11/8 sun <aleksey.solnt...@gmail.com>

>
> >> ну, никак не похоже )))
> >> в генетических алгоритмах есть стандартый набор приёмов, применив
> >> которые можно достичь результата.
> >> в agile  к сожалению такого нет (
>

> >> 2008/11/8 Artjom Serdyuk <artem.serd...@gmail.com>:

[sun]

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

2008/11/10 Artjom Serdyuk <artem....@gmail.com>:

--
sun

[Serhiy Yevtushenko]

По аналогиям.

Я ктн (правда, не по генетическим алгоритмам), но работал в коллективе, который занимался метаэвристиками (генетические алгоритмы, итеративный локальный поиск, ant colony optimization, ...).

 

Так вот, ИМО, аджайл и другие подходы скорее похожи на локальный поиск (то есть, определяем по текущей ситуации направление, которое дает наилучшее улучшение по имеющимся оценкам, затем двигаемся в этом направлении, проверяем результат, затем далее повторяем этот цикл).

 

Такие алгоритмы могут быть очень эффективны (например, симплекс метод в линейном программировании).

Такие алгоритмы в общем случае находят локальный оптимум.  (когда находишся на вершине горы, и дальше двигаться некуда), хотя рядом могут быть еще более высокие горы.

 

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

 

При применении итеративного локального поиска для решения сложных задач (NP-complete) для хороших результатов важно иметь также способ построения хорошего начального решения, с которого можно начинать итеративное применение локального поиска.

 

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

 

Также в метаэвристики почти всегда встраивается элемент случайности выбора, который и обеспечивает доказатальство нахождение глобального оптимума ( за счет случайного поиска_.

 

 

10 ноября 2008 г. 17:22 пользователь sun <aleksey....@gmail.com> написал:

[Artjom Serdyuk]

Сергей, спасибо!

По аналогиям:
какие Вы видите аналогии в аджайл-процессах:

* (оптимизация) оценка "хорошести" решения => (аджайл) ?
* определение направления, дающего наилучшее улучшение => ?
* пертурбация => ?
* хорошее начальное решение => ?
* механизм построения такого решения => ?
* элемент случайности выбора => ?

Я спрашиваю, потому что по моим ощущениям в скраме что-то пропущено, и
я очень хочу найти это "что-то".

Спасибо.

On Nov 11, 11:24 am, "Serhiy Yevtushenko" <syevtushe...@gmail.com>
wrote:

> 10 ноября 2008 г. 17:22 пользователь sun <aleksey.solnt...@gmail.com>написал:

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

> > 2008/11/10 Artjom Serdyuk <artem.serd...@gmail.com>:

> ...
>
> read more >>

[Serhiy Yevtushenko]

11 ноября 2008 г. 12:24 пользователь Artjom Serdyuk <artem....@gmail.com> написал:

Сергей, спасибо!

По аналогиям:
какие Вы видите аналогии в аджайл-процессах:

* (оптимизация) оценка "хорошести" решения => (аджайл) ?

Демо - оценка заказчиком

Аттрибуты качества решения с инструментами их измерения (Evo (Tom Gilb))

* определение направления, дающего наилучшее улучшение => ?

Инструменты - приоритизация беклога продакт оунером/разработка наиболее приоритетных свойств

Impact Estimation Table (Tom Gilb)

 

* пертурбация => ?

Старт нового проекта/продукта ???

* хорошее начальное решение => ?

Архитектура ???

* механизм построения такого решения => ?

Опыт предыдущих проектов ???

 

* элемент случайности выбора => ?

 

Вот тут ничего предложить не могу

[Serhiy Yevtushenko]

хорошее начальное решение => ?

механизм построения такого решения => ?

 

Другие аналогии -

Цветное моделирование в ФДД и построение каркасной модели предметной области

 

Фасилитируемые воркшопы по сбору требований в DSDM