Agile у каждого свой: как плыть по течению, управлять проектами и не страдать
Вы, конечно, знаете, что это метод гибкой разработки ПО. Некоторые учатся: ходят на курсы, слушают лекции, потом с адской болью внедряют эти принципы в процесс работы команды, а кто-то просто работает на совесть, не пытаясь называть это модным «Agile». Тут нет и не может быть никакого идеального решения, потому что все люди разные, с разным ритмом, представлением о работе и характерами. Так и не все команды могут работать по одинаковым принципам.
Рассказываем о том, что Agile это не свод правил, высеченный в камне, а советы, которые команды могут применять. Или нет. Учимся мудро подходить к организации рабочего процесса. И использовать на практике только те принципы, что близки вам (ну и заказчику!).
Ну, а узнать больше о том, как реально работает этот метод в компаниях, как управляют проектами с его помощью и почему даже крупные банки всё же держат у сердца манифест Agile, можно на вебинаре, который состоится 11 апреля в 17:00.
Наша мысль проста: нельзя слепо следовать тенденциям и начинать с понедельника работать по новой системе. Пытаться делать это = завалить рабочий процесс. ВЖУХ, Agile — ожидания от актуальной методологии могут не совпадать с реальностью. Если ваша работа после попыток внедрить Agile выглядит так, не пугайтесь. Вы на правильном пути (наверное):
// Ваш почтовый ящик забит комментами, а в Jira куча новых задач. Но вы их отчаянно систематизируете и стараетесь даже просматривать аналитику.
// Ваши клиенты стараются адекватно воспринимать процесс вашей работы и иногда даже и отдают себе отчет в том, как создается и запускается софт.
// Ваш код не идеален, вы меняете всё до последнего момента, что-то прикручиваете, и это нормально. Вы не пишете коммент к каждому новому символу и иногда с вами случаются разработческие траблы.
// Вы выкатываете новые версии, бесконечно что-то тестите, но не всегда это является залогом идеальной работы. Даже если всё идёт по графику.
// Заказчик всегда с вами на связи. Круглосуточно, из каждого принтера смотрит на вашу работу.
// Иногда в вашей команде случается полный Scrum, тогда все действительно бегают как спринтеры, а ещё стараются быть гибкими и вообще видеть коллег!
// «Работающий продукт — основной показатель прогресса,» — гласит Манифест Agile. Велосипед едет, а педали потом прикрутим.
А если серьёзно, то не стоит воспринимать Манифест Agile как Библию.
Или категоричные утверждения о том, что такое хорошо, а что такое — плохо. Суть в том, чтобы наладить и оптимизировать работу, сократить временные затраты, выкатывать продукт с умом, радовать заказчика. Так что читайте между строк и знайте, что даже в 4 основных принципах Agile нужно видеть не категоричные правила, а умение расставлять приоритеты:
Люди и взаимодействие (коммуникация) важнее процессов и инструментов.
И это точно НЕ значит, что процессы и инструменты не важны. Налаженные процессы — это то, что позволяет компаниям учиться и со временем совершенствоваться, а следование установленным внутри процедурам ведёт к результатам. Инструменты же могут фундаментально менять отношение команды к проблемам и умению их решать. Есть такая известная поговорка: если у вас есть только молоток, то и каждая проблема выглядит как гвоздь. Не ведитесь на это и продолжайте внедрять новые инструменты, налаживать процессы внутри компании и при этом обращать внимание на людей.
Работающий продукт важнее исчерпывающей документации.
И это точно НЕ значит, что документация — переоцененная и консервативная ерунда.
Не каждая деталь каждой линии кода должна быть прокомментирована и задокументирована, как и не каждое требование должно быть описано на микроуровне. Но без надлежащей документации вы рискуете потерять много времени при любых изменениях в вашем продукте, а ещё — сломать всё, что делалось долго и с трудом. Если вы не знаете, где вы находитесь, вы не сможете добраться туда, куда хотите. Ну и не забывайте, что люди иногда болеют, увольняются, ну и уходят на пенсии — собирайте максимум информации, чтобы смена членов команды никогда не приводила к замедлению работы.
Сотрудничество с заказчиком важнее согласования условий контракта.
И это точно НЕ значит, что условия контракта это чушь. Это не так. Скажем, вполне может быть, что условия широки и конкретный результат у вас не прописан перед стартом работы над продуктом). И если обе стороны сотрудничают, помогают друг другу, то в конце концов все участники должны быть удовлетворены. Вопрос только в том, не связались ли вы с людьми, которые вообще не шарят в создании софта. Тогд и работа не заладится, и требования к результату могут быть безумными.
Готовность к изменениям важнее следования первоначальному плану.
И это точно НЕ значит, что планировать ничего не надо. План — это важно, это вообще чудодейственная основа Agile. Но суть как раз в том, что план не надо выбивать в камне сразу. Над ним нужно работать и совершенствовать. План на ближайшее время работы должен быть. Благодаря ему можно распределять обязанности, делегировать задачи и следить за решением каждой проблемы. Короткосрочный план может быть изменен при необходимости, по запросу вашего заказчика.
Подключайтесь к крутейшему вебинару об Agile и реалиях использования методологии в рамках крупных компаний (спойлер: банка), который состоится уже завтра.
