История agile: История Agile — Управление проектами

Истоки мотивации в управлении по Agile и SCRUM / Хабр

UPD от 18-08-2018: обновил и упростил текст статьи

Agile — это концепция управления проектами, которая базируется на гибкости и максимальной адптивности к изменениям. Можно сказать, что суть аджайла заключается в принципе «проверять и адаптироваться». Можно и нужно как можно чаще внедрять небольшие готовые вехи продукта, чтобы понимать, создается ли именно то, что нужно рынку и потребителю — вот к чему призывает аджайл. Аналитика рынка и потребностей потребителя проводится часто, чтобы подкорректировать планы по развитию проекта. Программисты пишут проект короткими итерациями, что позволяет владельцам бизнеса проверить «на бою» свои бизнес-идеи. Учитывая, что некоторые фичи были нужны еще вчера, а взятые на прошлой неделе требования уже устарели, то каждый участник проекта должен быть всегда готов к изменениям. Разработчики, как и владельцы продукта, в идеале понимают весь процесс поставки продукта потребителю и ту выгоду, которую он решает. Многие говорят, что аджайл работает, некоторые считают, что он собрал просто лучшие практики разработки ПО, не создав ничего нового, однако нельзя отрицать, что аджайл работает. Это доказывают истории компаний [1]

История появления Agile

Исторически сложилось, что Agile чаще всего используют в проектах, так или иначе связанных с информационными технологиями. Например, согласно результатам опроса, проведенного компанией Scrumtek.ru, больше половины опрошенных компаний так или иначе связаны с разработкой ПО, даже если это не основное направление бизнеса [2]. 

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

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

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

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

Главные правила Agile

В 2001 году группа разработчиков создала так называемый «манифест Agile». Несмотря на то, что он содержит в тексте «разработку программного обеспечения», эти правила можно отнести к любому процессу создания нового продукта [3]:

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Влияние Agile на бизнес-процессы

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

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

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

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

Agile и теории мотивации персонала

Эффективность работы человека зависит от многих факторов, и одним из наиболее важных считается мотивация. Мотивация работника зависит от многого, и при этом считается, что только лишь материальное вознаграждение не является достаточным стимулом к работе [5]. Agile, по моему мнению, опирается на две популярных теории мотивации: теорию потребностей по Маслоу и двухфакторную теорию мотивации Ф. Герцберга.

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

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

По мнению Маслоу, люди удовлетворяют свои потребности последовательно от базовых к высшим:

“человек желает удовлетворить из двух потребностей более базовую, когда он не удовлетворён в отношении их обеих”.

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

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

По двухфакторной теории мотивации Ф. Герцебрга, на мотивацию влияют «гигиенические» и «мотивирующие» факторы». «Гигиенические»

• условия работы;
• помещение;
• культура;
• политика компании в отношении внутренних процессов;
• оплата труда, премии, бонусы и т.д.

Эти факторы побуждают работника возвращаться каждое утро на работу.

«Мотивирующие»:

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

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

По моему мнению, именно на мотивирующие факторы опирается Agile. Работники самостоятельны при исполнении задач, получают высокую степень ответственности за свои дела, а руководство поощряет их хорошие решения через обратную связь. Если же что-то пошло не так, то Agile рекомендует руководителям разъяснять, в чем была ошибка исполнителя, а не порицать и/или наказывать. Это способствует развитию поддерживающего стиля руководства, который признают одним из наиболее эффективных при работе с высококвалифицированным персоналом [6]. Если работник принимает какое-либо решение в рамках своей компетенции, и оно показало хорошие результаты или руководство оценило его пользу, то это мотивирует работника развиваться дальше, чтобы в будущем принимать более ответственные решения.

Роль обратной связи в вопросах мотивации

Дэн Ариели (Dan Ariely) — израильско-американский профессор психологии и поведенческой экономики. Он преподает в Университете Дьюка (Duke University) и является основателем научного центра The Center for Advanced Hindsight. [7] Ариели проводил некоторые эксперименты, отражающие важность обратной связи при выполнении работы. Одним из наиболее известных экспериментов является сборка конструктора людьми за деньги. Суть эксперимента заключается в том, что испытуемых делят на две группы. Обе группы людей собирают конструктор из предоставленных деталей за 3 доллара. После того, как человек заканчивал сборку, он приступал к сборке другого конструктора, но за цену на тридцать центов меньше. Вопрос эксперимента заключался в том, перестанет ли человек собирать конструктор до того момента, когда он за сборку не получает ничего. Разница между группами заключается в том, что собранный конструктор испытуемым из первой группы убирался в ящик, а результат работы испытуемых из второй группы на их глазах разбирался и отдавался им же на повторную сборку на следующем этапе. В среднем испытуемые из первой группы, где собранный конструктор убирался в ящик, повторяли работу 11 раз, а участники из второй группы – только 7. [8]

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

Аналогичные эксперименты проводились Ариели и в последующем. Например, вместо сборки конструктора людям предлагалось отметить на листе хаотичного набора букв те, что стоят рядом и образуют осмысленные слова. Испытуемых поделили на три группы, при этом участники первой группы записывали свое имя на листе ответов, а участник двух других — нет. Результаты первой группы проводящий эксперимент человек оценивал на глазах испытуемых и складывал в стопку, давая заполнить еще один такой лист. Ответы испытуемых второй группы же просто складывались в стопку без просмотра. Ответы испытуемых третьей группы без оценки уничтожались через шредер на их глазах. Оплата за заполнение листа начиналась с 30 центов, за каждое последующее заполнение выплачивалось на 1 цент меньше. Результаты эксперимента были следующими: участники первой группы, чьи ответы оценивались, прекращали повторные заполнения на 15 центах в среднем, участники третьей группы, чьи ответы уничтожались без оценки, заканчивали на 28 центах, что не удивительно. Но удивительным фактом для проводивших эксперимент оказалось то, что участники второй группы, чьи ответы не подписывались и не оценивались тут же, прекращали повторное заполнение уже на 26 центах. Ариели пришел к выводу, что игнорирование и обезличивание результатов работы человека практически равносильно полному уничтожению плодов труда работника у него на глазах. Снизить мотивацию сотрудников достаточно легко, а поднять – тяжело.

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

Как говорит ученый, потребители подобных товаров, требующих участия самого клиента в доведении продукта до завершенного состояния, положительно отзываются на усложнение процесса вовлечения. Об этом говорит небольшое исследование компании «Betty Crocker», которая в конце 50-х годов прошлого столетия решила выпускать готовые смеси для выпечки, где клиенту нужно было лишь высыпать смесь в форму и поставить в печь для запекания. Как отмечают исследователи, целевая аудитория – домохозяйки – не стали массово покупать продукт, хотя с экономической точки зрения такой продукт был выгоден с точек зрения как финансовых вложений, так и временных затрат. Компания столкнулась с низкими продажами. Руководители решили исключить из смеси молоко и яйца, что вовлекало потребителей в процесс изготовления пирога больше – домохозяйке нужно было добавить недостающие компоненты в нужных пропорциях. Официальных данных нет, но представители компании говорят о росте продаж в несколько раз. Как считают Нортон и Ариели, потребители в случае выпечки полностью готовой смеси не могли почувствовать, что готовый пирог – это плод их усилий, однако, когда нужно было замешать смесь с яйцами и молоком, это давало домохозяйкам чувство причастности к изготовлению, и они могли сказать: «Это мой пирог». Такой вывод они сформулировали: чем больше человек вкладывает сил и души в дело, тем больше радуется результату [9]. 

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

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

В заключение

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

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

Источники

1. Can Big Organizations Be Agile
2. Отчет о результатах опроса компаний России за 2017 год
3. «Agile-манифест разработки программного обеспечения», официальный сайт
4. «Agile: как и когда применять этот метод», Сергей Карпов
5. «Стили руководства», ресурс «Grandars.ru»
6. «Теории мотивации», ресурс «grandas.ru»
7. Биография Дэна Ариели
8. «Дэн Ариэли: Эксперименты с мотивацией сотрудников», статья об эксперименте
9. «Эффект IKEA – что смастерил, то и полюбил», ресурс «Harvard Business Review» об «эффекте IKEA»

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

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

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

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

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

Похожие материалы

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

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

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

ИСТОЧНИК

крупнейшая идеологическая проблема в IT / Блог компании Издательский дом «Питер» / Хабр

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» — обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile — самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile — это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.

В сущности, Agile была бунтом против корпоративного засилья в разработке ПО. Впервые было признано, что разработка ПО – сложный и зачастую таинственный процесс, который обязательно нужно уберечь от корпоративной забюрократизированности. Изменения, переизобретение, гибкость, динамизм – вот красные нити, проходящие через манифест Agile. Они показали себя бесконечно привлекательными: согласно одному глобальному исследованию, около 97% всех организаций в той или иной форме практикуют принципы Agile. Благодаря такому повсеместному распространению, Agile достигла в теории управления разработкой ПО тотальной номинализации: сегодня термином «аджайл» именуют идеологию, методы работы и даже системы, используемые для разработки ПО в современной организации. Agile даже распространяется за пределы программерских команд и все чаще практикуется в других командах, отвечающих, например, за финансы или управление человеческими ресурсами. Agile, трактуемая как универсальная теория менеджмента, оказалась исключительно доступной и популярной – несмотря на скудость эмпирических подтверждений ее эффективности и полезности.

Интересно, что в манифесте Agile не делается попыток артикулировать какие-либо конкретные методы работы, правила, процессы, системы или структуры, которые помогали бы разрабатывать ПО в стиле Agile. Это и неудивительно: ведь манифест Agile никогда и не претендовал на подробное описание того, как достичь целей этого манифеста. Такая явная размытость ничуть не убавила популярности Agile: фактически, стремительный рост спроса на конкретные методы и инструменты Agile привел к возникновению метаиндустрии на основе ресурсов Agile. Этот интерес стимулировал внедрение Agile, проникновение в новые отрасли самой идеологии Agile и ее производных. Наиболее отчетливо проявили себя тщательно определенные методологии Agile (например, Scrum и Kanban—т.e., детализированные описания процессов, которых нужно придерживаться для воплощения принципов манифеста Agile) и специализированные софтверные платформы, специально разработанные для поддержки Agile-разработки. Австралийская технологическая компания Atlassian продает целый ряд таких продуктов, предназначенных для поддержки процессов разработки ПО в стиле Agile; особого упоминания заслуживают Confluence и Jira, уже де-факто ставшие стандартами в индустрии. Для тех, кто не варится в технологическом сообществе, такие продукты кажутся весьма таинственными. Появился целый ряд поясняющих статей, прежде чем Atlassian попала в списки NASDAQ и непосредственно после этого. Статьи были призваны объяснить, что же именно продает Atlassian, и почему компания добилась такой высокой рыночной капитализации.

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

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

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

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

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

Про Agile на пальцах. Путь к быстрой разработке. — @emacsway’s blog

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

Задумывались ли Вы когда-нибудь, почему одни люди работают в разы быстрее чем другие?
Причем, часто “тормозят” в работе именно наиболее умные и толковые разработчики.

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

Этот парень использовал на то время лишь ограниченный сегмент практик Extreme Programming (XP) — наиболее эффективной и одной из первых Agile-методологий.
Все что он использовал — TDD, Evolutionary Design, принципы SOLID, из которых особый упор был на Single Responsibility Principle (SRP), а также активно использовал Type Hinting для автоматического рефакторинга, поскольку язык был с динамической типизацией.

Именно так я и познакомился впервые с Extreme Programming, вернее, с его неоспоримым превосходством даже в столь урезанном виде.
Под настоянием этого парня я прочитал свою первую книгу в области качества кодирования — Clean Code, и с этого началось мое становление специалиста в области проектирования программного обеспечения.

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

Итак, как нам это удалось, и почему до этого мы не могли работать эффективно?

Кент Бек как-то сказал, что труднее всего работать в Agile-разработке докторам наук.
Причина в том, что чем выше интеллект человека, тем больше ему свойственно продумывать всю задачу наперед, охватывать умом всю реализацию, от начала до конца (upfront thinking), еще до начала ее реализации.

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

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

Ответом на эту проблему является Evolutionary Design (Emergent Design).
Смысл его заключается в том, что мы начинаем реализовывать первое пришедшее на ум решение, которое затем, уже в процессе разработки, изменяем путем рефакторинга по мере роста информированности.
Но при этом соблюдаем несложные правила:

• Single Responsibility Principle (SRP)
• Качественное проектирование кода, позволяющее отложить решение о конкретной реализации. Декларирование качественных интерфейсов важнее конкретной реализации.
• Обеспечение автоматического рефакторинга: расстановка Type Hinting для динамических языков программирования, покрытие кода тестами, использование средств автоматизированного рефакторинга.
• YAGNI — реализация только того, что требуется текущей задачей, без предположений о том, что нам потребуется в будущем, т.е. ничего не реализуется “впрок”. Существует простая лакмусовая бумажка принципа YAGNI: “выделение лишних абстракций (и любое другое усложнение) оправдано лишь в том случае, если стоимость их выделения в будущем будет существенно дороже, чем сейчас”.

Из перечисленного, второй принцип “Качественное проектирование” очень важен, и ниже я расскажу почему.
Но сперва об Agile-разработке.

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

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

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

Суть Agile-разработки заключается в том, чтобы изменить этот экспоненциальный график стоимости изменения кода на плоский и горизонтальный (насколько это возможно), более правильное название которого — асимптота.
Если проект равно одинаково легко изменить в любой момент независимо от объема кодовой базы, то это значит, что нам не нужно проектировать его заранее (т.е. нет необходимости в upfront design)!
Вот в чем заключается смысл слова “гибкий” (agile)!

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

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

Agile-разработка — это значит достигнуть такого качества архитектуры (проектирования), которое позволит дешево внедрять проектные решения не забла

Опыт внедрения Agile в компании Ticketland — статьи на Skillbox

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

запись вебинара

 1ч. 32 мин.

статья

 13 мин.

Экономия времени

 1ч. 19 мин.

Попытки создать идеальную систему управления данными начались еще в середине девяностых годов прошлого века. Даже ФБР попыталось придумать что-то новое для замены каскадной модели управления (Waterfall), но, потратив600 млн долларов, отказалось от этой затеи. Почему же за10 лет так ничего и не удалось сделать? Проблема была в самой методике работы «по каскадам» (ступеням), когда следующий этап запускается только после того, как реализован предыдущий: если останавливался один из этапов, то замирал весь проект.

В 2001 году появился «Манифест гибкой методологии разработки программного обеспечения» (англ. Agile Manifesto), и ситуация изменилась. За счет итерационной модели удалось наладить непрерывную работу всех участников проекта, и проклятье Waterfall исчезло. А пример ФБР и выброшенных на ветер600 млн долларов научил всех.

Важно!

С помощью старых подходов нельзя решать современные задачи.

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

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

• Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервиса.

• «Сакральные» знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.

• Низкая скорость разработки и низкое качество продуктов.

• Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.

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

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

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

Agile — это гибкая методология в разработке ПО. В ее основе лежит4 принципа:

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

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

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

В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо — Product Owne

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.

Важно!

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

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

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

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

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

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

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

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

В Agile нет места хаосу, каждое нововведение должно быть четко обосновано

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

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

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

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

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

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

Схематическое отображение t-shape

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

Важно!

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

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

Положение Product Owner в бизнес-процесса и в команде

Ключевые навыки Product Owner:

• обладает видением продукта;

• является владельцем бэклога продукта;

• умеет расставлять приоритеты;

• управляет ожиданиями заинтересованных лиц;

• представляет пользователя;

• взаимодействует с командой;

• принимает продукт.

То есть каждое обновление рассматривали не только со стороны бизнеса, но и со стороны пользователя.

Схематическое отображение пользовательской истории

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

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

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

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

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

Независимое обновление

Масштабирование

Возможность экспериментов

Поддержка любым разработчиком

Сложно выкатывать

Сложно тестировать

Респределительная система

Сложно эксплуатировать

Несогласованная БД 

Все поставленные задачи были решены. Сервис Ticketland вошел в двадцатку Forbes, компанию оценили в 84,2 млн долларов. Для бизнеса такого рода это отличный результат.

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

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

Больше узнать про Agile и другие актуальные методологии управления процессами, применяемые в IT, маркетинге и медиа, вы сможете, пройдя наш курс «Управление digital-проектами».

Курс «Управление Digital-проектами»

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

•  32 часа теории и 16 практических заданий
• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Отчет об исследовании Agile в России 2019 — статья в блоге ScrumTrek

Скачать полную версию отчета Agile в России 2019 (2 Мб, PDF) | Отчеты за все прошлые года Ежегодное масштабное исследование Agile в российских организациях в 2019 году проводилось с 21 марта по 10 декабря, и в нем приняли участие 1502 человека. Это самое крупное в мире ежегодное исследование гибких подходов к управлению (по сравнению с […]

Скачать полную версию отчета Agile в России 2019 (2 Мб, PDF) | Отчеты за все прошлые года

Ежегодное масштабное исследование Agile в российских организациях в 2019 году проводилось с 21 марта по 10 декабря, и в нем приняли участие 1502 человека. Это самое крупное в мире ежегодное исследование гибких подходов к управлению (по сравнению с исследованиями Agile в отдельных странах, а также с общемировым исследованием State of Agile от CollabNet VersionOne).

Фокус исследования – узнать, как и насколько успешно в России проходят Agile-трансформации.

Agile проникает в новые отрасли

ИТ-индустрия теряет свою монополию на Agile. К примеру, с прошлого года процент Agile-практиков из тяжелой промышленности увеличился в 2 раза.

Agile распространяется по всей стране

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

Главный результат внедрения Agile – скорость поставки

Заметили существенное ускорение поставки продуктов:

• На этапе пилотирования Agile – 47%.
• На этапе трансформации (масштабирования Agile) – 60%.
• После внедрения Agile – 75%.

Сроки внедрения

Agile все чаще масштабируют с помощью SAFe^®

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Скачать полную версию отчета Agile в России 2019 (2 Мб, PDF) | Отчеты за все прошлые года

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

Примите участие в исследовании Agile в России 2020! Ответы на 15 вопросов исследования займут у вас около 5 минут. Взамен получите скидку 10% на все тренинги, онлайн-курсы и конференции ScrumTrek, а также шанс выиграть один из 16 призов!

Манифест agile все еще имеет вес?

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

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

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

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

Вот этот набор:

Манифест разработки программного обеспечения по методологии Agile

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

мы смогли проделанной работе благодаря осознать следующее.

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

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

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

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

Таким образом, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Дженинг Сазер52

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

Это все. С тех пор сайт с Манифестом agile практически не изменился (а может, и не менялся вообще). А вот мир, окружающий маневренный, значительно изменился.

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

.

Эпики, истории, темы и идеи

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

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

Что же предоставить собой истории, эпики, инициативы и темы?

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

Эпики и истории в agile

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

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

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

Примеры agile-историй

• Пользователи iPhone хотят при использовании мобильного приложения смотреть прямые трансляции в вертикальной ориентации.
• Пользователям компьютеров нужна кнопка «Полноэкранный режим» в правом нижнем углу видеопроигрывателя.
• Пользователям устройств Android нужна ссылка на магазин Apple.

Узнайте, как настроить истории (задачи) в Jira Software

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

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

Полные определения, примеры и рекомендации в следующих разделах.

Эпики и инициативы в agile

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

Пример эпиков в инициативе

Предположим, ваша ракетная компания хочет в этом году сократить стоимость запуска в космос на 5%. Такая цель идеально походит на роль инициатора. Инициативу можно разделить на такие эпики, как «сокращение потребления топлива на этапе запуска на 1%», «увеличить частоту запусков в квартал с 3 до 4» и «уменьшить значение на всех терморегуляторах в экономичном режиме с 22 до 20 градусов Цельсия».

На примере компании Atlassian

У нас в компании инициативы называются «PC-заявками». Заявки Project Central («проекта всех проектов») формируются в Jira Software так же, как и эпики. Каждая команда выбирает для себя 4–5 самых важных целей на год и создает PC-заявку для каждой из них. За счет таких заявок руководство и учредители понимают, какая работа ведется в компании.

ДАЛЕЕ: узнайте, как настраивать agile-эпики.

Инициативы и темы

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

• Инициативы — это набор эпиков.
• Темы — это метки, которые помечаются цели организации более высокого уровня.

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

Вот так темы выглядят в Advanced Roadmaps для Jira:

На примере компании Atlassian

В этом году в качестве одной из тем мы выбрали Open Work (Открытость в работе). Эта тема отражает стремление сделать работу в компании прозрачнее как для сотрудников, так и для сторонних наблюдателей.Моя команда работает в направлении этой темы: мы проводим открытую ретроспективу по использованию методик Agile. Мы просим разработчиков ПО поделиться впечатлениями о своем опыте agile-разработки и дополнить свои мнения в Twitter хэштегом #RetroOnAgile. Для этого в рамках трехмесячной кампании мы создали его темой «Открытая работа».

Формулируемая работа

Гибкость, которая достигается за счет применения методик agile, и использование структурированного подхода не исключают друг друга.Описанная выше структура не является универсальной. Чтобы добиться успеха, команде нужно усвоить приведенные понятия и адаптировать их к своим потребностям. Мы строим работу на историях, эпиках, инициативах и темах. Для начала вы можете узнать, как задать эпики в Jira Software.

Поделитесь этой статьей

Макс Рекопф

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

.

Отчет об исследовании Agile в России 2019 — статья в блоге ScrumTrek

Скачать полную версию отчета Agile в России 2019 (2 Мб, PDF) | Отчеты за все прошлые года Ежегодное масштабное исследование Agile в 2019 году проводилось с 21 марта по 10 декабря, и в нем приняли участие 1502 человека. Это самое крупное в мире исследование гибких подходов к управлению (по сравнению с […]

Скачать полную версию отчета Agile в России 2019 (2 Мб, PDF) | Отчеты за все прошлые года

Ежегодное масштабное исследование Agile в российской организациих в 2019 году проводилось с 21 марта по 10 декабря, и в нем приняли участие 1502 человека.Это самое крупное в мире исследование гибких подходов к управлению (по сравнению с исследованиями Agile в отдельных странах, а также с глобальным исследованием State of Agile от CollabNet VersionOne).

Фокус исследования — узнать, как и насколько успешно в России проходят Agile-трансформации.

Agile проникает в новые отрасли

ИТ-индустрия теряет свою монополию на Agile. К примеру, с прошлого года процент Agile-практиков из тяжелой промышленности увеличился в 2 раза.

Agile распространяется по всей стране

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

Главный результат внедрения Agile — скорость поставки

Заметили существенное ускорение поставки продуктов:

• На этапе пилотирования Agile — 47%.
• На этапе трансформации (масштабирования Agile) — 60%.
• После внедрения Agile — 75%.

Сроки внедрения

Agile все чаще масштабируют с помощью SAFe ^®

SAFe и Scaled Agile Framework являются зарегистрированными товарными знаками Scaled Agile, Inc.

Скачать полную версию отчета Agile в России 2019 (2 Мб, PDF) | Отчеты за все прошлые года

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

Примите участие в исследовании Agile в России 2020! Ответы на 15 вопросов исследования займут у вас около 5 минут.Взамен получите скидку 10% на все тренинги, онлайн-курсы и конференции ScrumTrek, а также шанс выиграть один из 16 призов!

.

Восемь самых популярных книг по Agile, Scrum и Kanban / Блог компании Leader-ID / Хабр

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

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

В конечном результате инструментами для анализа стали: поиск Яндекса, Wordstat и их крупнейшие книжные сайты с статистикой и отзывами. О том, какой рейтинг можно «намыть» с их помощью, — под катом. И еще мы думаем, что методика получилась универсальной — вполне применимой для подбора книг по другим направлениям.

Как растет спрос на гибкие методологии

Раз уж всплыл этот вопрос, нам стала любопытна динамика интереса к Agile, Scrum и Kanban внутри нашей платформы.Для этого подняли статистику по всем мероприятиям в «Точках кипения» и сделали поиск по трем основным ключевым словам. Отредактировав вручную финальные списки, получили любопытную картину.

Начнем с Agile:

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

А тут разбивка по месяцам. Особенно впечатляет пик в апреле, во время самоизоляции:

Ну а в июне уже чувствуется сезонный спад активности.

По Scrum — похожая ситуация, где по годам наблюдается даже более быстрый рост:

Хотя по месяцам цифры достаточно ровные:

А вот с Канбан все скромнее: пять мероприятий в 2019 году и три — за первые пять месяцев 2020 года.

Далее мы оценили эффективность в «Точках» согласно общим тенденциям роста интереса к Agile-тематике.

Мы взяли яндексовский WordStat и посмотрели динамику запросов по ключевым словам за последние полгода:

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

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

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

В поисках правильных критериев оценки

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

Вот так выглядит один из субъективных рейтингов, который нам встретился:
Лучшие книги по Agile, Scrum и Kanban, по версии одного из экспертов

В итоге после объединения списков из разных источников удалось собрать шорт-лист из 22 книг.Как понять, какие из них наиболее полезные?

Вариант 1 : посмотреть рейтинг книг по отзывам на сайтех, посвященных книгам. Их можно найти, например, на Litres.ru, Livelib.ru, Ozon.ru. Есть также сайт Bookmate.com, где пользователи отмечают, какие книги они прочитали, оставляют рекомендации. Для нас интересно количество этих рекомендаций.

Если свести все данные в единую тепловую карту, получится вот такая картина.

Рейтинг книг на основании оценки пользователей сайтов

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

Продолжаем искать более объективные метрики.

Вариант 2 : посмотреть популярность книг по запросам в Яндексе и количеству страниц, на которых упоминаются книги.

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

Рейтинг книг на основании количества упоминаний

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

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

Итак, мы выбрали для себя пять метрик, по каждой из них отсортировали книги. Затем 10 лучшим в каждом чарте присвоили по 1 баллу. Если значение метрики одинаковое у 10-й и 11-й книг, даем баллы обеим. Суммируем баллы и сортируем по их возрастанию.

Метрики, на которых остановились мы: рейтинг Livelib как самый полный, упоминания на сайте HSE, количество запросов в апреле, количество страниц с книгой в Яндексе и… Вот здесь мы решили использовать еще один интересный параметр — количество пользователей, прочитавших книгу на Bookmate , так как он показался более наглядным, чем количество положительных оценок.

Вот что получилось:

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

Кратко расскажем о каждой из них.

1. Джефф Сазерленд. Scrum. революционный метод управления проектами

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

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

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

2. Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте

Toyota к семинарам по производственной системе из далеких 1970-х годов.Как Сазерленд по Scrum является своеобразным «евангелием», так и эта книга стала точкой отсчета для Kanban-подхода.

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

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

3. Майк Кон. Agile: Оценка и планирование проектов

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

«Подход руководителей проектов можно представить как«, планирование, планирование — выполнение ». Agile-подход — это «планирование — выполнение — адаптация», «планирование — выполнение — адаптация».Чем выше неопределенности проекта, тем важнее применение agile-подход для успеха ».

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

4. Дженнифер Грин, Эндрю Стиллмен. Постигая Agile

Этот объемный труд (450 страниц) включает в себя описание всех основных Agile-методологий: Scrum, Kanban, Lean и XP (экстремальное программирование).Книга легко читается, методологии даются несколько поверхностно, в обзорном режиме.

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

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

5. Хенрик Книберг. Scrum и XP: заметки с передовой

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

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

Книга небольшая, в сети можно найти перевод, сделанный энтузиастами из Agile Ukraine.

6. Борис Вольфсон. Гибкое управление проектами и продуктами

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

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

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

7. Майк Кон. Scrum: гибкая разработка ПО

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

«Scrum-командам приходится отвыкать мыслить в категориюх« моих »задач и« ваших »задач и привыкать мыслить в категории« наших »задач».

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

8. Дэвид Андерсон.Канбан. Альтернативный путь в Agile

Замыкает наш топ одна из ключевых книг по Kanban. Для первого знакомства, правда, она не подходит: слишком все разжевано, много тонкостей, которые будут интересны уже погруженному в тему читателю. Зато те, кто ее осилит (и пару раз перечитает), смог «включиться» в канбан.

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

Стоит обратить внимание, что здесь Kanban рассматривает проблему разработки именно для ИТ-продуктологов, что здесь руководители проектов.

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

.