жизненного цикла. С карточками альф может проводиться множество самых разных игр:

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

●Планирование работы: слева выкладываются карточки, которые уже пройдены, а справа — ещё не пройденные карточки. Выясняются проблемы, которые не дают возможность “чекнуть” следующую карточку, и эти проблемы (или сразу по обсуждении — задачи, следующие из этих проблем) документируются в форме дел (issues) в системе ведения дел.

●Больше игр см. тут: http://www.ivarjacobson.com/alphastatecards/

Работа с карточками связана с обнаружением проблем и планированием задач для их решения. Для учёта проблем, переходящих в задачи, а после их решения становящихся уведомлениями о решении проблем, используются специальные системы отслеживания дел — issue trackers. Когда-то такие системы появились для учёта обнаруживающихся в проекте ошибок (bugs), но довольно скоро они были обобщены до отслеживания “вопросов” (issues, мы будем переводить их как “дела”). Эти системы ведения дел обычно тесно связаны с системами поддержки версионности (управления конфигурацией).

Каждый раз, когда обнаруживаются проблемы, мешающие честно сказать “да” для ответа на вопросы карточек, эти проблемы заносятся в issue tracker и далее отслеживается решение этих проблем (”закрытие дел”).

Контрольные вопросы инженерного проекта

Карточки основных альф инженерного проекта

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

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

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

В большинстве случаев вместо длинной фразы “метод описания, принятый в выбранной для проекта практике XXX” приведена более короткая (хотя и менее точная фраза) “практика XXX”. Для различных опросов фраза “методика опросов и формат отображения результата” в таблицах не прописана.

Ну, и нужно понимать, что карточки альф инженерного проекта даны в их самом универсальном виде — но в зависимости от паттерна жизненного цикла

(http://csse.usc.edu/csse/TECHRPTS/2009/usc-csse-2009-502/usc-csse-2009-502.pdf —

“купи готовое” … “акцент на сервисах”) и жёсткости регулирования (например, военные разработки, или разработки атомной энергетики, или даже разработки в строительстве с его лицензированием и детальными нормативными документами отличаются детальной прописанностью многих рабочих процедур), так что без адаптации их к условиям конкретного проекта использовать их может оказаться затруднительно.

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

Так что в нижеприведённых таблицах обращайте прежде всего внимание на суть задаваемых вопросов, а примеры рабочих продуктов и практик их описания даны только для того, чтобы проиллюстрировать использование практики контрольных вопросов для “тяжёлых” разработок в больших инженерных предприятиях и сильно зарегулированных отраслях. Не забывайте, что нынешний тренд — это уменьшение “бюрократии”, но без ущерба для дела. Поэтому контрольные вопросы будут оставаться, но вот письменные развёрнутые доказательства со специализированными рабочими продуктами и хитрыми методиками их разработки в ответ на каждый вопрос — вряд ли, ибо цель вопросов не “отчитаться за проделанную работу”, а просто обратить внимание команды на текущее положение дел, не дать забыть какую-нибудь банальность типа известности источника финансирования или наличия механизма управления конфигурацией. Трудно поверить, но в пылу авралов забывается и такое: карточки с контрольными вопросами помогают не упустить леса за деревьями.

Стейкхолдеры

Основные практики работы со стейкхолдерами — это обеспечение того, чтобы представители групп стейкхолдеров/исполнители ролей стейкхолдеров активно участвовали в разработке, т.е. практики лидерства и коллаборации.

Стейкхолдеров обычно много (для удобного их группирования часто используют луковичную диаграмму — http://businessanalystlearnings.com/ba- techniques/2013/1/22/how-to-draw-a-stakeholder-onion-diagram), и все они обычно находятся в разном состоянии в какой-то момент времени. Поэтому хорошей практикой является определение подальфы “стейкхолдер”, и далее работа с отдельными экземплярами этой альфы (понимая, что продвижение по состояниям

Системноинженерное мышление TechInvestLab, 2 апреля 2015 219

каждого из стейкхолдеров ведёт/drive к продвижению по состояниям всей альфы “стейкхолдеры”).

Помним также, что “подрядчик” и “член команды” — это тоже подальфы “стейкхолдеров”.

Признаны

Стейкхолдеры были определены.

Представлены

Механизмы вовлечения стейкхолдеров согласованы и назначены представители стейкхолдеров

Удовлетворены для разворачивания

Минимальные ожидания представителей стейкхолдеров были достигнуты.