Pull to refresh
55.51
Rating
Alconost
Localization in 70+ languages & video production

Почему Agile иногда не работает

Alconost corporate blog IT Terminology Development Management *Project management *Agile *
Translation
Original author: John Cutler

Пару лет назад я заходил к родственнику. Моему бедному кузену (а он генеральный директор страховой компании) продали «серебряную пулю Agile» — но она не сработала, и его это очень расстроило:
Чушь всё это! Мы начали делать всё совершенно иначе. Мы пригласили консультантов. Мы наняли специальных руководителей проектов. Не сработало! Ничего не изменилось. Никто ни за что не отвечает. Я слышу только оправдания.
Не помню, что я ответил тогда, но знаю, как ответил бы сегодня. Я бы набросал несколько рисунков, словом не упомянув Agile. Пришлось бы объяснить кузену несколько основных понятий…

Переведено в Alconost

1. КПД процесса


Во-первых, если посмотреть на срок разработки — время, прошедшее с момента появления идеи до момента, когда ее воплощение дойдет до клиентов, — можно заметить, что большую часть времени занимает «ожидание». 15-процентный КПД (время фактической работы / срок разработки) — это нормально. Звучит странно, да? Но давайте пристальнее взглянем на то, что находится вроде бы на виду: на собственно выполнение работы тратится малая часть времени. У лучших компаний этот показатель достигает 40%. В общем, чтобы ускорить разработку, нужно сократить время «ожидания».



2. Незапланированная работа и многозадачность


Обычное дело, когда 75% ресурсов уходят на незапланированную работу и переключение между задачами. Команда может даже не понимать, что все происходит именно так. Это в буквальном смысле «накладные расходы», которые часто даже не отслеживаются в системах учета задач. Скорее всего, команда на такое положение дел жалуется (поскольку это ужасно раздражает), но если на эти жалобы достаточно долго не обращать внимания, люди просто принимают мрачную действительность как данность.

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

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



3. Маленький, средний и большой


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



4. Реализация коммерческой выгоды


Множество усилий тратится на снижение того, что я называю «риском поставки» — это когда вы делаете проекты на заказ, а клиент оплачивает работу по факту поставки готового продукта. В случае SaaS (ПО как услуга) нам платят не по факту сделанной работы — коммерческая выгода нарастает со временем. Я называю это «риском коммерческой выгоды» (риск того, что работа окажется коммерчески бесполезной).

Крупные организации часто внедряют методологию гибкой разработки, но не видят ожидаемого повышения коммерческой выгоды. Причина в том, что разработка, конечно, идет быстрее, но это не влияет на 1) принятие правильных решений по продуктам и ​​2) работу над реализацией того, что дает коммерческую выгоду. ВЕСЬ СМЫСЛ методики Agile — снижение риска. В терминах работы над проектом риск определяется выполнением работ по графику и обеспечением заданной функциональности. Тот же риск в терминах продукта выражается так: «Эта штука ни черта не работает!» Поэтому заказчику нельзя соглашаться на «принятие» некоторой функции, если коммерческой выгоды от нее нет.

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



5. Неуправляемая сложность


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



Agile


А вот теперь поговорим про «гибкую разработку». Методология Agile бесполезна, если она не служит катализатором непрерывного совершенствования — то же касается методов Scrum и фреймворка SAFe. Дело в том, что замедление работы лишь частично объясняется тем, что вы используете «спринты», записываете «истории пользователей» или каждые две недели выпускаете демо-версии. И я могу поспорить, что перечисленное вносит относительно небольшой вклад (это становится понятно, если врубиться в идею постепенного снижения риска).

Придерживаться гибкой методологии разработки — это значит тратить много денег и усилий на следующее:

  • Делать то, что действительно имеет значение (коммерческая выгода). Делать меньше.
  • Автоматизация, внедрение инструментария, конвейер развертывания, управление функциональностью (feature flags) и т. д. (DevOps).
  • Изменение культуры управления.
  • Пересмотр финансирования инициатив. Переход на поэтапное финансирование на основе целей и задач и отказ от финансирования проектов.
  • Выделение ресурсов для управления сложностью (регулярные рефакторинг и пересмотр архитектуры проекта).
  • Распределение потоков создания ценности и подход к компании как к обслуживающей экосистеме.
  • Новое понимание «совмещенных услуг».

Нет никакой «серебряной пули» — нужно работать. И остерегайтесь тех, кто говорит иначе.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com
Tags:
Hubs:
Total votes 13: ↑9 and ↓4 +5
Views 15K
Comments Comments 12

Information

Founded
2004
Website
alconost.com
Employees
201–500 employees
Registered