В современном менеджменте «гибкую» модель управления рассматривают в трёх разных контекстах, которые (каждый по-своему) и определяют, что такое Agile.
Три объёма значения Agile
В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.
Во втором, более широком, значении термина принципы Agile применяются к ведению почти любого бизнеса и в качестве составляющих используются, например, в концепции «бережливого стартапа» (Lean Startup). В этом значении под Agile-моделью (Agile Model) понимают следование гибкой методологии развития проекта, проходящей по характерной схеме в несколько шагов.
- Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
- По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
- Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный подход применяется в течение всего проекта (всех итераций).
- Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.
В третьем, ещё более широком значении, Agile – это часть модели управления, применяемого на заводах «Toyota» и теперь – одна из базовых составляющих менеджмента почти любого успешного производства. Основы Agile в этом контексте схожи с основами понимания технологии в других контекстах.
Быструю обратную связь в настройке конечного формата производства на заводах «Toyota» обеспечивал любой рабочий, который мог стать инициатором остановки конвейера и автором корректировок по донастройке производственного цикла. В масштабах всего производства Agile-трансформация может повлечь за собой переналадку производственной деятельности в целом, если продукт становится результатом живого отклика на текущие потребности клиента. Так, если фабрика выпускала пластиковые тазы, а обратная связь с клиентом демонстрирует потребность в вёдрах, то быстрая адаптация с параллельной корректировкой нюансов (формы ручки, величины, цвета) будет как раз в стиле Agile management (если соблюдены и остальные принципы).
Принципы Agile-управления
Agile в управлении проектами как модель управления бизнес-процессом применяется тысячами команд во всём мире, и везде присутствуют следующие отличительные черты этого подхода:
- Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
- Для принятия решения команды должны быть высокоэффективными и сплочёнными.
- Поэтапная и цикличная работа становится основой процесса. Проект делится на мелкие части, которые завершаются к определённому сроку до завершения проекта в целом.
- Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
- В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
- Предполагается обязательное завершение одного этапа перед переходом к следующему.
«Гибкий» подход стал базовым для целого ряда методологических практик, которые отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.
Метод Scrum демонстрирует, как «гибкий подход» может быть применён на практике в конкретных операциях. Так, например, работа с требованиями по проекту реализуется с помощью четырёх «артефактов»:
- Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
- Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
- Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
- Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.
Формат Agile-управления проектами подходит не всем и не всегда. Государственные структуры, деятельность которых базируется на неизменном законодательстве и консервативна по своим целям и реализации, не нуждаются в такой оптимизации.
Характерные ошибки внедрения Agile и недостатки подхода
Тот же фактор, который считается в одних случаях сильной стороной подхода, в других может приводить к возникновению проблем. Так «гибкость» нередко становится причиной размывания фокуса. При отсутствии методологической основы возникает потеря ориентиров, и подмена первичного вторичным. Для предотвращения подобных «перекосов» используют готовые методологии или собственные разработки, более строго регламентирующие содержание и последовательность операций по ходу воплощения проекта. Тем не менее, и в этом случае в Agile-management возможны ошибки.
К распространённым ошибкам внедрения относятся следующие:
При всех сложностях внедрения гибкого подхода в целом он эффективнее традиционных «неповоротливых» производств, если речь идёт о быстром создании нового клиентоориентированного продукта. Пока традиционное производство вязнет в бюрократических проволочках, Agile-подход обеспечивает естественное движение сразу после запуска проекта.
Гибкая методология разработки (англ. Agile software development , agile-методы ) - серия подходов к разработке программного обеспечения , ориентированных на использование итеративной разработки и динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности, известны как гибкие методики экстремальное программирование , DSDM , Scrum .
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований , проектирование , кодирование , тестирование и документирование . Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen . Как минимум, она включает и «заказчиков» (англ. product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
- удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
- приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
- частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
- тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
- проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
- рекомендуемый метод передачи информации - личный разговор (лицом к лицу);
- работающее программное обеспечение - лучший измеритель прогресса;
- спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
- постоянное внимание улучшению технического мастерства и удобному дизайну;
- простота - искусство не делать лишней работы;
- лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
- постоянная адаптация к изменяющимся обстоятельствам.
Критика
Многие руководители проектов, работающие в традиционных методологиях вроде «водопада », критикуют agile-методы.
Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход - «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.
Методологии
Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto, некоторые из них:
Примечания
Ссылки
- Статья Введение в гибкую разработку программного обеспечения (рус.)
- Статья Гибкий подход разработки ПО - Scrum (рус.)
- Статья Автоматизация тестирования в Agile (рус.)
- Статья Scrum - зачем заказчику знать такие непонятные слова? (рус.)
Литература
- Майк Кон Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). - М .: «Вильямс», 2011. - С. 576. - ISBN 978-5-8459-1731-7
Wikimedia Foundation . 2010 .
Гибкая методология разработки (от англ. - Agile software development) - манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework - каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как "гибкая методология разработки" не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют - фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.
Определение с точки зрения BPM CBoK [от англ. - Guide to the Business Process Management Common Body Of Knowledge]. Agile - Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.
В основе гибкой методологии разработки лежит либерально-демократический подход к управлению и организации труда команд, члены которой сконцентрированы на разработке конкретного программного обеспечения.
За счет того, что разработка программного обеспечения с применением гибкой методологии определяет серии коротких циклов (итераций), с длительностью 2-3 недели, достигается минимизация рисков т.к. по завершению каждой итерации Заказчик принимает результаты и выдает новые или корректирующие требования т.е. контролирует разработку и может на неё сразу влиять. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. Обычно одной итерации не достаточно для выпуска полноценного программного продукта, но при этом по окончании каждого этапа разработки должен появляться "осязаемый" продукт или часть функционала, которую можно посмотреть, потестировать и выдать дополнительные или корректирующие меры. На основе проделанной работы, после каждого этапа, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки программного обеспечения.
Одной из основных идей Agile, является взаимодействие внутри команды и с заказчиком лицом к лицу, что позволяет быстро принимать решения и минимизирует риски разработки программного обеспечения, поэтому команду размещают в одном месте, с географической точки зрения. Причем в команду входит представитель заказчика (англ. product owner - полномочный представитель заказчика или сам заказчик, представляющий требования к продукту; такую роль выполняет менеджер проекта от заказчика или бизнес-аналитик).
История выпуска Agile манифеста
«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с "методом водопада" ("waterfall"), т.к. на момент выхода манифеста, именно "метод водопада" являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий:
- Adaptive software development (ASD)
- Crystal Clear
- Dynamic Systems Development Method (DSDM)
- Extreme Programming (XP)
- Feature driven development (FDD)
- Pragmatic Programming
- Scrum
Собственно данные методологии гибкой разработки существовали и до выпуска манифеста. Сам же выпуск манифеста дал новый толчок к развитию гибких методологий, заложил основы, можно сказать конституцию гибкого подхода к разработке программного обеспечения.
Agile-манифест разработки программного обеспечения:
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами.
Это привело к критике этих методов как недисциплинированных.
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Авторы манифеста:
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Основополагающие принципы Agile-манифеста:
Мы следуем таким принципам:
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт - основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота - искусство минимизации лишней работы - крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Критика Agile
Agile плохо описывает процессы управления требованиями, можно сказать, что такое понятие просто отсутствует т.к. гибкая методология разработки не подразумевает под собой долгосрочного планирования (планирование осуществляется на краткосрочную перспективу), как следствие пропущен шаг формирования плана развития продукта или другими словами дорожной карты продукта. Т.к. планирование краткосрочное (на ближайшую итерацию разработки), а Заказчик по окончанию каждой итерации принимает продукт и выставляет новые требования, сам продукт может поменяться в корни, а выставляемые новые требования зачастую противоречат структуре и архитектуре продукта уже поставляемого клиентам. По большому счету, в случае, если Заказчик не до конца понимает, что хочет увидеть в итоге (конечный продукт), а понимание приходит во время разработки (это случается в 90% случаев), процесс разработки превращается в формализованную и легализованную бюрократию т.е. продукт дорабатывается бесконечно, пока не кончаются деньги, или заказчик не переключается на другой продукт. Справедливости ради, необходимо заметить, что Заказчик знает на что идет и сам решает, платить за разработку продукта или нет, по большому счету команда разработчиков просто выполняет требования заказчика. Однако, реально, в работе это приводит к хаосу, срыву сроков и авралам, что порождает новые требования, которые меняют не в лучшую сторону продукт. Более того, снижается качество разрабатываемого продукта, т.к. Agile определяет подход к разработке, в рамках которого необходимо быстро тушить пожары, наиболее простым и быстрым способом. Код пишется не соблюдая требований платформы, на которой разрабатывается продукт, появляется множество обходных решений и дефектов, а такая конструкция не очень устойчива и не безопасна, растет негодование клиентов от частых сбоев в работе программного обеспечения. Бизнес на выходе получает потери, падает качество планирования.
Некоторые эксперты Agile ассоциируют больше с подходом по совершенствованию уже готового продукта, нежели разработки нового. Сторонников много у гибкой методологии разработки, ровно, как и противников. Последние в свое время даже выпустили Anti Agile Manifesto. Далее в ознакомительных целях, мы приводим содержание двух, наиболее популярных манифестов, противоречащих основному манифесу Agile:
Anti-Agile манифест (необходимо отметить, что данный anti-agile манифест на самом деле противоречит не самому Agile, а скорее одному из фреймворков, основанном на принципах Agile - Scrum т.к. в манифести используются термины именно из этого фреймворка):
Через нас прошло множество консультантов и мы провели огромное количество часов на встречах и совещаниях по гибкой методологии. Опираясь на данный опыт, мы поняли, что Agile, это просто запудривание мозгов, потому, что:
- эпики (epics) - это просто проекты
- пользовательские истории (user stories) - это просто сценарии использования (use case)
- спринты (sprints) - это просто работа
- стенд апы (stand-ups) - это просто совещания
- итерации (iterations) - это просто версии
- бэклоги (backlogs) - это просто список дел
- скорость команды (velocity) - это просто результаты
- и эти задачи (tasks) - это реально, просто задачи
Таким образом, в то время, когда термины слевой стороны предлагается рассматривать как новаторские, меняющие подход к разработке, они просто являются расплывчитыми понятиеми терминов справа.
Разновидность методологий гибкой разработки
На основании ценностей и принципов, определенных в Agile Manifesto были сформированы следующие гибкие методологии разработки:
- Agile Modeling (AM) - данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.
- Agile Unified Process (AUP) - унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.
- Agile Data Method (ADM) - набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.
- Dynamic Systems Development Method (DSDM) - итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений - Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта.
- Essential Unified Process (EssUP) - подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).
- Extreme programming (XP) - идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.
- Feature driven development (FDD) - основное ограничение, которое накладывается в рамках данного подхода, это "каждая функция должна быть реализована не более, чем за две недели". Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.
- Getting Real (GR) - в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность.
- OpenUP (OUP) - данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.
- lean software development - данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).
- Scrum - один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.
Все знают вошедший в классические
учебники по менеджменту пример устройства завода Toyota, где каждый сотрудник имел право остановить конвейер, чтобы устранить дефект или внести рационализаторское предложение. Именно такой подход лег в основу
философии Agile.
Agile, появившийся как метод разработки ПО в небольших
командах лет 10-15 назад, сегодня становится новой культурой управления большими компаниями. Термин Agile входит в лексикон
всех современных российских менеджеров.
Что же такое Agile и почему этот метод называют чуть ли не единственно правильным?
Существует классический подход к созданию
продуктов и сервисов,
характерный в первую
очередь для ИТ-индустрии. Этот подход
называется каскадная, или итеративная методология разработки. В английской
терминологии такой подход называют waterfall development (от англ.
- водопад). Почему его называют водопадом? Потому что при такой схеме разработки, однажды утвердив план программного продукта, вы не сможете
этот план остановить или изменить до его
создания.
Аgile - подход инновационного переосмысления создания нового продукта или услуги. В его
основе очень простая идея: каждый участник процесса, каждый сотрудник этой «конвейерной сборки» должен вовлекаться в процесс
переосмысления своих задач и общего
дела. Каждый может остановить конвейер и внести
свои рациональные предложения.
В большинстве организаций при создании программных продуктов люди, ответственные за те или иные этапы проекта, находятся в самых
разных, зачастую конфликтующих между собой, подразделениях. Ни для
кого не секрет,
что сотрудники отдела эксплуатации, тестировщики и разработчики
обычно находятся в конфликте
друг с другом.
И если
продукт не работает
и не приносит
бизнесу прибыль, то каждый норовит обвинить другого. Хотя на самом
деле в таких
случаях виноваты, как правило, все.
Метод Agile подразумевает вовлечение всех участников процесса разработки программного продукта, оставляя участникам привычные компетенции. Подобный подход позволяет понять, что все они работают ради одной и той же
конечной цели - качественного продукта для своих клиентов.
Так происходит изменение бизнес-культуры
самого предприятия. В рамках
программ МBА есть целый курс, который касается организационной структуры компании. В нем
существует понятие эквилибриум, когда внутри начинающих компаний и стартапов
все делают все, зачастую именно поэтому там рождается дружный коллектив, эффективно выступающий на рынке.
И с точки
зрения эффективности и вывода
на рынок
новых идей, это идеальная организационная структура.
Безусловно, есть организации, которым Аgile вовсе не нужен.
Например, государственные ведомства. Их деятельность
основывается на законодательстве.
Мы не сможем
взаимодействовать с государством,
если правила игры меняются каждый день.
Таким образом, мы имеем
две радикальные противоположности организационной инфраструктуры. С одной
стороны - строжайшая бюрократическая заформализованная организация, которая применяется в тех
или иных случаях и хорошо
работает в определенных
ситуациях. И полная
диаметральная противоположность ей - молодые стартапы, команды единомышленников, которые действительно создают нечто новое, и Agile
находится гораздо ближе к состоянию
эмоционального коллектива, который работает на конечную
цель, работоспособный качественный (программный) продукт. И поэтому
проблемы, возникающие на любом
этапе, - это проблемы всех людей, и все,
кто способен их решить,
вовлекаются в этот
процесс.
Переход большого классического бизнеса (Enterprise) к Agile
Это крайне важный вопрос, и он очень
интересен. Об этом
говорит весь мир, об этом же
сказал Герман Греф. Он сказал:
«Ребята, мы - банк, наши конкуренты не банки,
наши конкуренты - молодые компании, привносящие ""цифру"" в общество».
Передовой бизнес базируется на трех
китах: опыт и знания
в индустрии
(в которой
работает бизнес), разработка продуктов и сервисов
по методологии Agile и самое
главное - инновационная культура.
Ведущие ИТ-компании,
легко скопировав банковские продукты и сервисы,
начинают их достраивать
(или преобразовывать) на такой
уровень, на который
банк их вывести
не может,
поскольку традиционная финансовое учреждение не обладает
достаточно развитой инновационной культурой.
Очень простой пример - микрофинансовые организации. Это фирмы,
создающие сервис буквально щелчком пальцев. Сегодня компания появилась, выдала кредит под невероятно высокий процент - завтра у нее
прибыльность в разы
больше, чем у банка.
Такие организации могут мгновенно перестраивать свои сервисы и продукты,
оперативно выходить на новые
рынки, вытесняя классические банки.
Похожие вещи происходят не только
в банковской
индустрии, это происходит во всех
индустриях и сферах
бизнеса. Мобильные операторы начинают заниматься платежными системами. Uber изменили
подход к пассажирским
перевозкам по всему миру за несколько
лет, а Airbnb
сделали то же
самое с гостиничным
сегментом туристического бизнеса.
Гибкое планирование
При каскадной разработке вы должны
планировать на год
вперед. Но если
что-то
изменится - например, потребуется больше серверов или других компонентов, то возможен такой сценарий, когда проект будет остановлен - ведь будет нужно проводить новый тендер, покупать новую инфраструктуру и т.д.
То есть Agile становится не просто
методологией создания нового ПО, а системой
гибкого планирования развития всей компании. Должна быть построена такая инфраструктура, которая так же
гибко реагирует на запросы,
поступающие от клиентов,
и требования,
меняющиеся в процессе
разработки программного продукта и его
эксплуатации (это, кстати, подразумевает тотальный переход к облачным
технологиям).
Для гибкого планирования необходимо понимать и анализировать
каждый бизнес-процесс.
А это
уже следующий этап развития компании - ее дигитализация.
Для современного цифрового предприятия должно быть три компонента: методология гибкой разработки (agile development), гибкая подстраиваемая под него инфраструктура (agile infrastructure) и аналитика
больших данных. Вот какой
случай произошел с моим
коллегой из США.
Он ехал
на такси
в аэропорт,
опоздал на самолет,
написал в твиттере,
что из-за пробки
опоздал на свой
рейс. Когда он приехал
в аэропорт,
ему пришла SMS: «Перейдите, пожалуйста по ссылке - для вас готов электронный посадочный талон. Авиакомпании ХХХ перебронировала вас на следующий
рейс».
Это реальный пример, когда система авиакомпании анализирует разрозненную информацию и на ее основе
принимает решения с целью
повышения качества услуг для своих клиентов.
Отдельный вопрос: хочу ли
я, чтобы по каждому моему чиху во внешнем
мире что-нибудь
происходило?
Еще один пример - Sundance Institute, глобальная платформа для поддержки независимого авторского кинематографа.
За последние 30 лет
Sundance Institute обзавелась большим объемом информации о фильмах,
съемочных группах, активности зрителей. Чем больше
накапливалось информации, тем сложнее было ее структурировать
и соответственно
использовать.
Разрозненность данных и отсутствие
единой базы не позволяли
привлекать специалистов из прошедших
проектов и тормозили
новые.
Руководство фестиваля пригласило инженеров Pivotal (компании входящей в федерацию
EMC), чтобы создать единый портал, который объединил в себе
всю связанную с Sundance
информацию. В результате
платформой пользуются как сотрудники фестиваля, волонтеры, профессионалы индустрии, так и любители
кино.
Каким же
образом классическим предприятиям внедрить философию Agile? Что нужно
сделать, чтобы разрозненные отделы большой компании превратить в команду
единомышленников, как в стартапах?
Лидерство и ответственность
- вот единственный ответ. Руководитель должен в первую
очередь сам привносить что-то
новое в компанию
каждый день, и это
стремление к инновациям
станет основой корпоративной культуры организации. Инновационная культура закладывается в принципах
формирования команды менеджеров, темах дискуссий, которые происходят на всех
совещаниях, постановке стратегических задач, миссии и видения
компании. И без
этого никак.
- И о стратегии внедрения и области применения Agile и SCRUM от Михаила Софронова**
Рассказываем, что представляет собой лежащая в основе методология, раскрываем основные понятия, объясняем, как устроена agile-команда и как оценивается ее эффективность.
Agile - это целое семейство методологий гибкого управления проектами. Интересно, что само понятие управления здесь оказывается не вполне верным. Было бы более точным употреблять формулу «Agile - это способ командного взаимодействия, позволяющий совместно создавать продукты». Однако мы слишком привыкли к силе вертикальных, иерархических связей, поэтому и здесь устойчивым стало употребление слова «управление».
Неудобные вопросы
- Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
- Как справиться с тем, чтобы разработка плана проекта не занимала до 30% времени от всего объема его реализации?
- Как, в конце концов, добиться того, чтобы эти планы соблюдались?
Управленцы самого разного уровня, от менеджеров низшего звена до директоров корпораций и государственных чиновников, бились над этим десятилетиями. Но до тех пор, пока единственным известным способом более-менее контролируемого создания продуктов и разработки проектов оставался поэтапный, - шаг за шагом, одно за другим, ничего с этими вызовами было не сделать.
Для того, чтобы перейти на качественно новый уровень проектной работы, потребовалось коренное изменение парадигмы.
Оказалось, что искать ответы на большинство этих больных вопросов просто незачем. Их нужно снять, а понятия, их породившие, по возможности упразднить. Так на месте поэтапной waterfall-разработки возникли гибкие методологии.
Делай сразу!
Главное мерило эффективности, принятое в гибкой методологии, - продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это - как в знаменитой мотивирующей формуле «сделано - это лучше, чем идеально». Реализуйте первую функцию и начните тестировать ее, создавая следующую, и так раз за разом - вот главное правило.
Этап разработки в Agile, это самое «раз за разом», называется итерацией. Итерации имеют одинаковую длительность на протяжении всего проекта и в среднем составляют две недели. В рамках отдельной итерации выполняется конкретная задача, главным свойством которой является то, что ее решение должно обновлять продукт до новой версии или увеличивать его эффективность. Именно по этому признаку такие задачи и отбираются.
Как итеративный подход обеспечивает гибкость? Благодаря тому, что отдельные процессы могут идти параллельно и независимо друг от друга. Да, надо признать, что это может увеличить конечный срок разработки от идеи до полностью готового продукта. Но в том-то и дело, что рабочий, функциональный и уже способный встретиться с конкурентами и порадовать пользователей продукт создается в Agile гораздо раньше, а цикличность доработок позволяет добиться куда лучшей проработки таких функций и возможностей, до которых при плановой работе руки бы не дошли никогда.
Горизонтальная организация
Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле - лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах product owner’у, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.
Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:
Еще одна важная ценность agile-команд - взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер - маркетологом.
Но иметь базовые знания о смежных специализациях в гибкой разработке необходимо.
Изначально предполагалось, что это просто будет повышать эффективность работы и уровень взаимопонимания в команде, но сегодня, с развитием нейронаук, стало понятно, что такой подход вдобавок обеспечивает поддержание мозга в тонусе и динамичное создание новых нейронных связей. Такое перекрестное опыление знаниями в Agile называется t-shape. Иллюстрация ниже объяснит, почему так, лучше всяких слов.
Как внедрить Agile?
Переход от каскадной разработки, до сих пор привычной для многих организаций, к гибким методам работы над проектами может быть довольно болезненным.
Во-первых, вам предстоит упразднить иерархичность и при этом добиться того, чтобы все участники процессов смогли на равных разделить ответственность за результат.
Во-вторых, переход к итеративной разработке заставит сосредоточиться на том, чтобы каждый из этапов гарантированно привносил в продукт что-то новое. Это непросто, инерция плановой разработки будет преследовать вас первые несколько месяцев.