понедельник, 28 декабря 2015 г.

Системный моделер из стены и липучек




     User story mapping -- http://jpattonassociates.com/user-story-mapping/. Основная заявленная идея тут упорядочить пользовательские задачи (activities) во времени, из историй сделатьэпопею. Если внимательно приглядеться, то время оказывается логическим -- привет, вид жизненного цикла (то бишь практики) по горизонтали с разбивкой на эпические/тематические подпрактики по вертикали. 


    Тем самым user story mapping оказывается про принципиальную схему взаимодействия пользователя с системой, функциональный анализ -- "как оно работает, как получается польза". Поэтому user story map так сильно отличается от product backlog, который появляется исключительно в попытке модульного синтеза -- "как это реализовать, из каких кусков сделано".
    Поразглядывайте примеры для user story map в google image. Очень поучительно.
    И сразу становится понятным, почему user story mapping хорошо сочетается с domain-driven design (DDD) --http://blog.eriksen.com.br/en/mapping-domain-knowledge.
    Забавно, как принципы хорошего архитектурного моделирования, основанные на системном мышлении мееееедленно вползают в жизнь: из стенки и липучек изображают эдакий системный моделер, который по мере воплощения основных принципов системного мышления работает лучше и лучше. 

    Одно системное мышление, тысяча применений.

    Но интересно читать, как понятия архитектурной работы "по норме" пытаются изложить "на пальцах" в коммуникативной парадигме ("истории", "нарратив", "эпопеи"). Скажем, берём принципиальную схему радиоприёмника, и рассказываем про "эпопею настройки колебательного контура", "эпопею подключения антенны", только чтобы не использовать системноинженерного языка. 
    Вот что пишет автор подхода user story map (http://jpattonassociates.com/the-new-backlog/): "I hate that word “epic.” I haven’t written Beowulf here. There’s no hero with a magic weapon slaying a monster. It’s just my user “managing email” – a relatively basic thing from my user’s perspective. At least the terms “activity” and “user task” give me some idea of what kinds of stories they are. That said, I’m not fond of the term “user story” either, but I’ve come to accept it. It beats the crap out of requirement
    Куда ведёт в этой цитате ссылочка со слова requirements? К его же статье Requirements considered harmful, где от слова requirements с его кажущейся неизменяемостью и окончательностью он уходит к слову decision, что можно было бы изменять и объяснять. Но кончается всё опять-таки не словом desicion, а теми самыми "нарративами" и "эпопеями" (epic) в user stories -- описаниями. Требования всего-то описания системы как чёрного ящика, со стороны её работы в составе использующей системы. И, конечно, описания могут меняться по мере продвижения в понимании, почему бы и нет. 
    То есть борьба у современных аджилистов IMHO идёт с ветряными мельницами, а не "бюрократической инженерией", но при этом медленно-медленно всё таки они ползут в сторону принятия системного мышления -- а хоть и устраивая системный моделер из стенки и липучек. Но мне кажется, один раз разницу между модульными и компонентными описаниями объяснить проще, чем мучительно переизобретать её снова и снова (например, противопоставляя product backlog и narrative -- хотя да, требуется дополнительный мыслительный шаг, модуль в product backlog это не просто новый файл или обособленный фрагмент кода, но распределённость в мышлении о модуле дела не меняет. Это именно "из чего сделано").
    *   *   *

    Это у нас дома пирожок дня:
    то нету силы есть работа
    то нет работы сила есть
    то есть и сила и работа
    а нужен косинус угла

    © broad
    Тестирование системы в целом зло, оно и дорого, и не достигает запланированных результатов: http://www.infoq.com/news/2015/12/end-to-end-testing. Там много чего ещё интересного. Например, You discuss that creating a fragile system that prioritises low mean time between failures (MTBF) over mean time to recovery (MTTR) can lead to risk in regards to exposure to 'Black Swan' events. How can developers and operators convince management of the reality (and inherent risk) of this issue? -- и далее объясняется, как.

    Как запасать энергию в воздухе по стоимости ниже батарей, и сколько миллионов долларов и лет стоит разработать для этого компрессор --http://www.technologyreview.com/qa/544611/the-energy-startup-conundrum/. На рынке электроэнергии скоро будет очень весело, накопители-то подтягиваются. 

    Иллюзии на социальных сетях: как ошибиться в мнении большинства (это ведь легко!) -- http://arxiv.org/abs/1506.03022. Individuals often lack global knowledge of the behaviors of others and must estimate them from the observations of their friends' behaviors. In some cases, the structure of the underlying social network can dramatically skew an individual's local observations, making a behavior appear far more common locally than it is globally. "Majority illusion" may facilitate the spread of social contagions in networks and also explain why systematic biases in social perceptions, for example, of risky behavior, arise. 

    А вот официальное подтверждение правильности бесцельного существования: http://www.amazon.com/Why-Greatness-Cannot-Planned-Objective/dp/3319155237. Постановка чётких целей в сложных ситуациях -- зло, сфокусированность на достижении целевых показателей любой ценой -- меднолобый фанатизм, хорошего из этого ничего не выйдет.

    Ух, почти все табы браузера позакрывал. Практически рекорд этого года. Хотя в pdf-ридере этих табов уже зашкаливает, но что с этим делать -- не понимаю. И вообще, нужно чистить свой списочек GTD -- там ведь залежи каких-то старых хотелок, на экран список уже не помещается. Нужно сосредоточиться, и отважно наступить на горло всем этим собственным песням, всё равно ведь руки до них не дойдут. Бесцельность, так бесцельность. Всё по науке!

    Комментариев нет:

    Отправить комментарий