7902
правки
Изменения
м
Нет описания правки
{{Conf-Ref}}
Сегодня прошел день тренингов на [http://www.secr.ru SECR-2012] и я был на [http://www.secr.ru/courses/best-practices-in-software-process-and-product-measurement курсе Билла Кертиса "Современные методы измерения программных продуктов и процессов разработки ПО"]. Я пошел не него, потому как различные метрики для отражения хода разработки активно применяются сейчас и реально обеспечивают эффективность. Об этом рассказывают практики, в качестве примера можно привести доклад [http://2011.secr.ru/lang/ru-ru/talks/using-metrics-in-software-development Максима Кузькина из Parallels Использование метрик в разработке ПО] на прошлом SECR. B хотелось узнать, что думает по этому поводу современная наука.
К сожалению, меня ждало большое разочарование. Потому что рассказ был совсем не о современных методах измерения, а о классике времен становления CMMI, 90-х годах уже прошлого века. И основной массив графиков и историй был из той эпохи, когда была надежда обеспечить предсказуемость процесса разработки и успех проектов за счет регламентных процедур. включая различные измерения. Реальный результат, который был достигнут в то время - это осознание необходимости различных практик раннего обнаружения дефектов в виде проверки требований, design review, code review, раннего тестирования и многих подобных. Раннее обнаружение дефектов было показателем хорошего процесса. А метрики - ориентированы на мониторинг этого, включая сравнение различных проектов - для чего применяется нормировка по числу строк или другому измерению размера проекта.
Под это тогда была разработана определенная теория. А дальше она - законсервировалась, принимая новые понятия, методики и подходы разработки исключительно с целью обеспечить свое псевдосовременное брендирование. Поэтому число use case, story point, functional point - это просто альтернативные способы изменения размера, и вы можете мерить в них, а не в килостроках. А Lean - ну это процесс непрерывного мониторинга показателей (мы всегда говорили, что это нужно!), и их улучшения. И Lean излагается со ссылкой на книгу Поппендик (2007) и иллюстрируется графиками 1995 года. А Agile - это просто когда проект состоит из итераций, каждая из которых - отдельный проект. Список можно продолжать. При таком подходе новые идеи - неизбежно упрощаются и выхолащиваются, увы.
Надо отметить, что это - системная проблема, присущая части современной IT-отрасли, связанной со всякой стандартизацией и сертификацией. Достаточно почитать [http://www.computer.org/portal/web/swebok SWEBOK 3 версии (2004)] и [http://www.pmi.org/PMBOK-Guide-and-Standards.aspx PMBOK 4 версии (2008)], которые формально вписали agile в старый водопадный процесс, без реального согласования коротких итераций, практически непрерывности процесса, со старыми фазами. Кстати. у Билла на слайдах agile culture - это CMMI-5. Биллу задавали вопросы о том, изменилось ли что в мире, почему графики и примеры столь старые. В его мире - не изменилось.
А если подняться еще на один уровень, то этот процесс показывает проблемы глобальной бюрократизации общества. которая способствует образованию подобных регламентных наростов. Потому что институты, созданные в то время и в рамках той парадигмы - они продолжают существовать и имитируют развитие. При том что начальные идеи - были безусловно правильными и хорошими. Более того, большинство практик - восприняты в Agile и активно используются. Только метрики совсем другие: agile, объединив фазы и добавив принципы непрерывного рефакторинга, по-сути, уничтожил старое понятие re-work, сделав его слабо отлдичимым от work, основной работы.
Это же относится к статическому анализу кода, который измеряет интеллектуальная тула [http://www.castsoftware.com/ 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, а необходимая и полезная деятельность. На сей позитивной ноте я закончу свои впечатления о курсе.
{{wl-publish: 2012-10-31 19:39:49 +0400 | MaksTsepkov }}
Сегодня прошел день тренингов на [http://www.secr.ru SECR-2012] и я был на [http://www.secr.ru/courses/best-practices-in-software-process-and-product-measurement курсе Билла Кертиса "Современные методы измерения программных продуктов и процессов разработки ПО"]. Я пошел не него, потому как различные метрики для отражения хода разработки активно применяются сейчас и реально обеспечивают эффективность. Об этом рассказывают практики, в качестве примера можно привести доклад [http://2011.secr.ru/lang/ru-ru/talks/using-metrics-in-software-development Максима Кузькина из Parallels Использование метрик в разработке ПО] на прошлом SECR. B хотелось узнать, что думает по этому поводу современная наука.
К сожалению, меня ждало большое разочарование. Потому что рассказ был совсем не о современных методах измерения, а о классике времен становления CMMI, 90-х годах уже прошлого века. И основной массив графиков и историй был из той эпохи, когда была надежда обеспечить предсказуемость процесса разработки и успех проектов за счет регламентных процедур. включая различные измерения. Реальный результат, который был достигнут в то время - это осознание необходимости различных практик раннего обнаружения дефектов в виде проверки требований, design review, code review, раннего тестирования и многих подобных. Раннее обнаружение дефектов было показателем хорошего процесса. А метрики - ориентированы на мониторинг этого, включая сравнение различных проектов - для чего применяется нормировка по числу строк или другому измерению размера проекта.
Под это тогда была разработана определенная теория. А дальше она - законсервировалась, принимая новые понятия, методики и подходы разработки исключительно с целью обеспечить свое псевдосовременное брендирование. Поэтому число use case, story point, functional point - это просто альтернативные способы изменения размера, и вы можете мерить в них, а не в килостроках. А Lean - ну это процесс непрерывного мониторинга показателей (мы всегда говорили, что это нужно!), и их улучшения. И Lean излагается со ссылкой на книгу Поппендик (2007) и иллюстрируется графиками 1995 года. А Agile - это просто когда проект состоит из итераций, каждая из которых - отдельный проект. Список можно продолжать. При таком подходе новые идеи - неизбежно упрощаются и выхолащиваются, увы.
Надо отметить, что это - системная проблема, присущая части современной IT-отрасли, связанной со всякой стандартизацией и сертификацией. Достаточно почитать [http://www.computer.org/portal/web/swebok SWEBOK 3 версии (2004)] и [http://www.pmi.org/PMBOK-Guide-and-Standards.aspx PMBOK 4 версии (2008)], которые формально вписали agile в старый водопадный процесс, без реального согласования коротких итераций, практически непрерывности процесса, со старыми фазами. Кстати. у Билла на слайдах agile culture - это CMMI-5. Биллу задавали вопросы о том, изменилось ли что в мире, почему графики и примеры столь старые. В его мире - не изменилось.
А если подняться еще на один уровень, то этот процесс показывает проблемы глобальной бюрократизации общества. которая способствует образованию подобных регламентных наростов. Потому что институты, созданные в то время и в рамках той парадигмы - они продолжают существовать и имитируют развитие. При том что начальные идеи - были безусловно правильными и хорошими. Более того, большинство практик - восприняты в Agile и активно используются. Только метрики совсем другие: agile, объединив фазы и добавив принципы непрерывного рефакторинга, по-сути, уничтожил старое понятие re-work, сделав его слабо отлдичимым от work, основной работы.
Это же относится к статическому анализу кода, который измеряет интеллектуальная тула [http://www.castsoftware.com/ 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, а необходимая и полезная деятельность. На сей позитивной ноте я закончу свои впечатления о курсе.
{{wl-publish: 2012-10-31 19:39:49 +0400 | MaksTsepkov }}