В одном из наших постов мы уже рассказывали о некоторых гибких методологиях. В этом материале предлагаем посмотреть на причины провалов 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. Наши материалы о методологиях разработки программного обеспечения:
- «Гибкая разработка»: кратко о методологиях Agile
- Кратко о методологиях разработки ПО: Waterfall, Lean и Feature Driven Development
P.P.S. Материалы по теме из блога «ИТ Гильдии»:
Автор: it-guild
