Внедрение Agile ALM
Команды Agile работают качественнее, результаты выдают быстрее, кроме того, они более гибки, что позволяет им быстрее отвечать на изменения в требованиях (когда эти требования приняты всеми заинтересованными лицами). В итоге это ведет к тому, что соотношение прибыли ко вложенному капиталу у них больше (да и сама прибыль зачастую поступает быстрее). Прошли времена доминирования отдельных крупных проектов. В последние годы IT-проекты становятся все мельче и мельче. Поэтому все выше важность создавать продукты быстро и с низкими затратами - это и касается и малых/средних проектов, и подэтапов в больших проектах. Важно также создавать эффективную, “легкую” инфраструктуру с тем, чтобы получить максимум преимуществ от знаний и сплоченной работы. В ALM нет универсального рецепта такой инфраструктуры, в основном потому, что каждая компания и даже каждый проект имеют собственные исходные условия и исходную культуру. Подход, основанный чисто на процессах или на инструментах, уводит нас от того факта, что ПО делается людьми и для людей, вот почему и присматривать за ним непрерывно тоже должны люди. ALM как раз дает возможность присматривать за процессом в целом. Это один из путей, на котором ALM помогает создать структуру для Agile. В Agile ALM мы фокусируемся на процессах и инструментах, которые играют значительную роль в поддержке ALM, но в центре каждого проекта - люди, культура, процессы и инструменты, создающие его стабильность, или, можно сказать, устойчивость. Если представить эти взаимосвязи в виде пирамиды, то инструменты и процессы расположены на вершине пирамиды устойчивости. Люди - это фундамент пирамиды, вслед за ними идет культура. Вы не захотите использовать инструменты, которые навязывают вам те или иные процессы, вам необходим другой образ действий: сначала вы определяете процессы, а потом уже решаете, какие инструменты помогут вам в этих процессах. Рассматривая же полный путь, изначально вы определяете цель - и уже потом выясняете, какие процессы лучше подходят в их достижении. Значительное влияние на сформировавшуюся культуру оказывают предыдущие проекты, исторические события, а также накопившийся опыт и знания в компании. Хотя это непросто, но если организация собирается достичь успеха в долгосрочной перспективе, культура должна измениться. Убеждение не работает. Менеджмент должен взять на себя обязательства создавать высококачественное ПО, совмещая разработку с обучением, и всячески поддерживать освоение новых практик и процессов, которые работают лучше старых. Они должны обеспечить правильные внутренние мотиваторы, такие, как автономность и возможность использования инноваций. Команда разработчиков также должна взять на себя обязательства по разработке высококачественного ПО. При этом разработчики должны понимать, что вкладывается в понятие “качество”, а менеджмент должен ценить качество превыше сроков, охвата и стоимости. Как только люди начнут понимать, что им разрешено “делать все правильно”, у них появится мотивация искать и изучать такие инструменты, которые лучше всего подходят процессу. Выбор инструментов под процесс - это легкая часть задачи, довольно легко внедрить структуру наподобие Scrum. Но куда сложнее сделать из этого реальную приверженность качеству и сотрудничеству бизнеса и разработчиков. Все это означает, что если вы хотите изменить подход к разработке в вашей компании, вам необходимо двигаться как сверху вниз, так и снизу вверх. На нижнем уровне вы должны убедить людей стремиться к целям, которые вы озвучили. Намного проще преодолевать сопротивление переменам, если вас поддерживают ключевые фигуры, например, опытный программист, который рекомендует или сам уже использует какой-то конкретный инструмент (часто это продукт с открытым кодом). Опираться на мнение опытных людей лучше, чем бюрократически продавливать большие, громоздкие инструменты. На высшем уровне вам также необходимо настойчивое стремление руководства изменить процессы или инструменты, потому что люди имеют склонность привязываться к определенным процессам или инструментам и не хотят их менять, если на то нет особых причин. В целом, стабильность является преимуществом, поэтому для того, чтобы нечто, что и так успешно работает, должны быть веские причины. Но разработка ПО сама по себе состоит из изменений, именно поэтому и возникла гибкая методология. Может быть трудно превратить среду в гибкую, поэтому необходимо сосредоточиться на выборе таких инструментов, которые лучше всего подходят вашим гибким процессам (а не наоборот). У этих инструментов должна быть открытая архитектура, они должны быть просты в использовании, взаимозаменяемы, расширяемы и должны уметь взаимодействовать друг с другом. Быть гибким в классическом понимании - это быть открытым для перемен. Кроме того, неотъемлемой частью должно стать непрерывное управление рисками и пересмотр всего процесса - чтобы можно было быстро выявить проблемы и их возможные последствия. Современная разработка ПО состоит из управления изменениями и понимания всех активностей разработки как определенного и прослеживаемого процесса. Гибкая методология помогает управлять изменениями и рисками вне зависимости от общего процесса разработки, который вы используете. Кроме того, она фокусируется на важности прозрачности и согласованности с бизнес-стоимостью.
Оригинал: http://www.manning.com/huettermann/ Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
