Том ДеМарко: инжиниринг ПО — идея, время которой прошло?

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
  • Перевод
Я часто общаюсь с людьми на тему гибких методов разработки ПО, иногда пишу статьи про это (например, недавняя статья на хабре про Канбан в 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 лет, например, мы пытали себя за то, что мы не можем закончить проекты вовремя и без превышения бюджета. Но, как я отметил ранее, гораздо более важная цель — это создание ПО, которое меняет мир, или которое трансформирует компанию или то, как она ведет свой бизнес. Мы были скорее намного успешными в изменениях, которые часто происходят вне контроля.

Разработка ПО есть и всегда будет чем-то экспериментальным. Да, само создание программы не обязательно экспериментально, но концепция программы — всегда.
И это именно то место, где мы должны фокусироваться. И это то самое место, где мы всегда должны были фокусировать и раньше.
Поделиться публикацией
Комментарии 37
    +3
    Честно говоря, напоминает гадскую рекламу новостных сайтов: на баннере написано, что «Сенсация! Запущен первый в мире телепортатор!», на сайте в заголовке статьи — что учоныи в лаборатории произвели телепортацию микрочастицы на расстояние 1 метр, а в тексте статьи выясняется, что речь идет об очередном эксперименте по квантовой сцепленности (т.е. речь идет вообще о передаче информации по классическому каналу связи).

    Точно так же и здесь: «Процессы фигня! Софтверная инженерия мертва!», а в статье только предостережения от излишнего расчета на метрики в процессе разработки, и о том, что в программировании большую роль играет экспериментирование.

    Короче!
    Народу не нужны нездоровые сенсации! Народу нужны здоровые сенсации!!!
      +6
      Странно, может мы разные статьи читали?

      Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
      А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…
        +2
        Да нет же. ДеМарко: «Я все еще верю, что есть огромный смысл в инжиниринге ПО. Но это не совсем то, что инжиниринг ПО стал значить.» Просто многие слишком этот инжиниринг переоценивают. От чего автор и предостерегает.
      –1
      > понимание математики проще измерить
      колоссальное заявление!

      > «чем более вы фокусируетесь на контроле, тем более вероятно, что вы работаете на проекте, который в итоге принесет очень мало прибыли»
      Логика потрясает.
      Не делайте дешёвых проектов, делайте проекты, которые приносят много бабла!
      Вот примерно так и на качестве экономят.

      Вообще в любом деле успех это всегда баланс между свободой/творчеством и стандартами/методологиями. Важно найти этот баланс.
        +3
        Не делайте дешёвых проектов, делайте проекты, которые приносят много бабла!

        Неа, скорее «не делайте дорогих проектов, которые приносят мало бабла, а делайте дешевые проекты, которые приносят много бабла, тогда контроль будет не так важен» — классическое ПОДЕПРОДО =)
        • НЛО прилетело и опубликовало эту надпись здесь
          +1
          Если что-то делать сложно, это не значит, что нужно от этого отказываться. Мир не бывает черным или белым. Так и здесь — автор говорит о том, что нельзя переоценивать вклад метрик в достижение успеха, только и всего.

          Также он говорит, что метрики не есть обязательная часть каждого успешного проекта. Но ни слова о том, что отсутсвие метрик — залог успеха. Так что статья не только провокационная, но еще и популистическая в некотором роде.
            0
            >> Но ни слова о том, что отсутсвие метрик — залог успеха.

            «Залога успеха» в разработке ПО вообще нет и быть не может. А уж называть «залогом успеха» отсутствие чего-то — это глупо было бы.
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Зря вы так. Лучше боритесь с эффектами баззвордов, чем с людьми.
                +1
                Люди проявляют энтузиазм в своей области и двигаются вперёд.
                Эти самые паттерны иногда спасают десятки часов работы.

                А процесс (XP, SCRUM) вообще важнее любых технических решений в достижении цели.
                Это я как программист говорю.
                0
                Шаблон затрещал и не выдержал. То ли перевод подкачал, то ли в оригинале слишком много несвязных высказываний.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    А попробуйте «инжиниринг» на русский перевести. «Программотехника» я нашел, но звучит по-советски. Уж лучше «индиниринг».
                      0
                      «Технология программирования», «Технология разработки ПО»
                  0
                  Интересная заметка. Узнаю Демарко :)

                  Peopleware (Человеческий фактор: успешные проекты и команды) написан несколько в другом ключе. Но по сути про то же — книга ставит акцент на организации условий работы команды, а не на инжиниринг.

                  Кстати, считаю что это одна из лучших книг про организацию работы компании. Позитивно написана, и читается легко. Кто не читал и интересуеться темой — рекомендую.
                    0
                    Интересная информация к размышлению. Спасибо

                    Возмущенным: «Не надо воспринимать всё так критично. Надо, как мне кажется, просто подумать над этим.

                    Мысль очень интересная
                      0
                      Спасибо за перевод, сам бы вряд ли наткнулся на оригинал. Мысли и правда очень интересные. Погоня за всеобъемлющим контролем малоэффективна, то факт, надо уметь балансировать на грани контроля и бесконтрольности.
                      Воспринимать статью критично тоже не стоит, все останутся при своем мнении, если вы нашли для себя оптимальную методику разработки, то незачем тут пинать кого-то за полезные размышления и переосмысления спустя годы.
                      –3
                      В избранное.

                      P.S.
                      Офтоп: а что с википедией, лежит она что-то, м?
                        +2
                        Менеджеры! Смиритесь с технократией!

                        Мотивируйте, мотивируйте, мотивируйте! :)

                        Всё что требуется от Вас, это чёткого понимания
                        СВОИХ целей и задач. А в остальном придется положиться
                        на технарей.
                          0
                          Истину говоришь!
                          Вообще неясны цели измерений.
                          Цели, ребята, цели!
                          0
                          ИМХО если без особого контроля раздолбаю дать писать проект, сдача которого принесет зарплату не одному ему, то плакали их денюшки.
                            +1
                            Так не нанимайте раздолбаев на проект. Иначе никакие методологии не помогут.
                              –1
                              Ну да, но увы я не нанимаю ))
                            –2
                            инжиниринг? теперь по диплому я инжинир?
                              +2
                              можно сокращенно — инжир
                              +1
                              Статья ни о чём. Я думаю это уже старческий маразм. Он как и любой другой старик, живёт воспоминаниями про огромные мейнфреймы и разработкой системы управления багажом для даллаского аэропорта.

                              «Множество проектов развивались без всякого контроля, но все-таки в результате получились превосходные продукты — такие, как GoogleEarth или Wikipedia.» Это он о чём? С каких это пор наполнение контента — это и есть программный продукт?

                              «Но это не совсем то, что инжиниринг ПО стал значить.» Надо сказать иначе «Инжиниринг ПО — это не то, что ты думаешь, ДеМарко.»
                                0
                                Читал оригинал, рад, что сделали перевод.
                                Статья ценна не свежестью мыслей, а именно тем, что выбивает табуретку из под фанатов метрик. Часто в дискуссии с таким любителем экселевских таблиц, набитых ROI/KPI/SLOC… всплывает заезженное (и перевранное по эффекту телефона) «нельзя управлять неизмеряемым». Теперь их ткнуть носом в автора и его раскаяние.

                                BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении проектами» постить?
                                  –1
                                  >> BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении
                                  >> проектами» постить?

                                  Все равно уже на главной — все прочитают и оттуда и оттуда :)
                                  На самом деле, чем больше агрессии, тем больше шансов, что «агрессоры» задумаются. И вообще, хорошо, что они это прочитали.
                                  +4
                                  Я думаю, что ДеМарко в чем-то прав. Понравилась мысль, что тотальный контроль нужен только в никудышных проектах — очень верно подмечено, но таких проектов большинство. Имхо, тут надо все-таки глубже смотреть на вопрос.
                                  Откуда возникла потребность в создании методов оценки и контроля хода выполнения проектов, а также PMI и прочих методологий? Просто хотелось сделать разработку ПО сделать контролируемым производственным процессом, т.е. превратить ее в конвейер с понятными для инвесторов параметрами (столько-то вложили — столько-то получили через такой-то срок). Фигня только в том, что писать софт — это не гайки крутить, т.е. данная работа требует творчества (правда, можно и галеру быдлокодеров посадить, если вас не смущает что главным преимуществом продукта будет красивая коробочка и дорогая реклама). Получается, что, работая на проектной основе с фиксированными сроками, требованиями к качеству, бюджетом и ресурсами, менеджеру постоянно приходится бороться с энтропией в проекте: то у клиента «полет мысли» включился, то программисты что-то накосячили и теперь из-за переделок нужно думать, как бы не выйти за ограничения по времени и срокам, и как багу выдать за фичу. Другой вариант — превратить разработку в постоянный и непрерывный процесс с короткими циклами, и в конце каждого цикла иметь работающий продукт, но с неполным функционалом (собственно, это и есть подход гибких методологий). Венчурные проекты — это вообще отдельная история, потому что они действительно управляются по-другому, так что не стоит смешивать их с довольно нудным бизнесом заказной разработки ПО.
                                  Есть хорошая статья Алистера Коуберна «Каждому проекту своя методология». На мой взгляд, правильный подход: каждый метод управления — это способ «подстелить себе соломку» в определенном месте, поэтому если чувствуешь, что где-то будет прокол — используй соответствующий метод, чтобы снизить риски, если нет, то не трать время и ресурсы. А если всего боишься, то PM'ом тебе не быть.
                                    –1
                                    Все верно вы написали, даже добавить нечего.
                                    –2
                                    Вообще-то экстремизм — зло.

                                    Всё просчитать нельзя и вообще без расчетов тоже нельзя.

                                    Надо найти грамотный баланс.

                                    А то, что автор не знает, как измерить этику — его проблема. Кто-то это знает. Даже один ученый психологии изобрел модель, по которой все разнообразные и разномастные методики и классификации можно свести в примерно одну систему координат. См. понятие «Пентабазис». medbookaide.ru/books/fold1002/book1226/content.php

                                    В-общем и целом это раскидка объекта по осям:
                                    — пространство
                                    — время
                                    — энергия
                                    — информация
                                    И сбор всего в пятой точке — субстрате, который интегрирует все четыре и является пятым элементом.

                                    Кароче «5 элемент» не на пустом месте сняли :)

                                    До Менделеева тоже думали, что химия — это что-то такое!

                                    Кароче гуру метнулся из крайне-левого положения в крайне-правое, что тоже не есть гут.
                                      0
                                      все правильно: для проектов типовых, посчитанных нужны метрики и контроль. Го заниматься ими неинтересно ни с профессиональной ни с финансовой точки зрения. А для инновационных вещей, обещающих сверхприбыль контроль скорее губителен.
                                      Ну и все собственно.
                                        0
                                        Ну очень режет глаз:
                                        " натуральной науки " — natural science, что переводится как «естественнонаучные дисциплины».
                                          0
                                          а мне кажется что у демарко последнее время не клеются проекты… из-за жосткого контроля… вот он и пришёл к такому выводу…
                                          я его мнение на носу себе никогда не зарублю… тока приму к сведению… не более…
                                            0
                                            кстати книги Тома очень неплохие. следовать им как заветам ильича кончено не стоит, но структурируют мысли они хорошо.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое