10 важнейших принципов разработки программного обеспечения

S.O.L.I.D

Эта аббревиатура обозначает пять принципов объектно-ориентированного программирования и дизайна.

S — Single Responsibility Principle (SRP) — Принцип единой ответственности.

O — Open/Closed Principle (OCP) — Принцип открытия / закрытия.

L — Liskov Substitution Principle — Принцип замещения Лисков.

I — Interface Segregation Principle — Принцип разделения интерфейса.

D — Dependency Inversion Principle — Принцип инверсии зависимостей.

Давайте кратко рассмотрим каждый из этих принципов

Принцип единой ответственности (SRP)

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

Здесь мы говорим о связанности. Все элементы в структурах или модулях данного класса должны иметь функциональное родство друг с другом. Чётко определив ответственность своего класса, вы повысите его связанность.

Принцип открытости / закрытости (OCP)

Принцип гласит, что вы должны иметь возможность изменять поведение класса, не изменяя сам класс.

Следовательно, вы можете расширить поведение класса за счет композиции, интерфейса и наследования. Однако вы не можете открыть класс для незначительных изменений.

Принцип замещения Лисков (LSP)

В своей исследовательской работе 1988 года Барбара Лисков заявила, что производные классы должны быть спроектированы так, чтобы их при необходимости можно было заменить своими базовыми классами без потери обратной совместимости

Таким образом, вам нужно проявлять осторожность при использовании наследования в проекте

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

Перед выполнением наследования необходимо учитывать предварительные условия класса.

Принцип разделения интерфейса (ISP)

ISP предпочитает много конкретных интерфейсов одному общему. Цель состоит в том, чтобы иметь гранулярные и специфичные для клиента интерфейсы.

Вам необходимо повысить связанность в интерфейсах и разработать бережливые модули — с минимально возможным поведением.

Интерфейсы с множеством поведений сложно поддерживать и развивать. Так что вам следует избегать их.

Принцип инверсии зависимостей (DIP)

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

Модули высокого уровня должны быть независимыми от модулей низкого уровня. И те, и другие должны зависеть от абстракций

Абстракции не должны зависеть от деталей реализации. Детали должны зависеть от абстракций.

Итак, в чем причина этого принципа? Ответ состоит в том, что абстракции мало меняются. Следовательно, вы можете легко изменить поведение вашего приватного или публичного кода. Таким образом, вы ускорите его дальнейшую эволюцию.

Заключение

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

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

Для вас подготовил перевод Никита Ульшин, Team Lead & JS-разработчик, веду блог ulshin.me и ТГ-канал @ulshinblog.

Комментарии, пожелания и конструктивная критика приветствуются

«Бережливое» производство: как это понимать

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

Этот термин обычно понимается в двух основных значениях:

1. Совокупность практических инструментов и бизнес-технологий для достижения поставленных задач.
2. Система положений, близкая к философской, которая характеризует особое отношение к организации деятельности на всех уровнях – от руководства до простого рабочего.

Вопрос: Какие есть отраслевые особенности применения системы менеджмента бережливого производства на основе национальных стандартов?Посмотреть ответ

В различной литературе эта технология может именоваться:

• БП («бережливое производство»);
• Английский эквивалент – «lean production»;
• Леан или Лин-технология (калька с английского термина);
• Может писаться в английской транскрипции, например, «принципы LEAN».

В современном менеджменте без внедрения БП ни одна компания не может рассчитывать на лидирующее положение в своей отрасли и даже на сколько-нибудь серьезную конкуренцию.

Scrum и Kanban как методы, основанные на Agile

Наиболее популярные системы, близкие к методологии Agile, — Scrum и Kanban.

Scrum

Scrum является методом управления проектами, который имеет много общего с Agile. Этот подход был впервые описан в вышедшей в 1986 г. статье, авторами которой стали специалисты по менеджменту Хиротака Такэути и Икудзиро Нонака. Они дали ему образное название, взяв слово из спортивной терминологии: scrum — толкотня, борьба за мяч в регби.

Суть метода состоит в том, что лучший результат дают небольшие команды, включающие в себя разнопрофильных специалистов. При этом рабочий процесс делится на короткие этапы, именуемые спринтами. Они длятся 2-4 недели, и каждый из них представляет собой завершенный цикл:

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

Scrum в основном используется для управления процессом разработки сложного программного обеспечения. В сравнении с последовательной, каскадной моделью waterfall, он позволяет повысить производительность и сократить время реализации проекта. Его преимуществом является возможность видоизменять продукт по ходу его создания, если появились новые требования у заказчика или выявились другие значимые факторы. Достоинства Scrum:

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

Kanban

Родственной Agile-методологии можно назвать систему организации командной деятельности Kanban. Дословно в переводе с японского kanban означает «рекламный щит, вывеска», а сам метод был впервые реализован в компании Toyota.

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

Основные принципы Kanban:

• Наглядность содержания проекта: вся наиболее важная информация выставляется на всеобщее обозрение, и каждый видит, что и в какой срок нужно сделать, какие к этому есть препятствия.
• Жесткие ограничения на WIP (work in progress — работа, выполняемая одновременно), чтобы не допустить распыления сил и на каждую группу возложить адекватные задачи.
• Установление лимитов времени для этапов выполнения проекта и ежедневный контроль качества работ, поощрение инициатив исполнителей, позволяющих оптимизировать производственные процессы.

Вступление

Сегодня существует достаточно большое количество стандартных процессов и методологий, применяя которые фирма получает ту или иную модель производства ПО. Самыми известными из них являются CMM (Capability Maturity Model) и серия стандартов ISO 9000. Как правило, организации внедряют эти процессы исключительно для того, чтобы получит сертификат соответствия своего процесса одному из вышеупомянутых стандартов. Однако, как не парадоксально это звучит, зачастую попытки внедрить один из вышеупомянутых процессов пагубно сказывались на стабильности работы фирмы.

В последние 3 года на западе стали модными термины «легковесный процесс», «адаптивный процесс», «единый рациональный процесс» и «экстремальное программирование». Что это такое? И почему иногда эффект от внедрения ISO9000 оказывается негативным? Какой процесс предпочесть и какими критериями руководствоваться при выборе процесса? Остальная часть статьи является попыткой найти ответы на эти и другие вопросы.

Скрытые потери

Система «Бережливого» производства предельно конкретна. Для того чтобы перестроить производство, сначала нужно навести порядок в имеющейся системе, устранив наиболее явные «утечки», то есть минимизировав скрытые потери, сведя на нет неполезные действия. Таким образом, повысится эффективность и наладится хозяйствование и в других сферах. Поэтому нужно в первую очередь определить главные виды возможных потерь на производстве. Основатели и последователи системы Лин выделили несколько их разновидностей:

• перепроизводственные – потери вследствие избыточного изготовления продукции (усиливают влияние остальных видов потерь);
• «ожидательные» – потери из-за непродуктивного ожидания (по разным причинам, например, простой, несвоевременные поставки, наладка плохого оборудования, неэффективный производственный цикл и др.);
• динамические – потери, вызванные непроизводительными движениями и нецелевыми передвижениями (поиск нужных инструментов или документов, выполнение действий без необходимости, неправильная организация пространства);
• «запасные» – потери из-за чрезмерного количества запасов (деталей, документов, сырья и т.п.), так как нужно тратить ресурсы на хранение, поиск и др.;
• качественные – потери из-за дефектных результатов производства (большого количества брака);
• технологические – потери из-за несоответствия технологии требованиям к конечному продукту;
• психологические – потери вследствие творческого выгорания сотрудников.

История Agile

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

В 1970 году американским специалистом по информатике Уинстоном Ройсом было написано своеобразное руководство под названием «Управление развитием крупных программных систем». Ройс считал неэффективным последовательный процесс создания ПО, когда работа производится по принципу конвейерной сборки с добавлением к проекту новых элементов на каждом этапе.

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

Позднее на основе идей Ройса были выработаны гибкие методы разработки компьютерных программ, которые позволили повысить эффективность труда программистов. Основные вехи исследований в этом направлении:

• 1991 год – создание метода быстрой разработки приложений RAD, нацеленного на получение результата в максимально короткие сроки в условиях ограниченности ресурсов.
• 1994 год – появление метода разработки динамических систем DSDM, при котором ускорение работ достигается различными способами, включая участие пользователей в создании и тестировании продукта.
• 1995 год – формирование подхода гибкой разработки ПО Scrum, где реализация проекта делится на короткие промежутки – спринты с представлением заказчику достигнутых на каждой стадии результатов.
• 1996 год – появление гибкой методологии разработки Crystal Clear, делающей упор на формирование человеко-, а не проектно-ориентированных команд, и экстремального программирования XP, позволяющего разрабатывать ПО с учетом меняющихся запросов заказчиков.
• 1997 год – создание итеративной методологии FDD («разработка, управляемая функциональностью»).

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

Значимым событием стала встреча в 2001 году на курорте Snowbird (штат Юта) семнадцати ведущих программистов, которые обсудили проблемы, возникающие при управлении проектами. Результатом дискуссий стал документ «Манифест о гибкой разработке программного обеспечения Agile». Именно это понятие, которое дословно означает «подвижный», «проворный», но в данном контексте обычно переводимое как «гибкий», стало основой новой методологии создания ПО.

Технология внедрения методов бережливого производства

Алгоритм реализации может быть
представлен в восемь этапов:

1. найти агента перемен (вам нужен лидер, который может взять на себя ответственность).
2. получить необходимые знания о системе бережливости (из надежного источника).
3. найти или создать кризис (хорошим мотивом для введения lean является кризис в организации).
4. не увлекайтесь стратегическими вопросами (вы можете начать с устранения потерь там, где это возможно).
5. создавать карты потоков ценности (сначала текущее состояние, а затем будущее состояние, после бережливого внедрения).
6. как можно скорее начать работу по ключевым областям (информация о результатах должна быть доступна сотрудникам организации).
7. стремиться к достижению немедленных результатов.
8. осуществлять непрерывное совершенствование в соответствии с системой Кайдзен (переход от процессов с добавленной стоимостью в магазинах к административным процессам).

Для создания бережливой культуры
необходимо изменить корпоративную культуру в организации. Примером тому
является служебная записка сотрудника ОАО «КУМЗ»:

1. Мы можем делать все, что захотим.
2. Мы знаем рынки, которые мы обслуживаем.
3. Мы гордимся нашими продуктами и соответственно ценим их.
4. Мы стараемся меняться каждый день и тем самым делать качественный скачок.
5. Мы сильны, подвижны, предприимчивы.
6. Мы привержены бережливым решениям.
7. Мы вознаграждаемся результатами, а не позициями.
8. Мы следуем правилу: «Не приходите с проблемой, приходите с решением».
9. Мы говорим: «Плохое решение лучше, чем вообще никакого решения».
10. И последнее — «Босс занят, так что будь боссом».

4 ценности Agile

1. Люди и социальное взаимодействие важнее технологических процессов. Это фундамент философии Agile, которая исходит из того, что результат обеспечивают члены команды, постоянно находящиеся в общении друг с другом, а не безликие планы, лишенные привязки к конкретным людям.
2. Работающий продукт важнее самой подробной документации. Команды, придерживающиеся принципов Agile, отвергают приоритетность отчетов и прочих документов – для них главной целью является создание действующих программ.
3. Сотрудничество с заказчиком важнее согласования условий контракта. Концепция Agile предполагает тесное взаимодействие с заказчиком на всех этапах работы над проектом и обратную связь с клиентами. Это имеет большее значение, чем долгое согласование объемных контрактов.
4. Готовность к изменениям важнее следования первоначальному плану. Еще один принцип, демонстрирующий гибкость Agile-подхода к управлению проектами. В условиях современности нужно уметь адаптироваться к меняющимся условиям и новым вызовам.

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

Классификация проектов

Модель и параметры процесса производства ПО в значительной мере зависит от типа проекта. У каждой команды есть свои заказчики, с которыми сложились те или иные отношения.

«Свой» заказчик

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

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

Продукт под заказ

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

• доступность заказчика можно охарактеризовать как «периодическую»;
• представление о нуждах и потребностях заказчика формируется на базе произведенного обследования;
• заранее оговоренные требования к программному обеспечению, согласно которым производится приемка готового продукта;
• разработчик в течение заранее оговоренного периода времени поддерживает поставленный продукт;
• финансовые отношения оформляются в виде разового контракта;
• планы по дальнейшему сотрудничеству в значительной мере зависят от качества и устойчивости продукта, который разработчик поставил заказчику.

Тиражируемый продукт

Ситуация, при которой команда разработчиков либо вообще не имеет конкретных заказчиков («коробочный продукт»), либо довольно значительное количество заказчиков на один и тот же продукт. Основные характеристики такого типа проекта:

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

Аутсорсинг

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

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

Исправление ошибок — сложная задача

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

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

Инструменты LEAN

Для достижения целей, задекларированных «Бережливым» производством, применяется разветвленная система различных управленческих инструментов:

1. Концепция 5S. Этот инструмент предназначен для первичного упорядочивания основных процессов, вызывающих скрытые потери тех или иных разновидностей. Применение метода сразу оказывает положительное влияние на качество выпускаемой продукции, производительность труда, безопасность его условий. Название «5S» отражает пятерку основных этапов минимизации скрытых потерь, каждый из которых начинается с буквы «С»:
   • сортировка;
   • самоорганизация;
   • содержание рабочего места в надлежащем состоянии;
   • стандартизация рабочего места;
   • совершенствование.
2. Метод JIT. Аббревиатура расшифровывается как «Just-in-Time», «точно вовремя». Направлен на сокращение сроков производственного цикла, что, в свою очередь, существенно уменьшит себестоимость продукции, а значит, и цену товара. Сущность метода в том, что материалы и сырье предоставляются только тогда и в том количестве, когда они нужны для производства. При состоянии «в обрез» рабочие потери значительно уменьшатся, по сравнению с постоянным переизбытком исходного материала.
3. Метод «Пока-ёке» (Poka – Yoke). Перевод с японского языка выражения — «защита от ошибок». Смысл в том, чтобы ликвидировать саму возможность допущения ошибки. Всем известно, что профилактика всегда менее сложна и затратна, чем исправление. Поэтому все силы персонала и управляющих звеньев направляются на создание процедур или использования устройств для предотвращения ошибок.
4. Подход Кайдзен. Слово можно перевести как «совершенствование без остановки». Основа ее в постепенном переходе с этапа на этап, каждый из последующих предусматривает пусть небольшое, но изменение к лучшему. На каждой ступени сначала производится анализ текущей обстановки, затем предлагаются конкретные шаги для улучшения, которые и реализуются на следующей ступени.
5. Система Канбан. Также японский метод, который предусматривает контроль над потоками материалов и товаров. Основана на использовании специальных рабочих карточек для сопровождения изделия во всем его производственном цикле, каждую из которых и называют «канбан». Они бывают двух видов:
   • карточки отбора ­– несут информацию о деталях продукции, которые должны поступить с других участков или от поставщиков;
   • карточки заказа – несут информацию о движении изделий или их деталей внутри организации (виды, количество), которые должны прийти с предыдущего этапа производства.
6. Режим Андон. Предусматривает прозрачность процесса для всех участников производства с помощью визуального контроля, позволяет вовремя запросить помощь или остановить процесс.
7. Метод SMED. («Single Minute Exchange of Die», что можно перевести как «промедление смерти подобно») позволяет минимизировать временные потери на промежуточных этапах производства.
8. Контроль качества может производиться с помощью разнообразной палитры приемов:
   • контрольный листок;
   • контрольная карта;
   • стратификация;
   • гистограмма;
   • диаграмма разброса, Парето, Исикавы и др.
9. Управление качеством осуществляется с помощью разнообразных диаграмм, графиков и матриц:
   • сетевой график;
   • матрица приоритетов;
   • диаграммы связей, сродства, древовидная, матричная и др.
10. Анализ и планирование качества могут выполняться с помощью различных процедур:
    • метод «5 почему»;
    • «домик качества»;
    • FMEA-анализ и др.

Это далеко не полный перечень инструментария «Бережливого» производства. Поскольку БП, как уже говорилось, не набор технологий, а система, наибольший эффект принесет комплексное применение методик, хотя и каждая из них в отдельности окажет положительное влияние на ту или иную отрасль производства.

Создавайте знание

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

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

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

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

Feature Driven Development

Feature driven developmentэтойисследованиямпредложил

Разработка общей модели. Команда разработчиков делится на группы создаёт модели для отдельных задач. Затем выбирается одна из предложенных моделей или их сочетание.

Создание . Когда команда разработала общую модель, она определяет полезные для клиента функции.

Планирование

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

Дизайн и разработка. На основе данных первого процесса, менеджер проекта выбирает группу функций, которые команда должна реализовать за определённый срок.

Реализация

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

созданаотмечаютпомогаетутверждаетснижаетP.S. О чем еще мы пишем в нашем корпоративном блоге:

Управление ИТ-проектами – 5 вызовов и их преодоление

Управление изменениями – о целях процесса и его внедренииТоп-10 самых популярных вопросов при внедрении ServiceNow

Как создать и начать использовать каталог услуг (Service Catalog)
Как сделать ITIL более клиентоориентированной

Гибкие подходы к разработке программного обеспечения

На базе семейства итеративных моделей был создан крайне распространенный на данный момент вариант разработки — Agile. Это скорее является подходом, нежели целостной методологией. Дело в том, что внутри проекта на различных стадиях допускается использование как итерационных, так и каскадных моделей.

Гибкие подходы к разработке программного обеспечения

Суть данного подхода заключается в дифференцировании процесса разработки на несколько отдельных задач. Программисты могут выполнять эти задачи с высоким уровнем независимости друг от друга. Каждый день организовываются встречи команды (Scrum), в рамках которых проговаривается нынешнее состояние проекта. Разработку дифференцируют на несколько стадий-спринтов (Sprint). Во время прохождения этих спринтов разработчики должны выполнить поставленные цели.

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

Преимущества:

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

Недостатки:

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

В рамках данного подхода применяется целый ряд всевозможных техник, методологий и приемов. Выделим некоторые из них:

• Scrum. Участники проекта находятся в постоянном взаимодействии и обсуждают текущий прогресс.
• Kanban. Используется виртуальная доска с задачами. Последовательность выполнения таких задач не определяется.
• RUP. Наличие четких стадий планирования, уточнения и построения новых итерация программного обеспечения.
• Extreme Programming. Частые обновления версии продукта и отыскивание наиболее скоростных решений.

Гибкие подходы к разработке программного обеспечения

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

Говоря о гибких методологиях, следует отдельно упомянуть так называемую бережливую разработку ПО Lean. Ее целью является увеличение уровня эффективности создания продукта и повышение результативности всех рабочих процессов. Иными словами, разработка организуется таким образом, чтобы на реализацию проекта ушло меньше денег и времени.

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

Кратко о том, что входит в Agile сегодня

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

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

Канбан отличается от Скрама по многим параметрам, в частности:

• имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
• в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
• нацелен не только на ускорение, но и на равномерность процессов;
• имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
• отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).

Подробнее об этом см. в статье про отличия Kanban и Scrum.

Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу»:

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

Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.

Отличительные особенности всех сколь-нибудь популярных в России подходов, имеющих отношение к Agile (а также к более широкому понятию Business Agility), вы можете посмотреть на одном экране, скачав нашу карту гибких подходов для бизнеса в виде картинки и в виде пригодного к печати плаката.

Когда бережливое производство не работает

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

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

Но немногие менеджеры согласятся на то, чтобы работники часть времени отдыхали. 

Иногда компании готовы внедрять отдельные инструменты Lean, но не готовы перенимать ценности бережливого производства. Особенно если люди уже сталкивались с попытками оптимизации и успели накопить скепсис к нововведениям.

Заключение

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

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