Software Engineering is Dead?!

Я часто общаюсь с людьми на тему гибких методов разработки ПО, иногда пишу статьи про это. И могу сказать, что основной аргумент, который люди приводят против этих методов, который останавливает многих даже от мыслей про Канбан, 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 лет, например, мы пытали себя за то, что мы не можем закончить проекты вовремя и без превышения бюджета. Но, как я отметил ранее, гораздо более важная цель - это создание ПО, которое меняет мир, или которое трансформирует компанию или то, как она ведет свой бизнес. Мы были скорее намного успешными в изменениях, которые часто происходят вне контроля.


Разработка ПО есть и всегда будет чем-то экспериментальным. Да, само создание программы не обязательно экспериментально, но концепция программы - всегда.
И это именно то место, где мы должны фокусироваться. И это то самое место, где мы всегда должны были фокусировать и раньше.


Понравилась статья? Подпишись на RSS!

15 комментариев к Software Engineering is Dead?!

  • Хорошая статья, провокационная :)

    1. Тот кто придет через неделю и скажет, что “пора сдавать” контроллирует проект и ведет какие-то метрики. Ведь если он придет через 2 недели после начала большого проекта, то готовый продукт вряд ли выйдет.

    2. Степень контроля при таком подходе выше, чем раньше. Если сравнивать с армией, то роте (группе разработчиков) придется находится в состоянии полной боевой готовности.

    3. Если контроль метрик не приводит к нужному результату, то возможно, что их влияние на результат мало. Скорее всего эти метрики были выбраны, потому что других нет :)

  • Ilya

    Сроками/ресурсами проекта управляет скорее project manager, а product manager управляет развитием продукта и должен думать о получении value.
    Вероятно, что роли project и product manager будет совмещать один человек.

    • Вероятно, что роли project и product manager будет совмещать один человек.

      Это не очень хорошо, когда эти 2 роли совмещены, ибо они требуют разных навыков и, часто, полной самоотдачи. Совмещая их, можно получить неполноценных project менеджера и продакт менеджера.
      Мало того, последнее время мне все больше нравится работать совсем без project менеджера - команда, работающая над проектом, является project менеджером сама по себе :)

  • Отличная статья! Большое спасибо за перевод! В последних работах тема выбора проектов по их ожидаемой отдачи прослеживается часто. Особенное внимание было в его “Вальсируя с медведями”. Хоть там поднималась тема немного под другим углом, что уровень риска напрямую связан с уровнем отдачи. Собственно здесь тоже самое - ключевой посыл в выборе проектов с максимальной отдачей “которые меняют мир”.

    Тема правильная, однако … Автор старый военный, много чего и кого знает, что привело его совершенно к другому уровню понимания проблем - он на более высоком уровне. Но этот уровень все еще очень зависит от уровня навыков инженерии ПО. Собственно не в Управлении проектами, а, скорее, методам создания этих проектов. Т.е. к архитектуре и программированию. Т.е. автор видит идеальную ситуацию.

    Да идеальная ситуация складывается. Но складывается из идеальных, или приближенных к ним, знаниях более низкого технического уровня.

    • Т.е. автор видит идеальную ситуацию.

      Авторы книг и статей вообще этому сильно подвержены - они видят и описывают обычно “идеальную” ситуацию. Ибо описать все ситуации просто невозможно - каждая ситуация уникальна и можно исписать миллион страниц и не описать и 1% реальных ситуаций.

  • А мне интересно, как можно оценить value от проекта, да еще и в денежном эквиваленте, чтобы решить стоит проект того или нет.

    Или подразумевается, что если мы не будем ставить контроль на первый план, то у проекта A есть шанс стать проектом B ? :)

    p.s.
    Опять старая история с обрезанием комментариев…

  • >>А мне интересно, как можно оценить value от проекта, да еще и в денежном эквиваленте, чтобы решить стоит проект того или нет.

    Это задача маркетологов, а не программистов :)
    >>p.s.
    >>Опять старая история с обрезанием комментариев…

    Авторы OpenID так еще и не исправили…

  • Если проект планируется на продажу, как коробка, - то, я могу себе представить, что в принципе можно как-то оценить спрос/предложение. А если это внутренний проект?

    p.s.
    Если честно, не встречал ни разу маркетологов вообще и, в частности, тех, которые бы оценивали ИТ-проекты. Как они могут оценить value ИТ-проекта?

  • Ну я встречал маркетологов. У меня сложилось впечатление, что их задача подготовить пресс-релиз с новыми фичами.

    А оценивать ценность фичи должны product manager’ы или лица их заменяющие :)

  • Если это внутренний проект, то value продукта тоже можно оценить - это сэкономленные деньги и время на том, что будет делать этот новый продукт. Ведь даже если он внутренний - его же не просто так начинают, а чтобы сделать что-то эффективнее. А значит можно как-то оценить эту будущую эффективность.

    Если честно, не встречал ни разу маркетологов вообще и, в частности, тех, которые бы оценивали ИТ-проекты. Как они могут оценить value ИТ-проекта?

    У нас оценивают как-то. Но идея как раз в том, как я понял, чтобы браться за сильно прибыльные проекты. Если прибыль планируется в 10 раз больше расходов, то даже если маркетолог ошибется в 2 раза - ничего страшного. А если прибыль чуть выше расходов - лучше отказаться от такого проекта.

  • > А оценивать ценность фичи должны product manager’ы или лица их заменяющие :)

    Разве PM занимается не тем, что управляет сроками/ресурсами проекта, учитывая всевозможные ограничения? Какое отношение он имеет к определению value?

  • Не соглашусь с тобой. Насколько я знаю этим занимаются организационные структурные службы маркетинга.

  • Этим занимается project manager. А то product manager :)

  • Не так прочитал, прошу прощения.
    Product manager’ов я тоже не встречал, это видимо те же “коробочные” роли? А что если у нас не коробка, а внутренный ИТ-проект?

  • Тогда проще. У вас есть внутренний заказчик, который ставит требования. Плохо когда этих внутренних заказчиков несколько. Например, один продукт несколько отделов обслуживает и этим отделам нужен разный функционал.

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>