2017-10-26 - SECR-2017: Ivar Jacobson и другие

Короткая ссылка: SECR-2017

Ссылки сюда (2) →

Прошла очередная, тринадцатая конференция SECR-2017, и название поста отражает мое главное впечатление о ней. А вообще это было в Санкт-Петербурге, два дня 4 трека докладов и один - мастер-классы, а на третий день, в воскресенье - еще три мастер-класса параллельно.

О других конференциях

На конференции - много умных и опытных профессионалов, и этим она отличается от других. И это - не только докладчики, но и участники, и ряд докладчиков, общаясь со мной, отмечали качество вопросов от слушателей. А еще конференция отличается от других широтой охвата тем, возможностью заглянуть в соседние области, которая, на самом деле, не часто получается. Так устроены многие региональные конференции, задача которых - поднять уровень сообщества в целом. А вот российские преимущественно специализированные - аналитики, java-разработчики, .net-разработчики, интернет-разработка и многие другие. Хотя, тут надо отметить, что ряд конференций интернет-разработки расширяет свою тематику, поскольку web и мобильная разработка сейчас охватывает практически все области IT. И еще широким мероприятием является питерский IT Global Meetup, на котором, кстати, я буду выступать в ближайшую субботу. Возвращаясь к SECR хочу отметить, что широта охвата - увеличивается, хотя формально это, быть может не слишком заметно. Просто отдельные доклады превращаются в секции: в прошлом году пришли аналитики, в этом году - технические писатели и секция TOC и ТРИЗ. И достаточно широко представлены ВУЗы, в том числе региональные, например, из Ульяновска, где ВУЗ тесно сотрудничает с местными IT-компаниями. Интерес ВУЗов и вообще, тез, кто занимается наукой, понятен - SECR имеет статус партнера ACM SIGSOFT и доклады, поданные в форме научных статей (и прошедшие отбор), попадают в электронную библиотеку и индексируются. За лучший научный доклад, кстати, уже несколько лет присуждается премия Бертрана Майера.

Естественным образом, в рамках задачи "заглянуть в смежную область и на мировой уровень", SECR зовет иностранных спикеров. В этом году приезжал Ивар Якобсон, в общем-то человек-легенда. А еще - Эрик Райс, только не тот, который написал про Lean, а тот, который гуру в Usability (их двое, а имена совпадают, поэтому поясняю). И ими число иностранных спикеров не ограничивалось. А еще в этом году был интересный эксперимент: мы предлагали русскоязычным докладчикам делать выступления по-английски. И было достаточно много тех, кто согласился. Одна из целей - сделать конференцию действительно международной и интересной не только для русских участников и спикеров. Потому что иначе спикер, прочитав свой доклад, в общем-то скучает. И вопрос же не только в переводе, но и в слайдах. С другой стороны, для российских докладчиков это получается возможность порепетировать доклад для рассказа на международных конференциях, что тоже ценно. Посмотрим, что из этого выйдет, насколько конференция пойдет в международное русло.

В целом на конференции я много общался и меньше ходил на доклады. Зато с тех докладов, которые слушал - сразу публиковал заметки в facebook. Поэтому формат рассказа дальше будет такой: я расскажу о выступлениях Ивара Якобсона, потому что мне кажется, что содержание - важно. Немного представлю свой доклад, а затем - соберу посты из FB.

Ивар Якобсон и OMG Essence

Видео и слайды

Естественно, Ивар рассказывал про свой продукт - OMG Essence. Это было основным содержанием и его доклада на конференции, и мастер-класса. Но это была не просто презентация продукта "смотрите, что мы сделали". Это был рассказ о целях, для которых он был сделан, и способах его использования для их достижения.

И для начала я хочу процитировать свой пост в FB. #secrus В продолжение вчерашнего поста про методы Agile и предпочтение SAFe - доклад Ивара Якобсона. Все существующие методы - монолитны, не модульны, со своим user experience, структурой, терминологией, стилем. Их комбинируют, но они изначально для этого не были предназначены. И жесткие рамки метода - как тюрьма, которую еще и контролируют гуру этого метода. Надо разбить монолит, и освободить практики из тюрьмы методов и надсмотра гуру, ведущих методологический войны, предоставив возможность их комбинировать, собирая индивидуальные методы проекта. Прекрасный доклад и великолепные метафоры!

Оригинал Димы Безуглого

Оригинал Димы Безуглого

И вообще, это прекрасно - когда известный и достойный гуру говорит о том, что гуру - они лишние, они сковывают развитие методов, потому защищают в нем что-то свое от чужих посягательств. При этом люди-то, наоборот - хотят гуру, хотят всеобъемлющих методов, которые можно взять как готовые, во всяком случае сначала. Об этом как раз было обсуждение накануне на выступлении Асхата, где в опросе лидировал сверхсложный SAFe именно за свою всеобъемлемость - как до сих пор популярен RUP и ментально - именно по этой причине. Сам Ивар, кстати, RUP переосмыслил, и пошел дальше. OMG Essence - результат этого пути. Отмечу, правда, что Дима Безуглый утверждает, что получился RUP в гриме. Но мне кажется, он просто опознав опорные конструкции достраивает хорошо знакомую ему конструкцию до полной. А вот этого делать вовсе не обязательно и в Essence как раз такой детализированной полноты - нет, в нем полнота - концептуальная.

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

Эдуард Галиаскаров Примеры были? Можешь пересказать?

Максим Цепков Примеры для меня очевидны. ScrumGuide - одна терминология, PMBOK - другая, и так далее. Вчера Асхат делал доклад про фреймворки масштабирования Agile - каждый дает свой шаблон организации, некоторые - крайне сложный, и не особо заботится о сопряжении с другими. Scrum очень долго шел к тому, чтобы абстрагироваться от конкретной практики user story для ведения требований. Сейчас на уровне ScrumGuide задача решена, там понятие program backlog item, но в более широкой рамке планирования релизов - не до конца. (Это - мой пример, не Ивара)

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

Максим Цепков Ну, да, все как и в проектировании софта: пришла команда и сделала монолит. Но в софте довольно давно работают над подходами компонентной и далее микросервисной архитектуры, а в управлении - пока была эпоха монолитов. И только OMG Essence открывает время компонентной архитектуры..

Сергей Нужненко Я что-то не совсем понимаю. То есть организация разработки ПО не подчиняется тому, что написано в учебнике по организации производства? А, может, именно наслоения монолитных методов и вавилонское столпотворение в терминах мешает увидеть отсутствие отличий от обычного производства и проектирования?

Максим Цепков Конечно, не подчиняется, и это - очень старая новость. Том ДеМарко PeopleWare, 1987. А еще - весь классический менеджмент - про организацию физического труда, а организовывать умственный он не умеет. Это тоже не я, это Питер Друкер (с 1980-х в разных работах, в нулевых - отдельной книгой). А почему разработка - умственный труд, и какие из этого следствия именно для IT - раскрыл Reeves в статье 1992 года, и это - тоже известная вещь.

Сергей Нужненко Похоже, тут конфликт культур. Врядли мы договоримся

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

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

Максим Цепков Сергей, Ривз, на статью которого я ссылался, все это очень хорошо разобрал, показав, в чем отличается производство софта от конструирования самолетов, и какие из этого отличия есть следствия в методах, из-за которых скучный учебник по организации производства оказывается не применим. Статья - классическая - я сам на нее вышел по ссылкам в нескольких статьях и книгах уважаемых авторов. Это - про устройство мира. А практический индикатор для меня прост: столкнувшись с успехами Agile IBM и Microsoft начали перестраивать свои весьма громоздкие производственные машины, сделанные высококвалифицированными людьми по тем самым учебникам. Потому что у Agile перспектив больше. Ну и еще статистика, но вот это - индикативные примеры. Что касается недостатка кадров, то это - системная проблема, возникшая с появлением персоналок, и ситуация будет только ухудшаться. Именно потому, что Agile предоставляет возможность команде за счет кооперации делать то, для чего при классическом способе квалификации. При этом потребность в разработке будет только расти, и потому закрывать ее будут Agile-методами, а не квалифицированными кадрами - это быстрее, дешевле, а результат - не хуже по качеству, а значит, с учетом сроков - лучше.

Асхат Уразбаев Ивар кажется возится с этими идеями лет 40 уже. Фундаментальная проблема в его системах (уже третья!) - никто никогда не строит свой процесс "с нуля" из кирпичиков. Все идут от проблемы, которую надо решить. Она должна быть понятна на уровне бизнеса, иначе тебе денег никто на изменения не даст.

Максим Цепков Не, Ивар это переосмыслил прежние подходы лет 7 назад, когда SEMAT начался. А реально Ивар решает несколько понятных и актуальных проблем.

1. Как наблюдать за прогрессом множества команд и проектов сверху, при том, что каждая команда использует свой метод, живущий и адаптирующийся в ходе ретроспективы.
2. Как относительно быстро людям осваиваться в другой команде при внутрикорпоративных перемещениях, где все вроде похоже, но по-другому.
3. Как строить композитные процессы, взяв какой-либо за основу (строить с нуля - действительно лишнее), но дополняя практиками других. Для простых процессов (Scrum/Kanban и гибриды) решается без сложного формализма, а вот в сложных процессах - нет.
4. Как эффективно обучать/представлять совокупность методов без того, чтобы надо было осваивать понятийный аппарат каждого.

Наиболее актуально, на мой взгляд, проблема-1.

Асхат Уразбаев А зачем отслеживать? Отслеживание должно быть "actionable", то есть должны приниматься какие-то управленческие решения. Как это работает у Ивара?

Максим Цепков Работает как с доской и/или burndown. То есть смотришь - и принимаешь управленческие решения. Коллективно в команде или каждый индивидуально. На уровне сопоставления разных проектов из программы, на уровне большого проекта, состоящего из многих, или на уровне отдельного проекта. Для отдельного проекта отслеживается пренебрежение отдельными аспектами (например, делают систему "непонятно для кого", без понимания целей бизнеса). Решения еще завязаны на метод, но общая схема представления от него зависит слабо, тут ситуация напоминает доску, которая тоже различается для разных методов и проектов, но при этом общий принцип сохраняется. Просто доска - только трек отдельных задач/фич, а здесь - больше аспектов.

Сергей Рогачев Мы проводили такие мероприятия. К сожалению, на уровне менеджмента такие детали уровня конструктор лего не дают возможности принятия решений. Им нужен ментор, который смог бы объяснить маппинг их проблем на эти отдельные кубики. То есть выходит, что это инструмент Agile-коуча (ментора). И второе, это слабо влияет на реальные изменения в командах: ату "всем завтра внедрить такую-то штуку" сверху не работает - эти кубики надо продавать командам, чтобы решить задачи-проблемы их бизнеса-менеджмента. Итого, выходит, что бизнесу-менеджменту нужно решение проблемы, но решить проблему может только команда, поэтому конструктор решения проблем не нужен бизнесу, но, возможно, нужен команде и их ментору. А это... по сути просто инструмент ретроспективы, не более того. Короче, слишком сложно по мне.

Максим Цепков Сергей Рогачев С OMG Essence - как с диаграммами бизнес-процессов. Сначала ты рисуешь их сам, чтобы понимать, показываешь бизнесу. потом бизнес тоже начинает их понимать, можно на них обсуждать. А дальше - он и сам это дело рисует, а не просто говорит. Но язык Essence - это сильно больше, чем просто бизнес-процесс, в этом ценность. Теперь про проблемы и практики. Это как шаблоны программирования, тоже очень похоже. Есть какая-то проблема, например, нарушена коммуникация, или что-то бросаются разрабатывать раньше, чем убедились в необходимости у стейкхолдеров или что-то еще. У тебя в библиотеке есть практика под нее, например, особая фаза ретроспективы, или отдельный чек-лист по проверке готовности на планировании, Ты ее достаешь и добавляешь к процессу - но не только текстом, а на схемах. Естественно, не сверху "всем внедрить", а в каждой команде отдельно. А дальше каждая команда идет своим отличающимся путем - она же его на ретро корректирует, плюс могут быть отдельные сессии со стейкхолдерами по удовлетворенности работой команды, еще что-то. И тут есть инструмент компактного описания для тех, кто смотрит на ситуацию в целом, сравнивает команды и т.п. - для agile-коучей, руководителей и других. Но применять имеет смысл только если организация - большая, команд - много. Иначе - да слишком сложно, можно и без этого.

Сергей Рогачев Maxim Tsepkov мне показалось, что ты подтвердил мое впечатление. Это инструмент ментора. Но инструментом команды он не станет. Команда пока что-то не переживет на своей шкуре, не верит никаким авторитетам: именно поэтому мы на тренингах даём меньше теории, но больше упражнений и игр - если не верят авторитетам, то как поверят библиотеке? Про общение с бизнесом и менеджментом - да, но опять же инструмент ментора: посмотрел, сделал выводы и... пошел к бизнесу с предложением изменений на обычном языке. :)

Максим Цепков Сергей Рогачев Подтвердил, но отчасти. Начинается все с ментора, так же как рисование процессов через activity diagram начинается с аналитика. А дальше - развилка: ментор, как и аналитик может оставить эти диаграммы себе, разговаривая с остальными на привычным им языках (простыми текстами или вольными картинками), а может - обучить простым диаграммам, и при успехе они начнут пользоваться. Что уместно - зависит от ситуации.

Максим Цепков Что касается авторитета и библиотек, то тут как с кодом. Многие программисты свято уверены, что лучший код могут написать они сами, и таких надо учить паттернам и практикам эффективного кодирования. Но зрелые-то знают, что все-таки целесообразно посмотреть, может кто что написал, и можно использовать готовое, и часто берут чужой код, а если он открыт - то и дописывают. И вот когда к процессам команды ментально начнут относиться как к коду (ну или к проекту системы) - тут тоже произойдет перестройка.

Александр Юняев Максим Цепков, в первом ответе Асхату перечислены 4 проблемы. Каков ответ Ивара на них?

Максим Цепков На все 4 проблемы Ивар говорит "мы разработали OMG Essence для того, чтобы это решить", и дальше показывает, как именно, в докладе и мастер-классе, ну и других работах. Если кратко, то там измерение прогресса оторвано от метода, и потому можно сопоставлять разные проекты, предложен язык для описания методов, большинство существующих методов в IT описаны как комбинация практик в модульном виде (часть - в самом стандарте как примеры, часть есть в библиотеке Ивара), а конструкция языка предусматривает точки расширения, в которые ты можешь вставлять свое, а так же заменять одни практики на другие.

Александр Юняев Максим, ты для себя какую-то позицию сформировал по отношению к OMG Essense?

Максим Цепков Я для себя его осваиваю, мыслю в этих категориях и пытаюсь применять. Что касается использования в коллективной работе, то тут как с Archimate для описания архитектуры предприятия: инструмент - мощный, но с существенным порогом входа, поэтому сильно зависит от команды. Archimate, кстати, я у нас в компании пробовал применять лет пять как, не получалось. Но сейчас в некоторых командах - используют. А в других - не идет. Так и с OMG Essence будет, все-таки сложноват он несмотря на все усилия.

А еще я хочу дать ссылку на пост Димы Безуглого про доклад Ивара, в нем и комментариях - фото слайдов презентации (впрочем, презентацию скоро выложат вместе с остальными) и обсуждение. Процитирую. Отличный пример системного мышления по отношению к проблеме разных методологий. Вызов вызовов - создать платформу для методологий и привлечь на нее создателей методологии и потребителей :) ... Для меня разница и вопрос в глубине и системности рассмотрения темы методологии. Я тоже не очень верю в будущее Essence как платформу для практик, хотя Ivar много сделал в этом направлении и шанс есть. Определенный сегмент уже там. Но популистический гон(иначе не скажешь), который идет от большинства проповедников "Гуру" последнего поколения методологий это просто стыдобища.

В воскресенье мы вместе с Димой и еще 15 участниками были на мастер-классе Ивара, посвященном работе с рисками проектов и мониторингом его движения. И начался он с довольно большой вводной части по сопоставлению разных подходов. Интересно и требует определенного осмысления. А дальше - был практический, как к этому подходит Essence, отслеживая продвижение альф по состояниям. Включая конструирование состояний на примере гипотетического проекта и на примере английского стандарта по фазам проекта и критериям продвижения - его сопоставляли с теми фазами, которые дает Essence в виде "отправной точки". Отмечу, кстати, что Ивар не уложился в тайминг (что достаточно часто бывает), но не остановил мастер-класс, а продолжил еще полтора часа. Это - культура: есть обязательства перед аудиторией, и их надо выполнять.

Agile

Тема Agile логично продолжает выступление Ивара, хотя на конференции ей предшествовала.

Доклад Асхат Уразбаев - хороший обзор фреймворков масштабирования Agile в одном докладе. И голосование. По голосованию победил SAFe, и он же лидирует по популярности в мире. SAFe воcпроизводит идею PMBOK и RUP: у нас ВСЕ написано, возьмите нужное. Люди плохо учатся на ошибках прошлого... Особенно инженеры: ну и что, что раньше у других не получилось, у нас-то точно получится.

И я тут как раз хочу отметить, что видно большая разнородность представленных фреймворков. Которые описаны через визуальные образы, не являющиеся схемами, а просто картинками, представляющими фреймворк. В результате мы получаем монолиты, разборка и пересборка которых предлагается делать на свой риск - авторы этого не предусматривают, даже в наиболее сложном SAFe в поставке - несколько стандартных конфигураций, а вовсе не модельная система. Кстати, на сайте Ивара в Practice Library есть формальное описание SAFe и не только его в языке Essence, я смотрел - интересно. Доступ к библиотеке - бесплатный, но требует регистрации.

Доклад Dmitry Lobasev. Не надо внедрять Scrum просто так, даже если заказчик этого хочет. Надо поднять до проблемы, которую Заказчик хочет решить - подобрать инструменты. И надо различать Task Work и Knowledgу Work - для них - разные методы. А компании внутри сейчас это часть путают, и подходят к проверке гипотез как к операционной работе, а к taskwork подходят как к проектам. И проваливают и то и другое. Казалось бы, мысли понятные, но при этом не очевидные. И доклад вскрывает причины и разбирает кейсы.

Мой доклад

Оригинал Sergey Pchelyakov

Мой доклад на конференции Бизнес-анализ: от абстрактного замысла до внедрения и дальнейшего развития ИТ-решения, как легко догадаться из названия, был посвящен практикам и компетенциям бизнес-аналитика. Дело в том, что содержание работы бизнес-аналитика с тех времен, когда были написаны классические учебники Вигерса, Коберна и других классиков, принципиально изменилась. Если раньше основой работы был именно анализ, фиксация и, далее, трансляция на язык, понятный IT, требований к IT-системе и представлений о ее окружении, то есть предметной области, то сейчас основной фокус идет на совместном с бизнесом проектировании социотехнической системы, реализуемой совместно бизнесом и IT-разработчиками в общем проекте. Рамки проекта - тоже расширились.

Вот эти изменения, вместе с расширенным жизненным циклом проекта, составом работ на каждой фазе и ключевыми компетенциями я и рассказывал. Естественно, OMG Essence при этом тоже использовался - чтобы показать изменение рамки проекта, которое он зафиксировал, и чтобы представить тот жизненный цикл, который мы используем у себя в компании. При этом OMG Essence не был единственным формализмом и источником терминологии. И, в общем-то странно, если бы он был таким. Ведь он появился сравнительно недавно и представляет собой новое явление, а вовсе не стандрт отрасли. А коммуникацию надо вести на понятном слушателям языке, у компетентного бизнес-аналитика, которым я являюсь, это - обязательное условие. Поэтому коммуникация получалась мультиязычной и мультитерминологической: ведь представления слушателей были сформированы в разное время и разными книгами, единая стройная терминология - отсутствует, поэтому как раз изменения смыслов и варианты интерпретаций одних и тех же слов в докладе отдельно отмечались.

В частности, два значения слова requirements: это и описание системы как черного ящика, занимающее определенное место на V-диаграмме между концептом и архитектурой, и вся совокупность артефактов, разрабатываемых при спуске по левой ножке V-диаграммы, от описания возможностей бизнеса и их нужд, до детального дизайна, непосредственно предшествующего коду - именно так трактует requirements OMG Essence.

И спасибо Евгению Пчелякову за отзыв на доклад, фото из которого приведено здесь.

И все остальное

доклад Олег Гарипов рассказывает про дизайн-мышление в IBM. Попробовали применять дизайн-сессии - не пошло, анализ показал, что просто дизайн в их проектах недостаточно, нужно делать функциональный прототип, и уже результат показывать. Прототип, кстати, делают по Scrum. И, как приято в большой компании есть показатели результативности: 30% сокращена фаза исследования, при этом проект по результатам исследования получается сделать быстрее на 60%

доклад Pascale Xelot-Dugat рассказывает про то, как IBM работает со стартапами. И это интересно не только из позиции "заглянуть в опыт большой компании", но и из позиции встраивания в международный рынок стартапов и софта.

Я был не только на этих докладах, но только эти задели настолько, что захотел написать. При этом докладов - много, и в заключении хочу привести ссылку на пост, в котором впечатлениями SECR делится Маусымжан Нурмагамбетова. А вообще - смотрите по тэгам #secrus и #secr

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 02:56, 26 октября 2017 • нет комментариев