Как появился agile. часть 2. поиски

Содержание

Плюсы Agile

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

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

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

История зарождения Agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения. Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта . Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях. Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы . Популярность облачных технологий (SaaS-, PaaS-, IaaS- и других сервисных моделей) также стимулирует распространение эджайл.

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

  • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
  • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
  • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
  • изменения в проекте приветствуются и быстро включаются в работу.

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

Краткое видео о том, что такое Scrum (english).

Scrum

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

Впервые термин прозвучал в 1986 году. Японские исследователи Икуджиро Нонака и Хиротака Такеучи в статье The new New product development game сформулировали принципы, позволяющие быстрее создавать новый продукт. Среди условий такой разработки назвали самоорганизующуюся команду специалистов, их полную свободу в творчестве и работе — без ограничений со стороны топ-менеджмента. Этот подход авторы описали так:

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

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

Главное для Scrum-подхода — особая динамика работы, когда команда постоянно обсуждает, как сделать продукт лучше. Такой ритм авторы сравнивают с регби: игроки передают мяч друг другу, но при этом команда движется по полю как единое целое, достигая общей цели. Из регби и пришел термин «скрам» — это схватка из-за мяча.

Методика, предложенная Нонака и Такеучи, нашла применение в IT-сфере, разработке инженерных решений в машиностроении, электронике. В 90-х Scrum оформился как проработанная и цельная методология, оброс конкретными приемами, помогающими с нуля наладить работу команды. Благодаря Кену Шваберу и Джеффу Сазерленду Scrum пришел в IT и приобрел популярность среди разработчиков — некоторые даже считают эту методологию революционной.

Командный дух

В команде, работающей по принципам Scrum, нет внутренней иерархии: ни руководителей, ни подчиненных, ни указаний-приказов. Есть два особых члена группы: product owner — владелец продукта, и scrum master — скрам-мастер.

Product owner лучше всех знает, каким должен быть продукт. Зачастую это заказчик, его представитель или сотрудник, ответственный за взаимодействие с клиентом. Он должен ясно понимать, что именно требуется конечному пользователю программы. Все пожелания и предложения по функциональности и внешнему виду продукта (в Scrum они называются stories — истории) он заносит в специальный список — Product Backlog. Бэклог формируется до старта разработки и по ходу постоянно пополняется. Здесь же указывают приоритеты доработок.

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

Рывок! Еще рывок!

Работа над программой в Scrum, как и в Agile в целом, разделена на итерации. Здесь любят спортивную терминологию: эти отрезки разработки называют забегами или спринтами. Каждый начинается с того, что команда сообща определяет, какие именно истории из списка владельца продукта она сможет реализовать на этом спринте. Выбранные идеи переносятся в отдельный список — sprint backlog. Фиксируется цель: что конкретно команда сможет продемонстрировать пользователю в итоге. Задачи распределяют, и начинается забег.

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

В конце забега результаты демонстрируют владельцу продукта. И немедленно начинают новый спринт — очередную итерацию цикла разработки.

Важно помнить, что в итоге скрам-забега пользователь получает готовую версию программы: можно запускать и работать. На ранних этапах проекта программа может быть способна только вывести сообщение «Hello, world!»

Но даже самый первый спринт должен дать результат: программа уже есть и она запускается.

Когда нельзя внедрять Agile

Есть простое правило:

Agile методология дает не только результат:

Если вы хотите рассмотреть возможность внедрения гибкого управления проектами Agile, значит ваша компания готова к интеграции гибких методов управления проектами в Ваши бизнес-процессы:

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

И повторюсь еще раз: Agile методология это мышление, а не только инструменты.

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

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

Горизонтальная организация

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

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

Ещё одна важная ценность agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер — маркетологом.

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

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

Темная сторона силы: недостатки Agile

Не факт, что программа когда-нибудь будет завершена.

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

Но если вы планируете долговременное сотрудничество с заказчиком и он готов платить за все время разработки — почему нет?

Пользователь требует все и сразу.

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

Работа над проектом требует не только профессионализма разработчика, но и сознательности пользователя. А спросите у программистов, часто ли им встречались адекватные, понимающие пользователи.

«Золотые пользователи»

Если в обсуждении участвуют несколько заказчиков (пользователей), их вклад в проект часто разномасштабный. Кто-то более внимателен и вносит много предложений, а другой сидит молча. Обсуждение проекта с широким охватом может и вовсе проходить на форуме.

Фактически это приведет к тому, что небольшая группа активистов будет уводить разработку по интересному лично им пути, формировать программу под себя. Мнения других пользователей уйдут в тень.

Строительство без чертежей

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

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

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

Постоянная спешка

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

Это сказывается на качестве кода: бывает, фрагменты программы пишутся по принципу «и так сойдет», без попыток сделать их более изящными или эффективными. Разработчик осознает, что такой код годится только как временное решение, но вернуться и переписать получается редко. Работает — и хорошо.

До тех пор, пока работает…

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

Внедряйте спринты

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

Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.

Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.


Так выглядит бэклог со спринтами.

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

Agile — философия, Scrum — ее реализация

Таким образом, Agile — это не методология разработки, а система ценностей, помогающих разработчикам делать новые продукты быстрее и с бОльшим эффектом для бизнеса:

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

Образ мышления Agile сейчас чаще всего реализуется через фреймворк Scrum, поэтому неудивительно, что эти два слова очень часто используются вместе.

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

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Scrum и Канбан на масштабе крупной компании

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

Однако есть и разница. 

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

Приходится применять фасилитацию на большом масштабе, проводить громоздкие и дорогостоящие встречи (например, Big Room Planning), чтобы все вовлеченные Scrum-команды успели поговорить, договориться и двигаться дальше с общим пониманием целей, задач и контекста.

Так как у каждой Scrum-команды своя собственная Scrum-доска и свой пул задач, то в процессе движения нужны синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Scrum-мастера или Владельцы продуктов), чтобы сделать прозрачным для всех текущий статус движения к общей цели, проблемы и необходимость разрешать зависимости. 

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

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

На рисунке показаны разные типы встреч, которые могут присутствовать в Канбан-методе.

Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг).

Другие носят стратегический характер (ревью рисков, ревью сервиса поставки) и проводятся раз в несколько месяцев

С другой стороны, на разных уровнях иерархии надо собирать разные данные.

На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.

На уровне среднего менеджмента нужно собирать данные о работе крупного подразделения (например, департамента) над разными проектами.

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

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

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

Создание Agile

Созданный в феврале 2001 году «Манифест Agile» подписали ведущие IT компании и  эджайл практически за 15 лет распространился на все бизнес-процессы и сферы бизнеса, что фактически подчеркивает гибкость и адаптивность самой методологии.

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

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

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

Agile команды объединяют

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

Agile команда в российском бизнесе

У небольших компаний очень большое преимущество при внедрении Agile, так как эджайл создан для небольших команд: 7-10 человек идеальный состав для Agile команды.

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

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

Agile изменяет мышление и мировоззрение, фокусируясь на достижении цели, используя коммуникации, а не командно-административную структуру.

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

Ошибочно также полагать, что Agile может увеличить результативность вашей компании моментально, все зависит от двух факторов:

  1. от ваших сотрудников
  2. и ваших бизнес-процессы,

а они уникальны в каждой компании!

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

Начали использовать микросервисы

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


Разница между монолитной архитектурой проекта и использованием микросервисов

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

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

преимущества

недостатки

Независимое обновление

Сложно выкатывать

Масштабирование

Сложно тестировать

Возможность экспериментов

Респределительная система

Простота

Сложно эксплуатировать

Поддержка любым разработчиком

Несогласованная БД 

Зачем нужен Agile?

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

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

Что мы будем понимать под Agile?

(Несколько абзацев для тех, кто в танке. Ну, и для того, чтобы сверить часы — а то бывает, что любой бардак называют словом «Agile»)

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

При этом важно помнить, что Agile — это подход, который стоит применять для проектов, связанных с высокой неопределенностью требований (не очень понятно на старте, что мы хотим получить в результате), и высокой технической неопределенностью (не очень понятно на старте, как мы будем это делать).  Если всё понятно как делать, внедрение стандартное, все требования в начале уже известны — необходимости городить Agile нет. 
Потому что работать по Agile совсем не так просто, как полагают те, кто бодро делает заявления в стиле “Мы не документируем — у нас Agile”!.

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

Делай сразу!

Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это как в знаменитой мотивирующей формуле: «„Сделано“ — это лучше, чем „идеально“». Реализуйте первую функцию и начните тестировать её, создавая следующую, и так раз за разом — вот главное правило.

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

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

Какие навыки нужны?

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

  • Глубинное слушание. Тоже известная вам тема. Вожделенное состояние всех начинающих, да и не начинающих коучей – это способность видеть, понимать, что есть за словами собеседника. Да, тут главное не путать с попыткой диагностировать и интерпретировать чужие слова.
  • Безоценочное восприятие. Очень мега крутой навык, мне кажется. Но знаете, его очень часто понимают не верно. Я как-то за кружкой пива с приятелем, я ему сказал, что очень хочу лучше стать в безоценочном восприятии. Он сказал: «Что ты? Не надо это, опасная ерунда, я пробовал это». Пробовал он, да? У собеседников возникает ощущение, что тебе на все пофиг. Ребята, безоценочное восприятие должно вызывать у собеседника ощущение, что его безоговорочно на 100% принимают его таким какой он есть. Это как бы противоположное от ему все пофиг.
  • Безграничная вера в людей. Куда без этого в нашей профессии.
  • Осознание своих убеждений.
  • Понимание границ ролей, ответственности ролей.
  • Долгосрочное мышление.

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

Ценности Agile простыми словами

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

  1. люди,
  2. работающий продукт,
  3. сотрудничество с заказчиком,
  4. готовность к изменениям.

Посмотрим, зачем нужны эти ценности Agile.

1. Люди и их взаимодействие важнее процессов и инструментов

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

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

2. Работающий продукт важнее исчерпывающей документации

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

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

3. Сотрудничество с заказчиком важнее согласований условий контракта

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

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

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

4. Готовность к изменениям важнее, чем следование плану

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

Что касается готовности к изменениям со стороны представителей заказчика (клиента), то в такой ситуации они могут пожертвовать чем-то запланированным (но менее ценным) ради новых возможностей. Готовность заказчика оперативно жертвовать какой-то частью запланированного также нужна в ситуации, когда исполнители столкнулись с непредвиденными проблемами в ходе разработки.

Осознанность мышления и открытость к изменениям

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

Так как же можно изменить образ мышления? Он начинается с осознания того, как формировались текущие установки человека

Кроме того, очень важно прививать убеждение в том, что мышление можно развивать и улучшать (Growth Mindset, мышление «роста», как показано на рисунке 1, в противовес Fixed Mindset). Лидерам также необходимо иметь в виду, что для управления организационными изменениями (с целью стать бережливым предприятием), традиционные методы управления нуждаются в доработке

Рис. 1. Принятие нового образа мышления требует веры в развитие новых способностей через усилие

В следующих двух разделах описываются ключевые элементы Lean и Agile, которые составляют основу мышления Lean-Agile.