Как именно Agile ALM может помочь?
В этой статье в общих чертах рассказывается, как именно ALM может помочь компаниям, и более подробно - как технологии Agile используют ALM. Технологии ALM условно могут быть разбиты на три сферы:
Внутри каждой из этих сфер при любой стратегии, которой придерживается команда разработчиков, можно применить следующие методики ALM
По мере роста команд разработчиков, инструменты для управления жизненным циклом стали опорой для многих компаний и важной составляющей ALM-пространства. Но что именно делают инструменты ALM и методики Agile? Agile ALMПоскольку методики Agile обязывают команды разработки ПО к дисциплине, многие инструменты появились в помощь этим методикам. Как гласит «Манифест Agile»: «Люди и взаимодействия между ними превыше процессов и инструментов (в том смысле, что второе нам очень ценно, но первое еще ценнее». Очевидно, что Agile не препятствует использованию инструментов, но сущность Agile не в том, как инструменты используются или какие методики ALM применяются. Компания должна использовать технологии ALM лишь в том случае, если они приносят ценность. Agile - это не серебряная пуля и не талисман, это лишь способ лучше разрабатывать ПО. Поэтому прежде всего надо удостовериться, что люди взаимодействуют друг с другом, не полагаясь на одно лишь взаимодействие инструментов. Это единственный способ убедиться, что ваши методики ALM действительно используют Agile. Чтобы проверить, что взаимодействия на самом деле ценятся превыше инструментов, не подгоняйте процесс под выбранный вами инструмент. Пусть сначала члены вашей команды сами освоятся с методиками Agile, пусть устраивают конференции в переговорных. Затем используйте низкотехнологичные методы - карточки на стене, графики, таблицы для сбора требований и планирования, пока вам не понадобится нечто более мощное. Отточите за это время взаимодействие между командой и бизнесом. А когда низкотехнологичный подход станет превращаться в головную боль - тогда и ищите инструмент, который избавит вас от боли. Как Agile ALM улучшает планированиеДля многих планирование проекта означает открыть MS Project и нарисовать в нем схемку. В нее войдет первичное планирование, затем решение, с чего начинать, а потом развернутый план с заделом на далекое будущее. Для команд Agile такие комплексные планы могут помочь скоординировать крупные инициативы, но большая часть планирования осуществляется в виде написания планов с историями. Фокус при этом идет на взаимодействии внутри команды. Планирование происходит на небольших сессиях, что позволяет быстро менять области изменений, ресурсы или даты. Использование механизмов отчетности - таких, как диаграмма burndown (она показывает прогресс работы всей команды), диаграммы скорости и сводные графики - помогает упростить планирование. Доски с задачами также позволяют сделать планирование более прозрачным для команды. Методики гибкой разработки делают и планирование общей задачей команды. Такие подходы, как Scrum, спринт, сессии итерационного планирования, позволяют команде планировать и воплощать запланированное в короткие промежутки времени. Кроме того, при изменении обстоятельств (а обстоятельства меняются постоянно) эти приемы позволяют оперативно менять планы. Как Agile ALM улучшает сбор требованийВ сборе требований команды Agile полагаются на рабочие объекты с небольшой сферой применения. Большинство команд для передачи функций, которые надо воплотить, задействует так называемые пользовательские истории. У инструментов ALM должен быть способ собирать такие истории и использовать их на сессиях планирования. Самый простой инструмент ALM, который можно использовать для базового сбора требований - это карточки на большой доске. Карточки на доске - это замечательный способ для команды стартовать проект. Кроме того, он хорош и для того, чтобы вся команда, работающая в одном месте, видела требования и прогресс продвижения по ним. Для больших (более 10 человек) и удаленных команд, однако, этот способ вряд ли подходит. Еще один тип требований включает в себя критерии приемки. В командах Agile - как и в большинстве команд - они принимают форму макетов, мокапов или предоставляются в письменном виде. Разница в том, что команды гибкой разработки используют автоматизированные критерии приемки или заменяющие их тесты. В зависимости от зрелости команды, использование электронных инструментов для сбора и хранения пользовательских историй, мокапов, макетов и критериев приемки может помочь большим удаленным командам в сборе требований. Команды могут использовать для сбора требований те же инструменты, что и для планирования. Роль контроля версий в Agile ALMКогда вы пишете код командой, вам необходимо иметь какую-то систему контроля версий. В наше время для большинства разработчиков это является очевидным, но все еще время от времени слухи доносят истории о командах, которые для контроля версий используют файловую систему (и это именно то, о чем вы подумали!). Методология ALM - и Agile в частности - предполагает практику контроля версий. Основное требование - ваша система контроля версий должна позволять откатиться к какой-либо версии без затруднений. Кроме того, она должна и позволять команде разрабатывать новые функции, и при необходимости выполнять работы по технической поддержке. Таким образом, необходимо определить для всей команды стратегии ветвления и объединения. Эта необходимость - не уникальное требование именно для Agile, это потребность для всякого внедрения ALM. Ваша система контроля версий не должна вставать на пути у процесса разработки. У команды гибкой разработки должен быть способ осуществлять непрерывную интеграцию, когда кто-то из членов команды добавляет код. Контроль качества в Agile ALMСтратегия ALM всегда содержит план по контролю качества. В решениях Agile ALM всегда заложен подход к разработке, опирающейся на тесты. Таким образом, необходимо автоматическое тестирование, а так же возможность измерять результаты этих тестов. Позвольте подчеркнуть: результаты тестов предназначены не для карательных мер - они для того, чтобы информировать команду. Например, использование такого показателя, как покрытие кода, может сообщить команде, что уровень покрытия составил 86% при цели в 95%. В таком случае команде надо будет исследовать причины, почему уровень оказался ниже. Тем не менее, инструмент не может прямо сказать команде, достаточно ли хорош модульный тест. Для выявления этого нужно задействовать пересмотр кода при помощи парного программирования или другие механизмы. Как ранее упоминалось, автоматизированные критерии приемки могут использоваться и для проверки качества. Некоторые команды используют в этих целях инструменты для Behavior Driven Development (BDD) - разработке, основанной на функционировании. Большинство инструментов включает также поддержку автоматизированного тестирования пользовательских интерфейсов. Поскольку на некоторых стадиях разработки тестирование GUI - вещь довольно хрупкая, использовать данный функционал надо с осторожностью. Если ваш продукт предусматривает выпуск небольших технических релизов с новыми функциями, тестирование GUI может значительно снизить издержки регрессионного тестирования. Но если в вашей команде хорошо налажены BDD и TDD тесты, то особой нужды в автоматическом тестировании GUI нет. Большинство инструментов, кроме того, позволяет отслеживать метрики таких автоматизированных тестов. Однако независимо от методологии или инструмента, применяемых вашей командой для процесса контроля качества, сам по себе этот процесс является одним из столпов стратегии ALM. DevOps в Agile ALMОдним из аспектов разработки, который часто упускают из виду, является вовлечение в продукт инфраструктурных групп. Подход DevOps поощряет более тесное сотрудничество между командами разработчиков и инфраструктурными отделами, в частности операционными группами. Практики ALM хорошо взаимодействуют с концепцией DevOps, поскольку требуют создания устойчивой и постоянной среды разработки для уверенности в качестве продукта и бесшовного развертывания. В зависимости от продукта должны быть настроены различные среды (веб, десктоп, мобильная разработка). Например, команде веб-продукта могут понадобиться среды интеграции, контроля качества, отладки и боевые серверы. Если все эти среды развернуты наобум, риск возникновения дефектов стремительно растет. Предположим, что все среды настроены сходным образом. Поддержка вашей среды в стабильном состоянии, целостной, легко адаптируемой - это продвижение в сторону устранения коллизий между средами. Это критично для концепции DevOps, которая включает в себя систему сборки, которая берет на себя контроль исходного кода, собирает и разворачивает все в единой манере для каждой среды. Некоторые практики Agile ALM в DevOps включают непрерывную интеграцию, когда команда производит развертывание в среде один раз в день или каждый раз при добавлении кода. Некоторые команды практикуют непрерывное развертывание для быстрого развертывания в прод, следуя всем положительным методикам, какие им по нраву. Выбор инструментов ALMВыбор инструментов Agile ALM - это решение командное. Команды разработчиков имеют различный опыт и могут быть более продуктивными, когда им разрешают использовать инструменты по их выбору. Я призываю компании слушать разработчиков и использовать различные инструменты ALM. Кроме того, выбор командами своих инструментов отвечает самоорганизующейся природе Agile-команд. Компании должны наделить своих разработчиков некоторыми правами в плане выбора инструментария и принятия конечных решений. Вооруженная правильным набором инструментов, команда разработчиков может включить ALM в процесс гибкой разработки и воспользоваться преимуществами Agile ALM.
Оригинал статьи: http://www.logigear.com/magazine/agile/agile-alm-and-the-tools-to-practice-it/ Автор: Эрик Ландес В отрасли разработки ПО Эрик работает с 1986 года. В настоящее время он работает архитектором решений в Agile Thought, где занимается Agile-коучингом, консультирует по практикам ALM и инженерным методологиям в целом. Эрик специализируется в управлении проектами Agile (XP/Скрам вариант), методике «бережливой разработки» и управлении проектами разработки ПО. Он разработчик MVP и сертифицированный скрам-мастер. Больше о нем можно прочитать на его сайте www.ericlandes.com Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
