Рассказы PRO: Гибкие методологии в разработке на Java
Мы пообщались с Александром Суходоловым, Senior Java-разработчиком компании Centicore Group, чтобы узнать, как современные гибкие методологии разработки помогают решать сложные задачи в сфере IT. Александр поделился своим опытом использования agile-подходов, рассказал о предпочтениях между Scrum и Kanban, а также мы обсудили нюансы работы с техническим долгом и автоматизированными тестами.
- Можете рассказать о проекте на Java, где agile-подход значительно улучшил результат? Как это повлияло на рабочий процесс?
Большинство проектов, в которых я участвовал на Java, так или иначе использовали agile-подход. Это позволяет максимально быстро доставлять ценность пользователю. Agile — итеративный процесс с постоянными уточнениями и изменениями. Мы проверяем гипотезы, вносим изменения, и это действительно ценно, потому что изначальные гипотезы могут быть ошибочны.
Например, сейчас мы разрабатываем детский банк. Пользователи — дети от 6 до 14 лет, и они все совершенно разные. То, что взрослому человеку кажется очевидным, для ребенка может быть непонятно. Мы проводим исследования с детьми сотрудников, смотрим, как они взаимодействуют с продуктом — например, насколько быстро ребенок находит нужный пункт в меню. Это помогает нам понять, что работает, а что нет. В современном мире странно было бы не применять agile-методы при разработке, особенно для пользовательских продуктов.
– А какой у вас был опыт работы с waterfall-подходом?
У меня есть опыт работы по waterfall. Я уже давно в IT, и раньше эта методология была основной. В waterfall есть контрольные точки, но коррективы в процесс вносятся только на определенных этапах. Если посмотреть на IT 15 лет назад, то waterfall был довольно распространен, особенно в тех проектах, где нужно было выполнять задачи строго по плану.
Но в бизнесе даже тогда часто требовалась гибкость, потому что задачи менялись быстро, и пользователи требовали других решений. Это был не явный agile, но гибкость присутствовала, потому что требования изменялись на ходу.
- А если говорить про Scrum и Kanban, какой подход вам больше нравится для разработки на Java и почему?
Я не приверженец какой-то конкретной методологии. Методология должна соответствовать задачам. Например, если взять команды в Google или Amazon, у них нет жесткого подхода. Они используют то, что лучше подходит для их задач.
Мне лично ближе Kanban. Хотя мы работаем по Scrum, у нас есть все артефакты Scrum, такие как спринты, но задачи визуализируются на Kanban-доске. Это удобно. У нас используется смешанный подход. В зависимости от периода разработки, мы можем использовать разные методы. Когда мы разрабатываем большую фичу, которую сложно разложить на мелкие задачи, то стандартный Scrum может не подойти. Например, аналитика по фиче может занять целый месяц, и это просто не укладывается в двухнедельный спринт. В такие моменты Scrum становится негибким, и поэтому приходится использовать что-то вроде Kanban.
- Были ли случаи, когда гибкие методологии не срабатывали для разработки сложных Java-приложений? Как вы решали такие проблемы?
Да, был такой случай, когда мы разрабатывали детскую копилку. Это большой продукт, хотя для пользователя он может не казаться таким сложным. У нас были моменты, когда в течение двух месяцев мы не выпускали никаких обновлений. IT-Lead приходил и говорил: “Ребята, может, вам нужно как-то нарезать задачи, чтобы что-то поставить?”. Но для нас это не имело смысла — делать искусственные поставки, которые не имеют никакой ценности для бизнеса, только чтобы показать результат.
Здесь все решалось через договоренности: объясняли, почему мы не можем поставить что-то полезное в течение спринта, и находили компромиссы.
- Часто ли бывает, что несколько месяцев нет никакой ценности для бизнеса?
Скорее нет. Это случается, когда разрабатываются большие фичи. Например, недавно парень из Google рассказывал, что у них задачи могут длиться по 1-2 месяца, и двухнедельные спринты для них просто не подходят.
- Как вы проводите рефакторинг Java-кода в условиях непрерывной разработки и коротких циклов спринтов?
У нас в команде сервисы достаточно новые, поэтому большого легаси нет. Если мы понимаем, что рефакторинг не срочный, то делаем его “по-хорошему” — переписываем код. Если задача горит, можем сделать временное решение, но обязательно договариваемся, что это потом будет исправлено. Иногда, если рефакторинг небольшой, его можно провести, даже не сообщая об этом, просто делая свою работу.
- А как ваша команда организует взаимодействие при деплое Java-приложений? Как это зависит от выбранной методологии разработки?
Мы не привязываемся к спринтам для деплоя. Мы можем деплоиться по мере готовности задач. Здесь между Scrum и Kanban нет разницы, потому что как только задача готова, мы можем её деплоить.
- Какую роль играют автоматизированные тесты в процессе разработки на Java в условиях agile?
Автоматизированные тесты играют очень важную роль. Они пишутся в первую очередь для разработчика, чтобы ускорить разработку. Ты пишешь функциональность, запускаешь тесты, и если тесты падают, то сразу видишь, где ошибка. Это позволяет уверенно двигаться вперед, понимая, что твой код работает так, как ты задумал. Иногда тесты занимают больше времени, чем написание самого кода, но это ускоряет работу в будущем.
- А как вы справляетесь с техническим долгом в Java-проектах?
Стараемся не допускать его появления. В нашей компании есть тех время — 20% рабочего времени выделяется на тех таски. Иногда тех таски и тех долг пересекаются, например, при переходе на новую технологию. Если тех долг есть, можно выделить отдельный спринт для его устранения. Главное — чтобы продукт оунер (PO) понимал важность этих задач и не давил на команду с требованиями новых фич.