Диасофт

ЭФФЕКТИВНОЕ ПРОИЗВОДСТВО

ПРОГРАММНЫХ ПРОДУКТОВ

Введение

За последние тридцать лет многократно выросла сложность архитектуры программных продуктов. Если раньше с задачами бизнеса мог справиться достаточно простой файл-серверный продукт, то сегодня необходимы многокомпонентные микросервисные решения.
Безусловно, производство таких многосоставных решений — сложный механизм, состоящий из многих элементов:
  • сотни, а иногда и тысячи команд разработки;
  • множество одновременно разрабатываемых и сопровождаемых программных продуктов;
  • десятки одновременно используемых языков программирования и сред разработки;
  • сотни вспомогательных программных продуктов (инструментов), обеспечивающих процессы разработки и выпуска программных продуктов;
  • тысячи серверов для разработки, тестирования и выпуска продуктов.
Меня часто спрашивают: какой элемент производства самый важный? Какую технологию использовать? И я всегда отвечаю — в производстве программных продуктов нет «серебряной пули». Все элементы одинаково важны.
В этой книге я поделюсь опытом создания эффективного производства программных продуктов. Моя цель — не просто рассказать об опробованных и эффективных практиках организации производства, но и научить читателя осознанно выбирать и применять их.
Книга не является пересказом прошедших событий, а все примеры даны только для справки. Она будет интересна как компаниям, разворачивающим производство программных продуктов для собственных нужд, так и тем, кто разрабатывает их на заказ.

Проблематика

Основной мировой тренд в бизнесе — цифровая трансформация, именно она определяет высокую потребность организаций в создании, развитии и управлении цифровыми продуктами и услугами. Отсутствие готовых решений, закрывающих эту потребность, заставляет компании создавать собственные отделы разработки программных продуктов. А поскольку это дело не является для них основным бизнесом, занимаются они им не профессионально, другими словами, неэффективно. Наивно предполагать и ожидать, будто достаточно просто набрать программистов и собрать их в команды, а они самоорганизуются и станут работать максимально результативно и производительно. Такие представления приводят к тому, что в крупных организациях отделы разработки разрастаются до нескольких тысяч, а то и десятков тысяч сотрудников. Пионеры цифровой трансформации потратили и продолжают тратить колоссальные средства на её реализацию. Однако большинство компаний в России не в силах вкладывать столь большие средства в свою цифровую трансформацию.
Приведу основные признаки неэффективного производства программных продуктов. Если ваша эмоциональная оценка ситуации пересекается хотя бы с одним из приведённых признаков, значит, вам есть над чем поработать.
  • Требования бизнеса реализуются долго — простые, казалось бы, задачи реализуются в течение многих месяцев, а то и кварталов. Реализованную функциональность при сдаче бизнесу приходится дорабатывать. В нашем быстро меняющемся мире к моменту ввода продукции в эксплуатацию требования сильно меняются, так что порой потребность в том или ином функционале полностью отпадает.
  • Требования бизнеса реализуются дорого — оценка задач превышает все разумные пределы.
  • Не хватает разработчиков — и это вынуждает постоянно нанимать новых людей, так как вал задач от бизнеса непрерывно растёт, а штатные специалисты просто не успевают его разгребать.
  • Непонятно, что делают разработчики — вместо реализации задач, необходимых бизнесу, львиная доля времени тратится на реализацию технических компонентов (логирование, аудит, аутентификация и т. д.).
  • «Проекты под угрозой срыва, а у разработчиков всё хорошо» — проще говоря, разработчики используют SLA (Service Level Agreement, соглашение об уровне поддержки услуг) как способ снять с себя ответственность.
  • В разработанных программных продуктах много ошибок — в сдаваемом функционале огромное количество ошибок. Создаётся впечатление, что его никто не тестировал, а понятия «выпуск продукта», похоже, вовсе не существует.
  • Все команды работают по-разному — каждый коллектив использует собственные процессы, стандарты, языки программирования и инструменты разработки. Так что любая команда проходит свой путь становления и тратит время на уже решённые другими коллегами вопросы.

Что вы узнаете из этой книги?

Книга состоит из четырёх частей.
В ПЕРВОЙ ЧАСТИ мы поговорим об организации производства программных продуктов в целом. Какое оно — современное, умное и эффективное производство? Как оно должно быть организовано, чтобы стать результативным, управляемым и эффективным? Как организационная структура влияет на эффективность работы команд? Ответим на вечный вопрос: нужно ли менять существующую организационную структуру, чтобы выстроить действительно эффективное производство?
Вы узнаете:
  • главные принципы, на которых должно строиться современное, умное и гибкое производство. В современном мире выживут не самые сильные, а самые гибкие, умеющие приспосабливаться к быстро изменяющимся условиям;
  • какая система коммуникаций призвана поддержать умное производство;
  • о пульте управления производством программных продуктов — ситуационном центре.
ВО ВТОРОЙ ЧАСТИ спустимся на уровень команды. Я подробно остановлюсь на принципах формирования команды, командной ответственности и её культурном коде. Почему одни команды эффективны, а другие нет? Как сделать так, чтобы все они вышли на высокий уровень и продолжили непрерывно повышать свою эффективность?
Вы узнаете:
  • что люди, объединённые вокруг программного продукта в автономные осознанные команды — ваш стратегический ресурс;
  • как взрастить культуру производства, направленную на непрерывное повышение профессионализма сотрудников;
  • что основное влияние на качество программного продукта оказывает программист, а не тестировщик;
  • о кодексах программиста и аналитика.
В ТРЕТЬЕЙ ЧАСТИ поговорим о гибких методологиях разработки программных продуктов. Я подробно расскажу об основных процессах разработки. Почему внедрение гибких методологий часто не приводит к успеху? Как гарантированно получить пользу от их внедрения? Почему оценка задач на разработку программных продуктов и оценка на их основе бюджета проекта превышает все разумные пределы?
Вы узнаете:
  • как научить команды сознательно применять гибкие методологии разработки и показавшие свою эффективность практики;
  • что такое осознанный Scrum;
  • как с помощью нормирования типовых работ сократить оценку бюджетов проектов в 12 раз;
  • как гарантированно получить пользу от внедрения DevOps;
  • о системном подходе к разработке и внедрению эффективных практик на конкретных примерах;
  • о теориях процессного и проектного подходов, лежащих в основе методологии разработки программных продуктов.
В ЗАКЛЮЧИТЕЛЬНОЙ ЧЕТВЕРТОЙ ЧАСТИ разберём, как правильная архитектура помогает усилить положительный эффект от внедрения гибких методологий. Самое неэффективное занятие — эффективно создавать, то, что не нужно было создавать в принципе. Наиболее полно на современные вызовы отвечает микросервисная архитектура. Микросервисы очень удобно разрабатывать, применяя гибкие методологии. Как не потерять контроль среди тысяч микросервисов? Если каждая команда разрабатывает собственные микросервисы, как избежать их дублирования? Как пользователям без навыков программирования использовать микросервисы?
Вы узнаете:
  • о компонуемой бизнес-архитектуре;
  • как разрабатывать продукты один раз и не дублировать их для нескольких каналов, например, для веба и мобильного приложений;
  • что готовые low-code платформы экосистемы цифровой трансформации снижают сложность реализации задач в 6 раз.
В итоге, прочтя книгу полностью, вы узнаете, как организовать производство, чтобы каждая команда направляла не менее 70% своей мощности на создание ценности в каждом спринте (каждые две недели), и как поднять общую эффективность разработки программных продуктов в 72 раза! Нормирование типовых работ сразу поднимет эффективность вдвое. Автоматизация производственных процессов, например, DevOps-конвейер, снизит стоимость разработки ещё в три раза, а применение low-code платформ и готовых компонентов — дополнительно в шесть раз. Сокращение количества ошибок, публичная соревновательная среда, фокусировка на создании ценностей в каждом спринте поднимет производительность команд ещё вдвое.

Кому адресована эта книга?

Эта книга написана для всех, кто так или иначе работает с командами, разрабатывающими программные продукты, а также для тех, кто заинтересован в организации эффективного производства программного обеспечения. Книга будет полезна как лидерам, так и всем членам команды, которые хотели бы содействовать её развитию. Материал и форма изложения не требуют от читателя серьёзной базовой подготовки в информационных технологиях (IT). Все необходимые понятия раскрываются по ходу изложения. Отрасль IT достаточно молода, ей всего несколько десятков лет, а многим технологиям, например, DevOps, нет и десяти лет. Зачастую даже активные участники по-разному понимают суть технологий и протекающих процессов, поэтому в книге приведено много примеров из обычной жизни — для более точной передачи смысла приводимых практик.
В этой книге я поделюсь многолетним практическим опытом эффективного производства программных продуктов в компании «Диасофт».
ПЕРВЫЙ ПРИМЕР: стабилизация качества автоматизированной банковской системы (АБС) Diasoft FA#. АБС состоит более чем из 100 продуктов, автоматизирующих корпоративный, розничный, финансовый бизнес банков, а также получение обязательной банковской отчётности.
На начало проекта:
  • все продукты выпускались единовременно одним релизом;
  • проект выпуска длился три месяца, и в нём участвовали все производственные команды (более 300 сотрудников);
  • количество исправляемых в квартал ошибок превышало 13,5 тысяч, и большинство из них приходилось исправлять с существенным превышением сроков;
  • законодательство выпускалось с превышением сроков ввода в действие и с критическими ошибками, препятствующими выполнению основных бизнес-процессов;
  • для разработки новой функциональности катастрофически не хватало ресурсов;
  • на данный релиз перешли всего 10 пилотных банков, остальные 190 отказывались от перехода.
Через два года проект был успешно завершён со следующим результатом:
  • релиз каждого из 100 продуктов теперь выпускается независимо каждые полтора-два месяца;
  • выпуск релиза любого продукта производится автоматически за один день, без участия сотрудников;
  • количество исправляемых за квартал ошибок снижено более чем в 10 раз (около 1000), и все они исправляются в срок или раньше срока;
  • законодательство выпускается за две недели до вступления в силу без критических ошибок;
  • 70% ресурсов производства используется для разработки новой функциональности;
  • все клиенты перешли на данный релиз и в основном сделали это самостоятельно.
ВТОРОЙ ПРИМЕР: перевод процессов производства на Scrum, снижение стоимости разработки продуктов в четыре раза и внедрение DevOps. Проект затронул более 70 команд (около 900 сотрудников), разрабатывающих более 300 продуктов для Diasoft FA# (двухуровневая клиент-серверная архитектура), FLEXTERA (трёхуровневая архитектура) и Digital Q (микросервисная архитектура).
На начало проекта:
  • действовала прежняя функциональная структура компании (департаменты аналитики, разработки и тестирования);
  • часть команд (АБС Diasoft FA#) работала по Scrum, остальные использовали водопадную модель;
  • трудоёмкость разработки функциональности во FLEXTERA превышала трудоёмкость разработки аналогичной функциональности в Diasoft FA# от 4 до 6 раз;
  • отсутствие процессов DevOps;
  • разворачивание стендов FLEXTERA от 1 до 14 дней в зависимости от количества развёртываемых продуктов.
Через два года проект был успешно завершён со следующим результатом:
  • сформировано более 70 кросс-функциональных команд по 7−12 сотрудников в команде;
  • внедрены процессы Scrum;
  • трудоёмкость разработки функциональности FLEXTERA снижена более, чем в 4 раза;
  • автоматическое развёртывание стенда после выкладывания исходного кода в кодовую базу занимает 10 минут.
Часть 1. ПРИНЦИПЫ ОРГАНИЗАЦИИ ЭФФЕКТИВНОГО ПРОИЗВОДСТВА
Made on
Tilda