Agile философия: Agile философия и ее польза для бизнеса

Agile философия и ее польза для бизнеса

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

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

 

 

 

В Agile вся работа держится на четырех основных ценностях:

 

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

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

 

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

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

 

 

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

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

Но сейчас нас уже 500, и я не уверен, что мы до сих пор верны этим ценностям.

У нас есть инструменты, процессы, переговоры по контрактам. Мы постоянно создаем презентации, документы, и следование плану берет верх над здравым смыслом». Следующий вопрос, который задает бизнес: «Как же мне это изменить?».

Очевидно, что это не те перемены, которые можно внедрить «с понедельника». Прийти на работу, сказать: «Сегодня у нас тренинг по Scrum и через три дня мы начинаем работать по Scrum». Нет, это так не работает. Agile – это не рубильник, который можно дернуть у себя в компании и сказать: «Мы стали Agile».

 

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

 

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

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

 

 

Вот почему важна каждая из четырех ценностей:

Люди и взаимодействие важнее, чем процессы и инструменты

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

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

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

Результаты поражают — организационные изменения инициируются «снизу» и реализуются при поддержке «сверху».

 

 

Взаимодействие с заказчиком важнее переговоров по контрактам

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

 

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

 

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

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

 

 

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

Некоторые клиенты говорят: «Черт возьми, зачем мы создаем идеальные презентации и документы? Просто чтобы продать идею внутри компании? А ведь лучше сделать рабочий прототип, показать его ценность, результаты действия на рынке и двигаться дальше».

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

 

 

Реакция на изменения важнее следования первоначальному плану

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

 

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

 

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

 

 

Agile — это непросто.

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

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

Что такое Agile (Аджайл) методология управления проектами

Содержание статьи

Что такое Agile

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

Agile-философия фундаментально отличается тем, что все процессы работы стараются быть максимально прозрачными, чтобы все заинтересованные стороны могли за ними наблюдать, а также внедрять ценные новые идеи как можно быстрее, а не “в новом квартале после обсуждения на квартальном совещании”.

Методология Agile строится на 12 принципах далее мы их рассмотрим.

Именно на этих agile принципах строятся agile-методы Scrum, Kanban и Scrumban рассмотренные в следующих статьях.

Основные принципы Agile-философии

Скачать для печати в .PDF

1. Давайте результат чаще (Deliver value faster)

Большой продукт/проект разбивается на небольшие кусочки, которые финалятся часто.

Пример применения этого принципа в создании корпоративного сайта:

Вместо сдачи через месяц корпоративного сайта через месяц, а потом переделывания его еще под пожелания пару месяцев, можно использовать принцип Agile так:

• Сперва делается карта сайта с основными разделами – она согласовывается с заказчиком
• Когда структура согласована – прописываются ключевые слова для разделов и пишутся идет основных статей / текстов => согласовывается с заказчиком
• Параллельно выбирается фирменный цвет (если его еще нет) и рисуется макет дизайна сайта => согласовывается с заказчиком
• Идет верстка сайта и наполнение контентом.

Таким образом вместо подхода:

1.Продали услугу по созданию сайта -> 2.Получили тех. Задание -> 3. Сдали в конце готовую работу через N недель -> 4. Переделываем М раз под хотелки заказчика

Используется подход:

1.Сделали кусочек – показали – согласовали

2.Сделали следующий кусочек работы – показали – согласовали

…

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

2.Изменения приветствуются (Welcome changes)

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

3.Выпускайте обновления продукта регулярно (Deliver working software frequently)

Главный критерий хорошего продукта – чтобы клиенты были довольны. Поэтому есть смысл регулярно собирать «хотелки» клиентов, и дорабатывать свой продукт в соответствии с ними.

Хорошим примером может служить сервис для создания сайтов – Тильда, где существует доска Trello с хотелками клиентов, и эти пожелания регулярно реализуются в виде обновлений/дополнений платформы.

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

4.Работайте сообща день за днем (Work together daily)

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

Особенно остро эта проблема проявляется в случае болезни или отпуска, когда многие вопросы просто «подвисают в воздухе» до момента пока сотрудник не выйдет на рабочее место.

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

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

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

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

Что делать если команда разбросана в разных странах?

И даже если они находятся на расстоянии – можно удобно организовывать онлайн-встречи с помощью таких инструментов как: групповые видео-звонки в Whatsapp/Facebook/Skype/Google Hangouts/Zoom (последние два позволяют делать еще записи онлайн-встреч).

Например некоторые компании даже доплачивают сотрудникам, чтобы они начали работать в удаленном формате.

В Agile-философии люди и их взаимодействие важнее процессов и инструкций.

5. Создавайте проекты вокруг замотивированных индивидов (Build projects around motivated individuals)

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

Если в вашем проекте по-другому – задумайтесь, а те ли люди рядом с вами?

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

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

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

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

6. Общение «лицом к лицу» (Face to face conversations)

Когда вы не видите глаза человека, очень тяжело понять его настрой и определить насколько он с вами честен.

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

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

7.Результаты важнее документов (Working software is a primary measure of progress)

В классическом методологии управления проекта значительное внимание уделяется подготовке проектной документации, которая как правило остается неизменной вплоть до реализации проекта.

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

Ведь если к вам придет 100 потенциальных клиентов и попросят внедрить какую-то современную фишку (например, выгрузку отчетов в телеграм-бота), то agile разработчики добавят эту фичу в прототип работающего продукта и клиенты смогут это тестировать уже через неделю, а не после того как через N месяцев проект будет завершен.

8. Разработка без перерывов (Sustainable development)

Так как большой проект разбивается на логически законченные «кубики»  (см. пункт 1), то разработка этих «кубиков» происходит регулярно, а если наступает момент, когда

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

И даже очень полезно сделать “буферные задачи”, которые команда выполняет в момент проверки основных заданий.

9. Качество кода и дизайн решают (Attention to technical excellence and good design)

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

Также важное место занимают дизайн и usability продукта (удобство интерфейса для клиента)

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

10. Простота (Simplicity)

В классическом же подходе продукт часто перегружается функционалом, который придумали основатели проекта.

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

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

Есть такое выражение «The art of maximizing the work not done» дословно это можно перевести как «Искусство максимизации работы которую делать не нужно». Agile-подход создает эффективные продукты/проекты «отсекая все лишние элементы». Главные критерии отсечения – это удобство для пользователя и скорость работы.

11.Команды, которые умеют самоорганизовываться (self-organising teams)

Чтобы проект стал успешным недостаточно просто наличия мотивированных индивидов. Гораздо важнее, чтоб эти мотивированные индивиды умели объединяться в команды и уметь работать в коллективе.

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

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

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

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

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

Поэтому, дружеский совет для собственников проекта и HR’ов – когда нанимаете руководителя проекта или CEO стартапа не поленитесь потратить время чтобы понять насколько он командный игрок (это лучше всего сделать с помощью испытательного срока и тестовых заданий, ориентированных на командную работу, а после тестового срока сделать личный опрос среди членов команды, насколько им было комфортно работать с этим человеком). Как вариант еще можно попросить будущего кандидата сыграть вместе с командой в деловую игру по управлению проектами (например Ферма.Project). Задача акционеров – понаблюдать за тем как человек ведет себя в команде со стороны: прислушивается ли к членам команды, дает ли положительное подкрепление сотрудникам за результаты, делегирует ли процессы и т.д.

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

12.Регулярно думайте о том, что можно улучшить в работе.

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

И совсем нет времени, чтобы собраться всей командой и задать себе вопрос «как в следующий раз сделать проект лучше?» – такие встречи называются ретроспективой (или ретро).

А те кто все же проводят ретроспективы, часто об этом сожалеют, т.к. участники превращают такие встречи в перепалки и личную брань!!!

Важные правила ретро:

– Высказываться коротко и по существу;

– Неприкосновенность личности – говорим о фактах, а не о людях;

– Уважаем себя и собеседника – не перебиваем!

– Когда озвучиваем проблему, предлагаем еще свой вариант решения.

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

Для этого как правило ищутся ответы на 3 вопроса:

1. Какие действия за период разработки «кубика» были особенно успешными.

2. Какие действия были провальными и почему.

3. Что можно улучшить в подходе к работе.

Искренность и самокритика на таких совещаниях очень поощряется.

Важное правило также: не критиковать людей, а критиковать результаты и стараться предлагать альтернативные идеи / решения.

Важные отличия Agile-подхода к управлению проектами от методологии «водопад» (waterfall)

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

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

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

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

В Agile подходе есть очень важный принцип «деление большого на малое» и дальнейшее последовательное «зафиналивание» малых частей.

Если бы я был на месте руководителя того проекта, то

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

Б) после этого была бы запущена разработка альфа-версии продукта с упрощенным функционалом и коротким сроком (например, 2 спринта по 2 недели на разработку и 1 неделю на тестирование)

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

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

Д) на основании этих данных была бы внесена корректировка в фин. модель

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

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

Выводы об Agile методологии

Главная сложность по внедрению принципов Agile в организации – это кардинально другая философия и нежелание людей меняться (особенно старожил, которые проработали в организации не один год).

Ведь в Agile-проектах сразу становится понятно:

– кто работает неэффективно и без энтузиазма;

– кто «индивидуальный игрок» а кто командный;

– кто умеет слышать других людей и клиентов, а для кого его мнение самое важное;

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

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

В следующих статьях мы рассмотрим такие agile-методы управления проектами как Scrum, Kanban и Scrumban, которые подойдут как для управления проектами в сфере IT, так и в любых других сферах.

С уважением Александр Цыглин,
основатель Мастер Продуктивности и проекта SkillsMarketplace.ru
(Facebook / Linkedin / Instagram / Youtube)

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

---

Что еще почитать об управлении проектами:

---

Agile для бизнеса больших и маленьких компаний

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

Термины: Agile, Scrum, Kanban

Agile (Аджайл) — это методология, идеология, система ценностей, философия в управлении проектами.

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

Существует множество различных гибких подходов на основе методологии Agile. Самые популярные практики, или другими словами гибкие подходы, которые были созданы на основе идеологии Agile, или, как их иногда называют, фреймворки (frameworks) это Scrum и Kanban.

Скрам (Scrum — в переводе с английского — схватка) — это практика, гибкий фреймворк, основаный на философии Agile и позволяющий организовать работу команды. Scrum объединяет в себе элементы и классического подхода Waterfall (водопад) и идеологию гибкого подхода.

Agile Scrum характеризуется: кросс-функциональная команда 5-9 человек, короткие спринты 2-4 недели на каждый спринт, на выходе каждого спринта быстрые и видимые промежуточные результаты. Scrum значительно сокращает время и увеличивает производительность проектной команды по сравнению с классическим подходом Waterfall.
Практика скрам подходит как для маленькой так и для большой компании.

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

Что такое Agile для бизнеса

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

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

Посмотрите на динамику компаний за последние 50 лет. Средний срок жизни компаний сместился с нескольких десятков лет до 2-5 года жизни. Компании дохнут как мухи, не выдерживая конкуренции в современном мире.

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

1-2 года на принятие управленческих решений по классической системе управления и старые методы выпуска новых продуктов приводят к тому, что к моменту выхода на рынок новый продукт становится никому не нужным.

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

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

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

Комплексная Agile трансформация компании

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

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

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

По ходу создания продукта в компании с философией Agile идет постоянная коммуникация с клиентом сбор обратной связи и корректировка разработки с фокусом на ценность для клиента.

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

Это работа со всеми департаментами: продажи, маркетинг, hr, бухгалтерия, разработка, производство, логистика, работа с командой и ее оптимизация, активизация творчества и талантов, другое отношение команды к своей работе и так далее.

ТОП менеджмент во многих крупных российских компаниях уже не первый год отцифровывает как можно больше бизнес функций: hr, продажи, маркетинг, производство, бухгалтерию, логистику для того, чтобы результативнее управлять, отслеживать статистику в динамке, повышать эффективность, и в конечном счете стать более конкурентоспособным в своем рынке. Это делается с помощью всевозможных ит-решений, не нуждаются в представлении ERP класса 1C или SAP.

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

Гибкие подходы Agile практикуют уже Альфа-Банк, Райффайзен, Сбербанк, Яндекс, …. несколько десятков крупных российских компаний у нас и несколько тысяч западных по всему миру работают по аджайл.

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

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

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

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

ЭТАПЫ ВНЕДРЕНИЯ AGILE

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

• Этап 1. Выбор гибкой методики управления проектом, которая отвечала бы всем вашим требованиям

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

• Этап 2. План внедрения в компании гибкого framework Agile

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

• Этап 3. Обучение персонала

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

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

• Этап 4. «Пилотный проект»

  Первый боевой проект вашей команды под руководством нашего опытного коуча-наставника.

 

AGILE: ЕСТЬ ПРОТИВОПОКАЗАНИЯ, ПЕРЕД УПОТРЕБЛЕНИЕМ ПРОКОНСУЛЬТИРУЙТЕСЬ С НАШИМ AGILE — коучем

Agile не универсальная таблетка, когда и где не стоит применять Agile

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

 

  Если вашей компании нужна комплексная AGILE трансформация, наша команда к вашим услугам, позвоните нам +7 (985) 261-92-55 установочная встреча для Вас бесплатна

 

 

популярные мифы о гибкой разработке / Хабр

Методологии гибкой разработки (Agile) прижились и в IT, и в не-IT, обросли своими приметами, стереотипами, суевериями и мифологией. Редакция блога Mail.Ru Cloud Solutions решила поговорить об этой мифологии с Agile-коучем Василием Савуновым из ScrumTrek.

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

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

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

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

Миф 1. Agile — это только для IT

Уже нет. Достаточно посмотреть на список компаний, от лица которых выступают спикеры на конференциях Agile Days и Agile Business Conference: «Газпромнефть», «Ростелеком», «Северсталь», PTG-Group, 12Storeez. Эти и масса других организаций, не относящихся к IT-индустрии, более чем успешно используют Agile-подходы.

Миф 2. Agile — не для проектов с фиксированным бюджетом

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

Миф 3. Agile — панацея для бизнеса и разработки: внедри, что-нибудь да улучшится

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

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

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

Миф 4. Scrum, Lean, Kanban не пересекаются между собой

Следует разделять методологии и инструменты. Методология — это алгоритм построения рабочего процесса. Инструменты – это те «кирпичики», которые в этом алгоритме используются.

Разные методологии могут включать в себя одни и те же инструменты, но в разной компоновке. Часто можно увидеть, как при реализации Scrum прибегают к инструментам XP (экстремального программирования) или Kanban. И это нормально, так как все они отвечают ценностям Agile, и позволяют сделать рабочий процесс создания продукта гибким.

Если рассуждать о конкретных Agile-подходах, которые сейчас получили наибольшее распространение, то это, безусловно, Scrum и Kanban. Другие — FDD, XP, RUP и так далее, либо сошли со сцены, либо редко применяются целиком, но отдельные инструменты из их арсенала задействуются при реализации Scrum или Kanban.

Методологии гибкой разработки

Миф 5. Scrum — это как быстро и дёшево сделать продукт

Насчёт «быстро» всё верно, а вот насчет «дёшево» — нет. Судите сами: вам нужно сформировать полноценную команду, выделив в неё на 100% нужные компетенции. Эти люди будут заняты

только

разработкой вверенного им продукта и ничем другим, а значит, придётся либо нанять таких специалистов, либо «оторвать» их от какого-то отдела. То же самое касается бизнес-части: хочешь, не хочешь, а потребуется выделить владельца продукта, который 50–80% своего времени будет уделять только этой команде и её продукту.

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

Спринты

Спринт — термин из арсенала Scrum. Это фиксированный отрезок времени, в течение которого команда делает часть продукта, имеющую ценность для заказчика. Смысл — в том, что за каждый спринт команда должна сделать ещё один шаг, к цели, который можно «пощупать», оценить по реальному результату. Чаще всего длина спринта составляет 2 недели.

Спринт включает 4 обязательных встречи: планирование, реализация, релиз, спринт-ревью с ретроспективой. Кроме того, каждый день проводятся короткие встречи (stand-up meetings), на которых члены команды в едином формате «сверяют часы» и согласуют свои действия. Добавлять новые задачи в открытый спринт нельзя — это приучает команду к планированию и страхует от возникновения управленческого хаоса.

Миф 6. Канбан — это доски с вывешенными на них задачами

Вовсе нет! Доски — это лишь первый, самый простой шаг в Канбане. Но им дело

не ограничивается

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

Если в двух словах, то главный смысл Канбана — в том, чтобы:

• Сделать текущий рабочий процесс прозрачным, причем охватить все стадии — от возникновения задачи в голове бизнеса до ее реализации и отгрузки продукта потребителю.
• Управлять рабочим процессом, выявляя потери времени и устраняя их. Таким образом, мы делаем наш рабочий процесс предсказуемым.
• Принимать управленческие решения на основе метрик, а не ощущений.

Миф 7. Scrum и Канбан можно насадить в любых проектах и компаниях

Мне не нравится слово «насаждение», всё-таки Agile — про работу с людьми. Правильнее будет говорить о том, чтобы «прививать» команде новую философию мышления.

При этом, алгоритм прививания Scrum и Канбан — разный.

Степень успешности использования Scrum зависит от главенствующей в компании корпоративной культуры. В жёсткой иерархической структуре, где на каждый чих нужна бумажка, никакие усилия по «выращиванию» Scrum не увенчаются успехом без поддержки топ-менеджмента. Придётся встраивать новую, параллельную структуру, основанную на командном подходе. Своего рода «заповедник Agile», который будет защищать кто-то из управленцев высшего эшелона. В таких условиях есть возможность показать быстрый результат за три-четыре месяца. Но впереди будет задача посложнее — распространить эту культуру на всю организацию. Сколько это продлится, оценить крайне сложно. Но, по моему опыту, если новый подход охватил 30 % компании, то дальше он начинает распространяться сам, и ему больше не нужна защита сверху.

Внедрение Scrum вообще требует больших изменений, как в структуре организации, так и в контрактовании с подрядчиками (нужен контракт time & material), и в бюджетировании (поэтапное бюджетирование), и во всём остальном.

Kanban столь радикальных изменений не требует. Он предлагает: «Начните с того, что есть, и начните эволюционно это улучшать». Скорость изменений будет значительно ниже, чем в Scrum, зато все изменения будут основываться на статистике и иметь чёткое обоснование.

Миф 8. Scrum рассчитан только на проекты, которые делаются с нуля

Бывают разные случаи, нет какого-то жёсткого правила, что Scrum предназначен только для разработки с нуля. Переводить существующие проекты на Scrum не только возможно, но часто и целесообразно. Всё зависит от готовности исполнителей и заказчиков перестроить свою работу для того, чтобы ускорить разработку. Если они готовы, всё достижимо.

Например, один из создателей Scrum Джефф Сазерленд в своей книге «Scrum: The Art of Doing Twice the Work in Half the Time» рассказывал, как он применил Scrum для разработки автоматизированной системы учёта данных ФБР. Когда он взялся за проект, разработка шла четвёртый год, ни одну функцию не довели до релиза и ни конца, ни края проекту не было видно. Джеффу удалось радикально ускорить разработку и сделать её прозрачной для заказчиков. Через полгода увидела свет первая рабочая версия продукта, а в течение двух лет разработка была успешно завершена.

Пара слов о книге Джеффа Сазерленда

Scrum: The Art of Doing Twice the Work in Half the Time. В русском переводе — «Scrum: революционный метод управления проектами». Впервые изданная в 2014 году, книга описывает предпосылки к созданию методологии, её базовые принципы, инструментарий и примеры внедрения. За 20 лет, прошедшие с тех пор, как автор книги Джефф Сазерленд и Кен Швайбер системно описали концепцию Scrum, они приложили немало усилий к тому, чтобы распространить методологию за пределы IT-отрасли и поставить её на службу нетехнологическим компаниям — финансовым, промышленным и так далее.

Миф 9. При внедрении гибких методологий неизбежны конфликты с представителями традиционной иерархии

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

А о том, кто такой Scrum-мастер, вы узнаете в следующей серии. Ждите во второй части рассказ Василия о внедрении гибких методологий разработки: сложности, выгоды, подводные камни и бомбы замедленного действия.

UPD. А вот и продолжение: Все дело в Agile — 2: особенности внедрения гибкой разработки

Нет времени объяснять, материал бескорыстно и с любовью подготовила команда Mail.Ru Cloud Solutions.

Что такое методология Agile, как внедрить Agile и почему это нужно сделать

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

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

Agile-подход и принципы Agile

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

Agile появился таким, как мы его знаем сегодня, только в 2001 году, когда группа программистов опубликовала Agile Manifesto. Озвученные ими принципы Agile впервые стали применяться для разработки программного обеспечения, но впоследствии инструменты Agile перекочевали и в другие отрасли.

Ценности Agile. Ключевые инсайты:

1. Люди и личностные отношения важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

Agile-манифест содержит ключевые инсайты создателей и 12 принципов Agile для разработки программного обеспечения. В манифесте нет однозначных инструкций, как организовать работу по методу Agile. Например, там нет никаких упоминаний о мотивации сотрудников. Однако основные положения Agile-манифеста стали ключевыми для этого семейства гибких методологий, позволяющих легко управлять различными проектами. Самые известные из них — это SCRUM и Kanban.

Фреймворк SCRUM. Отличие Agile от SCRUM

Часто люди затрудняются ответить, в чем же заключается отличие Agile от SCRUM. На самом деле все просто. SCRUM — это конкретный метод реализации Agile-подхода, фреймворк, который соответствует ценностям Agile и использует в работе метод Agile. Ключевую роль в SCRUM играет agile-команда: это команда «универсальных солдат», которые могут работать над разными проектами. Помимо специалистов в команде есть product manager, владелец продукта, и scrum master. Product manager следит за тем, чтобы проект отвечал потребностям заказчика и решал его задачи. Scrum master же координирует работу команды, в том числе отвечает за мотивацию команды, решает рутинные задачи.

Гибкий цикл разработки по фреймворку SCRUM делится на равные отрезки времени, которые принято называть «спринтами». Это может быть как неделя, так и месяц. Перед спринтом команда и scrum master определяют задачи, которые необходимо решить для реализации проекта, а в конце спринта — подводят итоги. С помощью спринтов scrum-мастеру легко контролировать эффективность команды, находить недочеты в работе и определять способы мотивации.

Kanban. Отличия Kanban от SCRUM

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

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

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

 

Task	Step 1	Step 2	Step 3	Step 4	Status
	Max 2	Max 3	Max 3	Max 2
K
L	I	F	C	A
M	J	G	D	B
N		H	E
O
P

Agile или Waterfall. Что выбрать?

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

Agile

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

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

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

Waterfall

+	—
Легко оценить итоговую стоимость проекта	Итоговая стоимость работ по проекту может увеличиться, но маловероятно, что она уменьшится
Привычная и понятная модель работы	Работу нельзя подстроить под непредвиденные обстоятельства. В крайнем случае — можно сэкономить время на стадии тестирования продукта, отказавшись от нее
Привычные формы отчетности по проекту	Невозможно тестировать продукт в ходе работы. Тестирование можно организовать, только когда проект фактически завершен
Задачи определены с момента запуска проекта	В продукт невозможно внести изменения в процессе разработки, даже если разработчик понимает, как продукт можно улучшить

Модель Waterfall стоит использовать в том случае, если основное ограничение для проекта — сроки реализации или если ваша команда недостаточно сработалась, чтобы участвовать в управлении сообща. Для гибкого цикла разработки продукта же участие команды в управлении проектом — это обязательное условие.

Применение Agile в управлении бизнесом и маркетинге

Методологии Agile — не свод правил и предписаний, а радикально иной способ взглянуть на организацию рабочего процесса. Agile Project Management может быть очень выгоден компании в первую очередь тем, что помогает быстро адаптироваться к изменениям на рынке, а также найти узкие места и устранить их. Что такое узкие места? Простыми словами — это рабочие задачи, которые решаются очень медленно и тормозят работу компании.

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

Возможное решение по Agile Project Management: организовать более жесткий контроль качества изделий до обжига и перевести на него часть рабочих, которые производят новые вазы. Это позволит улучшить качество изделий, которые в итоге попадают в печь, и снизить нагрузку на узкое место.

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

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

Новый манифест Agile-маркетинга. Философия подхода:

1. Точные исследования, а не мнения и предубеждения.
2. Кооперация, направленная на соблюдение интересов клиента, а не иерархия.
3. Итерация и адаптация, а не сложное планирование в рекламных кампаниях.
4. Исследование клиентов, а не статистическое прогнозирование.
5. Гибкое, а не жесткое планирование.
6. Адаптация к изменениям, а не четкое следование плану.
7. Множество небольших экспериментов, а не один большой.

Внедрение Agile

Многим компаниям тяжело дается внедрение Agile, потому что эта методология — особая культура работы, к которой сотрудникам и самой компании еще долго придется привыкать. Для того чтобы наладить эффективный гибкий цикл разработки продукта Agile, прежде всего нужна специально обученная agile-команда, которой руководитель может доверять. Есть несколько способов эффективно организовать обучение Agile для команды:

1. Agile-коуч. Выбрать подходящего agile-коуча для компании может оказаться непростой задачей. Во-первых, без знаний по Agile сложно оценить квалификацию коуча и качество его работы. Зачастую тот, кого нанимают как agile-коуча, начинает выполнять роль scrum-мастера. Без предварительного обучения команды такой способ может только навредить компании и внести смуту в рабочие процессы.
2. Тренинги Agile для руководителя. Сначала руководитель проходит обучение по Agile, а затем он обучает команду. Главный минус такого метода в том, что основная нагрузка по внедрению Agile ложится на плечи руководителя, при этом он продолжает решать свои повседневные задачи.
3. Курсы Agile. Обучение на курсах Agile дает возможность познакомить всю команду с культурой и методологией Agile. Главное — выбирать качественные курсы, которые славятся положительными отзывами других студентов. Например, с курсом Lectera «Эффективное управление бизнесом по методологии Agile» руководитель в кратчайшие сроки освоит принципы работы по Agile, а при покупке тарифа Lectera Corp — сразу сможет организовать обучение для своих сотрудников. Преимущество курсов от Lectera в том, что основной упор в них делается на практику: студенты могут отработать полученные знания с помощью прилагающихся кейсов и упражнений.

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

Книги, посвященные Agile, его технологии и философии:

1. Agile-манифест разработки программного обеспечения.
2. Элияху Голдратт, Джефф Кокс. «Цель: процесс непрерывного совершенствования».
3. Джефф Сазерленд. «SCRUM. Революционный метод управления проектами».
4. Хенрик Книберг. «SCRUM и XP: заметки с передовой».
5. Дэвид Андерсон. «Канбан. Альтернативный путь в Agile».
6. Эндрю Стеллман, Дженнифер Грин. «Постигая Agile. Ценности, принципы, методологии».

Главное в статье

1. Agile — семейство методологий. В методологиях Agile работа над проектом выстраивается так, чтобы гибко реагировать на изменения.
2. SCRUM — фреймворк Agile. В SCRUM работа над задачей разбивается на равные промежутки времени — спринты. Их анализ позволяет отслеживать эффективность работы.
3. Kanban — Agile-методология. Основной показатель эффективности для нее — скорость решения задач. Чтобы отслеживать прогресс, стадии работы над каждой задачей визуализируют на kanban-доске.
4. SCRUM и Waterfall — две самые популярные методологии для разработки программного обеспечения. SCRUM лучше подходит для зрелых команд.
5. Гибкие методологии идеально подходят для областей, в которых нужно быстро реагировать на изменения рынка, например для программирования и маркетинга.
6. Для эффективной работы по Agile необходимо качественно обучить команду. Удобнее всего это делать на Agile-курсах.

Хватит «переходить к agile»! | Atlassian

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

На самом деле принципы Agile увеличивают продуктивность команд и позволяют быстрее поставлять проекты. Однако это справедливо только в том случае, если все согласятся с правилами игры. Присоединяйтесь к обсуждению с участием Хизер Флеминг и Джастина Ризервато из компании Gilt — гиганта электронной коммерции — о том, почему в контексте принципов Agile важнее достигнуть консенсуса, а не внедрить процесс.

В частности, Хизер и Джастин анализируют ответы на три крайне важных вопроса, которые стоит рассмотреть любой команде, прежде чем начинать путь к Agile.

• «А когда будет выполнена работа?» Почему при внедрении принципов Agile важнее всего избавиться от концепции сроков сдачи.
• «Для меня крайне важно с вами встретиться, но я не смогу этого сделать до следующей недели». Что делать, если ваш бизнес-партнер не может (или не хочет) быть полноправным членом команды.
• «Я хочу просто писать код. Почему я должен присутствовать на всех этих собраниях?» Почему внедрение Scrum не является первым шагом на пути к Agile.

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

Вопрос 1. Цифровая или обычная Agile-доска? Что вы о них думаете?

Ответ 1. Это всецело зависит от конкретной команды. Все ли участники находятся в одном месте? Какой размер у команды? Достаточно ли у вас пространства, чтобы повесить большую традиционную доску? У нас в Gilt используют обе доски, но мы обнаружили, что когда в компании насчитывается несколько десятков команд, Agile-доски в Jira Software оказываются более практичным решением. Их удобнее настраивать, в них удобнее вносить изменения, а также ими удобнее делиться с удаленными участниками команды. Традиционные доски нравятся нам за то, что их сложно игнорировать, поскольку они находятся перед вами. А еще они отлично подходят для проведения спонтанных дискуссий о текущей работе или стендапов (если у вас так принято).

Вопрос 2. Как работать с менеджерами или клиентами, которые не следуют процессу согласно методике Agile или не понимают его принципов? Иногда мне кажется, что я совсем не умею объяснять суть рабочих процессов.

Ответ 2. Важно продумать порядок действий. Если вы пытаетесь работать по Agile-процессу с людьми, которые в него не верят, вы несколько забегаете вперед. В этой работе важнее сначала достигнуть общего согласия в философии, а не переходить к выполнению процесса. Ранее мы рассматривали конкретные проблемы, которые возникают у команды с текущим процессом, и применяли для их решения Agile-подход. Можете ли вы подробно рассказать своему менеджеру или клиенту о реальных проблемах и о том, как бы вы решали их с точки зрения Agile-методики? Получится ли у вас постепенно подвести их к методике Agile, не меняя весь процесс? Таким образом можно шаг за шагом показывать реальные результаты улучшения работы команды. Короче говоря, используйте Agile-подход в процессе внедрения Agile. 😉

Вопрос 3. Как внедрить Agile-процесс, если проект имеет фиксированную стоимость и (или) четкий график с установленным списком требований для реализации?

Ответ 3. Начнем с того, что успешно завершить проект с четким графиком и установленным списком требований для реализации невозможно. Можно ли заставить всех согласиться с тем, что это фантастика? Большая часть ограничений по срокам и требованиям не являются истинными ограничениями: это желания. Начните обсуждение с того, почему выполняется данная работа или какую проблему она должна решить. Если вы действительно понимаете цели проекта и причины ограничений, вы можете быть уверены, что команда сделает нужную работу вовремя. Запись всех требований и сроков выполнения не заставит все происходить вовремя как по волшебству.

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

Ответ 4. Нам кажется, что вы сами ответили на свой вопрос — нужно согласовывать объем работ. Если это невозможно, вы правы — пострадает качество. Наивно полагать, что можно втиснуть в объем работы все что угодно. Вам нужно убедиться, что команды выполняют реальные задачи, даже если это идет вразрез с ожиданиями других людей. Можете прочесть короткую запись, которую Хизер опубликовала на эту тему в блоге.

Вопрос 5. Как, на ваш взгляд, следует изменить способ реализации Scrum?

Ответ 5. Самая большая проблема Scrum заключается в жесткости этой методики. Было бы слишком самонадеянно считать, что один строго регламентированный процесс будет работать для всех команд независимо от сферы деятельности и задач. Scrum может работать для некоторых команд, но это не единственный подход к Agile. Многие команды не могут внедрить Agile-методику разработки, поскольку считают, что им нужно реализовать Scrum особым образом со всеми предписанными рабочими ролями, пользовательскими историями, критериями приемки, совещаниями и артефактами. А Хизер и вовсе не нравится название «Scrum-мастер». 😉

Вопрос 6. Как вы предотвращаете непосредственное влияние заинтересованных сторон на участников команды?

Ответ 6. Начнем с того, что хорошее заинтересованное лицо ЯВЛЯЕТСЯ участником команды. Поэтому в идеале необходимо привлечь его в свою команду, чтобы вы могли работать вместе! Если же заинтересованные лица относятся к тому типу людей, которые выполняют свою часть работы и уходят от участия в дальнейшем процессе либо вмешиваются во время работы над проектом и пытаются все изменить, важно, чтобы вся команда понимала, что она делает и с какой целью. В этом случае неважно, с кем будут говорить заинтересованные лица — они получат один и тот же ответ. Именно это делает вас командой, а не просто группой людей. Вам нужно общаться (много) и следить за тем, что все придерживаются единого мнения и движутся в одном направлении.

Вопрос 7. Вы оцениваете истории на основе приблизительной оценки (в часах) или с учетом баллов?

Ответ 7. Мы используем оба способа, а некоторые команды не проводят оценку вообще. Баллы хороши, поскольку они более абстрактны и не привязаны к календарному времени. Оценка в часах может быть полезна в качестве переходного варианта, если команда не переваривает баллы, поскольку часы проще «прочувствовать». Оценка нужна для того, чтобы оценить сложность спринта и иметь возможность ее отрегулировать; после запуска спринта оценки действительно становятся бесполезны. Мы обнаружили, что после работы с командой в течение некоторого времени процесс оценки становится ненужным. Мы все можем посмотреть на работу и с легкостью решить, подходит нам этот объем для спринта или нет.

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

Ответ 8. Они невероятно ценны 🙂 Организация встреч, ведение записей и т. д. не являются специальными навыками. Этим может заниматься любой. Эту работу также важно выполнять, однако так вы приносите сравнительно немного пользы команде. Если вы занимаетесь только административной работой, у команды может возникнуть резонный вопрос: почему вы являетесь ее частью? В компании Gilt каждый сотрудник отдела по управлению проектами обладает глубокими познаниями в соответствующей предметной области, а также знаниями о рабочих инструментах и техниках, и эти знания они несут в каждую команду, с которой работают. Многие из нас в прошлом были техническими специалистами либо работали с другими отделами Gilt и имеют уникальные экспертные знания в предметной области.

Вопрос 9. Какого размера обычно ваши команды и каким опытом обладают сотрудники компании Gilt?

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

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

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

Вопрос 11. Допустим, у вас есть команды, которые работают над несколькими «продуктами» одновременно. Будет ли работать такая схема: во время планирования спринта все менеджеры по продукту находятся в одной комнате и определяют относительные приоритеты по продуктам? Может быть, у вас есть другие идеи?

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

Вопрос 12. Я пытаюсь внедрить принципы Agile в команде, предоставляющей творческие услуги по маркетингу. Нам нужно предоставить результаты по некоторым задачам (разработка рекламы для печати в журнале) к определенной дате. Как нам вписать эти проекты в структуру Agile?

Ответ 12. Методике Agile по силам подобные ограничения. Команде нужно определить задачи и сроки, а также запланировать спринт с учетом этих факторов. Методика Agile поможет вам справиться вовремя, поскольку она позволяет корректировать приоритеты и планировать объем работы на каждый спринт. Если вы начнете отслеживать скорость команды, скоро сможете определять, получится ли у вас выполнить работу раньше срока. Тогда хороший лидер команды сможет договориться об условиях, необходимых для успешной работы команды.

Вопрос 13. Разве изменение целей не похоже на расширение области проекта?

Ответ 13. Вы правы, но мы не называем это «расширением области проекта», поскольку хотим поощрять изменения в ходе работы. Одно из самых больших преимуществ философии Agile заключается в том, что она позволяет адаптироваться к вещам, которые находятся вне зоны вашего влияния. Захотите ли вы использовать созданную несколько месяцев назад матрицу требований, если вдруг произойдут изменения в конкурентной среде, в потребностях бизнеса либо появятся новые технологии? Если вам нужно предоставить клиенту лучший продукт, примите изменения и используйте их в своих интересах. В Agile нет «расширения области проекта» (произносить голосом джедая).

Как выстроить систему управления в компании?

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

Система, в отличие от Waterfall, позволяет вносить изменения в проект даже на поздних стадиях. Идея Agile родилась ещё в 1980-х годах, а основные принципы были сформулированы в «Agile-манифесте» для разработчиков программного обеспечения в 2001 году.

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

В «Agile-манифесте» прописаны 12 принципов подхода к работе. Они основываются на следующих утверждениях:

• Люди и их взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее документации.
• Сотрудничество с заказчиком важнее согласования условий контракта. Он может давать обратную связь в ходе работы над продуктом.
• Готовность к изменениям важнее следования первоначальному плану.

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

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

В Scrum-подходе рабочий процесс делится на короткие циклы — спринты. Один спринт может длиться неделю или месяц, в зависимости от объёмов работы. Это позволяет сосредоточиться на постоянном улучшении продукта. Scrum, в отличие от других agile-методик, требует обязательной оценки эффективности каждого спринта. Каждый спринт строго фиксирован по времени, перед стартом ставятся задачи, которые нужно выполнить к окончанию цикла. Таким образом можно предсказать, успеет ли команда достичь цели спринта за установленное время и измерить производительность (velocity) команды по итогам.

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

• Scrum толерантен к изменениям в процессе работы, но при этом требует от участников постоянной вовлечённости в процесс.

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

• Scrum является гибкой методикой, но при этом позволяет строго контролировать сроки работы над проектом за счёт ограниченных во времени спринтов.

• Благодаря совместной работе над разными задачами сотрудники учатся друг у друга новым навыкам.

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

Kanban («табличка») — это подход, позволяющий выстроить сбалансированную работу всех членов команды. Впервые методику разработали и начали применять в компании Toyota. Kanban ещё называют «методом вытягивания» или конвейером. Его основная функция — равномерно распределить работу между разными специалистами и ранжировать задачи по приоритету, а не выполнять их все одновременно.

Kanban удобен для стартапов, у которых нет чёткого плана, но есть потребность в быстром результате. Для работы по этой методике, в отличие от Scrum, не требуется направляющий мастер — только владелец бизнеса, который после внедрения системы может уже не принимать участия в ежедневном контроле производства. При этом Kanban позволяет «ставить на конвейер» новые задачи в любой момент. Бизнес-процессы дробятся не на недели, а на дни и даже часы, потому что выполнение задач проекта отслеживается с помощью стадий: «список задач (backlog)», «в производстве», «тестируется», «выполнено», «заморожено» и т. д.

Главный критерий эффективности методики Kanban — скорость продвижения задачи между стадиями, то есть время, прошедшее со старта задачи до её завершения (cycle time). При этом если какая-то из задач — например, кусок кода — с большой вероятностью не войдёт в итоговый продукт, её допустимо заморозить, чтобы не тратить время работников. В рамках этой проектной системы управления нужно открыто контролировать выполнение задач — например, с помощью досок, где задачи сортируются по стадиям. Количество задач на одной стадии необходимо ограничить, иначе это также повлияет на скорость производства и не позволит быстро адаптироваться к изменениям.

• Kanban не ограничивает работников жёсткими дедлайнами, но, как и Scrum, требует от них мотивации.
• Kanban — самая гибкая из agile-методик, так как позволяет в любой момент менять приоритетные задачи.
• Нагрузка распределяется равномерно. Это позволяет компании экономить ресурсы и повышать вовлечённость специалистов.

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

• В Scrum объём работы меряется спринтами, включающими ряд задач. Каждый спринт должен длиться минимум неделю и не подразумевает сдвигов в процессе работы. Список задач и время, которое пойдёт на выполнение каждой, устанавливается строго перед стартом. Kanban — более гибкий подход: он позволяет внедрять новые задачи, отказываться от неэффективных и менять приоритеты в любой момент.

• Scrum требует оценки производительности команды в конце каждого спринта. Она зависит от количества выполненных задач. Главный критерий эффективности Kanban — скорость продвижения задачи по доске от старта до завершения.

• Kanban допускает большую самостоятельность команды: работники отмечают статусы задачи на доске, каждый может увидеть «провисы» и предложить свой вариант оптимизации. В Scrum за соблюдением дедлайнов и производительностью следит project manager или scrum-мастер.

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

Что такое Agile — философия и принципы

Среда, 1 января 2020 г. / Опубликовано в Без категории

Agile. Ловкость. Что на самом деле такое Agile? Каковы ценности, философия, образ мышления или гибкий образ мышления? Какие гибкие методы, инструменты и техники доступны? Каковы общие роли Agile? Это некоторые из тем, которые мы рассмотрим в серии статей, посвященных демистификации Agile.

Здесь мы рассмотрим философию Agile и двенадцать принципов Agile Manifesto.

Гибкая философия

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

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

Двенадцать принципов *

1. Нашим высшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.

Подсказка: все дело в клиенте и раннем предоставлении ценности.

2. Приветствуем меняющиеся требования даже на поздней стадии разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.

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

3. Поставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, с предпочтением более коротких сроков.

Совет: доставляйте чаще. Ранняя обратная связь неоценима, а доставка в короткие сроки сохраняет заинтересованность клиента.

4. Деловые люди и разработчики должны работать вместе на протяжении всей работы.

Совет: работайте с бизнесом — мы не против них. Речь идет о совместной работе.

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

Совет: мотивируйте и расширяйте возможности людей. Предоставьте людям автономию в организации и планировании своей работы. Дело не в микроменеджменте.

6. Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение.

Совет: по возможности общайтесь лицом к лицу. Успешное общение — это не только электронная почта!

7. Работающее программное обеспечение — это главный показатель прогресса.

Подсказка: то, что можно измерить, делается. Измеряйте рабочие решения и результаты.

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

Совет: поддерживайте устойчивый темп, иначе люди «выгорят». Баланс между работой и личной жизнью важен.

9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает гибкость.

Совет: держите дизайн чистым, эффективным и открытым для изменений.

10. Простота — искусство максимального увеличения объема незавершенной работы — очень важна.

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

11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.

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

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

Совет: регулярно размышляйте и корректируйте. Речь идет о непрерывном (и прикладном) обучении.

Для получения дополнительной информации о сертификации Agile Project Management (AgilePM®) или если вы хотите поговорить с одним из наших консультантов по профессиональному развитию, свяжитесь с нами сегодня по телефону 1300 70 13 14.

* Принципы Agile Manifesto. Доступ через http://agilemanifesto.org/ 14/12/2018.

Суть философии Agile

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

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

Что такое Agile: философия и принципы?

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

Эта философия была изобретена в 2001 году и известна как Agile Manifesto. Манифест представляет 4 основных ценности и 12 принципов, которые сегодня являются строительными блоками для гибкого подхода к управлению проектами (не только в индустрии разработки программного обеспечения).

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

В чем разница между Waterfall и Agile?

Модель водопада, также известная как модель последовательного жизненного цикла лайнера, вероятно, является одним из самых популярных методов управления проектами.Часто это называют традиционным подходом к управлению проектами. Как следует из названия, Waterfall — это линейный подход к разработке. Он основан на строгом планировании и поэтапном выполнении плана.

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

Почему?

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

Основные различия между Waterfall и Agile:

• Waterfall подходит для проектов с четко определенными требованиями, где почти не ожидается изменений (строительство 20-этажной гостиницы). Agile работает без сбоев, когда высока вероятность частого изменения требований (создание цифровых продуктов).
• В Agile требования к проекту могут меняться практически ежедневно.В Waterfall требования к проекту определяются только один раз БА (бизнес-аналитиком).
• Waterfall следует последовательному линейному подходу. Agile позволяет нам вносить изменения на любом этапе; таким образом, преимущества маневренности и гибкости, которые он предлагает.
• В описании гибкого проекта детали могут быть изменены в любое время, даже на поздних стадиях проекта, в то время как в Waterfall это невозможно, где план предопределен.

Почему Agile?

Мы можем много рассуждать о преимуществах Agile как философии достижения гибкости бизнеса.Однако за последнее десятилетие мы стали свидетелями масштабного сдвига во всех отраслях — от традиционного управления проектами к гибкому управлению проектами.

«Почему Agile» — это не объяснение из одного предложения. Agile необходимо хорошо понимать и приветствовать на всех уровнях вашей организации.

Наш ответ на вопрос «Почему Agile» состоит из 9 статей, написанных на основе того, что мы испытали при внедрении Agile в каждом отделе нашей компании.

Наслаждайтесь!

Философия Agile способствует адаптируемости внутри вашей компании

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

Вот что вы найдете в этой статье:

Что такое Agile?

Agile как философия была составлена ​​в 2001 году 17 авторами (Scrum Alliance) и основана на двенадцати принципах и четырех основных ценностях, изложенных в Agile Manifesto. Набор ценностей и принципов Agile был широко принят организациями и командами, которым нужно больше реагировать на потребности пользователей и изменения рынка. В целом, Agile-методологии легко принять малым и средним компаниям, занимающимся разработкой программного обеспечения.Agile — это все о быстром движении, гибкости, предвидении изменений, постоянном улучшении, прозрачности, доверии и открытости для всей команды.

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

Альтернатива гибкой разработке — разработка водопада

Такие тяжелые методологии, как Waterfall, Spiral, Iterative или V-Model, являются более традиционными, когда речь идет о подходах к разработке программного обеспечения.

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

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

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

Тем не менее, у модели Waterfall есть и неоспоримые преимущества. Один из них заключается в том, что разделение ваших поставок на несколько этапов упрощает для менеджера проекта контроль над процессом разработки.Многие опытные менеджеры проектов по-прежнему предпочитают модель «Водопад», поскольку она помогает им заранее составить четкий график.

Преимущества гибкой разработки программного обеспечения

Легкие по своей природе методологии Agile адаптируются и учитывают изменение требований на любой стадии проекта. Таким образом, технология может постоянно согласовываться с бизнес-целями. «Гибкая стратегия начинается с« достаточно хорошо ». Начнется всего через несколько недель, с меньшими затратами и усилиями, чем при использовании традиционных методов, и на основе подхода, ориентированного на возможности.Это позволяет организации быстро разработать начальную стратегию, а затем, реализуя ее, использовать собранные свидетельства и идеи для быстрого изменения стратегии по мере необходимости ». (Agile-стратегия, внедрение адаптируемости в ДНК вашей организации)

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

Недостатки гибкой разработки программного обеспечения

Теперь, когда мы рассмотрели преимущества Agile, давайте посмотрим на недостатки.

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

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

Agile Manifesto

Термин Agile впервые был использован в 2001 году, когда Agile Manifesto был опубликован 17 профессионалами в области технологий и бизнеса. Они встретились, чтобы обсудить процесс разработки программного обеспечения и искали альтернативы традиционной разработке программного обеспечения. Под названием Agile Alliance они разработали набор практик, известных как Agile Fundamentals.

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

Как заявили его авторы в Манифесте Agile Alliance, ниже перечислены ценности и принципы Agile:

Делая это, мы открываем лучшие способы разработки программного обеспечения и помогаем в этом другим. Благодаря этой работе мы получили значение:

• Отдельные лица и взаимодействие над процессами и инструментами
• Рабочее программное обеспечение поверх исчерпывающей документации
• Сотрудничество с клиентами в процессе переговоров по контракту
• Реагирование на изменение в соответствии с планом
  

Принципы Agile Manifesto следующие:

1. Нашим высшим приоритетом является удовлетворение потребностей клиента за счет своевременной и непрерывной поставки ценного программного обеспечения.
2. Приветствуем меняющиеся требования даже на поздних стадиях разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.
3. Поставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, с предпочтением более коротких сроков.
4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
5. Создавайте проекты вокруг мотивированных людей. Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.
6. Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение.
7. Работающее программное обеспечение — это главный показатель прогресса.
8. Agile-процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп бесконечно.
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
10. Простота — искусство максимизировать объем незавершенной работы — очень важен.
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
12. Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

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

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

Гибкие методологии

Термин Agile объединяет несколько облегченных методов разработки программного обеспечения, таких как Scrum, Extreme Programming (XP), Crystal, метод разработки динамических систем (DSDM), Feature Driven Development (FDD), Lean и Kanban.

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

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

Скрам

Следуя Agile Manifesto, наиболее часто используемой методологией Agile для разработки продуктов был Scrum.

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

Роли Scrum включают владельца продукта, мастера Scrum и команду Scrum.

Владелец продукта представляет клиента, и часто это кто-то из группы управления продуктом или ключевой участник. Скрам-мастер отвечает за то, чтобы команда Скрама располагала всеми необходимыми инструментами, чтобы работать максимально продуктивно. Обычная команда Scrum состоит из 5-9 участников с плоской иерархией (все участники считаются равными).

Scrum состоит из четырех церемоний:

• Планирование спринта — собрание в начале каждого спринта, на котором определяется содержимое бэклога спринта.
• Sprint Review — собрание, на котором все заинтересованные стороны могут увидеть, что было сделано в последнем спринте, и внести необходимые изменения.
Ретроспектива
• Sprint — возможность для владельца продукта и мастера Scrum оценить, насколько хорошо Scrum работает для них, и составить план для следующих шагов.
• Daily Scrum Meeting — проводится каждый день и обсуждает, что команда делала накануне и что она будет делать в течение текущего дня для достижения цели спринта, а также возможные препятствия.

Цикл итерации Scrum

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

Канбан

Термин «канбан» происходит от японского и означает «вывеска». Этот Agile-метод управления рабочим процессом не определяет никаких ролей или церемоний, как это делает Scrum, но он основан на трех основных принципах:

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

Канбан-доска

Наш взгляд на Agile и клиентский опыт

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

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

Agile-подход помогает нам преодолевать препятствия на пути к успешному CX.Философия Agile ориентирована на клиента и поддерживает постоянные корректировки на основе отзывов клиентов. Каким бы чистым ни был код, разрабатываемый продукт должен удовлетворять потребности клиента, чтобы сохранить свое конкурентное преимущество на рынке. Agile помогает нам уделять первоочередное внимание обратной связи с клиентами и внедрять улучшения, которые необходимы для дальнейшего повышения качества обслуживания клиентов.

Что говорят члены нашей команды?

Адина Балеа — Директор службы разработки программного обеспечения

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

Андреа Казаку — сертифицированный скрам-мастер и владелец продукта

«В Wirtek мы поставляем программное обеспечение с использованием методов Agile, уделяя особое внимание качественному рабочему программному обеспечению, которое удовлетворяет потребности наших клиентов.”

Кристиан Олариу — старший тестировщик программного обеспечения, сертифицированный мастер Scrum

«Клиенты ценят нас, потому что мы адаптировали наш гибкий стиль работы, чтобы быстрее реагировать на их меняющиеся потребности».

Выводы

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

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

---

Ресурсы

Ссылки ниже:

1. Курс Стивена Хаунца: «Основы гибкой разработки» | Pluralsight https: // app.pluralsight.com/library/courses/agile-fundamentals
2. курс: основы канбана, Стив Смит | Pluralsight https://app.pluralsight.com/library/courses/kanban-fundamentals

Что такое гибкое управление проектами?

Терминология Agile может сбивать с толку. Мы составили список наиболее распространенных терминов Agile, с которыми вы можете встретиться, и их определения:

• Agile — подход к управлению проектами, основанный на итеративном и поэтапном выполнении требований на протяжении всего жизненного цикла.
• Гибкая разработка — общий термин для итеративных методологий разработки программного обеспечения. Популярные методы включают Scrum, Lean, DSDM и экстремальное программирование (XP).
• Agile Manifesto — описывает четыре принципа гибкой разработки: 1. Индивидуумы и взаимодействия важнее процессов и инструментов. 2. Рабочее программное обеспечение над исчерпывающей документацией. 3. Сотрудничество с клиентом вместо переговоров по контракту. 4. Реагирование на изменение следования плану.
• Бэклог — приоритетные работы, которые еще не завершены (см. Требования).
• График выгорания — используется для отслеживания прогресса; показывает незавершенную работу (Бэклог) в сравнении с общим временем.
• Cadence — количество дней или недель в Спринте или релизе; продолжительность цикла разработки команды.
• Церемонии — встречи, часто ежедневные собрания по планированию, на которых выявляются, что было сделано, что должно быть сделано, и препятствия на пути к успеху.
• DAD ( дисциплинированная гибкая доставка ) — структура процесса принятия решений.
• Daily Scrum — встреча команды stand-up. Планируйте, делайте, повторяйте ежедневную сессию.
• DevOps (разработка / эксплуатация) — устраняет разрыв между гибкими командами и оперативной доставкой в ​​производство.
• DSDM (метод разработки динамических систем) — методология гибкой разработки, теперь измененная на «структуру управления проектами DSDM».
• Канбан — метод управления работой с упором на своевременную доставку.
• Канбан-доска — инструмент визуализации рабочего процесса и рабочего процесса, который обобщает статус, прогресс и проблемы, связанные с работой.
• Бережливое производство — метод работы, направленный на «устранение потерь» путем избегания всего, что не создает ценности для потребителя.
• LeSS (масштабный Scrum) — метод гибкой разработки.
• RAD (quick application development) — метод быстрой разработки; позволяет разработчикам быстро создавать решения, напрямую разговаривая с конечными пользователями, для удовлетворения бизнес-требований.
• Требования — записываются в виде «историй», которые сгруппированы в приоритетный список, называемый «Бэклог».
• SAFe (масштабируемая гибкая структура предприятия) — гибкая методология, используемая для разработки программного обеспечения.
• Scaled Agile — Agile масштабируется до крупных проектов или программ, например, за счет наличия нескольких подпроектов, создания траншей проектов и т. Д.
• Scrum — гибкая методология, обычно используемая при разработке программного обеспечения, когда регулярные встречи команды рассматривают прогресс на одном этапе разработки (или спринте).
• Scrum of scrums — метод масштабного управления Scrum для нескольких команд, работающих над одним и тем же продуктом.
• Скрам-мастер — человек, который наблюдает за процессом разработки и следит за тем, чтобы все придерживались согласованного метода работы.
• Sprints — короткий этап разработки в рамках более крупного проекта, определяемый доступным временем («временными рамками») и ресурсами.
• Ретроспектива спринта — обзор спринта, содержащий извлеченные уроки с целью содействия постоянному совершенствованию.
• Рассказы — см. Требования.
• Timeboxes — см. Спринты.
• Скорость — мера работы, выполненной в течение одной фазы разработки или спринта.
• Waterfall — последовательный подход к управлению проектами, направленный на предварительное определение подробных требований; противоположность Agile.
• XP (eXtreme Programming) — методология гибкой разработки, используемая при разработке программного обеспечения; позволяет программистам определять объем поставок.

Что такое Agile Manifesto?

Agile Manifesto — это документ, в котором определены четыре ключевых ценности и 12 принципов, которые, по мнению его авторов, следует использовать разработчикам программного обеспечения в своей работе. Официально называемый «Манифест для гибкой разработки программного обеспечения », он был подготовлен 17 разработчиками во время прогулки 11-13 февраля 2001 года в The Lodge на горнолыжном курорте Snowbird в Юте.

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

Согласно agilemanisfesto.org, онлайн-источнику документа, заявленная цель разработчиков заключалась не в противодействии методологии, а, скорее, в «восстановлении доверия к словесной методологии».

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

Разработка манифеста Agile

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

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

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

Четыре ценности Agile

Четыре основных ценности гибкой разработки программного обеспечения, заявленные в Agile Manifesto:

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

12 принципов

12 принципов, сформулированных в Agile Manifesto:

1. Удовлетворение потребностей клиентов за счет своевременного и непрерывного выполнения ценной работы.
2. Разделение большой работы на более мелкие задачи, которые можно выполнить быстро.
3. Признавая, что лучшая работа возникает из самоорганизованных команд.
4. Обеспечение мотивированных людей окружающей средой и необходимой им поддержкой, а также доверие им в выполнении работы.
5. Создание процессов, способствующих устойчивым усилиям.
6. Поддержание постоянного темпа выполненных работ.
7. Приветствовать меняющиеся требования даже на поздних стадиях проекта.
8. Ежедневное формирование команды проекта и владельцев бизнеса на протяжении всего проекта.
9. Заставить команду регулярно размышлять о том, как стать более эффективными, а затем соответствующим образом настраивать и корректировать поведение.
10. Измерение прогресса по количеству выполненных работ.
11. Постоянное стремление к совершенству.
12. Использование изменений для получения конкурентного преимущества.

Цель Agile Manifesto

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

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

Agile vs. scrum и другие методологии

Agile, как указано в Agile Manifesto, считается философией, но есть и другие конкретные методологии и структуры, которые формализуют многие или все идеи, представленные в Agile Manifesto.

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

Другие фреймворки и методологии включают Канбан, Кристалл, Бережливое и Экстремальное программирование (XP), все из которых содержат элементы, основанные на философии Agile.

Критика и споры

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

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

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

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

Каковы 4 ценности Agile?

Agile Manifesto состоит из четырех ключевых значений:

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

Давайте подробно рассмотрим каждый из них:

Узнайте больше об Agile Manifesto.

Значение 1: отдельные лица и взаимодействия

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

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

Значение 2: Рабочее ПО

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

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

Значение 3: Сотрудничество с клиентами

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

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

Значение 4: реакция на изменение

Можете ли вы представить себе время, когда вы составили бы дорожную карту, и она никогда не изменилась бы? Что ж, в прошлом именно так и было.

Проблема со статическими дорожными картами в том, что мы не живем в статичном мире. Потребности и требования всегда меняются, а приоритеты всегда меняются.Эта статическая дорожная карта скоро устареет.

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

Agile Manifesto также состоит из 12 принципов. О них читайте здесь.

.. .

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

Что такое Agile? Что такое скрам?

Agile — это образ мышления и философия, которые описывают набор принципов в Agile Manifesto. С другой стороны, Scrum — это структура, которая предписывает роли, события, артефакты и правила / рекомендации для реализации этого образа мышления.Другими словами, Agile — это образ мышления, а Scrum — это структура, которая предписывает процесс реализации гибкой философии.

Зонтик Agile

Agile — это общий термин для набора методов и практик, основанных на ценностях и принципах, выраженных в Agile Manifesto, который представляет собой образ мышления, который позволяет командам и компаниям внедрять инновации, быстро реагировать на меняющийся спрос, одновременно снижая риски. Организации могут быть гибкими, используя многие доступные фреймворки, такие как Scrum, Kanban, Lean, Extreme Programming (XP) и т. Д.

Scrum Umbrella

Что такое Agile?

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

Что такое Scrum?

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

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

Как работает Scrum?

Процесс Scrum отличается от других гибких процессов особыми концепциями и практиками, разделенными на три категории ролей (владелец продукта, мастер схватки, команда разработчиков и другие заинтересованные стороны), события, артефакты и правила.

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

Фреймворк Agile Scrum

Обратите внимание, что:

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

О Visual Paradigm

Visual Paradigm помогает организациям оставаться конкурентоспособными и быстро реагировать на изменения в быстро меняющейся среде. Нашим отмеченным наградами продуктам доверяют более 320 000 пользователей в самых разных компаниях: от малых предприятий и консультантов до голубых фишек, университетов и государственных структур по всему миру. Это позволяет организациям повысить гибкость бизнеса и ИТ и стимулировать инновации с помощью популярных открытых стандартов и структур процессов.Visual Paradigm, потрясающая функция Agile в 2018 году, представила Scrum Process Canvas для автоматизации процесса создания, управления и развертывания программного обеспечения командой Scrum, что дает возможность команде постоянно улучшать свою производительность с беспрецедентной скоростью и масштабом. Управляйте всем процессом Scrum в одной странице Автоматизируйте Scrum Framework на веселой и приятной панели инструментов с привлекательным обновленным статусом. Управление бэклогом, множественные спринты различных ролей Scrum с помощью одностраничного визуально исполняемого холста Разрешить мгновенный доступ, просмотр и создание артефактов схватки и связанных документов для архивации в общем кабинете Автоматизируйте события Scrum и связанные с ними действия с помощью понятных инструкций, образцов и необходимых шаблонов документов. No related posts. alexxlab Автор записи Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт