Адаптивная разработка программного обеспечения

Список условных обозначений, сокращений и терминов Adaptive Software Development (ADS) - Адаптивная разработка программного обеспечения;Agile Project Management (APM) – Agile управление проектами;Dynamic Systems Development Method (DSDM) – Метод динамическое развитие систем;Extreme Programming (XP) – Экстримальное программирование;Feature-Driven Development (FDD) – Разработка, управляемая функциональностью ;Lean Software Development (LSD) – Бережливая разработка программного обеспечения ;Microsoft Solutions Framework для Agile (MSF) – методология разработки программного обеспечения, предложенная корпорацией Microsoft ;Open Unified Process (OpenUP) – экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла. Pragmatic Programming (PP) – методология гибкой разработкиScrum – методология гибкой разработки Введение Формально методологии можно разделить на два типа – классические (монументальные, предсказуемые, где все этапы детально проектируется заранее и не допускается отклонение от первоначального плана) и их противоположность – адаптивные (гибкие, где в процессе работы допустимо и даже типично перепроектирование).Гибкие (Agile) методологии появились в противовес классическим, детально описывающим процесс создания системы. Эти методологии представляют собой попытку достичь необходимого компромисса между слишком перегруженным процессом разработки и полным его отсутствием.Agile – семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile-манифестом. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды разработчиков. Когда начинаешь интересоваться какие сейчас популярны методологии программирования, то очень быстро натыкаешься на очень красивое, но не понятное слово AgileСлушая семинары, читая статьи то и дело натыкаешься на фразы: «это не соответствует ценностям аджайла», «следуя принципам аджайла». Самое интересное, что при этом люди говорят, или пишут, очень интересные вещи, которые несомненно смогут помочь твоей личной работе и хочется понять, ачто такое Agile и с чем его едят. Agile - это только концептуальный каркас. Своего рода абстрактный класс, от которого вы можете наследовать свой рабочий процесс и выбрать: вы хотите работать по Extreme programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Или по нескольким сразу (SCRUM и Extreme programming прекрасно сочетаются ). Или же у вас непреодолимое желание создать свою методику, но все равно у вас есть шанс быть Agile командой (рис.1). Рис.1 – Схема методологии Agile Достаточно важно, как для меня, понимать, что Agile это только манифест. То есть, некие правила, соблюдая которые вы сможете хорошо разрабатывать код в приятной рабочей атмосфере. Agile может рассказать что должно быть, но не расскажет как. На вопрос как, вы можете или попытаться ответить сами, или прибегнуть к методологиям, которые исповедуют принципы Agile. Манифест гибкой разработки состоит из четырех пунктов, каждый из которых представляет собой альтернативу. Что позволяет, с точки зрения авторов Манифеста, лучше понять, с каким выбором команде приходится сталкиваться в процессе разработки, и какой путь ближе к ценностям гибкой разработки: Разрабатывая программное обеспечение и помогая другим делать это, мы стараемся найти наилучшие подходы к разработке. В процессе этой работы мы пришли к тому, чтобы ценить: Личности и их взаимодействия выше, чем процессы и инструменты.Работоспособное программное обеспечение выше, чем обширную документацию.Сотрудничество с заказчиком выше, чем переговоры по контрактам.Умение реагировать на изменения выше, чем следование плану.Таким образом, хотя и существует ценность в понятиях, стоящих в правой части этих сравнений, мы ценим понятия, стоящие в левой части, больше. Принципы гибкой разработки, основываясь на ценностях из Манифеста, дополняют их информацией более практического свойства.Основополагающие принципы Agile-манифестаНаивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.Работающий продукт — основной показатель прогресса.Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.Простота — искусство минимизации лишней работы — крайне необходима.Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.В чем суть Аgile и чем хороши эти методологии? Суть гибких методологий разработки программного обеспечения состоит в получении оперативной обратной связи и как следствие — безболезненной реакции на изменения в проекте (приоритетах, списке работ, в новых идеях заказчика).Это реализуется через сведение процесса разработки к коротким итерациям, которые обычно длятся несколько недель. Результат работы команды на каждой итерации сам по себе выглядит как программный проект в миниатюре и включает планирование, анализ требований, проектирование, кодирование и документирование.По окончании каждой итерации команда выполняет оценку своей результативности и планирует работу на следующий этап.Такие методологии имеют ряд преимуществ, основными из которых являются: Хорошая реакция на измененияРегулярная обратная связь от заказчика (о том что делаем именно то что он хочет)Стабильный и предсказуемый результатВысокая мотивированность командыСамоорганизацияРазделение рисков между заказчиком и командой Рассмотрим эти пункты подробнее: 1. Хорошая реакция на измененияВ отличие от альтернативной методологии разработки — “ватерфол”, когда заказчик получает через заранее определенный срок, к примеру, через год строго то, что изначально запланировали в проекте, в Аgile изменения можно вносить по мере необходимости в процессе разработки. 2. Agile уделяет много внимания качественной обратной связиДля того чтобы понять всю сложность взаимоотношений заказчика и разработчика, предлагаю рассмотреть следующий рисунок, который сам по себе о многом говорит (рис.2). Рис.2 – Взаимоотношение заказчик-разработчик В продолжение к картинке нужно отметить, что зачастую сам заказчик точно не знает всех своих требований к программному продукту и тем более не может сформулировать.Помимо этого даже очень точно задокументированный проект после полугода разработки может утерять свою актуальность, и нередко возникают ситуации, когда желание переделать небольшую составляющую часть, на основе которого строится все приложение, приводят к длительной переработке продукта.Кроме того, динамика бизнеса сама по себе просто не дает времени на детальную документацию проекта, ведь в конкурентной среде является немаловажным, кто анонсирует и предоставит готовый проект первым. Документация требует значительных временных затрат и еще более усложняется переменчивыми запросами пользователей.Agile подразумевают, что продуктом уже первой итерации станет демо-версия завершенной функциональности, в которую заказчик может внести комментарии и поправки практически с самого начала проекта, а через несколько итераций можно запускать бета-версию продукта для получения обратной связи от пользователей.Методологии Agile позволяют легко реагировать на изменения функциональных требований и приоритетов. 3. Agile обеспечивают предсказуемостьAgile предлагают воспринимать команду как некий черный ящик, который имеет определенный объем входных данных и время для предоставления результата.В начале итерации команда оценивает задачу и дает подтверждение того, что сможет предоставить результат, но не дает конкретных сроков и стоимости исполнения – они варьируются в процессе разработки.Отказ от долгосрочного планирования и отсутствия информации по срокам и стоимости продукта в целом может быть обоснован незначительным количеством выполненных в срок и по изначально предусмотренной стоимости проектов с фиксированной заранее ценой.Например, если мы имеем следующие исходные данные: Объем работ = 1000 единиц, Производительность команды = 50 единиц за итерацию, Цена итерации (сумма ставок каждого из ее членов) = 100$. То в итоге мы получаем: (1000/50)*100=2000$. Это означает, что изменение объема работ на 50 пунктов влечет за собой изменение стоимости конечного продукта на 100 у.е. Рис.3 – Команда разработчиков 4. Agile позволяют использовать самоорганизацию для мотивации командыСамоорганизация позволяет уйти от излишней структуры менеджмента.Методология Agile предполагает наличие только представителя заказчика, который выражает интересы бизнеса.Кроме того, нет необходимости в проверке каждого участника: команда сама распределит задачи и ответственность внутри группы и определенно будет гарантировать качество и производительность. Это является хорошей мотивацией продуктивной командной работы. 5. Agile подразумевают разделение рисков между заказчиком и командойСейчас наиболее распространёнными видами взаимодействия с заказчиком является заключение контрактов с фиксированной ценой (fixed-price контракты) или контрактов «Время и материалы» (time & material).В случае заключения fixed-price контракта все риски по проекту ложатся на разработчиков. Эти риски в основном включают в себя неверные оценки сложности и трудоемкости в связи с тем, что основой этих расчетов является весьма скудная документация. Особенно большие сложности возникают в том случае, если проект большой и рассчитан не на один месяц. После нескольких таких неудач компания-исполнитель, набив шишки на том, что и документацию не дописали, и оценили не верно, и недопоняли, и заказчик не раз передумал – начинает закладывать огромные буферы на случай непредвиденных затрат. Такое увеличения стоимости защищает разработчика от постоянных отклонений от изначальных требований, но заказчик не заинтересован в том, чтобы платить лишние деньги.Вторая схема контракта – time & material, суть которого в том, что заказчик оплачивает фактическую работу. Рис.4 – Разделение рисков между заказчиком и командой Это приводит к тому, что разработчик не стремится брать на себя ответственность за результат, а просто не спеша выполняет порученные ему задачи. Как следствие, исполнителю, по сути, безразлично, в правильном ли направлении ведется разработка. Заказчик заплатит и за время, потраченное на разработку в неверном ключе, и за переделывание неудовлетворительных результатов.Страница 12Следующая »Scrum, Extreme Programming и другие модели AgileНа практике методология Agile может использоваться в нескольких интерпретациях. В проектах для заказчиков EPAM наиболее часто применяет: ScrumExtreme ProgrammingLean Software Development (LSD)Dynamic Systems Development Method (DSDM)Open Unified Process (OpenUP)Agile Project Management (APM)Microsoft Solutions Framework для Agile (MSF)Обеспечить высокое качество при реализации проектов и при этом уложиться в сжатые сроки нам помогает:Особое внимание к созданию и оформлению программного кодаСочетание различных техник разработки ПО: парное программирование, разработка через тестирование, коллективное владение кодом и др.Использование методов непрерывной интеграции для снижения количества ошибок и постоянного мониторинга производственных процессовПрименение апробированных технологий для управления проектомДля контроля над распределением ресурсов и работой ИТ-команды используется информационная система EPAM Project Management Center. По мнению ряда экспертов, это одно из лучших решений в мире для поддержки методологий гибкой разработки программного обеспечения, в частности, Scrum. Методология Scrum Scrum - это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.Спринт — итерация в скрам, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в резерве проекта. На протяжении спринта никто не имеет права менять список требований к работе, внесенном в резерв проекта.В методологии Scrum всего три роли.Scrum MasterProduct OwnerTeamСкрам Мастер (Scrum Master)Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой.Основные обязанности Скрам Мастера таковы:Создает атмосферу доверия,Участвует в митингах в качестве фасилитатораУстраняет препятствияДелает проблемы и открытые вопросы видимымиОтвечает за соблюдение практик и процесса в командеСкрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.ScrumMaster может также помогать Product Owner создавать Backlog для командыProduct OwnerProduct Owner - это человек, отвечающий за разработку продукта. Как правило, это product manager для продуктовой разработки, менеджер проекта для внутренней разработки и представитель заказчика для заказной разработки. Product Owner - это единая точка принятия окончательных решений для команды в проекте, именно поэтому это всегда один человек, а не группа или комитет.Обязанности Product Owner таковы:Отвечает за формирование product visionУправляет ROIУправляет ожиданиями заказчиков и всех заинтересованных лицКоординирует и приоритизирует Product backlogПредоставляет понятные и тестируемые требования командеВзаимодействует с командой и заказчикомОтвечает за приемку кода в конце каждой итерацииProduct Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.Команда (Team)В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.Обязанности команды таковы:Отвечает за оценку элементов баклогаПринимает решение по дизайну и имплементацииРазрабатывает софт и предоставляет его заказчикуОтслеживает собственный прогресс (вместе со Скрам Мастером).Отвечает за результат перед Product OwnerРазмер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2.Команда в Scrum кроссфункциональна. В нее входят люди с различными навыками - разработчики, аналитики, тестировщики. Нет заранее определенных и поделенных ролей в команде, ограничивающих область действий членов команды. Команда состоит из инженеров, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями и проектной необходимостью. Команда самоорганизуется для выполнения конкретных задач в проекте, что позволяет ей гибко реагировать на любые возможные задачи.Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы.Методология Extreme Programming – Экстремальное программированиеЭкстремальное программирование (XP) – это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований.Цели XPОсновными целями XP являются повышение доверия заказчика к программному продукту путем предоставления реальных доказательств успешности развития процесса разработки и резкое сокращение сроков разработки продукта. При этом XP сосредоточено на минимизации ошибок на ранних стадиях разработки. Это позволяет добиться максимальной скорости выпуска готового продукта и даёт возможность говорить о прогнозируемости работы. Практически все приемы XP направлены на повышение качества программного продукта. Принципы XPОсновными принципами являются:Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое – 1-2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении XP методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве – в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.Достаточная степень смелости и желание идти на риск. ВыводAgile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе иногда называемом bullpen. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
http://www.kport.info/money/finlikbez/index.php?ELEMENT_ID=11485http://ru.wikipedia.org/wiki/Гибкая_методология_разработкиhttp://www.epam-group.ru/strengths/methodology/agile.htmlhttp://cmcons.com/articles/obshhie_stati_rup/rup_i_drugie_metodologii_razrabotki_pohttp://www.digital-soft.ru/methodology.php