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

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

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

    Рассказываем о том, что Agile это не свод правил, высеченный в камне, а советы, которые команды могут применять. Или нет. Учимся мудро подходить к организации рабочего процесса. И использовать на практике только те принципы, что близки вам (ну и заказчику!).




    Наша мысль проста: нельзя слепо следовать тенденциям и начинать с понедельника работать по новой системе. Пытаться делать это = завалить рабочий процесс. ВЖУХ, Agile — ожидания от актуальной методологии могут не совпадать с реальностью. Если ваша работа после попыток внедрить Agile выглядит так, не пугайтесь. Вы на правильном пути (наверное):

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



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



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



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



    // Заказчик всегда с вами на связи. Круглосуточно, из каждого принтера смотрит на вашу работу.



    // Иногда в вашей команде случается полный Scrum, тогда все действительно бегают как спринтеры, а ещё стараются быть гибкими и вообще видеть коллег!



    // «Работающий продукт — основной показатель прогресса,» — гласит Манифест Agile. Велосипед едет, а педали потом прикрутим.



    А если серьёзно, то не стоит воспринимать Манифест Agile как Библию.

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

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

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

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

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

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

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

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

    И это точно НЕ значит, что планировать ничего не надо. План — это важно, это вообще чудодейственная основа Agile. Но суть как раз в том, что план не надо выбивать в камне сразу. Над ним нужно работать и совершенствовать. План на ближайшее время работы должен быть. Благодаря ему можно распределять обязанности, делегировать задачи и следить за решением каждой проблемы. Короткосрочный план может быть изменен при необходимости, по запросу вашего заказчика.
    • +10
    • 8.7k
    • 1
    icanchoose.ru
    47.47
    Make your career great again.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 1

      +1
      как плыть по течению, управлять проектами и не страдать

      Забыть о и забить на Agile.

      Кстати, «агиль» — так проганяют гусей. :)

      Only users with full accounts can post comments. Log in, please.