Пару лет назад я заходил к родственнику. Моему бедному кузену (а он генеральный директор страховой компании) продали «серебряную пулю 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

Комментарии (11)


  1. nkozhevnikov
    25.10.2017 09:20

    Было уже.
    habrahabr.ru/post/340096


    1. alconost Автор
      25.10.2017 09:31

      Жаль. Зато мы перевели с картинками :)


    1. sparhawk
      25.10.2017 16:57

      Тот перевод невозможно читать, к сожалению


  1. Neraverin
    25.10.2017 10:22

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


  1. Dmitry_7
    25.10.2017 12:38

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


    1. vyatsek
      25.10.2017 16:52

      На самом деле все успешные проекты, сделаны по аджайлу. Только сами авторы этого не знают :)
      Принцип аджайл декларируют чуть детальнее подход называемый «здравый смысл». Любой успешный проект сделан с подходом здравого смысла, иначе бы проект не «взлетел». Принципы делкарируемые Agile работали за долго до него. Проходимцы-продаваны присовили эти принципы Agile, так же как LGBTшники себе радугу.


      1. yorick_kiev_ua
        27.10.2017 08:15

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

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


    1. kozzztik
      25.10.2017 18:47

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


      1. lxsmkv
        25.10.2017 20:31

        burnout графики
        опечатка по Фрейду :)


        1. kozzztik
          25.10.2017 20:48

          да, простите. Просто выгорание нынче горячая тема )


  1. lxsmkv
    25.10.2017 21:25

    просто оставлю тут ссылку на манифест программиста programming-motherfucker.com ( macode.ru )