Agile и CMMI

Подготовка выступления к SQA Days и, особенно, обсуждение на форуме http://software-testing.ru моей статьи, помещенной в качестве анонса к докладу, вызвало пару мыслей про Agile, которыми хочу поделиться. Именно про agile — хотя само выступление про совмещение ролей аналитика и тестировщика, в я активно апеллирую к agile-процессу и это вызвало отдельную ветку обсуждений.

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

Надо сказать, что мысль о принципиальном отсутствии унифицированного процесса звучит не слишком ярко. И, более того, не воспринимается многими как сторонниками так и противниками agile. Сторонники получаются догматическими приверженцами определенных вариантов, а противники — указывают на провалы и вообще на «проблемы с методологией». Потому что многим людям очень хочется, чтобы было некоторое «правильное государство», «правильная методология», «правильный процесс» — такая постановка близка их мышлению.

Мысль вторая. Я тут пересмотрел презентацию Джефа Сазерленда на SECR, и вспомнил вещь, на которую обратил внимание еще на конференции. Для Джефа развитие компании идет так: CMMI 1 → CMMI 5 → CMMI 5+SCRUM. Однако, я знаю много лждей, с точки зрения которых CMMI5 и SCRUM — вещи слабо совместимые. На самом деле, тут вопрос оценки CMMI. CMMI 4 говорит о том, что в компании должна быть настроена оптимизация процессов на основе показателей. А CMMI 5 — что сам процесс оптимизации тоже должен оптимизироваться. Дальше вопрос — что именно мы вкладываем в понятие «оптимизация». Максималисткий подход — рассматривать оптимизацию как поиск оптимума (логично, правда), который еще должен быть достаточно быстрым — чтобы придти близко к оптимуму за то время, пока окружение можно считать квазистатичным.

А можно рассматривать это иначе, понимая под оптимизацией всего лишь процесс, направленный на улучшение чего либо. То есть некоторые регулярные мероприятия, в рамках которого формулируются шаги по улучшению некоторого процесса, которые потом воплощаются. И достаточно, если шаги будут в среднем правильными. И если оценивать так, то CMMI 4 в SCRUM есть — это ретроспектива. На которой, в числе прочего, следует обсуждать показатели работы команды — burndown (и другие показатели), придумывая меры по их исправлению, которые затем будут воплощены. А чтобы получился CMMI 5 — нужно еще ретро по ретре, и процесс обмена всем этим опытом в рамках компании (процесс обмена и для CMMI 4 нужен).

Естественно, так происходит не в любом SCRUM, нужно как минимум желание и усилия в этом направлении. И, надо сказать, что слушая истории о конкретных командах от Джефа (и от Хенрика Книберга тоже) — вполне допускаешь, что в конкретных компаниях, в них фигурирующих, SCRUM действительно означает CMMI 5.

14 комментариев "Agile и CMMI"

cmmi_ru:

29.11.2011 в 11:55

«Есть много более интересного, а на все времени не хватит.» — с этим не поспоришь. 🙂

Но всегда буду рад любой возможности очной встречи где-либо: курс, конференция и т.п. Хотя на конференциях я бываю редко, но бываю.
SALar:

29.11.2011 в 11:27

Дествительно изменяет ;-). Забыл, забыл, что «Organizational Process Definition» это третий уровень.

> курс http://www.peoplemind.ru/?page=software-executive&sub=catalog&ouid=337329&course=337330

Не, это без меня. Есть много более интересного, а на все времени не хватит.
cmmi_ru:

25.11.2011 в 15:46

«Меняются названия (второй уровень сменил), » — от рождения CMMI и до сих пор не менялось (Ваши аргументы против этого утверждения?)

«Если хотим спорить предметно, то может и придется.» — хм-м-м… еще и пересказывать содержание трехдневного курса… ну хорошо, хотя бы кратко… Процессы третьего уровня (и, собственно, сам уровень) называется defined. Далее см. глоссарий:

defined process — A managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes process related experiences to the organizational process assets. (See also “managed process.”)

standard process — An operational definition of the basic process that guides the establishment of a common process in an organization.
A standard process describes the fundamental process elements that are expected to be incorporated into any defined process. It also describes relationships (e.g., ordering, interfaces) among these process elements. (See also ―defined process.‖)

Еще надо что-то добавлять относительно третьего уровня?

«Никакое высокое звание не может служить абсолютным подверждением того, что оратор говорит истину». — конечно, претендовать на истину глупо, но быть к ней близко — почему бы и нет, если:
а) на всю СНГ являешься единственным сертифицированным специалистом в части CMMI, сертифицированным институтом SEI — который единственный и «правит» всем, что касается CMMI;
b) когда знания проверяются этим самым институтом;
c) когда результаты деятельности (те же оценивани, называемые в народе «сертификацией) проверяются институтом SEI в обязательном порядке и претензий вроде как не было;
d) когда работы выполнялись не только в СНГ, но и в Европе (точнее — в Испании) неоднократно и там ни у кого не возникало сомнений в том, что сертифицированный специалист имеет право быть гораздо «ближе к истине», чем «остальные»;
e) наконец, когда являлся со-рецензентом предрелизного варианта (пусть из команды в порядка сотни специалистов, но все они индивидуально одобрены были SEI) одной из моделей CMMI-SVC (for Services);
f) и т.д.

Я к тому, что да, естественно, некоторые ошибки в моих суждениях могут быть, но они могут касаться некоторых деталей, но никак ни концепций модели. Моя рекомендация — тут дискуссию «притормозить», а лучше найти способ для «оффлайновых» обсуждений. Кстати, один из более-менее доступных вариантов — курс http://www.peoplemind.ru/?page=software-executive&sub=catalog&ouid=337329&course=337330. Пусть это авторский (а не SEI) курс, но все-таки. Готов поговорить с коллегами-партнерами (а организуют его они, я, в рамках своего бизнеса, открытыми мероприятиями не занимаюсь) относительно персональной скидки для Вас за мой счет. 🙂
SALar:

25.11.2011 в 15:17

Курс от компании «Крес-консалтинг». Проходил довольно давно, лет пять или шесть назад. Поскольку информацией оттуда пользовался не слишком активно, то часть мог забыть. И часть понять неправильно. Кроме всего прочего CMMx-xx еще и эволюционируют, а следить за всем нет времени. Меняются названия (второй уровень сменил), меняются области усовершенствокания и т.д.

> Реально надо копипастить часть глоссария модели

Если хотим спорить предметно, то может и придется.

> И уж тем более интересно — оказывается я, как сертифицрованный оценщик и инструктор, все неправильно (или неаргументированно) все понимал?

Понятия не имею. Возможно мы говорим примерно одинаковые слова, но понимаем под этим разные вещи.

Терминологическая путаница это очень неприятная вещь. Я например, регулярно вижу «консультанов от Agile» (и даже сертифицированных), которые почему то вместо Agile рассказывают об очередной процессной методологии, имеющей очень слабое отношение к Agile манифесту. И что мне с их сертификатов? Рынок просит рассказать про процессы, они и рассказывают про процессы, а не про Agile. Но мне от этого не легче. А после того как Аристотель сказал, что «Более тяжелые предметы падают быстрее» все прогрессивное человечество верило в это порядка 2000 лет.

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

==============================

Я имел ввиду, что внедрение SCRUM в первую очередь относится к «описанию стандартного процесса» и «созданию инструкции по подгонке». ЕМНИЛ (Если Мне Не Изменяет Память) это второй уровень.

Можно конечно сказать что внедрение SCRUM затрагивает:
- Requirements Management
- Project Planning
- Project Monitoring and Control
- Measurement and Analysis
- Process and Product Quality Assurance
но я не буру так широко. Почему? Да потому что в противном случае можно сказать «что в любой капле отражается весь мир».
cmmi_ru:

24.11.2011 в 13:57

А что за курс, на котором обучались? Официальный? И после него такие вопросы?
(С ужасом) — неужели я так обучил?!

По поводу аргументов? Реально надо копипастить часть глоссария модели? И уж тем более интересно — оказывается я, как сертифицрованный оценщик и инструктор, все неправильно (или неаргументированно) все понимал?
SALar:

24.11.2011 в 13:24

Именно. Обучался на курсе. И модель читал. И книжка дома лежит.

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

> Это наличие организационных процессов, которые могут быть адаптированы проектами в соответствии с установленными правилами и критериями. Главная идея такого подхода в том, что в организационных процессах есть некое «ядро», которое должно присутствовать в процессах каждого проекта.

Область усовершенствований? Название практики?
cmmi_ru:

24.11.2011 в 10:25

Действительно, на втором уровне процессы есть (например, основанные на scrum), но они могут быть специфичны для каждого проекта. Но они, не смотря на разнообразие, все-таки увязаны немного между собой через т.н. «организационную политику». В этой политике указывается (в контексте каждогов вида деятельности или нескольких видов) — что, все-таки, ожидается в проектах и зачем вообще это все надо. Для «агильных» проектов, такая политика может «отталкиваться» от того же agile manifesto. Но нельзя забывать, что политика — это только один из почти десятка признаков процесса второго уровня. 🙂
Третий уровень — да. Это наличие организационных процессов, которые могут быть адаптированы проектами в соответствии с установленными правилами и критериями. Главная идея такого подхода в том, что в организационных процессах есть некое «ядро», которое должно присутствовать в процессах каждого проекта. Этим обеспечивается «консистентность» процессов между собой независимо от проекта. Что, в свою очередь, должно повышать управляемость и проектов, и процессов. Если это «ядро» достаточно декларативное, а что ни проект, то свой вариант использования (построения) процесса, то это — возврат на второй уровень.

Примерно так в очень кратком изложении.
maksiq:

23.11.2011 в 21:11

Насколько я понимаю, тут вопрос о сфере применения. Если scrum внедрен в рамках всей компании, и обеспечивается наблюдение за единообразием, а процесс вариаций и обмена опытом узаконен, то будет третий уровень. А если каждой команде предоставлено право самоорганизовываясь править scrum как она хочет, то будет только второй.
cmmi_ru:

23.11.2011 в 16:32

«Именно на втором появляется описание стандартных процессов/проектов и «инструкция по подгонке».»

Ну просто новое слово в концепциях уровней CMMI. 🙂 Берем модель и изучаем внимательно. Или обучаемся, лучше на официальном курсе. 🙂
SALar:

23.11.2011 в 11:46

> В то же время, применение этого метода (Scrum) в его «базовом» варианте соответствует концепции не более, чем 3-го уровня.

Второму, господа, второму. Именно на втором появляется описание стандартных процессов/проектов и «инструкция по подгонке».
cmmi_ru:

21.11.2011 в 12:31

Пробую еще раз…
Итак, burndown — это не иснтрумент 4-го уровня. Не подлежит сомнению экспертиза Джефа в части Scrum, но вот в части CMMI (я имею в виду практическую сторону)… Плюс и времени у него на презентацию не было достаточно, что могло сбить слушателей с толку.
Основная задача 4-го уровня — управление процессом (или процессами), используемыми при выполнении проекта (или работ) при помощи количественных и статистических методов, позволяющих выявить проблемы в процессах или внешнее воздействие на эти процессы. Устраняя эти проблемы, можно добиться предсказуемости и стабильности процессов. А уж это позволит использовать методы прогнозирования (и моделирования), которые базируются на вполне определенных статистических методах. Earned Value Management — прекрасный инструмент для сокрытия проблем (в этом контексте), который не учитывает, например, вариации показателей. Если посмотреть публикацию того же Джефа на тему Scrum’а в компании пятого уровня, то там есть публикация, показывающая применявшийся «инструмент» для такого управления и это отнюдь не burndown!
Да, CMMI и Scrum прекрасно сосуществуют вместе, как верхнеуровневое руководство и прикладной метод, который учитывает рекомендации этого самого руководства. В то же время, применение этого метода (Scrum) в его «базовом» варианте соответствует концепции не более, чем 3-го уровня. Требуется немного больше того, что заложено изначально (в т.ч. и у мение работать — не всех, но тех, кто работает с данными — с методами вероятностной статистики, например) в метод.
cmmi_ru:

21.11.2011 в 12:22

Хм—м-м… написал длинный окмментарий по поводу неправильности трактовки burndown, как инструмента 4-го уровня, а он не опубликовался. :((
maksiq:

22.11.2011 в 11:25

Джеф действительно не рассказывал детально, как обеспечивается в рамках SCRUM выполнение требований CMMI. И я согласен, что SCRUM, особенно в том виде в котором он практически реализуется во многих компаниях не обеспечивает управление процессом на основе количественных показателей. Но сами показатели там присутствуют, и это — важно. Потому что управление на основе показателей часто упирается просто в отсутствие этих показателей, отсутствие практики их ведения. И показателей реально много — хотя внутри спринта они отображаются как burndown, особенно при использовании системы ведения дел и автоматического порождения burndown, что очень распространено. Так что надо поставить процесс анализа имеющихся показателей и принятия решений на их основе, что проще. Более того, имеется регулярное мероприятие — ретроспектива — куда это встроить. Но я полностью согласен, что имеющаяся возможность — всего лишь возможность, а над ее использованием надо будет отдельно работать, scrum «по умолчанию» это не делает.
cmmi_ru:

22.11.2011 в 11:52

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

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.