Saturday, February 03, 2007

Post-Agile

Это должно было свершиться и это свершилось. В наше время быть "новой методологией" в течении 10 лет невозможно. 10 лет это слишком долго, чтобы называться "новым".

Итак, прощай Agile, здравствуй Post-Agile. Early adopters уже "наигрались" с Agile, перепробовали все предлагаемые практики и методологии в разных комбинациях, и теперь им стало скучно с Agile. На текущий момент определенной новой сформировавшейся методологии нет, но Google уже выдает более 10тыс. результатов по фразе "Post-Agile".

Flow – одна из методологий (или, скорее, идеологий), претендующих на звание Post-Agile.

Сейчас "на коне" web2.0 проекты и цикл их жизни очень сильно отличается от жизненного цикла локальных конечнопользовательских приложений и, еще больше, от жизненного цикла корпоративных систем. Основное отличие в том, что эти проекты не предлагают решения проблем или нужд пользователей, они развлекают, делают жизнь более приятной, красочной, интересной. Многие из них, безусловно, очень полезны, но не необходимы. А так как любая игрушка рано или поздно надоедает - надо пользователям постоянно давать что-то новое, чем-то их привлекать снова и снова, чтобы они не ушли на другой свежий ресурс. Именно на это нацелен Flow:

Картинка из поста "What comes after usability?"

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

8 comments:

Sergey Rozovik said...

Назвать это новой методологией ИМХО нельзя. Но какое то зерно в этом есть. Я скажу больше, многие (разработчики) работают в режиме "Flow" не подозревая об этом. В статье Jenova Chen, посвященной "Flow" есть интересный график challenge - abilities. Когда челендж превышает наши возможности мы попадаем в полосу сплошного стресса, когда возможности выше, чем сложность задач - это становится скучно. А посередине располагается наиболее комфортная для работы область - flow.
Я, кстати сам работал в таком режиме, не поверите, лет 7 назад. :) Было это в АСУП большого предприятия, мы разрабатывали ряд локальных приложений (типа "расчет себестоимости"), сведя их в один внутренний web портал на ASP и ISAPI. Никаких требований не было, вернее они были - но передавались изустно пользователями, которых у нас было человек 50. По началу приложения были простые, но по мере того как мы набирались квалификации, приложения становились все сложнее внутри, но проще и функциональней для пользователей. Порой мы добавляли туда фичи, о которых нас никто не просил, но пользователями они принимались на ура (типа поздравлений в день рождения пользователей при заходе на портал :)
Как теперь я понимаю - это был настоящий "Flow" :)

Elena Makurochkina said...

Методологии пока еще нет, но это, как мне кажется именно пока.
Flow - хорошая идея, вокруг которой можно построить методологию. А может она и не пойдет дальше. Но какая-то новая методология обязательно должна появиться. Сейчас идет поиск вокруг чего ее кристаллизировать - вокруг Users's Needs или Development Process. В любом случае в конечном варианте должно быть и то и другое.

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

Alex Ott said...

на мой взгляд, это все просто новые слова, такие же как раньше были "java, linux, xml". в них есть рациональное зерно, но они без меры раздуваются, пытаясь применить их там, где они неприменимы

Elena Makurochkina said...

2 Alex Ott:
Абсолютно согласна с тем что практически любое повое понятие в IT, ставшее популярным, очень быстро превращается в buzzword и начинает упоминаться всеми к месту и не к месту. Но это не повод не придумывать ничего нового :)

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

Майевтик said...

Спасибо за эту тему!

Это хорошо согласуется с моим видением того, что атрибуты качества системы с точки зрения пользователя надо выстраивать в пирамиду, только я исходил из более простой модели -
1. Функциональность
2. Удобство
3. Эстетика

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

copylove said...

Вот отличные две статьи на эту тему:
http://dev.uxmatters.com/MT/archives/000124.php
http://dev.uxmatters.com/MT/archives/000152.php

Также, в комментариях к первой частью некий "Anonymous" высказался так:
"For a similar use of Maslow's hierarchy of needs, see "Universal Principles of Design" by Lidwell, Holden, and Butler. They use the following levels: functionality, reliability, usability, proficiency, and creativity"

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

Elena Makurochkina said...

2 Майевтик:
"я исходил из более простой модели -
1. Функциональность
2. Удобство
3. Эстетика"


Выстраивание того, что надо пользователям по приоритетам это, в общем-то, идея не новая. Новое - именно порядок. Обратите внимание - у вас Функциональность на первом месте, а в Flow на последнем.

Иерархия нужд (именно нужд, а не требований) очень сильно зависит от ниши продукта.
Функциональность всегда была на первом месте для корпоративных систем и для продуктов, которые решают какие-то сложные проблемы пользователей. Например «полетел» HDD – вы воспользуетесь первым продуктом, который продемонстрирует, что может спасти ваши данные, не зависимо от интерфейса.
В нишах полезных, постоянно используемых продуктов (особенно при наличии большого количества конкурентов) на первое место выходит usability. Я постоянно пользуюсь RSS reader-ом и перебрала довольно много вариантов. Функциональность плюс-минус у всех одинаковая, т.ч. мне уже важно насколько удобно мне пользоваться конкретной программой или сервисом.
Практически все методологии разработки нацелены имнно на эти 2 ниши.

А сейчас, прямо на глазах, сформировался новый класс – развлекательный. Это casual games (он и раньше был, но сейчас это уже стало совсем отдельной индустрией) и разнообразные web проекты. Вот для них постепенно выкристализовывается новая методология.

Т.ч. на счет перетекания приоритетов пользовательских качеств игрового ПО в сферу ПО массового пользования абсолютно согласна, а вот что это дойдет до корпоративного ПО – это совсем не реально.

Elena Makurochkina said...

2 copylove:
Большое cпасибо за ссылочки.
Но весь фокус в том, что Flow использует иерархию, перевернутую с ног на голову.