February 4th, 2013

2019

Основы: контрольные вопросы по состоянию проекта

Контрольные вопросы по состоянию проекта разработки программной системы (чеклисты из Essence) определены в стандарте Основ (OMG Essence -- сущности и язык для методов программной инженерии, http://ailev.livejournal.com/1051048.html), но использоваться должны по правилам из книжки Cheklists Manifesto (http://ailev.livejournal.com/1029295.html).

Я постарался перевести эти контрольные вопросы для сущностных альф Основ на русский, заодно собрав их в табличку:
Collapse )
Успешного вопрошания!
2019

Как пользоваться контрольными вопросами к состоянию проекта

Основы (OMG Essence) предполагают активное использование контрольных вопросов для определения текущего и желаемого состояний проекта. Для этого стандарт предлагает список самых основных, минимальных вопросов в виде их списков (чеклистов) -- я предложил перевод этих списков в http://ailev.livejournal.com/1059781.html.

Обоснование такого подхода хорошо изложено в книжке Checklist Manifesto (http://ailev.livejournal.com/1029295.html). То есть, как минимум:
-- читаются чеклисты вслух в присутствии всей команды (команда должна согласиться с зачитанным) в специальных проверочных паузах (checkpause). Фишка в том, что ежели кто-то из участников проекта понимает, что есть проблема, то зачитывание вслух и подтверждение ответа всеми -- именно тот момент, когда все члены команды могут о проблеме узнать (т.е. все считают, что какой-то контрольный вопрос пройден, но у кого-то может быть знание, что это не так -- и он спасёт ситуацию, не даст наступить на затаившиеся грабли).
-- срабатывает чеклист (там, где ожидалось единогласное "да", вдруг оказывается "нет") только один раз из десяти, но этот один раз обычно является критическим для успеха проектах. Ибо люди очень умны, но забывчивы, и регулярно полагаются на "авось" (или на то, что работу сделал кто-то другой). Основы предполагают, что достижение состояний со всеми отвеченными утвердительно контрольными вопросами обеспечивается тяжёлой работой, их достижение необходимо, и отрицательные ответы означают, что работы было недостаточно. Незаданный вопрос (или нечестный ответ на вопрос) -- это классические грабли, на которые наступают по самым разным причинам, хотя об их существовании прожужжали все уши, всем они известны, но... хотят как лучше, получается, как всегда. Чеклисты Основ -- именно об этом, о возвращении к основам, о проверке тривиального.

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

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

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

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

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

Выступление на Ontology Summit 2013

Мой доклад на сессии Ontology Summit 2013 будет 7 февраля 2013 (четверг), в 21:30 MSK -- http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2013_02_07 (на этой странице подробные инструкции, как подключиться всем желающим -- эти сессии проходят голосом по скайпу, плюс веб-чат, плюс сервер показа слайдов).

Докладчики в этой сессии, конечно, ой: кроме меня там Barry Smith, Chris Partridge и Mike Bennett. И темы их докладов тоже весьма прелюбопытные.

Меня попросили там презентовать работу более чем годичной давности: нашу методологию инженерии справочных данных ISO 15926 (http://techinvestlab.ru/files/RefDataEngenEnglish/RefDataEngen_ver_3_English.doc).

Слайды доклада тут: http://www.slideshare.net/ailev/ontology-methodology-jan13.
Abstract: The "ISO 15926 Reference Data Engineering Methodology" describes the engineering of ontologies for systems federation purposes. "Situational Method Engineering" is a discipline for the description of development methodologies. This presentation will describe the practical experience of applying the Situational Method Engineering discipline to the creation of an ontology development methodology for the growing community of ISO 15926 reference data engineers.