Agile управление: Scrum, Kanban, PRINCE2 и другие – Гибкая методология разработки — Википедия

Как работать в Agile

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

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

Да, по моему опыту, примерно 5 из 10 команд после перехода на Agile уже в среднесрочной перспективе повышают производительность труда, удовлетворённость клиентов и качество разработки, а в долгосрочной — снижают общие затраты и улучшают другие KPI.

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

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

Главная фишка Agile в том, что это не готовая структура или некий свод правил, диктующий, что и как нужно делать. Нет, вся команда думает, что лучше для их проекта. Она может выбрать любую методологию (Scrum, Kanban, XP, Lean, SAfe…) или даже создать свою собственную. Это же касается и любых рабочих инструментов.

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

«Неудача — это возможность начать заново, на сей раз умнее».

ГЕНРИ ФОРД

Почему Agile не работает и что с этим делать / ИТ Гильдия corporate blog / Habr

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

/ Flickr / Hamza Butt / CC

Гибкие методологии не новы, не оригинальны и испробованы многими компаниями. И некоторые из них (как, например, американская компания-поставщих BI-решений для железных дорог Railinc) признают, что agile — лучшее, что могло с ними произойти. Правда, их энтузиазм разделяют не все. Крис Йорк (Chris York), тестировщик и разработчик с пятнадцатилетним опытом, утверждает, что ни разу в своей жизни не видел, чтобы гибкие методологии работали так, как надо.

Что значит, не работают?

По данным исследования VersionOne, 98% компаний считают свои agile-проекты успешными. Однако всего 7% респондентов сказали, что внедрение agile помогло компании лучше адаптироваться на рынке, и только 11% опрошенных заявили, что достигли высокого уровня компетентности внутри организации благодаря agile. Остальные 82% говорят, что всё ещё не достигли желаемого уровня «гибкости». Возможно, эти компании что-то делают не так, попробуем разобраться, что именно.

1. Общение — не самоцель

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

Многие компании осознали важность личного общения: IBM переместила удалённых сотрудников в офис, чтобы получить максимум от командной работы. Кроме IBM удалённых сотрудников «превращают в офисных» компании Reddit, Aetna, Bank of America и Best Buy. Диана Герсон (Diane Gherson) старший вице-президент по кадровой политике IBM говорит, что причина изменений состоит в том, что при этом подходе можно развивать «непрерывный процесс генерации инноваций».

Хуан Эмилио Инзауррага (Juan Emilio Inzaurraga), менеджер проектов компании Hexacta, также подчеркивает важность общения в agile-командах. Компания практикует ежедневные встречи/звонки с участием заказчика, и, по словам Хуана, это помогает ему определять прогресс команды, возможные узкие места и недостатки продукта. С другой стороны, встречи помогают разработчикам сконцентрироваться на текущей задаче, а новичкам и неопытным членам команды — лучше понять задачу и определить способы её выполнения.

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

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

Увлечение личными встречами тоже имеет свои негативные последствия. Например, опытный разработчик и резидент Quora Оливер Долан (Oliver Dolan) подсчитал, что на ежедневные встречи уходит 2640 минут или 44 часа за 1 спринт. Это не так уж и мало. Пользователи Hacker News также приводят множество аргументов против этих встреч: встречи убивают мотивацию, отвлекают, раздражают разработчиков, о чём также упоминает Джон Парселл (John Purcell), создатель образовательного проекта CaveOfProgramming.

Все эти опасения — не повод «отменять agile». Вопрос в том, насколько удачно компания сможет адаптировать гибкую методологию под себя. Например, другой резидент Quora, Патриция Оковицка (Patrycja Okowicka), разработчик с двенадцатилетним стажем, говорит, что в ее scrum-команде встречи занимают только 15% времени, остальные 85% — чистая работа. При таком подходе волноваться о том, что вся работа превращается в совещания, не приходится.

И несмотря на уверенность одного из создателей Agile Manifesto Роберта Мартина (Robert Martin) в том, что для достижения результата разработчикам нужно находиться буквально «в одной комнате», примеры того, как распределенные команды успешно внедрили agile, тоже существуют. Например, Джейми Болстер (Jamie Bolster), генеральный директор MentorMate, успешно управлял командой разработчиков, которые работали удалённо, с помощью agile. А Сандип Джоши (Sandeep Joshi), разработчик Microsoft, предлагает конкретные действия для грамотного управления удалённой командой.

2. Менеджер vs Надзиратель

Энтони Мерсино (Anthony Mersino), основатель тренинговой компании Vitality Chicago и автор книги «Agile Project Management: A Nuts and Bolts Guide to Sucess», утверждает, что менеджеров в agile вообще не должно быть. А Стив Деннинг (Steve Denning), автор шести книг о бизнесе и блога в Forbes, говорит, что «менеджмент» и agile — два разных мира. Предполагается, что члены команды могут сами организовать рабочий процесс и мотивировать себя.

К сожалению, многие реальные участники рабочего процесса считают такой подход, мягко говоря, оторванным от реальности. Патрик Харрингтон (Patrick Harrington), один из основателей и главный аналитик данных компании Paysa, подчёркивает, что опытные разработчики не нуждаются в постоянном надзоре, они уже достаточно взрослые и мотивируются KPI. Проблема в том, что менеджера обычно привыкли видеть «надсмотрщиком над разработчиками», в то время как в действительности (в особенности в agile-командах) его роль должна быть совершенно иной.

В сообществах вроде Hacker News [1, 2] разработчики отмечают, что «идеальный PM» должен быть на стороне команды, помогать каждому ее участнику разобраться в целях и задачах проекта, по возможности устранять мешающие факторы вроде нехватки ресурсов и (самое главное) защищать интересы и время разработчиков, а также ограждать команду от слишком частых совещаний и прочей энтропии. Такой подход позволит программистам работать слаженно и быстро реагировать на требования клиента — а это именно то, к чему стремятся agile-команды.

3. Agile-принципы != KPI

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

Один из участников этого треда на Hacker News проводит аналогию с футболом. В футбольной команде все игроки четко понимают цель, обладают навыками, чтобы её достичь. Каждый из них знает, как общаться с товарищами по команде так, чтобы они выполняли свои задачи, и каждый готов проявлять инициативу в сложившейся ситуации на поле. Никто не дышит футболистам в спину со словами: «Нужно забить гол через 15 минут и 48 секунд после начала матча и не минутой позже, даже если это невозможно». Такая команда работает слаженно и обычно достигает цели, и это именно то, что пытаются донести agile-методологии.

Следование принципам agile положительно влияет на эффективность работы, но (само по себе) не является показателем эффективности: выполнение формальных «ритуалов agile» не приблизит команду к достижению KPI. Более того, и показатели, по которым измеряется качество работы, с введением agile имеет смысл пересмотреть: если ваша команда должна незамедлительно реагировать на новые вводные, быстро адаптироваться к меняющейся ситуации, могут ли при этом оставаться неизменными KPI и подходы к их оценке? Этот вопрос, в частности, поднимает Джим Хайсмит (Jim Highsmith) в книге Agile Project Management.

Иногда такой «гибкий» пересмотр KPI «на ходу» требует немало смелости. Кстати, именно смелость сказать, что что-то в проекте идет не по заранее спланированному сценарию, как одну из важнейших качеств agile-лидера, выделяет Гари Поллис (Gary Pollice), практикующий профессор информатики и один из авторов книги «Разработка программных проектов. На основе Rational Unified Process (RUP)».

4. «Неформальный» agile

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

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

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

Один из успешных примеров — команда разработчиков RentaTeam. Они изменили принципы общения в команде и подстроили agile-методологии под свою команду и проект. Так agile обрёл смысл для сотрудников, а продуктивность разработчиков возросла на 30%.

По мнению Грега Йоргенсена (Greg Jorgensen), «типичного программиста» с сорокалетним опытом работы, увлечённая команда профессионалов, которая не зависит от решений сверху, понимает цели и требования и знает, как их достичь — вот, что сделает проект успешным. Методологии и инструменты — это прекрасно, но главное — это люди.

P.S. Наши материалы о методологиях разработки программного обеспечения:

P.P.S. Материалы по теме из блога «ИТ Гильдии»:

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

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

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

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

Вы наверняка слышали такие термины как SCRUM, Crystal, DSDN, Extreme programming – все это подмножества множества Agile, есть и другие agile-методики, которые упоминаются не так часто.

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

Как возник Agile

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

На тот момент в ходу был метод «водопада» (waterfall) – последовательной разработки программного продукта из шести стадий:

1. Формирование системных и программных требований.
2. Анализ требований, существующих процессов и т.п.
3. Дизайн архитектуры программного обеспечения.
4. Непосредственно написание программного кода.
5. Тестирование и исправление ошибок, выявленных тестерами.
6. Внедрение и исправление ошибок, выявленных пользователями.

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

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

Гибкие методы появлялись органично в ответ на условия конкуренции:

• если нет определенности в отношении финальных параметров продукта, не нужны жесткие спецификации – используем список пожеланий к продукту (back-log), который может меняться и дополняться по мере развития проекта;
• если данные о требованиях рынка противоречивы, и единственное решение – как можно быстрее показать конечному клиенту или начать продавать, то делим продукт на части, которые сразу можно использовать или выпускаем MVP – минимальный жизнеспособный продукт (minimum viable product).
• если сроки «жмут», надо поставить график перед лицом, а для наглядности заменить его доской «Канбан» (см. также про бережливое производство). И так далее.

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

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

О принципах Agile четко и ясно

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

Основные постулаты:

1. Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
2. Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
3. Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
4. Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой — процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

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

   На примере калькулятора для анализа проекта:

   • по завершении первого спринта вычисляется NPV в Microsoft Excel – все основные формулы работают, ошибок нет, выдается только финальная цифра – рассчитанный NPV;
   • по завершении второго спринта NPV рассчитывается также как по итогам первого спринта, но добавляется функциональность – комментарий о полученном значении, расчет IRR и других критериев – для более полной картины;
   • по завершении третьего спринта на основе разработанной в первых двух спринтах логики и формул, выверенных и согласованных с заказчиков текстов готовится десктопная версия продукта;
   • по завершению четвертого спринта готовится мобильная версия продукта и… вуаля! Продукт готов к использованию для задач заказчика.

2. Изменения требований приветствуются. Разработка продукта ведется в быстроменяющейся конкурентной среде, когда по завершении цикла разработки уже может измениться рынок, например, вышел аналог. Тогда, чтобы не выкинуть в мусорную корзину реализованный проект, его дорабатывают, кстати, можно использовать опыт уже вышедшего на рынок конкурента. Поэтому в рамках гибкого подхода изменения требований продуктов даже в конце разработки – приемлемы и приветствуется.
3. Частая поставка рабочего программного продукта. Важность этого принципа все в том же – мир быстро меняется и чем короче цикл поставки, тем точнее финальный продукт будет соответствовать ожиданиям.
4. Погружение заказчика в работу над проектом на протяжении всего времени его реализации. Заказчик в этом случае является единственным участником команды, носителем знания, «как надо», соответственно его заключение о соответствии продукта ожиданиям и его удовлетворение от результата – ключевой критерий. Чем чаще ожидания заказчика сопоставляются с работой команды проекта, тем, естественно, выше соответствие ожиданий и результата.
5. Проектом занимаются мотивированные личности, которые обеспечены соответствующими условиями работы, поддержкой и доверием. Этим принципом проблемы мотивации выводятся за рамки работы над проектом. Предполагается, что на этапе формирования команды, необходимо отбирать только мотивированных профессионалов, самодостаточных личностей, которых не надо подгонять, уговаривать и т.п. Задача сведется только к созданию условий, не препятствующих реализации их потенциала в этом проекте: инструменты связи, возможности для взаимодействия, оборудование и материалы и др.
6. Рекомендуемый метод коммуникации – лицом к лицу. Это спорный принцип в цифровую эпоху, когда многие компании развивают сетевое взаимодействие и внедряют удаленную работу в свои процессы. При этом личное взаимодействие имеет ряд преимуществ, которых нет у других видов коммуникации: например, скорость решения вопросов, невербальные сигналы (эмоции, жесты), мотивация (можно похвалить, выделить, поставить «на место»). В любом случае манифест акцентирует на этом внимание и заявляет, как один из ключевых принципов.
7. Работающее программное обеспечение – лучший измеритель прогресса. Перенося этот принцип на более общую систему координат, работающая версия продукта — лучший критерий успешности и прогресса проекта. В большом числе случаев этот принцип реализуем и понятен, а там, где не применим Agile.
8. Разработчики, а также их куратор и заказчик должны быть готовы сохранять заданный темп в разработке в течение не определенного (читай — неограниченного) времени. Надо понимать, что в такой парадигме срок разработки финальной версии продукта не известен, более того, финальной версии может и не быть, что мы видим на примере постоянно шлифуемых и дорабатываемых версий десктопного программного обеспечения и мобильных приложений.
9. Краеугольным камнем Agile-разработки заявляется стремление к техническому совершенству и качеству планирования спринтов. Этот принцип призван сбалансировать возможный негативный эффект на качество разработки от других принципов, например, частой поставки рабочего продукта. Можно разными методами добиваться частой поставки в условиях отсутствия или недостатка спецификаций продукта, например, использовать готовый, но некачественный код разработанный «индийскими программистами» и пренебречь тестированием. Личные качества, профессионализм разработчиков и коллективная ответственность – заложенные в принципе «стремления к техническому совершенству» требуют более высокого уровня ответственности.
10. Простота и минимизация лишней работы. Этот принцип надо бы применять во всех проектах, но в качестве ключевого принципа он заложен только в Agile-методиках. Приоритет отдается тому, что делается быстро с минимальными затратами. Отказываемся от ненужных работ как в процессах, так и в отношении продукта, например, консалтинговая компания обычно готовит многостраничную презентацию по выполненным работам и предполагаемым шагам, но если клиент интегрирован в команду, то ему формальная бумага не нужна, ему важнее то, что уже идет в работу – те самые два-три слайда, которые уже готовы для финальной презентации. В отношении продукта – можно стремиться реализовать все задумки в отношении функционала сразу до первого релиза, однако так уже никто не делает, в каждой итерации продукт совершенствует в соответствии с требованиями рынка, что может подразумевать как добавление нового функционала, так и удаление каких-то фич, не «принятых» клиентами.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Речь идет не об анархии, а о высокой внутренней дисциплине в команде, четком распределении ролей и высоком уровне профессионализма каждого участника. Если вы не можете самоорганизовываться – не работайте в концепции Agile.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Этот принцип подчеркивает, что вся полнота ответственности за проект и его продукт лежит на всех членах команды, никто со стороны не вносит корректив и не анализирует эффективность – все делают участники внутри своего коллектива в интересах проекта и результата.

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

Области применения Agile

Agile в своем максимальном объеме применим и эффективен при создании продуктов, которых:

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

Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:

1. Программное обеспечение для массового сегмента, в том числе мобильные приложения, игры и т.п.
2. Стартап-проекты – это идеальная почва для внедрения гибких методологий.
3. Интернет-порталы и СМИ.
4. Медицинские проекты – тело человека до сих пор в значительной мере «терра инкогнита», что создает высокую долю неопределенности в медицине.
5. Образовательные продукты и проекты. Если мы говорим о чем-то новом, а не о компиляции старых методов и практик, то образовательные проекты – стартапы на неизведанной территории, все ищут новые методы цифровой эпохи на замену старым технологиям индустриального мира.
6. Консалтинг – любой проект в этой сфере требует применения большинства принципов Agile Manifesto. McKinsey однозначно используют методику соответствующую указанным принципам.
7. Разработка финансовых и страховых продуктов (индустрия финтех), так как финансовые компании сегодня, это в большой степени ИТ-компании, а финансовый продукт уже стал в значительной степени ИТ-продуктом или применяет результаты работы ИТ-проектов/продуктов.

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

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

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

Agile руководство шаг за шагом, внедряем эджайл 5+ шагов

Agile (Эджайл) краткое руководство по внедрению шаг за шагом

Agile как методология гибкого управления становится очень популярной, уже можно с уверенностью сказать, что 100% компаний из списка Forbes применяет Agile в своей работе или по крайне мере думает о том как применить. Почему?

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

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

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

В Agile входит много разных методологий Scrum, Канбан, ХР, Lean, а также множество интересных методик, которые можно использовать по отдельности.

Модель Водопада — Waterfall Model

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

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

Зачем внедрять Agile методы гибкого управления в компании

Agile манифест

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

• умение работать с людьми; находить,… воспитывать и управлять талантами.
• выстраивать систему деловых коммуникаций, как с клиентами, так и с партнерами.
• уметь управлять изменениями, девиз: «подвижный в подвижной среде» очень хорошо подходит для Agile команд.

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

Распространенные заблуждения по методологии Эджайл

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

Документация в Agile

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

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

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

Договор в Agile

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

Agile управление в компании

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

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

Agile это военная операция в условиях высокой неопределенности

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

Какие отличия Agile от других систем управления

Рекомендую ознакомиться:

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

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

Примеры Agile в компании

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

Может ли Agile привести к хаосу — да, а хаос к системе? Ответ тоже Да, почему?

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

Scrum методика гибкого управления

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

Алгоритм реализации Scrum в компании довольно простой:

• определите владельца продукта.
• сформируйте команду от 2-10 человек.
• найдите наставника или скрам-мастера.
• составьте требования к продукту и цели, которые вы хотите достичь, зафиксировав данные в бэклог продукта.
• проведите оценку данных вместе со всей командой, зафиксировав сколько времени потребуется на выполнение.
• определитесь с периодом спринтов, отрезки времени, которые необходимы для внедрения выделенного объема задач. Спринты проводятся до момента завершения проекта.
• проводите ежедневные встречи, 15-20 минут, кратко обозначая следующие вопросы: что делал вчера, что будем делать сегодня и какие трудности мешают.

Дополнительно вы можете делать:

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

7 шагов внедрения SCRUM в компании

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

Где Agile ужасен, особенно Scrum / Habr

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

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

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

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

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

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

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

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

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

1. Бизнес-ориентированная разработка.

Agile часто подают в сравнении с «водопадом». Что такое водопад?

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

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

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

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

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

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

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

В конечном счёте, Agile (как практикуется) и Waterfall — формы бизнес-ориентированной разработки, и поэтому ни одна из них не подходит для разработки качественного ПО или мотивации сотрудников.

2. Подчинённое положение молодых.

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

Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.

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

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

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

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

3. Слишком краткосрочный подход, что глупо и опасно.

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

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

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

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

4. Он не имеет никакого отношения к построению карьеры.

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

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

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

5. Цель определить низкие показатели, но при этом неприемлемо высок уровень ложноположительных результатов.

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

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

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

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

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

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

Часто от внедрения Agile/Scrum страдают лучшие сотрудники, потому что R&D эффективно устраняется. Одержимость краткосрочными «итерациями» или спринтами означает невозможность опробовать нечто новое, рискованное.

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

6. Пьяный эффект.

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

С точки зрения менеджера, который не знает, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько «примадонн» уровня 7+ покинут корабль под парусом Дивного Нового Scrum, зато 3-ки и 4-ки станут вполне приемлемыми 5-ками. Проблема в том, что разница между программистами 7 и 5 существенно больше, чем между 5 и 3. Если вы потеряете своих лучших людей и своих лидеров (которые необязательно находятся на руководящих ролях), то небольшое повышение уровня некомпетентных, для которых предназначен Scrum, не приносит пользы.

Scrum и Agile играют в то, что я называю предвзятостью к смене статуса. По сути, многие люди судят о своих успехах или неудачах не объективно, а исходя из субъективных изменений в статусе. Убедить программиста уровня 5 согласиться на зарплату программиста уровня 3 в стартапе (в обмен на долю в стартапе) психологически расценивается не как потеря денег, а как серьёзная прибавка в статусе.

Agile/Scrum и культура дискриминации по возрасту в целом касаются получения наиболее впечатляющей статусной прибыли, а не фактической экономической прибыли. Её можно достичь, как правило, путём найма людей, которые принесут наибольшую ценность (даже если вы предлагаете на 50% выше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной ставки).

Люди, которые меньше всего осведомлены о том, какой социальный статус они «должны» иметь — это молодёжь. Вы найдете 22-летнего программиста уровня 6, который думает, что у него уровень 3 и который согласится на Scrum, но 50-летний уровень 9, вероятно, знает, что у него 9 и может неохотно принять условия уровня 8,5, но точно не опустится до 3 или даже 6. Поиск статусной прибыли, конечно, бесполезен. Эти пункты ничего не значат. Вы выигрываете в бизнесе на разнице в доходах и расходах, а не на разнице в бессмысленных пунктах статуса. Может быть, существует целая индустрия в привлечении инженеров 5-го уровня, расценивая (и оплачивая) их как 4, но в нынешних рыночных условиях гораздо выгоднее нанять 8 и относиться к нему как к 8.

7. Нечестная реклама.

Здесь я сосредоточусь на Scrum. Некоторые утверждают, что Scrum является «экстремистским вариантом Agile», а другие — что это самый далёкий вариант от истинного Agile. (Возможно, здесь проявляется одна из проблем: мы не можем договориться о том, что является и не является Agile).

Решениям вроде Scrum есть своё место: очень ограниченное, временное. Нечестно говорить, что оно работает везде и на постоянной основе.

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

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

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

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

Таким образом, Scrum признаёт идею, что иногда власть нужно делегировать «экстренным» руководителям: они будут делать всё, что считают необходимым, чтобы выполнить работу, оставив споры на потом. Всё нормально. Иногда всё должно быть именно так.

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

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

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

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

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

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

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

25 Янв 2016

Гибкие методологии набирают популярность за пределами ИТ, крупные компании всё чаще рассматривают Scrum в качестве альтернативы классическому проектному управлению. Но прежде чем приступить к внедрению гибких методик управления проектами необходимо найти ответы не несколько вопросов, таких как: подходит ли Agile нашей компании? Подойдёт ли существующая организационная структура для таких изменений? Как измерить отдачу от внедрения?

Во многих ситуациях внедрение Agile может серьёзно повысить производительность и улучшить результативность всех членов команды. Однако недостаточно просто нанять «гибкого» менеджера проектов (Agile Project Manager (APM) – прим. пер.). Для успешного внедрения и использования гибких методологий необходимо изменение всей организации, метрик и образа мышления.

Хотите использовать гибкие методы? Вам нужна гибкая организация!

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

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

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

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

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

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

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

Источник: http://www.esi-intl.co.uk/blogs/pmoperspectives/index.php/agile-project-management-a-shift-in-metrics-and-mindset/

Как разработать “проект-огонь” с методологией Agile?

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

Что такое Agile?

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

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

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

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

Как пользоваться Agile?

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

6 этапов Agile-разработки:

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

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

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

• Внедрение, кодирование и развитие. А также создание и начальное тестирование основных функций.

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

• Выпуск. После всех видов тестирования, продукт передается заказчику.

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

Инструменты Agile сконцентрированы на гибкости и усовершенствовании. Здесь мы объединили несколько основных преимуществ методологии Agile.

Как это работает? 6 ключевых преимуществ Agile для менеджеров проектов:

1. Приспособиться к изменениям в ходе реализации проекта с более короткими циклами планирования не составляет труда. Вы всегда можете уточнить и изменить приоритеты по отстающим вопросам. Также позволить команде вносить изменения в проект.
2. Конечная цель может быть невидимой. Методология Agile может быть полезна для проектов с неопределенными конечными целями.
3. Высокое качество и быстрые стандарты доставки. Из-за разбивки проекта на итерации, команды могут быть сфокусированы на разработке и тестировании.
4. Сильное взаимодействие команды. Методология обеспечивает прямое взаимодействие. Люди могут работать вместе и совместно брать на себя ответственность.
5. Клиенты могут работать в тесном сотрудничестве с командой. Они могут внести свой реальный вклад и оказать воздействие на продукт.
6. Постоянное улучшение. Проекты на основе метода Agile подразумевают обратную связь от пользователей и членов команды.

Читайте также: Критерии успешности проекта.

5 главных недостатков метода

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

1. Процесс планирования может быть менее конкретным. Иногда бывает трудно определить конкретную дату поставки. Некоторые элементы, запланированные к реализации, могут не быть завершены в срок. Это происходит потому, что менеджеры часто вносят изменения приоритетов при решении текущих задач.
2. Команда должна знать все детали и факты. Как правило, команды Agile-проектов небольшие, и их участники должны быть «подкованы» в разных областях.
3. Время для развития. Успешное Agile-движение происходит тогда, когда команда полностью посвящена проекту.
4. Команды часто забывают о документации. Лучше всего найти баланс между бумажными вопросами и личными встречами.
5. Конечный продукт может сильно отличаться от того, что было изначально задумано. Вы можете добавлять новые итерации, поскольку метод подразумевает гибкость.

Основные обязанности менеджера Agile-проектов:

• Поддержание всех активностей и ценностей в проектной команде.
• Устранение помех и препятствий.
• Проведение и модерирование всех совещаний.
• Обсуждая путей преодоления препятствий.
• Работа с приоритетами, усиление отстающих вопросов в рамках процессов.
• Мотивирование. Руководители проектов должны быть основными мотиваторами для своих команд.

Читайте также: О методе критического пути (critical path method) и иерархической структуре управления.

Сравнение гибких методологий

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

Список методов Agile:

XP (Extreme Programming)

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

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

FDD (Feature driven development)

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

ASD (Adaptive system development)

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

Kanban

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

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

Crystal Clear

Crystal Clear – еще один пример методологии Agile. Он чаще всего используется командами из 6- 8 разработчиков. Crystal Clear преимущественно сфокусирован на людях, а не на процессах.

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

Scrum

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

Scrum-разработка: участники процесса

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

• Владельцы продукта несут ответственность за все бизнес-вопросы проекта. Они имеют право принимать решения о продукте и могут сбалансировать все приоритеты.

• Scrum-мастер помогает членам команды работать вместе и получить наиболее эффективные результаты. Он устраняет препятствия, отслеживает прогрессы и проблемы, облегчает обсуждения, организовывает встречи и т.д.

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

5 ресурсов для работы с Agile-проектами

JIRA

Одна из классических систем для решения задач и управления проектами онлайн. Задачи в JIRA состоят из названия, типа, темы, приоритетности, содержания и компонентов.

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

HP Agile Manager

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

GanttPRO

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

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

Basecamp

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

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

Bipulse

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

Пример работы с проектом в JIRA:

Пример работы с проектом в GanttPRO:

А вы использовали методологию Agile в своей работе?

Что вы можете сказать о результатах вашего проекта?

Получился ли тот самый “огонь”?!