Что такое agile простыми словами: Гибкая методология разработки

Содержание

Просто о сложном: agile-разработка / Далее

Что было до аджайла

До гибкой разработки все диджитал и IT-компании создавали продукты целиком. Например, в студию обращался заказчик и говорил, что он хочет сайт. Студия отвечала, что не может начать работу без исчерпывающего технического задания. Заказчик вздыхал, садился за бумагу, писал ТЗ на сто страниц, пытаясь по пути не упустить ничего важного. Команда принимала техзадание, закрывалась у себя в студии, работала 2 месяца и показывала результат. После тестирования и правок сайт запускали.

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

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

Agile Manifesto

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

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

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

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

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

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

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

Как команды работают по аджайлу

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

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

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

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

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

Кое-что еще

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

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

Процесс работы по Scrum: спринты, циклы разработки, standup-митинги

Канбан-доска: карточки перемещаются по колонкам-этапам

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

Какому продукту точно нужен аджайл?

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

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

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

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

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

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

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

Agile и гибкие методологии разработки. Модуль 2

В этом модуле вы:
• узнаете четыре ценности аджайла и проверите, готовы ли вы по ним работать;
• узнаете двенадцать принципов аджайла и посмотрите, как они меняют рабочие ситуации;
• проверите — может, вы уже работаете по аджайлу?

Ценности аджайла

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

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

Теперь вы знаете о четырех ценностях аджайла:

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

Как применять аджайл на практике

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

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

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

Правильный ответ: принцип 6 — лишний.
Это просто цитата из романа «1984» Джорджа Оруэлла.

Какие-то принципы сформулированы непонятно? Тогда давайте разберем их на знакомых вам случаях с работы. Например, представьте, что вы работаете в компании, которая разрабатывает и поддерживает сайты клиентов. Таких компаний в России сотни, у всех клиенты, и очень разные, но все они норовят постоянно менять требования и просят «поиграться со шрифтами и цветами». Работать нужно очень быстро — иначе клиенты уйдут к конкурентам. Давайте посмотрим, как работа в такой компании проходит без аджайла и с ним.

Общение — ключ к успеху. Оно помогает сократить переделки

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

Как это описано в манифесте аджайла:

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

Что это значит

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

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

Результат — это то, чем можно пользоваться. Почему лучше сразу пользоваться, чем ждать, пока доделают?

Что говорит манифест аджайла:

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

Что это значит:

Принцип аджайла — после каждого этапа появляется осязаемый результат. Это может быть прототип сайта, первый набросок дизайна, черновик текста… — в общем, какой-то продукт.
Даже если этот продукт с большими ограничениями и пока далек от совершенства, заказчик все равно может его посмотреть и дать свой отзыв после каждой версии продукта. А может, как в случае с сайтом, сразу же начать пользоваться и извлекать для своего бизнеса пользу.
Простота также важна. Когда заказчик просит сделать онлайн-магазин с блогом, разделом «О компании» и форумом, то, возможно, на первых порах он может обойтись страничкой с формой для заказов и телефоном. Новости можно будет временно публиковать во «ВКонтакте», а общаться с покупателями в WhatsApp.

Менять планы — не страшно. Что делать, если заказчик передумал

Что говорит манифест аджайла:

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

Что это значит:

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

Работа — это что-то новое каждый день. Не знать — не стыдно, стыдно — не хотеть учиться

Что говорит манифест аджайла:

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

Что это значит:

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

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

Что говорит манифест аджайла:

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

Что это значит:

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

Проверьте, насколько хорошо вы усвоили материал:

ПРОВЕРИТЬ СЕБЯ

Scrum и Agile, в чем разница. Скрам и Эджайл для чайников

Автор Елена Трускова На чтение 8 мин. Просмотров 21.3k. Опубликовано 10.05.2017

Комментарий Котиков

Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.

Елена Трускова рассказывает:

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

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

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

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

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

Эджайл

(англ.agile —«проворный, шустрый, сообразительный»)

Концепция гибкости:

Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.

«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?

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

Скрам

(англ. scrum — толкотня в борьбе за мячик в регби)

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

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

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

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

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

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

Команда в скраме

Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.

В каждой команде есть:

участники (в случае IT — разработчики, кто эти семь человек у вас — решите сами)
продакт оунер (product owner, владелец продукта). Его роль: понимать рынок и пользователя, формулировать задачи на языке бизнеса и пользователей, держать в голове осознание того, в каком направлении должны развиваться ценность и польза, придумывать и отбирать задачи для развития продукта. Что-то вроде руководителя продукта (не команды).
скрам мастер (scrum master, скрам-евангелист). Его роль: следить за процессом, наблюдать за внутренней жизнью команды, мотивировать людей, устранять препятствия. Что-то вроде тренера.
Вокруг команды есть пользователи и стейк-холеры (stakeholders, заказчики). К этим людям продакт оунер ходит советоваться.

Устройство спринт

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

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

В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.

Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.

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

Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.

В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.

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

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

Структура спринта

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

Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.

Каждый участник стендапа по очереди отвечает на три вопроса:

что я сделал вчера
что я сделаю сегодня
что меня тормозит

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

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

В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.

«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)

Подпишитесь на рассылку новостей. Никакого спама!

Email*

Scrum, Kanban, PRINCE2 и другие

08 Июл 2016

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

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

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

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

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

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

В этой статье мы рассмотрим:

Классический проектный менеджмент
Agile
Scrum
Lean
Kanban
Six Sigma
PRINCE2

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

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?», а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC), тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1.

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

Краткая история проектного управления

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2.

Изобретённая независимо Королем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Классическое проектное управление

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 3.

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

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

5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5.

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть здесь – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

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

Сильные стороны Agile

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

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

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

Слабые стороны Agile

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

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

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

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

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

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

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

Сильные стороны Scrum

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

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

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

Слабые стороны Scrum

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

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

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

Lean

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

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

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

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

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

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

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

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

Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

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

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

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

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

Специализированных аспектов управления проектом, например, отраслевых;
Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

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

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

Бизнес-аспект (Принесёт ли этот проект выгоду?)
Потребительский аспект (Какой нужен продукт, что мы будем делать?)
Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

Начало проекта (Starting up a project):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
Инициация проекта (Initiation a project):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
Руководство проектом (Directing a project): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
Контроль стадии (Controlling a stage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
Управление созданием продукта (Managing Product Delivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
Управление границами стадии (Managing a stage boundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
Завершение проекта (Closing a project):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

Адаптируемость к особенностям организации;
Наличие чёткого описания ролей и распределения ответственности;
Акцент на продуктах проекта;
Определённые уровни управления;
Фокус на экономической целесообразности;
Последовательность проектной работы;
Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

Отсутствие отраслевых практик;
Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

Управление проектами – это наука, но наука не самая точная. В данной области нет незыблемых основ и универсальных решений. Если вам удастся найти метод, идеально подходящий вашему проекту – считайте, что вам крупно повезло, ведь большинству менее удачливых руководителей приходится прикладывать усилия для создания и настройки собственных систем управления проектами. Эти системы могут быть составлены из элементов существующих систем или даже созданы совершенно с нуля, как в случае с миссией «Аполлон». Главное используйте что-нибудь, что даст вам хоть какую-то структуру и позволит не забыть о том, что главное для вашего проекта.

Как получить международный сертификат по Agile?

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «ICAgile Certified Professional»

Смотрите также:

Источник: https://zapier.com/learn/ultimate-guide-to-project-management/project-management-systems/

Agile — гибкая методология разработки

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

Что представляет собой Agile?

Agile — это ускоряющая методология создания проектов. Она минимизирует риски посредством коротких (2 – 3 недели)циклов, или итераций, разработки.

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

проектирование;
анализ требований;
кодирование;
тестирование;
документирование.

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

Методы Agile

Методы Agile — это такие гибкие методологии, как Lean Development («Бережливая разработка ПО»), Scrum и др. Они были разработаны еще в начале 2000-х как альтернатива малоэффективным традиционным IT методам.

Практически все аgile-команды сконцентрированы в одном офисе (bullpen). Офис включает product owner – заказчика, который и определяет требования к продукту. В качестве заказчика может выступать бизнес-аналитик, менеджер проекта или клиент. Кроме того, в офис могут входить и дизайнеры интерфейса, тестировщики, технические писатели. То есть методы Agile направлены в первую очередь на непосредственное общение.

Принципы Agile

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

Главные преимущества Agile

Качество web-продукта

Вовлечение заказчика в процесс каждой итерации дает возможность корректировать процесс, что неизменно повышает качество.

Высокая скорость разработки

Итерация длится не более 3-х недель, к концу этого срока обязательно есть результат.

Минимизация рисков

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

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

Прозрачность оплаты

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

Что такое Agile? 1 часть

Николай Борисов, руководитель направления Дирекции по процессам, «Альфа-Банк»:

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

И сегодня у нас в гостях Асхат Уразбаев, руководитель компании ScrumTrek, один из ее основателей.

Приветствую, Асхат.

Асхат Уразбаев, генеральный директор ScrumTrek:

— Доброе утро.

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

— Давайте для начала немножко предыстории.

Agile начался относительно давно. Само слово, термин такой появился в 2001 году, и возник он в IT-индустрии. В 2001 году методологи собрались, и многих их них вы, может быть, знаете, то есть методы, которые тогда придумали – Scrum, например, Future-driven Development, Lean Software Development. Вот они собрались вместе и сформулировали то общее, что у них было.

— Что вообще означает сам термин Agile? Что это?

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

— То есть точного определения не существует, так, получается?

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

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

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

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

Читайте также: Роль Agile в современном мире

— Вы говорите о том, что можно сократить время выполнения каких-то задач в разы. Правильно?

— В разы, да. Обычно мы получаем средне (очень средне, где-то сильно быстрее, где-то не так сильно) это 2,5-3 раза. Ощущение такое.

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

— Это не магия, конечно. Это некоторый такой разворот модели управления. В классической модели управления, если взять какую-нибудь не IT-область… Чтобы было более понятно, давайте возьмем продажу чего-нибудь крупного. Танки вы продаете или самолеты, или консалтинг. HR-консалтинг, например.

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

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

— Специалист в своей области.

— Вручную идет и пытается все это… Специалист в своей области. Если мы формируем команду, они могут действовать совместно. То есть там, где нужно, например, поговорить с клиентом на какую-то тему, едет один специалист. Там, где нужно для него подготовить презентацию, может подготовить другой специалист. Небольшая команда из 3-4 человек, которые координируют свою работу каждый день, раздавая друг другу, по сути, задачи каждый день, может работу сделать в разы быстрее.

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

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

— То есть по специальности, получается?

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

— Как заставить их помогать друг другу? У них же разные цели. Они специалисты в своей области, и всю жизнь росли и развивались в этой области. То есть юрист повышал свою квалификацию, он классный, здоровский специалист. Что его заставит ехать, продавать что-то, условно, выступать в роли sales какого-то?

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

— Почему нельзя, да?

— То есть, как ни странно, повышение квалификации приводит к тому, что можно найти больше рисков. На самом деле, вопрос, который мы бы хотели задать юристу – не почему это невозможно, а как это сделать. Нельзя вам выдавать, я не знаю, кредиты без аутентификации больше 15 тысяч. Да, это невозможно по закону. И вам объяснят тысячу раз, почему это невозможно. Задайте вопрос, как этого добиться. «А я хочу».

— То есть нарушить закон?

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

Продолжение следует!..

При использовании материала гиперссылка на соответствующую страницу портала HR-tv.ru обязательна

Agile & Scrum: реализация за 10 шагов

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

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

+ Что такое Agile-управление проектами?

+ 12 принципов гибкого управления проектами

+ Зачем использовать гибкое управление проектами?

+ Что такое Scrum?

+ 10 простых шагов к Agile-управлению проектами с помощью Scrum + Бесплатные шаблоны

+ Как наша команда R&D реализует Scrum

+ Кто может получить выгоду от работы с Agile-управлением проектами?

+ Расскажите подробнее.Больше!

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

В 2001 году 17 разработчиков программного обеспечения собрались на курорте Snowbird в Юте, чтобы кататься на лыжах, пить горячее какао и болтать о том, как избавиться от жестких ограничений традиционной разработки программного обеспечения. Джефф Сазерленд, который теперь считается крестным отцом Agile-управления проектами, и его приятели вместе написали ставший уже легендарным Манифест для гибкой разработки программного обеспечения . Хотя жаргон гибкого управления проектами может показаться устрашающим, вам не нужно быть разработчиком программного обеспечения, чтобы легко понять, что это такое.

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

Давайте вернемся на секунду и посмотрим, как Merriam-Webster определяет слово «гибкий».

1. Отличается готовностью двигаться быстро и легко. Например: «Как ловкий павлин! Как цыпленок с обезьяньей мордой … летаю! » — Герцог Везелтон, Холодное сердце

2. Обладающий быстрым, находчивым и легко приспосабливаемым характером. Например: «На самом деле, в выигрыше нет ничего.То есть, если вам посчастливилось быть наделенным острым глазом, подвижным умом и вообще без угрызений совести ». — Альфред Хичкок (Примечание: как вы произносите как agile? Самые достойные британцы говорят «aj-aisle», но многие свободолюбивые американцы говорят «aj-il»).

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

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

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

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

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

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

Узнайте, как monday.com может помочь вам внедрить гибкое управление проектами

Зачем использовать гибкое управление проектами?

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

75% очень гибких организаций достигли своих целей и бизнес-намерений
65% завершили проекты в срок
67% завершили проекты в рамках бюджета

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

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

Другие преимущества гибкого управления проектами включают:

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

Попробуйте наш шаблон гибкого планирования!

Что такое гибкое управление проектами с помощью Scrum?

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

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

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

What Is Agile

Agile, альтернатива традиционному жизненному циклу разработки программного обеспечения «водопад», по-прежнему является модным словом в мире ИТ.Но истории Agile как минимум два десятилетия! Классическая каскадная модель руководила разработкой программного обеспечения в течение нескольких десятилетий с ее последовательными фазами требований, проектирования, кодирования, тестирования и выпуска. Коммуникация между командой проекта и заказчиком будет плотной на этапе требований и выпуска и тонкой на средних этапах. Типичный цикл выпуска будет длиннее; от 1-2 лет. Заказчик, представив требования, с нетерпением ждал релиза, чтобы увидеть продукт, и часто разочаровывался в продукте, и это также было трудным для бизнес-планов.Еще одна серьезная проблема, затрагивающая клиентов и бизнес-сообщество, — это изменение противоположного характера модели водопада; это препятствует адаптации к динамическим изменениям в технологии gy , пользовательских предпочтениях и рынке для получения преимуществ для бизнеса.

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

Альянс Agile сформировал agile-манифест, отражающий свою философию, и на его основе разработал двенадцать принципов4.Простой манифест Agile гласит:

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

Отдельные лица и взаимодействия свыше Процессы и инструменты

Рабочее ПО сверх Подробная документация

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

Реагирование на изменение вместо следования плану

То есть, хотя предметы справа имеют ценность, мы ценим предметы слева больше.

Первоначальные гибкие методы включают Scrum, Extreme Programming (XP), Feature Driven Development (FDD), Dynamic System Driven Development (DSDM) и Crystal . Канбан-разработка и экономичная разработка программного обеспечения были добавлены к гибкой разработке в недавнем прошлом. Несмотря на то, что существует несколько гибких методов, два самых популярных метода — это Scrum и XP. Сильной стороной Scrum является его простая структура процессов, тогда как XP черпает свою силу в превосходных методах разработки программного обеспечения.Многие из сегодняшних гибких адаптаций являются гибридными, основанными на сильных сторонах Scrum & XP.

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

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

Agile-методы являются благом для клиентов и бизнес-сообщества, предлагая

Более быстрое время выхода на рынок (TTM) и выше Рентабельность инвестиций (RoI) небольшими выпусками каждые 3-6 месяцев
Позволяет клиентам динамически формировать продукт, используя обработку отставания по продукту и обратную связь на каждой итерации демонстрации.

Так что неудивительно, почему Agile все еще остается в моде в ИТ-индустрии.

Автор: SrinivasanVenkatachalam

Глоссарий Agile и Scrum | SCRUMstudy

Критерии приемки	Характеристики продукта, указанные владельцем продукта, которые должны быть удовлетворены, прежде чем они будут приняты пользователем, покупателем или другим уполномоченным лицом. Они используются в качестве стандартов для измерения и сравнения характеристик конечного продукта с заданными характеристиками.
Приемочные испытания	Эти тесты проводятся с точки зрения бизнеса и клиента. Эти тесты проверяют запрошенную и реализованную функцию и определяют, соответствуют ли эти функции требованиям бизнеса и клиентов
Разработка на основе приемочных испытаний (ATTD)	Метод разработки системы или продукта, в котором критерии приемки подробно обсуждаются участниками с использованием примеров и хорошо спланированных приемочных испытаний на основе этих критериев перед началом разработки.
Точность	Степень, на которую измеренное значение очень близко к истинному значению (PMI).
Приобретение проектной группы	Это процесс подтверждения и обеспечения команды, необходимой для завершения проекта. Навыки, опыт и доступность ресурсов — важные параметры, которые необходимо учитывать при подборе проектной команды.
Адаптивность	Желательная характеристика человека, группы, процесса или системы, измеряемая в способности / способности адаптироваться или приспосабливаться.В организационном контексте это относится к способности изменить что-то или себя в соответствии с происходящими изменениями.
Адаптация	Модификация продукта, разрабатываемого или находящегося в процессе разработки. Различия в фактическом и истинном значениях вызывают необходимость контроля и модификации продукта или процесса.
Адаптивное планирование	Гибкие методологии сокращают отходы за счет сокращения объема работы, не приносящей добавленной стоимости.Планирование проекта напрямую не увеличивает бизнес-ценность. Поэтому планирование на любом этапе проекта Scrum должно быть максимально эффективным. Заблаговременное планирование всего проекта считается бесполезным, потому что Agile-проекты подвержены высокому уровню изменений. Следовательно, планирование выполняется точно в срок (JIT).
Адаптивное управление проектами	Адаптивное управление проектами — это структурированный итеративный процесс управления, в котором упор делается на меньшее предварительное планирование, в отличие от методов водопада.Это создает довольно адаптируемую среду для команд, где они сосредотачиваются только на текущих задачах, выполняют их, а затем переходят к следующим задачам. Если есть какие-либо изменения в требованиях, они включаются в следующий Спринт. Это гарантирует, что вы будете идти в ногу с быстро меняющимся рыночным и технологическим сценарием, что позволит вам в кратчайшие сроки предоставить клиентам максимальную выгоду.
Дополнительное планирование реагирования на риски	Это делается для того, чтобы позаботиться о рисках, которые не были изначально идентифицированы, или когда влияние риска на цели больше, чем ожидалось.Существующего планирования реагирования на риски может быть недостаточно для управления риском.
Гибкий	Agile — это группа итеративных и инкрементных методов разработки программного обеспечения. Это способствует гибкости и скорости реагирования на изменения. Это требует сотрудничества между самоорганизованными кросс-функциональными командами для выработки требований и решений.
Гибкий унифицированный процесс	Agile Unified Process (AUP) — это усовершенствованный вариант «IBM Rational Unified Process (RUP)», впервые описанный Крейгом Ларманом в 2001 году.Для выбора элементов из RUP используются гибкие концепции и методы. Итерации подразделяются на два типа: разработка и выпуск.
Все до любых	Последовательный процесс разработки, в котором выходные данные предыдущего шага используются в качестве входных данных для следующего шага процесса с размером пакета 100%.
Подход	Используемый метод или предпринятые шаги для постановки задачи или проблемы командой Scrum.Подход отличается от команды к команде.
Артефакт	Любой конкретный побочный продукт, образующийся в процессе разработки. Примеры артефактов включают в себя бэклог продукта и бэклог спринта.
Допущения	Факторы, которые для целей планирования считаются истинными, реальными или достоверными.
Анализ предположений	Упражнение по управлению проектом, которое исследует обоснованность допущений, сделанных в начале проекта, для определения любого потенциального риска проекта, задуманного и разработанного из-за неточности любого предположения.Он также определяет риски, связанные с любой нестабильностью, непоследовательностью или неполнотой предположений.
Базовый унифицированный процесс (BUP)	BUP — это более простой вариант Rational Unified Process (RUP), разработанный в 2005 году. Он был оптимизирован для небольших проектов IBM.
Разработка, управляемая поведением	Разработка, управляемая поведением (или BDD) — это процесс разработки программного обеспечения, который включает сотрудничество между нетехническими или бизнес-участниками и людьми с техническими знаниями, такими как разработчики, QA и т. Д.
Мозговой штурм	Групповая деятельность или творческий подход, который можно использовать для генерирования и анализа идей или для выявления проблем, рисков или даже для определения решений проблем.
График сжигания	Графическое представление объема выполненной / выполненной работы за истекший период времени. Он используется для оценки времени, необходимого для завершения проекта.Вертикальная ось представляет запланированную работу, а горизонтальная рабочая ось представляет время. Общая тенденция на графике — «выгорать» до точки, когда не остается никакой работы.
График выгорания	Графическое представление объема выполненной работы по сравнению с запланированным за определенный период времени. Графическая линия тренда движется вверх к линии цели, поэтому называется «выгорать» в отличие от «выгорать». Он используется для оценки времени, необходимого для завершения проекта.
Отношения между продавцом и покупателем	В среде коммерческого проекта продавцом может быть любое лицо (субподрядчик, продавец или поставщик), которое управляет работой проекта или поставляет продукт проекта, а покупатель — это покупатель, который передает работу продавцу на аутсорсинг.
Каденция	Cadence — это подход к достижению приверженности и надежности системы.Это мера баланса и ритмичного хода процесса. Спринты с регулярным интервалом времени или продолжительностью задают ритм для усилий по развитию.
Интеграция модели зрелости возможностей (CMMI)	CMMI — это набор продуктов для улучшения процессов. Он был разработан в рамках проекта CMMI как совместная работа представителей промышленности, правительства и академических кругов, объединившая передовой опыт разработки программного обеспечения. Это очень эффективно для проектов, включающих определенные процессы.
Вместимость	Емкость определяется объемом работы, который может быть выполнен с использованием доступных ресурсов.
Церемония	Официальный акт или набор действий, выполняемых в соответствии с предписаниями ритуала или обычая. Основные действия Scrum, такие как весеннее планирование, ежедневный scrum, обзор спринта и ретроспектива спринта, называются командой Scrum церемонией.
Хаотическая область	Состояние кризиса, которое необходимо немедленно устранить, чтобы предотвратить дальнейший ущерб или убытки и восстановить порядок. Это требует быстрого ответа.
Куры и свиньи	Басня, используемая в Agile Project Management для определения типа роли, которую участник может играть в Scrum. Это происходит из басни о цыпленке и свинье, которые планировали вместе открыть ресторан.Они оба задействованы, но совершены только свиньи. Свиньи должны завершить проект в соответствии с требованиями.
Главный владелец продукта	Лицо, ответственное за общий бэклог продукта в разработке продукта с несколькими командами Scrum.
Проект комплексной системы компенсации Chrysler (C3)	C3 был проектом по созданию единой системы расчета заработной платы для всех в Chrysler.Этот проект продолжался с 1993 года до тех пор, пока DaimlerChrysler (после того, как Chrysler был выкуплен) не остановил проект C3 1 февраля 2000 года. В ходе этого проекта было разработано множество методов Agile-разработки; главным из них было экстремальное программирование (XP).
Рефакторинг кода	Метод, используемый при разработке программного обеспечения для реструктуризации / перепроектирования существующей части кода без изменения его поведения. Целью рефакторинга является улучшение нефункциональных атрибутов программного обеспечения, например.g., управление техническим долгом или ускорение программирования.
Собрать требования	Процесс определения и документирования потребностей заинтересованных сторон для достижения целей проекта.
Коллективная ответственность	В среде проекта Scrum вся команда несет коллективную ответственность за своевременное выполнение согласованной работы для спринта.
Обязательства	Обязательство означает сознательный выбор что-то делать. Связать или взять на себя обязательство перед причиной, лицом или действием посредством залога или заверения.
Коммуникационные технологии	Технологии или методы передачи информации между участниками проекта.
Комплексная адаптивная система	Многочисленные объекты, управляемые общими простыми локализованными правилами, которые взаимодействуют друг с другом различными способами и получают постоянную обратную связь.
Комплексный домен	Область в структуре Cynefin, в которой ситуация непредсказуема, а правильность ответа известна только задним числом.
Команда компонентов	Команды компонентов — это специализированные группы, организованные вокруг архитектуры разрабатываемого продукта. Команда, которая фокусируется на создании одного или нескольких компонентов более крупного продукта, который покупатель мог бы купить.Команды компонентов создают активы или компоненты, которые затем повторно используются другими командами для сборки ценных для клиентов решений.
Условия удовлетворения	Условия удовлетворения — это критерии приемки, определенные владельцем продукта, которые определяют желаемое поведение продукта, который должен быть принят. Это условия, при которых владелец продукта удовлетворен результатом каждого элемента бэклога продукта.
Непрерывная доставка	Доставка продукта или каждой функции продукта пользователям сразу после их интеграции и тестирования разработчиком.
Непрерывное развертывание	Доставка продукта или каждой функции продукта пользователям сразу после их интеграции и тестирования разработчиком.
Непрерывное совершенствование	В большинстве традиционных проектов извлеченные уроки собираются в конце проекта, чтобы их можно было применить в будущих проектах.Однако применение уроков к будущим проектам не добавляет ценности текущему проекту. Будущие проекты могут не быть похожи на прошлые. Поэтому Agile стремится постоянно учиться в ходе каждого проекта и применять полученные уроки в рамках текущего проекта. Несколько инструментов, методов, наборов знаний и навыков могут постоянно улучшать Agile-проекты — например, ретроспективные встречи, обмен знаниями и т. д.
Стоимость задержки	Денежные убытки, понесенные из-за задержки работы, процесса или достижения производственных целей.Эта концепция подчеркивает, что время, связанное с проектом, имеет финансовые затраты.
Межфункциональная группа	Команда проекта, имеющая опыт в различных областях, например дизайнеры, разработчики и тестировщики, обладающие навыками, необходимыми для эффективного и результативного выполнения работы.
Кристалл	Семейство методологий Crystal было разработано Алистером Кокберном в середине 1990-х годов.Методологии названы в честь цветов и / или драгоценных камней, чтобы указать «вес» необходимой методологии (в соответствии с атрибутами команды или стратегическими потребностями). Самая известная из них также самая легкая, называемая «Crystal Clear», используемая для небольших команд, члены которых работают вместе над некритическими задачами. Семья делает акцент на эффективности и пригодности для проживания как на составляющих безопасности проекта.
Daily Stand-Up	Ежедневное встречное собрание или собрание Scrum — это ежедневное собрание команды в рамках Scrum Framework.Название происходит от практики, когда участники вставали. Это побуждает участников делать собрание коротким. Это дает команде регулярную возможность отслеживать прогресс по плану спринта.
Определенный процесс	Четко определенный процесс, который каждый раз производит один и тот же результат для одного и того же входа (за вычетом незначительных изменений в пределах диапазона). В таком процессе четко указаны входы, выходы и этапы.
Управление определенным процессом	Подход к управлению процессом, используемый для определенных процессов. Эта модель в первую очередь включает создание и поддержку процессов, дающих ожидаемый результат.
Определение готовности	Условия, которым должен удовлетворять элемент невыполненной работы продукта, прежде чем он будет сочтен готовым к включению в спринт во время планирования спринта.
Метод Delphi	Метод Дельфи — это метод оценки / опроса, при котором оценки и мнения анонимно собираются группой. Это снижает предвзятость, которая может возникнуть из-за власти / влияния определенных членов комиссии.
Команда разработчиков	Команда разработчиков сформирована из членов из разных областей функционального опыта.Он должен быть самоорганизованным и стремиться к единой цели. Эта команда несет коллективную ответственность за разработку приемлемого продукта.
Домен расстройства	Это один из доменов в структуре Cynefin. Это опасный этап, и приоритет должен заключаться в выходе из этой области, потому что мы либо не понимаем, либо не можем понять ситуацию, в которой находимся.
Точечное голосование	Этот метод используется для определения элементов с более высоким приоритетом.Участники должны отдать свой голос, поставив цветную точку напротив одного предмета из списка, и предмет с наибольшим количеством точек считается предметом с более высоким приоритетом. Этот прием часто используется во время ретроспективы спринта.
Экономичный фильтр	Экономический фильтр используется организацией в качестве критерия принятия решения для оценки экономических выгод от рассматриваемого проекта и необходимости его финансирования.
Эмпирическое управление процессами	Подход к управлению процессом, используемый, когда процессы определены не полностью, а выходные данные уникальны. В этой модели используются частые проверки, адаптация и прозрачность. Scrum обеспечивает эмпирический контроль процессов для управления проектами.
Конечная неопределенность	Конечная неопределенность — это неопределенность, окружающая свойства конечного результата проекта или процесса.
Эпический	Эпик — это большая пользовательская история, обычно слишком большая, чтобы уместиться в одном спринте. Эпики должны быть разбиты на более мелкие пользовательские истории на определенном этапе до реализации в рамках спринта.
Основной унифицированный процесс	Гибкий метод, полученный из Rational Unified Process (RUP), Capability Maturity Model Integration (CMMI) и Agile-процессов.Используемый в основном для разработки программного обеспечения, он был разработан Иваром Якобсоном, одним из первых участников RUP, как усовершенствование Rational Unified Process. Он ориентирован на практику, а не на процессы / роли. Он основан на разделении проблем, принципе разделения продукта на отдельные разделы, каждый из которых посвящен отдельной проблеме.
Оценка	Приблизительный расчет количества, количества или размера элементов невыполненной работы продукта, элемента невыполненной работы портфеля и задачи невыполненной работы спринта.
Хронология событий	Техника, используемая во время ретроспективы спринта, которая включает хронологическое описание событий, которые произошли за определенный период времени.
Экспертное заключение	Заключение эксперта (ов) в конкретной области по вопросам или деятельности, осуществляемой в этой области. Эксперт может быть человеком или группой со специальной подготовкой или образованием, знаниями и навыками.Опыт также можно было приобрести со временем и опытом.
Прогнозирование	Оценка или прогнозирование будущего статуса и хода проекта на основе знаний и информации, доступных на момент прогнозирования.
Функциональный тест	Функциональное тестирование обычно описывает, что делает система. Здесь функции проверяются путем подачи ввода и изучения вывода.Это тип «тестирования черного ящика», при котором мы не рассматриваем внутреннюю структуру программы и в основном сравниваем фактические и ожидаемые результаты.
Генчи Генбуцу	По-японски это означает «пойдите и убедитесь сами». Это убеждение, что опыт в реальном времени более полезен, чем теория. Чтобы понять проблему, нужно видеть проблему, а не слышать о проблеме от кого-то другого. Это поможет принять осознанное решение о решении.
Методы принятия решений в группе	Используется для генерации, классификации и определения приоритетов требований к продукции. Некоторые методы, используемые для достижения групповых решений: единогласие, большинство, множественность и диктатура.
Препятствие	Фактор, который препятствует эффективному выполнению схватки в команде или организации.
Протокол препятствий	Журнал препятствий регистрирует или регистрирует препятствия, описание препятствий, влияние препятствий, решение, если таковое имеется, и статус препятствий. Формат может отличаться. Скрам-мастеру рекомендуется обновлять журнал после каждого ежедневного выступления.
Дополнительное финансирование	Финансирование части разработки продукта без обязательств по его финансированию.При дополнительном финансировании финансируется только малая часть усилий по развитию, после чего решение о финансировании критически оценивается, чтобы увидеть, сколько платят, чтобы получить от этой небольшой части.
Информационный радиатор	Визуальный дисплей, который представляет прохожим достаточно подробную, актуальную и важную информацию в удобном для понимания формате.
Учет инноваций	Математически сложный процесс определения, измерения и сообщения об улучшениях в инновациях.Эта структура пытается определить причины различий в инновационной продукции между командами в разные периоды времени. Обычно используется в качестве метрики для измерения прогресса стартапов.
Отходы инноваций	Упущенная возможность создать инновационное решение. Обычно возникает, когда предписанное решение предоставляется с элементом невыполненной работы по продукту.
Интеграция	Комбинация различных компонентов продукта для формирования связного, более масштабного рабочего продукта, который можно проверить на правильность функционирования в целом.
Внутренние заинтересованные стороны	Заинтересованные стороны, которые являются внутренними по отношению к организации, то есть те, кто участвует в разработке продукции. Например, руководители высшего звена, менеджеры и внутренние пользователи.
Интервью	Официальный или неформальный подход к получению информации от заинтересованных сторон путем прямого разговора с ними
Итерационная разработка продукта	При итеративной разработке продукта конечный продукт разрабатывается в несколько итераций и доставляется заказчику.
Канбан	Этот термин в переводе с японского означает «вывеска». Тайити Оно адаптировал слово, используемое для обозначения вывески магазинов, чтобы изобразить следующую философию: процесс спуска пара должен идти и приносить то, что ему нужно — аналогично тому, как мы идем и получаем то, что нам нужно, из магазина / магазина.
Модель Кано	Названный в честь Нориаки Кано, японский профессор Кано Модель используется для сопоставления того, что ценит покупатель, путем классификации атрибутов продукта на основные, производительные и привлекательные категории.Его можно использовать для определения минимально жизнеспособного продукта, который, по мнению клиента, удовлетворяет его или ее основным требованиям.
Известный технический долг	Категория статуса для технического долга, представляющая долг, который известен команде разработчиков и стал видимым для дальнейшего рассмотрения. В отличие от «возникшего технического долга» и «целевого технического долга». См. Также «технический долг».
Постное	Бережливое производство или просто Бережливое производство фокусируется на удалении отходов производства.Это практика предоставления большей или той же ценности с меньшими ресурсами за счет устранения потерь в организациях и бизнес-процессах. Lean рассматривает элемент или деятельность как «отходы», если они используются не для создания ценности для клиентов.
Бережливая разработка продукта (LPD)	LPD — это применение принципов бережливого производства при разработке продуктов. Это один из первых методов Agile.
Прибыль за жизненный цикл	1.Общая потенциальная прибыль продукта в течение его срока службы. 2. Общая потенциальная прибыль всего портфеля, а не одного продукта.
Означает неопределенность	Означает неопределенность — это неопределенность в отношении средств, с помощью которых будет создан результат.
Минимальные товарные характеристики (MMF)	Наименьший или минимальный набор функциональных возможностей, связанных с функцией, которая должна быть предоставлена для того, чтобы покупатель воспринял ценность (чтобы она была востребованной).Сравните с «минимальным количеством доступных функций».
Минимальный жизнеспособный продукт (MVP)	Продукт только с теми минимальными функциями, которые позволяют его развертывать, и не более того. Обычно MVP — это результат первого спринта.
MoSCoW	Метод, используемый для категоризации важности различных атрибутов в продукте с точки зрения Заказчика, чтобы позволить команде разработчиков придавать значение выполнению каждого требования.Это учение полезно при определении «критериев приемлемости» продукта путем определения требований «должен иметь, должен иметь, мог иметь и не иметь».
Муда	Это японский термин, обозначающий любую бесполезную расточительную деятельность. Муда — важный фактор в Канбане. Чтобы вести бизнес, организация должна производить товары или предоставлять услуги, которые покупатель может покупать или оплачивать. Для этого нужен процесс, и этот процесс использует ресурсы.Фактор потерь проявляется, когда ресурсы потребляются без надобности. Канбан-подход повышает осведомленность о расточительном потреблении ресурсов и помогает выявлять потери и неиспользованные перспективы и возможности.
Мура	На японском языке этот термин означает неравномерность или несоответствие физического или духовного состояния человека. В канбане Mura сокращается за счет оснащения процесса точной частью, в точное время и в точном количестве.
Мури	Это японское слово используется для обозначения чрезмерной нагрузки, необоснованности или абсурда. Канбан избегает Мури благодаря стандартизированной работе. Во-первых, стандартный вывод определяется так, чтобы можно было эффективно оценить качество. Затем элементы в каждом процессе упрощаются для изучения и рекомбинации. Затем процесс стандартизируется для получения стандартного состояния.
Необходимые функции	Набор функций, которые должны присутствовать в предстоящем выпуске, чтобы выпуск был жизнеспособным.
Полезные функции	Это функции, которые «было бы неплохо иметь» в следующем выпуске, но их можно не учитывать, если для завершения проекта не хватает средств.
Объективное определение	Определение цели является частью собрания по планированию спринта, на котором владелец продукта объясняет приоритетные элементы в бэклоге продукта, а команда обязуется выполнить элементы бэклога продукта, которые должны быть выполнены во время спринта.
Открытый унифицированный процесс	Платформа процессов с открытым исходным кодом, разработанная Eclipse Foundation на основе Basic Unified Process (BUP) IBM. Основные принципы: итеративный жизненный цикл, совместная работа, управление требованиями и знание архитектуры.
Организационная схема	Диаграммы, которые используются для отображения позиций и отношений в графическом формате.
Парное программирование	Парное программирование — это метод программирования, при котором два программиста работают вместе над одной системой. Эта практика существует с 1950-х годов. Многие исследования показали, что парные программисты более чем в два раза эффективнее; в производстве кода и особенно в свободе от ошибок, чем один программист в одной системе.
Планирование управления рисками	Процесс определения того, как проводить действия по управлению рисками для проекта.
Планирование покера	Практика оценки Agile, которая является разновидностью широкополосного метода оценки на основе консенсуса Delphi. Он используется для оценки усилий или относительного размера пользовательских историй путем присвоения каждой пользовательской истории баллов. Этот метод также можно использовать для встреч, на которых команда оценивает риск в различных модулях.
Инфляция пунктов	Прискорбный феномен завышения значения оценок размера отставания по продукту в попытке согласовать или оптимизировать неразумно задуманную меру (например, достижение целевой скорости).
Задание портфеля	Самый высокий уровень отставания в Agile framework; он состоит из продуктов, программ, проектов или эпических произведений высокого уровня. См. Также «планирование портфеля».
Практика	Сеансы, запланированные для репетиций и повышения производительности, называются практическими. Например, принцип демонстрации прогресса поддерживается практикой Scrum обзора спринта.
Прецизионный	Степень, в которой значения повторных измерений сгруппированы и имеют небольшой разброс [PMI].
Профилактика и проверки	Предотвращение — это деятельность, которая может снизить вероятность негативных последствий, связанных с рисками проекта, в то время как меры инспекции для проверки соответствия деятельности, компонента, продукта или услуги установленным требованиям.Стоимость предотвращения ошибок намного меньше стоимости исправления ошибок, обнаруженных во время проверки.
Принцип наименьшего удивления	Действовать или разрабатывать рабочие продукты таким образом, чтобы меньше всего удивлять пользователей.
Приоритизация	Процесс упорядочивания списка в соответствии с заданным атрибутом.
Приоритетная доставка	Scrum верит в то, что можно доставить наибольшую ценность за минимальное время.Это требует приоритетной доставки, в которой «что будет сделано» должно быть выбрано из «того, что должно быть сделано» в соответствии с ценностью бизнеса.
Ожидание продукта	Приоритетный список работ, которые необходимо выполнить в проекте. В рамках Scrum это развивается с потребностями бизнеса и окружающей средой.
Уход за продуктом	Фильтрация задач в отставании продукта на основе их важности в соответствии с критериями, установленными владельцем продукта.
Элемент невыполненной работы продукта (PBI)	Элемент, такой как функция или преимущество, который имеет значение для процесса разработки продукта.
Описание продукта	Документирует характеристики продукта или результатов, для создания которых предпринимается проект.
Усилия по разработке продукта	Полный объем усилий, приложенных для создания или улучшения продукта или услуги.
Владелец продукта	Руководитель группы разработки продукта. Голос сообщества стейкхолдеров перед командой scrum. Владелец продукта определяет, что делать и в каком порядке
Прокси-сервер владельца продукта	Лицо, уполномоченное владельцем продукта действовать от его имени в определенных ситуациях. См. Также «product owner».
Дорожная карта продукта	Дорожная карта продукта — это план высокого уровня, который показывает, когда в будущем ожидается разработка или внедрение новой продукции организацией / командой.Запросы на редактирование дорожной карты (обычно путем добавления новых продуктов) поступают от отдела продаж или высшего руководства компании при разработке маркетинговой стратегии.
Объем продукта	Функции или услуги, характеризующие продукт, результат или услугу
Видение продукта	Заявление, описывающее желаемое будущее состояние, которое будет достигнуто путем разработки и развертывания продукта.Хорошее видение продукта — это простое, легкое для понимания заявление и последовательное руководство для людей, которых просят его реализовать.
Прогрессивное уточнение	Организованное разбиение больших слегка детализированных элементов бэклога продукта на набор более мелких и более подробных элементов.
Фрахтование проекта	Набор предварительных работ, необходимых для определения проекта с определенным уровнем детализации, чтобы можно было принять решение о финансировании.
Завершение проекта	Процессы и процедуры, разработанные для закрытия или отмены проектов.
Записи проекта	Это может включать переписку, служебные записки, протоколы встреч и документы с описанием проекта.
Качество	Степень, в которой набор присущих характеристик удовлетворяет требованиям (соответствует назначению).
Показатели качества	Описывает конкретными терминами атрибут проекта или продукта и то, как он измеряется в процессе контроля качества.
Очередь	Термин адаптирован из Lean Manufacturing. Инвентаризация элементов, ожидающих следующего действия в рабочем потоке.
Быстрая разработка приложений	Процесс разработки программного обеспечения, впервые названный и представленный в 1991 году.Он ставит во главу угла ускоренную разработку и упрощение обслуживания приложений, а не функциональность и производительность.
Рациональный унифицированный процесс	Это комбинация моделей разработки программного обеспечения, созданных в 1996 году в Rational Software Corporation. Это структура процесса; где отдельные строительные блоки можно было выбрать и адаптировать к текущему проекту. Он был направлен на то, чтобы продемонстрировать преимущества как водопадных моделей, так и моделей быстрой разработки приложений.
Практика найма	Политика, руководящие принципы или процедуры, регулирующие набор персонала.
Планирование выпуска	Термин, заимствованный из Lean Manufacturing. Функция планирования выпуска — синхронизировать прогнозируемый диапазон возможных дат поставки в будущем с задачами, которые нужно выполнить сегодня.
Поезд выпуска	Метод планирования выпуска продукции на регулярный или циклический период времени.Компания Cisco, известная своей программной платформой IOS, затем разбивается на несколько проектов для нескольких продуктов.
Избежание рисков	Одна из запланированных мер реагирования на риск, в которой мы пытаемся полностью избежать риска, изменяя некоторые аспекты проекта.
Роль	Четко определенный набор обязанностей, которые могут выполняться одним или несколькими людьми и за которые они несут ответственность.Три роли Scrum — это владелец продукта, мастер Scrum и команда разработчиков.
Правило	Обычная практика или общепринятый метод действий в конкретной ситуации. Правило может быть нарушено, когда необходимость ситуации диктует необходимость отклонения от нормального образа действий. Структура Scrum включает правила.
Скрам	Методология, первоначально усовершенствованная в 1995 году Кеном Швабером и Джеффом Сазерлендом на основе работы Хиротаки Такеучи и Икуджиро Нонака.Названный в честь SCRUM в регби, это самая известная среда Agile. Это итеративная методология, при которой основные этапы разработки рассматриваются как контролируемый черный ящик. Итерации, называемые спринтами, используются для разработки продукта, который готов к выпуску после каждого спринта [Швабер, Кен «Процесс разработки SCRUM»].
Доска схватки	Доска Scrum используется для планирования и отслеживания прогресса во время спринта, который обычно содержит три столбца для индикации прогресса предполагаемых задач для спринта: столбец To Do для еще не начатых задач, столбец Work in Progress для запущенных задач но не завершено, и столбец «Готово» для выполненных задач.Доска Scrum также содержит диаграмму выгорания Sprint и место для неожиданных элементов.
Структура Scrum	Набор принципов, ценностей, практик и правил, которые составляют основу разработки на основе Scrum.
Скрам Мастер	Скрам-мастер — одна из трех основных ролей в Скрам-команде. Скрам-мастер облегчает Скрам и отвечает за устранение препятствий; таким образом позволяя команде достичь цели / результата спринта.
Scrum of Scrum	Scrum of Scrums аналогичен Daily Scrum. Эту встречу проводит Главный Скрам Мастер и обычно она проводится в крупных проектах, где несколько Скрам-команд работают синхронно, чтобы обеспечить прогресс проекта.
Роли Scrum	В Scrum есть три основные роли: владелец продукта, мастер Scrum и команда Scrum (также называемая командой разработчиков).Это люди, ответственные за достижение целей проекта.
Скрам-команда	Команда Scrum состоит из владельца продукта, Scrum Master и команды разработчиков, ответственных за качественное и своевременное выполнение обязательств по спринту.
Самоорганизация	Команда или группа людей, которые управляют собой, своим временем и ресурсами, считаются самоорганизованными.
Демонстрация спринта	Действие обзора спринта, при котором будут продемонстрированы завершенные элементы невыполненной работы по продукту. Намерение состоит в том, чтобы стимулировать насыщенное информацией обсуждение между командой Scrum и другими участниками обзора спринта.
Спринт Гол	Цель спринта — это то, что должно быть выполнено к концу спринта. Это сводка действий / результатов, разработанных элементами невыполненной работы продукта, которые владелец продукта хотел бы выполнить во время спринта.
Совещание по планированию спринта	Совещание по планированию спринта проводится в начале каждого спринта. Цель встречи — определение целей и задач.
Ретроспектива спринта	Это обзор и анализ, выполняемые в конце каждого спринта. Цель состоит в том, чтобы улучшить работу команды Scrum и внедрить передовые методы.
Обзор Sprint	Встреча по обзору спринта проводится в конце каждого спринта. Команда доставки показывает, чего они достигли во время спринта. Атрибуты деятельности проверяются, изменяются и согласовываются на каждой встрече по обзору спринта.
Кадровый резерв	Характеристики потенциальных сотрудников, которые могут присоединиться к команде.
Требования к персоналу	Определяет, какие виды компетенций требуются от отдельных лиц или групп и в какие сроки.
Заинтересованная сторона	Любое физическое или юридическое лицо, которое может повлиять на начинание / проект, или быть затронутым им, или считаться затронутым, является заинтересованной стороной.
Статистическая выборка	Выборка, которая включает выбор части исследуемой совокупности для проверки.
Совещания по пересмотру статуса	Встречи, которые планируются регулярно для обмена и анализа информации о статусе проекта и его эффективности.
Story Point	Абстрактная мера усилий по реализации рассказа называется сюжетной точкой. Обычно определяется при участии в планировании покера.
Устойчивый темп	Надлежащий агрессивный темп, в котором работает команда, чтобы обеспечить хороший поток бизнес-ценности в течение длительного периода времени, не перегорая.
Синхронизация	Синхронизация — это координация событий для работы системы в унисон. Часто используется для обеспечения согласованной совместной работы нескольких Scrum-команд, начиная и заканчивая спринтами в одни и те же дни.
Диаграммы системы или процессов	Графическое представление процесса, показывающее взаимосвязи между различными этапами процесса.Во время планирования качества блок-схемы помогут команде проекта предвидеть проблемы с качеством, которые могут возникнуть. Обычно используется в методах водопада.
Доска задач	Диаграмма / доска, отображающая всю работу, которую команда выполняет во время спринта. Есть 5 столбцов: «История», «Сделать», «Выполняется» и «Готово».
Оценка задачи	Команда разбивает выбранные элементы бэклога продукта на задачи, а затем задачи оцениваются членами группы в соответствии с их сложностью, вовлеченным риском, потенциальным затраченным временем и т. Д. С помощью командных упражнений.
Тимбилдинг	Мероприятия, специально предпринимаемые руководством и членами команды, чтобы помочь отдельным членам команды эффективно работать вместе, тем самым повышая эффективность команды
Техника	Техника — это процедура, используемая для выполнения определенного действия или задачи. Это определенная процедура, которая используется для выполнения некоторых или всех действий или поддержки подхода.
Time Box	Фиксированная продолжительность времени, в течение которого выполняется действие. В Scrum спринты — это итерации с ограничением по времени.
Допуски и контрольные пределы	Допуски указывают указанный диапазон приемлемых результатов. Пределы контроля — это пороговые значения, которые показывают, вышел ли процесс из-под контроля.
Прозрачность	Одним из ключевых принципов Scrum является прозрачность, при которой заказчик постоянно осведомлен о развитии продукта, а члены команды осознают свои роли и обязанности.
Анализ тенденций	Математический метод для прогнозирования будущих результатов на основе исторических результатов. Это выполняется с помощью графиков прогона.
Триггеры	Также называемые симптомами или предупреждающими знаками, они указывают на то, что событие произошло или вот-вот произойдет. Обычно используется в управлении рисками.
Пользовательские истории	Пользовательская история — это утверждение (или группа утверждений), которое выражает желаемую функциональность конечного пользователя.Пользовательские истории обычно просты, короткие и легко реализуемые. Более длинные пользовательские истории далее разбиваются на несколько пользовательских историй.
Голос клиента (VOC)	Владелец продукта (ЗП) представляет заинтересованные стороны и несет ответственность за то, чтобы команда приносила пользу. Заказчик отвечает за обеспечение четкой передачи информации о функциональных возможностях продукта команде Scrum, поэтому его обычно называют голосом клиента.
Широкополосный метод Delphi	Широкополосный метод Delphi является разновидностью метода Delphi. Здесь, после раунда сбора ответов, членам группы показывают собранные данные, а авторов ответов, далеких от среднего, просят обосновать свой ответ / оценку опроса. Затем следует еще один цикл сбора ответов.
Без функций	Набор функций / параметров, которые специально объявлены недоступными в предстоящем выпуске.
Работа в процессе	Относится к работе, которая была проведена, но еще не завершена. Если большие сегменты проекта являются незавершенными, это может создать несколько проблем. Выявление узких мест в проекте становится трудным, если одновременно выполняются несколько задач. Каждая WIP требует капитала и не способствует рентабельности инвестиций, пока не станет готовым продуктом, пригодным для использования. Канбан-доски эффективны для ограничения незавершенной работы.

Agile Assessment: проверьте гибкость своей команды

Оценка ловкости

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

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

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

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

Agile Assessment

Возможно, вы не проявите гибкости, если …

С другой стороны, вы тоже не сможете быть гибкими, если

Кнопки «Отправить / получить» и «Сохранить как» инициируют общение в большинстве групп.
Ваши белые доски в основном белые
«Тест-драйв» по-прежнему относится к вашей машине
Вы еще не знаете, что означает PHB (подсказка)
Вы знаете, что означает CPM, и продолжаете полагаться на него
Вы тратите больше времени на управление зависимостями проекта, чем на их удаление
Кто-то все еще верит, что диаграмма невозможна (ой, это диаграмма Ганта)
Только разработчики разрабатывают, тестировщики только тестируют, а менеджеры только управляют
Простота считается простой, а
Заседание Совета по контролю за изменениями…ever

Что такое Agile SDLC и как он работает?

Что такое Agile SDLC и как он работает? | Synopsys

Товары
Решения
Ресурсы
Сервисы
Сообщество
Обучение

Инструменты и услуги
Решения
Обучение
Клиенты
Ресурсы
Партнеры
Блог

Насчет нас
Отношения с инвесторами
Сообщество
отдел новостей
Ресурсы
Карьера

Апрель 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Что такое agile простыми словами: Гибкая методология разработки — Википедия

Просто о сложном: agile-разработка / Далее

Что было до аджайла

Agile Manifesto

Как команды работают по аджайлу

Кое-что еще

Какому продукту точно нужен аджайл?

Agile и гибкие методологии разработки. Модуль 2

Ценности аджайла

Как применять аджайл на практике

ПРОВЕРИТЬ СЕБЯ

Scrum и Agile, в чем разница. Скрам и Эджайл для чайников

Комментарий Котиков

Эджайл

Концепция гибкости:

Скрам

Команда в скраме

Устройство спринт

Структура спринта

Scrum, Kanban, PRINCE2 и другие

08 Июл 2016

Почему «управление проектами»?

Краткая история проектного управления

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

Классическое проектное управление

Agile

Scrum

Lean

Kanban

6 сигм (Six Sigma)

PRINCE2

Лучшая система управления проектами … для Вас!

Как получить международный сертификат по Agile?

Agile — гибкая методология разработки

Что представляет собой Agile?

Методы Agile

Принципы Agile

Главные преимущества Agile

Качество web-продукта

Высокая скорость разработки

Минимизация рисков

Прозрачность оплаты

Что такое Agile? 1 часть

Agile & Scrum: реализация за 10 шагов

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

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

Зачем использовать гибкое управление проектами?

Попробуйте наш шаблон гибкого планирования!

Что такое гибкое управление проектами с помощью Scrum?

What Is Agile

Глоссарий Agile и Scrum | SCRUMstudy

Agile Assessment: проверьте гибкость своей команды

Оценка ловкости

Agile Assessment

Возможно, вы не проявите гибкости, если …

Что такое Agile SDLC и как он работает?

Добавить комментарий Отменить ответ