Agile Ценности и Принципы | Полное руководство по гибким ценностям и принципам
Обзор гибких ценностей и принципов
В этой статье представлен обзор наиболее часто используемых ценностей и принципов в Agile. Неудивительно, что Agile предложил эффективную замену традиционной модели управления проектами с использованием водопадов. Из-за обременительного, жестко медленного и ориентированного на документы метода разработки продукта команда из 17 системных разработчиков (называемая «Agile Alliance») выпустила «Agile Manifesto» в 2001 году.
Agile Manifesto получил глобальное признание и может быть определен как документированный набор из 4 значений и 12 принципов, который предлагает разработчикам рекомендации по разработке системы / приложения.
Таким образом, Agile Manifesto содержит «4 ключевых значения» и «12 соответствующих принципов», которые направляют гибкую методологию разработки системы. Agile Manifesto служит в качестве руководства для обеспечения высокого качества продукции для клиентов.
Ценности гибкого манифеста
Agile Manifesto состоит из 4 значений. Позвольте нам понять их в деталях.
Значение 1 — (отдельные лица и взаимодействия имеют большее значение, чем процессы и инструменты)
Люди являются ключевыми факторами, способствующими существенному развитию бизнеса и пониманию потребностей клиентов. Разработка хороших продуктов требует эффективной командной работы и взаимодействия, независимо от инструментов, предоставляемых людям.
Невозможно разработать отличные продукты, не понимая требований клиентов. Следовательно, индивидуальные взаимодействия помогают создавать специфичные для клиента продукты. Простое использование процессов и инструментов не только делает бизнес вялым и невосприимчивым к изменениям, но также приводит к неспособности оправдать ожидания клиентов.
Значение 2 — (Рабочее программное обеспечение имеет значение по сравнению с подробной документацией)
В начальные времена огромное количество времени было потрачено на документацию, которая включала бы технические детали и спецификации.
Этот исчерпывающий и жесткий метод выполнения специфических для документа инструкций привел к задержкам проекта и замедлению поставок продукции. В конечном итоге, конечный продукт не будет соответствовать ожиданиям клиента или станет устаревшим.
С внедрением Agile акцент сместился на рабочее программное обеспечение с документооборота. Работающее программное обеспечение обеспечивает эффективную адаптацию к изменениям и лучшее понимание требований клиентов. Таким образом, Agile ограничивает использование документов только «пользовательскими историями», которые определяют разработчиков при выполнении задач.
Значение 3 — (партнерство с клиентами имеет большее значение, чем переговоры по контракту)
В традиционной модели Waterfall клиенты общаются с разработчиками о конкретных требованиях до возобновления работы проекта. Обычные договорные методы обсуждения создают стену между заказчиками и разработчиками. Участие клиентов ограничено началом проекта и готовностью продукта к доставке.
И участие клиента не происходит во время процесса изготовления.
И наоборот, в соответствии с манифестом Agile Values and Principles, участие клиентов поощряется на протяжении всего процесса создания или создания. Гибкий подход увеличивает участие клиентов на регулярной основе для своевременных демонстраций. Это не только помогает понять требования клиентов, но и позволяет им создавать ценность. Таким образом, сотрудничество с клиентами на протяжении всего жизненного цикла продукта составляет основу гибкого подхода.
Значение 4 — (Быть адаптивным к изменениям вместо того, чтобы быть конкретным планом)
Учитывая нестабильную деловую среду, происходят технологические достижения и меняются потребности клиентов. В традиционном управлении водопадом изменение рассматривается как стоимость и ее следует избегать. Кроме того, традиционное управление проектами является жестким и имеет меньшую гибкость. Это препятствует адаптации к изменениям, и со временем план становится излишним.
Однако Agile рассматривает изменения как ценный агент и предлагает эффективное реагирование и адаптивность к ним. Подход Agile, который состоит из более коротких итераций и спринтов, позволяет добавлять новые атрибуты к продукту в последовательных итерациях с периодическими интервалами.
Принципы Agile Манифеста
12 принципов Agile, распространяемых Agile Alliance:
1) Одним из главных приоритетов гибкого подхода является стремление к удовлетворению клиента за счет быстрой и постоянной доставки продуктов с добавленной стоимостью.
2) Гибкий подход должен охватывать изменения, даже на более поздних этапах развития. Изменения считаются ценным агентом, предлагающим конкурентное преимущество для клиентов.
3) Рабочее программное обеспечение должно доставляться клиентам для любых отзывов или предложений с периодическим интервалом в недели или месяцы, предпочтительно в более короткие промежутки времени.
4) Управление бизнесом и разработчики систем должны работать совместно на протяжении всего цикла проекта.
5) Гибкий подход заключается в том, чтобы назначать проекты мотивированным людям и предоставлять людям хорошую рабочую среду и систему поддержки, прививая им доверие к выполнению работы.
6) Agile Ценности и Принципы направлены на то, чтобы способствовать личным дискуссиям и продвигать их как эффективное средство общения с командой разработчиков и внутри нее.
7) Рабочее программное обеспечение является одним из основных средств измерения прогресса системы в Agile.
8) Гибкий подход направлен на содействие последовательному и устойчивому прогрессу в развитии системы. Заинтересованные стороны обязаны поддерживать постоянную и постоянную скорость в разработке продукта.
9) Постоянное обновление благодаря постоянному технологическому обновлению и эффективности способствует гибкому подходу.
10) Гибкий процесс заключается в принятии простоты путем сокращения комплексных задач и сосредоточения внимания на задачах, которые по существу повышают ценность.
11) Самоорганизованные команды помогают создавать хорошие структуры, требования и разработки.
Agile команды проактивны, что позволяет им преодолевать любые препятствия и сводить к минимуму ошибки для достижения совершенства.
12) Agile команды постоянно обновляются и стремятся стать более продуктивными, эффективно адаптируясь к изменениям. Команды разработчиков постоянно формируются и находятся в мире с изменяющимися внешними условиями. Это позволяет постоянно импровизировать, чтобы поставить ценность. Периодическая обратная связь от клиентов позволяет команде разработчиков достичь этого.
Вывод
Обсудив 4 ценности и 12 принципов Agile Manifesto, становится очевидным, что акцент на удовлетворение потребностей клиентов принес успех гибким предприятиям по всему миру. Подход Agile практически доказал свою эффективность не только в индустрии программного обеспечения, но и в разных отраслях.
Таким образом, следуя ценностям и принципам Agile Manifesto, компании могут получить много преимуществ, не только путем повышения производительности и удовлетворенности клиентов.
Но, также, оставаясь прибыльным в долгосрочной перспективе, независимо от внешних факторов.
Итак, пришло время изменить систему ценностей вашего бизнеса и привить принципы манифеста, чтобы привить гибкую культуру. Сделайте свой бизнес Agile-публичным!
Рекомендуемые статьи
Это руководство по гибким ценностям и принципам. Здесь мы обсудили обзор, различные значения и принцип в Agile. Вы также можете просмотреть наши другие предлагаемые статьи, чтобы узнать больше —
- Принципы Лин Шесть Сигм
- Гибкое программирование
- Общие концепции управления качеством
- Роли и обязанности руководителя проекта
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
| LiveJournal.com | |||||||||||||||||||||||||||||||||||||||||||||||||||||
0 — 10 лет спустя
Мои убеждения и ценности. Затем это потихой начинает проявляться и влиять на набор моих навыков и поведенческих реакций. Это мой внутренний мир. И этот внутренний мир начинает проявляться во внешнем мире — мои конкретные действия. Моё поведение. А это создаёт мир вокруг меня. Это сложно принять, но мы авторы того, что вокруг нас. Но вопрос «авторства» не тема этого поста 🙂
0 (link)
xebia.com/2010/12/23/moreagile-manifesto/
Agile-подходы в разработке программного обеспечения
Гибкая методология разработки или Agile (аджайл) – современный термин, который используют для обозначения нескольких подходов к разработке ПО. Эти подходы называют итеративными от слова “итерация”. Термин используется для обозначения этапов работы над реализацией проекта. Каждый цикл, который также называют спринтом, фиксирован и продолжается 2-3 недели.
Название Agile произошло от одноименного англоязычного слова.
Оно имеет два определения:
- способный двигаться быстро и легко;
- способный быстро думать и понимать.
Эти качества, вне всякого сомнения, важны и необходимы любому бизнесу, который работает в условиях высокой конкуренции. Фактически, быть agile означает быть гибким, уметь подстраиваться под постоянно меняющуюся ситуацию, чтобы удержаться на плаву и преуспеть. В контексте IT-бизнеса аджайл-методология позволяет сократить время вывода продукта на рынок и ускорить процесс работы за счет упрощения организационной структуры, отказа от жесткой иерархии.
В основе новой философии лежит Agile Manifesto. Этот документ создан коллективом преуспевающих веб-разработчиков в 2001 и включает основные принципы Agile разработки. В подготовке манифеста приняли участие 17 человек. Они обобщили существующие методологии разработки и сформулировали ценности, которые призваны повысить скорость разработки и эффективность готового продукта. Стоит отметить, что аджайл – это не методология в буквальном смысле этого слова, а особая система ценностей, образ мышления и философия, которую можно принять за основу.
Принципы методологии основаны на ценностях данного подхода, который подразумевает изменение традиционного образа мышления на более гибкий. Создатели манифеста отмечают четыре основных ценности, которые лежат в основе философии:
- на первом месте – люди и их взаимодействие;
- на втором – качественный и эффективно работающий продукт;
- на третьем – грамотно построенное сотрудничество с заказчиком;
- на четвертом – готовность к изменениям.
Предлагаем подробнее рассмотреть каждый из принципов.
- Взаимодействие.
Сторонники аджайл подчеркивают, что люди и их взаимодействие важнее любых процессов и программных инструментов. Члены команды сами должны решать, какие инструменты использовать и как организовать рабочие процессы для повышения эффективности своей деятельности. Расширение полномочий исполнителей и демократичный формат работы позволяют всей команде сфокусироваться на нуждах и целях клиента, повышает мотивацию сотрудников, делает их более зрелыми в психологическом отношении.
Они превращаются в самоорганизованную команду, члены которой умеют принимать решение и нести за него ответственность.
Конечно, многим компаниям непросто отказаться от классического метода кнута и пряника в пользу принципов Agile, но результат действительно стоит того! Если команда столкнется с неизвестной ранее проблемой или ситуацией, работа не остановится. Для людей, которые занимаются умственным трудом, крайне важна самореализация. Если отказаться от жесткой иерархии в пользу более демократичной обстановки, сотрудники чувствуют себя более счастливыми, а значит, работают лучше. Аджайл-технологии – это, в первую очередь, гуманистический подход со стороны руководства к работникам компании и со стороны компании к своим клиентам.
Еще один важный принцип Agile – взаимодействие клиентов и разработчиков напрямую, активное использование обратной связи. Это подразумевает личное общение вместо многочисленных электронных документов и онлайн-переписки. Участники проекта встречаются вживую, чтобы обсудить идеи и протестировать их.
Такой подход дает каждому члену команды четкое понимание того, каким является клиент и что он хочет получить. Конечно, многие вопросы сейчас решаются в мессенджерах и с помощью других программ для дистанционного общения. В этом случае сторонники Agile разработки предлагают использовать видеосвязь с интерактивными онлайн-досками. Это поможет собеседникам установить контакт и избежать расхождения в восприятии одних и тех же явлений.
- Все внимание – на продукт.
Модель Agile подразумевает концентрацию внимания на создании работающего продукта, а не на соблюдении регламентов, подготовке различных отчетов и других документов. Сложная организационная структура, необходимость составления большого объема документации замедляет сам процесс разработки, а это совершенно не то, что нужно клиентам. Они хотят как можно скорее получить готовое к работе ПО, а не всевозможные диаграммы и отчеты, которые иллюстрируют рабочий процесс.
Самым популярным способом организации рабочего процесса в рамках модели Agile является фреймворк Scrum.
Он стал популярен благодаря своей предельной простоте. “Скрам” подразумевает составление графика встреч, так называемых групповых сессий, на которых команда планирует ближайшую итерацию. После этого сотрудники возвращаются к своей работе и могут сконцентрироваться на поставленных задачах вместо многочисленных планерок и соблюдения инструкций.
Во время встреч каждый участник команды может высказать свои идеи, как сделать продукт лучше. Это коренным образом отличается от традиционной модели, где каждый сотрудник отвечает за свой отрезок работы. Больше мнений – больше вариантов, а значит, больше возможностей найти действительно хорошую идею и сделать замечательный продукт.
Результатом каждой итерации является не просто промежуточный результат, а работоспособный вариант продукта. Это еще одна особенность модели Agile. В промежуточном варианте уже заложен функционал, которым можно пользоваться.
- Тесное сотрудничество с заказчиком и отказ от жестких условий контракта.
Гибкая методология разработки подразумевает подвижность в условиях сотрудничества с клиентом. Традиционный подход к работе подразумевает контракт с жесткими условиями. Это может негативно отражаться на результатах, так как детали контракта мешают учитывать новые данные. Во время разработки могут поменяться приоритеты и требования, поэтому разработчику важно поддерживать контакт с клиентом и обсуждать возникающие изменения. Такой подход помогает сторонам наладить доверительные отношения, а клиент в свою очередь получает продукт, который действительно ценен и важен.
- Готовность к изменениям на любой стадии проекта.
В рамках эджайл-модели процесс работы над ПО делится на итерации – короткие циклы. Это упрощает планирование и помогает при необходимости внести изменения в первоначальные планы. Подобный подход помогает избежать ситуации, при которой все риски откладывают на последние стадии разработки. Когда проект подходит к концу, а результаты не радуют, слишком поздно что-то менять.
При использовании итеративного метода можно вносить изменения на любой стадии проекта, усиливать команду разработчиков или сдвигать первоначальные сроки.
Готовность вносить существенные изменения в первоначальные планы позволяет добавить в продукт новые возможности, которые важны для результата и делают ПО более ценным для бизнеса. Как показывает практика, заказчики готовы пожертвовать чем-то запланированным, чтобы в итоге получить более качественный результат.
Метод Agile подразумевает то, что называют работой через эксперимент. Этот подход далеко не новый. Его использовали в медицине, ракетостроении, экономике и многих других отраслях до того, как внедрить в IT-индустрию. Суть подхода заключается в активном использовании обратной связи. В процессе разработки продукта его тестируют или выпускают на рынок, а затем анализируют обратную связь и устраняют недочеты.
Плюсы и минусы AgileГибкий подход к web-разработке имеет неоспоримые плюсы и некоторые минусы.
Для начала отметим преимущества модели:
- ускоренный вывод продукта на рынок;
- увеличение прибыли и быстрая отдача от инвестиций;
- регулярное тестирование повышает качество продукта;
- в реализацию проекта в максимальной степени вовлечены все участники;
- условия сделки понятны и приемлемы для обеих сторон;
- поддерживается постоянная обратная связь;
- снижаются риски ошибок, так изменения вносятся на любой стадии проекта.
При многочисленных плюсах гибкая методология разработки не всегда применима на практике. В ряде случаев новая философия воспринимается как абстрактное понятие, так как руководство компании и исполнители мыслят слишком традиционно и не могут принять новые принципы.
Модель Agile дает меньше предсказуемости. Если речь идет о реализации крупного проекта, это может создавать определенное напряжение у менеджмента и исполнителей.
Они, скорее, предпочтут традиционный формат, где все строго регламентировано, чтобы избежать негативного опыта.
Необходимость постоянного взаимодействия между клиентом и сотрудниками компании – еще один спорный фактор. Такой формат работы подходит не всем заказчикам, так как они должны найти время и возможности для активных коммуникаций. На практике такое случается не всегда. Более того, для вовлеченности в проект по веб-разработке клиент должен обладать соответствующими знаниями. При их отсутствии придется проходить обучение, на которое опять же нужны время и энергия.
Многие специалисты называют минимальное количество документов не плюсом, а минусом гибкого подхода. Если документация недостаточно подробная, новым членам команды будет непросто во всем разобраться, так как они не участвовали в ранних этапах разработки.
Модель Agile обходится без подробного планирования. Это может приводить к ошибочным решениям из-за нехватки информации. Например, заказчик недостаточно четко озвучил свои потребности или не вовремя предоставил данные, поэтому исполнители сосредоточились на разработке в неправильном направлении и получили совсем не такой результат, который хочет видеть заказчик.
Эксперты подчеркивают, что аджайл – это лишь один из способов управления проектами, но его нельзя считать единственно возможным и применимым.
Чтобы избежать ошибок, специалисты рекомендуют анализировать каждый проект с точки зрения масштабируемости. В ряде случаев традиционный подход с жестким регламентом дает более качественный и предсказуемый результат по сравнению с гибким подходом. Это касается проектов, где заказчики работают по четкому бюджету или графику, а объем и содержание проекта известны заранее и не нуждаются в изменениях.
Мы используем AgileКоманда Dynamic Sun принимает ценности данной философии и использует ее принципы на практике, чтобы предложить заказчикам лучших из возможных продуктов.
Наши сотрудники – команда людей, которые действительно любят свою работу и получают от нее удовольствие, а самое главное – имеют соответствующий образ мышления. Доверяя нам реализацию своего проекта, клиент убеждается в своем правильном решении.
Ценности Agile помогут девелоперам повысить эффективность
Например, при реконцепции торгово-развлекательного комплекса пройти все этапы без доработок практически невозможно. Уже после создания концепции, проектирования – в ходе подготовки рабочей документации – может появиться необходимость оптимизировать решения по оборудованию или материалам. Это повлечет возвращение процесса на начальные этапы. Еще сложнее, когда необходимость корректировки появляется на этапе взаимодействия с подрядчиком.
Agile помогает выявить все возможные нестыковки на максимально ранних этапах. Этого удается добиться за счет формирования саморегулируемой проектной команды профессионалов, в состав которой входят представители всех заинтересованных направлений бизнеса. Agile-команда в сфере девелопмента коммерческой недвижимости будет включать строителей, архитекторов, специалистов по инженерным системам, проектировщиков, маркетологов, менеджеров, занимающихся подбором арендаторов.
Взаимодействие внутри команды строится по горизонтальному принципу, а постоянная общая вовлеченность в процесс достигается благодаря универсальной ИТ-платформе.
Жизненный цикл проекта разбивается на итерации, по окончании каждой из которых проводится анализ результатов и корректировка действий. К каждой итерации в режиме реального времени подключены все члены команды, они самостоятельно определяют цели следующего этапа, оценивают текущее движение проекта в том числе на предмет выявления рисков по своим профессиональным направлениям.
Все только начинается
В рейтинге отраслей российской экономики по степени проникновения Agile, приведенном в исследовании консалтинговой компании ScrumTrek от октября прошлого года, сфера проектирования, строительства и промышленного дизайна лишь на 12-м месте с уровнем вовлеченности около 2%.
Лидируют в рейтинге компании, специализирующиеся на разработке программного обеспечения.
Они, по данным исследования, составляют 36% от общего числа организаций, следующих ценностям Agile. Такое безоговорочное лидерство не удивительно, ведь именно в ИТ-отрасли эти ценности и были сформулированы. Они отражены в манифесте, подписанном в 2001 году на международной встрече разработчиков ПО, объединившихся в Agile Alliance. Ценностей четыре: взаимодействие между людьми важнее процессов и инструментов; работающий продукт важнее документации; сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее соблюдения первоначального плана.
Возникнув в ИТ-сфере, Agile довольно быстро распространился в банках и страховом бизнесе (22% от общего числа российских компаний, практикующих Agile, на конец 2017 года). Этому немало способствовали усилия президента Сбербанка Германа Грефа, активно проводящего политику Agile-трансформации банка.
Довольно широко Agile распространился и в сфере телекоммуникаций — 11% российских компаний, работающих по его принципам, относятся к этому бизнесу.
За отраслями-лидерами следуют консалтинг, розничная торговля и общепит, тяжелая промышленность, маркетинговые исследования, СМИ, образование, энергетика, легкая промышленность, и лишь затем компании, связанные с девелопментом, строительством и проектированием.
Не буквой, а духом
В последнее время участники рынка все чаще упоминают Agile в числе инструментов повышения эффективности работы девелоперов. Выступая в конце прошлого года в рамках круглого стола «Кадровая перезагрузка строительной компании как стратегическая программа на стыке GM, PM, HR», организованного Российской гильдией управляющих и девелоперов, вице-президент Санкт-Петербургского отделения международного института проектного менеджмента, доктор экономических наук Валерий Фунтов назвал девелопмент исключительно проектным бизнесом, где важны три составляющие: техническое управление, вхождение в стратегию компании и эджайл-компетенции.
Правда, среди экспертов существует мнение, что в такой зарегулированной сфере как девелопмент недвижимости использование принципов Agile затруднено.
Если подойти к проблеме как к возможности, то решения находятся – эксперты предлагают, например, организовать в компании проектный офис как своего рода буфер между независимой саморегулируемой Agile-командой и основной корпоративной структурой, управляемой по традиционным принципам. Такой проектный офис может взять на себя ведение документации, подготовку отчетности, оценку соответствия создаваемого продукта нормативным требованиям.
Дмитрий Манылов
Почему стоит меньше рассуждать об Agile и больше о потоке – Digital Enterprise
Традиционные компании подвергаются высокому риску подрывных инноваций, и многие стремятся к гибкой трансформации в масштабах всей организации в попытке сохранить конкурентоспособность на современном цифровом рынке.
Однако эти преобразования дороги и, зачастую, терпят неудачу с угрожающей скоростью. В вашей компании, как и во множестве других, могут возникнуть дополнительные трудности из-за сложности наблюдения потока работ «от бизнеса до бизнеса», диагностики узких мест и измерения действительной ценности работы.
В погоне за мифической «серебряной пулей» очень скоро становится очевидным, что само по себе использование гибких фреймворков и методологий не обеспечивает прочной основы для успешного развития.
Поток, определяемый как движение бизнес-ценности от понимания ожиданий заказчика до поставки продукта, представляет собой альтернативный подход, проявляющий с какими проблемами приходится сталкиваться компаниям. Разработка и визуализация рабочего процесса «от бизнеса до бизнеса» является фундаментальным требованием, позволяющим компаниям масштабировать основные программные решения.
Традиционно понятие «от бизнеса до бизнеса» трактуется как процесс от спецификации требований к поставке программного обеспечения.
Но в потоке мы определяем, что деятельность начинается намного раньше вверх по течению. То, как мы понимаем и интерпретируем изменения в рыночных условиях и как именно продукты находят своё место в потоке создания ценности, имеет решающее значение для удовлетворения потребителей. Без этих шагов компании всего лишь будут успешно реализовывать плохие проекты.
Чтобы двигаться вперёд, вам прежде всего необходимо проявить в потоке:
- метрики, позволяющие оптимизировать решения на основе данных
- фокус на ценностно-ориентированной гибкости через восходящую аналитику
Проблема производительности
Многие компании добились больших успехов в обеспечении полного жизненного цикла программного обеспечения. DevOps и непрерывная интеграция привели к тому, что компании быстро и часто доносят ценность до заказчиков.
Однако, эти компании в ходе цифровой трансформации вкладывают значительные средства в оптимизацию небольшой части жизненного цикла, отвечающего за доставку (delivery), и пренебрегают оптимизацией всего потока «от бизнеса до бизнеса», не снижая общее время задержки между идеей и реализацией.
Гибкость как понятие относится к способности сокращать и концентрировать работу и процессы. Но зачастую компании фокусируются только на скорости. Эта потеря акцента на адаптивности является печальной реальностью, которая может привести к провалу в цифровую эпоху.
Проблема ценности
Чтобы сохранить конкурентное преимущество в среде подрывных инноваций и всё более неопределённого цифрового рынка, успешные компании постоянно совершенствуют свою стратегию и ищут новые возможности. Компании, не умеющие оценить свою цепочку создания ценности, увеличивают риск неудачи в цифровой трансформации, поскольку они не могут выработать необходимую стратегию.
Без стратегической основы для оценки бизнес-ценности, менеджеры продукта не могут понять, когда отказаться от ненужной работы. В результате забитые воронки потребностей и бэклоги продукта делают неясной полезную работу по созданию ценности и превращают весь поток в болото.
Поток как инструмент раскрытия ценности
Технологии выявления ценностей во многих случаях недостаточно развиты и не ориентированы на ожидания заказчиков.
Клиентоориентированность является отправной точкой для нового подхода к выявлению ценности.
Выявление ценности (discovery) в бережливых гибких методологиях – это по большей части способ поиска баланса. То понимание, которое даёт нам минимально жизнеспособный продукт (MVP) и итерационный подход к разработке, по сути является оценкой ценности, но это не процесс её выявления. Фактически, это приводит к очень «небережливой» беспорядочной форме использования новых решений. Компаниям предлагается попробовать и выяснить, имеет ли идея ценность в поставке (вниз по течению), а не исследовать ценность на ранних этапах (вверх по течению).
Важной частью процесса выявления ценности является способность определять возникающие потребности. Многие стартапы перехватывают пальму первенства в этом процессе по нескольким потенциальным причинам:
- Часто предприниматель приходит из крупной компании, в которой он и его коллеги агрегировали потребность в новых продуктах для непокрытых сегментов рынка в течение длительного времени.
- Исходя из личного опыта, предприниматель просто знает, что перед ним есть востребованный потенциал
- Предприниматели знают, как использовать известную технологию для адаптации к новым потребностям рынка
Так возникают подрывные инновации, как описывал Клейтон Кристенсен. Проработанный механизм выявления ценности (discovery) помогает компаниям обнаружить потенциальные стрессоры рынка на раннем этапе, прежде чем они попадут в руки стартапа, который сможет ответить новыми ценностными предложениями.
Поток создания ценности использует глубокую сегментацию рынка, чтобы удовлетворить растущие потребности клиентов. Он позволяет акцентировать интерпретацию факторов на успех у клиентов в этих сегментах — идея, заимствованная у SaaS.
Поток помогает оценить существующее программное обеспечение, уникальные преимущества и базу активов ИС, чтобы узнать, нужно ли вам создавать, обновлять или адаптировать существующие активы. Существуют серьёзные последствия для ресурсов, когда вы выбираете стратегию построения или выбора новшеств, а не адаптации имеющихся резервов.
В итоге, мы имеем доверительную выборку целенаправленных инноваций, которые используют эти активы для точечных потребностей, с учётом ясных факторов успеха для клиентов. Таким образом мы удерживаем актуальность нашего запаса идей.
Выявление ценности (discovery) должно способствовать достижению ряда целей:
- Является источником идей, которые действительно актуальны для существующих клиентов или способствуют привлечению новых клиентов
- Позволяет понять, что сделает клиентов более удовлетворёнными
- Уменьшает спекулятивные проекты и сокращает нагрузку на бэклог продукта
- Даёт пространство для маневра или отката командам разработки, в случае, если новая функциональность не оправдывает ожиданий и вряд ли доставит ценность
- Обеспечивает передовую линию защиты от конкурирующих компаний, получивших эту ценность раньше
Поток как инструмент может помочь переосмыслить управления полным спектром поставки программного обеспечения, чтобы измерить и оптимизировать бизнес-ценность, обеспечить фокусировку на производительности и результативности.
Прикладные практики могут выявить основные показатели потока (например, эффективность потока создания ценности) которые помогут определить вектор усилий по непрерывному улучшению на основе данных в организации. Такие данные могут дать командам и руководителям возможность принимать лучшие решения, поскольку они стремятся изменить свой способ организации работы и бороться с непродуктивностью. Но ключевым моментом является сопоставление этой информации с выявлением ценности как можно раньше вверх по течению.
Не скрывайте измерение ценности в потоке
Быть ориентированным на ценность и вытаскивать на поверхность потока бизнес-ценность являются жизненно важной предпосылкой для любой гибкой трансформации. Попытка трансформировать методологии и структуры, не зная, как ценность переходит от идеи к реализации, будет всего лишь игрой в догадки.
В мире, где большинство преобразований не дают ожидаемой выгоды, инструменты и метрики, правильно применяемые к потоку, могут помочь компаниям оперативно получить предсказуемые и значимые результаты.
Гайдн Шонесси , Фин Голдинг, Мик Керстен
Оригинал статьи: Why You Should Be Talking Less Agile and More Flow
Agile — это фанатичное стремление к качеству
— Антон, свой путь в Agile Райффайзенбанк начинал вместе с консультантами из Unusual Concept и AgiliX. Зачем понадобилась внешняя экспертиза?
— Когда нужен прорыв, быстрые качественные изменения, проще нанять консультанта, который обладает богатым опытом, поработал с разными компаниями на рынке, может предостеречь от типичных ошибок, направить в нужную сторону. Unusual Concept и AgiliX, на мой взгляд, — самые опытные тренеры на рынке, это хороший выбор.
— Было ли на начальном этапе движения понимание, что Agile — это скорее философия, культура? Как это тогда и сейчас сочетается с консервативным имиджем банкира?
— Я не знаю, как все происходило на начальном этапе, но мне кажется, что Райффайзенбанк инициировал эти изменения осознанно.
Имидж консервативного банкира устарел: банки точно так же, как другие компании, находятся в очень неопределенной среде с жесткой конкуренцией, в условиях падающего рынка, кризиса. Здесь выживает тот, кто хорошо приспособлен к изменениям, может быстрее реагировать, эффективнее и быстрее предоставляет лучший сервис за счет адаптивности и гибкости.
Agile давно проник в банковскую сферу. Огромный вклад в это внес Герман Оскарович. Кажется, он сделал для Agile-культуры в России больше, чем все бизнес-консультанты вместе взятые. Но «Райффайзен» — не тот банк, который посмотрел на Сбербанк и тоже захотел. Наш выбор был сделан осознанно, по нашим внутренним соображениям.
— В чем преимущество и отличие Scrum, LeSS и других фреймворков, которые банк использует в продуктовой разработке?
— Чем Scrum хорош? Тем, что он простой. В этом фреймворке мало лишних элементов. Чем хорош LeSS? Тем, что LeSS — это Scrum. Выбор в пользу LeSS был сделан неслучайно: люди, которые принимали решение, сравнивали разные фреймворки между собой, смотрели на Nexus, на SAFe, на LeSS и выбрали LeSS по причине логичности, простоты и элегантности.
LeSS прост, логичен и понятен. По сравнению со Scrum в него добавлен всего лишь один элемент, и это позволяет организовывать работу до восьми команд над одним продуктом. В этом его главное преимущество и отличие от других фреймворков. В нем нет ничего лишнего.
Но это не значит, что в LeSS совсем все просто. В этих фреймворках есть глубина и определенные вещи, без которых они не работают: ценности, принципы, инженерные практики и так далее. Еще одно неочевидное свойство LeSS — он не просто выстраивает процессы, а изменяет структуру организации. Без этого никакие процессы не заработают. Если вы их будете «натягивать» на старую структуру, которая под них не приспособлена, ничего не изменится. Внедрение LeSS начинается с того, что мы изменяем структуру и потом уже в ней запускаем новый процесс. К сожалению, к таким масштабным изменениям не все готовы.
— Использование фреймворков предполагает изменение ролей. Появляются product owner или скрам-мастера, исчезают проектные менеджеры.
Как воспринимает изменения существующий штат и готовят ли вузы кадры со соответствующим менталитетом?
— Роли меняются, и тут важно сделать плавный переход — люди, которые ранее работали, не должны чувствовать обреченность, ненужность и невостребованность. Они являются ценными носителями знаний, источниками экспертизы, у них есть опыт, отстроенные связи внутри организации. Если эти люди готовы к изменениям, готовы принимать ценности Agile, работать в другой роли и помогать организации двигаться вперед, то, скажем, из проектного менеджера может получиться прекрасный product owner или scrum master. Почему бы и нет? Ведь scrum master — это лидерская роль, и в ней важен управленческий опыт.
Те, кто не готов к изменениям, уходят. Это нормально. При изменениях всегда происходит отток. Те, кто готовы меняться, остаются и реализуют себя в новых ролях. Они воспринимают это как вызов, интересный опыт, новый эксперимент. Новые роли, такие как скрам-мастер, востребованы на рынке.
Люди повышают свою ценность — это тоже хорошо.
Готовят ли вузы кадры с соответствующим менталитетом? Насколько я знаю — нет, и это большая проблема. У нас вузы до сих пор готовят даже разработчиков по моделям прошлого века, то есть их учат программировать, но не учат практикам совместной, командной работы. В некоторых вузах начинают появляться такие программы, но нельзя сказать, что они стали мейнстримом. У нас пока еще довольно консервативное образование. Я не видел институтов продакт-оунеров или скрам-мастеров. К счастью, выпускники — довольно открытые, подвижные люди, они готовы учиться.
— Культура Agile. Есть ли «религиозные» течения внутри, кого легко принимает коллектив, от кого старается избавиться?
— Из чего состоит культура, на самом деле, исчерпывающе описывает манифест. Во-первых, это опора на командные решения. Мы доверяем команде в том, что она готова на самоорганизацию и принятие лучших решений, чем каждый отдельный участник команды или менеджер.
Мы думаем о том, какую пользу приносит в целом команда, а не каждый отдельный человек. Команда работает для того, чтобы приносить максимальную пользу клиентам и бизнесу. Это значит, что она не идет на поводу у каких-то формальных договоренностей, а воспринимает клиента как своего партнера и старается действовать в его интересах. Ну и конечно, это постоянная готовность к изменениям, потому что ради этого Agile и был придуман — выживать в неопределенной среде, когда ситуация все время меняется и нужно на нее реагировать. Это не исключение, а правило. Ты должен строить свой процесс из предпосылки, что в окружающем мире нет ничего постоянного. Именно поэтому культура Agile стоит на двенадцати принципах, среди которых доверие и качество. Мы доверяем команде, мы доверяем нашим продакт-оунерам, клиентам. Про качество, кстати, часто забывают. Очень часто Agile почему-то воспринимают как хаос и безответственность. На самом деле Agile базируется на фанатичном стремлении к качеству и на очень высокой требовательности друг к другу.
При этом мы делаем ставку не на то, что кто-то придет и проверит, а на то, что команда сама будет отвечать за результат, постоянно меняться и постоянно учиться. Качество и доверие — это неотъемлемая часть Agile-культуры.
Есть ли «религиозные» течения? Провокационный вопрос. Наверное, есть. На этой культуре пытаются заработать все, кому не лень, возникают разные течения, школы, каждая из которых пытается создавать какой-то свой бренд и его монетизировать. Но тут важно не увлекаться каким-то конкретным течением, а помнить о ценностях и жить в соответствии с ними. В Agile-методах работы команда — это важнейшая сущность, на которую опирается весь процесс, поэтому важно не только то, насколько человек профессионален, но и то, насколько он способен работать в команде. Выполнять договоренности, адаптироваться, приспосабливаться к мнению других, объяснять спокойно свою позицию, выслушивать другую позицию, принимать совместные решения, соблюдать договоренности, которые приняла команда, постоянно обучаться.
Обучение — это еще одна важнейшая вещь в Agile. Люди, готовые учиться, нормально вписываются. Людей, которые паразитируют на других, команда сразу видит и быстро от них избавляется. Как и от людей, которые ценят себя выше команды, от токсичных персон, от тех, у кого «звезда во лбу», таких, знаете, ковбоев: «Вот я приду, сам все сделаю, всех спасу, ночь не посплю…». Командная работа — другая, она не полагается на ярких одиночек. Это не значит, что в команде все равны . Это значит, что команда антихрупкая. Если любой человек однажды не сможет выйти на работу, то команда все равно выживет, сделает работу с тем же качеством и в тот же срок. Это ее не убьет. А если не выйдет ковбой «со звездой во лбу», то все обречены.
— Как с такими особенностями Райффайзенбанк сосуществует с коллегами по группе RBI? Нет ли трений между географически распределенными командами из России?
— Agile-сообщество существует не только в России, мы с нашими венскими коллегами общаемся, делимся опытом и помогаем друг другу.
Я бы даже сказал без ложной скромности, что российское отделение Райффайзенбанка по развитию Agile-культуры намного сильнее европейских коллег, и это скорее мы им помогаем и делимся нашим опытом. Мы уже выстроили роли, прошли определенные этапы трансформации, описали, чем занимается scrum master и другие роли в ADORE, описали грейды, и у нас есть понятная линейка развития. Мы создали программу подготовки ключевых ролей. Мы прошли долгий путь признания скрам-мастера — от полного непонимания, что это за роль, до текущей ситуации, когда команда скрам-мастеров подчиняется напрямую Сергею Монину. Такого нет нигде, не только в RBI, но и на российском рынке.
Нет ли трений между географически распределенными командами из России? В этом смысле удаленная работа сыграла нам на руку. Если раньше коллеги из Омска могли находиться в каком-то неравноправном положении (например, мы здесь собираемся в «переговорке», а они подключаются удаленно), то сейчас, когда все в равных условиях, это как раз помогло распределенным командам работать более эффективно.
— До какой степени зрелости Agile банк дошел сегодня? Нет ли на горизонте новых целей? Вообще, где предел совершенства в рамках этой философии?
— Зрелость в Agile неравномерная. Есть команды, которые приобрели очень большой опыт — они работают по Agile, Scrum и LeSS уже два-три года и прошли большой путь. Если хотите посмотреть, как работает настоящий Scrum (многие не верят, что он есть вообще), приходите к нам. Покажем, расскажем. Но такие команды, естественно, не все в банке. Есть другие, менее опытные команды, которые находятся только в начале этого пути. Те, кто только стартовали, сталкиваются со сложностями и проходят естественные этапы взросления, с которыми сталкивается любая Agile-команда.
Agile — это бесконечное развитие. Нельзя сказать в один прекрасный день: «Всё! Мы Agile-трансформацию закончили». Она не заканчивается никогда. В Agile заложен механизм постоянных изменений процессов, это никогда не прекращается.
Кроме этого, в зрелой Agile-организации люди понимают, где им нужен Scrum а где не нужен, и делают этот выбор осознанно.
Scrum — очень дорогой фреймворк, который оправдан только в условиях высокой неопределенности. Его тоже нужно применять к месту. Компания, которая умеет это делать — собирать подходящие инструменты под подходящий контекст и отказываться от них вовремя, когда ситуация изменилась, — вот это и есть Agile-организация. В этом смысле многим организациям есть чему учиться, и нам в том числе.
Недавно мы провели опрос внутри банка, знакомились с командами, узнавали, в каком фреймворке они работают, куда хотят двигаться. Этот опрос дал нам очень много информации и почвы для размышлений о том, что будет дальше. Оказалось, например, что у нас 72 команды — больше половины — выбирают Scrum или LeSS. Это не только продуктовые команды, есть и сервисные команды, каналы, стримы и платформы. Эти команды находятся в разной степени зрелости, но у нас наработана очень сильная экспертиза, и мы готовы ее расширять. У нас есть опыт, сильное сообщество профессиональных скрам-мастеров, к нам приходят с рынка профессионалы, которые тянутся к этому сильному сообществу, хотят в нем жить и развиваться.
То есть мы создали критическую массу, которая притягивает профессионалов. Это наша сильная сторона, и мы будем и дальше ее развивать.
У значительной части из этих 72 команд, которые хотят работать в Scrumе, нет скрам-мастера. Это значит, что мы им должны помочь. Возможно, некоторые из них не видят ценности в этой роли, не понимают ее до конца. И мы готовы предоставить сервис, то есть помочь запустить команду, обучить, рассказать про эту роль, продемонстрировать в деле, как она работает, помочь обучить участников команды, которые готовы взять эту роль на себя.
Оказывается, у нас есть довольно большое количество команд — целых 25, которые выбирают для себя Kanban, и этой экспертизы у нас в банке пока нет. Мы ее развиваем. Прямо сейчас мы создаем роль канбан-коуча, и человек в этой роли будет помогать становлению процесса Kanban.
Кроме того, в самой идее LeSS заложено развитие организационной структуры команды, которая работает над продуктом. Где-то границы продукта проведены неправильно, и их нужно пересмотреть, где-то они слишком узкие — команда выросла и нужно их раздвигать, где-то нужно их менять — эти вещи нужно делать постоянно.
Равно как и усиливать автономность команд за счет более тесной работы между собой, обучения, упрощения технических и инженерных решений, автоматизации.
Agile опирается на техническое совершенство, это один из принципов. У нас много успехов — мы используем современные технологии, переходим на Kubernetes, наши команды IT-платформы ставят себе цель обеспечить такой же сервис для команд, как в «Амазоне», чтобы команды могли легко поднимать микросервисы за минимальное время, а затем самостоятельно их развертывать и обслуживать. Нам еще многое предстоит сделать вместе.
Agile-манифест и гибкие принципы — ИТ-стратегия
Agile Manifesto был написан в феврале 2001 года семнадцатью независимыми специалистами по программному обеспечению. Несмотря на несогласие участников, документ все же был подготовлен.
Документ, официально названный «Манифест гибкой разработки программного обеспечения», был подготовлен 17 разработчиками во время прогулки 11, 12 и 13 февраля 2001 года на горнолыжном курорте The Lodge в Сноуберд, штат Юта.
Разработчики, называющие себя Agile Alliance, стремились пересмотреть процессы разработки программного обеспечения, которые они считали громоздкими, не отвечающими на запросы и слишком сосредоточенными на документировании.
В Соответствии С agilemanisfesto.org, онлайн-дом провозглашения, цель разработчиков не была анти-методология. Они были больше озабочены «восстановлением достоверности слова методология».
В нем также говорится: «Мы хотим восстановить баланс. Мы приветствуем моделирование, но не для того, чтобы отправить диаграмму в пыльный корпоративный репозиторий. Мы принимаем документацию, но не сотни страниц никогда не обслуживаемых и редко используемых справочников. Планируйте, но осознавайте пределы планирование в неспокойной обстановке ».
Разработка Agile Манифеста
De Проворный Подход к разработке программного обеспечения характеризуется идеей создания инкрементального программного обеспечения. Такой подход предоставляет пользователям новые версии или выпуски программного обеспечения через короткий промежуток времени.
Мы часто ссылаемся на эти короткие периоды работы спринт.
Этот гибкий процесс резко контрастирует с традиционным подходом к разработке программного обеспечения. Это метод, при котором разработчики обычно фиксируют потребности и требования пользователей, а затем создают программное обеспечение за один раз. Эти традиционные методологии выпускают готовый проект в конце проектного цикла.
Agile Alliance искал альтернативу этому водопад приближается, которые были описаны как «основанные на документации тяжелые процессы разработки программного обеспечения».
Четыре ценности Agile
Манифест начинался так: «Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к пониманию четырех основных ценностей ».
Четыре основных ценности гибкой разработки программного обеспечения, заявленные в Agile Manifesto:
- Люди и взаимодействия идут за процессами и инструментами.
- Рабочее программное обеспечение идет для обширной документации.
- Сотрудничество с заказчиком важнее переговоров по контракту.
- Реагировать на изменения важнее, чем следовать плану.
То есть, хотя предметы справа имеют ценность, мы ценим предметы слева больше.
(© 2001, авторы Agile Manifesto.
Это утверждение не может быть скопировано в какой-либо форме, но только во всей его полноте посредством данного сообщения. )
Ниже приведены рекомендации, которые помогают командам внедрять и внедрять Agile.
Принципы 12, которые следуют из Agile Manifesto
Эти основные ценности получили дальнейшее развитие в 12 принципах, которые восходят к разработке программного обеспечения. Следующие принципы основаны на Agile Manifesto:
- Удовлетворение клиентов за счет ранней и постоянной доставки ценной работы.
- Разделите большие работы на меньшие задачи, которые могут быть выполнены быстро.
- Признайте, что лучшая работа приходит от самоорганизованных команд.
- Обеспечьте мотивированных людей окружающей средой и поддержкой, в которой они нуждаются. И верь, что они выполнят свою работу.
- Создание процессов, способствующих устойчивым усилиям.
- Поддерживайте постоянный темп выполнения работ.
- Приветствуя меняющиеся требования, даже поздно в проекте.
- Команда проекта и владельцы бизнеса встречаться ежедневно во время проекта.
- Попросите команду регулярно думать о том, как сделать это более эффективно, а затем координируйте и корректируйте поведение.
- Измерение прогресса на основе объема выполненных работ.
- Непрерывное стремление к совершенству.
- Используйте изменения, чтобы получить конкурентное преимущество.
И верь, что они выполнят свою работу.Цель Agile Манифеста
Сторонники Agile-методологий говорят, что четыре значения, изложенные в Agile Manifesto, способствуют процессу разработки программного обеспечения, ориентированному на качество, путем создания продуктов, отвечающих потребностям и ожиданиям пользователя.
Принципы 12 предназначены для создания и поддержки рабочей среды, ориентированной на пользователя и соответствующей бизнес-целям.
Рабочая среда, которая может реагировать и реагировать быстро, когда потребности пользователей и рыночные силы меняются.
Это одна из основных причин, по которой люди в наше время также используют Agile вне разработки программного обеспечения. Например, в маркетинговых командах.
Agile против SCRUM и другие методологии
Agile, как изложено в Agile Manifesto, может рассматриваться как философия. Тем не менее, существуют конкретные методологии и структуры, которые формализуют многие или все идеи Agile Manifesto.
Agile в действии
Например, Scrum — это среда для управления итеративными проектами, в которой владелец продукта работает с кросс-функциональными командами. Все дело в списке задач разработки. Этот список известен как отставание продукта.
Другие основы и методологии Crystal, Kanban , Наклонитесь и экстремальное программирование (XP). Все они содержат элементы, вытекающие из философии Agile.
Критика и противоречие по поводу Agile Manifesto
Agile был широко принят командами разработчиков программного обеспечения в ИТ-индустрии, а также в ИТ-отделах крупных международных компаний.
Кроме того, Agile рассматривается как причина, по которой программные проекты более успешны в удовлетворении потребностей пользователей, клиентов и бизнеса, а также в создании программного обеспечения намного быстрее, чем традиционные методологии водопада.
Поддельный Agile
Тем не менее, Agile не обходится без критики, и некоторые считают, что она слишком раздута. Некоторые видят, что Agile работает не во всех ситуациях и что методы, терминология и культура Agile не вписываются в культуру некоторых организаций и проектов.
Другие отмечают, что некоторые команды разработчиков ложно заявляют, что работают по Agile. На самом деле они просто отказались от некоторых идей традиционного метода разработки. Однако при этом фактически не принимаются ценности и принципы Agile.
ITpedia Рекомендации по разработке инструментов
| Предложить программное обеспечение для разработки приложений | Ключевые особенности, которые следует искать в программном обеспечении для разработки приложений: при принятии решения о том, какое программное обеспечение для создания приложений лучше всего поможет вам создавать индивидуальные приложения, уделите много внимания четырем критическим областям: функции создания контента, распространение, взаимодействие с клиентами и помощь и вспомогательные средства. Распространение создания контента и совместимость с ОС Функции справки и поддержки службы поддержки клиентов |
| отставание | Программное обеспечение для управления проектами онлайн для разработчиков | Backlog Backlog — это универсальное программное обеспечение для управления проектами для всей команды. Отслеживание проблем, хостинг Git и контроль версий, а также Wiki. Нужные инструменты, которые помогут вашей команде разработчиков быстрее выполнять качественные проекты. Начните с бесплатного аккаунта! |
| Caylent | Решения DevOps для всех Caylent предлагает индивидуальные решения DevOps для компаний на всех этапах, предоставляя вашей команде свободу сосредоточиться на функциях, приносящих доход, а не на инфраструктуре. Позволить программным командам автоматизировать развертывание контейнеров без каких-либо хлопот, не управлять облачной инфраструктурой или поддерживать конвейеры CI и CD. Это приводит к легкому сотрудничеству между командами разработчиков и операторов, что позволяет им упростить самые сложные рабочие процессы. |
| Hive | Макеты проекта. Организуйте проекты в виде диаграммы Ганта, доски Канбан, таблицы или календаря и легко переключайтесь между каждым макетом. Обновления отражаются во всех представлениях проекта, поэтому вся команда получает информацию независимо от того, какой вариант они используют. Сводные просмотры. Объедините несколько проектов и просмотрите общую картину своей компании или отдела. Проекты можно сортировать по текущему статусу, члену команды или присвоенным ярлыкам. Шаблоны действий. С легкостью планируйте и повторяйте задачи, используя шаблоны действий. Изложите все необходимые шаги в повторно используемом шаблоне действий, чтобы назначать задачи нужным людям в нужное время. |
| ПО для управления ИТ-проектами | Лучшие программные решения для управления ИТ-проектами для ваших команд DevOps |
Monday. com DV | Гибкое управление — это набор принципов, которые используются для управления проектами и командами. Хотя это обычно неверно истолковывают как кучу волшебных уловок, которыми руководствуются руководители, не понимая их истинной ценности, Agile действительно предлагает список основных ценностей и рекомендаций, которые, как было доказано, повышают как производительность команды, так и ответственность. |
| Услуги по созданию сайтов | Лучшие веб-конструкторы, такие как: Wix, Bizness Apps, Weebly и Web Sitebuilder. |
резюме
статья
Agile Manifesto и Agile Принципы
Описание
Agile Manifesto был написан в феврале 2001 семнадцатью специалистами по программному обеспечению. Хотя участники не очень согласились, документ был подготовлен. Agile подход к разработке программного обеспечения характеризуется идеей создания дополнительного программного обеспечения.
Подход предлагает пользователям новые версии или выпуски программного обеспечения через короткий промежуток времени. Мы часто называем эти короткие периоды работы спринтами.
Автор
Wim Hoogenraad
Имя издателя
ITpedia
Издательство Логотип
гибких ценностей | Определение и обзор
Каковы 4 ценности Agile?
Ценности Agile относятся к набору из 4 ценностей, изложенных Agile Alliance в Манифесте Agile . Этот набор ценностей поощряет ставить людей выше процессов, быстро выпускать программное обеспечение, сотрудничать с клиентами и корректировать планы по мере необходимости.
- человек и взаимодействия над процессами и инструментами
- Рабочая программное обеспечение над всеобъемлющей документацией
- Сотрудничество на клиенте над согласованием контракта
- Отвечая на изменение в соответствии с планом
ниже мы сломаемся из 4 Agile-ценностей и объясните, как их можно интерпретировать с точки зрения менеджера по продукту или владельца продукта.
Люди и взаимодействие важнее процессов и инструментов
Независимо от того, насколько хорошо изучены ваши процессы и высокотехнологичны ваши инструменты, именно команда, с которой вы работаете, и то, как вы работаете вместе, определяют успех. Ваша команда и ее способность эффективно и продуктивно общаться более ценны, чем процессы, которым они следуют, или инструменты, которые вы используете.
Это не означает, что agile-философия не поощряет формализованные процессы или инструменты. И то, и другое может быть полезно для создания структуры вашей команды и облегчения взаимодействия.Но в итоге они идут вторыми.
В конце концов, процессы и инструменты ничего не стоят, если ваша команда не может общаться. Но поставьте перед задачей умную, мотивированную команду без каких-либо процессов или инструментов для управления проектом, и, скорее всего, они найдут способ ее выполнить.
Работающее программное обеспечение важнее исчерпывающей документации
Традиционные процессы разработки продукта часто требовали обширной документации, прежде чем была написана хотя бы одна строка кода.
В соответствии с agile-философией передача программного обеспечения в руки клиентов является наивысшим приоритетом.В конце концов, как вы собираетесь улучшать свой продукт, если не выпускаете его в свет и не собираете отзывы реальных пользователей?Хотя это значение подчеркивает важность поставки программного обеспечения, а не документации, которая может стать узким местом, важно отметить, что документация сама по себе не является чем-то плохим… до тех пор, пока вы не переусердствуете.
Сотрудничество с клиентами вместо переговоров по контракту
Философия Agile подчеркивает важность практики разработки продукта, ориентированной на клиента, а не подходов, ориентированных на продукт.Хотя контракты всегда будут иметь место в бизнесе, список вещей, которые вы предлагаете своим клиентам, не заменит фактического общения с ними о том, каковы их потребности и в чем их проблемы.
Традиционные процессы, ориентированные на продукт, позволяли контрактам диктовать, что будет поставлено в конечном итоге, что оставляло много места для несоответствия ожиданий.
Agile-философия (и многие формализованные процессы, вытекающие из нее) поощряют встраивание непрерывного цикла обратной связи с клиентами в циклы разработки.В соответствии с agile-философией сотрудничество с клиентами начинается на ранней стадии процесса разработки и часто происходит на протяжении всего процесса. Эта культура тесного сотрудничества с реальными клиентами помогает специалистам по продуктам обеспечивать эффективные и полезные решения для клиентов. Когда вы часто разговариваете с клиентами и встраиваете обратную связь в процесс разработки, вы снижаете риск и устраняете догадки.
Реагирование на изменения вместо следования плану
Важным преимуществом гибкой методологии является то, что она поощряет частый пересмотр и переоснащение текущих планов на основе новой информации, которую команда постоянно собирает и анализирует.Таким образом, дорожная карта продукта — это уже не статичный документ, а динамичная стратегия. Менеджеры по продуктам в agile-средах должны будут научиться представлять свои динамические дорожные карты заинтересованным сторонам в прозрачной форме, отражающей вероятность изменений на основе новых знаний.
Другими словами, гибкая методология позволяет команде разработчиков корректировать свои приоритеты и планы всякий раз, когда это имеет стратегический смысл. Эти команды не застревают в устаревшем плане просто потому, что они взяли на себя обязательство довести его до конца.
Помните: ценности Agile — это не правила
Наконец, не забывайте, что Agile — это образ мышления, а не набор строгих правил, которым нужно следовать. Эти значения подлежат интерпретации и не являются твердыми инструкциями, высеченными на камне.
Продолжайте узнавать о ценностях Agile на нашем вебинаре «Управление сложными требованиями в мире Agile» ниже.
Что такое Agile-манифест? 12 принципов и 4 ценности
Что такое Agile-манифест?
Agile-манифест для разработки программного обеспечения был декларацией объединяющей философии для фреймворков, таких как Scrum, экстремальное программирование и разработка, основанная на функциях (FDD).Манифест Agile сильно отличался от подходов к управлению проектами в стиле водопада, которые широко использовались до того времени.
Манифест гибкой разработки программного обеспечения гласит:
«Мы находим лучшие способы разработки программного обеспечения, занимаясь этим и помогая в этом другим.
Благодаря этой работе мы пришли к ценности:
Индивиды и взаимодействия над процессами и инструментами
Работающее программное обеспечение поверх исчерпывающей документации
Сотрудничество с клиентами по согласованию условий контракта
Реагирование на изменение в связи с выполнением плана
То есть, хотя элементы справа имеют ценность, мы больше ценим элементы слева.
Agile-решения появляются как самоорганизующиеся межфункциональные Agile-команды, использующие соответствующие практики для своего контекста. Но это не значит, что они обходятся без менеджеров.
Менеджеры еще нужны:Создайте среду, способствующую успеху команды
Убедитесь, что у членов команды есть соответствующие наборы навыков
Предоставлять рекомендации, когда команды не могут решить проблемы самостоятельно
Очистить блокпосты и защитить внешние ресурсы по мере необходимости
Кто создал Манифест Agile?
С возвышающимися над ними горами Уосатч в Сноуберде, штат Юта, в начале 2001 года 17 человек собрались, чтобы обсудить будущее разработки программного обеспечения.Среди них были сторонники экстремального программирования, Scrum, метода разработки динамических систем (DSDM), адаптивной разработки программного обеспечения, Crystal, FDD, прагматического программирования и другие, которые видели необходимость в альтернативе «управляемым документацией тяжеловесным процессам разработки программного обеспечения».
Из этой группы 14 человек подписали Agile Manifesto, в том числе:
Майк Бидл , основатель и генеральный директор e-Architects Inc., консалтинговой компании, специализирующейся на разработке приложений с использованием распределенных объектов и интернет-технологий.
Арье ван Беннекум , активно участвующий в DSDM и Консорциуме DSDM с 1997 года.
Алистер Кокберн , основатель Humans and Technology, известный своими обширными интервью с проектными группами.
Ward Cunningham , основатель Cunningham & Cunningham, Inc., который работал директором по исследованиям и разработкам в Wyatt Software и главным инженером лаборатории компьютерных исследований Tektronix.
Мартин Фаулер, главный научный сотрудник Thoughtworks, компании по разработке приложений и консалтингу.
Джим Хайсмит , главный разработчик гибкого метода адаптивной разработки программного обеспечения и автор одноименной книги.
Эндрю Хант , партнер The Pragmatic Programmers и соавтор книги The Pragmatic Programmer: From Journeyman to Master и Programming Ruby.
Рон Джеффрис , владелец XProgramming.com, консультант Object Mentor и соавтор книги Extreme Programming Installed.
Джон Керн , который увлечен тем, что помогает клиентам добиться успеха в повышении эффективности бизнеса за счет усилий по разработке программного обеспечения.
Брайан Марик , программист и консультант по тестированию программного обеспечения.
Роберт С.Мартин , президент и основатель компании Object Mentor Inc.
, которая предлагает консультации по процессам XP и Agile, консультации по разработке программного обеспечения, обучение и услуги по разработке для крупных корпораций по всему миру.Кен Швабер , президент Advanced Development Methods (ADM), занимающийся улучшением практики разработки программного обеспечения.
Джефф Сазерленд , технический директор PatientKeeper, стартапа из Массачусетского технологического института, предоставляющего клиницистам мобильные/беспроводные приложения.
Дэйв Томас , соавтор The Pragmatic Programmer.
История Agile Manifesto.
В 1990-х годах, до встречи Agile Manifesto, разработчики программного обеспечения начали искать лучшие, более гибкие способы работы, смешивая старые и новые идеи Agile-разработки и пытаясь найти наилучшее сочетание для своих целей.
Их различные методологии были сосредоточены на:
Тесное сотрудничество между командой разработчиков и заинтересованными сторонами бизнеса
Частая доставка ценности для бизнеса
Сплоченные, самоорганизующиеся команды
Более разумные способы создания, подтверждения и доставки кода
Они начали разрабатывать фреймворки, которые могли бы использовать другие команды, включая Scrum, Extreme Programming, FDD и DSDM.
Во время встречи Agile Manifesto 2001 года участники искали общие черты в этих разных подходах. Отбросив то, с чем они не могли согласиться, участники кодифицировали оставшиеся пункты соглашения в Agile-манифесте, предоставив набор утверждений о ценности и придумав термин «гибкая разработка программного обеспечения».
Agile Alliance был создан в конце 2001 года, чтобы разработчики программного обеспечения могли исследовать и делиться своими идеями и опытом.Команды разработчиков были первыми, кто использовал методологию Agile, но с тех пор она была принята другими командами, особенно теми, которые работают над проектами, у которых нет четкого объема и требований с самого начала.
По мере того, как Agile стал более широко применяться, сформировалась экосистема, в которую вошли люди, занимающиеся Agile-разработкой программного обеспечения, и другие люди, которые помогали им посредством консультаций, обучения, фреймворков и инструментов.
Ценности Agile Manifesto.
Четыре значения Agile Manifesto:
1.Люди и взаимодействия важнее процессов и инструментов.
Именно люди управляют процессом разработки и мгновенно реагируют на потребности бизнеса, поэтому они имеют приоритет над процессами и инструментами. Если последние факторы стимулируют развитие, команда становится менее отзывчивой и способной удовлетворять потребности клиентов.
2. Работающее ПО с исчерпывающей документацией.
Agile Manifesto приуменьшает значение документации процесса разработки, которая исторически занимала огромное количество времени и часто увязала в работе команды.Избегая неважных мелочей, Agile смещает фокус команды с самого процесса на результаты процесса (фактически работающее программное обеспечение).
3. Сотрудничество с клиентами при заключении контракта.
В традиционных методах управления проектами, таких как Waterfall, клиенты очень подробно обсуждают требования к продукту до начала любой работы, и обычно они участвуют только в начале и в конце.
В Agile клиент становится важным соавтором на протяжении всего процесса разработки, гарантируя, что его вклад включен, а результат соответствует его потребностям на этом пути.4. Реагирование на переход по плану.
Поскольку постоянная адаптация не встроена в традиционный процесс разработки программного обеспечения, изменения — это дорогостоящая головная боль. Agile принимает изменения, сосредотачиваясь на выпуске минимально жизнеспособного продукта, который можно оценивать и корректировать от итерации к итерации.
Принципы Agile Manifesto.
12 принципов Agile Manifesto, расширяющие исходный манифест, включают:
Наивысшим приоритетом является удовлетворение клиента за счет ранней и непрерывной поставки ценного программного обеспечения.
Команда проекта приветствует изменяющиеся требования даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, отдавая предпочтение более коротким временным рамкам.
Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
Процесс строит проекты вокруг мотивированных людей, предоставляя им среду и поддержку, в которых они нуждаются, и доверяет им выполнение работы.
Беседа лицом к лицу — самый действенный и действенный метод передачи информации команде разработчиков и внутри нее.
Работающее программное обеспечение — важнейший показатель прогресса.
Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны поддерживать постоянный темп на неопределенный срок.
Уделяйте постоянное внимание техническому совершенству, а хороший дизайн повышает маневренность.
Простота необходима. Это искусство максимизировать количество невыполненной работы.
Самоорганизующиеся команды создают лучшие архитектуры, требования и проекты.
Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, и соответствующим образом корректирует свое поведение.
Актуальность сегодня.
С момента подписания Agile Manifesto широко распространенный подход к разработке продуктов добился многих успехов.Это привело к другим масштабируемым процессам Agile-разработки, таким как Scaled Agile Framework (SAFe) и Large-Scale Scrum (LeSS), которые помогают перенести Agile с арены разработки программного обеспечения в другие команды внутри предприятия. По данным Harvard Business Review, примерно 80% компаний используют по крайней мере некоторые аспекты Agile во всех своих основных бизнес-функциях: исследования и разработки; производство и операции; обслуживание и поддержка клиентов; маркетинг и коммуникации; продажи; и даже HR, финансы и администрация.
Ценности и принципы Agile в управлении проектами
Приступая к новому проекту на работе, важно иметь структуру, которая поможет вашему проекту добиться успеха. План важен, но может быть трудно понять, с чего начать. К счастью, существует множество проверенных подходов к управлению проектами, из которых вы можете выбирать — они называются методологиями, и многие из них сгруппированы в разные семейства для использования организациями.
Agile-методологии являются одними из самых популярных подходов к управлению проектами, и если вам интересно, почему, разгадка кроется в названии — Agile-методологии позволяют руководителям проектов быть проворными и гибкими, адаптироваться к возникающим проблемам и быстро меняться. к наиболее успешному способу работы.
Чтобы эффективно использовать Agile-управление проектами в своей организации, нужно многое понять. В этой части мы расскажем, что такое Agile, основные ценности и принципы Agile и как внедрить принципы Agile в ваш следующий проект.
Что такое гибкое управление проектами?
Прежде всего, что такое гибкое управление проектами? Проще говоря, это способ подхода к управлению проектами, который использует ценности и принципы Agile, чтобы проложить путь к успеху проекта. Agile использует набор из четырех ценностей и 12 принципов, которыми руководствуются руководители проектов в своей работе.
Эти ценности и принципы Agile были впервые разработаны и изложены в уставе, известном как Agile-манифест, который был написан в 2001 году на собрании разработчиков и профессионалов в области программирования.Манифест Agile был создан, чтобы найти решение для старых методологий и процессов управления проектами, которые считались неприменимыми для современных проектов.
Манифест Agile подписали 17 человек, которые впоследствии стали известны как Agile Alliance. После того, как манифест был выпущен, Альянс в конечном итоге насчитывал более 72 000 членов по всему миру, которые все придерживаются ценностей и принципов Agile-управления проектами в своей повседневной работе.
Итак, какими проектами можно управлять с помощью Agile? Хотя изначально он был разработан специально для проектов программирования, Agile оправдал свое название и смог быть адаптирован для множества различных проектов в самых разных отраслях.Agile — это гибкий вариант для проектов, который позволяет изменять цели, не влияя на общий успех проекта. Эта гибкость означает, что Agile подходит для команд, которым нравится двигаться быстро, без слишком большого количества ограничений или сроков. Если ваша команда последовательна в общении, менее структурирована и более адаптируема, Agile может быть для вас.
Но каковы основные ценности и принципы, составляющие методологию Agile? Давайте подробно рассмотрим каждый из них.
Каковы четыре ценности Agile?
Прежде всего, давайте рассмотрим ценности Agile.
- Индивиды и взаимодействие через процессы и инструменты
Это краеугольный камень Agile-управления проектами — отдавать предпочтение общению и межличностным отношениям, а не строгим процессам. Agile рекомендует более персонализированный подход к управлению проектами, при котором команды постоянно общаются, а не полагаются на более застойные запланированные обновления. - Рабочее программное обеспечение поверх исчерпывающей документации
Agile-команды не большие любители бумажной работы.Они предпочитают использовать более гибкие программные решения для управления своими данными, отчетами и обновлениями статуса, а не традиционную документацию. - Сотрудничество с заказчиком в ходе переговоров по контракту
Agile-команды любят сотрудничество, которое включает в себя регулярное обновление и поддержание связи с клиентами и заинтересованными сторонами, чтобы получить их мнение о том, как продвигается проект. Длительные контракты с большим количеством изменений являются частью документации, от которой Agile-команды предпочитают отказываться. - Реагирование на изменение плана
Наконец, у нас есть ценность, которая прежде всего характеризует Agile-управление проектами. Agile-команды реагируют на изменения и успешно адаптируются к новым условиям и задачам.
Эти значения информируют о каждом процессе и задаче, выполняемой под эгидой Agile. Но каковы 12 принципов, которые углубляются в то, что делает Agile таким уникальным?
Каковы 12 принципов Agile?
Вы могли заметить, что многие принципы Agile относятся непосредственно к разработке программного обеспечения.Так как это было предысторией многих членов первоначального Agile Alliance, это было основным направлением Agile-манифеста. Однако эти принципы по-прежнему применимы к проектам в других областях и отраслях — давайте подробнее рассмотрим, как.
- Наивысшим приоритетом для нас является удовлетворение клиента за счет быстрой и непрерывной поставки ценного программного обеспечения
Agile-команды ставят удовлетворение своих клиентов на первое место и отдают приоритет получению результатов через регулярные промежутки времени, а не ждут одного окончательного раскрытия в конце процесса. - Приветствуйте меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента
Agile-команды готовы и способны вносить изменения даже в последнюю минуту. Это дает им преимущество перед более традиционными командами, которым может быть не так легко сменить руководство. - Поставлять работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, предпочтительно в более короткие сроки
Опять же, мы отмечаем, что Agile-команды занимаются регулярным и последовательным общением, а не запланированными обновлениями, которые могут быть слишком далекими друг от друга, чтобы быть пригодными для клиентов.Scrum-команды, которые подпадают под эгиду Agile, разбивают свои рабочие нагрузки на временные рамки продолжительностью от одной до четырех недель, известные как спринты. - Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта
Сотрудничество является ключевым в Agile не только между членами команды, но и с заинтересованными сторонами, разработчиками, клиентами и другими соответствующими сторонами. - Создавайте проекты вокруг целеустремленных людей. Предоставьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы
Agile-команды успешны, потому что они формируют свою команду с нужными людьми для проекта.Как только члены вашей команды получат поддержку, совместную работу и инструменты, необходимые им для достижения успеха, все остальное приложится. - Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу
Мы все можем признать, что ничто не может заменить личное сотрудничество, когда речь идет об управлении проектами. Но этот принцип применим и к нашим «новым нормам» гибридных моделей и моделей удаленной работы. Zoom и Teams — отличная альтернатива телефонным звонкам и электронной почте, и команды также могут приложить усилия, чтобы встретиться лично, чтобы обсудить ключевые моменты прогресса на протяжении всего проекта. - Работающее программное обеспечение является основным показателем прогресса
Этот принцип ссылается на программное обеспечение в качестве основного результата, но его идея остается неизменной — ваша команда всегда должна быть сосредоточена на том, чтобы предоставить своим клиентам максимально качественный результат. Если они довольны, то это самый сильный показатель успеха вашего проекта. - Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного времени
Это может быть трудной задачей для многих команд, которые могут выйти из ворот с быстрым прогрессом, прежде чем замедлится до конца проекта.Agile-команды должны обеспечить постоянство темпа своей работы на протяжении всего проекта. - Постоянное внимание к техническому совершенству и хорошему дизайну повышает гибкость
Agile — это не подход «один и готово» к управлению проектами. Каждый новый проект дает возможность для инноваций и создания чего-то нового, а не для повторения одних и тех же идей. - Простота — искусство максимального увеличения объема незавершенной работы — необходима
Agile-команды не увязают в чрезмерном усложнении — они выполняют свои требования, хорошо выполняют свою работу и переходят к следующему проекту. - Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами
Лучшие команды — это те, у которых есть лидер, который не боится позволить им блистать. Микроуправление редко делает какую-либо команду лучше или продуктивнее, и Agile-команды — отличный пример того, что может произойти, когда это не так. - Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, затем соответствующим образом настраивает и корректирует свое поведение
Непрерывное совершенствование — это суть игры в Agile, а регулярные обзоры производительности команды в целом могут помочь избавиться от бесполезных привычек и привести к большему успеху.
Как внедрить ценности и принципы Agile в ваши проекты
Возможно, вы готовы попробовать Agile-управление проектами, но задаетесь вопросом, как лучше следовать рекомендациям манифеста.
Не существует единого способа внедрить ценности и принципы Agile в ваши проекты. Agile-манифест — это интуитивно понятное руководство для ваших команд. Если вы придерживаетесь основных идей Agile, вы можете адаптировать его в соответствии с потребностями своего проекта.
Один из способов добиться успеха — использовать программное обеспечение для управления проектами, совместимое с принципами Agile.Инструмент управления совместной работой, такой как Wrike, может помочь вашей Agile-команде добиться успеха благодаря таким функциям, как:
.- Единый источник достоверной информации для отчетов, правок и комментариев без ненужных документов
- @упоминания и интеграция приложений, которые гарантируют, что вся коммуникация может осуществляться в одном месте для быстрых и последовательных обновлений
- Настраиваемые формы запроса и приема, чтобы можно было четко расставить приоритеты в работе и получить максимальную отдачу от каждого спринта
- Готовые к использованию шаблоны для вашей команды, включая Agile-командную работу, планирование спринтов, проекты Kanban и многое другое
Узнайте, как Wrike может помочь вашей команде добиться успеха в Agile.
Начните бесплатную двухнедельную пробную версию прямо сейчас.4 ценности Agile Manifesto, которые выведут ваш бизнес на новый уровень
Гибкая разработка стала стандартным процессом для многих технологических компаний благодаря своей прозрачности и быстрым результатам. Agile Manifesto продолжает влиять на современные методы разработки программного обеспечения, в первую очередь потому, что предлагает свежие альтернативы и доверие к процессу разработки программного обеспечения. Клиентоориентированный подход Agile Manifesto, пожалуй, более актуален и востребован сегодня, чем в 2001 году, когда группа из 17 разработчиков из Юты впервые представила манифест.Следуя фундаментальным ценностям Agile Manifesto и усердно применяя их, многие организации смогли эффективно отслеживать ход и успех проекта.
76% респондентов опроса, проведенного KPMG, считают, что к концу этого года гибкие проекты превзойдут число традиционных проектов.
Agile-разработка предлагает как итеративный, так и поэтапный набор практик для управления.
Это позволяет командам разработчиков сосредоточиться на быстрой доставке ценности для бизнеса в прогрессивной среде.Все методы Agile-управления проектами, такие как Scrum, Kanban и XP, поддерживают Agile-манифест, чтобы обеспечить плавную разработку, более высокую производительность, большую адаптируемость и превосходную поставку продукта, тем самым приводя к Agile-трансформации организации.Истоки Agile-манифеста
В 90-е годы одной из серьезных проблем для организаций был значительный временной разрыв между определением бизнес-требований (запросов от клиентов) и доставкой решений, которые могли удовлетворить соответствующие требования.К тому времени, когда конечный продукт будет готов, он также будет избыточен, поскольку реквизиты заказчика изменились бы из-за лага. Скорость и маневренность стали серьезной причиной для беспокойства при разработке продуктов, и широко используемая модель водопада не могла решить эту проблему.
Разочарование из-за низкой продуктивности разработки программного обеспечения привело к тому, что в 2001 году группа из 17 идейных лидеров объединилась на горнолыжном курорте в штате Юта, чтобы найти решение и в результате записать Манифест и его принципы.
Этот документ, проложивший путь к новым подходам к разработке программного обеспечения, с тех пор широко используется несколькими организациями по всему миру.Что такое Agile-манифест?
Краткий документ с 4 ценностями и 12 принципами гибкой разработки программного обеспечения, манифест резко отличается от традиционных методов. Agile Manifesto продолжает изменять процессы разработки программного обеспечения, подчеркивая при этом потребности клиентов. Однако он не навязывает какой-либо процесс или руководство для гибкой методологии.Вместо этого он предлагает теоретический подход к разработке программного обеспечения.
12 принципов Agile-манифеста
ИсточникЦенности и подход Agile фокусируются на поэтапном и поэтапном создании программного обеспечения для выпуска его версий (пользовательских историй) в определенные периоды или спринты. В отличие от традиционного процесса, Agile не создает программное обеспечение после одновременного сопоставления всех требований, а допускает итерации и гибкость на протяжении всего процесса.
Четыре ценности Agile-манифеста
Как упоминалось ранее, манифест включает четыре основополагающие ценности и двенадцать поддерживающих принципов Agile, чтобы сосредоточиться на выпуске высококачественного программного обеспечения.Вот подробный взгляд на 4 ценности Agile.
1. Люди и взаимодействие важнее процессов и инструментов
Сосредоточив внимание на общении, это значение придает отдельным лицам и взаимодействиям большее значение, чем процессам и инструментам. Если группы будут работать согласованно, они смогут более эффективно управлять процессом, быстрее реагируя на бизнес-требования и функциональные требования. Когда в деятельности доминируют инструменты и процессы, члены команды могут стать менее восприимчивыми к потребностям клиента и, в конечном итоге, клиентов.
Всегда рекомендуется поощрять общение между командами, а не полагаться на процедуры для управления продвижением вперед. Члены команды могут быть гибкими и оперативными в решении проблемы, а не полагаться на инструменты или процессы, что делает их более ориентированными на время и менее частыми.
2. Работающее программное обеспечение важнее полной документации
Здесь главное время — подход Agile не полностью игнорирует документацию, но предлагает разработчику работающее программное обеспечение для начала работы.Традиционное управление проектами включало в себя обширную документацию, которая предполагала задержку на несколько месяцев. Это повлияло бы на реализацию проекта, и задержки были неизбежны.
Чем раньше вы решите проблемы с отзывами клиентов, тем быстрее вы сможете перейти к следующей проблеме или проекту. Agile оптимизирует документацию и предлагает разработчикам то, что им нужно для поддержания работы, не отвлекаясь на технические вопросы. Agile ценит документацию, но еще больше ценит работающее программирование.Это означает, что команды реагируют и готовы принять вызов, когда это необходимо, придерживаясь мышления продукта, а не мышления проекта.
3. Сотрудничество с клиентами при заключении контракта
Переговоры по контракту обычно происходят, когда клиент и менеджер по продукту работают над деталями продукта в начале процесса с небольшими возможностями для изменений в процессе.
Это сильно исключает возможность участия заказчика в процессе разработки.Манифест Agile отдает предпочтение сотрудничеству с клиентами, а не переговорам по контракту. Сотрудничество с клиентами относится к процессу объединения клиентов на протяжении всей процедуры разработки.Agile позволяет вести открытое обсуждение между заказчиком и разработчиками. Это позволяет скоординированным командам лучше соответствовать требованиям клиентов. Преданный владелец продукта может помочь команде прояснить ситуацию в режиме реального времени и скорректировать задачи в соответствии с потребностями клиента.
4.Реакция на изменение плана
Обычный подход к жизненному циклу разработки программного обеспечения заключается в том, чтобы избегать любых изменений, поскольку они могут повлечь за собой затраты и привести к увеличению расходов. Однако с Agile из-за нескольких итераций задачи продолжают меняться, и с каждым спринтом эти входные данные помогают проекту становиться лучше и создавать ценность.
Ценность заключается в том, чтобы быть восприимчивым к требованиям клиентов во время проекта, а не создавать сложные планы с самого начала, которые пренебрегают изменениями.Изменения — это постоянный процесс, и иногда клиентам могут потребоваться новые дополнения, функции и т. д. к продукту. Адаптация к их требованиям может помочь владельцу продукта и командам создать более точный продукт и обеспечить удовлетворение своих клиентов.
Заключение
Ценности Agile Manifesto предлагают предприятиям возможность стремиться к совершенству. Манифест способствует созданию атмосферы доверия, прозрачности, командной работы и сотрудничества с клиентами. Хотя методологии программного обеспечения кажутся простыми, всегда рекомендуется сотрудничать с экспертами, которые понимают важность создания отличного продукта и удовлетворения потребностей клиентов.Если ценности и принципы Agile усердно применяются в процессе разработки программного обеспечения, они, безусловно, могут оказать положительное влияние на продукт и, в конечном итоге, на бизнес.
Что такое гибкое управление проектами? Ценности, принципы и этапы
- Карьерный справочник
- Развитие карьеры
- Что такое гибкое управление проектами? Ценности, принципы и этапы
12 января 2022 г.
Agile-управление проектами — это процесс разбиения проекта на управляемые этапы с упором на оперативность и сотрудничество с клиентами.Гибкое управление проектами отличается от традиционных методов управления проектами несколькими важными моментами. В этой статье мы обсудим, что такое управление проектами Agile, основные ценности и принципы управления проектами Agile, а также шесть этапов процесса управления проектами Agile.
Связанный: Важность управления проектами
Что такое гибкое управление проектами?
Гибкое управление проектами — это относительно новый метод, который фокусируется на гибкости и переоценке в процессе разработки продукта.Компании, внедряющие Agile-управление проектами, как правило, быстрее производят свою продукцию.
Agile-управление проектами предлагает преимущества на протяжении всего производственного процесса, а не только в конце. Гибкое управление проектами можно применять во всех отраслях, хотя эта структура приобрела популярность в секторе программного обеспечения, а некоторые основные ценности и принципы относятся непосредственно к разработке программного обеспечения.
Сравнение традиционного и гибкого управления проектами
Гибкое управление проектами отличается от традиционного управления проектами.В традиционной модели команда проекта ставила бы конкретную цель, создавала серию шагов для достижения этой цели, а затем реализовывала процесс. Agile-управление проектами разбивает проект на небольшие цели или спринты и использует частые оценки для изменения шагов и даже, возможно, конечной цели. Традиционное управление проектами линейно: каждый шаг должен быть завершен, прежде чем можно будет начать следующий. Agile-управление проектами является итеративным — над этапами можно работать одновременно и оценивать их в одно и то же время.
Среди множества различных методологий, вот некоторые из наиболее распространенных в управлении проектами Agile:
Люди и общение ценятся больше, чем процессы и инструменты
Программное обеспечение ценится больше, чем документация важнее переговоров по контракту
Адаптация к изменениям ценится больше, чем следование плану
- Влияние. Решает ли это важную бизнес-проблему? Масштаб
- — влияет ли это на большую часть аудитории?
- Выполнимость — Можем ли мы выполнить этот тест? Насколько сложно реализовать?
- Измеримый — можем ли мы точно измерить и определить со статистической значимостью, если это сработает?
- Измеримая цель и легкая стратегия для руководства командой
- Короткие итерационные циклы (или спринты) с ограничением по времени для выполнения, обычно две-четыре недели
- Аналитический обзор для выявления новых возможностей и корректировки стратегии
- Организация хочет, чтобы все использовали один и тот же процесс и систему запросов для взаимодействия с командой инфраструктуры, чтобы они могли лучше управлять своей рабочей нагрузкой.Ожидается, что все данные будут указаны в билете. Тем не менее, Скрам-команда может обратиться и попросить, чтобы кто-то из команды инфраструктуры был доступен на неполный рабочий день, чтобы помочь спроектировать более крупное и сложное решение и построить его поэтапно, быстро адаптируя дизайн по мере того, как они узнают больше в каждом спринте.
- Скрам-команда использует специальный инструмент для сбора элементов невыполненной работы по продукту. Однако понимание приходит из совместных разговоров, которые они ведут во время доработки и разработки.
- Скрам-команде сообщают, что необходимо заполнить несколько «необходимых» документов по соответствию проекту.Некоторые из этих документов не кажутся достаточно ценными и в конечном итоге задерживают поставку рабочего продукта. Вместо того, чтобы просто принять статус-кво и «поставить галочку», эта Scrum-команда говорит, что она является PMO, чтобы лучше понять цель документов. Вместе они обнаруживают, что Scrum-команда может достичь цели другими способами, которые являются более эффективными и действенными.
- Вместо подробной технической документации, на которую редко ссылаются, которую трудно использовать и которую сложно поддерживать, разработчики могут выбрать различные способы получения технической документации.Например, они могут написать свой код в виде документации с определенными стандартами, согласованными с командой. У них может быть более краткая и удобная версия технической документации для поддержки, может быть, даже фотографии рисунков на доске.
- Во время спринта разработчики показывают владельцу продукта, как развивается функция.Владелец продукта понимает, что то, о чем он изначально просил, не будет соответствовать потребностям бизнеса. Несмотря на то, что потребуются доработки, разработчики сотрудничают с владельцем продукта, чтобы упростить функцию, чтобы она могла лучше соответствовать бизнес-потребностям, но при этом иметь возможность получить завершенный приращение к концу спринта. Владелец Продукта добавляет новый PBI в Бэклог Продукта, чтобы зафиксировать части функции, которые не будут включены в этот Спринт. PBI не должны быть контрактами.
- Вместо того, чтобы заключать контракт с фиксированным объемом, фиксированным бюджетом и фиксированным графиком, Скрам-команда открыто заявляет о непредсказуемости и сложности предоставления решения. Болезненные процессы запроса на изменение часто встроены во многие проекты с фиксированной ставкой. Клиенты вынуждены платить больше, чтобы получить продукт, который они хотят, но попытка «управлять изменениями» таким образом сопряжена с большими накладными расходами. Вместо этого Скрам-команда сообщает клиенту, что они могут детализировать и даже строится.Клиент будет получать что-то готовое к выпуску в каждом спринте и сможет направлять направление продукта, когда он увидит и использует работающий продукт. Влияние на стоимость и график будет прозрачным, и клиент сможет расставлять приоритеты и принимать обоснованные решения. Этот тип сотрудничества и прозрачности укрепляет доверие.
- Скрам-команда создает новую функцию. Они выпустили раннюю версию этой функции с некоторыми ключевыми преимуществами для пользователей.Однако владелец продукта обнаруживает из данных об использовании, что этой функцией пользуется меньше людей, чем ожидалось. Отзывы клиентов показывают, что люди не будут платить дополнительно за эту премиум-функцию. Владелец Продукта переупорядочивает Бэклог Продукта так, чтобы PBI, связанные с дальнейшими улучшениями этой функции, были ниже. Скрам-команда может сосредоточиться на следующем приоритете, в то время как Владелец Продукта проводит дополнительные исследования, чтобы определить, как улучшить новую функцию.
- В середине спринта разработчики обнаруживают, что реализовать функцию будет намного сложнее из-за сложности интеграции.Они оценивают варианты и определяют, что единственный способ предоставить готовый к выпуску Инкремент и достичь Цели спринта — это значительно сократить объем функции. Получив информацию от Владельца Продукта, Разработчики полностью воссоздают Бэклог Спринта. Несколько PBI удалены. Новый PBI создается, чтобы зафиксировать минимальную функциональность, которая может быть предоставлена как для проверки технического подхода, так и для получения отзывов о ценности от заинтересованных сторон на обзоре спринта.
- Каковы примеры случаев, когда мы решили оценить элемент слева и почему? Каковы примеры случаев, когда мы решили оценить элемент справа и почему? Выберем ли мы что-то другое в следующий раз?
- Каким образом ценности/принципы проявились во время прошлого спринта?
- Какие ценности/принципы вызывают у нас наибольший вызов? А что бы облегчить?
- Какие препятствия мы должны преодолеть, чтобы ввести в действие эту ценность/принцип?
В соответствии с agile-философией передача программного обеспечения в руки клиентов является наивысшим приоритетом.В конце концов, как вы собираетесь улучшать свой продукт, если не выпускаете его в свет и не собираете отзывы реальных пользователей?
Agile-философия (и многие формализованные процессы, вытекающие из нее) поощряют встраивание непрерывного цикла обратной связи с клиентами в циклы разработки.
Менеджеры еще нужны:
, которая предлагает консультации по процессам XP и Agile, консультации по разработке программного обеспечения, обучение и услуги по разработке для крупных корпораций по всему миру.
В Agile клиент становится важным соавтором на протяжении всего процесса разработки, гарантируя, что его вклад включен, а результат соответствует его потребностям на этом пути.
Agile рекомендует более персонализированный подход к управлению проектами, при котором команды постоянно общаются, а не полагаются на более застойные запланированные обновления.
Agile-команды реагируют на изменения и успешно адаптируются к новым условиям и задачам.
Если они довольны, то это самый сильный показатель успеха вашего проекта.
Начните бесплатную двухнедельную пробную версию прямо сейчас.
Это позволяет командам разработчиков сосредоточиться на быстрой доставке ценности для бизнеса в прогрессивной среде.Все методы Agile-управления проектами, такие как Scrum, Kanban и XP, поддерживают Agile-манифест, чтобы обеспечить плавную разработку, более высокую производительность, большую адаптируемость и превосходную поставку продукта, тем самым приводя к Agile-трансформации организации.
Этот документ, проложивший путь к новым подходам к разработке программного обеспечения, с тех пор широко используется несколькими организациями по всему миру.
Это сильно исключает возможность участия заказчика в процессе разработки.Манифест Agile отдает предпочтение сотрудничеству с клиентами, а не переговорам по контракту. Сотрудничество с клиентами относится к процессу объединения клиентов на протяжении всей процедуры разработки.
Ценность заключается в том, чтобы быть восприимчивым к требованиям клиентов во время проекта, а не создавать сложные планы с самого начала, которые пренебрегают изменениями.
Все эти методы по-разному реализуют основные ценности, принципы и шаги гибкого управления проектами. Один может лучше подходить для вашего бизнеса, чем другой. Стоит изучить несколько методологий, прежде чем выбрать одну из них для продвижения вашего проекта.
Манифест Agile
В 2001 году семнадцать разработчиков программного обеспечения составили список основных ценностей и принципов Agile-управления проектами. Agile Manifesto — это сборник передового опыта, широко распространенный в отрасли.
Обратите внимание, что компания Indeed не связана с какой-либо третьей стороной, упомянутой в этой статье. Эта статья предназначена только для информационных целей и не должна рассматриваться как основной ресурс Agile Manifesto. Для получения дополнительной информации об этой методологии, пожалуйста, перейдите по ссылке выше.
4 основные ценности Манифеста Agile
Манифест Agile выделяет четыре основные ценности:
Принципы Agile-манифеста
В рамках Agile-манифеста было создано двенадцать принципов передового опыта.
Среди них эти принципы поощряют тесную связь между разработчиками программного обеспечения и клиентами, а также адаптируемость в быстро меняющейся среде и акцент на техническое совершенство и своевременную доставку. Полный список 12 принципов можно найти на веб-сайте Agile Manifesto, указанном выше.
Связанный: Руководство по управлению содержанием проекта
Этапы процесса управления проектами Agile
Управление проектами Agile состоит из шести этапов.
1. Планирование проекта
Перед началом любой работы команда должна определить конечную цель проекта.Однако цель должна быть относительно широкой, чтобы учитывать изменения и улучшения на протяжении всего процесса.
2. Создание дорожной карты проекта
Дорожная карта проекта состоит из всех функций, включенных в конечный продукт. Это не список шагов, а список элементов, которые можно выполнять несколько одновременно.
3. Планирование выпуска
После создания дорожной карты проекта составьте план выпуска.
Это календарь, когда прототипы или элементы продукта будут доставлены заказчику для ознакомления.Ожидается, что отдельные части всего проекта будут часто пересматриваться, а весь проект будет обновляться по мере необходимости.
4. Планирование спринта
Спринты — это короткие циклы проектирования, которые заканчиваются выпуском версии. Планирование спринта должно быть детальным. Каждый член команды должен знать, чего от него ожидают в течение каждого дня спринта.
5. Ежедневные встречи
Каждый рабочий день во время спринта должен начинаться с встречи. Здесь члены команды поделятся успехами и проблемами предыдущего дня, а также подтвердят задачи и цели на этот рабочий день.
6. Обзоры спринта и ретроспектива
Обзор спринта — это презентация элемента продукта покупателю. Во время этой встречи команда получит обратную связь и подготовится к пересмотру элемента или корректировке долгосрочной цели в соответствии с указаниями заказчика.
После обзора спринта команда соберется отдельно от клиента для проведения ретроспективы.
Здесь команда будет размышлять о спринте. Такие проблемы, как дисбаланс рабочей нагрузки, сроки и коммуникация, будут решены и улучшены в следующем спринте.
Связано: Понимание процессов и этапов управления проектами
6 основных ценностей гибкого маркетинга
Agile Marketing — это способ работы, который черпает вдохновение из Agile-разработки программного обеспечения с точки зрения маркетинга. Хотя следующие ценности были первоначально формализованы в 2012 году как Манифест Agile-маркетинга, за последние несколько лет люди быстро начали проявлять к ним интерес.
Часто, когда вы думаете об Agile, на ум приходят такие процессы и структуры, как Scrum, Kanban, Sprints и Retrospectives.Хотя будут случайные ссылки на эти процессы, основное внимание здесь будет уделено созданию основы для определения Agile-маркетинга. Давайте начнем с введения в основные ценности Agile-маркетинга, затем мы углубимся в то, как они отходят от принципов гибкого программного обеспечения, и объясним факторы успеха (и препятствия) на пути к внедрению.
Многие маркетологи считают, что их сдерживает отсутствие доступа к своевременным и точным данным для отчетов или наличие квалифицированных ресурсов для анализа и получения информации.Однако, как только мы начинаем исследовать процесс планирования кампании, мы часто видим, что существуют значительные пробелы в том, насколько на самом деле управляется данными маркетинговая организация. На самом деле, для многих компаний эмоции и инстинкты, а также то, что было сделано в прошлом, являются главными проводниками к тому, что будет сделано.
Традиционная маркетинговая команда обычно начинает с идеи проекта или кампании, которая обусловлена конкретной бизнес-потребностью. Что касается того, какой проект привлекает внимание команды, то это либо первый пришел первый обслужен, либо самый громкий и/или самый старший запросчик становится во главе очереди.Команды исполнителей будут проинструктированы, а программа будет разработана и запущена на рынок.
В Agile Marketing данные используются на каждом этапе пути. Он начинается с изучения возможных возможностей с использованием доступных результатов и идей, количественной оценки ожидаемой выгоды и принятия решения о том, что делать в первую очередь. На этом этапе программа разрабатывается, запускается и измеряется. Наконец, знания и возможности для оптимизации выявляются и возвращаются в следующий цикл проектов.
Хотя может показаться, что эти шаги затормозят процесс кампании, мы обнаружили, что команды, использующие этот способ работы, становятся более эффективными. Имея данные на стороне маркетинговой команды, чтобы определять стратегию и направление, команды больше не тратят время на бесконечные, основанные на мнениях дебаты о том, что и как делать.
Сравнение традиционного и гибкого маркетинговых процессов 2. Релевантно: Индивидуумы и взаимодействия более одного размера подходят всем Сосредоточение внимания на потребностях клиента — это серьезный сдвиг в мышлении разработчиков программного обеспечения, но это вторая натура большинства маркетологов.
Технологии являются препятствием для предоставления более персонализированного опыта. Хотя данные и технологии будут влиять на то, насколько быстро и далеко вы сможете продвинуться, есть и другие факторы, которые часто упускают из виду.
Основа должна быть сначала построена на хорошо продуманном видении будущего состояния, которое дает информацию для разработки пользовательских историй и вариантов использования. Для успешного выполнения потребуются не только данные и технологии, но и вспомогательные люди, процессы и измерения.
Активаторы клиентоориентированности 3.Nimble: быстрые итерации кампаний Big Bang Поговорка «Идеальное — враг хорошего» отражает суть того, почему маркетологам так трудно быть более ловкими. В старом мире маркетинга с его масштабными телевизионными кампаниями и длительными программами прямой почтовой рассылки ошибки обходились дорого, и было почти невозможно вносить изменения после того, как что-то было запущено.
Хотя эти ограничения не применяются к сегодняшнему цифровому миру, маркетологи сохранили эту перспективу избегания риска.Еще одно препятствие заключается в том, что, в отличие от Agile-разработки программного обеспечения, где легче представить постепенное улучшение продукта, гораздо сложнее представить отдельные компоненты кампании, потому что каждая программа рассматривается как целостная взаимозависимая сущность.
Решение состоит в том, чтобы разобрать каждый элемент кампании и найти способы получить более простую версию (которая по-прежнему оказывает влияние на бизнес), которая может быть реализована за меньшее время. Вместо бесконечного количества сегментов просто сосредоточьтесь на одном или двух.И если данные или технология не могут поддерживать полностью автоматизированный подход в режиме реального времени, подумайте, как можно использовать смешанный или даже полностью ручной процесс с использованием того, что у вас есть сегодня.
Будь то технологии, ресурсы или другие возможности, всегда будут препятствия.
В Agile есть уклон к действию, что означает принятие и максимальное использование несовершенного.
Этот принцип является воплощением основного убеждения Agile в непрерывном совершенствовании.Однако, когда бюджеты сжимаются, сроки сжимаются или ресурсы перерасходуются, первое, что нужно исключить из программы, — это тестирование. Мы понимаем, тестирование похоже на большую работу, и некоторые из нас помнят трудоемкие тесты, которые дали неутешительные результаты. Но проведение небольших экспериментов должно стать обязательной частью процесса кампании и включено в каждый бриф проекта.
Чрезвычайно важно решить, что тестировать. Часть проблемы заключается в том, что мы часто видим тесты, которые продиктованы прихотью руководителя или импровизированным добавлением члена команды с благими намерениями.Соображения должны включать:
Решает ли это важную бизнес-проблему? Реакция на этот принцип будет сильно различаться в зависимости от отрасли, в которой вы работаете.Те, кто работает в строго регулируемых областях, таких как банковское дело, страхование или фармацевтика, скорее всего, торжественно кивнут в знак признания необходимости быть более адаптивными. С другой стороны, те, кто работает в быстро развивающейся, слабо регулируемой отрасли, такой как розничная торговля, вероятно, думают: «План? Какой план?» Ни одна из крайностей не идеальна, но с точки зрения Agile облегченный план с достаточным количеством информации для руководства выполнением гораздо предпочтительнее подробной диаграммы Ганта с прописанными каждой задачей и связанными с ней зависимостями, и нет места для изменений или отклонений.
Один из способов структурировать проект для большей адаптивности — рассмотреть основные принципы Scrum — одной из наиболее известных структур Agile:
Суть в том, чтобы как можно быстрее интегрировать знания прошлых проектов в будущие стратегии, вместо того чтобы запирать себя в жестком плане, который пересматривается максимум один или два раза в год.
6. Интеграция: совместная работа в условиях разрозненности и иерархииЧтобы быть по-настоящему гибкой, организация должна эффективно сотрудничать, чтобы принимать наилучшие решения с учетом всего бизнеса.
Многие предприятия по-прежнему имеют традиционную структуру отделов: маркетинг, управление взаимоотношениями с клиентами, цифровые технологии, аналитика, финансы, коммерция.
Эти команды были созданы давно, чтобы обеспечить специализацию в различных предметных областях. Однако по мере роста компаний и команд ключевые показатели эффективности, ориентированные на показатели конверсии в каждом отделе, не всегда совпадают.Например, команда по привлечению нацелена на объемы чистых добавлений, независимо от качества клиента или скидки, предоставляемой для привлечения клиента. Это может привести к разочарованию в команде CRM, которая занимается удержанием, но имеет высокий уровень оттока новых клиентов с низкой ценностью.
Объединяя коллег для достижения общей цели, вы можете гораздо эффективнее объединить различные специальности, необходимые для комплексного мышления.
Простое изменение порядка подчинения или реструктуризация команды не всегда приводит к желаемым результатам.Многие организации просто переходят от горизонтальных отделов к вертикальным «кросс-функциональным» командам. При переходе на кросс-функциональную работу вы должны установить, как различные кросс-функциональные команды подходят друг другу, чтобы по-прежнему продвигаться к вашим бизнес-целям.
В последнее десятилетие термины отряды, племена и ордена стали более распространенными. Эта структура, разработанная Spotify, показывает, как лучше всего организовать людей в автономные команды (отряды) с общей целью; работа с другими отрядами для достижения общей цели (внутри племени).В каждой команде есть разные специализации (CRM, UX, платные медиа, понимание), которые делятся передовым опытом, обучением и разработками в разных командах, помогая развитию талантов и снижая риск того, что команды станут самостоятельными.
Правильная расстановка ролей в отрядах для достижения цели и обеспечения определенного уровня автономии в рамках ограниченной численности персонала может стать огромным шагом на пути к высокопродуктивной рабочей среде для совместной работы.
Чтобы команда была действительно эффективной, она должна быть автономной, что требует двух вещей:
1) Предоставление командам возможности принимать решения для достижения своих целей без одобрения других
2) Сквозные навыки, необходимые для того, чтобы не зависеть от внешней команды, которая работает с другими временными рамками и приоритетами
Автономия в команде не означает, что каждая роль или навык ДОЛЖНЫ быть в каждой команде.
Иногда лучше иметь определенные навыки, поддерживаемые центром компетенции или общей службой, работающей в нескольких группах.
Наиболее эффективные предприятия в этой области зашли так далеко, что изменили то, как команды и люди обязуются работать друг с другом. Эти предприятия внедрили «культуру сотрудничества», заключая новые социальные контракты, написанные их собственными командами, и даже изменили процессы найма, чтобы новые сотрудники соответствовали культуре команд сотрудничества.
Хотя может показаться, что это слишком много для размышлений, такой уровень изменений не происходит в одночасье. Ключевым соображением при реорганизации является то, что мы должны помнить, что имеем дело с людьми.Изменение ситуации может привести к некоторому уровню беспокойства и срыва. Мы должны признать, что нам нужно поддерживать людей во время изменений, но если мы не забудем придерживаться наших основных принципов гибкости и возьмем наших людей с собой в путешествие, они часто в конечном итоге будут способствовать нашему успеху.
Хотите узнать больше? Ознакомьтесь с отчетом Merkle о взаимодействии с клиентами за второй квартал здесь.
Ценности Agile на практике
Одна из самых важных вещей, которые мы можем сделать, чтобы помочь отдельным людям и командам стать лучше, — это научить их придерживаться гибкого мышления.Манифест гибкой разработки программного обеспечения содержит ценности и принципы, помогающие командам ориентироваться в сложностях разработки продукта. Он включает следующее утверждение: «Хотя элементы справа имеют ценность, мы больше ценим элементы слева».
Это означает, что мы не просто говорим «нет» пунктам справа. Это было бы слишком черно-белым. Однако мы используем эти значения, помогающие нам ориентироваться во множестве оттенков серого в сложной работе. В этом посте мы рассмотрим четыре ценности и приведем несколько примеров того, как они помогают командам принять этот образ мышления.
Индивиды и взаимодействие с процессами и инструментами Процессы и инструменты могут быть полезными, но они не идеальны.
Они не могут быть разработаны для соответствия всем сложным сценариям. Кроме того, они часто мешают, если им следуют слепо или без гибкости.
Вот несколько примеров, иллюстрирующих, как это значение может проявляться на практике:
За последнее десятилетие или около того появилось множество гибких инструментов и методов.Некоторые из них полезны, но многие используются в контексте традиционной модели, потому что организации думают, что могут «купить» стандартизацию и передовой опыт. Но это подрывает самоорганизующийся, совместный аспект Agile-команд.
Благодаря общению и сотрудничеству люди найдут лучший путь вперед. Не позволяйте процессам и инструментам мешать коллективному разуму.
Рабочее программное обеспечение вместо полной документации Работающее программное обеспечение является основным мерилом прогресса.Документация, скорее всего, должна быть создана, чтобы ее можно было опубликовать. Эта документация может быть частью рабочего процесса команды (например, обновление схемы архитектуры), автоматических тестов для поддержания качества или может быть чем-то, что используется клиентами и имеет определенную ценность, связанную с этим (например, продукт).
обучающее видео). Во многих случаях нулевая документация не будет профессиональной.
Вот несколько примеров, иллюстрирующих, как это значение может проявляться на практике:
У них может быть более краткая и удобная версия технической документации для поддержки, может быть, даже фотографии рисунков на доске.Делая акцент на том, чтобы всегда предоставлять что-то ценное, и переосмысливая, какая документация является ценной и как создавать документацию более эффективным способом, мы обеспечиваем гибкость.
Сотрудничество с заказчиком при заключении контрактаКонтракты важны и необходимы в бизнесе.Целью договора является установление достигнутого сторонами соглашения и закрепление их прав и обязанностей в соответствии с этим соглашением. Обязанности сторон определены до уровня детализации, необходимого для того, чтобы обе стороны чувствовали себя комфортно в отношениях. Подумайте, когда контракты необходимы, насколько ограничительными должны быть контракты и когда они могут препятствовать сотрудничеству с клиентами и гибкости бизнеса.
Срочный договор можно интерпретировать как формальный договор с внешней стороной или подразумеваемое обещание внутренней стороне.
Документы с требованиями часто используются в качестве контрактов, когда нет доверия к людям, запрашивающим характеристики и функции.
Сотрудничество с клиентами необходимо для обеспечения того, чтобы мы создавали правильные продукты. Люди часто затрудняются точно описать, чего они хотят. Часто людям нужно что-то увидеть, чтобы лучше понять, что они делают или чего не хотят.
Вот несколько примеров, иллюстрирующих, как это значение может проявляться на практике:
PBI не должны быть контрактами. Эта agile-ценность, в конечном счете, заключается в работе с вашими клиентами и построении доверительных отношений, а не в работе против ваших клиентов с помощью контрактов.
В быстро меняющемся и непредсказуемом мире мы должны уметь реагировать на изменения.Планы важны, потому что они помогают нам установить общие ожидания, исходя из которых мы можем затем оценить прогресс и определить, что могло измениться. Реагирование на изменения — это просто обновление плана, чтобы отразить то, что мы знаем сейчас. Поскольку план будет часто меняться по мере того, как мы проверяем и адаптируем его, мы должны облегчить его обновление.
Вот несколько примеров, иллюстрирующих, как это значение может использоваться командой Scrum:
Владелец Продукта переупорядочивает Бэклог Продукта так, чтобы PBI, связанные с дальнейшими улучшениями этой функции, были ниже. Скрам-команда может сосредоточиться на следующем приоритете, в то время как Владелец Продукта проводит дополнительные исследования, чтобы определить, как улучшить новую функцию.Регулярно размышляйте над этими ценностями
Ретроспектива спринта — отличное время для размышлений о том, как ценности Agile проявляются в повседневной работе команды.
Вы также можете ввести 12 основных принципов. Это возможность прояснить их значение с точки зрения поведения и результатов.
Вот несколько вопросов для размышления:
___________________________
Хотите углубить свои знания?
Если вам понравился этот пост, ознакомьтесь с моей книгой Mastering Professional Scrum.
В этой книге рассказывается, что значит эффективно применять эмпиризм, гибкое мышление и командную работу, чтобы по-настоящему раскрыть преимущества гибкости.
