Сегодня прошел день тренингов на SECR-2012 и я был на курсе Билла Кертиса "Современные методы измерения программных продуктов и процессов разработки ПО". Я пошел не него, потому как различные метрики для отражения хода разработки активно применяются сейчас и реально обеспечивают эффективность. Об этом рассказывают практики, в качестве примера можно привести доклад Максима Кузькина из Parallels Использование метрик в разработке ПО на прошлом SECR. B хотелось узнать, что думает по этому поводу современная наука.
К сожалению, меня ждало большое разочарование. Потому что рассказ был совсем не о современных методах измерения, а о классике времен становления CMMI, 90-х годах уже прошлого века. И основной массив графиков и историй был из той эпохи, когда была надежда обеспечить предсказуемость процесса разработки и успех проектов за счет регламентных процедур. включая различные измерения. Реальный результат, который был достигнут в то время - это осознание необходимости различных практик раннего обнаружения дефектов в виде проверки требований, design review, code review, раннего тестирования и многих подобных. Раннее обнаружение дефектов было показателем хорошего процесса. А метрики - ориентированы на мониторинг этого, включая сравнение различных проектов - для чего применяется нормировка по числу строк или другому измерению размера проекта.
Под это тогда была разработана определенная теория. А дальше она - законсервировалась, принимая новые понятия, методики и подходы разработки исключительно с целью обеспечить свое псевдосовременное брендирование. Поэтому число use case, story point, functional point - это просто альтернативные способы изменения размера, и вы можете мерить в них, а не в килостроках. А Lean - ну это процесс непрерывного мониторинга показателей (мы всегда говорили, что это нужно!), и их улучшения. И Lean излагается со ссылкой на книгу Поппендик (2007) и иллюстрируется графиками 1995 года. А Agile - это просто когда проект состоит из итераций, каждая из которых - отдельный проект. Список можно продолжать. При таком подходе новые идеи - неизбежно упрощаются и выхолащиваются, увы.
Надо отметить, что это - системная проблема, присущая части современной IT-отрасли, связанной со всякой стандартизацией и сертификацией. Достаточно почитать SWEBOK 3 версии (2004) и PMBOK 4 версии (2008), которые формально вписали agile в старый водопадный процесс, без реального согласования коротких итераций, практически непрерывности процесса, со старыми фазами. Кстати. у Билла на слайдах agile culture - это CMMI-5. Биллу задавали вопросы о том, изменилось ли что в мире, почему графики и примеры столь старые. В его мире - не изменилось.
А если подняться еще на один уровень, то этот процесс показывает проблемы глобальной бюрократизации общества. которая способствует образованию подобных регламентных наростов. Потому что институты, созданные в то время и в рамках той парадигмы - они продолжают существовать и имитируют развитие. При том что начальные идеи - были безусловно правильными и хорошими. Более того, большинство практик - восприняты в Agile и активно используются. Только метрики совсем другие: agile, объединив фазы и добавив принципы непрерывного рефакторинга, по-сути, уничтожил старое понятие re-work, сделав его слабо отлдичимым от work, основной работы.
Это же относится к статическому анализу кода, который измеряет интеллектуальная тула CAST (где Билл - Chief Scientist). Она анализирует код почти на любой платформе и ищет дефекты. Только, опять-таки, эти дефекты - из прошлого: buffer overflow, sql injection и подобные. Не в том смысле, что в современных разработках они не встречаются, а в том смысле, что сейчас их надо не измерять, а устранять, и там, где для этого есть желание - этот процесс организуют. Плюс современные платформы и фреймворки - просто обеспечивают на базовом уровне, в них проблемы статического анализа и сложности кода возникают совершенно на другом уровне - сложные generic-классы, лямбда-выражения с замыканием и тому подобное. B вокруг этого - разрабатываются современные средства, хотя они - четко не успевают за развитием мультипарадигмальных языков.
Однако, такие мероприятия напоминают нам о реальном мире и отличительных особенностях его устройства, в частности бюрократизации. Кроме того, из подобных обзорных докладов можно извлечь пользу в части взаимоотношений с бюрократизированной частью мира, особенно выступающей в роли заказчиков - крупных государственных или коммерческих структур. Например, продажа рефакторинга и реинжиниринга, который вроде как не имеет business value. На самом деле, в этом случае имеет место быть Real Option Valuation: вложи сейчас 100 рублей, чтобы не вкладывать через год 300. Правда. 300 еще надо показать, но это уже ловкость рук и никакого мошенничества :) Или метафора технического долга (technical debt) - способ объяснить менеджерам и финансистам, почему низкое качество кода является проблемой, подлежащей решению путем рефакторинга и реинжиниринга.
А еще - широкий и относительно плотный обзор на высоком уровне даже не концепций, а ключевых слов, мемов в их взаимосвязи - является полезным. Он добавляет в твой арсенал те концепции и ключевые фразы, которых там, возможно. раньше не было, например, концепцию Application Health, которая дополняет (должна дополнять) концепцию Business Value, и объясняет, почему работа над качеством - вовсе не waste и muda, а необходимая и полезная деятельность. На сей позитивной ноте я закончу свои впечатления о курсе.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.