Модель Кеневин (Cynefin Framework)

Модель Кеневин (Cynefin Framework)

Модель Кеневин (Cynefin Framework)

На протяжении десятилетий мы думали, что до написания кода разработчиками, можно получить достоверные или почти достоверные условия к поставленной задаче. Аналитики освобождали нас от ответственности за конечный результат, тщательно проверяя и перепроверяя требования к продукту, чтобы убедиться, что ничего не было пропущено для достижения необходимых бизнес целей. Теперь, с появлением Agile методов и стратегии Lean Start-up (стратегия запуска стартап кампаний, автор Eric Ries), мы осознаем необходимость обратной связи.

Тем не менее команды по-прежнему борются с человеческим качеством: врожденная неприязнь, которую мы все испытываем к неопределенности. Методы, такие как Acceptance Test Driven Development (ATDD) и Behaviour-Driven Development (BDD), помогают нам придумать четкие критерии успешности, заменяя потребность в больших объемах документации, при этом создает иллюзию того, что принятые на старте критерии и условия не будут изменены после того, как мы начнем писать код. Тем не менее мы все еще сталкиваемся с ситуациями, когда исходные условия, требования или потребности меняются в процессе производства. Это может произойти как из-за полученных отзывов от пользователей и внешних заинтересованных сторон, так и от внутренней обратной связи.
В результате мы пытаемся все проанализировать, а затем будем получать обратную связь, пока весь наш процесс не увязнет и не забуксует. Поэтому это настоящее чудо, когда мы успеваем что-то изготовить и закончить с новыми правками посередине производственного пути!

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

Простые

Это те задачи, с которой может справиться любой человек, даже ребенок. Компания Дейва Сноудена, Cognitive Edge, использует пример срыва велосипедной цепи. Легко понять, как вернуть цепь на место.
Такие задачи легко классифицируются и на них просто отвечать, анализ здесь не требуется. Это напоминает: «О, так это одна из этих проблем». На такие задачи существуют так называемая Best Practice, т.е. лучшее решение и если эту лучшую практику не применить, то любое другое решение будет заведомо менее эффективным. Другими словами, в мире уже придумали как решать такие задачи, не надо изобретать велосипед заново.
Некоторые из энтузиастов Lean Start-up стратегии рассматривали комплексные интеллектуальные модели и применяли их к разработке программного обеспечения. В частности, интеллектуальная модель Cynefin дала нам новый способ понять наши проблемы и требования, которые исходят от них самих. Другими словами, однажды поняв эту модель, процессы становятся очевидными! Сначала я объясню структуру, а затем покажу, как она относится к процессу разработки программного обеспечения, и как мы можем сделать нашу практику более эффективной.

Cynefin – понимание сложности задач

Модель Кеневин был разработан Дейвом Сноуденом и некоторыми его коллегами для описания различных проблем. Он вводит четыре области – простые, сложные, запутанные, хаотичные и пятый домен в центре, беспорядок, когда неясно, с какими проблемами мы сталкиваемся. Внимательно посмотрев на картинку, можно увидеть небольшую складку на границе между «очевидным» доменом и «хаотическим». Это сделано специально, чтобы показать, насколько легко очевидные решения могут вызвать ложное спокойствие и опрокинуть всю систему в хаос.

дачи в программировании это написание скрипта передвижения черепахи на экране компьютера: две единицы вперед, повернуть направо на 90 °, пройти еще два блока вперед, пока вы не доберетeсь до цели.

Сложные

Сложные проблемы имеют предсказуемые решения, но требуют экспертизы для понимания. Часы сложны. Автомобили сложны. Понятно для чего они нужны и что от них ожидать, но неподготовленный человек без экспертизы не сможет решить проблему связанную с этими сложными вещами.
Сложные задачи требуют анализа и следующего из анализа первого шага в решении. Вы говорите: «Позвольте мне взглянуть на эту проблему и я расскажу вам, как ее решить, потому что имею опыт в этой сфере». Проблемы в этой области обычно имеют более одного способа решения и такие методы иначе называют Good Practice.
Большинство нашего программного обеспечения очень сложно для понимания. Например, форма CRUD (акроним, обозначающий четыре базовые функции, используемые при работе с хранилищами данных – прим. автора перевода) хорошо понятна экспертными группами разработчиков. На самом деле, для большинства разработчиков это настолько неинтересно, что они создадут инструменты для работы над ними (например, фреймворк Ruby on Rails), превращая повторяющиеся сложные проблемы в более мелкие.

Запутанные

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

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

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

Задачи из этого домена повлияли на Agile манифест. Мы не могли все понять правильно, поэтому вместо этого мы начали создавать схемы обратной связи в нашем процессе. Хорошим примером являются веб-технологии. Я просто выбросил старую книгу на Javascript, которая посвятила всего две страницы новой вещи под названием «Ajax». Кто в результате мог предвидеть рост современных веб-приложений?

Хаотические

Хаос – это когда ваш дом горит. Хаос – это авария и чрезвычайная ситуация. В хаосе вы действуете, думаете и потом только пытаетесь решить, причем сначала ДЕЙСТВУЕТЕ – это самое важное. Вы спасаетесь из дома. Вы останавливаете кровотечение. Вы делаете что-то, чтобы лучше контролировать ситуацию.
Рон Джеффрис спросил: «Будучи в хаосе, мудро ли предпринимать действия опасного характера?»

Истина заключается в том, что если наш дом сгорит, и мы не выясним причину возгорания, ситуация разрешится сама по себе (дом сгорит и без нас), но пока мы будем думать над причиной возгорания, мы можем сгореть вместе с домом! В таком решении нет ничего безопасного!

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

В программном обеспечении хаос – это баг, который вы упустили на стадии продакшена и привел к падению вашего сайта в день релиза. Такие ситуации заставляют вас всё бросить и действовать, в данном случае восстановить работу сайта.
Однажды я “уронил” сайт путешествия Guardian, потому что данные, которые использовались при стейджинге, отличались от данных на продакшене настолько незаметно, что никто не обратил на это внимание. В итоге вся команда побросала свои дела, чтобы решить “поднять” сайт. Мы быстро нашли ошибку, и я уверен, что прибывал в панике больше, чем кто-либо другой. Теперь я определенно не хочу снова программировать в режиме “ахтунг”!

Если вы это делали раньше, требования известны

Дэвид Андерсон, автор книги «Канбан», работал в индустрии мобильных телефонов. Он говорит о различии между дифференциаторами (аналоговый функциональный блок в АВМ – прим. автора перевода) и ширпотребом; вещи, которые вам нужны для большой игры. В качестве примера подумайте, как бы вы вошли на рынок мобильных телефонов. Ваш телефон должен будет иметь возможность совершать и принимать звонки и тексты, сохранять контакты и т. д.
Теперь, если я попрошу вас определить, как выглядит операция «сделать звонок», это будет не сложно. Вы можете легко дать мне сценарий, в котором вы звоните кому-либо. Требования ясны и понятно что нужно делать, чтобы решить эту задачу.
Если можно легко вывести сценарии решения из краткого описания условий задачи, то достаточно краткой инструкции! Нам не нужно подробно останавливаться на том, как именно работают наши решения. Возможно, у нас будет несколько итераций, чтобы проверить, нет ли исключительного аспекта проблемы. Обычно я спрашиваю: «Есть что-то, что работает не так как должно?» И этого достаточно.

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

Если задачу решил кто-то до вас, то решение можно изучить
Дэвид Андерсон рассказывая про дифференциаторы и ширпотреб товарах – хотел донести мысль, что-то, что мы хотим сделать, уже кем то сделано. Например, Kyocera выпустила первый камерофон. Когда они это сделали, это был отличительный знак, затем Nokia испортил его. В наше время это настолько распространено, что это в значительной степени товар широкого потребления.

По мере того как бизнес-домены и проблемы внутри них становятся понятнее, мы переходим от запутанных задач к сложным. Существует предсказуемое решение; для этого требуется немного усилий.

В этой сфере разговоры о проблеме могут помочь обеспечить понимание области, а также выявить дифференцирующие проблемы. Крис Маттс, аналитик, который помог на ранних этапах становления BDD, получил предупреждение. «Не надо ходить к своему эксперту и спрашивать:« Что лучше, вот это или это? »- говорит он. «Найдите другой способ получить эту информацию и сохраните разговоры с экспертами для действительно интересных вещей».

Как только домен будет лучше понят, автоматизация сценариев – с помощью Cucumber например, чтобы связать с написанием кода, – может помочь предоставить документацию для всех, кто будет решать такую задачу после вас. Здесь можно найти баланс между автоматизацией до написания кода и последующим автоматизацией. Если вы слишком часто меняете автоматические сценарии, подождите, пока вы лучше вникнете в проблему. Если вы обнаружите, что вам не придется беспокоиться об изменении процесса решения задачи в будущем, то вы поняли проблематику достаточно хорошо. По мере того, как ваше понимание области возрастает, вы, надеюсь, придете к готовому сценарию написания кода для решения этой задачи, прежде чем перепишите код много раз.
Если задача до вас ни кем не была решена, условия будут меняться
Код, написанный как BDD, так и TDD, основан на четком понимании результата и способах его достижения – когда требования известны или их можно узнать (вам, возможно, придется искать лучшего эксперта в своей области).

Поиск четких результатов хорошо работает в сложных задачах и простых задачах – в том, что причина и следствие сильно коррелированы и предсказуемы, но если бы можно было проанализировать все задачи наперед, то наверняка бы знали, что сработало бы, а что нет.
Когда у вас есть обсуждения вокруг сценариев, иногда бизнес не будет уверен в желаемых результатах. Они могут знать о результатах более высокого уровня – например, набирают больше клиентов или больше доходов от рекламы, но они могут не знать, действительно ли функция, которую они предлагают, будет работать.
Многие энтузиасты Agile рекомендуют иметь четкие критерии приема до того, как история будет принята в беклог. Тем не менее, Extreme Programming имеет одну практику, называемую всплеском, иначе известную как «попробовать что-нибудь и научиться». Прототипирование в документе или коде аналогично этому приему.
Если вы находите себя в пространстве с высокой степенью неопределенности, вместо того, чтобы пытаться устранить неопределенность при анализе, лучше попробовать что-то, что не приведет к потерям и потерпеть неудачу, после чего уже проводить анализ случившегося и на основе его делать выводы (иначе, по-русски говоря “Метод научного тыка” прим. автора перевода). Чем больше коллаборация между бизнесом и ИТ, тем чаще бизнес будет готов опробовать рискованные вещи, особенно если речь идет о компаниях, которые внедряет инновации!

Обсуждайте только сложные и запутанные задачи

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

Учитывайте контекст, Когда происходит событие, Чтобы понять какие последствия могут произойти.

Я вызываю первый контекстный опрос:
Есть ли другой контекст, в котором это событие приведет к другому результату?

И второй вопрос:
Возможен ли еще какой-то другой результат, кроме ожидаемого?

Например, если мы разрабатываем банкомат, эти два вопроса напомнят нам о том, что некоторые клиенты имеют овердрафты, и нам нужно дебетовать счет, а также давать деньги клиентам. Однако, наиболее интересные ответы – это когда заинтересованные стороны бизнеса отвечают: «О, я не уверен! Я не думал об этом ». В этот момент мы можем перестать пытаться провести анализ – мы только что обнаружили неопределенность; мы находимся в запутанном домене, и мы можем сосредоточиться на получении обратной связи, а не на том, чтобы бизнес дал более понятные для нас условия задачи.Если во время обсуждения задачи людям скучно, вероятно, проблема простая или находиться на грани перед сложной и обсуждать здесь особо нечего – уже есть Best Practice по решению данной проблемы.

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

Автор оригинала: Лиз Кеох – независимый консультант Lean и Agile, базирующийся в Лондоне. Она является известным блоггером и международным оратором, основным членом сообщества BDD и участником ряда проектов с открытым исходным кодом, включая JBehave.

Оригинал статьи на английском

Отставить отзыв

Ваш e-mail не будет опубликован. Обязательные поля помечены *