Сейчас модно говорить о agile-методологии, особенно о scrum. Поскольку скрам за последние годы преувеличил свои преимущества, мы склонны думать, что это единственный путь. Но так ли это?
Есть еще один подход: создание водопада MVP с помощью экстремального программирования. Это по-прежнему гибкий подход, но не схватка.
Представьте, каково было бы работать три дня в неделю подряд, без всяких совещаний, без перерывов. Работа с фокусом только на одной функции, которая не является самой маленькой (также не должна быть большой). Представьте, что ваша рабочая функциональность выполняется за три дня, а не за один спринт, который длится две недели. Представьте, что у вас есть только один день в неделю, полный встреч и планирования. Где полдня вы будете планировать с менеджерами, владельцами продукта и т. д., другие полдня планировать с коллегами-разработчиками программного обеспечения задачи шаг за шагом, определять техническую сторону функционала и записывать шаги.
Например, владелец продукта хочет, чтобы изменение существующей таблицы было динамическим, поэтому вам нужна форма для добавления новых данных в таблицу.
Шаги будут такими:
- Напишите интерфейс данных на пост и получите
- Решите, как вы будете удалять строки. Если вы хотите оптимизма или пессимизма, удалите.
- Запишите методы и нарисуйте архитектуру, если вам понадобится новый компонент для формы.
- Наконец, обсудите технический процесс с коллегами.
- Работайте три дня, договорившись, что у вас есть один час в начале или в конце дня для возможных встреч и координации.
- На пятый день проведите обзор с коллегами и немного расслабьте свой мозг или время на рефакторинг.
Разве это не звучит здорово? С точки зрения разработчика такой подход вознаградит вас. Это будет мотивировать вас. С точки зрения руководства, процесс пойдет быстрее. Так в чем же причина того, что оно не так распространено Иногда даже менеджеры и разработчики не знают термина экстремальное программирование.
Ну… Короче говоря: чтобы использовать такую технику, вам нужна доминирующая и способная команда, а также отличные разработчики, которые, скорее всего, будут дорогими, потому что:
- Владелец продукта должен иметь четкое видение и писать идеальные истории.
- Разработчики должны чувствовать бизнес. Они должны предложить некоторые решения, основанные на рассказе.
- Некоторые функции могут быть написаны расплывчато. Но разработчик на основе своего опыта должен понять хотя бы MVP из истории и предложить решение.
- Разработчик не должен посещать много совещаний! У разработчика должна быть четкая дата в календаре для встреч, это должен быть понедельник. День планирования должен быть разделен на две части: планирование функций и техническое планирование. В первой части команда обсуждает важность, влияние и смысл новой логики или если есть задачи поменьше, то вы их заказываете и разработчики остановят вас, когда посчитают, что объем работы больше 3-х дней. Во второй части техническая часть вашей команды обсуждает подход и описывает методы и шаги, которые необходимо выполнить. (Конечно, если во время второй части будут какие-то блокираторы, это нужно еще раз обсудить с руководством).
- Менеджменту нужно понять, чтобы перестать планировать внутри спринтов, работа будет выполняться еженедельно на основе согласованной работы, и после некоторого времени практики вы получите понимание объема работы, выполненной в рамках таких циклов, и на основе этого вы можете планировать кварталы .
- Фокус, фокус и еще раз фокус
Что может пойти не так с экстремальным программированием?
Даже с одним немотивированным товарищем по команде долго не протянешь. Процесс прервется. В то же время неправильно понятый бизнес может нанести большой ущерб. И хуже всего то, что это не для младших разработчиков, поскольку у каждого человека должно быть свое время, сосредоточенное на истории без перерыва.
Подводя итог, экстремальное программирование — это мощный способ разработки программного обеспечения, его сложно правильно настроить, и только самая продвинутая команда может с ним справиться. Поэтому я рекомендую хотя бы попробовать и почувствовать, чего можно достичь сфокусированной работой и идеальным управлением. Я думаю, что команда, которая хоть раз успешно попробовала этот подход, уже никогда не вернется к традиционному управлению. С экстремальным программированием легко экспериментировать, пробовать непрерывные релизы и многое другое.
