Мастерство Lean-разработки ПО: Практическое руководство для CTO в 2022 году

Выбор подходящей методологии разработки ПО может быть сложным.

И почему бы нет? В конце концов, разработка ПО всегда была дорогостоящим процессом и таким, что часто занимает месяцы или годы для завершения.

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

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

Если вы не уверены, как начать, вот пошаговое руководство для вас.

Мы дадим обзор Lean-разработки ПО и все основные принципы Lean. Обсудим, как эта философия отличается от Agile, и объясним Lean-роли и ответственности.

Начнём!

Что такое Lean-разработка ПО?

Lean-разработка ПО (LSD) применяет принципы Lean к разработке ПО.

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

Методология Lean-разработки ПО упрощает и оптимизирует работу разработчиков ПО по тем же принципам.

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

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

Каковы семь принципов Lean-разработки ПО?

Существует семь установленных принципов Lean-разработки ПО, которые могут помочь вам строить программные продукты с эффективностью.

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

Давайте глубже погрузимся в эти принципы.

Источник изображения

Принцип 1: Устранить потери

В разработке ПО потери — это всё, что не приносит никакой бизнес-ценности клиенту и не улучшает качество вашего продукта.

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

• Ненужный код или функциональность: Убедитесь, что вы приоритизируете разработку только тех функций, которые добавляют значительную ценность клиенту. Всё остальное потребует времени на обсуждение, разработку и тестирование и задержит TTM (time to market) вашего продукта.
• Начало большего числа задач, чем можно завершить: Это добавляет ненужную сложность в систему, приводя к переключению контекста, передачам и нарушению рабочего процесса.
• Задержка в процессе разработки ПО: Задержки замедляют доставку конечного продукта и циклы обратной связи.
• Неясные и меняющиеся требования: Это приводит к потере фокуса командой, переработке, фрустрации и в конечном итоге проблемам качества продукта.
• Бюрократия: Хотя хорошая организация и управление важны, допущение большей бюрократии, чем нужно, задерживает весь процесс разработки ПО.
• Плохая коммуникация: Это включает неэффективную коммуникацию между IT-командой и стейкхолдерами. Это приводит к ненужным задержкам, фрустрации и потере фокуса.
• Частично выполненная работа: Незавершённая и частично выполненная работа ни не добавляет ценности клиенту, ни позволяет членам команды учиться на работе.
• Переключение задач: Перескакивание членов команды с задачи на задачу из-за плохого планирования часто приводит к избегаемым задержкам, сбоям в коммуникации, низкому моральному духу команды и плохому качеству работы.
• Ошибки кода и проблемы качества: Дефекты и баги ведут к дополнительной работе. Они заставляют программистов остановить текущую работу и фокусироваться на исправлении багов. Результат — брошенная работа, задержанные планы и низкая удовлетворённость клиентов.

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

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

Принцип 2: Встраивать качество

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

Принцип «Встраивания качества» в Lean-разработке ПО решает все такие проблемы до их возникновения. Вместо того чтобы полагаться исключительно на обширное тестирование позже, мы начинаем с качества как критического требования с самого начала, добавляя его на каждом шаге.

Следующие инструменты и техники используются в Lean-разработке для обеспечения качества на протяжении всего процесса:

• Рефакторинг: Практикуйте регулярно и держите код чистым и структурированным.
• Парное программирование: Это отличный метод, использующий экспертизу двух разработчиков вместо одного. В результате каждая задача выполняется двумя разработчиками, чтобы вы могли иметь более эффективные решения.
• Разработка через тестирование (TDD): вы можете избежать проблем качества, пишая тесты до написания кода. Поскольку разработчик знает, как код будет тестироваться, он с большей вероятностью напишет код, покрывающий все сценарии.
• Инкрементальная разработка и постоянная обратная связь: такая обратная связь бесценна и обеспечивает хорошее качество.
• Минимизация состояний ожидания: если вы минимизируете время между написанием кода, тестированием и исправлением багов, вы можете быть уверены в снижении переключения контекста и пробелов в знаниях из цикла разработки.
• Автоматизация тестирования: Это подразумевает автоматизацию каждого процесса, который утомителен, ручной и подвержен человеческим ошибкам.

Принцип 3: Создавать знания

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

Ваша команда должна документировать и сохранять своё ценное обучение согласно этому принципу. Это делается применением комбинации следующих инструментов:

• Код-ревью
• Парное программирование
• Документация
• Тщательно прокомментированный код
• Сессии обмена знаниями
• Обучение
• Методы вроде дизайна на основе активов для управления требованиями

Принцип 4: Откладывать принятие решений

Этот принцип Lean — всё об ответственном принятии решений. Однако он не даёт команде свободу быть непостоянными и безответственными в рабочих обязательствах.

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

Что это значит:

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

Принцип 5: Доставлять быстро

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

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

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

Именно поэтому Lean-инженеры строят MVP (минимально жизнеспособный продукт) с необходимой функциональностью и запускают MVP-продукт на рынок максимально быстро. Обратная связь пользователей помогает инженерам учиться и вносить поправки соответственно.

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

Принцип 6: Уважение к людям

Lean нацелен на расширение возможностей членов команды вместо контроля над ними.

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

Как?

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

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

Отношение к разработчикам как к компетентным, мотивированным профессионалам, а не как к роботам, пишущим код — вот ключ.

Принцип 7: Оптимизировать целое

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

Субоптимизация — большая проблема в разработке ПО. Есть два порочных цикла, в которые Lean-команды разработки склонны впадать из-за субоптимизации.

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

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

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

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

Lean vs Agile: Ключевые различия

Lean и Agile — популярные методологии разработки ПО. Пока оба метода продвигают продуктивность и быструю доставку, мы настоятельно рекомендуем понять различия для их гарантированного правильного применения.

Давайте посмотрим.

	Lean	Agile
Фундамент	Начался в производственном секторе, затем другие секторы последовали.	Родился в секторе разработки ПО, затем другие секторы последовали.
Основная философия	Эта методология фокусируется на устранении потерь и минималистичном подходе к разработке ПО.	Коллаборация — ядро методологии Agile.
Принципы	Есть 7 принципов Lean-разработки ПО. 1. Устранить потери 2. Встраивать качество 3. Создавать знания 4. Откладывать принятие решений 5. Доставлять быстро 6. Уважать людей 7. Оптимизировать целое	Есть 12 принципов Agile-разработки ПО. 1. Высший приоритет — удовлетворение клиента 2. Приветствовать меняющиеся требования 3. Частая доставка ПО 4. Бизнес-люди и разработчики сотрудничают ежедневно 5. Строить проекты вокруг мотивированных людей 6. Личный разговор — лучший 7. Работающее ПО — основная мера прогресса 8. Устойчивый темп разработки 9. Непрерывное внимание к техническому превосходству и хорошему дизайну 10. Простота 11. Самоорганизующиеся команды 12. Регулярная рефлексия и адаптация
Другие различия	1. Lean — всё о стабильном рабочем процессе. 2. Lean даёт больше важности процессу разработки ПО. 3. Lean можно применять для снижения затрат. 4. Lean следует системному подходу к построению продуктов, устраняя всё лишнее.	1. Agile более адаптивен к изменениям. 2. Agile даёт работающему продукту больше ценности, чем процессу. 3. Agile нельзя использовать для снижения затрат. 4. Agile входит в построение продукта через последовательные ответы и обратную связь.

Руководство CTO по Lean-ролям и ответственности

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

И это может случиться только когда у вас есть lean-мыслящая команда с вами.

Что составляет такую команду? Каковы их роли и ответственности?

Lean хорошо работает как с малыми, так и с большими командами. Размер команды почти не имеет значения, но основные Lean-роли, которые вам нужны:

1. Lean-мастер

Lean-мастер — опытный профессионал, работавший с клиентами в той же среде. Благодаря этому он будет больше осведомлён о проекте и продукте.

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

Lean-мастеры поддерживают клиента:

• Установкой целей и цели каждой команды.
• Отбором и выделением людей (ресурсов) с релевантными навыками.
• Менторством и обучением людей в Lean-мышлении.
• Управлением мастер-плана и изменениями.
• Поощрением команды к принятию интеллектуальных решений.
• Их знанием Lean-инструментов и техник.

2. Лидеры Lean-проектов

Лидер Lean-проекта работает как основной канал коммуникации между Lean-мастером и командой. Они также работают как мотиватор.

Ключевые обязанности лидера Lean-проекта включают:

• Ведение Lean-проектов и команд.
• Устранение барьеров в проекте и отчётность о прогрессе.
• Обеспечение чёткой коммуникации и организация проектных активностей.
• Вклад в улучшение команды.

3. Участники Lean-команды

Lean-команды спроектированы вокруг индивидуальных процессов. Плохие члены команды — эксперты в своей работе. Они включают разработчиков и тестировщиков с релевантными навыками. Члены команды отлично справляются с проектированием и реализацией решения.

Разработайте мощное кастомное ПО с Imaginovation

Если вы хотите построить уникальное ПО с учётом стратегии устранения потерь Lean, свяжитесь с нами в Imaginovation.

Мы поможем вам спроектировать кастомизированное решение, отвечающее вашим бизнес-потребностям.

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