Технология аджайл: Что такое Agile и подойдет ли он вашей компании — Независимое театральное объединение "Зрительские симпатии"

Содержание

Что такое Agile и подойдет ли он вашей компании

Agile-манифест базируется на четырех главных ценностях:

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

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

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

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

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

3. Сотрудничество с заказчиком важнее соблюдения формальных условий.

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

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

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

Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:

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

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

Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.

Как объяснить бабушке, что такое Agile за 15 минут с картинками / Хабр

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера. »

— закон Хофштадтера

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Роли

Это Пэт,

владелец продукта

. Она не знает технических деталей, зато обладает видением общей картинки, знает,

зачем

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

Это

заинтересованные лица

. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.

Это

пользовательские истории

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

У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.

Это

команда разработчиков

. Те, кто будет

строить

рабочую систему.

Пропускная способность

Так как команда использует

гибкую методологию разработки

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

пропускная способность

. Ее очень просто измерить — количество пользовательских историй за 7 дней.

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

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

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

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

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

Допустим, команда возьмется сделать 10 новых историй за эту неделю.

Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

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

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

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

Есть только один способ держать список задач под контролем — это слово “нет”

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

Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.

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

Принятие решений

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

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

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

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

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

Владелец ИТ-продукта должен постоянно со всеми общаться

Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.

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

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

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

Знание можно рассматривать как противоположность риску.

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

В идеале — все три одновременно, но в реальности приходится выбирать.

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

или

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

или

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

Между ролями в Scrum существует здоровое противостояние

Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.

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

Компромисс между разработкой нового продукта и улучшением старого

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

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.

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

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.

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

Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

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

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

Несколько команд

Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.

Исходник — Agile Product Ownership in a nutshell

видео на английскомвидео на русском

Scrum — что это такое, как это работает и в чем преимущества

Платформа

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

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

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

Артефакты Scrum

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

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

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

Собрания или мероприятия Scrum

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

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

Организация бэклога. За это мероприятие, также известное как ведение бэклога, несет ответственность владелец продукта. В число его основных обязанностей входят приведение продукта в соответствие с его концепцией и постоянное отслеживание настроений на рынке и потребностей клиента. Для этого владелец продукта и ведет список, изменяя в нем приоритеты и поддерживая его в актуальном виде на основании информации от пользователей и команды разработчиков, чтобы в любое время можно было приступить к работе над внесенными в него задачами. Подробнее о том, как правильно вести бэклог, можно прочитать здесь.
Планирование спринта. На этом собрании команда разработчиков под руководством Scrum-мастера планирует работу (объем спринта), которую необходимо выполнить в течение текущего спринта. На нем выбирается цель спринта. Затем в спринт добавляются конкретные пользовательские истории из бэклога продукта. Эти истории всегда соотносятся с целью. При этом команда Scrum согласовывает такие истории, которые можно будет реализовать на практике в ходе спринта.
В конце собрания по планированию каждый член команды Scrum должен четко представлять, какие задачи можно выполнить за спринт и как поставить инкремент.
Спринт. Спринт — это фактический промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторым командам проще спланировать объем спринта на одну неделю или поставить инкремент, обладающий достаточной ценностью, за месяц. Дейв Уэст из Scrum.org рекомендует планировать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой. Не стесняйтесь менять продолжительность спринта, если покажется, что она вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут пересмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сути Scrum.
Все мероприятия, от планирования до ретроспективы, проводятся в течение спринта. После того как временной промежуток для спринта определен, он должен оставаться неизменным, пока ведется разработка. Так команда будет извлекать ценные уроки из прошлого опыта и применять выводы к будущим спринтам.
Ежедневное Scrum-совещание, или стендап. Это очень короткое ежедневное собрание, которое для удобства проводится в одно и то же время (обычно утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, однако это лишь рекомендация. Такое собрание также называется «ежедневным стендапом», что подчеркивает его краткость. Ежедневное Scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от цели и получал план работы на ближайшие 24 часа.
Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.
Чаще всего в рамках стендапа каждому участнику команды предлагается ответить на следующие три вопроса, связанные с достижением цели спринта:
• «Что мне удалось сделать вчера?»
• «Что я планирую сделать сегодня?»
• «Может ли мне что-то помешать?»
Впрочем, такое собрание может превратиться в зачитывание людьми записей из ежедневника. Стендап нужен, чтобы вся болтовня оставалась в рамках ежедневного собрания, а в остальное время команда могла сосредоточиться на работе. Поэтому если кто-то начинает просто зачитывать свой ежедневник, не стесняйтесь внести изменения в собрание; проявите смекалку.
Обзор итогов спринта. В конце спринта команда собирается для просмотра демонстрации инкремента (или для его изучения) в неформальной обстановке. Команда разработчиков представляет заинтересованным сторонам и коллегам завершенные рабочие задачи из бэклога, чтобы собрать отзывы. Владелец продукта решает, стоит ли выпускать инкремент, хотя в большинстве случаев команда получает зеленый свет.
На собрании по обзору итогов владелец продукта также изменяет бэклог продукта на основании результатов последнего завершенного спринта. Этот процесс может перейти в планирование следующего спринта. Если спринт длится один месяц, отводите под собрание для обзора итогов не более четырех часов.
Ретроспектива спринта. Ретроспектива проводится, чтобы команда зафиксировала и обсудила все успехи и неудачи спринта, проекта, участников и их взаимоотношений, инструментов или даже определенных собраний. Цель ретроспективы — создать условия, чтобы команда могла уделить внимание всему, что удалось и что нужно улучшить в следующий раз, и не зацикливалась на неудачах.

Три важнейшие роли, от которых зависит успех применения Scrum

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

Владелец продукта Scrum

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

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

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

Scrum-мастер

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

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

Команда разработчиков Scrum

На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос (в команде должно быть столько участников, чтобы им хватало двух пицц).

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

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методика, что слова Scrum и Agile многие ошибочно используют как синонимы. Но есть и другие популярные методики, например Kanban. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

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

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

За что мы любим Scrum?

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

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

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

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

Чтобы изучить Scrum с помощью Jira Software, прочитайте это руководство.

AGILE – гибкая система управления проектами

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

В 1991 году появился метод быстрой разработки приложений RAD
В 1994 году появился метод разработки динамических систем DSDM
В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

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

Идеи Agile:

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

Принципы Agile:

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

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

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

Ключевые моменты в применении Agile

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

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

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

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

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

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

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

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

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

Что я делал вчера?
Чем я буду занят сегодня?
Что мешает мне работать?

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

Четко обозначается значение проекта
В процессе реализации активно участвует клиент
Общий объем работ выполняется пошагово
Ориентироваться следует на конкретный результат
Численность одной рабочей группы: от 7 до 9 человек

В настоящее время проект-менеджмент с поддержкой Аджайл по большей части распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на вооружение множеством компаний и государственных структур.

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Подать заявку на DIRECTOR — EMEA AGILE/LEAN

Станьте частью команды NIKE, Inc. —

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

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

NIKE is a technology company. From our flagship website and five-star mobile apps to developing products, managing big data and providing leading edge engineering and systems support, our teams at NIKE Global Technology exist to revolutionize the future at the confluence of tech and sport. We invest and develop advances in technology and employ the most creative people in the world, and then give them the support to constantly innovate, iterate and serve consumers more directly and personally. Our teams are innovative, diverse, multidisciplinary and collaborative, taking technology into the future and bringing the world with it.

WHO WE ARE LOOKING FOR

The Digital Transformation Program Office team is seeking a Director of Lean/Agile, responsible for defining and enabling the enterprise in operational and cultural components that supercharge our agile transformation. You will be highly proficient in various methods and practices around provisioning capabilities into the business, as well as improving the overall agile maturity across the organization. You should have experience in defining and building agile strategies for large scale organization and implemented the strategies within all levels of the organization successfully.

You are a natural servant leader, passionate and relentless in developing and supporting a learning organization through mentorship and coaching, encouraging training and continuous improvement throughout. You embody and enable the agile cultures and has proven track record in transforming large scale delivery from traditional methodologies to agile and beyond.

WHAT YOU WILL WORK ON

The Director of Lean/Agile will be leading a team to develop and lead agile practices, putting in place the systems, processes and ways of working to sustain high performing teams, where skill development, increased agility, collaboration and improved ways of working are key to success.

Key Accountabilities

Bring vision and inspiration towards individual and teams
Build and maintain agile-at-scale competency and talent strategy at the enterprise level with direct oversight of methodology guidelines and the Agile Coaching Team.
Evolve and continually improve the interdependencies between business models and operating practices, integratingwaterfall, iterative, and agile delivery models into one, cohesive delivery strategy to best meet the evolving business needs.
Instill a learning culture to continuously inspect and adapt methodology and efficiency.
Provide support to ensure the cultural behaviors and mindsets support the organization values
Lead agile coach managers on agile thought leadership for the organization and the wider delivery community on how best to apply these principles to project and program delivery.
Cultivate a culture of inclusion and promote a growth mentality among teams and collaborators
Act as a mentor, thought partner, and Agile evangelist across the organization.
Set the tone of operations by encouraging a culture of trust and collaboration

WHO YOU WILL WORK WITH

This role reports directly into the Senior Director, EMEA Digital Transformation Program Office within the Technology organization. You will lead a team of Agile Coach Managers, RTE and Scrum Masters to affect positive and sustainable change. In this capacity, you will collaborate with EMEA and global agile leadership team to define best practices, influence organizational health, and drive multiple enterprise and lean/agile initiatives each year. You will have strong presence in both Nike European Headquarters in the Netherlands and European Logistic Center in Belgium.

WHAT YOU BRING

Proven track record with practical certification such as CAL2, SPC, KCP, AKT, TKP, KANBAN-EXP, etc
Certified coaching experience (ICF-CPP) a plus
Demonstrated ability that reflects a bias towards action and delivering outsized results
Outstanding collaboration, listening, written and verbal communication skills
Disposition towards building relationships and using partnerships to navigate sophisticated organizational challenges
Demonstrated ability to market your ideas and persuasively move others to action
Leadership and influencing expertise with senior stakeholders across functions to align strategy, and implement change.
Inquisitive, aware, and maintains knowledge of current industry trends and innovations
A strong facilitator with experience in engaging teams in a collaborative, distributed environment.

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

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

Picosun AGILE ALD – решения АСО для фотоники

ЭСПОО, Финляндия, 29 апреля 2020 г. – Picosun Group, ведущий поставщик решений в мировой промышленности для тонкопленочных покрытий AGILE ALD (Atomic Layer Deposition, АСО, атомно-слоевое осаждение), сообщает о нескольких значимых проектах, реализованных с помощью решений для тонкопленочных покрытий Picosun AGILE ALD® в области фотоники.

ALD технология Picosun успешно применена в фотонике

Как и все другие глобальные экспортные компании, Picosun также пострадала от пандемии COVID-19. Тем не менее, технология АСО по-прежнему набирает обороты, поскольку новые отрасли промышленности непрерывно развиваются. Фотоника является одним из примеров тех областей, где решения в технологии АСО Picosun позволяют использовать множество новых оригинальных применений.

«Глобальная команда Picosun теперь концентрирует все усилия на предоставлении нашим клиентам передовых решений и услуг АСО. В эти сложные времена многие отрасли испытывают трудности. Сейчас особенно подчеркивается важность перспективных технологий, таких как АСО. Происходит глобальный цифровой скачок, и все компании вкладывают средства в удаленную работу, видеоконференцсвязь и другие цифровые технологии. Это требует быстрых сетевых подключений и передачи больших объемов данных в реальном времени. Photonics может предложить решение нового поколения для этих проблем», — говорит г-н Юсси Раути, генеральный директор Picosun Group.

Фотоника – ключевой рынок для решений Picosun AGILE ALD

Фотоника быстро стала ключевым рынком для технологических решений АСО от Picosun. Было реализовано несколько крупных промышленных продаж, как новым, так и постоянным клиентам, где конечные приложения связаны с производством оптоэлектроники, дисплеев, процессоров обработки сигналов, датчиков, оптических приборов и устройств виртуальной или дополненной реальности.

«Фотоника — это широкий спектр, охватывающий несколько ключевых технологий сегодняшнего дня, от оптической передачи данных и оптических интегральных схем до медицинских приложений и даже квантовых вычислений. Мы в Picosun рады предоставить наши решения АСО ведущим компаниям в этой области, чтобы их бизнес продолжал развиваться. Новые передовые средства связи и обмена данными помогут нашему глобальному сообществу не только во времена кризиса, но и в будущем, поскольку происходящая сейчас смена парадигмы в способах работы окажет далеко идущее и глубокое влияние на нашу жизнь», — продолжает Раути.

R-200 — установка ALD (АСО) Picosun

R-200 – одно из решений Picosun для АСО, имеет 2 модификации (с ручной и полуавтоматической загрузкой). Разработана специально для проведения НИОКР, в том числе и в различных областях фотоники. Инновационный модульный дизайн позволяет получать пленки высочайшего качества и гарантировать широкие возможности изменения конфигурации системы для будущих приложений. Также возможна интеграция с перчаточными боксами, камерами для работы с порошками, аналитическим оборудованием для in situ анализа.

Подробнее об установке ALD R-200 Picosun Standard >>>

Подробнее об установке ALD R-200 Picosun Advanced >>>

О компании Picosun

Picosun предлагает самые передовые решения для тонкопленочных покрытий AGILE ALD® (атомно-слоевое осаждение) для мировой промышленности. Решения Picosun для АСО позволяют совершить технологический скачок в будущее с производственными процессами «под ключ» и непревзойденным новаторским опытом в этой области, начиная с изобретения самой технологии. Сегодня оборудование PICOSUN® ALD ежедневно используется во многих ведущих отраслях промышленности по всему миру. Picosun находится в Финляндии, имеет дочерние компании в Германии, Северной Америке, Сингапуре, Тайване, Китае, Корее и Японии, офисы в Индии и Франции, а также всемирную сеть продаж и поддержки.

Каталог продукции компании Picosun >>>

Заинтересовало оборудование для атомно-слоевого осаждения? Обращайтесь к нашим специалистам! Мы подберем оборудование под Ваши цели и задачи и сориентируем Вас по ценам на продукцию. Присылайте Ваши вопросы и заявки на эл.почту [email protected], тел. +7 495 204 13 17.

Что Такое Методология Agile и Каким Проектам Она Подходит

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

Методология Аджайл (Agile methodology) — один из самых популярных способов достижения этой цели. Согласно исследованию State of Agile (2020), 95% респондентов заявили, что их компании частично либо полностью используют Agile методологии ведения проектов.

Также участники опроса рассказали, в каких департаментах их организаций используют Agile методологии. Среди них:

Разработка программного обеспечения (37%).
IT (26%).
Управление операциями(12%).
Маркетинг (7%).
Отдел кадров или HR (6%).
Отдел продаж (5%).

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

Что такое методология Agile?

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

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

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

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

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

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

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

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

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

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

Преимущества Agile:

Быстрое обнаружение и исправление ошибок.
Прозрачность рабочего процесса.
Частые и ожидаемые релизы.
Предсказуемая стоимость проекта.
Оперативное принятие решений.
Нацеленность на пользователей.
Конечный продукт является лучшей своей версией.
Высокий уровень удовлетворенности заказчиков.

Agile манифест

Публикация Agile манифеста в 2001 году знаменовала рождение Agile как методологии.

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

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

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

За последние 20 лет с момента создания манифест приняли многие команды и организации из разных профессиональных сфер. Сегодня документ доступен более чем на 50 языках, включает в себя 4 ценности и 12 принципов.

4 ценности Agile манифеста:

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

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

12 принципов Agile манифеста о разработке программного обеспечения:

Главный приоритет — удовлетворение потребностей клиента. Достигается это за счет постоянной и систематической поставки ценного ПО.
Изменения требований одобряются, независимо от того, на какой стадии разработки находится продукт.
Частые релизы усовершенствованного продукта приветствуются.
Разработчики и представители бизнеса должны работать сообща ежедневно на протяжении всего проекта.
Личное общение с командами и внутри них является наилучшим способом передачи информации.
Мотивация сотрудников должна быть в приоритете. Чтобы работа была выполнена качественно, создайте атмосферу уважения, доверия и расширения возможностей.
Работающее ПО — главный показатель прогресса.
Важно, чтобы инвесторы, команда разработчиков и пользователи поддерживали постоянный рабочий ритм. Именно Agile помогает наладить цикличный и устойчивый процесс разработки.
Непрерывное внимание к совершенству проектирования и качеству разработки повышает гибкость проекта.
Простота — необходимая часть эффективной работы с Agile.
Самоорганизованные команды создают наилучшие требования, технические и архитектурные решения.
Чтобы быть более эффективными, команды должны систематически анализировать собственную работу и постоянно корректировать ее.

Популярные Agile методологии

Существует множество различных методологий (или фреймворков) гибкой разработки, которые держат за основу ценности и принципы Agile манифеста. Канбан (Kanban), Скрам (Scrum), Бережливое производство (Lean) и Экстремальное программирование (XP) — часто используемые из них.

Kanban

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

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

Scrum

Скрам — это методология управления проектами, в которой командой руководит Скрам-мастер. Его главная задача состоит в устранении преград на пути к завершению проекта.

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

Экстремальное программирование (XP)

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

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

Бережливое производство (Lean)

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

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

Другие гибкие методологии разработки ПО

В управлении проектами существует ряд других методологий управления проектами кроме тех, что мы перечислили выше:

Разработка, управляемая функциональностью (FDD).
Crystal Clear.
Метод разработки динамических систем (DSDM).
Разработка через тестирование (TDD).
Адаптивные рамки проекта (APF),
и другие.

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

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

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

Например, разработчики программного обеспечения чаще предпочитают Scrum и XP, в то время как Канбан — любимец команд, ориентированных на сервис (IT, маркетинг или отдел кадров).

Кому подойдет методология Agile?

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

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

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

Если грядущий проект технологически сложный и комплексный.

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

Если проект продолжительный по времени.

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

Если в реализации проекта много неопределенных моментов.

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

Если количество идей по проекту превышает возможности команды.

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

Если клиент хочет участвовать в каждом этапе реализации проекта.

Идеальное условие для внедрения Agile методологий — это заинтересованность заказчика в плотном сотрудничестве с командой.

Инструменты для работы с Agile-проектами
Вовлеченность в проект нескольких команд делает рабочий процесс менее прозрачным. Кроме того, менеджеру, руководителю и заказчику становится все сложнее следить за прогрессом проекта, контролировать его реализацию и вносить изменения.
Облегчить работу с комплексными проектами и настроить взаимодействие между участниками команды помогут инструменты управления Agile-проектами. С ними вы всегда можете видеть общую картину проекта, контролировать загрузку работников, общаться с командой и держать заказчика в курсе изменений и корректировок.
Онлайн-диаграмма Ганта с легкостью выполнит все эти задачи и упростит работу с проектом всем его участникам.
Онлайн диаграмма Ганта GanttPRO
Ведите проекты, управляйте временем, ресурсами и финансами.
Попробуйте бесплатно
Какую гибкую методологию управления проектами предпочитаете вы?
Agile — незаменимый подход к управлению проектами, который держит команду в тонусе и постоянно помогает добиваться лучших результатов. Благодаря тесному сотрудничеству команды и заказчика, а также вовлеченности и обратной связи потребителей продукта, результат приносит еще большее удовлетворение каждому участнику проекта.
А какие Agile методологии управления проектами предпочитает ваша команда? Делитесь в комментариях ниже.
5 3 голоса
Рейтинг статьи
Agile Technologies

Agile Technologies, Inc. Agile Technologies — компания, предлагающая электронные решения. комплексные услуги по проектированию, производству и управлению продуктами электроники для глобальные компании, занимающиеся электроникой и технологиями. Мы помогаем нашим клиентам приносить продукты электроники на рынок быстрее и более рентабельны, предоставляя полное управление цепочкой поставок электронных продуктов и комплексное, индивидуализированные, сфокусированные решения в широком спектре отраслей и Приложения.
Если вы хотите расширить продуктовую линейку, запустите прототип программы или интеграции производственной стратегии совместной разработки, мы повышаем качество вашей продукции при снижении затрат.
Конкурентное преимущество заключается в сборке правильного набора деловые отношения для сохранения и увеличения доли рынка. Гибкие технологии нацелена на построение прочных партнерских отношений и предоставление гибких решений для способствовать успеху наших клиентов. Мы адаптивны и гибки и помогаем нашим клиентам удерживать лидирующие позиции за счет объединения производства и логистики функции для сокращения избыточных процессов по всей цепочке поставок.Это позволяет проектирование, сборка и распространение продуктов, которые должны быть завершены и доставлены в рынок с меньшим количеством контактов и меньшими затратами.
Вы можете рассчитывать на партнерство с Agile Technologies. Наш качество, технологии, сервис и опыт — в вашем распоряжении. Были готовы и готовы быть быстрыми и отзывчивыми.
И мы всегда ставим клиента на первое место. Мы помочь вам стать более успешным, предоставляя компетентность, преданность делу, готовность и боевой дух.Предлагаем конструкторские, производственные и логистические решения. это повлияет на вашу прибыль!
Дизайн и проектирование
Мы предлагаем нашим клиентам дизайнерские и инженерные решения и продолжаем найти способы помочь вам стать более успешными.
Какие факторы влияют на успех вашего продукта на рынке? Как выйти на рынок быстрее, с меньшими затратами и с более высоким качеством стандарты? Возможность ответить на эти вопросы помогает установить технологию компании отдельно и дает им значительное конкурентное преимущество.
С более чем 80% цен на продукцию и цепочки поставок производительность, определяемая на этапе проектирования и проектирования, с доступом к Необходим правильный партнер EMS, который может доставить все по всем направлениям. Гибкий Качество технологий и технологическое лидерство, а также репутация в торговая площадка поможет вам конкурировать и добиться успеха.
Мы являемся продолжением вашей команды по разработке продуктов. . .
Печатная плата и окончательная сборка системы
Все это объединено в Agile Technologies.Мы обеспечиваем сборку печатных плат и полную интеграцию электронных продуктов. Мы быстро закупать компоненты, собирать продукты, проводить комплексные испытания и отправлять ваш конечный покупатель. Мы предлагаем комплексное решение для продукта, синхронизированное с обеспечение качества и процессы тестирования для обеспечения производства на высшем уровне на всех сборках.
Мы заслуживаем ваше доверие, управляя цепочкой поставок, собирая вашу продукцию и ставлю вас на первое место.
Логистика
В Agile Technologies мы тесно сотрудничаем процессы производства, логистики и управления цепочками поставок, позволяющие проектирование, сборка и распространение вашей продукции будет завершено подробнее быстро, по более низкой цене и с высокими стандартами качества.
Почему логистика и управление цепочками поставок усложняют ваш бизнес?
По мере того, как вы готовите свой бизнес к немедленному и будущему росту, обращайте внимание на Agile Technologies в качестве вашего предпочтительного партнера.
Качество
Наше качество и ориентация на клиента очевидны в все, что мы проектируем, производим, тестируем и доставляем. Это акцент на качество, инновационные технологии и комплексное непрерывное производство решения, которые движут нашим бизнесом и предоставляют нашим клиентам значительные конкурентные преимущества на мировом рынке.
Были ли разработки и прототипы продуктов, запуск новых продуктов, развертывание персонала, необходимого для удовлетворения спроса клиентов или доставки поставки нашим клиентам, мы принимаем все меры для обеспечения качества, совершенство и ведущие в отрасли процессы на протяжении всей нашей деятельности.
Модульные решения
В Agile Technologies есть множество возможностей. Мы были здесь, отвечая на все потребности наших клиентов. Необходимость большой опыт в разработке и производстве модульных решений? Смотри нет дальше, чем Agile Technologies. Мы предоставляем полный спектр DRAM, Модули Flash и SRAM, а также другие нестандартные решения.
Agile Technologies занимается разработкой, производством и предоставление новейших, наиболее экономичных и инновационных решений для наших OEM-клиенты по всему миру. Наш обширный ассортимент DRAM, Flash и SRAM модули позволяют OEM-заказчикам максимально гибко увеличивать скорость, качество и дизайн своей продукции.
Agile Technologies большой опыт в модульном проектировании и производство использует инновационные, современные и отраслевые стандарты технологии памяти. Наши передовые возможности проектирования и производства предлагать превосходные решения по сборке, тестированию, программированию и развертыванию для всех модульные потребности продукта. Чтобы сохранить лидирующие позиции в качестве модульного поставщик продуктовых решений, Agile Technologies, постоянно изучает, разработка и внедрение решений нового поколения.
Улучшенная и гибкая поддержка
Наши клиенты полагаются на высочайшее качество Agile Technologies, гибкость и быстрое реагирование, чтобы предложить им правильные решения. Мы предоставить
Обширный опыт проектирования и производства модульных решений
Быстрый вывод на рынок экономичных решений
Портфель комплексной поддержки продуктов с DRAM, Flash и SRAM
Стратегия, ориентированная на клиента
В Agile Technologies сервис означает возможность распознавать, предвидеть и концентрироваться на конкретных потребностях наших клиенты.Как наша бизнес-стратегия, так и повседневная деятельность основаны на отзывы, которые мы получаем от наших клиентов, и мы создали и развили Agile Technologies — один довольный клиент за раз. Сегодня мы предлагаем индивидуальные услуги клиентам в автомобильной, коммуникационной инфраструктуре, корпоративные вычисления и хранение, оборона и авиакосмическая промышленность, медицина, промышленность и полупроводниковое оборудование, мультимедиа и возобновляемые источники энергии Мировой.
Что такое гибкая методология? — Обзор гибкой разработки программного обеспечения и гибких моделей
Ключевые методологии Agile
Agile — это общий термин для нескольких методов и практик.Давайте посмотрим на некоторые из популярных методологий:
Scrum
Extreme Programming (XP)
Adaptive Software Development (ASD)
Dynamic Software Development Method (DSDM)
Feature Driven Development (FDD)
Kanban
Разработка, управляемая поведением (BDD)
Scrum
Методология
Методология Scrum — это простая структура для работы со сложными проектами, созданная Кеном Швабером и Джеффом Сазерлендом.
Гибкие методологии разработки программного обеспечения являются итеративными, то есть работа делится на итерации, которые в случае Scrum называются спринтами. Скрам выполняется небольшими командами из 7-9 человек, включая Скрам-мастера и владельца продукта.
В Scrum проекты делятся на циклы (обычно двух- или трехнедельные), называемые спринтами. Спринт представляет собой временной интервал, в рамках которого должен быть разработан набор функций. Несколько спринтов можно объединить в Релиз, в котором официальная поставка программного обеспечения / продукта осуществляется заказчику / рынку.
Общая функциональность продукта разбита Владельцем продукта на более мелкие функции (обычно называемые эпиками и пользовательскими историями или просто историями). Эти истории имеют приоритет и используются в каждом спринте или итерации. Цель метода состоит в том, чтобы команда могла в конце каждого спринта демонстрировать рабочие части продукта Владельцу продукта, чтобы убедиться, что продукт работает должным образом.
В целом метод Scrum разбивает длительный каскадный процесс на более мелкие циклы, что позволяет производственным группам и конечным потребителям часто проверять работающее программное обеспечение и обеспечивать его соответствие их бизнес-требованиям.Это гарантирует, что конечный продукт также соответствует конечным требованиям заказчика.
Метод Scrum характеризуется особыми церемониями, такими как ежедневная встреча Standup, встреча по обзору спринта, демонстрация для владельца продукта и ретроспективная встреча спринта. Все эти встречи предоставляют возможность совместной работы и обзора для команды, чтобы убедиться, что разработка идет должным образом, а любые проблемы решаются быстро.
«Путешествуя по жизни, будьте открыты для сотрудничества.Другие люди и чужие идеи часто лучше ваших собственных ». — Amy Poehler Щелкните для твита
Экстремальное программирование (XP)
Экстремальное программирование (XP) — или парное программирование — методология, разработанная Кентом Беком в начале 90-х годов. Эта гибкая методология ориентирована на улучшение межличностных отношений как ключ к успеху в разработке программного обеспечения. XP также ориентирована на развитие командной работы, заботу об обучении разработчиков и создание благоприятной рабочей среды.Он характеризуется тем, что разработчики работают в парах, где один разработчик программирует, а другой наблюдает; и они меняют эти роли на регулярной основе на протяжении всего спринта. Таким образом, они обеспечивают непрерывный обзор кода и обратную связь, что повышает качество кода и возможности разработчика.
Экстремальное программирование (XP) способствует постоянной обратной связи между клиентом и командами разработчиков, плавному общению между всеми участниками, простоте внедряемых решений и готовности к изменениям.XP особенно подходит для проектов с нечеткими и сильно меняющимися требованиями, а также с высоким техническим риском.
Адаптивная разработка программного обеспечения (ASD)
Адаптивная разработка программного обеспечения (ASD) была разработана Джимом Хайсмитом и Сэмом Байером в начале 1990-х годов. Он включает в себя принципы непрерывной адаптации, т. Е. адаптироваться к изменениям, а не бороться с ними . Адаптивная разработка программного обеспечения использует динамический цикл разработки, известный как «размышлять, сотрудничать и учиться».Этот цикл посвящен постоянному обучению и интенсивному сотрудничеству между разработчиками и клиентами в связи с постоянными изменениями в деловой среде.
В отличие от большинства методологий разработки программного обеспечения, которые используют статический жизненный цикл, то есть Plan-Design-Build, ASD предлагает нелинейный итеративный жизненный цикл, где каждый цикл может повторяться и изменяться во время выполнения другого цикла. Он указывает на быструю разработку приложений ( RAD ), которая подчеркивает скорость разработки для создания высококачественного продукта, не требующего особого обслуживания, с максимально возможным участием пользователя.Основные характеристики ASD:
Спекуляция: Это начальная фаза проекта, когда необходимо установить основные цели и задачи проекта, понимая ограничения (области риска), с которыми работает проект.
Сотрудничество: Это этап, на котором сосредоточена большая часть разработки, поддерживая координацию между командами, которая гарантирует, что то, что изучено одной командой, передается остальным и не нужно изучать снова другими командами с нуля .
Learn: Последний этап заканчивается серией циклов сотрудничества — задача состоит в том, чтобы зафиксировать то, что было изучено, как положительное, так и отрицательное. Этот этап имеет решающее значение для эффективности проекта.
«В гибком проекте команда заботится о задачах, а руководитель проекта заботится о команде». — Джим Хайсмит Нажмите, чтобы твитнуть
Метод динамической разработки программного обеспечения (DSDM)
Метод динамической разработки программного обеспечения (DSDM) был разработан в 1994 году группой поставщиков и экспертов в области разработки программного обеспечения.DSDM фокусируется на проектах программного обеспечения, для которых характерны ограниченные бюджеты и графики. Он ориентирован на частую реализацию продуктовых циклов, а разработка является итеративной и поэтапной.
С помощью метода динамической разработки программного обеспечения (DSDM) можно разработать дорожную карту ранних и непрерывных поставок для проекта, внедряя инкрементное решение, адаптируясь на основе отзывов, полученных на протяжении всего процесса, и проверяя, достигаются ли ожидаемые выгоды .
DSDM — это гибкая модель, которая, несомненно, может помочь организациям, которые привыкли работать над проектами, изменить свой менталитет и методы работы, чтобы повысить их способность приносить пользу и сократить время выхода на рынок.
Feature Driven Development (FDD)
Feature Driven Development (FDD) Методология в основном ориентирована на более крупные команды с большим количеством людей, чем те, к которым обычно применяются другие гибкие методологии, такие как Scrum. FDD был разработан Джеффом Де Лука и Питером Коадом в 1997 году. Эта методология ориентирована на короткие итерации, которые позволяют осуществлять материальные поставки продукта за короткий период времени (2 недели).
Проекты с несколькими командами и большим количеством людей представляют собой проблему, поскольку не все будут одинаково талантливы и дисциплинированы.FDD включает в себя конкретные мероприятия, которые помогают решать проблемы коммуникации и координации таких проектов.
FDD — это 5-этапный процесс, первые 3 из которых являются последовательными, а два последних этапа являются итерационными (как показано на диаграмме выше). Все гибкие методологии следуют ряду принципов, которые делают их похожими друг на друга. Однако FDD предлагает решения о том, как организовать команду и как программировать код, что делает его особенно жизнеспособным для больших команд разработчиков, создающих сложное программное обеспечение.
Одна из самых популярных книг по методу FDD была опубликована Стивеном Палмером в 2002 году под названием «Практическое руководство по разработке, основанной на функциях».
Канбан-метод
Канбан-метод был определен Дэвидом Андерсоном в начале-середине 2000-х годов в ответ на некоторые проблемы различных гибких методов, особенно Scrum. Эти методы, пытаясь решить проблемы традиционных / водопадных методов, сами стали жертвой некоторых из тех же проблем.
2-3-недельный цикл спринта стал слишком длинным для многих бизнес-контекстов, необходимые изменения в организационной структуре (новые роли и обязанности) и процессы управления / планирования проекта стали слишком тяжелыми для организаций, и многие команды оказались невыполнение обязательств даже на уровне спринта по объему и качеству. Для большинства организаций внедрение этих методов стало очень разрушительным.
Метод Канбан был определен как противоположность этому — не разрушающий эволюционный метод улучшения, который в конечном итоге позволяет командам работать непрерывно, а не в течение 2-3 недель, быстрее получать обратную связь и сокращать опережение. время доставить ценность клиенту.
Канбан — это визуальная система для управления работой в процессе. Канбан визуализирует как процесс (рабочий процесс), так и фактическую работу, проходящую через этот процесс. Цель Канбана — выявить потенциальные узкие места в вашем процессе и исправить их, чтобы работа могла проходить через него с минимальными затратами и с оптимальной скоростью или производительностью.
Канбан определяется как высокоэффективная и действенная производственная система. Истоки методологии Канбан лежат в производственных процессах «точно в срок» (JIT), разработанных Toyota, в которых карты использовались для определения материальных потребностей в производственной цепочке.Вы можете узнать больше о канбане здесь: https://www.digite.com/kanban/what-is-kanban/
Behavior Driven Development (BDD)
Behavior Driven Development (BDD) — это методология гибкой разработки, ориентированная на поведение. . Он был создан Дэном Нортом в 2003 году как эволюция методологии TDD. Дэн Норт стремился объединить нетехнических специалистов в процессе создания технической функциональности системы. Бывает, что когда мы разрабатываем программное обеспечение, мы невольно не включаем бизнес-концепции, представленные в функциональности, что может привести к повторяющимся и даже серьезным ошибкам.
Источник: Johnfergusonsmart.com
BDD использует универсальные языковые концепции, которые поощряют сотрудничество между людьми с техническими знаниями или без них в проекте программного обеспечения. Процесс разработки BDD основан на написании тестовых сценариев и функций. Они содержат требования и критерии приемлемости для поведения системы. Он сообщает вам, какие функции необходимы для начала работы, что они будут делать дальше и каковы будут результаты после их выполнения.
BDD помогает командам более точно сообщать о требованиях, обнаруживать дефекты на раннем этапе и создавать программное обеспечение, которое будет устойчивым с течением времени.
«Эффективное общение — это на 20% то, что вы знаете, и на 80%, как вы относитесь к тому, что знаете». — Джим Рон. Щелкните, чтобы написать в Твиттере
Что такое гибкая методология? Объяснение современной разработки программного обеспечения
Кажется, что сегодня каждая технологическая организация применяет гибкую методологию разработки программного обеспечения или ее версию. По крайней мере, они верят, что верят. Независимо от того, являетесь ли вы новичком в гибкой разработке приложений или изучили разработку программного обеспечения несколько десятилетий назад, используя методологию разработки программного обеспечения «водопад», сегодня на вашу работу, по крайней мере, влияет гибкая методология.
Но что такое гибкая методология и как ее применять при разработке программного обеспечения? Чем гибкая разработка отличается от водопада на практике? Что такое жизненный цикл гибкой разработки программного обеспечения или гибкий SDLC? И чем отличается Scrum Agile от Kanban и других гибких моделей?
Agile был официально запущен в 2001 году, когда 17 технологов разработали проект Agile Manifesto.Они написали четыре основных принципа гибкого управления проектами с целью разработки лучшего программного обеспечения:
Люди и взаимодействие важнее процессов и инструментов
Рабочее программное обеспечение поверх исчерпывающей документации
Сотрудничество с клиентами в рамках переговоров по контракту
Реагирование на изменение в соответствии с планом
До Agile: эпоха водопадной методологии
Старые руки вроде меня помнят дни, когда водопадная методология была золотым стандартом для разработки программного обеспечения. Процесс разработки программного обеспечения требовал наличия тонны документации, прежде чем начинать кодирование. Кто-то, обычно бизнес-аналитик, сначала написал документ с бизнес-требованиями, в котором было зафиксировано все, что бизнесу нужно было в приложении. Эти документы с бизнес-требованиями были длинными, подробно описывая все: общую стратегию, исчерпывающие функциональные спецификации и дизайн визуального пользовательского интерфейса.
Технологи взяли документ с бизнес-требованиями и разработали собственный документ с техническими требованиями.Этот документ определяет архитектуру приложения, структуры данных, объектно-ориентированный функциональный дизайн, пользовательские интерфейсы и другие нефункциональные требования.
Этот каскадный процесс разработки программного обеспечения, наконец, начнется с кодирования, затем интеграции и, наконец, тестирования, прежде чем приложение будет признано готовым к производству. Весь процесс может занять пару лет.
От нас, разработчиков, ожидалось, что они будут знать «спецификацию», как называлась полная документация, так же хорошо, как и авторы документов, и нас часто ругали, если мы забывали должным образом реализовать ключевую деталь, описанную на стр. 77 200-страничный документ.
В то время разработка программного обеспечения была непростой. Многие инструменты разработки требовали специального обучения, и рядом не было существующих сегодня программных компонентов с открытым исходным кодом или коммерческих, API и веб-сервисов. Нам пришлось разработать низкоуровневые вещи, такие как открытие соединений с базой данных и многопоточность обработки данных.
Даже для базовых приложений команды были большими, а средства коммуникации были ограничены. Наши технические характеристики были тем, что нас согласовывало, и мы использовали их, как Библию.Если требование изменилось, мы заставили бизнес-лидеров пройти долгий процесс проверки и подписать, потому что информирование об изменениях в команде и исправление кода было дорогостоящим.
Поскольку программное обеспечение было разработано на основе технической архитектуры, сначала были разработаны артефакты более низкого уровня, а затем — зависимые артефакты. Задачи назначались в зависимости от навыков, и обычно инженеры баз данных сначала конструировали таблицы и другие артефакты базы данных, затем разработчики приложений кодировали функциональность и бизнес-логику, а затем, наконец, накладывали пользовательский интерфейс. Потребовались месяцы, прежде чем кто-либо увидел, что приложение работает, и к тому времени заинтересованные стороны начали беспокоиться и часто стали более сообразительными в отношении того, чего они на самом деле хотят. Неудивительно, что внедрение изменений стоило так дорого!
Не все, что вы показываете пользователям, работает должным образом. Иногда пользователи вообще не использовали функцию. В других случаях возможность была широко успешной, но требовала реинжиниринга для поддержки необходимой масштабируемости и производительности. В мире водопада вы узнали эти вещи только после того, как программное обеспечение было развернуто, после длительного цикла разработки.
Поворот к гибкой разработке программного обеспечения
Методология водопада, изобретенная в 1970 году, была революционной, поскольку привнесла дисциплинированность в разработку программного обеспечения, чтобы гарантировать наличие четкой спецификации, которой необходимо следовать. В его основе лежал каскадный метод производства, заимствованный из инноваций на конвейере Генри Форда 1913 года, который обеспечивал определенность на каждом этапе производственного процесса, чтобы гарантировать, что конечный продукт соответствует изначально заданным спецификациям.
Когда водопадная методология пришла в мир программного обеспечения, вычислительные системы и их приложения, как правило, были сложными и монолитными, что требовало дисциплины и четкого результата.Требования также менялись медленно по сравнению с сегодняшним днем, поэтому масштабные усилия были менее проблематичными. Фактически, системы были построены исходя из предположения, что они не изменятся, а будут постоянными линкорами. Многолетние сроки были обычным явлением не только в разработке программного обеспечения, но также в производстве и другой деятельности предприятий. Но жесткость водопада стала ахиллесовой пятой в эпоху Интернета, когда требовались скорость и гибкость.
Методология разработки программного обеспечения начала меняться, когда разработчики начали работать над интернет-приложениями.Большая часть ранней работы выполнялась в стартапах, где команды были меньше, располагались в одном месте и часто не имели традиционных знаний в области информатики. Было финансовое и конкурентное давление, чтобы быстрее выводить на рынок веб-сайты, приложения и новые возможности. Инструменты и платформы разработки быстро изменились.
Это заставило многих из нас, работающих в стартапах, подвергнуть сомнению методологию водопада и искать способы повышения эффективности. Мы не могли позволить себе подготовить всю подробную документацию заранее, и нам нужен был более итеративный и совместный процесс.Мы все еще обсуждали изменения требований, но были более открыты для экспериментов и адаптации к потребностям конечных пользователей. Наши организации были менее структурированными, а наши приложения менее сложными, чем унаследованные корпоративные системы, поэтому мы были гораздо более открыты для создания, а не для покупки приложений. Что еще более важно, мы пытались развивать бизнес, поэтому, когда наши пользователи говорили нам, что что-то не работает, мы чаще всего слушали их.
Наши навыки и способность вводить новшества стали стратегически важными.Вы можете собрать все деньги, которые вам нужны, но вы не сможете привлечь талантливых разработчиков программного обеспечения, способных работать с быстро меняющимися интернет-технологиями, если вы собираетесь обращаться с ними как с подчиненными кодировщиками, рабски соблюдающими «спецификации». Мы отказались от менеджеров проектов, которые приходили со сквозными расписаниями, описывающими, что нам следует разрабатывать, когда должны поставляться приложения, а иногда даже то, как структурировать код. Нам ужасно удавалось выполнить трехмесячный и шестимесячный графики, которые руководители проекта водопада составляли и постоянно обновляли.
Вместо этого мы начали рассказывать им, как нужно разрабатывать интернет-приложения, и доставляли результаты по графику, который мы составляли итеративно. Оказывается, мы не так уж плохи в выполнении того, что мы обещали, когда мы делали это с небольшими интервалами от одной до четырех недель.
В 2001 году группа опытных разработчиков программного обеспечения собралась и поняла, что они коллективно практикуют разработку программного обеспечения, отличную от классической методологии водопада.И не все они были стартапами. Эта группа, в которую вошли технологические знаменитости Кент Бек, Мартин Фаулер, Рон Джеффрис, Кен Швабер и Джефф Сазерленд, разработала Agile Manifesto, который задокументировал их общие убеждения в том, как должен работать современный процесс разработки программного обеспечения. Они подчеркнули, что сотрудничество важнее документации, самоорганизации, а не жестким методам управления, и способности управлять постоянными изменениями, а не ограничиваться жестким водопадным процессом разработки.
Из этих принципов родилась гибкая методология разработки программного обеспечения.
Роли в гибкой методологии
Процесс гибкой разработки программного обеспечения всегда начинается с определения пользователей и документирования видения круга проблем, возможностей и ценностей, которые необходимо решить. Владелец продукта отражает это видение и работает с многопрофильной командой (или группами), чтобы реализовать это видение. Вот роли в этом процессе.
Пользователь
Гибкие процессы всегда начинаются с мыслей о пользователе или клиенте.Сегодня мы часто определяем их с помощью образов пользователей, чтобы проиллюстрировать различные роли в рабочем процессе, который поддерживает программное обеспечение, или различные типы потребностей и поведения клиентов.
Владелец продукта
Сам процесс гибкой разработки начинается с того, кто должен быть голосом клиента, включая любых внутренних заинтересованных лиц. Этот человек собирает все идеи, идеи и отзывы для создания видения продукта. Эти видения продукта часто бывают краткими и простыми, но, тем не менее, они рисуют картину того, кто является клиентом, какие ценности рассматриваются, и стратегию того, как их решать.Я могу представить, что первоначальное видение Google выглядело примерно так: «Давайте упростим для любого, у кого есть доступ в Интернет, возможность поиска релевантных веб-сайтов и веб-страниц с помощью простого интерфейса на основе ключевых слов и алгоритма, который поднимает авторитетные источники в результатах поиска».
Мы называем этого человека владельцем продукта . Его или ее обязанность — определить это видение, а затем работать с командой разработчиков, чтобы воплотить его в жизнь.
Для работы с командой разработчиков владелец продукта разбивает видение продукта на серию пользовательских историй, в которых более подробно рассказывается, кто является целевым пользователем, какая проблема решается для него и почему решение важно для него. , и какие ограничения и критерии приемлемости определяют решение.Эти пользовательские истории устанавливаются в приоритетном порядке владельцем продукта и просматриваются командой, чтобы убедиться, что у них есть общее понимание того, что от них требуется.
Команда разработчиков программного обеспечения
В Agile группа разработчиков и обязанности ее членов отличаются от таковых при традиционной разработке программного обеспечения.
Команды многопрофильны, они состоят из разнородной группы людей, обладающих необходимыми навыками для выполнения работы. Поскольку основное внимание уделяется доставке работающего программного обеспечения, команда должна создавать приложения, работающие от начала до конца.Таким образом, база данных, бизнес-логика и пользовательский интерфейс часть приложения разрабатываются, а затем демонстрируются демонстрационные версии, а не все приложение. Для этого члены команды должны сотрудничать. Они часто встречаются, чтобы убедиться, что все согласны с тем, что они создают, кто что делает и как именно разрабатывается программное обеспечение.
Помимо разработчиков, группы разработки программного обеспечения могут включать инженеров по обеспечению качества (QA), других инженеров (например, для баз данных и серверных систем), дизайнеров и аналитиков, в зависимости от типа программного проекта.
Scrum, Kanban и другие Agile-фреймворки
Множество Agile-фреймворков, которые предоставляют особенности процессов разработки и практик гибкой разработки, согласованные с жизненным циклом разработки программного обеспечения.
Самый популярный гибкий фреймворк называется scrum . Он фокусируется на каденции выполнения, называемой спринтом , и структурах встреч, которые включают следующее:
Планирование — где определяются приоритеты спринта
Обязательство — команда просматривает список или невыполненные пользовательские истории и решает, сколько работы можно сделать за время спринта.
Ежедневные стендап-встречи — чтобы команды могли сообщать обновленную информацию о своем статусе развития и стратегиях)
Спринты заканчиваются демонстрационным собранием, на котором функциональные возможности демонстрируются владельцу продукта, за которым следует ретроспективное собрание, на котором команда обсуждает, что прошло хорошо, а что требует улучшения в их процессе.
Многие организации нанимают мастеров схватки или тренеров, которые помогают командам управлять процессом схватки.
Хотя scrum преобладает, существуют и другие agile-фреймворки:
Канбан работает как процесс разветвления и разветвления, когда команда извлекает пользовательские истории с доски ввода и направляет их через поэтапный процесс разработки, пока они не будут завершены.
Некоторые организации применяют гибридный гибкий и каскадный подход, используя гибкие процессы для новых приложений и каскадный подход для устаревших.
Существует также несколько структур, позволяющих организациям масштабировать практику для нескольких команд.
В то время как гибкие структуры определяют процессы и сотрудничество, методы гибкой разработки специфичны для решения задач разработки программного обеспечения, выполняемых в соответствии с гибкой структурой.
Так, например:
Некоторые команды применяют парное программирование, когда два разработчика кодируют вместе, чтобы обеспечить более качественный код и дать возможность более старшим разработчикам наставлять младших.
Более продвинутые группы внедряют разработку и автоматизацию на основе тестирования, чтобы гарантировать, что базовая функциональность дает ожидаемые результаты.
Многие команды также принимают технические стандарты, чтобы интерпретация пользовательской истории разработчиком не приводила только к желаемой функциональности, но также соответствовала безопасности, качеству кода, соглашениям об именах и другим техническим стандартам.
Почему гибкая методология лучше
Agile-методология: что это такое, как это работает и почему это важно
Сегодня организации постоянно ищут способы идти в ногу с быстрыми темпами меняющихся технологий и развивающихся рынков.И когда имя игры — скорость, команды разработчиков должны быть более гибкими и гибкими, чем когда-либо прежде.
Вот где на помощь приходит методология Agile.
Читайте дальше, чтобы узнать, что такое методология Agile-разработки и как она может помочь вашей команде каждый раз создавать более быстрые, лучшие и надежные продукты.
Что такое гибкая методология?
Методология Agile была создана группой разработчиков программного обеспечения, которые хотели лучше подойти к традиционному процессу разработки, который, по их мнению, был слишком сложным и отягощенным требованиями к документации.
В основополагающем документе под названием Agile Manifesto группа выделила 4 ценности и 12 принципов, которые определяют философию Agile:
4 ценности Agile
Люди и взаимодействия важнее процессов и инструментов.
Рабочее программное обеспечение над исчерпывающей документацией.
Сотрудничество с клиентами в процессе переговоров по контракту.
Реагирование на изменение вместо следования плану.
Реагируя на потребности клиентов и более эффективно приспосабливаясь к изменениям, эти ценности помогают управлять процессом разработки, который обеспечивает надежную поставку качественных продуктов и довольных клиентов.
12 принципов гибкой разработки
Удовлетворяйте клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
Добро пожаловать и используйте изменения для конкурентного преимущества заказчика, даже на поздних этапах разработки.
Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков.
Ежедневно сотрудничать между бизнесменами и разработчиками на протяжении всего проекта.
Создавайте проекты вокруг мотивированных людей.Создайте среду и поддержку, которые необходимы разработчикам, и доверьте им выполнение работы.
Сделайте личный разговор наиболее эффективным и действенным методом передачи информации команде разработчиков и внутри нее.
Измерьте прогресс по количеству завершенных работоспособных программ.
Поддерживать постоянный и устойчивый темп развития на неопределенный срок.
Повысьте маневренность за счет постоянного внимания к техническому совершенству и хорошему дизайну.
Будьте проще.Простота — искусство максимизировать объем незавершенной работы — очень важна.
Признайте, что лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
Регулярно размышляйте и адаптируйте поведение для постоянного улучшения.
Эти ценности и принципы Agile представляют собой общую философию, которая может (и уже применялась) к многочисленным структурам и методологиям как в разработке программного обеспечения, так и в других процессах управления проектами.
Следуя этим ценностям и руководящим принципам, гибкое мышление ставит во главу угла гибкость и позволяет адаптироваться к изменениям в неопределенной среде.Это делает Agile популярной философией, поскольку она помогает командам быстрее доставлять продукты, лучше удовлетворяя потребности клиентов, пользователей и бизнеса.
Преимущества Agile
Метод Agile завоевал популярность как лучший выбор как для руководителей, так и для разработчиков. И неудивительно, почему.
Вот лишь несколько ключевых преимуществ гибкого управления проектами и гибкой разработки:
Более широкое участие и сотрудничество с заинтересованными сторонами
Agile поощряет высокую степень участия и сотрудничества между клиентом и командой разработчиков.Это приводит к тому, что клиенты становятся более довольными, поскольку весь процесс прозрачен, а разработчики лучше осведомлены о потребностях и желаниях клиентов.
Предсказуемые затраты и планирование
Разбив процесс разработки на итерационные спринты, менеджеры проектов могут более точно оценить затраты и установить четкие, предсказуемые сроки. Это делает заинтересованные стороны более счастливыми, потому что они знают, чего ожидать, и могут более точно планировать бюджеты и маркетинговые стратегии.Это также упрощает процесс разработки для команд, поскольку они могут сосредоточиться на быстрой и надежной доставке и регулярно тестировать программное обеспечение на предмет качества и эффективности.
Гибкость в условиях изменений
Гибкое управление проектами — это гибкость, позволяющая командам быстро адаптироваться к изменениям при одновременном сокращении невозвратных затрат. Agile позволяет командам менять направление в связи с изменяющимися потребностями клиентов, изменениями рыночных требований или в ответ на меняющиеся требования к продукту. Это дает командам гибкость для уточнения и изменения приоритетов отставания по продуктам, чтобы они всегда предоставляли высококачественные и актуальные продукты вовремя и в рамках бюджета.
Продукты более высокого качества
Гибкая разработка продуктов включает регулярное тестирование в процесс разработки. Это позволяет владельцу продукта выявлять проблемы на ранней стадии и вносить изменения по мере необходимости. В результате получаются актуальные и тщательно проверенные продукты более высокого качества.
Сниженный риск и более быстрая окупаемость инвестиций
Agile снижает риск, поскольку он регулярно тестирует и позволяет вносить изменения в середине разработки. Выполняя итерацию проекта шаг за шагом (вместо того, чтобы продвигаться вперед с жестким сквозным планом проекта), команды могут предсказуемо производить жизнеспособные продукты.Если они обнаруживают проблему в середине проекта, они могут быстро скорректировать курс, а не обнаруживать в конце всего проекта, что есть проблемы.
Кроме того, поскольку Agile больше ориентирован на пользователя, Agile-команды принимают решения на основе пользовательских историй, отзывов о тестировании и отзывов клиентов на протяжении всего процесса. Это гарантирует, что каждая функция будет не просто функциональным ИТ-компонентом, а ценным продуктом для конечных пользователей.
Вместе эти процессы минимизируют риски и помогают командам быстрее предоставлять ценность, что приводит к более быстрой окупаемости инвестиций.
Этапы методологии Agile
Жизненный цикл Agile состоит из 6 этапов:
1. Концепция
Первым шагом метода Agile является определение масштабов и приоритетов проектов. Вместе со своей командой и заинтересованными сторонами проведите мозговой штурм и определите возможности для бизнеса, а также оцените время и затраты на завершение каждого проекта. Затем вы можете определить, какие проекты являются выполнимыми и наиболее ценными, и отсюда расставить приоритеты для невыполненных работ по проекту.
2. Начало
После того, как вы узнаете, в чем состоит ваш проект, следующим шагом будет определение того, как вы его завершите.Кто вам нужен в вашей команде? Каковы исходные требования заказчика? Создайте диаграмму, чтобы определить обязанности команды и объем работы, которую необходимо выполнить в каждом спринте.
3. Итерация
После определения и утверждения исходного проекта группа разработчиков может приступить к работе над первой итерацией.
Базовый рабочий процесс на этом этапе включает:
Требования —Подтверждение требований на основе невыполненных работ по продукту и отзывов заинтересованных сторон.
Разработка —Разработка продукта в соответствии с установленными требованиями.
Тестирование — Проведите тестирование QA для проверки функций и выявления любых проблем.
Поставка —Изготовить рабочий продукт.
Обратная связь — Соберите отзывы клиентов и заинтересованных сторон, чтобы определить требования для следующей итерации.
4. Выпуск
После нескольких итераций пора выпустить окончательный продукт.На этапе выпуска вы проведете окончательное тестирование и проверку качества для выявления любых ошибок, устранения дефектов и доработки пользовательской документации перед выпуском в производство.
5. Производство
Ваш продукт популярен во всем мире! Фаза производства означает, что ваша функция работает. Пусть ваша команда обеспечит постоянный мониторинг и поддержку, чтобы система работала бесперебойно, а пользователи понимали, как ее использовать.
6. Вывод из эксплуатации
Когда ваша система устарела, ненужна или готова к замене, она переходит в фазу вывода из эксплуатации.Этот этап включает в себя все действия по окончании жизненного цикла, такие как уведомление клиентов и перенос выпуска системы из эксплуатации.
Примеры методологии Agile
Agile — это руководящая философия, которую можно применять к различным моделям разработки. Вот четыре наиболее популярных типа Agile-методологий:
Scrum
Scrum — это гибкая структура, которая фокусируется на кросс-функциональной командной работе, подотчетности и итерациях для разработки, доставки и поддержки сложных продуктов.Он в основном используется для разработки программного обеспечения, но его принципы могут быть применены и к другим командам управления проектами.
Структура Scrum разделена на ключевые роли, события и артефакты:
Роли Scrum:
Владелец продукта
Мастер Scrum
Команда разработчиков Scrum
События Scrum:
Ежедневное планирование Scrum
Sprint встреча
Обзор спринта
Ретроспектива спринта
Артефакты Scrum:
Журнал работы продукта
Журнал спринта
Инкремент (или цель спринта)
Scrum-команды используют такие инструменты, как доски задач Scrum для организации задач помочь членам команды визуализировать текущий статус проектов.
Канбан
Канбан — это гибкая модель, призванная помочь командам работать вместе более эффективно. Он следует трем руководящим принципам:
Визуализируйте свой рабочий процесс.
Ограничьте объем незавершенной работы.
Организуйте рабочий процесс по приоритету.
В отличие от Scrum, в Kanban нет предписанных ролей или спринтов с ограничением по времени. Вместо этого Канбан ориентирован на более короткие циклы для более быстрой доставки и прозрачности на протяжении всей разработки, чтобы все понимали, кто за что и когда отвечает.
Инструменты, такие как онлайн-доска Kanban, дают членам команды возможность вносить идеи, изменять статус задач и отслеживать их прогресс, чтобы все работали более эффективно и результативно вместе.
Визуализация процесса помогает всем оставаться на одной странице и гарантирует, что усилия будут сосредоточены на работе, которая имеет высокий приоритет и высокую отдачу.
Extreme Programming (XP)
XP — это наиболее специфическая гибкая среда разработки программного обеспечения. Он направлен не только на создание высококачественного программного обеспечения, но и на облегчение всего процесса для самой команды разработчиков.XP ценит общение, обратную связь, простоту, смелость и уважение.
Лучше всего применять, когда
Требования постоянно меняются
У команд жесткие сроки
Заинтересованные стороны хотят снизить риск в сроки
Команды могут автоматизировать модульные и функциональные тесты
Разработка через функции
Разработка через функции (FDD) — это ориентированный на клиента инструмент методологии Agile, который фокусируется на инкрементальной разработке и отчетности о состоянии на всех уровнях.Такой подход помогает предотвратить два основных препятствия в разработке программного обеспечения: путаницу и переделку.
FDD выполняет пять основных шагов:
Разработка общей модели
Составление списка функций
План по функции
Дизайн по функции
Построение по функции
FDD — это масштабируемая модель, которая предоставляет функции в большом количестве более короткие временные рамки, чем у других Agile-фреймворков. Например, вместо типичного 4-недельного цикла итераций в Scrum, FDD стремится предоставлять функции каждые 2-10 дней.Это упрощает группам отслеживание и устранение ошибок, адаптацию к запросам клиентов и быстрое информирование новых членов команды.
Самое замечательное в Agile то, что это скорее руководство, чем действительное правило. Поэтому, какой бы методологии Agile вы ни придерживались, убедитесь, что она отвечает потребностям вашей команды и клиентов. В конце концов, цель Agile — помочь командам выполнять работу лучше и быстрее. Так что найдите то, что лучше всего подходит для вас, и используйте его.
Охватывая гибкость
Вкратце об идее
Проблема
Гибкие методы, такие как scrum, kanban, и бережливая разработка , распространяются за пределы ИТ и на другие функции.Хотя некоторые компании добиваются значительных улучшений в производительности, скорости вывода на рынок и удовлетворенности клиентов и сотрудников, другие испытывают трудности.
Основная причина
Лидеры не понимают Agile. В результате они невольно продолжают использовать традиционные методы управления, которые подрывают гибкие проекты.
Решение
Изучите основы гибкой разработки. Разберитесь в условиях, в которых он работает или не работает. Начните с малого и дайте ему распространиться органически.Разрешите «мастерам» настраивать его. Используйте Agile на вершине. Разрушьте препятствия на пути к гибкому поведению.
Гибкие методы инноваций произвели революцию в информационных технологиях. За последние 25–30 лет они значительно увеличили показатели успеха в разработке программного обеспечения, улучшили качество и скорость вывода на рынок, а также повысили мотивацию и производительность ИТ-команд.
В настоящее время гибкие методологии, включающие новые ценности, принципы, практики и преимущества и являющиеся радикальной альтернативой командно-административному управлению, распространяются в широком диапазоне отраслей и функций и даже в топ-менеджеры. Национальное общественное радио использует гибкие методы для создания новых программ. John Deere использует их для разработки новых машин, а Saab — для производства новых истребителей. Intronis, лидер в сфере облачных сервисов резервного копирования, использует их в маркетинге. C.H. Робинсон, глобальный сторонний поставщик логистических услуг, применяет их в человеческих ресурсах. Винодельня Mission Bell использует их для всего: от производства вина до складирования и управления группой высшего руководства. И GE полагается на них, чтобы ускорить широко разрекламированный переход от конгломерата 20-го века к «цифровой промышленной компании 21-го века».«Вынимая людей из их функциональной разрозненности и помещая их в самоуправляемые и ориентированные на клиента междисциплинарные команды, гибкий подход не только ускоряет прибыльный рост, но и помогает создать новое поколение квалифицированных генеральных менеджеров.
Распространение гибкой разработки открывает интригующие возможности. Что, если бы компания могла получить положительную прибыль, увеличив на 50% внедрение новых продуктов? Что, если бы маркетинговые программы могли генерировать на 40% больше запросов клиентов? Что, если бы человеческие ресурсы могли нанять на 60% больше своих первоочередных задач? Что, если бы вдвое больше рабочих было эмоционально вовлечено в свою работу? Agile привнесла такие улучшения в ИТ.Возможности в других частях компании значительны.
Но есть серьезное препятствие. Когда мы спрашиваем руководителей, что они знают об Agile, обычно мы отвечаем неловкой улыбкой и шуткой вроде «Достаточно, чтобы быть опасным». Они могут использовать связанные с Agile термины («спринты», «временные рамки») и утверждать, что их компании становятся все более и более гибкими. Но поскольку они не прошли обучение, они не совсем понимают подход. Следовательно, они невольно продолжают управлять способами, которые противоречат принципам и практикам гибкой разработки, что подрывает эффективность гибких команд в подразделениях, которые им подчиняются.
Эти руководители запускают бесчисленные инициативы со срочными сроками, вместо того, чтобы уделять первоочередное внимание двум или трем. Они распространяют себя и своих лучших людей на слишком много проектов. Они планируют частые встречи с членами гибких команд, вынуждая их пропускать рабочие сессии или присылать замену. Многие из них чрезмерно вовлекаются в работу отдельных команд. Они больше говорят, чем слушают. Они продвигают маргинальные идеи, которые команда ранее рассматривала и отбрасывала.Они регулярно отменяют решения команды и добавляют уровни проверки и средства контроля, чтобы ошибки не повторялись. Из самых лучших побуждений они сводят на нет те преимущества, которые могут принести гибкие инновации.
Дополнительная литература
Инновации — это все, что нужно для гибкой разработки. Хотя этот метод менее полезен в рутинных операциях и процессах, в наши дни большинство компаний работают в очень динамичных средах. Им нужны не только новые продукты и услуги, но и инновации в функциональных процессах, особенно с учетом быстрого распространения новых программных инструментов. Компании, которые создают среду, в которой процветает гибкая разработка, обнаруживают, что команды могут быстрее производить инновации в обеих этих категориях.
В ходе нашей работы по консультированию и изучению таких компаний мы выделили шесть важнейших практик, которые следует применять лидерам, если они хотят извлечь выгоду из гибкого потенциала.
1. Узнайте, как на самом деле работает Agile
Некоторые руководители, кажется, ассоциируют agile с анархией (каждый делает то, что хочет), тогда как другие считают, что это означает «делать то, что я говорю, только быстрее».«Но Agile не является ни тем, ни другим. (См. Врезку «Ценности и принципы Agile».) Он бывает нескольких разновидностей, которые имеют много общего, но подчеркивают несколько разные вещи. К ним относятся схватка, , которая подчеркивает творческую и адаптивную командную работу при решении сложных проблем; бережливое развитие, которое фокусируется на постоянном устранении отходов; и канбан, , которые сосредоточены на сокращении времени выполнения заказа и объема незавершенной работы. Один из нас (Джефф Сазерленд) помог разработать методологию схватки, и на это его частично вдохновила «Игра по разработке нового продукта», статья HBR 1986 года, соавтором которой стал другой из нас (Хиротака Такеучи).Поскольку scrum и его производные используются как минимум в пять раз чаще, чем другие методы, мы будем использовать его методологии, чтобы проиллюстрировать гибкие практики.
Существует как минимум дюжина методологий гибких инноваций, которые разделяют ценности и принципы, но различаются акцентами. Специалисты часто сочетают разные подходы. Вот три из самых популярных форм и контекстов, в которых каждая работает лучше всего.
Scrum Канбан Бережливая разработка
Руководящие принципы Расширяйте возможности творческих межфункциональных команд Визуализация рабочих процессов и ограничение незавершенных работ Устранение отходов из системы в целом
Благоприятные условия для усыновления Творческие культуры с высоким уровнем доверия и сотрудничества, или
Радикальные инновационные команды, которые хотят изменить свою рабочую среду
Процессно-ориентированные культуры, предпочитающие эволюционные улучшения с несколькими предписанными практиками Процессно-ориентированные культуры, которые предпочитают эволюционные улучшения с всеобъемлющими ценностями, но без установленных практик
Предписанные роли Владельцы инициатив, ответственные за ранжирование приоритетов команды и предоставление ценности клиентам и бизнесу
Координаторы процесса, которые направляют рабочий процесс
Небольшие кросс-функциональные инновационные команды
Нет Нет
Правила предписанных работ Пять событий:
Планирование спринта для подготовки к следующему раунду работы
Фиксированные временные спринты постоянной продолжительности (1–4 недели) для создания потенциально готового к выпуску приращения продукта.
Ежедневные 15-минутные выступления для обзора прогресса и препятствий на поверхности
Обзоры спринтов, которые исследуют новый рабочий прирост
Ретроспективы спринта, чтобы команда могла изучить и улучшить себя
Три результата (или «артефакта»):
Portfolio backlog, гибкий и упорядоченный по порядку список потенциальных инновационных функций
Бэклог спринта, подмножество элементов невыполненного портфолио, выбранных для завершения в следующем спринте.
Деблокируемые рабочие приращения
Начни с того, что ты делаешь сейчас
Визуализируйте рабочие процессы и этапы
Ограничьте незавершенное производство на каждом этапе разработки
Измеряйте и улучшайте время цикла
Нет
Подход к культурным изменениям Быстро применять минимально предписанные практики, даже если они существенно отличаются от таковых в остальной части организации
Осваивайте предписанные практики, а затем адаптируйте их с помощью экспериментов
Уважать существующие структуры и процессы
Повышение прозрачности рабочих процессов
Поощряйте постепенные совместные изменения
Уважать существующие структуры и процессы
Подчеркните гибкие ценности во всей организации, сводя к минимуму организационное сопротивление
Преимущества Облегчает радикальные прорывы, сохраняя при этом (в отличие от skunkworks) преимущества работы в составе головной организации
Доставляет самые ценные инновации в кратчайшие сроки
Быстро увеличивает командное счастье
Развивает общие управленческие навыки
Избегает столкновений с культурой родительской организации
Максимизирует вклад членов команды за счет гибкой структуры команды и рабочих циклов
Облегчает быстрое реагирование на срочные проблемы за счет гибких рабочих циклов
Оптимизирует систему в целом и задействует всю организацию
Обеспечивает максимальную гибкость в настройке методов работы
Вызовы Лидерам может быть сложно определить приоритеты инициатив и передать контроль самоуправляемым командам.
Новые навыки матричного управления необходимы для координации десятков или сотен многопрофильных команд.
Фиксированное время итерации может не подходить для некоторых проблем (особенно тех, которые возникают ежедневно)
Некоторые члены команды могут быть недостаточно задействованы в определенных циклах спринта.
Практики должны выяснить, как лучше всего применять самые гибкие ценности и принципы
Широкое разнообразие практик может затруднить определение приоритетов инициатив и координацию между командами.
Когда инициативы не увенчаются успехом, бывает сложно определить, выбрали ли команды неправильные инструменты или использовали правильные инструменты неправильным образом.
Новичков, пытающихся изменить поведение, может разочаровывать отсутствие предписывающих методологий.
Эволюционные улучшения могут снизить вероятность радикальных прорывов, а крупные улучшения — менее быстрыми.
Лидерам необходимо, чтобы постоянное устранение отходов было вдохновляющим и увлекательным занятием.
Источник Даррелл К.Ригби, Джефф Сазерленд и Хиротака Такеучи
Из «Охват гибкости», апрель 2016 г. © HBR.ORG
Основы схватки относительно просты. Чтобы воспользоваться возможностью, организация формирует и наделяет полномочиями небольшую команду, обычно от трех до девяти человек, большинство из которых работают на полную ставку. Команда кросс-функциональна и включает в себя все навыки, необходимые для выполнения поставленных задач. Он управляет собой и несет строгую ответственность за каждый аспект работы.
«Инициативный владелец» команды (также известный как владелец продукта) несет полную ответственность за предоставление ценности клиентам (включая внутренних клиентов и будущих пользователей) и бизнесу. Человек в этой роли обычно приходит из бизнес-подразделения и делит свое время между работой с командой и координацией с ключевыми заинтересованными сторонами: клиентами, руководителями высшего звена и бизнес-менеджерами. Владелец инициативы может использовать такие методы, как дизайн-мышление или краудсорсинг, для создания всеобъемлющего «портфеля портфолио» многообещающих возможностей.Затем он или она постоянно и безжалостно ранжирует этот список в соответствии с последними оценками ценности для внутренних или внешних клиентов и компании.
Владелец инициативы не говорит команде, кто что должен делать и сколько времени займет выполнение задач. Скорее, команда создает простую дорожную карту и подробно планирует только те действия, которые не будут изменены до выполнения. Его члены разбивают задачи с наивысшим рейтингом на небольшие модули, решают, какой объем работы возьмет на себя команда и как ее выполнить, разрабатывают четкое определение «выполнено», а затем начинают создавать рабочие версии продукта в короткие циклы (меньше больше месяца) известна как спринтов. Координатор процесса (часто обученный мастер схватки) руководит процессом. Этот человек защищает команду от отвлекающих факторов и помогает задействовать коллективный разум.
Процесс прозрачен для всех. Члены команды проводят короткие ежедневные «стоячие» встречи, чтобы оценить прогресс и выявить препятствия. Они разрешают разногласия с помощью экспериментов и обратной связи, а не бесконечных дебатов или апелляций к властям. Они тестируют небольшие рабочие прототипы части или всего предложения с несколькими клиентами в течение коротких периодов времени.Если клиенты будут в восторге, прототип может быть выпущен немедленно, даже если один из руководителей не является его поклонником или другие считают, что ему нужно больше наворотов. Затем команда обдумывает способы улучшения будущих циклов и готовится атаковать следующий главный приоритет.
По сравнению с традиционными подходами к управлению Agile предлагает ряд основных преимуществ, которые были изучены и задокументированы. Это увеличивает продуктивность команды и удовлетворенность сотрудников. Это сводит к минимуму потери, связанные с повторяющимися встречами, повторяющимся планированием, избыточной документацией, дефектами качества и низкими характеристиками продукта.За счет улучшения видимости и постоянной адаптации к меняющимся приоритетам клиентов Agile улучшает взаимодействие с клиентами и их удовлетворенность, быстрее и более предсказуемо выводит на рынок наиболее ценные продукты и функции и снижает риски. Привлекая членов команды из разных дисциплин в качестве коллег, он расширяет организационный опыт и укрепляет взаимное доверие и уважение. Наконец, за счет значительного сокращения времени, затрачиваемого на микроменеджмент функциональных проектов, это позволяет старшим менеджерам более полно посвятить себя более ценной работе, которую могут выполнять только они: создание и корректировка корпоративного видения; определение приоритетов стратегических инициатив; упрощение и фокусирование работы; назначение нужных людей задачам; усиление межфункционального сотрудничества; и устранение препятствий на пути прогресса.
2. Понять, где Agile работает, а где нет
Agile — не панацея. Его наиболее эффективно и легко реализовать в условиях, обычно встречающихся в инновационном программном обеспечении: решаемая проблема является сложной; решения изначально неизвестны, и требования к продукту, скорее всего, изменятся; работа может быть модульной; возможно тесное сотрудничество с конечными пользователями (и быстрая обратная связь от них); а творческие команды обычно превосходят командно-контрольные группы.
По нашему опыту, эти условия существуют для многих функций по разработке продуктов, маркетинговых проектов, деятельности по стратегическому планированию, проблем цепочки поставок и решений по распределению ресурсов. Они реже встречаются в рутинных операциях, таких как техническое обслуживание оборудования, закупки, коммерческие звонки и бухгалтерский учет. А поскольку Agile требует обучения, изменения поведения и часто новых информационных технологий, руководители должны решить, оправдают ли ожидаемые результаты усилия и затраты на переход.
Условия Благоприятный Неблагоприятный
Рыночная среда Предпочтения клиентов и варианты решений часто меняются. Рыночные условия стабильны и предсказуемы.
Привлечение клиентов Возможны тесное сотрудничество и быстрая обратная связь.
По мере продвижения процесса заказчики лучше понимают, чего они хотят.
Требования ясны с самого начала и останутся стабильными.
Клиенты недоступны для постоянного сотрудничества.
Инновация Тип Проблемы сложные, решения неизвестны, а масштабы четко не определены. Технические характеристики продукта могут измениться. Творческий прорыв и время выхода на рынок очень важны.
Межфункциональное сотрудничество жизненно важно.
Подобная работа была проделана и раньше, и новаторы считают, что решения понятны.Подробные спецификации и планы работы можно с уверенностью прогнозировать, и их следует придерживаться. Проблемы могут быть решены последовательно в функциональных разрозненных хранилищах.
Модульность работы Дополнительные разработки имеют ценность, и клиенты могут их использовать.
Работу можно разбить на части и проводить в быстрых итеративных циклах.
Поздние изменения поддаются контролю.
Клиенты не могут начинать тестирование частей продукта, пока все не будет завершено.
Поздние изменения дороги или невозможны.
Влияние промежуточных ошибок Они дают ценное обучение. Они могут иметь катастрофические последствия.
Источник Bain & Company
Из «Embracing Agile», май 2016 г. © HBR.ORG
Гибкие инновации также зависят от наличия кадра активных участников.Один из ее основных принципов — «Создавайте проекты вокруг мотивированных людей. Обеспечьте им необходимую среду и поддержку и доверьте им выполнение работы ». Когда большая часть компании, подразделения или команды предпочитает применять гибкие методологии, лидерам может потребоваться оказать давление на противников, чтобы последовать их примеру или даже заменить их. Но лучше нанять страстных добровольцев, чем принуждать сопротивляющихся.
По этому пути пошла компания
OpenView Venture Partners, инвестировавшая около 30 компаний.Узнав об Agile от некоторых компаний из своего портфеля, Скотт Максвелл, основатель фирмы, начал использовать ее методологии в самой фирме. Он обнаружил, что они легче подходят для одних занятий, чем для других. Например, Agile хорошо зарекомендовал себя для стратегического планирования и маркетинга, где сложные проблемы часто можно разбить на модули и решить творческими мультидисциплинарными командами. Это было не в случае продажи: любой торговый звонок может изменить список дел представителя на месте, и было бы слишком сложно и долго собирать команду продаж, изменять портфель заказов и переназначать учетные записи каждый час. .
Гибкие инновации зависят от наличия кадра активных участников.
Maxwell предоставил компаниям, входящим в портфель OpenView, обучение принципам и методам гибкой разработки и позволило им решить, следует ли применять этот подход. Некоторым из них сразу понравилась идея реализовать ее; у других были другие приоритеты, и они решили воздержаться. Интронис был одним из его поклонников. В то время его маркетинговое подразделение полагалось на годовой план, ориентированный в первую очередь на выставки. Отдел продаж жаловался, что маркетинг был слишком консервативным и не приносил результатов.Поэтому компания наняла Ричарда Делахайе, веб-разработчика, ставшего маркетологом, для внедрения гибкой разработки. Под его руководством команда маркетинга научилась, например, тому, как проводить тематический вебинар за несколько дней, а не за несколько недель. (Быстро подготовленное занятие по вредоносному ПО CryptoLocker привлекло 600 зарегистрированных пользователей — все еще рекорд компании.) Сегодня члены команды продолжают создавать календари и бюджеты для подразделения цифрового маркетинга, но с гораздо меньшим количеством деталей по позициям и большей гибкостью для случайных разработок.Команда продаж намного счастливее.
3. Начните с малого и позвольте слову распространяться
Крупные компании обычно запускают программы изменений как массовые усилия. Но наиболее успешное внедрение гибкой разработки обычно начинается с малого. Часто они начинают с ИТ, где разработчики программного обеспечения, вероятно, знакомы с принципами. Затем Agile может распространиться на другую функцию, когда первые практикующие будут выступать в качестве тренеров. Кажется, что каждый успех создает группу страстных евангелистов, которым не терпится рассказать другим в организации, как хорошо работает Agile.
Примером может служить внедрение и расширение гибкости в John Deere, компании, производящей сельскохозяйственное оборудование. Джордж Томе, инженер-программист, ставший руководителем проекта в корпоративной ИТ-группе Deere, начал в 2004 году скромно применять принципы гибкой разработки. Постепенно, через несколько лет, их начали использовать и подразделения разработки программного обеспечения в других подразделениях Deere. Этот растущий интерес облегчил ознакомление с методологией компаний, занимающихся развитием бизнеса и маркетингом.
В 2012 году Том работал менеджером в отделе корпоративного маркетинга группы исследований и разработок, ответственной за открытие технологий, которые могут революционизировать предложения Deere. Джейсон Брантли, глава подразделения, был обеспокоен тем, что традиционные методы управления проектами замедляют внедрение инноваций, и эти двое решили посмотреть, сможет ли Agile ускорить процесс. Томе пригласил двух других руководителей подразделений на учебные курсы по гибкой методологии. Но вся терминология и примеры взяты из программного обеспечения, и для одного из менеджеров, не имевшего опыта работы с программным обеспечением, они показались тарабарщиной.Томе понял, что другие отреагируют таким же образом, поэтому он разыскал гибкого коуча, который знал, как работать с людьми, не имеющими опыта работы с программным обеспечением. За последние несколько лет он и тренер тренировали команды во всех пяти центрах группы НИОКР. Томе также начал публиковать еженедельные одностраничные статьи о принципах и практиках гибкой разработки, которые рассылались по электронной почте всем желающим и позже размещались на сайте Deere Yammer. Сотни сотрудников Deere присоединились к дискуссионной группе. «Я хотел разработать базу знаний об Agile, специфичную для Deere, чтобы любой сотрудник организации мог ее понять», — говорит Томе.«Это заложило бы основу для перехода к Agile в любую часть компании».
Используя гибкие методы, Enterprise Advanced Marketing значительно сократил время цикла инновационных проектов — в некоторых случаях более чем на 75%. Одним из примеров является разработка примерно за восемь месяцев рабочего прототипа новой «формы машины», которую компания Deere еще не раскрыла. «Если бы все прошло идеально в рамках традиционного процесса, — говорит Брантли, — то в лучшем случае это заняло бы полтора года, а может и два с половиной или три года.«Agile также привел к другим улучшениям. Вовлеченность команды и счастье в подразделении быстро перешли из нижней трети результатов компании в верхнюю треть. Качество улучшилось. Скорость (измеряемая объемом работы, выполненной в каждом спринте) увеличивалась в среднем более чем на 200%; некоторые команды достигли роста более чем на 400%, а одна команда взлетела на 800%.
Такой успех привлекает внимание. Сегодня, по словам Томе, почти в каждой области в John Deere кто-то либо начинает использовать Agile, либо думает о том, как его можно использовать.
4. Разрешить «мастерским» командам настраивать свои методы работы
японских студента боевых искусств, особенно изучающих айкидо, часто изучают процесс, называемый шу-ха-ри. В штате шу изучают проверенные дисциплины. Освоив их, они попадают в состояние га, , где расширяются и начинают изменять традиционные формы. В конце концов они продвигаются к ri, , где они настолько тщательно усвоили законы и принципы, что могут свободно импровизировать по своему усмотрению.
Освоение гибких инноваций аналогично. Прежде чем приступить к модификации или настройке гибкой разработки, человек или команда извлекут выгоду из практики широко используемых методологий, которые принесли успех в тысячах компаний. Например, не следует начинать с распределения по командам на неполный рабочий день или с ротации участников. Эмпирические данные показывают, что стабильные команды на 60% продуктивнее и на 60% лучше реагируют на запросы клиентов, чем команды, чередующиеся членов.
Дополнительная литература
Lean Knowledge Work
Управление людьми Особенность
Брэдли Статс и Дэвид М.Аптон
Принципы Toyota могут применяться в операциях, требующих экспертизы.
Со временем опытным практикам должно быть разрешено настраивать гибкие методы. Например, один принцип гласит, что команды должны постоянно следить за своим прогрессом и препятствиями. Первоначально наиболее популярным способом сделать это было вручную перемещать цветные стикеры из столбца «дел» в «делаю» и «готово» на больших белых досках (известных как доски канбан).Многие команды по-прежнему привержены этой практике и с удовольствием посещают свои командные комнаты, не являясь членами команды, чтобы посмотреть и обсудить прогресс. Но другие обращаются к программному обеспечению и компьютерным экранам, чтобы минимизировать время ввода и обеспечить одновременный обмен информацией в нескольких местах.
Ключевой принцип, которым руководствуется этот тип импровизации: если команда хочет изменить определенные методы, она должна экспериментировать и отслеживать результаты, чтобы убедиться, что изменения улучшаются, а не снижают удовлетворенность клиентов, скорость работы и боевой дух команды.
Spotify, компания, занимающаяся потоковой передачей музыки, является примером опытного адаптера. Основанная в 2006 году, компания с самого начала была гибкой, и вся ее бизнес-модель, от разработки продуктов до маркетинга и общего управления, ориентирована на улучшение качества обслуживания клиентов за счет гибких инноваций. Но высшие руководители больше не диктуют конкретные практики; напротив, они поощряют экспериментирование и гибкость, если изменения согласуются с принципами гибкой разработки и могут улучшить результаты. В результате практика различается в 70 «отрядах» компании (название Spotify для agile-инновационных команд) и ее «отделениях» (термин компании для обозначения функциональных компетенций, таких как разработка пользовательского интерфейса и тестирование качества). Хотя почти каждый отряд состоит из небольшой кросс-функциональной команды и использует ту или иную форму визуального отслеживания прогресса, ранжирования приоритетов, адаптивного планирования и мозговых штурмов о том, как улучшить рабочий процесс, многие команды пропускают диаграммы «выгорания» (которые показывают работу выполненная и оставшаяся работа), которые являются общей чертой гибких команд.Они также не всегда измеряют скорость, ведут отчеты о проделанной работе и не используют одни и те же методы для оценки времени, необходимого для выполнения данной задачи. Эти отряды протестировали свои модификации и обнаружили, что они улучшают результаты.
5. Практикуйте Agile на вершине
Некоторые действия высшего руководства не подходят для гибких методологий. (Рутинные и предсказуемые задачи, такие как оценка производительности, интервью с прессой и посещение заводов, клиентов и поставщиков, попадают в эту категорию.) Но многие, и, возможно, самые важные, таковы.Они включают разработку стратегии и распределение ресурсов, культивирование революционных инноваций и улучшение организационного сотрудничества. Руководители высшего звена, которые объединяются в гибкую команду и учатся применять дисциплину в этой деятельности, достигают далеко идущих преимуществ. Их собственная продуктивность и моральный дух улучшаются. Они говорят на языке команд, над которыми они работают. Они сталкиваются с общими проблемами и учатся их преодолевать. Они распознают и пресекают поведение, мешающее гибким командам.Они учатся упрощать и фокусировать работу. Результаты улучшаются, повышается уверенность и вовлеченность во всей организации.
Ряд компаний перераспределили 25% или более рабочего времени избранных руководителей из функциональной разрозненности в группы гибких руководителей. Эти группы упорядочивают портфели заказов по всему предприятию, создают и координируют гибкие команды в других частях организации для решения высших приоритетов и систематически устраняют препятствия на пути к их успеху. Вот три примера C-Suite, которые взяли на себя Agile:
1.Догоняют войска.
Systematic, компания-разработчик программного обеспечения с 525 сотрудниками, начала применять гибкие методологии в 2005 году. Когда они распространились на все команды разработчиков программного обеспечения, Майкл Холм, генеральный директор и соучредитель компании, начал беспокоиться о том, что его руководящая команда препятствует прогрессу. «У меня было такое чувство, что я говорил:« Следуй за мной — я за тобой », — сказал он нам. «Команды разработчиков использовали scrum и делали вещи по-другому, в то время как команда менеджеров застряла в том же старомодном стиле» — двигалась слишком медленно и полагалась на слишком много письменных отчетов, которые всегда казались устаревшими. Поэтому в 2010 году Холм решил руководить своей исполнительной группой из девяти человек как гибкой командой.
Команда изменила приоритеты управленческой деятельности, устранив более половины повторяющихся отчетов и преобразовав другие в системы реального времени, одновременно увеличив внимание к критически важным для бизнеса элементам, таким как коммерческие предложения и удовлетворенность клиентов. Группа начинала с встреч каждый понедельник на час или два, но сочла, что скорость принятия решений слишком медленная. Таким образом, он начал проводить ежедневные 20-минутные выступления в 8:40, чтобы обсудить, что участники делали накануне, что они будут делать в этот день и где им нужна помощь.Совсем недавно старшая команда начала использовать физические доски для отслеживания собственных действий и улучшений, поступающих от бизнес-единиц. Другие функции, включая HR, юриспруденцию, финансы и продажи, теперь работают примерно так же.
2. Ускорение корпоративного перехода.
В 2015 году General Electric провела ребрендинг в «цифровую промышленную компанию» с акцентом на продукты с цифровой поддержкой. Частью преобразования было создание GE Digital, организационного подразделения, в которое входят все более чем 20 000 сотрудников компании, связанных с программным обеспечением.Брэд Сурак, который начал свою карьеру в качестве инженера-программиста, а сейчас является главным операционным директором GE Digital, был хорошо знаком с Agile. Он провел экспериментальную схватку с командой руководителей, ответственных за разработку промышленных интернет-приложений, а затем, совсем недавно, начал применять ее к процессам управления нового подразделения, таким как операционные проверки. Сурак является инициативным владельцем, а технический руководитель — мастером схватки. Вместе они определили приоритетные задачи, которые должна решить исполнительная группа, включая упрощение административного процесса, которому команды следуют при приобретении оборудования, и решение сложных вопросов ценообразования для продуктов, требующих участия нескольких предприятий GE.
Члены scrum-команды проводят двухнедельные спринты и три раза в неделю проводят встречи в стойке. Они отмечают свой прогресс на доске в открытом конференц-зале, где это может видеть любой сотрудник. Сурак говорит: «Это снимает загадку с того, что руководители делают каждый день. Наши сотрудники хотят знать, созвучны ли мы тому, что им важно как наемным работникам ». Команда собирает опросы сотрудников, проводит анализ первопричин, препятствующих более эффективной работе, и отчитывается перед людьми во всей организации, говоря (фактически): «Мы вас услышали.Вот как мы будем улучшать ситуацию ». Сурак считает, что это показывает организации, что «руководители работают так же, как инженеры», повышая мотивацию сотрудников и приверженность гибким методам разработки.
3. Объединение отделов и функций по единому видению.
Эрик Мартелла, вице-президент и генеральный менеджер винодельни Mission Bell, производственного предприятия Constellation Brands, представил Agile и помог ему распространиться по всей организации. Руководители каждого отдела выступали в качестве владельцев инициативы в различных гибких командах своих отделов.Эти отдельные команды достигли впечатляющих результатов, но Мартелла беспокоился, что их время тратится слишком быстро и что приоритеты отдела и предприятия не всегда совпадают. Он решил объединить руководителей отделов в гибкую команду руководителей, сосредоточенную на корпоративных инициативах, которые имеют наибольшую ценность и дают наибольшие возможности для межфункционального сотрудничества, например, увеличение потоков процессов на складе.
Команда отвечает за создание и постоянное уточнение отставания по приоритетам предприятия, гарантируя, что гибкие команды работают над правильными проблемами и имеют достаточные ресурсы.Члены команды также защищают организацию от любимых проектов, которые не заслуживают высокого приоритета. Например, вскоре после того, как Мартелла начал внедрять Agile, он получил электронное письмо от начальника корпоративного офиса Constellation, в котором предлагалось, чтобы винодельня изучило личное увлечение отправителя. Раньше Мартелла мог ответить: «Хорошо, мы прыгнем прямо на это». Вместо этого он ответил, что винодельня следует принципам Agile: идея будет добавлена в список потенциальных возможностей и будет расставлена по приоритетам.Так получилось, что руководителю понравился такой подход — и когда ему сообщили, что его предложению присвоен низкий приоритет, он с готовностью принял это решение.
Scrum «снимает загадку с того, что руководители делают каждый день».
Работа в Agile-командах также может помочь подготовить функциональных менеджеров, которые редко выходят из своей изолированности в сегодняшних сверхспециализированных организациях, для выполнения общих управленческих ролей. Он знакомит их с людьми из других дисциплин, обучает методам совместной работы и подчеркивает важность тесного сотрудничества с клиентами — все это необходимо для будущих лидеров.
6. Разрушьте барьеры на пути к гибкому поведению
Исследование, проведенное Scrum Alliance, независимой некоммерческой организацией, насчитывающей более 400 000 участников, показало, что более 70% практиков Agile сообщают о напряженности между своими командами и остальной частью организации. Неудивительно: они следуют разным дорожным картам и движутся с разной скоростью.
Вот показательный пример: крупная компания, предоставляющая финансовые услуги, которую мы исследовали, запустила пилотный проект по созданию своего следующего мобильного приложения с использованием гибких методологий.Конечно, первым делом нужно было собрать команду. Это потребовало бюджетного запроса для авторизации и финансирования проекта. Запрос вошел в пакет представлений, претендующих на утверждение в следующем процессе годового планирования. После нескольких месяцев обзоров компания наконец одобрила финансирование. В ходе пилотного проекта было создано эффективное приложение, которое хвалили клиенты, а команда гордилась своей работой. Но до того, как приложение было выпущено, оно должно было пройти тестирование уязвимостей в традиционном «водопадном» процессе (длительная последовательность, в которой компьютерный код проверяется на документацию, функциональность, эффективность и стандартизацию), и очередь на этот процесс была длинной. .Затем приложение нужно было интегрировать в основные ИТ-системы, что потребовало еще одного каскадного процесса с затором от шести до девяти месяцев. В конце концов, общее время выпуска улучшилось очень незначительно.
Дополнительная литература
Расшифровка ДНК производственной системы Toyota
Управление человеческими ресурсами Статья в журнале
Стивен Спир
Х. Кент Боуэн
История Toyota была тщательно исследована и тщательно задокументирована, но то, что на самом деле происходит внутри компании, остается загадкой.Вот новый взгляд на негласные правила, которые дают Toyota ее конкурентное преимущество.
Вот несколько методов для устранения таких препятствий на пути к гибкой разработке:
Получите все на одной странице.
Отдельным командам, занимающимся небольшими частями больших и сложных проблем, необходимо видеть и работать в соответствии с одним и тем же списком корпоративных приоритетов, даже если не все команды, отвечающие за эти приоритеты, используют гибкие процессы. Если новое мобильное приложение является высшим приоритетом для разработки программного обеспечения, оно также должно быть высшим приоритетом при составлении бюджета, тестировании уязвимостей и интеграции программного обеспечения.В противном случае гибкие инновации будут испытывать трудности при внедрении. Это ключевая ответственность управленческой команды, которая сама практикует гибкую разработку.
Не меняйте структуру сразу; вместо этого поменяйте роли.
Многие руководители полагают, что создание большего количества кросс-функциональных команд потребует серьезных изменений в организационной структуре. Это редко бывает правдой. Мощные кросс-функциональные команды по определению нуждаются в некоторой форме матричного управления, но для этого в первую очередь необходимо, чтобы разные дисциплины научились работать вместе одновременно, а не по отдельности и последовательно.
Назовите только одного босса для каждого решения.
У людей может быть несколько боссов, но не у решений. В гибкой операционной модели должно быть предельно ясно, кто отвечает за создание кросс-функциональной команды, выбор и замену членов команды, назначение лидера группы и утверждение решений команды. Группа гибких руководителей часто уполномочивает старшего руководителя выявлять критические проблемы, разрабатывать процессы для их решения и назначать единственного владельца для каждой инновационной инициативы.Другие руководители высшего звена должны избегать сомнений в решениях собственников и их отмены. Давать советы и помогать — это нормально, но если вам не нравятся результаты, смените владельца инициативы — не лишайте его дееспособности.
Сосредоточьтесь на командах, а не на отдельных лицах.
Исследования, проведенные Центром коллективного разума Массачусетского технологического института и другими организациями, показывают, что, хотя интеллект людей влияет на работу команды, коллективный интеллект команды еще более важен. К тому же изменить намного легче.Agile-команды используют фасилитаторов процессов для постоянного улучшения своего коллективного интеллекта, например, путем уточнения ролей, обучения методам разрешения конфликтов и обеспечения равного вклада членов команды. Перенос показателей с показателей производительности и использования (насколько заняты люди) на бизнес-результаты и командное счастье (насколько ценны и вовлечены люди) также помогает, как и системы признания и вознаграждения, которые ставят командные результаты выше, чем индивидуальные усилия.
Руководите вопросами, а не приказами.
Генерал Джордж С. Паттон-младший, как известно, советовал руководителям никогда не рассказывать людям , как что-то делать: «Скажи им , что делать, и они удивят вас своей изобретательностью». Вместо того, чтобы отдавать приказы, лидеры в гибких организациях учатся направлять с помощью таких вопросов, как «Что вы порекомендуете?» и «Как мы можем это проверить?» Такой стиль управления помогает функциональным экспертам превратиться в генеральных менеджеров, а также помогает корпоративным стратегам и организациям превратиться из разрозненной борьбы за власть и ресурсы в совместные кросс-функциональные команды.
Agile-инновации произвели революцию в индустрии программного обеспечения, которая, возможно, претерпела более быстрые и глубокие изменения, чем любая другая сфера бизнеса за последние 30 лет. Теперь он готов преобразовать почти все остальные функции в каждой отрасли. На данный момент самым большим препятствием является не необходимость в улучшенных методологиях, эмпирических доказательствах значительных преимуществ или доказательстве того, что Agile может работать вне ИТ. Это поведение руководителей. Те, кто научится проводить внедрение Agile в более широкий спектр бизнес-операций, ускорят прибыльный рост.
Версия этой статьи появилась в выпуске за май 2016 г. (стр. 40–48, 50) журнала Harvard Business Review .
Гибкое управление проектами — Руководство для новичков
Что такое гибкое управление проектами?
Agile Project Management — это итеративный подход к управлению проектами, который фокусируется на разбиении больших проектов на более управляемые задачи, которые выполняются за короткие итерации на протяжении всего жизненного цикла проекта. Команды, использующие методологию Agile, могут быстрее выполнять работу, адаптироваться к меняющимся требованиям проекта и оптимизировать свой рабочий процесс.
Как следует из названия, Agile позволяет командам быть лучше оснащенными, чтобы быстро менять направление и фокус. Компании-разработчики программного обеспечения и маркетинговые агентства особенно осведомлены о тенденции смены участников проекта каждую неделю. Методология Agile позволяет командам переоценивать работу, которую они делают, и приспосабливаться к заданным шагам, чтобы быть уверенным, что по мере изменения работы и ландшафта клиентов меняется и фокус для команды.
Если вы новичок в Agile-управлении проектами, на первый взгляд это может показаться сложной и сложной в управлении системой.Но, осознаете вы это или нет, вы уже делаете многое из того, что требует Agile. С помощью нескольких настроек вы сможете сократить циклы разработки и сократить частоту выпусков продуктов.
Кто использует гибкое управление проектами?
Изначально разработанный для разработки программного обеспечения, Agile-подход к управлению проектами быстро адаптировался не только ИТ-командами. Маркетологи, университеты, военные и даже автомобильная промышленность также обращают внимание на методологию Agile и другие структуры Agile для доставки инновационных продуктов в неопределенных условиях.Многие организации могут извлечь выгоду из гибкого управления проектами, которое легко настроить и использовать.
В мире программного обеспечения, когда принимается решение о создании или дальнейшем развитии существующей технологии, конечный продукт может быть трудно определить. Agile допускает эту двусмысленность из-за своей гибкости, позволяющей изменять направление проекта по мере продвижения работы в будущее.
Несмотря на то, что вы можете воспользоваться преимуществами программного обеспечения Agile, книг или инструкторов по Agile, каждая команда Agile уникальна, и понимание основ может помочь вам разработать методологию Agile, которая будет работать для вас и вашей команды.
Белая книга: Как стать гибким агентством
Технический документ: Гибкий маркетинг для творческих команд
Каковы четыре основные ценности Agile?
Agile Manifesto определяет 4 основные ценности и 12 руководящих принципов, которые служат северной звездой для любой команды, применяющей методологию Agile.
Четыре основных ценности Agile:
1. Люди и взаимодействие важнее процессов и инструментов
Какими бы сложными ни были технологии, человеческий фактор всегда будет играть важную роль в любом виде управления проектами.Слишком большая зависимость от процессов и инструментов приводит к неспособности адаптироваться к меняющимся обстоятельствам.
2. Рабочее программное обеспечение над исчерпывающей документацией
Как ни важна документация, гораздо важнее рабочее программное обеспечение. Это значение дает разработчикам именно то, что им нужно для выполнения работы, не перегружая их.
3. Сотрудничество с клиентами по согласованию контрактов
Ваши клиенты — один из ваших самых важных активов. Независимо от того, внутренние или внешние клиенты, вовлечение их в процесс может помочь гарантировать, что конечный продукт будет более эффективно удовлетворять их потребности.
4. Реагирование на изменение в соответствии с планом
Это значение является одним из самых больших отклонений от традиционного управления проектами. Исторически изменение считалось расходом, которого следует избегать. Agile допускает постоянные изменения на протяжении всего жизненного цикла любого проекта. Каждый спринт дает возможность пересмотреть и скорректировать курс.
Каковы 12 принципов гибкой разработки?
Методологии
Agile могут быть столь же разнообразными и уникальными, как и каждая отдельная команда, но 12 принципов Agile всегда должны определять ваши решения и разработку продукта.
Нашим высшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения (или того, что вы доставляете).
Приветствуем изменение требований даже на поздней стадии разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.
Выполняйте проекты часто, от пары недель до пары месяцев, с предпочтением более коротких сроков.
Члены координационной группы должны работать вместе ежедневно на протяжении всего проекта.
Создавайте проекты вокруг мотивированных людей. Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.
Личный разговор — самый действенный и действенный метод передачи информации между разными командами и внутри них.
Конечный продукт — это главный показатель прогресса.
Agile-процессы способствуют устойчивому развитию. Все заинтересованные стороны должны иметь возможность поддерживать постоянный темп на неопределенный срок.
Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
Простота — искусство максимизировать объем незавершенной работы — очень важна.
Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.
Лист данных: Шпаргалка по гибкому маркетингу
Веб-семинар: Что удерживает маркетологов от перехода к гибкости?
Ключевые компоненты гибкого управления проектами
Истории пользователей
Проще говоря, пользовательская история — это высокоуровневое определение рабочего запроса.Он содержит достаточно информации, чтобы команда могла дать разумную оценку усилий, необходимых для выполнения запроса. Это короткое и простое описание написано с точки зрения пользователя и фокусируется на изложении того, чего хочет ваш клиент (его целей) и почему.
Спринты
Спринт — это короткая итерация, обычно от одной до трех недель, когда команды работают над задачами, определенными на собрании по планированию спринта. По мере продвижения вперед идея состоит в том, чтобы постоянно повторять эти спринты, пока ваш продукт не будет готов к функциональности.По окончании спринта вы просматриваете продукт, видите, что работает, а что не работает, вносите коррективы и начинаете еще один спринт, чтобы улучшить продукт или услугу.
Stand-up встречи
Ежедневные встречи (до 10 минут), также известные как «ежедневные встречи по Скраму», — отличный способ убедиться, что все находятся на верном пути и информированы. Эти ежедневные взаимодействия известны как «встать», потому что участники должны оставаться стоя, что помогает сделать встречи короткими и по существу.
Доска Agile
Доска Agile помогает вашей команде отслеживать прогресс вашего проекта. Это может быть доска с липкими заметками, простая доска Канбан или функция в вашем программном обеспечении для управления проектами.
Задержка
По мере того, как запросы проектов добавляются через вашу систему приема, они становятся выдающимися историями в невыполненной работе. Во время сессий Agile-планирования ваша команда будет оценивать количество баллов по каждой задаче. Во время планирования спринта истории в бэклоге перемещаются в спринт для завершения во время итерации.Управление невыполненными работами — жизненно важная роль для менеджеров проектов в среде Agile.
Различные методологии Agile могут потребовать определенных командных ролей для соблюдения структуры или могут не требовать каких-либо определенных ролей. Хотя индивидуальная реализация Agile может не требовать всех этих ролей, вот несколько общих ролей, которые вы можете найти:
Скрам Мастер. Scrum Master гарантирует, что каждый спринт не сбивается с пути, и помогает устранять или решать любые проблемы или проблемы, которые могут возникнуть.Они защитники команды.
Владелец продукта. Роль product owner-а — определять цели каждого спринта, управлять бэклогом команды и расставлять приоритеты, а также быть голосом клиента или внутренней заинтересованной стороны.
Члены команды. Люди в этой команде — это те, кто выполняет работу в каждом спринте. Эти команды, обычно состоящие из трех-семи человек, могут состоять из разных специальностей и сильных сторон, или они могут быть командами людей с одинаковыми ролями.
Заинтересованные стороны. Это только информационная роль. Заинтересованные стороны должны быть в курсе продукта и целей спринта, иметь возможность проверять и утверждать работу во время спринта, а также предоставлять обратную связь во время ретроспективы спринта.
Каждая методология Agile имеет свой собственный уникальный список членов команды и ролей, и, хотя названия могут меняться, существует несколько универсальных ролевых характеристик, которые должны иметь большинство структур Agile-команд:
Т-образный: Ценный член Agile-команды обладает обширными базовыми знаниями по своему предмету, но также обладает глубокими знаниями, опытом и способностями в одной (или нескольких) конкретных областях.
Межфункциональный: Межфункциональный Члены Agile-команды обладают навыками, выходящими за рамки их традиционных областей. Они могут знать некоторые основные принципы графического дизайна и анализа данных или даже немного HTML / CSS.
Адаптируемый: Если у них есть разноплановый набор навыков, они знают, как им пользоваться. Независимо от окружающей среды, их результат остается неизменным.
Любопытно: Часть оптимизации и повышения эффективности заключается в том, чтобы задавать правильные вопросы и бросать вызов тому, как всегда было, когда это уместно.
Предприниматель: Член Agile-команды — это тот, кто не ждет, чтобы ему сказали, что делать. Они готовы заполнять и разрабатывать кампании там, где они видят необходимость.
Командно-ориентированный: Командные игроки ставят успех команды выше своей личной славы. Если все работают вовремя и хорошо синхронизируются, они видят в этом победу.
Стремление к совершенству: Одним из ключевых преимуществ Agile-проектов является быстрое выполнение качественной работы.Члены команды, стремящиеся к совершенству, не соглашаются на среднее. Они не зациклены на совершенстве, но всегда стремятся создавать свои лучшие работы.
Подробнее об Agile-командах
Какие 6 шагов в методологии Agile?
Цель Agile — обеспечить более короткие циклы разработки и более частые выпуски продуктов, чем при традиционном каскадном управлении проектами. Эти более короткие временные рамки позволяют проектным группам более эффективно реагировать на изменения в потребностях клиента.
Как мы уже говорили, вы можете использовать несколько разных Agile-фреймворков — Scrum и Kanban — два из самых распространенных. Но каждая методология Agile будет следовать одному и тому же базовому процессу, который включает:
1. Планирование проекта
Как и в случае с любым другим проектом, перед тем, как начать, ваша команда должна понять конечную цель, ценность для организации или клиента и то, как она будет достигнута.
Здесь вы можете разработать объем проекта, но помните, что цель использования Agile-управления проектами состоит в том, чтобы иметь возможность легко вносить изменения и дополнения в проект, поэтому объем проекта не следует рассматривать как неизменный.
2. Создание дорожной карты продукта
Дорожная карта — это разбивка функций, которые будут составлять конечный продукт. Это важный компонент на этапе планирования Agile, потому что ваша команда будет создавать эти индивидуальные функции во время каждого спринта.
На этом этапе вы также создадите бэклог продукта, который представляет собой список всех функций и результатов, которые составят конечный продукт. Когда вы позже планируете спринты, ваша команда будет извлекать задачи из этого невыполненного журнала.
3. Планирование выпуска
В традиционном управлении проектами водопада существует одна дата реализации, которая наступает после того, как весь проект был разработан. Однако при использовании Agile в вашем проекте используются более короткие циклы разработки (называемые спринтами) с функциями, выпускаемыми в конце каждого цикла.
Перед тем, как приступить к проекту, вы составите общий план для выпусков функций, а в начале каждого спринта вы будете пересматривать и повторно оценивать план выпуска для этой функции.
4. Планирование спринта
Перед началом каждого спринта заинтересованные стороны должны провести собрание по планированию спринта, чтобы определить, что будет выполнено каждым человеком во время этого спринта, как это будет достигаться, и оценить нагрузку задачи. Важно равномерно распределить нагрузку между членами команды, чтобы они могли выполнять поставленные перед ними задачи во время спринта.
Вам также необходимо визуально задокументировать рабочий процесс для обеспечения прозрачности команды, общего понимания внутри команды, а также выявления и устранения узких мест.
5. Ежедневные выступления
Чтобы помочь вашей команде выполнять свои задачи во время каждого спринта и оценить, нужно ли вносить какие-либо изменения, проводите короткие ежедневные встречи. Во время этих встреч каждый член команды кратко расскажет о том, чего они достигли накануне и над чем они будут работать в этот день.
Эти ежедневные встречи должны длиться всего 15 минут. Они не предназначены для продолжительных занятий по решению проблем или возможности поговорить об общих новостях.Некоторые команды даже проводят эти встречи стоя, чтобы они были краткими.
6. Обзор и ретроспектива спринта
После окончания каждого спринта ваша команда проведет две встречи: во-первых, вы проведете обзор спринта с заинтересованными сторонами проекта, чтобы показать им готовый продукт. Это важная часть поддержания открытого общения с заинтересованными сторонами. Личная встреча или видеоконференция позволяет обеим группам наладить отношения и обсудить возникающие проблемы с продуктами.
Во-вторых, у вас будет ретроспективная встреча с вашими заинтересованными сторонами, чтобы обсудить, что прошло хорошо во время спринта, что могло быть лучше, была ли нагрузка задачи слишком тяжелой или слишком легкой для каждого участника и что было выполнено во время спринта.
Если ваша команда плохо знакома с Agile-управлением проектами, не пропустите эту важную встречу. Это помогает вам оценить, насколько ваша команда может решить во время каждого спринта, и наиболее эффективную продолжительность спринта для будущих проектов.
Подробнее: Workfront для управления проектами
Блог: Agile vs Waterfall
Переход на гибкое управление проектами
Когда вы почувствуете себя комфортно продвигаться вперед с Agile, вы захотите начать с обучения своих Agile-команд тому, как они перейдут на свои новые роли, когда у них начнутся ежедневные встречи и как они перейдут к своей текущей работе. в методологию Agile.
После того, как вы определите шаги перехода и убедитесь, что всем нравится новый стиль работы, вам нужно будет отслеживать и отслеживать их прогресс и успехи.
Если они изо всех сил пытаются бежать с той же скоростью, что и раньше, что может вызывать эти проблемы? Если команда не обновляет истории с их текущим статусом, были ли эти статусы четко определены?
Отслеживание прогресса или успеха новой Agile-команды будет очень полезно, чтобы придать ей уверенность в изменениях. Кроме того, наличие этих показателей Agile поможет обосновать преимущества перехода команды на Agile на собраниях более высокого уровня.
Наконец, важно предоставить вашей команде и новым скрам-мастерам форму, в которой изложены полезные вопросы, которые нужно задавать во время ежедневных встреч и ретроспективных итераций.Это дает отличную документацию для будущих обзоров процессов. Это также позволит команде определить области, которые нуждаются в улучшении, и поможет ответить на вопросы, о которых она, возможно, не думает обсуждать, если это новость для Agile.
Подробнее: Внедрение Agile в масштабе
Начать работу с гибким управлением проектами
Это самые основные и важные части управления проектами Agile. Когда вы переводите свою команду на гибкую методологию, эти процессы, гибкое программное обеспечение и инструменты, роли и принципы помогут вам изменить свое мышление и начать совместную работу, чтобы стать более гибкими и адаптироваться к изменениям по мере их появления.Гибкая разработка не для всех, но команды, которые ее правильно используют, получат огромные преимущества, в том числе оптимизированные рабочие процессы и быстрые инновации.
Что такое гибкая методология: определение
Методология
Agile — это набор принципов разработки программного обеспечения, в которых ценится адаптируемость и небольшие, постепенные изменения, направленные на повышение качества программного обеспечения и обеспечение большей способности реагировать на меняющиеся потребности бизнеса.
Что мне нужно знать об гибкой методологии?
Agile-принципы возникли в 1990-х годах, отчасти для устранения очевидных недостатков традиционного процесса разработки водопада.За последние два десятилетия гибкая методология неуклонно завоевывала доверие и стала популярной.
Чем гибкая методология отличается от других методологий разработки программного обеспечения?
Существует множество конкретных практик, и не все группы разработчиков программного обеспечения применяют все методы. Тем не менее, все группы гибкой разработки придерживаются основных принципов, которые вращаются вокруг коротких итеративных изменений и частых сборок, чтобы сделать процесс разработки отзывчивым и адаптируемым к меняющимся требованиям.Agile-разработчики считают, что удовлетворение клиента / бизнеса важнее, чем выполнение долгосрочного плана.
Методология
Agile получила широкое признание отчасти потому, что она намного лучше подходит для быстрых темпов изменений, которые стимулируют конкуренцию в бизнесе в эпоху Интернета и мобильных устройств. Создание единого набора требований к программному продукту с последующей установкой даты замораживания изменений в течение недельного или месячного процесса разработки не соответствует темпам и сложности сегодняшних бизнес-потребностей.Напротив, гибкие разработчики рассматривают создание программного обеспечения как органический эволюционный процесс.
Кто использует гибкую методологию?
Agile широко используется в компаниях, которые создают клиентские или потребительские веб-программные продукты или мобильные приложения, в которых распространены ежедневные или даже ежечасные выпуски. Однако всеобъемлющий принцип небольших выпусков и большей автоматизации процессов сборки и тестирования получил широкое признание даже в организациях, которые официально не приняли гибкую методологию.
.
No related posts.

	Scrum	Канбан	Бережливая разработка
Руководящие принципы	Расширяйте возможности творческих межфункциональных команд	Визуализация рабочих процессов и ограничение незавершенных работ	Устранение отходов из системы в целом
Благоприятные условия для усыновления	Творческие культуры с высоким уровнем доверия и сотрудничества, или Радикальные инновационные команды, которые хотят изменить свою рабочую среду	Процессно-ориентированные культуры, предпочитающие эволюционные улучшения с несколькими предписанными практиками	Процессно-ориентированные культуры, которые предпочитают эволюционные улучшения с всеобъемлющими ценностями, но без установленных практик
Предписанные роли	Владельцы инициатив, ответственные за ранжирование приоритетов команды и предоставление ценности клиентам и бизнесу Координаторы процесса, которые направляют рабочий процесс Небольшие кросс-функциональные инновационные команды	Нет	Нет
Правила предписанных работ	Пять событий: Планирование спринта для подготовки к следующему раунду работы Фиксированные временные спринты постоянной продолжительности (1–4 недели) для создания потенциально готового к выпуску приращения продукта. Ежедневные 15-минутные выступления для обзора прогресса и препятствий на поверхности Обзоры спринтов, которые исследуют новый рабочий прирост Ретроспективы спринта, чтобы команда могла изучить и улучшить себя Три результата (или «артефакта»): Portfolio backlog, гибкий и упорядоченный по порядку список потенциальных инновационных функций Бэклог спринта, подмножество элементов невыполненного портфолио, выбранных для завершения в следующем спринте. Деблокируемые рабочие приращения	Начни с того, что ты делаешь сейчас Визуализируйте рабочие процессы и этапы Ограничьте незавершенное производство на каждом этапе разработки Измеряйте и улучшайте время цикла	Нет
Подход к культурным изменениям	Быстро применять минимально предписанные практики, даже если они существенно отличаются от таковых в остальной части организации Осваивайте предписанные практики, а затем адаптируйте их с помощью экспериментов	Уважать существующие структуры и процессы Повышение прозрачности рабочих процессов Поощряйте постепенные совместные изменения	Уважать существующие структуры и процессы Подчеркните гибкие ценности во всей организации, сводя к минимуму организационное сопротивление
Преимущества	Облегчает радикальные прорывы, сохраняя при этом (в отличие от skunkworks) преимущества работы в составе головной организации Доставляет самые ценные инновации в кратчайшие сроки Быстро увеличивает командное счастье Развивает общие управленческие навыки	Избегает столкновений с культурой родительской организации Максимизирует вклад членов команды за счет гибкой структуры команды и рабочих циклов Облегчает быстрое реагирование на срочные проблемы за счет гибких рабочих циклов	Оптимизирует систему в целом и задействует всю организацию Обеспечивает максимальную гибкость в настройке методов работы
Вызовы	Лидерам может быть сложно определить приоритеты инициатив и передать контроль самоуправляемым командам. Новые навыки матричного управления необходимы для координации десятков или сотен многопрофильных команд. Фиксированное время итерации может не подходить для некоторых проблем (особенно тех, которые возникают ежедневно) Некоторые члены команды могут быть недостаточно задействованы в определенных циклах спринта.	Практики должны выяснить, как лучше всего применять самые гибкие ценности и принципы Широкое разнообразие практик может затруднить определение приоритетов инициатив и координацию между командами. Когда инициативы не увенчаются успехом, бывает сложно определить, выбрали ли команды неправильные инструменты или использовали правильные инструменты неправильным образом.	Новичков, пытающихся изменить поведение, может разочаровывать отсутствие предписывающих методологий. Эволюционные улучшения могут снизить вероятность радикальных прорывов, а крупные улучшения — менее быстрыми. Лидерам необходимо, чтобы постоянное устранение отходов было вдохновляющим и увлекательным занятием.
Источник Даррелл К.Ригби, Джефф Сазерленд и Хиротака Такеучи Из «Охват гибкости», апрель 2016 г.			© HBR.ORG

Условия	Благоприятный	Неблагоприятный
Рыночная среда	Предпочтения клиентов и варианты решений часто меняются.	Рыночные условия стабильны и предсказуемы.
Привлечение клиентов	Возможны тесное сотрудничество и быстрая обратная связь. По мере продвижения процесса заказчики лучше понимают, чего они хотят.	Требования ясны с самого начала и останутся стабильными. Клиенты недоступны для постоянного сотрудничества.
Инновация Тип	Проблемы сложные, решения неизвестны, а масштабы четко не определены. Технические характеристики продукта могут измениться. Творческий прорыв и время выхода на рынок очень важны. Межфункциональное сотрудничество жизненно важно.	Подобная работа была проделана и раньше, и новаторы считают, что решения понятны.Подробные спецификации и планы работы можно с уверенностью прогнозировать, и их следует придерживаться. Проблемы могут быть решены последовательно в функциональных разрозненных хранилищах.
Модульность работы	Дополнительные разработки имеют ценность, и клиенты могут их использовать. Работу можно разбить на части и проводить в быстрых итеративных циклах. Поздние изменения поддаются контролю.	Клиенты не могут начинать тестирование частей продукта, пока все не будет завершено. Поздние изменения дороги или невозможны.
Влияние промежуточных ошибок	Они дают ценное обучение.	Они могут иметь катастрофические последствия.
Источник Bain & Company Из «Embracing Agile», май 2016 г.		© HBR.ORG

Что такое Agile и подойдет ли он вашей компании

Как объяснить бабушке, что такое Agile за 15 минут с картинками / Хабр

Роли

Пропускная способность

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

Есть только один способ держать список задач под контролем — это слово “нет”

Принятие решений

Владелец ИТ-продукта должен постоянно со всеми общаться

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

Риски

Компромисс между ценностями знания и ценностями для клиента

Компромисс между краткосрочным и долгосрочным мышлением

Делать правильные вещи, делать вещи правильно или делать быстро?

Между ролями в Scrum существует здоровое противостояние

Компромисс между разработкой нового продукта и улучшением старого

График уничтожения историй

Несколько команд

Scrum — что это такое, как это работает и в чем преимущества

Платформа

Артефакты Scrum

Собрания или мероприятия Scrum

Три важнейшие роли, от которых зависит успех применения Scrum

Владелец продукта Scrum

Scrum-мастер

Команда разработчиков Scrum

Scrum, Kanban и agile

За что мы любим Scrum?

AGILE – гибкая система управления проектами

Метод Agile: определение и краткая история

Манифест Agile

Ключевые моменты в применении Agile

Популярные методы управления проектами

Метод Scrum

Метод Kanban

Плюсы и минусы Agile

Внедрение Agile

Заключение

Подать заявку на DIRECTOR — EMEA AGILE/LEAN

Picosun AGILE ALD – решения АСО для фотоники

Фотоника – ключевой рынок для решений Picosun AGILE ALD

R-200 — установка ALD (АСО) Picosun

О компании Picosun

Что Такое Методология Agile и Каким Проектам Она Подходит

Что такое методология Agile?

Онлайн диаграмма Ганта GanttPRO

Agile Technologies

Качество

Стратегия, ориентированная на клиента

Что такое гибкая методология? — Обзор гибкой разработки программного обеспечения и гибких моделей

Ключевые методологии Agile

Scrum

Метод динамической разработки программного обеспечения (DSDM)

Feature Driven Development (FDD)

Канбан-метод

Behavior Driven Development (BDD)

Что такое гибкая методология? Объяснение современной разработки программного обеспечения

До Agile: эпоха водопадной методологии

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

Роли в гибкой методологии

Пользователь

Владелец продукта

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

Scrum, Kanban и другие Agile-фреймворки

Почему гибкая методология лучше

Agile-методология: что это такое, как это работает и почему это важно

Что такое гибкая методология?

4 ценности Agile

12 принципов гибкой разработки

Преимущества Agile

Этапы методологии Agile

1. Концепция

2. Начало

3. Итерация

4. Выпуск

5. Производство

6. Вывод из эксплуатации

Примеры методологии Agile

Scrum

Канбан

Extreme Programming (XP)