Я часто общаюсь с людьми на тему гибких методов разработки ПО, иногда пишу статьи про это (например, недавняя статья на хабре про Канбан в IT).
И я могу сказать, что основной аргумент, который люди приводят против этих методов, который останавливает многих даже от мыслей про Канбан, Scrum или XP — это якобы низкий уровень контроля за разработкой у этих методологий.
При этом некоторые воспринимают, как непрофессионализм, доводы о том, что уровень контроля не сильно-то зависит от методологии, да и вообще контроль в сфере разработки ПО — это по большому счету фикция.
Для таких людей я перевёл новую статью Тома Демарко, одного из основоположников инжиниринга ПО, разработчика метрик для ПО и соавтора известной книги «Человеческий фактор: успешные проекты и команды».
Эта статья сильно провокационная и сейчас широко обсуждается в англоязычных блогах и странно, что я еще не встречал ее переводов на русский. Но, несмотря на провокационность, в ней есть несколько очень правильных идей, которые могут изменить у кого-то представление о важности и возможности контроля за разработкой.
В общем, читайте перевод статьи под катом.
Том ДеМарко: Инжиниринг ПО — идея, время которой прошло?
Совсем недавно прошла 40-ая годовщина конференции NATO про Software Engineering (инжиниринг ПО), которая проходила в Гармише, Германия. Именно там была впервые предложена дисциплина инжиниринга для ПО.
Так как мои ранние книги стали частью этой новой дисциплины, то сейчас кажется отличный момент для ревизии, пересмотра позиции. Моя ранняя книга о метриках, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), сыграла большую роль в том, как многие выдающиеся разработчики делили работу и планировали свои проекты.
И сейчас мне интересно, а были ли эти мои советы правильными в прошлом, правильны ли они до сих пор, и верю ли я все еще, что метрики необходимы для любого успешного проекта по разработке?
Мои ответы: НЕТ, НЕТ и НЕТ.
Книга для меня — это любопытная комбинация в общем-то верных вещей, написанных на каждой странице, но все вместе они создают общее послание, которое неверно.
Как будто бы юный автор книги никогда не встречал метрик, которые ему бы не нравились. Глубинный смысл книги видится в том, что метрики — это хорошо и чем больше метрик — тем лучше.
Сейчас же мы все понимаем, что метрики стоят денег и времени и должны быть использованы с осторожной умеренностью.
В дополнение, разработка ПО по сути отличается от натуральной науки, такой, как физика, и метрики из-за этого намного менее точны. И они должны рассматриваться очень скептически, а не безоговорочно.
Подчиненный контролю
Самая цитируемая строка моей книги — это самое первое предложение:
«Ты не можешь контролировать то, что ты не можешь измерить»
Это предложение — правда, но я все больше и больше нахожу, что мое использование этого предложение неверно. Предложение подразумевает, что контроль — это важный аспект, возможно самый важный для любого проекта по разработке ПО.
Но это не так!
Множество проектов развивались без всякого контроля, но все-таки в результате получились превосходные продукты — такие, как GoogleEarth или Wikipedia.
Чтобы понять реальную роль контроля, вы должны понять разницу между двумя абсолютно разными типами проектов:
«Проект A» в конечном счете будет стоить 1 млн$ и принесет прибыль (value) примерно в 1.1 млн$.
«Проект B» в конечном счете будет стоить около миллиона долларов и принесет прибыль (value) более, чем 50 млн.
Сразу становится понятно, что контроль реально очень важен для проекта A, но совершенно не важен для проекта B. Это приводит нас к совершенно странному заключению, что жесткий контроль — это что-то, что очень важно для относительно бесполезных проектов и намного менее важно для полезных проектов.
Это подсказывает, что чем более вы фокусируетесь на контроле, тем более вероятно, что вы работаете на проекте, который в итоге принесет очень мало прибыли.
Я думаю, что намного более важный вопрос — это «За каким дьяволом мы делаем так много проектов, которые приносят так мало прибыли?»
Могу ли я реально сказать, что это нормально запускать проекты без контроля или с относительно небольшим контролем? Практически!
Я предполагаю, что сначала нам надо выбрать проекты, где точный контроль не будет нужен так уж сильно. Далее нам надо уменьшить наши ожидания того, как сильно мы будем его контролировать, независимо от того, как усердно мы будем пытаться это делать.
Тревожащая аналогия
Представьте, что вы пытаетесь контролировать воспитание подростка. Сама идея контролирования вашего ребенка может показаться вам немного волнительной, неприятной. Кроме того, ставки на то, что у вас это получится, не могут быть высоки.
Если вы провалите эту задачу, совсем провалите, то это может разрушить чьи-то жизни. Так что очевидно, что вы не ослабите свою хватку полностью и не отпустите подростка в вольное плавание.
Так что вы, как фехтовальщик, учащийся держать свой меч, как будто это была бы птица: слишком сильно и птица будет повреждена; слишком слабо и она улетит…
Теперь примените правило «Вы не можете контролировать то, что вы не можете измерить» к подростку. Большинство вещей, которые реально важны — честь, достоинство, дисциплина, личность, вежливость под давлением, ценности, этика, изобретательность, лояльность, юмор, доброжелательность — они не измеримы.
Вы должны просто направлять вашего ребенка так хорошо, как вы можете без всякой помощи каких бы то ни было метрик. И это сложно, но ведь воспитание детей — сложно.
У вас будет немного «мерок» в виде школьных оценок, и вы благодарны за это. Но вы также знаете, что оценка по математике для вашего ребенка — это более хороший показатель достижений, чем оценка за «испанский», так как понимание математики проще измерить.
И его оценка по поведению скорее всего скажет вам намного больше об учителе, чем о ребенке.
Итак, как вы управляете проектом без контроля?
Чтож, вы управляете людьми и контролируете время и деньги. Вы говорите лидеру команды, например:
«Я знаю финальную дату, и я даже не собираюсь тебе ее говорить. В один день я приду к тебе и скажу, что проект закончится через неделю — ты должен быть готов закончить все работы и сделать то, что есть, готовым продуктом. Твоя задача — работать инкрементально, добавляя куски в проект в порядке их важности, и делая интеграцию, документацию и тестирование инкрементально и постоянно.»
Это может звучать, как рекомендация гибких методов, но я слишком далек сейчас от, собственно, создания ПО, чтобы рекомендовать на уровне методов. Скорее, я рекомендую менеджерский подход — такой, который может направить команду в сторону гибких методов, по крайней мере в сторону инкрементальных идей из школы гибкой разработки.
До сих пор я в основном обсуждал метрики из состава инжиниринга ПО (Software Engineering). Как насчет остального?
Я мало-помалу прихожу к заключению, что Software Engineering — это идея, время которой пришло и прошло!
Я все еще верю, что есть огромный смысл в инжиниринге ПО. Но это не совсем то, что инжиниринг ПО стал значить. Этот термин окружает определенный набор дисциплин, включающих определенный процесс, экспертизы и исследования, разработку требований, метрики, инжиниринг, контроль качества, строгое планирование и отслеживание, стандарты кодирования и документации.
Всё это нужно для логичности практик и для предсказуемости. Логичность и предсказуемость все еще желательны, но они никогда не были самыми важными вещами.
За последние 40 лет, например, мы пытали себя за то, что мы не можем закончить проекты вовремя и без превышения бюджета. Но, как я отметил ранее, гораздо более важная цель — это создание ПО, которое меняет мир, или которое трансформирует компанию или то, как она ведет свой бизнес. Мы были скорее намного успешными в изменениях, которые часто происходят вне контроля.
Разработка ПО есть и всегда будет чем-то экспериментальным. Да, само создание программы не обязательно экспериментально, но концепция программы — всегда.
И это именно то место, где мы должны фокусироваться. И это то самое место, где мы всегда должны были фокусировать и раньше.
И я могу сказать, что основной аргумент, который люди приводят против этих методов, который останавливает многих даже от мыслей про Канбан, Scrum или XP — это якобы низкий уровень контроля за разработкой у этих методологий.
При этом некоторые воспринимают, как непрофессионализм, доводы о том, что уровень контроля не сильно-то зависит от методологии, да и вообще контроль в сфере разработки ПО — это по большому счету фикция.
Для таких людей я перевёл новую статью Тома Демарко, одного из основоположников инжиниринга ПО, разработчика метрик для ПО и соавтора известной книги «Человеческий фактор: успешные проекты и команды».
Эта статья сильно провокационная и сейчас широко обсуждается в англоязычных блогах и странно, что я еще не встречал ее переводов на русский. Но, несмотря на провокационность, в ней есть несколько очень правильных идей, которые могут изменить у кого-то представление о важности и возможности контроля за разработкой.
В общем, читайте перевод статьи под катом.
Том ДеМарко: Инжиниринг ПО — идея, время которой прошло?
Совсем недавно прошла 40-ая годовщина конференции NATO про Software Engineering (инжиниринг ПО), которая проходила в Гармише, Германия. Именно там была впервые предложена дисциплина инжиниринга для ПО.
Так как мои ранние книги стали частью этой новой дисциплины, то сейчас кажется отличный момент для ревизии, пересмотра позиции. Моя ранняя книга о метриках, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), сыграла большую роль в том, как многие выдающиеся разработчики делили работу и планировали свои проекты.
И сейчас мне интересно, а были ли эти мои советы правильными в прошлом, правильны ли они до сих пор, и верю ли я все еще, что метрики необходимы для любого успешного проекта по разработке?
Мои ответы: НЕТ, НЕТ и НЕТ.
Книга для меня — это любопытная комбинация в общем-то верных вещей, написанных на каждой странице, но все вместе они создают общее послание, которое неверно.
Как будто бы юный автор книги никогда не встречал метрик, которые ему бы не нравились. Глубинный смысл книги видится в том, что метрики — это хорошо и чем больше метрик — тем лучше.
Сейчас же мы все понимаем, что метрики стоят денег и времени и должны быть использованы с осторожной умеренностью.
В дополнение, разработка ПО по сути отличается от натуральной науки, такой, как физика, и метрики из-за этого намного менее точны. И они должны рассматриваться очень скептически, а не безоговорочно.
Подчиненный контролю
Самая цитируемая строка моей книги — это самое первое предложение:
«Ты не можешь контролировать то, что ты не можешь измерить»
Это предложение — правда, но я все больше и больше нахожу, что мое использование этого предложение неверно. Предложение подразумевает, что контроль — это важный аспект, возможно самый важный для любого проекта по разработке ПО.
Но это не так!
Множество проектов развивались без всякого контроля, но все-таки в результате получились превосходные продукты — такие, как GoogleEarth или Wikipedia.
Чтобы понять реальную роль контроля, вы должны понять разницу между двумя абсолютно разными типами проектов:
«Проект A» в конечном счете будет стоить 1 млн$ и принесет прибыль (value) примерно в 1.1 млн$.
«Проект B» в конечном счете будет стоить около миллиона долларов и принесет прибыль (value) более, чем 50 млн.
Сразу становится понятно, что контроль реально очень важен для проекта A, но совершенно не важен для проекта B. Это приводит нас к совершенно странному заключению, что жесткий контроль — это что-то, что очень важно для относительно бесполезных проектов и намного менее важно для полезных проектов.
Это подсказывает, что чем более вы фокусируетесь на контроле, тем более вероятно, что вы работаете на проекте, который в итоге принесет очень мало прибыли.
Я думаю, что намного более важный вопрос — это «За каким дьяволом мы делаем так много проектов, которые приносят так мало прибыли?»
Могу ли я реально сказать, что это нормально запускать проекты без контроля или с относительно небольшим контролем? Практически!
Я предполагаю, что сначала нам надо выбрать проекты, где точный контроль не будет нужен так уж сильно. Далее нам надо уменьшить наши ожидания того, как сильно мы будем его контролировать, независимо от того, как усердно мы будем пытаться это делать.
Тревожащая аналогия
Представьте, что вы пытаетесь контролировать воспитание подростка. Сама идея контролирования вашего ребенка может показаться вам немного волнительной, неприятной. Кроме того, ставки на то, что у вас это получится, не могут быть высоки.
Если вы провалите эту задачу, совсем провалите, то это может разрушить чьи-то жизни. Так что очевидно, что вы не ослабите свою хватку полностью и не отпустите подростка в вольное плавание.
Так что вы, как фехтовальщик, учащийся держать свой меч, как будто это была бы птица: слишком сильно и птица будет повреждена; слишком слабо и она улетит…
Теперь примените правило «Вы не можете контролировать то, что вы не можете измерить» к подростку. Большинство вещей, которые реально важны — честь, достоинство, дисциплина, личность, вежливость под давлением, ценности, этика, изобретательность, лояльность, юмор, доброжелательность — они не измеримы.
Вы должны просто направлять вашего ребенка так хорошо, как вы можете без всякой помощи каких бы то ни было метрик. И это сложно, но ведь воспитание детей — сложно.
У вас будет немного «мерок» в виде школьных оценок, и вы благодарны за это. Но вы также знаете, что оценка по математике для вашего ребенка — это более хороший показатель достижений, чем оценка за «испанский», так как понимание математики проще измерить.
И его оценка по поведению скорее всего скажет вам намного больше об учителе, чем о ребенке.
Итак, как вы управляете проектом без контроля?
Чтож, вы управляете людьми и контролируете время и деньги. Вы говорите лидеру команды, например:
«Я знаю финальную дату, и я даже не собираюсь тебе ее говорить. В один день я приду к тебе и скажу, что проект закончится через неделю — ты должен быть готов закончить все работы и сделать то, что есть, готовым продуктом. Твоя задача — работать инкрементально, добавляя куски в проект в порядке их важности, и делая интеграцию, документацию и тестирование инкрементально и постоянно.»
Это может звучать, как рекомендация гибких методов, но я слишком далек сейчас от, собственно, создания ПО, чтобы рекомендовать на уровне методов. Скорее, я рекомендую менеджерский подход — такой, который может направить команду в сторону гибких методов, по крайней мере в сторону инкрементальных идей из школы гибкой разработки.
До сих пор я в основном обсуждал метрики из состава инжиниринга ПО (Software Engineering). Как насчет остального?
Я мало-помалу прихожу к заключению, что Software Engineering — это идея, время которой пришло и прошло!
Я все еще верю, что есть огромный смысл в инжиниринге ПО. Но это не совсем то, что инжиниринг ПО стал значить. Этот термин окружает определенный набор дисциплин, включающих определенный процесс, экспертизы и исследования, разработку требований, метрики, инжиниринг, контроль качества, строгое планирование и отслеживание, стандарты кодирования и документации.
Всё это нужно для логичности практик и для предсказуемости. Логичность и предсказуемость все еще желательны, но они никогда не были самыми важными вещами.
За последние 40 лет, например, мы пытали себя за то, что мы не можем закончить проекты вовремя и без превышения бюджета. Но, как я отметил ранее, гораздо более важная цель — это создание ПО, которое меняет мир, или которое трансформирует компанию или то, как она ведет свой бизнес. Мы были скорее намного успешными в изменениях, которые часто происходят вне контроля.
Разработка ПО есть и всегда будет чем-то экспериментальным. Да, само создание программы не обязательно экспериментально, но концепция программы — всегда.
И это именно то место, где мы должны фокусироваться. И это то самое место, где мы всегда должны были фокусировать и раньше.
