2005 год. Наша ИТ-компания переходит работать по методологии ITIL. Условно это как библия для ИТ, которая помогла разобрать тот хаос, который творился.
Это сейчас кажется, что SLA, сроки, критичность, приоритет были всегда. А тогда это было всё в диковинку.
Внедрили нам, конечно, же HP Service Desk, тогда другого не было. Я тогда был начальник отдела и как же было круто отслеживать статусы нарядов.
Скажем приходит заявка: подготовить физически сервер, развернуть нужно ПО и так далее. Делаешь наряды на ЦОД на монтаж сервера, затем сетевикам на настройку сети, админам - на на установку софта. Видно, где задача застряла.
Но потом кто-то придумал, что это не эффективно. Нужна Jira, Agile, scram и прочая лабуда. Работало же. А теперь Lean придумали.
История и принципы той, что дала нам основу бережливого производства
Привет, это WEEEK! Сегодня мы поздравляем всех женщин с праздником и хотим рассказать историю одной, которая в какой-то степени перевернула мир IT.
Это произошло с математиком-инженером из США Мэри Поппендик, которая полжизни проработала инженером на производстве телекоммуникационных технологий, проектировала системы контроля производственных линий и вот это вот всё.
В конце 90-х она столкнулась с каскадной моделью управления проектами, а в начале нулевых уже выпустила книгу, которая стала основной для формирования методологий на базе Agile — в том числе и Kanban-методу в разработке.
Конечно, все этапы своего пути она проходила вместе с мужем, но сегодня, в честь 8 марта, мы хотим сосредоточить своё внимание именно на Мэри.
Что общего между разработкой ПО и заводом
Мэри Поппендик начала карьеру инженера в 1967 году на одном из самых культовых предприятий XX века — Bell Labs, где она программировала телекоммуникационные оборудования для телефонных сетей
Тогда только начали формироваться две вещи: профессия «разработчик ПО» и методология бережливого производства Lean, которую впервые ввели на производстве японских машин Toyota.
Lean — это процесс производства, которое направлено на максимальное увеличение ценности продукта и при этом снижении любых потерь, которые только могут быть.
С процессами Lean Мэри Поппендик познакомилась, когда начала работать на крупнейшую американскую химическую корпорацию 3М. Проектировала системы контроля производственных линий, участвовала в разработке новых продуктов и руководила командами.
Именно работа на производстве подтолкнула Поппендик к тому, чтобы поменять процессы разработки ПО в будущем. Ну, а мы в 2026-м называем это Lean Software Development.
Гибкие методологии Agile появились в 2001 году, благодаря команде разработчиков, которые пришли и сказали: «Мы больше не можем терпеть жёсткую бюрократию и работать линейно. Нам нужна свобода и гибкость процессов!». Так появился Agile Manifesto — сборник принципов и правил, который перевернул процесс разработки на 180 градусов. Главные принципы:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее изначального плана
В это время Мэри Поппендик начала писать книгу «Lean Software Development: An Agile Toolkit» в паре со своим мужем Томом. На это её подтолкнуло то же самое, что и других сторонников Agile — ограничения, которые связаны с каскадной моделью управления проектами: жёсткая бюрократия, линейная система работ и невозможность внести изменения по ходу работы.
Основная цель Поппендик — доказать, что процессы и идеи бережливого производства можно и даже нужно применять и в разработке ПО. Инженер сформировала семь принципов Lean-разработки, которые мы и опишем.
Принципы, которые легли в основу Lean-разработки
Поппендик считает, что разработка программного обеспечения — это система создания ценности для пользователя. Всё, что не делает этого — потери, которые надо устранять.
«Главная причина неудач программных систем — не технические сбои, а разработка неправильного продукта
Вот, что мы ещё должны знать про принципы Lean Software Development
Устранять потери — того, что бесполезно и в работе, и для продукта, и для потребителя. Это может быть что-угодно: долгие согласования, код, который написали, но при этом не использовали, бесконечная бюрократия или ожидание, пока закончится предыдущий этап работы. Сюда же — бесконечное переключение между задачами, избыточные процессы, дефекты в коде и так далее. Список потерь может быть бесконечным.
Поппендик считает, что перед тем, как начать работать над проектом, нужно научиться эти потери видеть и прогнозировать.
Усилить обучение. Процесс разработки ПО — это непрерывное обучение, которое напрямую зависит от неопределённости. Представим ситуацию: команда работает над проектом, старается, выпускает его и понимает, что продукт перестал быть актуальным за три месяца до релиза.
В этом случае Поппендик делает ставку на итеративный подход, постоянную проверку гипотез и регулярную обратную связь не только внутри команды, но и от пользователей. Так команда сможет быстрее реагировать на изменения и скорректировать продукт так, чтобы избежать потерь.
Не стремиться решать заранее. Казалось бы, проще продумать всё сразу и идти по намеченному пути, но есть нюанс: на старте, как правило, команда не обладает достаточным количеством информации о том, как продукт будут воспринимать пользователи и что для них на самом деле важно.
Поэтому Поппендик советует сначала собрать данные, протестировать несколько решений, а затем уже выбирать наиболее подходящее. Таким образом можно снизить вероятность неверных шагов и переделок.
Выпускать продукт быстрее остальных. Чем быстрее у пользователя будет рабочий продукт, тем больше обратной связи получит команда. Это нужно для того, чтобы молниеносно вносить изменения и улучшать новые версии, делая их ещё более ценными для потребителей. Такой подход не искореняет неопределённость, но тем не менее, заметно её снижает.
Расширить полномочия команды. Waterfall критиковали не только за линейную модель рабочих процессов. В список недостатков этой методологии внесли ещё пункт о том, что всё решает менеджер, а разработчики — это просто рабочие руки.
Мэри и Том Поппендики считают, что разработка требует творческого подхода, глубокого понимания технических проблем и вообще всего, что связано с фразой «как это должно работать». Именно поэтому у команды должно быть больше свободы действий. Руководитель в данном случае лишь создаёт среду, устраняет препятствия и помогает получить необходимые ресурсы для продуктивной работы.
Встроить качество в процесс разработки. Нельзя просто так выпустить продукт, понять, что он так себе, и только потом пытаться исправить ошибки. Лукавим: так можно, но это дорого и мучительно. Принцип встроенного качества гласит: лучше сразу делать хорошо. Достичь этой цели можно только с помощью постоянного тестирования и выстраивания единой системы, которая будет понятна разработчикам и удобной пользователям.
Улучшать не отдельную часть системы, а всё сразу. Поппендик уверена: только так можно непрерывно работать над продуктом и доносить его ценность пользователям. Важно смотреть на процесс не по частям, а в целом, потому что разработка ПО состоит из множества элементов, которые связаны и зависят друг от друга.
После того, как книга с принципами вышла в свет, Мэри Поппендик стала знаменитой. Её приглашали спикером на конференции для разработчиков и фанатов Agile-методологии, она консультировала компании, помогала внедрять новую систему так, чтобы она заработала.
Кстати, точных данных нет, но, предположительно, сейчас одной из самых влиятельных женщин в области применения Agile-методологий в районе 80 лет.
