Эта статья про историю SDLC — System (Software) Development Life Cycle. Он принадлежит далёкому прошлому, но на него тем не менее продолжают ссылаться на конференциях и пытаются использовать.

Итак, в далеком 1981 году менеджеры задумались о регламенте для ведения ИТ-проектов, ведь софта требовалось всё больше, его разработка перестала быть частью научных исследований, а становилась частью развития бизнеса и даже развития государства. А это значит, что необходима методика, на которую, если что-то пошло не так, можно кивнуть «мы всё делали правильно». Если кто не знает, то основное назначение именно в этом, а вовсе не в том, чтобы успешно делать проекты.

Менеджеры посмотрели, что пишут специалисты, увидели водопад Ройса (1970) — простую и понятную схему. И наплевать, что сам Ройс в сопровождающей статье писал, что так работать не будет.

Нынешний дефицитный рынок персонала в ИТ требует, чтобы забота и гуманистическое отношение к сотрудникам не были простой декларацией, а подтверждались реальной практикой. Чтобы они работали даже в тех случаях, когда это вступает в конфликт с выполнением проектных обязательств. Потому что массовое увольнение в напряжённый период проекта гораздо опаснее, чем разговор об изменении обязательств с заказчиком. Да и если команда уволится после завершения острой фазы, которую она пройдёт из чувства ответственности, это тоже создаст много проблем для компании.

К сожалению, здесь лежат грабли, на которые часто наступают при найме менеджеров из школы MBA и других аналогичных подходов. Дело в том, что эта школа формировалась в эпоху профицитного рынка персонала, когда на каждую вакансию выстраивалась длинная очередь желающих. И эта ситуация заставляла людей ценить своё рабочее место, побуждала работать напряжённо, если этого требуют интересы проекта. Конфликт между интересами работы, семьи или другими личными интересами часто решался в пользу работы. И когда-то это было сформулировано открыто: вы на работе — работайте, делайте, что требуется. Но потом выяснилось, что если компания не просто зарабатывает деньги, а работает на великую миссию, если она заботится о своих сотрудниках, относится к ним по-человечески, то сотрудники работают гораздо лучше, потому что вовлечены в процесс. И дальше начался процесс оптимизации: как бы ограничиться только декларациями миссии, заботы и человеческого отношения, не требующими затрат, но реально работать по-старому, ставя зарабатывание денег и производственные интересы во главу угла.

В ходе обсуждений докладов на Analyst Days возник вопрос о связи Domain-driven design (DDD) с объектно-ориентированным подходом (ООП): оказывается, для большинства она вовсе не так очевидна, как мне представлялось. Подробнее погружаясь в это обсуждение, я понял, что для современной разработки их общность действительно не очевидна, а практики DDD можно применять, не связывая с ООП. Я думаю, что подробное рассмотрение этого вопроса будет полезно для получения комплексного представления и понимания DDD, что сделает его применение эффективнее.

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

Как ответ на это родились Agile-методы, которые организовывают разработку принципиально иным образом: короткими итерациями, с регулярным получением обратной связи от заказчика и пользователей, для чего необходимо им представлять работоспособную версию продукта, которую они смогут оценить.

Естественно, изменение организации проекта принципиально изменило работу с требованиями и проектирование системы. Если мы признаем высокую неопределенность проекта, влекущую активное изменение требований, тщательная работа с ними теряет смысл, превращается в лишнюю работу. И были предложены легкие форматы описания систем, а также форматы коммуникаций, которые позволили их создавать.

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

Решение — подход DDD, Domain Driven Design, было предложено Эриком Эвансом в 2003. Но прежде, чем о нем говорить, необходимо немного углубиться в историю развития разработки софта как такового.

Многие методологии требуют сначала описать требования к системе как черному ящику и лишь затем переходить к проектированию и построению моделей. Способам такого описания посвящена инженерия требований. Однако, это присуще и Agile-методам, ведь User Story тоже описывает систему как черный ящик. Целью такого подхода была гарантия, что разработанная система будет пригодна для использования, внедрение пройдет гладко. Проблема в том, что так — не работает. А значит, нет смысла чересчур углубляться в требования, а стоит быстро переходить к моделям системы, которые можно строить по-разному.

Чтобы найти способ улучшить процессы и процедуры в компании, полезно смотреть на чужой управленческий опыт: на чём строятся решения, какие паттерны и концепты можно попробовать у себя и уместен ли контекст. Чем шире кругозор, тем из большего числа подходов можно выбрать подходящее решение. 

Я Максим Цепков, IT-архитектор, бизнес-аналитик, эксперт по миру Agile, бирюзовых организаций и спиральной динамике. Помимо основной работы, я затаскиваю знания из других отраслей в IT и смотрю, что в них полезного для управления проектами. Потом делюсь опытом на конференциях. Сегодня расскажу о Социократии 3.0 — фреймворке с философскими корнями, который помогает настроить гибкие процессы внутри IT-проекта и команды, повысить производительность и задать фокус правильным ценностям.

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

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

В прошлой статье мы говорили о том, что основой хорошей интеграции является админка, которая позволяет быстро решать инциденты. Сегодня мы поговорим, как реализовать интеграцию, чтобы получить ее устойчивую работу — толерантность к потере сообщений, падению процессов и ошибкам обработки.

Для решения этих проблем устойчивости работы мы можем использовать шаблон «Идемпотентные операции». Для интеграции это значит, что если нам неизвестен результат выполнения операции, то мы можем повторно ее выполнять, повторно отправив то же самое сообщение, — и это не приведет к дублированию действий, даже если предыдущая операция была выполнена полностью или частично.

Мою предыдущую статью «История IT. Когда компьютеры были большими…» мы завершили концом 80-х, когда произошло два знаменательных события. Во-первых, появился ООП и объектный язык C++. А во-вторых, появились персоналки, и это принципиально изменило задачи, стоящие перед IT-разработкой.

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

Главное изменение в том, что персоналки сделали компьютеры доступными небольшим компаниям. Потребовались системы автоматизации бизнес-процессов, которые сильно отличаются в разных компаниях. Типовую систему сделать сложно: сейчас такие системы уже есть, например, 1C, а в то время их не существовало. Как раз эту задачу помог решить ООП. Эту часть истории развития IT и концепций, которые тогда появились и до сих пор используются, я расскажу в этой статье.

Некоторое время назад меня попросили рассказать или дать ссылки на историю развития IT-разработки, в которой была бы видна внутренняя логика развития, а не просто факты и события. Казалось бы, об этом должны быть книги или обзорные курсы, ведь логика развития IT-разработки в значительной мере овеществлена в логике развития языков программирования, и только в последние лет двадцать к этому добавилась логика развития фреймворков, платформ и концептуальных подходов к проектированию. Но я не нашел хороших источников.

Поэтому появился авторский текст, написанный, преимущественно, на основе моих собственных представлений. Он проверен по материалам википедии – там есть общий таймлайн в серии статей (этот откроется на 1957, наверху можно выбрать конкретный год), есть обзорная английская статья, которая, на мой взгляд, не раскрывает логику развития, а говорит о фактах, и есть статьи, посвященные отдельным языкам. Статьи по отдельным языкам как раз включают не только его описание, но и логику создания и развития языка. Но – изолированно от других, и простая сборка не даст целостной картины, а наоборот, будет содержать противоречивые фрагменты. Зато эти статьи позволяют проверить, насколько твои представления соответствуют реальной истории, и поправить их – что я и проделал.

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