Незрілість СММ (The Immaturity of CMM)

Відомо, що SEI (Software Engineering Institute in Carnegie Mellon University) заснований Міністерством Оборони США, щоб управлятися з десятками мільйонів доларів щорічно. Мешканці SEI – знавці офіційних військових процесів, і мають ресурси для оповіщення світу про свою діяльність. Ще відомо, що CMM (Capability Maturity Model) – це широкий і глибший набір тверджень, що складають хорошу практику розробки ПЗ. Резонно запитати, звідки ці твердження прийшли і чи дійсно вони повні і коректні.


Моя теза полягає в тому, що CMM є приватною міфологією процесу еволюції програмного забезпечення (ПЗ), і не може легітимно претендувати на природну або істотне подання програмного процесу.


CMM – це в кращому випадку згода серед окремої групи теоретиків і практиків програмування, що зібрали колекцію ефективних практик, які згруповані у відповідності з простою моделлю еволюції організації. Все це потенційно значимо для тих компаній, які повністю втратили здоровий глузд, або для тих, які мають його з надлишком і таким чином можуть уникати подібних підступів.


У гіршому випадку CMM – це відбілювач, який затемнює справжню динаміку інженерії ПО, пригнічуючи альтернативні моделі. Якщо організація слід CMM через урядові контрактів, то це може легко привести її до колапсу потенціалу конкурентоспроможності компанії. Саме з цієї причини CMM не популярна серед високо конкурентних та інноваційних компаній, що виробляють комерційне (коробкове) ПО.


Короткий опис CMM
CMM була задумана Watts-му Humphrey, який відштовхувався від більш ранньої роботи Phil-а Crosby. Активний розвиток моделі почалося SEI з 1986 року.


CMM складається з групи ключових практик – "key practices" – ні нових, ні унікальних, розділених на 5 рівнів, які організація повинна пройти, щоб стати "зрілої". SEI визначив строгий порядок атестації процесів для визначення того, наскільки добре організація задовольняє цілям кожного рівня. Атестацію повинен проводити авторизований провідний атестатором.


Рівні зрілості такі:



Компанія спочатку повинна атестувати свій поточний рівень зрілості, а потім досягати наступного рівня за спеціальним планом. Пропуск рівнів не допускається.


Спочатку CMM призначалася для використання, як інструмент розвитку спроможності урядових підрядників виконувати контрактні проекти з розробки ПЗ. М.б. вона і годиться для цієї мети. Але, по-моєму, вона також нав'язується як загальна модель поліпшення процесу розробки ПЗ. А в цій якості CMM має серйозні слабкості.


Комерційні компанії – Borland, Claris, Apple, Symantec, MS, Lotus … – дуже рідко (або ніколи) працюють з необхідними документами так формально, як це описано в CMM. Це вимога досягнення рівня 2, і значить, всі ці компанії повинні впасти до рівня 1 моделі …


Критика CMM
Тут не буде повною критики CMM, але ось два заслуговують на увагу критика: Capers Jones & Gerald Weinberg.


У книзі Assessment & Control of Software Risks Jones пропонує свою модель – SPR (Software Productivity Research), – яка була розроблена незалежно від CMM і приблизно в той же час. Jones присвятив главу критиці CMM. SPR враховує багато факторів, які CMM ігнорує. Наприклад, таким, як внесок в продуктивність індивідуальних інженерів.


У двотомній монографії Quality Software Management Weinberg описав сильну концепцію зрілості, застосовну до процесів створення ПЗ і засновану на парадигмі шаблонів поведінки. Ці моделі Weinberg-а засновані на взаємодії між людьми, а не між формальними конструкціями. Його підхід заснований на еволюції "керівництва за рішенням проблем", а не на консервативних процесах.


Головні проблеми, пов'язані з CMM
Далі перераховані не всі, але найбільші проблеми CMM з точки зору фахівця з процесів у світі коробочного ПЗ:



На глиняних ногах: Фундаментальне нерозуміння CMM організацій рівня 1



Світ технологій процвітає найкраще тоді, коли індивідуальності залишаються різними, творчими і непокірними – Don Valentine, Silicon Valley Venture Capitalist


Крім занепокоєнь, висловлених раніше, найбільш потужним аргументом проти CMM, як ефективного приписи для процесів створення ПЗ, є існування багатьох успішних компаній, які за CMM взагалі не повинні існувати. Це особливо ясно, якщо поглянути на зади (театральний задник) Силіконової Долини. Tom Peter "s Thriving on Chaos зараховують до маніфесту Силіконової Долини. Він поміщає інновації, діючі нелінійно і революційно, в центр свого бачення цього світу. У Долині інновації мають найвищий пріоритет. І ця вигідна позиція новатора є якраз тим, що CMM загубила найбільшою ступеня. Особистий досвід в Apple і Borland, і контакти з багатьма іншими тут тільки підтвердили цей висновок.


Прихильники CMM часто помиляються, вважаючи, що їх критики виступають проти процесів (і деякі з нас так і роблять). Але багато хто, включаючи мене, відносяться до процесним фахівцям. Ми віримо в ті різновиди процесів, які підтримують інновації. Ми робимо наголос на систематичне лідерство у вирішенні проблем для досягнення інновацій, замість того, щоб займатися управлінням процесу для вирішення проблем при нарізуванні печива.


По суті, в CMM взагалі немає інновацій, а з'являються вони тільки на рівні 5. Це шокує, тому що багато інноваційні фірми в комп'ютерній індустрії працюють на рівні 1 у відповідність з моделлю. Наприклад, General Magic – піонер в персональній цифрової технології комунікацій. Сюди ж можна віднести і Microsoft і, звичайно, Borland. У термінології CMM немає різниці між цими фірмами та компаніями, що звалилися на старті, або сталеливарними компаніями. На противагу цьому такі компанії, як IBM, яка за всіма підрахунками створила справжню плутанину в Federal Aviation Administration "s Advanced Automation Project, стоїть високо в термінах зрілості (за словами члена урядової команди аудиту).


Сьогодні SEI, стверджує, що інновації знаходяться поза їх сфери, і що CMM просто встановлює каркас, усередині якого інновації можуть виявлятися більш вільно. Відповідно до літературою з інновацій, однак, нічого не може бути понад істини. Стурбована передбачуваністю, CMM серйозно ігнорує динаміки інновації.


Такі динаміки задокументовані в добре відомих книгах з інноваційного бізнесу:



Там, де новатори радять компаніям бути гнучкими, CMM радить бути передбачуваними.


Там, де новатори пропонують знизити влада в організації, CMM висуває її нагору.


Там, де новатори пропонують постійні конструктивні інновації, CMM відносить їх до хаосу на рівні 1. Там, де новатори виходять з необхідності слідувати досліджуваному досвіду, CMM виходить з необхідності слідувати папері.


Ніде розкол між цими двома позиціями не виглядає настільки очевидним, як у ставленні до героїзму. SEI розглядає героїзм, як необгрунтовану жертву з боку деяких індивідуумів, наділених спеціальними талантами. Вони розглядають героїзм, як єдину причину досягнення успіху компанією рівня 1, якщо вона взагалі успішна.


Героїзм, найбільш загально практикований успішними компаніями рівня 1, є чимось більшим, ніж містикою. Наш героїзм означає взяття ініціатив за рішенням амбітних проблем. Це не означає, що треба запалити людей, а потім викинути їх, як трактує SEI. Героїзм – це певний і досліджуваний набір поводжень, який посилює і робить почесною здатність творити (як елемент United Technologies Microelectronics Center). Він і засіб спілкування, і спосіб взаємного визнання. Він означає селективне розгортання процесів, але не у відповідності з мандатом на управління, а відповідно до вміннями команди.


Персональне майстерність знаходиться в центрі героїзму, хоча йому теж немає місця в CMM, де він виключений з процесу встановлення формальної тренінгової програми. Peter Senge мав на увазі саме це, коли писав:



"Є очевидні причини, чому компанії чинять опір підтримці персонального майстерності. Це" soft ", заснований частково на неквантіруемих концепціях – таких, як інтуїція і персональне бачення. Ніхто ніколи не здатний виміряти за допомогою 3-х вимірів, в якій мірі персональне майстерність впливає на продуктивність і на практичний результат. У матеріалістичній культурі, як наша, важко навіть обговорювати деякі передумови індивідуальної майстерності. "Чому люди потребують в бесіді про цю нісенітницю", – може запитати хтось. "Хіба це не очевидно? Хіба ми вже не знаємо це?" "


У цьому, я впевнений, суть проблеми, і головна причина, чому CMM небезпечна для будь-якої компанії, створеної для інновацій. Тому, що CMM відноситься підозріло до персональних внесках, ігноруючи умови, необхідні для вирощування нелінійних ідей. Вона задоволена тим, що поміщає їх під обмежує суперструктуру. Досягнення рівня 2 по CMM-шкалі може успішно погасити той вогонь, що горів у компанії із самого початку.


Я згоден, що такі компанії стають більш передбачуваними. Можна слідувати тезі, що життя більш передбачувана, якщо ми вирішили ніколи не залишати ліжку. Але я сумніваюся, що ці компанії можуть довго бути успішними в динамічному світі, якщо вони працюють у своїх піжамах.
Альтернатива CMM


Якщо не модель зрілості, то який каркас може служити нам істинним путівником у процесі поліпшень?


Альтернативний каркас можна знайти в родовій формі в книзі Thriving on Chaos, яка містить 45 розпоряджень. Або в Fifth Discipline, де представлені – як це не дивно – саме 5 дисциплін. Приписи з Thriving on Chaos впроваджені в організаційний інструмент, названий The Excellent Audit. Тепер доступна і книга The Fifth Discipline Fieldbook, де дано додатковий напрям для створення навчаються організацій.



Перевага цих моделей полягає в тому, що вони задають напрямок, не постулюючи форму організації. Вони дійсно дають керівництво для проведення організаційних змін.


Якщо ж торкатися специфіки програмної інженерії, то зауважу, що я працював над процесної моделлю в Borland, яка складалася з семіразмерного каркасу для аналізу проблем та ідентифікації необхідних процесів. Цими вимірами були: бізнес фактори, фактори маркетингу, проектні комплектуючі вузли, 4 первинних процесу (зобов'язання, планування, здійснення, збіжність), команди, інфраструктура процесу, і контрольні точки.


Каркас був пов'язаний з безліччю масштабованих "процесних циклів". Цикли процесу – це повторювані крок за кроком рецепти для здійснення певних спільних завдань.


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


Ключем у цій моделі є те, що цикли процесу є залежними від евристик каркаса. Головне тут – допомогти винести рішення, а не приписи для встановлюють формалізмів. Структура каркасу у вигляді двухразмерной сітки допомагає в процесі підгонки і при пошуку відповідей на питання типу "що, якщо …?"


У термінах такої моделі зрілість означає розпізнавання проблем (через аналіз досвіду і використання метрик) та їх вирішення (через відбір визначень і розгортання формальних і неформальних процесів). І ще це означає розвиток думок і співпраці усередині команд. На відміну від CMM, тут немає пріоритетів в декларуванні проблем чи рішень. Це рішення знаходиться виключно в руках команди. Недолік цієї альтернативної моделі полягає в тому, що вона є більш складною, а тому й менш ринковою. Немає простих відповідей, і наш прогрес не може бути пояснений на пальцях однієї руки. Але ми повинні чинити опір спокусі відступити від незмірну і часом несподіваною реальності інновацій ПЗ.


Після всього цього їй нічого не залишається, як бути незрілої.


Postscript 02/99
За 5 минулих років ні CMM, ні моє ставлення до неї помітно не змінилися. Оборонна індустрія продовжує підтримувати CMM. Деякі комерційні IT-організації слідують їй, багато інших – ні. Програмні компанії, що беруть участь у великій технологічних перегонах нашого часу – Інтернеті – ігнорують цю модель на своїх шляхах. Вчення, яке стверджує, що CMM має велике значення, не розглядає альтернатив. Воно залишає осторонь критичну інформацію, що пропонує проводити повний аналіз того, що відбувається в компаніях, які претендують на просування вгору по рівнях CMM, для отримання переваг.


Одне в моєму думці змінилося. Я відчуваю себе більш комфортно, коли бачу відмінності між філософією CMM і його списком публікацій. Як список публікацій, гідних направлення на поліпшення процесу розробки ПЗ, CMM корисний і сприятливий. Я продовжую стверджувати, що ця модель є неповною і збиває місцями з пантелику, але це ще нічого. Проблеми починаються, як тільки CMM висувають, як філософію для розробки хорошого ПЗ.


Оскільки це так ясно мені, чому філософія CMM стала значно більш популярною, ніж вона того заслуговує. Вона дає надію і ілюзію контролю для управління (процесом розробки). Зіткнувшись з гнітючою реальністю, що успіх на шляху розвитку ПЗ є випадковим і залежить від великої кількості тонких і динамічних чинників і думок, CMM пропонує покроковий план, як робити що-небудь грубо і створювати що-небудь грунтовне. Сумний висновок полягає в тому, що цей покроковий план зазвичай стає замінником справжнього освіти в інженерному управлінні та істинного процесу поліпшень.


За останні кілька років я пройшов навчання в Jerry Weinberg класах з мистецтва управління і зміни: Problem Solving Leadership і Change Shop. Я став учасником його Software Engineering Management Development Group програми і форуму SHAPE. Інформація про це доступна за адресою: http://www.geraldweinberg.com. На мою думку, роботи Jerry продовжують залишатися прекрасною альтернативою парадигмі CMM. Менеджери спочатку повинні навчитися бачити, чути і розуміти людські системи перш, ніж вони можуть сподіватися керувати ними. Вся справа в тому, що програмні проекти – це людські системи.


Одне останнє зауваження. Додайте до свого списку для читання роботу The Logic of Failure (Dietrich Dorner). Dorner аналізує, як люди опановують мистецтво управління складними системами. Без згадки розвитку ПЗ або зрілості здібності (capability maturity), це яскравий аргумент проти філософії CMM (якщо знайдете).

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*