Коллективное воображение в ИТ: как менялись методологии разработки и кому они нужны
Лид-архитектор OpenShift из британского Barclays Айэн Миллопубликовал свои рассуждения о развитии методологий программирования, свидетелем которому он стал в ходе 20-летней карьеры в программировании. Его описание основано на концепции коллективного воображения из книги «Sapiens: Краткая история человечества» Юваля Ноя Харари. Она объясняет существование религий, демократии и многих других вещей, в основе которых лежат взаимоотношения мужду людьми. Публикуем сокращённый перевод.
Когда я начал карьеру в программировании 20 лет назад, «богом» была каскадная модель. Мы должны быи писать длинные спецификации, отполированные до последнего миллиметра, вплоть до каждого класса в Java. После того, как спецификации получал и утверждал клиент, начиналась разработка, по завершении которой клиент платил деньги. Тогда всё было проще — и все были счастливы.
Правда, заказчики иногда жаловались, что спецификации не соответствуют доставке, а продукт не всегда отвечал спецификации из-за того, что «что-то» изменялось во время работы над проектом. Иными словами, процесс Waterfall был результатом коллективного воображения, который давал достаточно стабильности и согласованности для сотрудничества, выпуска какого-то продукта и получения денег.
Компания вскоре закрылась, но не стоит делать никаких выводов из этого.
Коллективное воображение: стартапы 2000-х
Я устроился в другую компанию, которая смогла занять свою нишу и имела кучу работы. Я был сотрудником номер 39. В компании не было никакой каскадной методологии. Стоит сказать, что с точки зрения методологии в компании в принципе ничего не было. Спецификации утверждали в ходе телефонных звонков, дизайн, прототип и образец ПО были неотличимы друг от друга. Это был хаос, который по любом направлению протеворичил всему, чему меня учили. Работы было больше, чем компания могла «переварить», и все соглашались с таким положением вещей.
Секрет в том, что мой работодатель был достаточно маленьким, чтобы не прибегать к коллективному воображению. Отношения и факты можно было хранить в головах, а в случае, если была нужна помощь, можно было позвонить в нужный кабинет. Общий настрой был примерно таким, как на иллюстрации:
Впрочем, коллективное воображение работало — просто это не озвучивалось:
у нас никогда не будет сформулированной миссии;
нам не нужен HR или внутренние коммуникации, у нас есть паб (сложная задача для сотрудников с семьями);
мы нанимаем только лучших.
Как только компания стала немного больше, клиенты начали спрашивать о принятой методологии. Показалось не очень уместным отвечать «мы просто пишем код».
Оказалось, что существует «быстрая разработка приложений» (RAD) с акценом на прототипировании. Клиентам говорили, что в компании используют RAD, и они были довольны.
Затем компания выросла вдвое и переехала в большой многоэтажный офис. Прокричать вопрос через комнату больше не получалось. Команды увеличились, и везде стали появляться «менеджеры проектов» — и говорили о спецификациях и обязательных собраниях. Мы попробовали переписать всю платформу заново и провалили эту задачу.
Да, мы снова вернулись к каскадной модели, но на этот раз рабочие циклы были меньше и быстрее, к чему добавлялись те же проблемы изменения требований со стороны клиента, как и раньше. Был ли это «Водопад» на самом деле? Мы не знали.
Ещё один продукт воображения: Agile
Я начал слышать слово Agile в 2003 году. Иногда я спрашивал об этом людей, которые утверждали, что знают, о чём речь, — и их ответ в большинстве случаев очень быстро становился бессвязным. А те, кто действительно разбирался в проблеме, казалось, неспособны реально справляться с настоящим давлением со стороны проблемных клиентов, расписания и активных скептиков. В целом, мы продолжали работу со спецификациями, с некоторыми вкраплениями аджайл-терминологии. Собрания теперь называли «скрамы», но в остальном всё было как и прежде.
Как коллективное воображение это работало, потому что позволяло держать на расстоянии клиентов и проектных менеджеров, пока программисты трудились над созданием ПО.
И тогда, когда компания выросла до 700 человек, и во время работы в корпорации с 100 тысячами сотрудников, ситуация развивается примерно одинаково: нужно найти нужное заклинание для того, чтобы убить сидящих перед вами людей.
Вы не верите?
Я не хочу разбивать никакую из этих парадигм, потому что в этом нет никакого смысла. Если бы методологии разработки ПО не существовали, их нужно было бы выдумать — как ещё организовать эффективную совместную работу? Все эти условности нужны, чтобы эффективно работать в средних и крупных компаниях. Неслучайно парадигма Agile в чём-то имеют полурелигиозное влияние на команды.
Часто при обсуждении аджайла за пределами маленькой команды ощущается напряжённость. Когда я вижу нарисованный кем-то неизвестным мотивационный постер, который советует «избавиться от блоков», тогда как эти блоки внешние и необсуждаемые, что ещё мне делать, кроме как рассмеяться?
Как работать в agile-методологии, когда эти самые неконтролируемые блоки появляются на каждом шагу? Инфраструктура, аудит, безопасность, финансовое планирование — всё это препятствует возможности быстро создавать значимые итерации продукта. Мы говорим о таком «квадрате безысходности»:
Когда я вижу представляющие аджайл диаграммы наподобие этой, я могу реагировать на них лишь чёрным юмором в обществе коллег, и мы становимся похожими на школьников с задних парт.
Когда в небольшой эффективной команде «выветриваются» символы аджайла, остаются (если команда и правда хороша) взаимодоверие, открытость, ясная структура (формальная или неформальная), в которой можно достичь согласия и решений, а сотрудничество — продуктивно. Google надавно пришёл к таким же выводам (краткое описание доступно здесь, а более подробное — здесь).
Почему не говорить о вещах открыто?
Может показаться, что ответ — придумать методологию, которая лучше. Будто таких попыток не было.
Создать полезную методологию разработки ПО нелегко. Сложность состоит не в её определении, а в том, чтобы убедить других следовать ей. Значительная чать истории разработки ПО крутится вокруг вопроса как убедить инженеров верить в конкретные истории про эффективность обязательных собраний, очки за пользовательскую историю, график выполнения работ и подготовку списка требований к ПО. Однако в случае внедрения методологии дают компаниям большую силу, так как позволяют распределённым командам взаимодействовать и работать, создавая продукт. Представьте, как сложно было бы создать Microsoft, Google или IBM, если бы обсуждать можно было только конкретные технические вопросы (автор перефразировал абзац из книги Sapiens — dev.by).
Нужны ли миру новые методологии? Кажется, многие весьма умные люди уже задавались этим вопросом.
Принятие
Lean, Agile, Waterfall — неважно. Факт в том, что для взаимодействия в больших командах нужна общая методология. Ни одна из существующих не является злом, поэтому речь не о том, выбрать ли коммунизм вместо фашизма или наоборот. Любая из них не будет отражать реальность, и каждый, кто ожидает увидеть идеал, явно будет разочарован. И следите за наличием непроговоренных результатов коллективного воображения. Жизнь наполнена ими: например, что ваше мнение важно.
С++, несмотря на свой солидный возраст, остается одним из основных языков программирования, который применется очень широко: от разработки ПО до создания игр. В сети много ресурсов, которые помогут освоить этот язык. Советуем обратить внимаение на подборку команды Digitaldefynd, котрую мы дополнили. В ней как платные, так и бесплатные ресурсы для людей с разным уровнем подготовки и знаний С++.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.