Разработка ПО: 1. Индустрия на стероидах
Битва закончена, люди много говорят о том, какой методикой они руководствовались, когда принимали свои решения, но вообще-то всегда бывает чертовски много того, к чему приходят на ощупь.
Адмирал Ф.Д.Флетчер
Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.
Кроме этого, как и любого другого разработчика, меня несколько беспокоит перспектива отрасли на ближайший десяток лет, так как это связано с моими профессиональными перспективами. И, просто как человеку, хочется испытать свое понимание вещей на прочность, понять насколько локален опыт и выводы из него.
Речь пойдет о достаточно простых вещах, но я неоднократно замечал, что в научных исследованиях прогресс или тупик возникает, когда простая и очевидная вещь оказывается не тем, чем она кажется, или дефект в программе внезапно обнаруживается в модуле, который “не может” содержать ошибку.
(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)
1. Индустрия на стероидах
Сложно отрицать, но на программное обеспечение вот уже уже тридцать с лишним лет влияет одновременно и болезнь и благословение роста рынка. Когда рынок растет не нужно быть эффективным. Когда ты приносишь туземцам зеркальца и колокольчики, их мало волнует качество, они в них не разбираются, но они это хотят.
Да, случались тревожные звонки вроде кризиса 2000-х, когда распад самых чудовищно неэффективных высокотехнологичных компаний и сгорание инвестиций в перегретый рынок пошатнули экономику. Внезапно выяснилось, что IT компаниям было бы неплохо приносить прибыль хотя бы в отдаленной перспективе. Качество продуктов и их полезность немного выросли, случился очередной приток потребителей и инвестиций. И эта мысль опять ушла на второй план.
Если я работаю технологом или методологом при производстве зеркалец и колокольчиков для папуасов, то для меня нет смысла быть эффективным. Фактор роста подтвердит почти любые мои решения как правильные, а хорошая политика продаж и вовсе замнет то, что сам продукт является проблемным. Зеркальца могут быть расколотыми, почти ничего не отражать и не звенеть, но они будут продаваться, особенно хорошо они пойдут у тех, кто не видел других зеркал и если начал действовать фактор “хочу как у него”. Ему подвержены не только отдельные люди, Хотим модернизироваться, потому что все внедряют ERP или CRM, или открывать интернет-направление только потому, что все это делают. Почему-то такое поведение не кажется мне удивительным.
За это же время возникло большое количество методик разработки программного обеспечения и его оценки.
В теории, благодаря им из хаоса возникает порядок, весь продукт красиво раскладывается на характеристики, функционал, архитектурные особенности и т.д. А создание разбивается на вполне конечное количество процессов, подающихся унификации и измерению. Классно, красиво, и похоже на точную науку.
У меня есть два градусника, один старый ртутный, другой новый электронный. Я хочу узнать температуру своего тела, чтобы понять, не заболеваю ли я. Я беру старый градусник и он через 5 минут показывает мне своим ртутным столбиком что-то вроде 37,2 градуса. Потом беру новый, красивый и безопасный градусник, жму кнопочку, он пикает и через минуту показывает мне 36,638 градуса. Какой из градусников вы отправите на свалку?
Большинство отправит старый, потому что он медленно работает, выглядит замызганным и по нему можно узнать меньше цифр после запятой, что не имеет никакого отношения к точности измерения и, соответственно, прогноза заболею ли я. Да и в конце концов он стоил больше денег, выбрасывать жаль.
Подобная точность — лишь иллюзия, ориентированная на увеличения доверия. Методики разработки и оценки ПО хотят выглядеть научными, потому что это делает их солиднее и, это можно дороже продать. Время специалиста, который их использует, тоже начинает оцениваться дороже.
Да, это дает понимание того, как увеличить бюджеты и объем рабочих мест, но какое это отношение имеет к заявленным целям любой методологии, а именно: Уменьшение объема и стоимости работы, необходимого для создания определенного программного продукта или изменении существующего до определенного состояния.
Что такое “состояние продукта” — это отдельный вопрос и я предпочту пока его не затрагивать, так как это касается в первую очередь требований и методик измерения к которым есть много вопросов.
Целей много, и эта формулировка при хотя бы небольшом расширении, так или иначе покажется противоречивой для заказчика, разработчика или руководителя, находящегося между ними.
Если я разработчик, то хочу от методики помощи в том, чтобы делать мою работу как можно лучше. Как можно реже повторять код. Как можно реже пускать целые модули под нож и переписку с нуля. Быть уверенным, что определенная часть кода будет работать корректно при большинстве условий. Быстро искать дефекты. Быстро подключать к процессу разработки нового сотрудника.
С точки зрения бизнеса важно другое — извлечение прибыли из разницы в стоимости работ и бюджета проекта. Предсказуемость процесса и расходов. Юридическая обтекаемость требований к продукту. Привязка к этапам финансирования и календарным периодам. Формирование зависимости клиента от поддержки продукта и выхода новых версий.
Каждый из списков можно продолжить по своему желанию. Но это две разные планеты, кое-где цели совпадают, часто противоречат друг-другу, часто находятся в разных измерениях. Адаптировать методику тестирования продукта к квартальным периодам?! А это, вообще, как?
Иногда все сводится к нахождению компромисса. Я хочу иметь качественный код без дефектов, но хочу сдать проект в обозначенный срок. Ни одна из методик не разрешит это противоречие, оптимум зависит от конкретного случая. Наверное не получится сдать продукт, содержащий критические дефекты, какие бы сроки не стояли. И не получится потратить полдесятка лет на математическое обоснование корректности кода. (хотя, как ни странно бывает и так и так). Или, как было отмечено одним хорошим специалистом, общая задача существования компьютера — это упрощение повторяемых и рутинных операций. С точки зрения бизнеса, если они приносят ему прибыль, они выгодны.
Основная проблем в том, что претендуя на покрытие как можно больше целей все существующие методики прошли крайне мягкую проверку на эффективность. Наше ПО как-то работает и продается? Потом мы смогли собрать новую версию и тоже как-то ее продать? Наверное, у нас прекрасные методики, раз мы способны на столь значимые достижения.
Я открываю браузер и предполагается, что существует большое количество компаний, которые сформировали лицо того, что я в нем вижу. Неа, на самом деле это лицо формирует то, что сотня человек открыли браузер в первый раз пока вы читали этот абзац, остальное относится к деталям.
Постепенно и неравномерно для разных областей, но рынок ПО станет ближе к насыщению и рваться начнет там, где тонко. Систематические провалы определенных типов проектов скорее всего будут приводить к провалу и смене целых парадигм. Наверное, самые крупные из них касаются представлений об отрасли и управлении проектами внутри нее.
В следующих заметках я хочу рассмотреть, откуда к нам пришли методики и особенности управления и разобраться, что с ними не так.
Разработка ПО: 2. Наследство
В предыдущей заметке был сделан вывод, что индустрия разработки ПО молода и подвержена влиянию фактора роста настолько, что рано говорить об апробированности и применимости каких-либо методик в долгосрочной перспективе, а их выбор диктуется причинами часто отличающимися от заявляемых.
Если искать аналогии в плане управления, то весьма схожем с производством ПО может показаться строительство. Мало того, менеджеров по разработке ПО нередко знакомят с управлением проектированием и строительством зданий и инженерных сооружений.
Однако, происходит некоторая подмена причин этого знакомства. Да, эта область в чем-то похожа, в первую очередь наличием понятий “требования”, “проектирование”, “проект”, “строительство” (construction), “контроль качества”, “человеко-часы”, “работы”, “сроки”, а сам процесс развивается от экономической потребности и идеи до некого конечного продукта. Но основная причина того, что строительство является хорошей аналогией в том, что это наглядная аналогия.
(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)
Вот так выглядят требования, смотрите они описывают то, что мы хотим получить и таким-то образом обосновываются экономически. Вот так идут стадии проектирования, детализуя проект от общего видения в десятке штрихов и многоугольника на генплане до макета, а потом и до каждого подоконника и толщины каждого прута в армировочной сетке. Все это стоит вот таких-то денег и сметчик все достаточно точно посчитает бюджет с вилками на экономию или улучшение материалов. Вот у нас разные специалисты, каждый из которых выполняет конкретный вид работ. Вот мы четко разнесли все на задачи и этапы, и так выглядят связанные задачи а тут мы можем посчитать время специалистов. Это делает такая организация, это — другая. Тут присутствуют риски, например превышения срока и выхода за строительный сезон, мы берем калькулятор и их считаем. И так далее.
Знаете какое самое сильное впечатление от процесса проектирования и строительства здания с точки зрения программиста? Все участники удивительно четко понимают, что они делают и им крайне сложно допустить фатальные ошибки. Кроме того уже на стадии архитектурного проекта результат определен лишь с незначительными вариациями. Это классический водопад.
Но строительство относится к материальному производству и это означает, что тиражирование ограниченно возможно только на уровне апробированных сочетаний технико-экономических показателей и проектирования, которое занимает не очень большие 1%-15% от стоимости (и гораздо меньший процент от объема в человеко-часах) работ, а остальная часть процесса создания отличается в корне.
Цели подобного материального производства и требования к продукту относительно просто задать, так как измерение материального мира достаточно устоявшаяся область. 8 этажей означает 8 этажей за очень редкими исключениями, нагрузка в 150 килограмм на метр может увеличиться до предельных 300 килограмм или среднеэксплуатационных 50 но не превратиться в десять тон на километр.
Когда люди строят здание они хорошо понимают, что, каким способом и с какими затратами они хотят получить. Хотя бы в силу того, что они занимаются этим не первый десяток тысяч лет.
Область строительства и проектирования зданий является очень жестко регламентированной, как только ее масштабы становятся больше, нежели благоустройство дачного домика. Нормативных документов, регламентирующих реконструкцию хрущевки в разы больше, чем создание крупной банковской системы и они куда более конкретные. В них недвусмысленно говорится как делать можно и как нельзя.
Пожалуй, ближе всего могут оказаться уникальные инженерные конструкции вроде мостов, аэропортов или электростанций, но если присмотреться к жизненному циклу любого строительного проекта оказывается, что с жизненным циклом разработки ПО они лишь формально пересекаются в нескольких пунктах, содержание которых различается разительно.
Мало похоже и то, как влияет на процесс бюджет. Если у нас оказывается маленький санузел или низкий потолок, это вовсе не означает что архитектор идиот или у строителя оторвался кусок рулетки. Просто это низкобюджетный проект, так как потенциальный клиент не готов платить за большее. (Часто ли вам попадались жилые здания с санузлами, в которые нельзя войти или потолком с высотой полтора метра? А сервер, который не выдержал нагрузки?).
И еще один важный момент, часто ли архитектор проектирует или строитель строит здание больше загородного домика, в котором будет жить сам? Почти все дома строят по заказу.
Я считаю, что разработка ПО уникальная область и говорить о «схожих областях» человеческой деятельности можно лишь только лишь в целях упрощения понимания некоторых терминов, связанных со стадиями разработки и управления ей. Любое более детальное сравнение выявит скорее массу принципиальных различий, нежели возможность для проведения параллелей.
Тем не менее методики управления материальным производством, будь то строительство или создание автомобилей просочились и продолжают просачиваться в область проектирования ПО.
В следующей заметке я хочу рассмотреть, что становится основным камнем преткновения при переносе существующих каскадных методик в область разработки и оценки ПО
Разработка ПО: 3. Теплое и мягкое
В предыдущей заметке я сделал вывод о том, что разработка ПО настолько уникальная область что говорить о «схожих областях» человеческой деятельности можно лишь только лишь в целях упрощения понимания некоторых терминов, связанных со стадиями разработки и управления ей.
Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.
Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?
Нет, подождите, а как же декомпозиция и формализация бизнес-процессов, без которых невозможно было бы автоматизировать, ну тот же процесс строительного проектирования. А как же планирование работ, без которых никак не получилось бы организованно создать тысячу таблиц, логических структур и интерфейсов для подобного проекта?
(в качестве иллюстрации лицо типичной универсальной методики авторства RuxxSilver, которое на первый взгляд выглядит весьма привлекательно и правдоподобно)
Пока на горизонте мы продолжаем видеть материальное производство, и воспроизводим взаимосвязи сущностей, которые его составляют, все это крайне важно, как видеть пейзаж, рисуя его на этюднике. IDEF, UML и взвод консультантов и бизнес-аналитиков нам в помощь. Как только пейзаж исчезает в дело вступают совершенно другие принципы. Крупные проекты автоматизации производства проваливаются не потому, что совсем уж не получилось смоделировать объект автоматизации. Сложно прозевать факт работы доменной печи или невыхода на работу сотрудников отдела. Или не понять как это отразить в модели и что это за собой влечет.
Проваливаются и вылетают из бюджета они потому, что софт слишком часто взбрыкивал и отвергал детали проекта. Ну не влезла в систему разузловка из полумиллиона деталей, а все строилось на предположении, что влезет. Написание логики возврата выписанной квитанции внезапно, в силу ограничений исходной системы, заняло не 10 человеко-часов а 10.000. Более 19 джоинов в запросе к базе рушили всю систему отчетов, а сторонний модуль видит только три гигабайта памяти, а надо четыре.
Отражая реальный мир в программном продукте мы по сути создаем химеру и ее составные части живут по разным законам, управляются по разным законам и могут начать отторгать друг-друга в непредсказуемый момент. Разработка большой универсальной базы данных — это совершенно иное, нежели создание в ней описания связей между деталями автомобиля. Увы, многие менеджеры путают это чаще, чем хотелось бы.
Проблему химеры каждая конкретная организация с ее конкретными продуктами и подходом к работе решает по своему. Создаются весьма сложные методики, у которых есть одно общее свойство — они перестают работать когда переступают порог компании-прародителя.
Скажите, только честно, кто успешно использует RUP, так, чтобы это было больше нежели набор общих принципов, помещающихся на листке бумаги? У меня на полке лежит книжка по RUP и еще несколько в электронном виде. К сожалению, там не сказано, кто так делает. Интернет тоже не очень помог мне ответить на этот вопрос.
Пересекая порог IBM он сдувается как шарик, теряя все, что отличает его от куда более неформальных методик. В формализованном проекте, который сильно связан с реальным миром, он почти всегда начинает проигрывать методикам, которые превращают хотя бы часть разработки в полностью формализованный каскад и не привязаны к весьма конкретным программным продуктам, их сильным и слабым сторонам.
Универсальность — это не всегда хорошо, но всегда хорошо звучит.
Если мы хотим выдрессировать собаку мы будем поступать одним образом. Если хотим доехать куда-то на автомобиле — другим. И не стоит придумывать общие принципы решения этих двух задач только потому, что и в первом и втором случае кто-то чем-то управляет.
Когда мы создаем программный продукт, мы имеем дело в первую очередь с абстрактными сущностями, которые его составляют, внешними интерфейсами и программно-аппаратной средой в которой он существует.
Когда мы моделируем реальный мир мы имеем дело с его объектами, их измеримыми свойствами и их взаимоотношениями.
Программный продукт может предполагать что в него будут заложена модель определенной части реального мира. Реальный мир, в свою очередь, может быть описан так, чтобы его модель было проще занести в программу.
Когда мы считаем это тождественным, то мы начинаем путать теплое и мягкое.
Хотя бы в силу конфликта, который затрагивает саму природу информационных технологий. Компьютер и его программы — это дитя вычислительных систем, (особенно статобработки) и копировального аппарата.
Для примера: если мы хотим заняться классификацией и управлением камнями, то нам придется создать класс камень или таблицу в базе данных, описывающую камни.
В наименее затратном виде камни будут унифицированы: камень №1, камень №2, камень №3… В реальном мире не существует идентичных камней. Чтобы описать все камни нужно их полностью воспроизвести. Мы можем ввести в нашу систему множества камней, сгруппированных по весу, и с ее точки зрения унифицированность камней сильно уменьшится, нам будет проще определить к какой из групп относится конкретный камень в реальном мире. Для каких-то задач, информация о том, влезет ли эта группа камней в грузовик, может быть полезной. Вопрос в том, какая степень детализации окажется полезной и насколько эта польза будет сочетаться с затратами.
Чем более тиражурем и неспецифичен объект, тем проще обрабатывать информацию о нем. И тем меньше нужно работы, чтобы создать ПО, которое ее обрабатывает и преобразовывает.
И если мы хотим действительно претендовать на универсальные методики, то скорее всего нужно искать их основные принципы, отталкиваясь от теории множеств. Сейчас любые подобные попытки образуют столь сложный аппарат, что он находит лишь микроскопическое применение в оценке рисков и проектах весьма специфичных экспертных систем. На практике они смогут использоваться в виде разве что “капризного” черного ящика, мнение которого учитывается, когда авторитетность всех остальных мнений под сомнением.
Резюмируя: есть разные цели, и в соответствии с ними есть некоторые принципы: как писать неплохое ПО, как создавать модели реального мира и как извлекать экономическую прибыль из результата. Если кто-то претендует на смешение этих вещей и универсальные методики, то это относится к зоне экономических целей, потому что “универсальный” звучит круто, и продается лучше, чем “не универсальный”.
Универсальность невозможна и в плане применимости для различных организаций и проектов. Чем выше степень такой портируемости, тем больше методика похожа на компактный кодекс расплывчатых рекомендаций.
Плохие новости: вам самим придется определяться с целями, искать компромиссы, оптимумы, отвечать на коварные вопросы вроде “нужен ли нам хороший код”. Вероятность возникновения красивого водопадного процесса работ, как в строительстве, невозможен в обозримом будующем.
По мере снижения роста рынка и увеличения конкуренции внутри отдельных подсекторов все большую роль будут играть личные решения конкретных людей с личной ответственностью за них. Менеджмент разработки ПО не отомрет, но скорее отомрет или профессионально вырастет большинство существующих IT-менеджеров с их подходами. Остальные решат что отрасль стала бесперспективной для них в плане легкой карьеры и денег и исчезнут. Вряд ли мы что-то потеряем от этого.
И если молодой руководитель IT проекта или руководитель группы разработки сейчас видится нам действительно молодым человек в возрасте от 15 до 30 лет, то молодой архитектор (который проектирует здания) попадает скорее в возрастные рамки 30-45 лет и открыв альбом “20 молодых архитекторов” первая ваша мысль будет: “А кто все эти старперы?!”. Просто потому что 5-7 лет обучения и 10 лет практики это достаточно мало даже для того, чтобы хорошо спроектировать даже хрущевку.