lean agile что это
Знакомимся с Lean: как создать ценность без потерь
Рассказываем, с какого вопроса началась история Lean и как с ним работать.
Что такое Lean
Lean ― это философия бережливого мышления. Подход, который позволяет экономить ресурсы и получать лучший результат.
Цель Lean ― создавать ценность, сокращая расходы на ее производство.
Это не методология, поэтому в ней нет набора готовых практик. Конкретных правил тоже нет, но есть приемы, которые помогают извлекать пользу. Но как разобраться, что значит Lean, если нет методологии и правил? И как придерживаться философии, в которой не на что опереться?
Придерживаться Lean ― значит всегда использовать системный подход, искать и устранять потери, создавать поток. Поток ― это непрерывный процесс создания ценности — не любого продукта, а именно того, который нужен потребителю.
Lean ― это часть философии Agile. Если говорить о разработке ПО, то бережливое мышление ― основа для любой гибкой методологии, например, Scrum, где есть набор принципов и практик, которые пересекаются с ценностями Lean.
Agile, Scrum, Kanban, Lean ― в области управления digital-проектами есть много систем и методологий, в которых легко запутаться. Где-то есть набор практик, как в Scrum, где-то ― только несколько ценностей и никаких правил, как в Lean. Kanban, например, — не методология, а метод ее улучшения. Lean ― вообще философия, кстати, как и Agile. Осталось только понять, как во всем этом разобраться и не сойти с ума.
Digital-индустрия развивается постоянно, поэтому применить себя в этой области, используя вчерашние знания, будет нелегко. Чтобы стать профессионалом, нужно непрерывно совершенствовать уровень мастерства. Можно использовать статьи и кейсы, а можно записаться на офлайн- или онлайн-курсы, чтобы закреплять теоретическую базу на практике.
Чтобы лучше понять, что значит Lean, вернемся к истории и посмотрим, как появились ее основные ценности.
Как создавали Lean
Итак, мы остановились на том, что Toyota никак не могла продать свои автомобили из-за сложной экономической ситуации в стране. Но, как оказалось, дело было не только в этом. Слишком много денег компании уходило на закупку и хранение деталей, исправление дефектов. В результате больших трат на производство получались дорогие машины, которые в Японии были не нужны, а другие рынки уже давно осваивала компания Ford.
Стандартные методы решения проблем не помогали исправить ситуацию, поэтому Toyota ничего не оставалось, как полностью изменить подход к производству.
Системный подход показал, что нужно не увеличивать количество производимых автомобилей, а улучшать их качество и сроки поставки, при этом заметно сократив расходы на производство. Этого можно было добиться, полностью ликвидировав потери. Тогда появился другой вопрос: как это сделать?
Основные проблемы, с которыми борется бережливое мышление: муда ― потери, мура ― неравномерность, мури ― перегрузка. Еще есть кайдзен ― постоянное совершенствование.
Ответом стала новая система работы производства ― Toyota Production System. С ее помощью компания улучшила качество продукции, сократила расходы и сроки на ее создание. Но для этого пришлось полностью изменить подход не только к процессу работы, но и к мышлению сотрудников.
14 принципов производственной системы Toyota
Не бояться идти на жертвы ради будущей выгоды.
2. Непрерывность производственного потока
Создать единый и непрерывный поток производства.
Потребители должны получить товар точно в срок.
4. Равномерность в распределении нагрузки
Все участки производства должны работать одновременно и с одинаковой нагрузкой.
5. Остановка производства при сбоях
Любой рабочий имеет право остановить процесс производства, если на его участке произошел сбой.
6. Превращение опыта в стандарт
Опыт и знания, полученные в процессе работы, должны стать стандартом компании.
7. Визуальный контроль
Все участники процесса производства должны наблюдать за работой всей системы целиком, иметь общую картину происходящего.
8. Внедрение только проверенных технологий
Любая технология должна быть несколько раз проверена перед тем, как стать частью производственного процесса.
9. Воспитание лидеров внутри компании
Важно замечать и поддерживать стремления заинтересованных в прогрессе сотрудников и давать им возможность развиваться.
10. Формирование и поддержка рабочих команд
Необходимо объединять людей в небольшие группы, чтобы улучшить их результаты.
11. Уважение и помощь в развитии коллег
Компания должна помогать в развитии поставщикам и командам, с которыми взаимодействует. Это идет на пользу общему делу.
12. Контроль руководителя
Перед принятием важного решения руководитель должен увидеть ситуацию целиком.
13. Принятие решений согласием большинства
Решение считается верным, если большая часть сотрудников считает его таковым.
14. Непрерывный анализ и совершенствование процесса
Не важно, насколько хорошо идут дела, всегда можно сделать лучше. Поэтому команда должна постоянно анализировать, оценивать и улучшать процесс и результат своей работы.
Когда работа согласно этим 14 принципам была налажена, Toyota смогла занять лидирующую позицию в автомобильной промышленности. Цель была достигнута, а технологию lean-производства теперь используют в разных областях по всему миру.
Как использовать Lean при разработке программного обеспечения
В начале XXI века разработчики Том и Мэри Поппендик поняли, что систему Toyota можно применить в мире программного обеспечения. Они впервые использовали принципы бережливого мышления, чтобы помочь разработчикам. Так как Lean ориентирована на клиента и его потребности, при работе над программным обеспечением нужно создать полезный продукт, но сократить ресурсы, необходимые для его производства.
Lean-разработчики не используют все 14 принципов системы Toyota, но ориентируются на основные ценности бережливого мышления.
Если действие не улучшает качество продукта, не приносит прибыли заказчику и не экономит время разработчика, то его нужно исключить.
Чтобы создавать качественный продукт, команда должна постоянно совершенствовать свои знания и навыки. А руководитель ― обеспечивать команду временем и ресурсами.
Принимать важные решения в последний момент
Иногда запоздало принятое решение может испортить всю проделанную работу, но для Lean откладывать принятие решения до последнего ― это способ собрать как можно больше информации о вопросе. А значит, быть уверенным в его правильности и избежать ошибок.
Доставлять ценность как можно раньше
Чем раньше команда покажет свои наработки заказчику, тем быстрее получит от него обратную связь. Разработчики будут уверены, что все делают так, как хочет клиент, и смогут все изменить при необходимости.
Когда команда работает сообща и понимает свою ценность, процесс идет быстрее и эффективнее. Поэтому важно доверять сотрудникам и ценить то, что они делают.
Создавать целостный продукт
Команда должна сфокусироваться на качестве, не допускать дефектов и всегда ставить в приоритет потребности заказчика.
Следить за общим процессом
Чтобы работа шла хорошо, каждый в команде должен понимать задачи и иметь возможность постоянно видеть весь процесс. Вся информация по проекту должна быть доступна в любое время. Для этих целей в гибких методологиях (Scrum, Kanban) используют доску, где отмечены цели, задачи и процесс их выполнения.
Виды потерь при разработке ПО
Это может быть написанный, но неиспользованный код. Лишний код — зря потраченное время.
Возможности, которые добавили в ПО, но которые не используются потребителем, не приносят пользы. Клиенту нужны только полезные функции.
Если разработчик приступил к одному проекту, а потом его перекинули на другой, придется заново вникать и собирать информацию. То же самое происходит, если в команде проекта появляется новый разработчик. Весь процесс начнется сначала.
Проект или его части передают из одних рук в другие. Так происходит передача не только проекта, но и ответственности за него. В результате команды теряют контроль над ситуацией.
Переключение между задачами
Когда один разработчик выполняет два проекта одновременно и постоянно должен переключаться с одних задач на другие, он теряет больше времени, чем мог бы, работая над одним проектом.
Если команда постоянно занимается согласованием документов с заказчиком, то тратит много времени и в результате срывает сроки проекта.
Команда должна следить за качеством кода еще на начальных этапах. Если по окончании работы будут найдены критические ошибки, то придется начинать проект сначала.
Как правильно создавать ценности
Любой бизнес создает ценности: продукты или услуги, которые компания продает. Ценность продукта определяют пожелания потребителя, а задача Lean ― оптимизировать процесс производства таким образом, чтобы создавать ценности, уменьшая издержки.
Бережливое производство ― это системный подход, поэтому создание и продажа продукта рассматриваются как единый путь ценности от поставщика до потребителя. Всесторонняя оптимизация пути создания продукта называется lean-менеджмент.
Создание продукта состоит из разных процессов. Идея Lean в том, чтобы работать только с полезными, а лишние исключить.
Процессы, которые создают ценность
Это все, что ведет к нужному результату. Любой процесс, который помогает сделать продукт быстрее и лучше, должен постоянно совершенствоваться.
Процессы, которые не создают ценность
Все, что не приносит пользы: тормозит работу или плохо отражается на качестве продукта, не несет ценности для потребителя. Такие процессы нужно сократить до минимума или исключить полностью.
Для lean-мышления потери недопустимы, поэтому их нужно исключить.
Lean-менеджер устраняет организационные и технические проблемы при создании и распространении продукта, быстро реагирует на изменения спроса и ситуации на рынке. Параллельно учит и развивает свою команду, используя lean-ценности.
Вы узнали, что такое Lean, поняли, что такое lean-менеджмент и lean-философия. Теперь можно начинать внедрять полученные знания, но лучше сначала посмотреть, как работают практики. Учиться хирургии лучше у практикующего хирурга, одной теории мало. Так же — и с управлением.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.
Agile или Lean: Ага ага, какая разница-то?
Является ли Agile аналогичным Lean? Когда люди говорят “Agile”, подразумевают ли они на самом деле Scrum? Или люди все еще используют разные типы Agile и почему?
Получая много вопросов в прошлом, я решил расставить все точки над “и”.
Lean пришел из бережливого производства (Lean Manufacturing), он имеет набор принципов, относящихся к качеству, скорости и клиентоориентированности (то же, что мы пытаемся сделать в agile разработке, правильно?)
Мэри и Том Поппендик адаптировали принципы “Бережливого Производства” для разработки программного обеспечения, и я верю, что эти идеи являются основами и причинами того, как agile работает:
1. Устранение потерь.
2. Повышение качества.
3. Создание знаний.
4. Отсроченные обязательства.
5. Быстрая поставка.
6. Уважение людей.
7. Полная оптимизация.
В двух словах, Lean говорит: безжалостно избавляйтесь от всего, что не добавляет дополнительной ценности, и делайте только то, в чем вы абсолютно уверены, что это нужно делать в настоящий момент. Устранять потери означает устранять бесполезные собрания, задачи и документацию. Но это также означает избавляться от временных потерь в любых известных задачах, которые нужно будет сделать в будущем (все постоянно меняется и часто в итоге становится ненужным. Если бы мы сделали что-то наперед, то мы должны были бы потратить время на переделку этого, потому что условия или наше понимание уже изменилось в последствии). Это также означает, что мы должны избавляться от не эффективных способов работы, таких как многозадачность, чтобы мы могли делать поставки быстро.
Lean также делает очень сильный акцент на то, что называется “системой”, т.е. что команда работает как единое целое. Мы всегда должны смотреть на нашу работу “с высоты”, чтобы быть уверенным, что мы улучшаемся в целом. Например, много менеджеров хотят “занять” работой каждого разработчика на 100%, но в большинстве случаев это, на самом деле, контрпродуктивно. Давайте не будем заставлять людей кодировать то, что не нужно (или полностью не определено), только ради того, чтобы они кодировали, потому что в будущем для нас это создает еще больше работы.
Подводя черту, Lean говорит: уважайте людей. Это означает давать людям ту работу, которую они лучше всего знают как надо делать. Дайте им то, что им необходимо, чтобы быть эффективными и затем доверьте им сделать это. Суть программной разработки в постоянном обучении; поэтому строить работу нужно так, чтобы убеждаться, что мы постоянно учимся. И поэтому нужно откладывать принятие решения до последнего момента (ведь мы будем на тот момент знать больше). В итоге разработка идет путем создания качественного продукта, потому что нет другого способа, обеспечивающего постоянную быструю поставку, если нужно возвращаться и убирать наш беспорядок.
“Организации, которые по-настоящему следуют Lean, имеют сильное конкурентное преимущество, потому что они очень быстро и в высшей степени дисциплинированно реагируют на рыночный спрос, а не пытаются предсказывать будущее”, – Мэри Поппендик.
Agile
Agile опирается на совокупность ценностей и принципов, изложенных в манифесте Agile. Манифест был ответной реакцией на тяжеловесные методологии, которые были популярны, пока изнемогающие программные проекты, в конце концов, не начинали делать то, что на самом деле нужно, — создавать программное обеспечение, которое помогает клиентам. Я верю, что ценности и принципы Agile работают потому, что наука следует за Lean, и вы увидите множество заимствований, повторяющихся в Agile.
Ценности Agile – это:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условия контракта.
Реагирование на изменение важнее следования первоначальному плану.
Принципы Agile – это:
1. Наивысший приоритет — удовлетворение пользователей.
2. Изменение требований приветствуется.
3. Работающий продукт следует выпускать как можно чаще.
4. Представители бизнеса и разработки должны работать вместе ежедневно.
5. Над проектом должны работать мотивированные профессионалы.
6. Непосредственное общение является наиболее практичным и эффективным.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
9. Постоянное внимание техническому совершенствованию и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы повышение эффективности и соответственно корректировать стиль своей работы.
Любой проект, который следует этим ценностям и принципам, по праву может считаться agile. Тем не менее, безусловно есть наиболее общие практики для agile команд, следуя которым достигается гибкость (agility).
Наиболее общие это: Scrum или Kanban (или гибрид из обоих) для “Управленческих практик”. Экстремальное программирование (XP) для Технических практик (с новыми практиками становится популярным, во многом из-за Lean Statup, такие как непрерывное развертывание и тестирование на проде).
Хорошие agile команды выбирают часть из управленческих и технических практик, те, что лучше для них. (Плохой пример, когда берут только пару практик, ложно веря, что это “их делает agile”)
Благодарности: Спасибо Юрию Прокудину, Екатерине Кивелевой за помощь в подготовке текста.
LEAN + AGILE = AGILEAN или собираем целое по частям
1. Неправильный полёт неправильного шмеля. (Вступление)
Откуда взялись науки математика и физика?
Человечество искало ответы на то, как создан окружающий мир. Частично из любопытства, в гораздо большей мере, из желания управлять этим миром, предсказывать события на основе открытых закономерностей и адаптироваться к ним.
В сегодняшнем состоянии математика и физика не совершенны — это просто системы нашей интерпретации окружающего мира, и они переплетаются и взаимодополняются в вещах, которые просты и нам понятны и начинают расходиться и противоречить друг другу и себе там, где появляются силы, феномены и законы нам непонятные или до конца не познанные. Для того чтобы объяснить эту добавочную сложность, проявляющуюся в мире, приходится вводить новые понятия и системы интерпретации (пример: квантовая физика и математика Лобачевского). И чем глубже простирается наше понимание устройства Вселенной, тем больше правок нам приходится вносить в то, что раньше считалось незыблемым законом.
Есть известный случай, когда на заре аэродинамики учёные попытались рассчитать по её законам полёт шмеля, оказалось, что он летает против законов физики. Причиной, конечно, была не «неправильность» шмеля, а несовершенная научная интерпретация законов природы, которая потом была исправлена, и счастливый шмель вновь залетал, но теперь уже в строгом соответствии с аэродинамикой.
Наверное, самый полезный вывод из этого будет звучать следующим образом: за любой закономерностью или отдельным феноменом стоит система, где все гармонично и взаимосвязано. Это утверждение применимо как к науке, так и к бизнесу.
2. Бизнес как слон
Бизнес организации тоже являются гармоничными системами, функционирующими по строгим законам, представление у человечества, о которых пока далеко не полное.
Все знают притчу о том, как слепые щупали слона за разные места и пытались описать животное. Представление у того, кто держался за хобот, сильно отличалось от того, кто держался за ногу или бивень.
В этом смысле Agile и Lean это разные системы интерпретации одного большого сложного «слона’ или живого мира человеческой организации.
Производственники ухватили этого «слона» за процессы и получился Lean, IT-шники схватили многострадальное животное за человеческое взаимодействие вокруг этих процессов, и получился Agile.
И, несмотря на то, что в процессе развития Lean его приверженцы начали понимать, что без правильного вовлечения и организации взаимодействия людей даже самые совершенные процессы не заработают, а сторонники Agile постепенно приходят к мнению, что практикам Lean есть очень органичное применение в системах Agile, всё равно ещё существуют люди, которые уверенно утверждают, что «место Agile только в IT» или считающие что «внедрили бережливое производство», развесив таблички 5C и проведя несколько тренингов для своих сотрудников.
3. Lean и Agile – есть ли разница?
На первый взгляд она несомненно есть. Lean – сфокусирован на выстраивании идеальных процессов без потерь и их непрерывном улучшении. Agile фокусируется на быстром и эффективном взаимодействии людей вокруг этих процессов, на создании человеческих структур, способных гибко и креативно реагировать на любые изменения и запросы бизнеса.
Но если подумать, разве не очевидно, что две данные системы не просто органично дополняют друг друга, но буквально являются двумя половинками одного целого?
Эффективная, увлечённая и вовлечённая, гибко реагирующая на изменения, команда самоорганизованная вокруг идеальных процессов на принципах непрерывного улучшения – это ли не идеальная форма бизнеса?
Более того, стоит только попытаться начать смешивать эти два подхода на практике, и вы весьма органично вольётесь в царство Agilean. Как насчёт DMAIC в Scrum-формате? Или kaizen-сессии вместо ретроспектив? А может вы хотите вывешивать мероприятия по непрерывным улучшениям на Kanban-доску и отслеживать их выполнение, собираясь около неё всем отделом, перемещая карточки из бэклога в «Done»?
Любая подобная практика показывает отличные результаты и говорит о том, что здесь только sky is the limit.
Пробуйте, экспериментируйте, смешивайте, адаптируйте, создавайте свои уникальные фреймворки, инструменты и методологии и добивайтесь с их помощью невиданных ранее результатов. Если вы знаете, как это делать правильно, то построить организацию с высокой эффективностью, высокой устойчивостью к изменениям рынка, организацию где работать будет не только прибыльно, но и приятно, просто.
«Эффективная, увлечённая и вовлечённая, гибко реагирующая на изменения, команда самоорганизованная вокруг идеальных процессов на принципах непрерывного улучшения» — это не просто организация, это в некотором роде уже социальный феномен. О таких компаниях ходят легенды в мире бизнеса, и сама причастность к ним наполняет сердца сотрудников гордостью.
Как же всё-таки начать её строить и что скрывается за фразой «если вы знаете, как это делать правильно»?
4. Ценности и задачи vs Фреймворки и инструкции
Как попытка построить механизм без знаний законов физики, так и попытка внедрить бизнес-инструмент без знания, какие ценности он олицетворяет и насаждает, обречена на провал.
Наверное, многие сталкивались с феноменом карго-культа при внедрении различных новых бизнес-методологий, когда, к примеру, над кучами мусора висят плакаты 5С или «самоорганизующаяся» команда находится под плотным контролем микроменеджмента руководства. Результатом таких карго-культ внедрений всегда становится недостижение поставленных задач и запланированных эффектов от изменений. Что ещё хуже – организация прививает себе в результате этого стойкое отвращение к любым улучшениям.
«Мы пробовали – это не работает». «Это всё не для нашей отрасли, у нас своя специфика».
Причина всех таких провалов проста – отсутствие понимания, что такое организационная культура, на какие ценности опирается тот или иной её тип и как разные бизнес-инструменты связаны с тем или иным уровнем или типом культуры.
Знаменитое высказывание «культура есть стратегию на завтрак» подразумевает, что внедрение методологии без учёта культурных особенностей организации будет безуспешным.
Очень часто организационная культура ошибочно трактуется, как качество людей.
«Это же работяги, им всё это сложно. Им нужен просто чёткий приказ копать отсюда и до вечера и зарплата в конце месяца. И, конечно, контроль, контроль, контроль».
Знаменитый психолог и специалист по организационному развитию Джон Седдон сказал: «Попытки изменить организационную культуру наивны и всегда обречены на провал. Поведение людей (культура) всегда является продуктом системы. Изменение системы влечёт за собой изменение поведения людей».
Факт в том, что одни и те же люди будут себя по-разному вести, попадая в организации с разными культурами. Человек – социальное существо, одной из главных способностей которого является способность подстраиваться под существующую среду или систему.
И, несмотря на то, что, конечно, для разных людей такая адаптация потребует разных усилий и времени, фактом остаётся то, что, система всегда будет определять культуру. Кроме, может быть, тех уникальных случаев, когда некоторое количество людей определенных взглядов собрались в организацию и проектируют систему исходя из своих культурных особенностей.
Как же правильно формировать желаемую культуру через системные изменения? И что значит внедрять инструмент с учётом тех культурных особенностей, которые он представляет?
Очень часто, когда я рассказываю про Agile, Scrum и их церемонии клиентам в первый раз, я слышу: «Да у нас и так всё это есть. Чем это отличается от наших производственных совещаний? Мы так же обсуждаем рабочие проблемы в команде и как их нам улучшить?»
Ок. Давайте посмотрим. Ведь формально между Agile-ретроспективой и совещанием по разбору результатов рабочей недели нет. Команда собирается в одном кабинете и обсуждает рабочие вопросы. Однако, на практике, напряженная, психологически подавляющая («как бы чего-нибудь не ляпнуть») атмосфера обычного совещания иерархической организации с дежурными ответами «всё в рабочем порядке» оказывается в разы менее эффективней, чем правильно проведенная расслабленная демократичная Agile-ретроспектива, где люди могут сидеть или стоять, как и где хотят. Где любая «ляпнутая» глупость, не только не наказывается, а поощряется. Где нет «запретных» вопросов, и где, в целом, участникам интересно и «безопасно».
Ни разу из моего опыта, я не смог по-настоящему объяснить разницу между этими двумя такими схожими по формату и такими разными по духу событиями на словах. Разницу между одним и тем же инструментом с разным культурным и ценностным наполнением: Лояльность, Порядок, Субординация – в первом случае, и Прозрачность, Гибкость, Психологическая безопасность – во втором.
«Мы серьёзные люди», — говорили мне. – «У нас серьёзная организация и мы здесь решаем серьёзные вопросы. Нам некогда в игрушки играть».
И каждый раз, когда эти же люди в качестве эксперимента проводили обычное совещание в Agile (или, наверно, точнее сказать в “Agilean”) формате, было радостно смотреть потом, как широко открывались их глаза и менялось мнение.
«Это действительно работает, чёрт побери!»
Да, это действительно работает, чёрт побери, и начинает это работать, как только вы перестаёте смотреть на инструменты сквозь призму инструкций и формальных признаков, и начинаете видеть их сквозь призму ценностей.
Проще говоря, вы перестанете «внедрять Бережливое производство» или «внедрять Agile», а научитесь интерпретировать ваши частные бизнес-вызовы как проявление системных или в случае бизнеса, культурных проблем.
5. Agilean вместо Lean или Agile
Чем отличается этот новый подход Agilean, от существующих Lean и Agile или зачем плодить сущности? Там, где нужен Lean – применяй инструменты Lean, там, где нужен Agile, применяй Agile! Логично? Не совсем.
Сочетание компонентов иногда может быть больше, чем его сумма или 1+1 = 3
В нашем случае из сочетания Lean и Agile получается Agilean – философия, трансформационная модель и набор инструментов, основывающиеся на следующих ценностях:
СВОБОДНАЯ КОММУНИКАЦИЯ — это абсолютная прозрачность процессов и решений, общая доступность информации, возможность кому угодно обсудить что угодно с кем угодно внутри компании, если речь идет об улучшении и развитии компании. Без церемоний, бюрократии и иерархических поклонов.
ПСИХОЛОГИЧЕСКАЯ БЕЗОПАСНОСТЬ – это культура демократичности, культура отсутствия «глупых вопросов». Данная ценность пересекается с предыдущей и дополняет её, потому что только в культуре психологической безопасности могут рождаться, свободно обсуждаться и внедряться идеи по улучшению.
НЕПРЕРЫВНОЕ РАЗВИТИЕ – это не только непрерывное улучшение процессов и инструментов компании, это саморазвитие, развитие коллег вокруг вас, постоянный поиск и устранение потерь, повышение личной и командной эффективности, а также уровня счастья всех участников!
ГИБКОСТЬ – незыблемых догм и правил на все случаи жизни для реализации ценностей выше не существует, поэтому обязательным условием разработки правильных стандартов и их постоянной адаптации к непрерывно меняющемуся миру является гибкость. Постоянные эксперименты, поиск решения при помощи метода проб и ошибок, прототипирование и дизайн-мышление – это гибкость. Постоянная работа в команде, умение прислушиваться и уважать чужое мнение – это гибкость.
Учитывая, что, применяя подход Agilean каждый может строить и разрабатывать свои уникальные инструменты в зависимости от своих задач, контекста и культурных особенностей, можно назвать Agilean — сверхгибкими технологиями или универсальным подходом построения культуры стартапа, где все подчинено одному — целям всех сотрудников компании.
Задача – создание эффективной, увлечённой и вовлечённой, гибко реагирующей на изменения, команды самоорганизованной вокруг идеальных процессов на принципах непрерывного улучшения.
Наборы инструментов постоянно меняются и адаптируются. Нет лучших практик есть хорошие практики для данного места и времени, а главный смысл фреймворков только один – формировать, реализовывать и поддерживать выбранные ценности.