[1/2] Экстремальное программирование: постановка процесса (Extreme Programming Applied: Playing to Win) (Рубрика Engineering)
Сегодня я решил вспомнить книгу про экстремальное программирование (XP) из времен старта моей карьеры (на русском она появилась 20 лет назад, а на английском за пару лет до этого). В этой книге авторы разбирают что такое XP и главное, как его применить на практике. Большая часть практик XP стала стандартом де-факто и сейчас их даже не надо продавать, так как они считаются некоторым baseline для инженерных практик. Но в начале 2000х XP проиграла маркетинговую войну другим Agile подходам навроде Scrum и его вариаций - инженеры не так красиво пели, как любители поговорить за процессы и ритуалы, поэтому скрам был сильно известнее XP:)
Ну а теперь перейдем к самой книге.
Введение: играть, чтобы выиграть - здесь авторы говорят о том, что софт - это изменчивая сущность и нам надо быть готовым к модификациям нашей системы, а для этого надо учитывать стоимость изменений. И старые подходы (аля waterfall и тяжеловесное планирование, проектирование и т.д.) приводили к тому, что стоимость изменений в процессе создания системы экспоненциально росла, поэтому изменений старались избегать. Но в XP все сделано так, чтобы сгладить стоимость изменений. Именно это авторы и предлагали использовать в качестве главного аргумента. XP в кратком изложении - здесь авторы рассказывают про ключевые ценности XP и основные принципы, которые раскрываются дальше на страницах книги и объясняется как их практически применять, а также продавать коллегам для внедрения изменений. Основные ценности XP такие
- Коммуникация (Communication) - работая в стиле XP невозможно избежать общения
- Простота (Simplicity) - XP всегда предлагает решать проблему самым простым способом
- Обратная связь (Feedback) - частый и качественный feedback позволит оставаться продукту/проекту на правильной траектории
- Храбрость (Courage) - для движения с максимальной скоростью нужна храбрость. Плюс надо уметь побеждать sunk cost fallacy
Дальше авторы вспоминают про основные практики, которых всего 12 штук, но в дальше в самой книге они делят их на шесть стартовых и остальные, что надо внедрять во вторую очередь, поэтому я тут начну с первых 6 1) Игра в планирование - здесь авторы рассказывают про планирование и оценку трудозатрат. Фактически, предлагается следующая частотность Release planning (quaterly) -> Iteration planning (2 weeks) -> Standup meetings (everyday). Авторы отмечают важность оценивания трудозатрат для того, чтобы дискутировать с заказчиком на уровне приоритетов задач и стоимости их реализации. Это похоже на общепринятую сейчас практику 2) Частые релизы (Small releases) - частотность релизов и их небольшой размер очень хорошо укладываются в lean практики и позволяют инкрементально получать ценность. А с точки зрения инженерии это позволяет поддерживать нужный темп и не слишком рисковать во время каждого релиза - подробнее рекомендую почитать книгу "Accelerate" (см. мой пост) и про DORA метрики. Это уже стандарт де-факто 3) Тестирование - фактически, авторы рассказывают про TDD и объясняют зачем нам нужны тесты в сложных системах. Это уже стандарт де-факто. 4) Парное программирование - тут речь про работу в паре за одним компьютером при реализации одной задачи. Эта практика так и не стала общепринятой, но вместо нее принято делать design review до реализации задачи, а также code review уже после ее реализации 5) Рефакторинг - здесь авторы вспоминают Мартина Фаулера и его классическую книгу "Рефакторинг", а сам подход сейчас является стандартом де-факто в индустрии 6) Continuous integration - авторы продают важность интеграции проекта и прогона тестов как можно чаще, например, несколько раз в день. С тех пор тулинг вокруг CI сильно улучшился и мы собираем приложения и гоняем тесты на каждый коммит. Плюс теперь принято использовать TBD (trunk based development), который доводит идею continuous integration до логического финала
Продолжение в следующем посте
#Management #Software #Engineering #SoftwareDevelopment #Processes #Devops #SRE