Уокер Ройс о процессах разработки ПО
PR-отдел IBM наконец-то одобрил интервью, которое я взял у Уокера Ройса по просьбе дирекции Карьер-лаб/SoftwarePeople.
Интервью строго тематическое, я его провел в стиле подкастов Software Engineering Radio. Оно целиком посвящено истории, текущему состоянию, и перспективам процессов разработки ПО.
Ройс - жжот. Читайте.
***
Уокер Ройс - Вице-президент, Chief Software Economist, IBM SWG
Уолкер Ройс управлял большими проектами разработки программного обеспечения, консультировал клиентов IBM по всему миру и разработал подходы к управлению программными проектами, которые используют итеративный жизненный цикл разработки, лучшие практики индустрии и основные приоритеты архитектуры.
Он - автор двух книг: "Управление проектами по созданию программного обеспечения. Унифицированный подход" (Software Project Management, A Unified Framework , Addison Wesley, 1998) и "Экономика разработки ПО" (The Economics of Software Development Addison Wesley, 2009).
С 1994 по 2009, Ройс был вице-президентом и Генеральным директором IBM Worldwide Rational Services (500 технических специалистов и 100 миллионов долларов в консультационных услугах).
Расскажите, пожалуйста, об истории процессов разработки ПО. Когда о них стали говорить осознанно?
В истории процессов разработки ПО можно выделить три основных этапа.
Все началось с 70-х, когда был изобретен «waterfall». Это была первая попытка формализовать процесс разработки.
В 80-90 взгляд на процессы разработки изменился, и большинство процессов стали строиться на основе эволюционных и итеративных моделей, таких как RUP.
И начиная с нового тысячелетия - общей практикой стал Agile.
В наше время достаточно часто упоминают про проблемы цикла «waterfall». Каковы его основные проблемы, и как получилось, что он стал распространенным в свое время?
Waterfall представляет собой взгляд на процесс разработки как на последовательность четко определенных операций, и способен работать в небольших командах и проектах с небольшой степенью неопределенности.
Несмотря на это, министерство обороны США взяло его за основу при разработке стандарта, регламентирующего организацию работ по всем своим проектам, и, благодаря этому, он приобрел большую известность.
Правда ли, что Вы разработали «waterfall»?
Нет. Цикл «waterfall» изобрел мой отец. Я занимался RUP и циклом «контролируемая итерация».
Как Вы говорили, RUP относится ко второму поколению процессов разработки, и, таким образом, должен быть лучше, чем «waterfall». И, тем не менее, в наше время Agile-подходы более популярны. Какие уроки были извлечены из практики использования RUP, и что с ним оказалось не так?
Основная проблема RUP в том, что его слишком легко использовать неправильным образом. Она проистекает из факта, что RUP пытается быть своего рода энциклопедией практик разработки. Он старается включить в себя все. RUP перечисляет все возможные роли, и все варианты процедур в наиболее тяжелом виде, специфицирует артефакты, и пр.
RUP может быть правильно внедрен - так, что от него будет большая польза. Для этого, в каждом конкретном случае из него надо выкинуть большую часть, и выбрать подходящее подмножество.
Но чаще всего люди делают не так. Они берут RUP, и, вместо того, чтобы начать внедрение с необходимого минимума, выбирают слишком большое количество ролей, артефактов, и процедур. Потому, что они им нравятся. «Отличная роль - давайте ее добавим, это же правильно?» «Смотрите, какой замечательный документ - почему мы таких не делаем?»
В результате, они получают слишком тяжеловесный процесс, который не всегда отвечает их реальным потребностям, и переносят фокус с результата на сам процесс.
Agile-подходы лишены этого недостатка - они предлагают начать с минимума, оставляя возможность увеличивать сложность процесса по мере роста потребности в этом. И это хорошо.
Кроме того, Agile явным образом смещают фокус с производства проектных артефактов на разработку работающего ПО. Что не менее важно.
Термин Agile в наше время сильно размыт. Существует множество методологий, которые относят себя к Agile, и имеют при этом между собой очень мало общего. В качестве примера можно привести Scrum и Feature Driven Development. Многие считают, что это исключительно маркетинговый термин. Каким образом Вы понимаете термин Agile?
Очень просто. Процесс «Agile», если он гибок. Процесс, который адаптивен, и способен быстро меняться, реагируя на внешние обстоятельства и подстраиваясь под них, включая изменение требований - гибок.
И это абсолютно необходимое свойство процесса. В конце концов, это то, что отличает «софт» от «харда». «Софт» гибок по своей природе. Так как мы делаем «софт», было бы странно делать его, оставаясь «жестким».
Каким Вы видите будущее процессов разработки, и какие уроки индустрия извлекла из применения Agile-практик?
Слабая сторона Agile - это плохая способность к повторному использованию наработанных ценностей. Это наиболее серьезная проблема Agile-практик, и сейчас, после десятилетней практики, это совершенно понятно. В будущем это должно быть исправлено.
Другим приоритетом является совмещение управления, основанного на метриках, и Agile-практик.
Вы разделяете точку зрения автора высказывания «you can't control what you can't measure»?
Абсолютно. Представьте, что вы ведете автомобиль. Далеко ли вы уедете без приборной доски? Вы даже не заметите, когда у вас начнет заканчиваться бензин.
Что Вы думаете о работах Уотса Хамфри в данном направлении? Я говорю о CMM, CMMI, и методологиях разработки основанных на метриках - Personal Software Process и Team Software Process?
CMM был слишком сильно привязан к ментальности «waterfall», и это его основная проблема. CMMI исправляет ситуацию, он в большей степени ориентирован на итеративную и эволюционную разработку.
В целом - за CMMI стоит хорошая идея, и хорошие практики, но с ним есть проблема, похожая на проблему RUP. Он часто используется неправильно. Все дело в том, что вы можете иметь очень зрелый, но при этом крайне негибкий процесс разработки.
Касательно методологий TSP/PSP. Я фанат TSP, но не считаю, что PSP является правильным подходом.
Агрегатные метрики для группы разработки в TSP, и принципы управления с использованием метрик- это отлично и очень правильно. При этом PSP с персональными метриками на микроуровне слишком навязчив и отвлекает программистов от работы. Но главная проблема PSP даже не в микроменеджменте. Главное - в том, что по персональным метрикам невозможно судить о работе группы. А интересно-то именно это.
В группе разработки программисты выступают в разных ролях. Используя персональные исторически данные, полученные при индивидуальной работе, невозможно предсказать, как будет работать группа.
Можно ли, по вашему мнению, в принципе использовать метрики для оценки персональной продуктивности программистов?
Разумеется, можно. Но надо понимать, что метрики сами по себе человека не характеризуют. По набору метрик можно оценить человека, если рассматривать метрики в контексте его работы и результатов. И это очень важно.
Я приведу пример. Есть сайт - topcoder.com, на котором проходят соревнования по «спортивному программированию». (http://ru.wikipedia.org/wiki/TopCoder). У каждого участника есть статистика, с самыми разнообразными метриками.
Подход к оценке программистов на основе метрик хорош в случае соревнования, но не работает в случае команды. Что будет, если мы будем ориентироваться на рейтинг в духе topcoder? Допустим, возьмем лучших с topcoder, составим из них команду, чтобы сделать большой проект? Характеризует ли этот рейтинг, построенный на индивидуальных метриках, то, как они будут работать в команде?
Я скажу - с высокой вероятностью они проект провалят. Вместо того чтобы делать работу сообща, при такой системе люди будут конкурировать друг с другом, как это происходит на topcoder. Что не может не повлиять негативно на результат.
Резюмируя: если учитывать контекст, то персональные метрики могут помочь при оценке индивидуального вклада. Но слишком часто контекст не учитывается, и персональные метрики используются неправильно.
Как вы считаете, многие ли менеджеры способны правильно использовать персональные метрики, принимая во внимание контекст?
Я бы сказал, что процентов 80 менеджеров будут использовать их неправильно. Это оценка, основанная на моем опыте и ощущениях, на точность я не претендую.
Что вы посоветуете людям, которые хотят улучшить процесс разработки сейчас? С чего им начать?
Начать с современных Agile-практик. Двигаясь от простого и усложняя процессы только в случае, когда в этом возникает потребность.
Особое внимание на начальном этапе я бы рекомендовал обратить на Test Driven Development. Эта практика формирует правильное отношение к процессу разработки, делая акцент на том, что главный результат разработки и его цель - это корректно работающий код. Ради него все делается, все остальное второстепенно. Следуя TDD, это совершенно невозможно упустить.
Интервью строго тематическое, я его провел в стиле подкастов Software Engineering Radio. Оно целиком посвящено истории, текущему состоянию, и перспективам процессов разработки ПО.
Ройс - жжот. Читайте.
***
Уокер Ройс - Вице-президент, Chief Software Economist, IBM SWG
Уолкер Ройс управлял большими проектами разработки программного обеспечения, консультировал клиентов IBM по всему миру и разработал подходы к управлению программными проектами, которые используют итеративный жизненный цикл разработки, лучшие практики индустрии и основные приоритеты архитектуры.
Он - автор двух книг: "Управление проектами по созданию программного обеспечения. Унифицированный подход" (Software Project Management, A Unified Framework , Addison Wesley, 1998) и "Экономика разработки ПО" (The Economics of Software Development Addison Wesley, 2009).
С 1994 по 2009, Ройс был вице-президентом и Генеральным директором IBM Worldwide Rational Services (500 технических специалистов и 100 миллионов долларов в консультационных услугах).
Расскажите, пожалуйста, об истории процессов разработки ПО. Когда о них стали говорить осознанно?
В истории процессов разработки ПО можно выделить три основных этапа.
Все началось с 70-х, когда был изобретен «waterfall». Это была первая попытка формализовать процесс разработки.
В 80-90 взгляд на процессы разработки изменился, и большинство процессов стали строиться на основе эволюционных и итеративных моделей, таких как RUP.
И начиная с нового тысячелетия - общей практикой стал Agile.
В наше время достаточно часто упоминают про проблемы цикла «waterfall». Каковы его основные проблемы, и как получилось, что он стал распространенным в свое время?
Waterfall представляет собой взгляд на процесс разработки как на последовательность четко определенных операций, и способен работать в небольших командах и проектах с небольшой степенью неопределенности.
Несмотря на это, министерство обороны США взяло его за основу при разработке стандарта, регламентирующего организацию работ по всем своим проектам, и, благодаря этому, он приобрел большую известность.
Правда ли, что Вы разработали «waterfall»?
Нет. Цикл «waterfall» изобрел мой отец. Я занимался RUP и циклом «контролируемая итерация».
Как Вы говорили, RUP относится ко второму поколению процессов разработки, и, таким образом, должен быть лучше, чем «waterfall». И, тем не менее, в наше время Agile-подходы более популярны. Какие уроки были извлечены из практики использования RUP, и что с ним оказалось не так?
Основная проблема RUP в том, что его слишком легко использовать неправильным образом. Она проистекает из факта, что RUP пытается быть своего рода энциклопедией практик разработки. Он старается включить в себя все. RUP перечисляет все возможные роли, и все варианты процедур в наиболее тяжелом виде, специфицирует артефакты, и пр.
RUP может быть правильно внедрен - так, что от него будет большая польза. Для этого, в каждом конкретном случае из него надо выкинуть большую часть, и выбрать подходящее подмножество.
Но чаще всего люди делают не так. Они берут RUP, и, вместо того, чтобы начать внедрение с необходимого минимума, выбирают слишком большое количество ролей, артефактов, и процедур. Потому, что они им нравятся. «Отличная роль - давайте ее добавим, это же правильно?» «Смотрите, какой замечательный документ - почему мы таких не делаем?»
В результате, они получают слишком тяжеловесный процесс, который не всегда отвечает их реальным потребностям, и переносят фокус с результата на сам процесс.
Agile-подходы лишены этого недостатка - они предлагают начать с минимума, оставляя возможность увеличивать сложность процесса по мере роста потребности в этом. И это хорошо.
Кроме того, Agile явным образом смещают фокус с производства проектных артефактов на разработку работающего ПО. Что не менее важно.
Термин Agile в наше время сильно размыт. Существует множество методологий, которые относят себя к Agile, и имеют при этом между собой очень мало общего. В качестве примера можно привести Scrum и Feature Driven Development. Многие считают, что это исключительно маркетинговый термин. Каким образом Вы понимаете термин Agile?
Очень просто. Процесс «Agile», если он гибок. Процесс, который адаптивен, и способен быстро меняться, реагируя на внешние обстоятельства и подстраиваясь под них, включая изменение требований - гибок.
И это абсолютно необходимое свойство процесса. В конце концов, это то, что отличает «софт» от «харда». «Софт» гибок по своей природе. Так как мы делаем «софт», было бы странно делать его, оставаясь «жестким».
Каким Вы видите будущее процессов разработки, и какие уроки индустрия извлекла из применения Agile-практик?
Слабая сторона Agile - это плохая способность к повторному использованию наработанных ценностей. Это наиболее серьезная проблема Agile-практик, и сейчас, после десятилетней практики, это совершенно понятно. В будущем это должно быть исправлено.
Другим приоритетом является совмещение управления, основанного на метриках, и Agile-практик.
Вы разделяете точку зрения автора высказывания «you can't control what you can't measure»?
Абсолютно. Представьте, что вы ведете автомобиль. Далеко ли вы уедете без приборной доски? Вы даже не заметите, когда у вас начнет заканчиваться бензин.
Что Вы думаете о работах Уотса Хамфри в данном направлении? Я говорю о CMM, CMMI, и методологиях разработки основанных на метриках - Personal Software Process и Team Software Process?
CMM был слишком сильно привязан к ментальности «waterfall», и это его основная проблема. CMMI исправляет ситуацию, он в большей степени ориентирован на итеративную и эволюционную разработку.
В целом - за CMMI стоит хорошая идея, и хорошие практики, но с ним есть проблема, похожая на проблему RUP. Он часто используется неправильно. Все дело в том, что вы можете иметь очень зрелый, но при этом крайне негибкий процесс разработки.
Касательно методологий TSP/PSP. Я фанат TSP, но не считаю, что PSP является правильным подходом.
Агрегатные метрики для группы разработки в TSP, и принципы управления с использованием метрик- это отлично и очень правильно. При этом PSP с персональными метриками на микроуровне слишком навязчив и отвлекает программистов от работы. Но главная проблема PSP даже не в микроменеджменте. Главное - в том, что по персональным метрикам невозможно судить о работе группы. А интересно-то именно это.
В группе разработки программисты выступают в разных ролях. Используя персональные исторически данные, полученные при индивидуальной работе, невозможно предсказать, как будет работать группа.
Можно ли, по вашему мнению, в принципе использовать метрики для оценки персональной продуктивности программистов?
Разумеется, можно. Но надо понимать, что метрики сами по себе человека не характеризуют. По набору метрик можно оценить человека, если рассматривать метрики в контексте его работы и результатов. И это очень важно.
Я приведу пример. Есть сайт - topcoder.com, на котором проходят соревнования по «спортивному программированию». (http://ru.wikipedia.org/wiki/TopCoder). У каждого участника есть статистика, с самыми разнообразными метриками.
Подход к оценке программистов на основе метрик хорош в случае соревнования, но не работает в случае команды. Что будет, если мы будем ориентироваться на рейтинг в духе topcoder? Допустим, возьмем лучших с topcoder, составим из них команду, чтобы сделать большой проект? Характеризует ли этот рейтинг, построенный на индивидуальных метриках, то, как они будут работать в команде?
Я скажу - с высокой вероятностью они проект провалят. Вместо того чтобы делать работу сообща, при такой системе люди будут конкурировать друг с другом, как это происходит на topcoder. Что не может не повлиять негативно на результат.
Резюмируя: если учитывать контекст, то персональные метрики могут помочь при оценке индивидуального вклада. Но слишком часто контекст не учитывается, и персональные метрики используются неправильно.
Как вы считаете, многие ли менеджеры способны правильно использовать персональные метрики, принимая во внимание контекст?
Я бы сказал, что процентов 80 менеджеров будут использовать их неправильно. Это оценка, основанная на моем опыте и ощущениях, на точность я не претендую.
Что вы посоветуете людям, которые хотят улучшить процесс разработки сейчас? С чего им начать?
Начать с современных Agile-практик. Двигаясь от простого и усложняя процессы только в случае, когда в этом возникает потребность.
Особое внимание на начальном этапе я бы рекомендовал обратить на Test Driven Development. Эта практика формирует правильное отношение к процессу разработки, делая акцент на том, что главный результат разработки и его цель - это корректно работающий код. Ради него все делается, все остальное второстепенно. Следуя TDD, это совершенно невозможно упустить.