Недавно наткнулся на интересную статью «Меня беспокоит Agile, и я хочу об этом поговорить». В ней рассказывается про тюнинг этого процесса с точки зрения менеджера.
Мне же захотелось описать, что такое agile для меня как программиста. Без манифестов и громких слов. И что в нем особенного по сравнению с другими методологиями.
Предистория
Я работаю программистом в течение 9 лет. За это время попробовал себя в 7 компаниях от совершенно «беспроцессных» до сертифицированных СММI 5 уровня (кто знает, что это такое, не стоит сдерживать улыбку)). С этой компании с самым «строгим» в моей жизни процессом я и начну…
2008 год. Компания Моторола. Я параллельно заканчивал обучение в институте и имел 3 года опыта работы по специальности за спиной. В общем, считал себя опытным программистом. И тут в первый (и, надеюсь, последний) раз столкнулся с по-настоящему «негибким» процессом. Моторола очень гордилась своей сертифицированной CMMI Level 5 моделью разработки ПО и собственной концепцией управления производством от 1986 года Six Cigma.
Вполне допускаю, что для разработки железа тот процесс мог быть полезен. Возможно, что ПО для покорения космоса тоже стоит создавать под чем-то подобным. Но когда для написания простых клиентских приложений требовалось документации в несколько раз больше, чем кода, то это уже полный абсурд. Я чувствовал себя настоящим научным работником. Только вместо исследования кривизны пространства-времени, писал многостраничную документацию об имплиментации крошечного JSR. Который, к сожалению, не позволял направить ракету на марс, а лишь реализовывал API для получения уровня заряда батареи телефона.
Тогда я думал, что возможно так надо в больших компаниях и надеялся, что этим хотя бы достигается высокое качество продуктов, которыми пользуются миллионы человек. Но чем дольше я работал по такому процессу, тем больше осознавал бесполезность всех этих документаций. Как минимум, потому что большинство из них никто никогда не читал, а времени на создание и многоуровневые review тратилось уйма. При этом на качество кода это никак положительно не влияло.
И тут у Моторолы кончились деньги и настал cost saving. Начальство нам отчиталось, как много финансов удалось сэкономить, убрав одноразовые ложки из компанейских столовых по всему миру, но на этом не остановилось. Наш процесс разработки был резко преобразован в Agile.
Отличия от «негибкой» Моторолы
Что изменилось? Все.
Основные отличия:
- Мы перестали писать документацию
Вместо нее начали вставлять комментарии прямо внутри кода и Javadoc для классов и публичных методов. При этом стало понятно, для кого мы это пишем (для своей команды). Также эти комментарии не подвергались многоступенчатому review. - Мы стали следить за качеством своего и чужого кода
Освободилась куча времени от строгих документаций и теперь в основном стали уделять время именно коду и его качеству. При этом код должен был рождаться еще и самодокументированным. - Начались ежедневные стендапы
Наконец я узнал, кто работает в моей команде и чем занимается. - Изменилась цель работы
Фокус с документаций и множества формальных процессов вдруг резко сместился на качество кода и скорость разработки продукта. - Изменилась скорость разработки
До этого я не мог представить, что даже в большой компании не обязательно работать целый год, чтобы до продакшена дошли твои 100 строк кода. Оказалось, что для этого достаточно пары часов. - Agile в дизайн тим:))
У дизайнеров тоже настали «гибкие» методологии. Они стали менять дизайны и концепции каждый спринт. В общем, сильно усложнили жизнь разработчикам и менеджеру. - Время работы
Никаких 8 часов… увы, но работать я стал больше. В основном, правда, по собственной инициативе=)
Отличия от беспроцессности
При этом, я вспоминал свою первую компанию, у которой не было вообще процесса.
С ней тоже было много отличий:
- Средства распределения усилий внутри команды
Мне понравилось, что при ежедневном обсуждении и переклеивании бумажек, вся команда находится в полной осведомленности об успехах каждого (при искренности последнего). Таким образом, стахановцев легко удавалось направлять на помощь отстающим. - Время разработки
Когда не было процесса, тогда не было и четкогого времени релиза. Вернее, оно изначально доносилось, но за неимением средств делегирования усилий внутри команды, редко соблюдалось. Или же наверх без стеснения выдавался некачественный продукт. - Ты уже больше не хозяин своей фиче
Если раньше я говорил, что сделаю такую-то функциональность в продукте и занимался ей, порой, в Пи раз больше, чем планировал, то теперь это стало невозможным.
Во-первых, еще при планировании кто-то мог теперь сказать, что он сделает данную функциональность быстрее и тогда я терял возможность ей заниматься.
Во-вторых, даже при «выигрыше» фичи, я ей занимался только пока все шло по плану. При задержках появлялось 2 варианта: выделялся помощник/преемник или фича переносилась на следующий релиз. Время окончания спринтов никто старался не сдвигать. - Появился смысл делать быстрее (для экстровертов)
Скажу прямо — мне нравится, когда меня хвалят и потому Agile очень способствовал желанию делать все быстрее и качественнее возможного, потому что все теперь видели мой прогресс каждый день. - Появились ужасно нудные и неловкие 15 минут перед всеми каждый день (интроверты)
Такое я тоже слышал и в основном от интровертов — им вправду было действительно не по себе на стендапах.
Итог перехода на Agile
Наша команда разрабатывала приложение myFaves. Его надо реализовать для каждой платформы телефона, который компания хочет продаваться через мобильного оператора T-Mobile. Таким образом, данное приложение разрабатывалось десятки раз в стенах Моторолы. Но именно нашей команде удалось уложиться в самые короткие сроки за всю историю компании. Качество же тоже оказалось на самом высоком уровне, в результате чего оператор принял наш продукт на первом же test cycle. При этом разработка велась командой, обучавшейся этой системе по ходу создания продукта. Да и Андроид тогда еще был очень сырым. К тому же некоторые вроде меня обучались и самой Java.
Дальнейшие мысли
После этого, мне довелось ещё познать разные виды процессов, работая в Корее в Самсунге, затем в отечественных и американских компаниях. Но пока все вернулось снова к Agile в моей текущей компании Netflix.
Плюсы Agile
При этом я полностью понимаю, почему весь мир переходит на гибкие методологии. И для меня как инженера есть ряд незаменимых плюсов этого процесса:
- Мотивация
Иногда бывает тяжело заставить себя работать. Я знаю, что никто за мной не следит, все мной довольны и потому возникает большой соблазн пострадать фигней, читая бесполезные новости или зависая в соц.сетях. И тут на помощь приходит стендап!
Как говорил Фрейд: «все наши поступки берут начало в двух мотивах: в сексуальном влечении и желании быть великими». Именно это желание заставляет меня всерьёз готовиться к каждому стендапу. Я даже замечал, что в дни когда стендапа не будет, мне сложнее собраться и сделать запланированный объём работы. - Гибкость
К сожалению, в программировании иногда трудно точно предсказать, сколько времени займет конкретная задача. И очень хорошо, когда процесс позволяет исключать некоторые задачи из данного спринта прямо по ходу его выполнения или перераспределять ресурсы, если оказывается, что в первоначальных оценках была ошибка. - Внутрикомандная синхронизация
Мне нравится, что команда собирается каждый день и узнает, кто чем сейчас занимается, что планирует делать, какие проблемы были решены, а какие есть. На моих глазах часто тупиковые проблемы решались за несколько минут, когда вся команда после стендапа (или иногда прямо во время в нарушении идеологии) собиралась вместе и думала над проблемой одного. - Качество кода
Когда инженерным лицом продукта является не какая-то документация, а сам код, то и отношение к нему формируется намного более серьезное. Соглашусь, что во многих методологиях коду уделяется очень большое значение, но мало в каких код — это практически единственный результат работы инженера. И git blame ему потом судья. - Ревью
Мне нравится, что ревью в этом процессе довольно неформальные и действительно позволяют сконцентрироваться на совершенствовании кода. При этом, мне лично больше всего импонирует трактовка Agile, в которой code review проводится в очной форме. Я понимаю, что это не современно и не всегда возможно (особенно когда некоторые работают удаленно). Но если анализировать не просто код, а еще и слышать мнение автора: почему он сделал именно так и что этим хотел добиться, то намного проще уловить ошибки в рассуждениях или увидеть идеи для улучшения.
Минусы
Также в глаза бросается и неидеальность данного процесса:
- Меняющиеся требования
При постоянно меняющихся требованиях трудно соблюдать исходные сроки реализации самого продукта. А иногда вдруг может даже выясниться, что не все возможно выполнить в отведенные сроки и придется еще что-то срочно менять.
- Отменённые фичи
Когда программисту говорят, что твои усилия были напрасны и реализованную фичу решено не вносить в грядущий релиз — это редко способствует его воодушевлению…
- Дизайн Тим
«Гибкий» процесс для дизайнеров часто становится адом для программистов. Часто приходится переписывать код, объяснять, что так сделать быстро не получится, а данное изменение вообще делает напрасным всю предыдущую работу. Имхо, для них лучше иметь красный свет перед началом реализации фичи.
- Потеря времени во время стендапов
Редко удается уложиться в 15 минут и большая часть времени порой оказывается бесполезной для многих участников стояния.
- Плохой код одного может сильно навредить
К сожалению, Agile очень чувствителен к качеству работников и их коду. В этом процессе нерадивые программисты могут слишком сильно осложнить жизнь всей команде.
- Личная жизнь
Время работы обычно тоже становится «гибким». И под час очень трудно четко предсказать, во сколько удастся освободиться и не придется ли на выходных что-то срочно доделывать.
- Unit test driving development
Имхо, есть в Agile ряд идей, которые мне кажутся утопическими. Тратить кучу времени на разработку юнит-тестов и потом писать код, чтобы они завершались успешно? Возможно, есть проекты, где это имеет смысл. Но то, что встречалось мне обычно требовало месяцев работы программиста для разработки юнит тестов, которые не покрывали и 5 минут реального тестирования профессионалом. Какой-то минимальный набор автоматических тестов наверное необходим, но разрабатывать по ним весь продукт, имхо, несет намного больше затрат времени чем пользы. - Pair programming...
Мне реально помогал этот метод 3 раза в жизни. Но это должно быть реально востребовано данной задачей (по опыту, обычно каким-то сложным багом), а не использовано как метод ради метода.
В заключении, вспоминается известная фраза Уинстона Черчилля про демократию, которую вполне можно применить и к Agile:
«Демократия — наихудшая форма правления, за исключением всех остальных, которые пробовались время от времени.»