Гибкие методологии управления жизненным циклом и управление кейсами для управления работами. ​

Если контрольные точки неизвестны, и ресурсы для их выполнения тоже неизвестны, и планирование ведётся от открывающихся в ходе ведения проекта новых обстоятельств (все разработки именно таковы: вы не знаете, очередная инженерная идея приведёт к успеху, или её после проверки придётся отбросить и придумывать что-то новое), то от самой идеи проектирования как предварительного/up-front детального планирования приходится отказаться.

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

Очередное поколение видов/моделей/концепций жизненного цикла получило название гибких (agile, аджайл, эджайл, более правильный перевод был бы «ловкий» или «изворотливый», но в литературе закрепилось «гибкий») методов разработки (agile development process/agile product development). И вот эта терминология «методов разработки» (которые включали в себя и методы эксплуатации/использования, практики операторов системы) по факту сейчас вытеснила понятия «жизненный цикл» и «управление жизненным циклом», эти понятия остались по факту только в «железной инженерии» больших военных и государственных проектов.

В случае использования термина «agile» речь идёт о варианте метода/методологии (полного набора практик) управления жизненным циклом (но не управления работами!). Эти agile/гибкие методологии считают относящимися к разновидностям спиральной модели. Они подразумевают «операционную гибкость» (отсутствие заранее назначенного астрономического момента выполнения работы, отсутствие up-front planning/предварительного планирования): назначение работы (то есть выделение ресурсов) на практику жизненного цикла может произойти в любой момент проекта. Так, требования (помним, что в момент появления agile требования были --- как раз agile методы разработки и спровоцировали потом отказ от требований) можно подкрутить и ближе к концу проекта --- а потом реализовать эти требования, это ж одно требование реализовать, а не весь проект переделывать! Но и весь проект переделывать в случае agile не такая уж нештатная ситуация, прототипирование (это ведь именно оно, про несколько полных переделок всей системы) тоже отлично укладывается в эту идеологию управления жизненным циклом.

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

Общее для всех этих гибких методологий/методов и соответствующих им видов жизненного цикла в том, что они используют в части управления работами управление кейсами (case management)^[1]. Кейс --- ситуация, обстоятельства или начинание, которые требуют набора действий для получения приемлемого результата или достижения цели. Кейс фокусируется на предмете, над которым производятся действия (например, человек, судебное дело, страховой случай), и ведется постепенно появляющимися обстоятельствами дела.

Управление кейсами по факту обобщает управление проектами и процессами. В кейсе сначала мы имеем вопрос контрольной точки (issue, формулировку кейса, описание ожидаемого в результате выполнения работы состояния предмета кейса как альфы, реализованной какими-то артефактами/рабочими продуктами, но время выполнения этого описания ещё неизвестно, это не контрольная точка, а только вопрос этой контрольной точки --- главным образом известно что должно быть достигнуто, но пока неизвестно, когда).

После этого формулируется работа для прохождения этой контрольной точки. Формулирование задания на работу какого-то ресурса (task) --- отдельная операция, но контрольная точка может быть определена задолго до этой операции, потом отдельно будет назначение ресурса на работы и тем самым разбирательство с планированием и графиком. Тут могут быть использованы удобные для управления кейсами методы планирования, например, канбан (Kanban for development^[2] для управления кейсами прежде всего, для планирования производственных процессов используется обычно Kanban for manufacturing^[3]). И даже тут жизнь контрольной точки в управлении кейсами не заканчивается, потому как в рамках управления изменениями конфигурации нужно сообщить участникам проекта, что кейс закрыт: состояние системы изменилось, и всем остальным нужно ориентироваться на новую ситуацию.

Технологии, используемые для гибких методов в управлении жизненным циклом в части управления кейсами в управлении работами --- это технологии трекинга контрольных точек (issue tracking, часто их называют «системы управления задачами», «системы отслеживания ошибок», «системы отслеживания поручений»). Название отражает тот факт, что контрольные точки появляются не в плановом порядке, они изначально представляют собой вопрос/проблему (issue), требующую своего решения. Трекеры (issue trackers, софт для трекинга контрольных точек^[4]) учитывают эти контрольные точки по мере их появления. Вопросы (если они признаны важными), превращаются потом в назначаемые на выполняемые конкретными ресурсами задачи/tasks (попутно определяются практики, которые помогут решить вопрос, и ресурсы, которые владеют соответствующими оргвозможностями/capabilities выполнять работы для этих практик), а после выполнения задачи они превращаются ещё в уведомления/notices о завершении. Состояние мира изменилось после решения исходной проблемы/вопроса/issue, и нужно уведомить все заинтересованные в этом проектные роли.

Конечно, если появляется возможность что-то спланировать, в управлении кейсами это делается. Часто тут план --- это просто опыт прохождения какого-то кейса в прошлом, который берётся как шаблон для будущих прохождений. Вот эти записи о прошлом опыте (взятые из папки «Дело», куда записывают всё происходящее в кейсе, case file) и будут называться шаблоном (template), если их используют для планирования повторения какой-нибудь удачной последовательности подкейсов. Если шаблоны готовят не специально обученные программисты таких шаблонов, а сами участники команды проекта, то такое управление кейсами называют адаптивным (adaptive), а шаблоны --- шаблонами сообщества (community template).

Мы различаем управление жизненным циклом и виды/модели жизненного цикла (например, водопад, спиральный жизненный цикл, параллельную инженерию, гибкие методы --- способы назначения работ на практики в типовых практиках системной инженерии, т.е. когда «логически» в проекте выполняются работы инженерии требований, инженерии системной архитектуры: только в самом начале проекта или потихоньку в ходе всего проекта) и соответствующие им методы управления работами (например, управление программами и проектами, процессное управление, управление кейсами --- когда работы уже назначены и нужно просто их запланировать и отследить выполнение) и в рамках управления работами методы планирования работ (например, метод критического пути или критической цепи для планирования в управлении проектами, канбан в управлении кейсами). Это всё практики менеджмента как инженерии организации/предприятия/оргзвена/проекта, но все эти практики будут осознаваться как отдельные никак не связанные дисциплины, и не будет чёткого понимания их глубокой связи в предприятиях/проектных группах/оргзвеньях/системах создания/ведения жизненного цикла, если не мыслить о них в рамках системного и методологического мышления.

Вот схематическое изображение жизненного цикла одной из самых распространённых методологий гибкой (agile) работы, SCRUM^[[https://en.wikipedia.org/wiki/Scrum\_(software_development](https://en.wikipedia.org/wiki/Scrum_(software_development){target="_blank"})]:

В этой диаграмме бросается в глаза её нелинейная/неводопадная форма, в которой выделяются наличие циклов ежедневной работы и месячных «спринтов». Нелинейность, отсутствие предписанной чёткой стадийности выполнения практик --- верный признак «принципиальной схемы». Суть диаграммы в том, чтобы показать, как будут меняться альфы в ходе проекта. Ключевые события (моменты контрольных точек, когда альфы будут менять своё состояние) --- «выбор требований» (это довольно старая диаграмма, в 2008 году, когда эта классическая и широко распространённая диаграмма была сделана, требования ещё были), «демонстрация заказчикам» и т.д. Содержание работ при этом затрагивается показанным на диаграмме методом разработки SCRUM, он предписывает какое-то обсуждение практик работы, их дисциплин и технологии. Так что SCRUM оговаривает, какие практики (например, практика проведение планирующих сессий для текущего спринта, практика ежедневных совещаний) нужно будет задействовать, чтобы его альфы (например, альфа product backlog, альфа sprint backlog) меняли свои состояния. А дальше работы конкретных оргзвеньев::ресурсов будут менять артефакты/продукты, реализующие эти альфы.

Гибкие методы --- это не методы управления работами, а методы организации разработки, методы создания и развития систем. Скажем, kanban --- это один из методов управления работой, TameFlow --- это ругающий kanban за его многочисленные недостатки метод управления работой. И TameFlow, и kanban --- они вполне могут быть использованы в сочетании с самыми разными вариантами гибких методов разработки. Об этом подробно будет рассказано в курсе системного менеджмента --- это же операционный менеджмент как одна из практик системного менеджмента. О самих гибких методах разработки и как устроена инженерная работа --- это будет рассказано в курсе системной инженерии.

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

А вот «чтобы всё нормально работало, не ломалось и не ломало всё вокруг, выполняло все функции, о которых на текущий момент договорились» --- это интересует главным образом прикладных инженеров, это другой предмет, обсуждать нужно метод разработки/модель жизненного цикла, а не метод управления работами. Менеджеры и инженеры при этом должны договориться: если у инженеров agile, а у менеджеров up-front planning, то жди беды в проекте. Методы разработки и методы управления работами могут быть несовместимы, и поэтому менеджеры и инженеры обязательно должны договориться. Для этого у них должно быть какое-то знание методологии: они должны понимать природу методов разработки и методов управления работами, чтобы суметь обсудить их совместимость, а также не застревать на своих любимых методах, которые они узнали в предыдущих проектах и дальше могут или повторить --- или покинуть проект, поскольку не в состоянии понять, как адаптировать метод к текущей ситуации.

Конечно, и метод разработки, и метод управления работами --- это тоже альфы, за изменениями их состояний в проекте («не выбрали» --- «есть предложение» --- «договорились» --- «оргвозможность есть» --- «успешно работаем по методу» --- «успешно совершенствуем метод») нужен глаз да глаз, это важнейшие объекты внимания.

Гибкие методы/методологии очень жестки в вопросах соблюдения принципов и правил, и если под словом «гибкие методы» какая-то команда не в состоянии указать конкретный вариант жизненного цикла своего проекта (способа, которым она устраивает изменение состояния альф в ходе проекта, чтобы на выходе получить успешную систему), то верить в успешное завершение проекта этой командой нельзя.

При указании варианта метода разработки или метода управления работами команде не нужно говорить SCRUM, илиDSDM^[5],или OpenKanban^[6],или приводить ещё какие-то названия больших методологий со многими практиками. Вряд ли сегодня какая-то команда использует эти методологии во всей их полноте. Но нужно явно и осознанно сказать, какие команда использует практики создания систем и какие практики управления работами. И надо убедиться, что все члены команды понимают эти практики и им следуют --- это и есть «организовать работу».

Какой выбрать вид/модель/вариант жизненного цикла, какую методологию взять в основу? Мы крайне рекомендуем воздерживаться от даже упоминаний традиционного «водопада», всех этих «стадий» и неизбежных «требований», если у вас проект не похож на простую сборку уже спроектированной системы из стандартных деталей (например, стройка. Если это стройка типового здания --- вперёд, до стадии «отделка» всё будет работать, на стадии «отделка» придётся призадуматься, одни бригады будут красить, другие по свежепокрашенному делать мелкий ремонт --- и никакого «водопада» и up-front плана не будет).

В проектах, где происходит знаниевая работа (проектирование, исследования, моделирование), выбор в качестве модели разработки старинного «водопада» с V-диаграммой будет выбором утопии, вроде как выбора «вечного двигателя» в качестве модели для разработки какого-то двигателя. Ответ на вопрос про то, из каких методологий разработки брать какие практики, зависит от профиля рисков проекта, а этот профиль рисков определяется субъективно командой. Нет двух одинаковых проектов, нет двух одинаковых методов разработки (помним про неудачу инженерии методов и переходу к ситуационной инженерии методов: методы непереносимы из проекта в проект!). В другом проекте, а иногда и при очередном шаге развития в том же проекте все практики могут оказаться другими.

Начали делать концепцию использования, используя user story, потом выяснили, что проект слишком большой --- и перешли на более мощную практику use cases. И заодно поменяли софт с поддержки user story на поддержку use cases. А ещё в середине проекта вдруг решили менять архитектуру системы --- и по обратному манёвру Конвея вдруг поплыла и организация разработчиков. Кроме того, время от времени менеджеры будут настаивать, как в бандитских разборках: «никто тебя за язык не тянул, вот ты сказал свою оценку, а я превращаю её в твоё обязательство» --- отсюда лелеемое менеджерами у инженеров постоянное чувство вины за неминуемые изменения и концепции системы, и архитектуры, и времени прохождения контрольных точек. А ведь ничего стыдного в изменениях в ожиданиях от знаниевой работы нет, это всё гипотезы, часть гипотез обязана просто проваливаться! Кроме того, меняется мир, меняется проект (и design, и project), это нормально.

Просто нужно помнить, что управляющие работами методами проектного управления всегда и во всём видят несуществующий в природе, но удобный для их рассуждений и действий «водопад». Нужно просто работать с исполнителями менеджерских ролей, сильными в управлении кейсами (например, практика/метод TameFlow или даже критикуемая в TameFlow практика/метод Kanban for development), а не в классике проектного управления. Инженерам и менеджерам будет существенно легче договориться!

Даже если вы делаете подряд два похожих проекта, то в результате выполнения первого проекта команда получает опыт, и профиль рисков для команды во втором проекте будет другим. Это означает, что команда может для следующего похожего проекта (или даже в ходе текущего проекта!) подкорректировать практики/способы своей работы, изменить метод разработки целиком, или какие-то практики в текущем методе/процессе/практике разработки, а также изменить практики управления работой для того, чтобы учесть полученный опыт.

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