Agile-менеджмент. Лидерство и управление командами. Юрген Аппело
Читать онлайн книгу.
готового продукта предшествует созданию собственно программного кода), ревью кода (часто в сочетании с парным программированием), Definition of Done (чек-лист готовности элементов), итеративной разработки (адаптация кода в результате появившихся изменений или других обстоятельств) и рефакторинга (непрерывная оптимизация кода даже при отсутствии изменений в функциональности). Сторонники гибких методологий признают необходимость последовательного улучшения дизайна; под этим понимается, что в начале проекта архитектура продукта не разрабатывается в деталях (а только в самом базовом виде) и выявляется при дальнейшем развитии проекта.
Сторонники Agile-методологий считают, что инструменты – наименее важный из факторов, влияющих на успешность проекта. И тем не менее инструменты часто упоминаются и продвигаются в литературе по гибким методологиям. Опытные Agile-команды предпочитают инструменты, позволяющие осуществлять ежедневные сборки, непрерывную интеграцию и автоматическое тестирование. Команды нуждаются в мотивации, поэтому повторяющиеся скучные операции должны быть автоматизированы. Многие сторонники гибких методологий в качестве обязательного условия выдвигают наличие поддерживающей «среды обитания» в виде открытого офисного пространства, а также информационные радиаторы (к ним относятся, например, доска задач и диаграммы сгорания задач). Предназначение инструментов в контексте Agile-методологий – усиливать мотивацию, коммуникации и сотрудничество внутри команды.
У Agile-методологий особые отношения со временем. В Agile-проектах даты поставки, бюджеты и крайние сроки могут устанавливаться почти произвольно. Программное обеспечение создается короткими отрезками, часто в рамках тайм-боксов или «спринтов», и поставляется в виде инкрементных релизов; при этом каждый из релизов сам потенциально является готовым к поставке продуктом. Это позволяет владельцам бизнеса управлять графиком проекта, сдвигая дату сдачи готового продукта вперед или назад в зависимости от того, в какие сроки они хотят сделать доступной ту или иную функциональность. Тем временем команда стремится найти для себя оптимальную скорость разработки, которую она сможет поддерживать практически бесконечно.
Одной из важнейших причин создания Agile-манифеста было стремление подчеркнуть важность своевременной реакции на изменения. Среда, в которой функционирует программный продукт, никогда не бывает статичной. Функциональность, которая еще вчера представляла собой значительную ценность, завтра может оказаться бесполезной, включая функциональность, которая уже имеется в версиях продукта, переданных заказчику. Разработчики, практикующие гибкие методологии, стараются справиться с этой проблемой, предпочитая короткие циклы разработки и обратной связи. Смысл частых релизов программного продукта не только в том, чтобы получить обратную связь от пользователей и учесть ее в последующем процессе разработки, но и в