Гибкая модель разработки программного обеспечения Agile

Содержание:

Введение

Методология управления проектами включает совокупность моделей, методов и программных продуктов, применяемых при разработке и реализации проектов различных классов и типов.

Специфика проектов по разработке программных продуктов заключается в том, что результат разработки нематериален – это коллективные ментальные модели, записанные на языке программирования. Это приводит к тому, что большая часть проектов разработки программного обеспечения (ПО) завершается со срывами сроков, перерасходом бюджета, а часть проектов не завершается в принципе. Вышесказанное подтверждают исследования Standish Group, которые показали, что только 35 % проектов завершились в срок. Одной из главных задач, напрямую влияющих на эффективность разработки ПО, является выбор модели процесса разработки.

Проблемой является то, что не существует единого оптимального решения. Модель должна определяться для каждого конкретного проекта и может меняться в широком диапазоне, в зависимости от масштаба, новизны и критичности проекта, распределения участников, требований заказчика.

На выбор модели также влияет возможность дальнейшей сертификации, что позволяет компании разработчику получить преимущество перед конкурентами, привлечь новых заказчиков, повысить имидж организации.

Целью курсовой работы является изучение гибкой модели разработки программного обеспечения Agile. На основе поставленной цели будут решены следующие задачи:

- рассмотрены теоретические основы гибкой модели разработки программного обеспечения Agile;

- проанализированы плюсы и минусы гибкой модели разработки программного обеспечения Agile;

- на примере методологии scrum рассмотрены решения по управлению Agile проектами.

Предмет курсовой работы – методы разработки ПО, объект – Agile.

Курсовая работа состоит из введения, трех глав, заключения и списка литературы.

Глава 1 Теоретические основы гибкой методологии разработки Agile

Понятие гибкой методологии разработки Agile

Гибкая методология разработки (от англ. - Agile software development) - манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework - каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля^[1] (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как "гибкая методология разработки" не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют - фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.

Определение с точки зрения BPM CBoK [от англ. - Guide to the Business Process Management Common Body Of Knowledge]. Agile - Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.

В основе гибкой методологии разработки лежит либерально-демократический подход к управлению и организации труда команд, члены которой сконцентрированы на разработке конкретного программного обеспечения^[2].

За счет того, что разработка программного обеспечения с применением гибкой методологии определяет серии коротких циклов (итераций), с длительностью 2-3 недели, достигается минимизация рисков т.к. по завершению каждой итерации Заказчик принимает результаты и выдает новые или корректирующие требования т.е. контролирует разработку и может на неё сразу влиять. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. Обычно одной итерации не достаточно для выпуска полноценного программного продукта, но при этом по окончании каждого этапа разработки должен появляться "осязаемый" продукт или часть функционала, которую можно посмотреть, потестировать и выдать дополнительные или корректирующие меры. На основе проделанной работы, после каждого этапа, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки программного обеспечения.

Одной из основных идей Agile, является взаимодействие внутри команды и с заказчиком лицом к лицу, что позволяет быстро принимать решения и минимизирует риски разработки программного обеспечения, поэтому команду размещают в одном месте, с географической точки зрения. Причем в команду входит представитель заказчика (англ. product owner - полномочный представитель заказчика или сам заказчик, представляющий требования к продукту; такую роль выполняет менеджер проекта от заказчика или бизнес-аналитик).

Гибкие методологии построены таким образом, что изменения приветствуются, а неопределенность признается. Существует несколько отличительных признаков всех гибких методологий.

Разработка ведется короткими итерациями. Чем короче итерация, чем чаще можно демонстрировать продукт заказчику и изменять направление развития продукта. Заказчик сможет руководить разработкой продукта вместо того, чтобы дождаться окончания разработки и убедиться, что получилось совсем не то, что он хотел.

Инкрементальная разработка. За каждую итерацию продукт дополняется новыми функциями, оставаясь при этом полностью функциональным и готовым к передаче заказчику

Самоорганизующаяся команда. Как показывает практика, только самоорганизующиеся команды способны гибко реагировать на изменения. Дело в том, что короткие итерации и часто меняющиеся требования приводят к тому, что поддерживать документацию по проекту в полном объеме невозможно технически. В этом случае команда тратила бы на работу с требованиями больше времени, чем на разработку кода. А раз документации мало – команде приходится намного больше общаться лицом к лицу, решая повседневные проектные задачи. Команда должна быть самоорганизующейся, чтобы справится с потоком проблем.

Адаптирующийся процесс. В традиционном подходе к разработке процесс определяется на уровне организации, а на уровне проекта происходит его тейлоринг, «подгонка по телу проекта». На практике это означает, как правило, что менеджер проекта принимает решения, какие из стандартных регламентных требований организации не применимы к проекту и документирует свое решение в соответствующем документе. В Agile процесс определяется по ходу проекта самой проектной командой.

Принципы Agile изменяют представление о том, как надо разрабатывать программное обеспечение. Трансформируется сама парадигма^[3]: фокус смещается с ориентированности на процесс как на последовательность заранее продуманных руководством шагов на ориентированность на проектную команду, как на группу людей, способных самоорганизоваться и решать все проблемы самостоятельно. Это изменение носит совсем не формальный характер: оно требует от членов проектных команд совершить переворот в собственном сознании, отказаться от ориентированности на административно-командные методы управления и попытаться сформировать совершенно новые для них методы решения проблем.

По сути Agile – набор практик, которые позволяют воплощать все эти принципы в жизнь.Некоторые принципы и связанные с ними практики просты и практически никогда не вызывают трудностей при внедрении. Речь идет прежде всего об итеративной и инкрементальной разработке. Сокращение длины итерации до месяца и меньше принимается руководством с удовольствием, да и разработчики не видят в этом ничего непонятного или странного.

Куда сложнее дело обстоит с принципами самоорганизации команды и адаптирующегося процесса. Agile особенно эффективен, если команда самоуправляема и самоорганизуема. Добиться этого на практике непросто. Фактически, это означает смену парадигмы мышления – с привычки подчинения на привычку сотрудничества. Препятствует процессу внедрения, например, индивидуальная оценка деятельности каждого члена команды, принятая во многих организациях. Нет ничего более опасного для воспитания команды, чем осуждение отдельного члена команды. Виноватый настраивается не на сотрудничество, а на самозащиту. Все Agile методологии подчеркивают, что оценивать производительность можно только для команды целиком.

Внедрение коллаборативного мышления требует особого мужества в организации, управляемой традиционными административными методами. Все менеджеры достигли своего положения благодаря тому, что знают, что такое личная ответственность и способны принимать правильные решения в одиночестве. Как теперь перебороть представление о том, что такое хорошо и что такое плохо и начать внедрять “демократию” в отдельно взятом проекте? Зачастую решения о внедрении Agile принимаются чисто административными методами – находится отсветственный, ему поручается команда. Стараясь быть эффективным, менеджер щедро раздает пинки и тычки, кровью выбивая из команды “мотивированность” на успех. Такая тактика не принесет ничего, кроме разочарования. Команда не умеет принимать решения самостоятельно – а значит и не несет за решение ответственность.

1.2 История выпуска Agile манифеста

«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с "методом водопада" ("waterfall"), т.к. на момент выхода манифеста, именно "метод водопада" являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий^[4]:

• Adaptive software development (ASD)
• Crystal Clear
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature driven development (FDD)
• Pragmatic Programming
• Scrum

Собственно данные методологии гибкой разработки существовали и до выпуска манифеста. Сам же выпуск манифеста дал новый толчок к развитию гибких методологий, заложил основы, можно сказать конституцию гибкого подхода к разработке программного обеспечения.

Agile-манифест разработки программного обеспечения:

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. 
Это привело к критике этих методов как недисциплинированных.

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: 

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану. 

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Авторы манифеста:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Основополагающие принципы Agile-манифеста:

Мы следуем таким принципам:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт - основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота - искусство минимизации лишней работы - крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Глава 2 Плюсы и минусы методологий гибкой разработки Agile

2.1 Разновидности методологий гибкой разработки Agile

На основании ценностей и принципов, определенных в Agile Manifesto были сформированы следующие гибкие методологии разработки^[5]:

- Agile Modeling (AM) - данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.

- Agile Unified Process (AUP) - унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.

- Agile Data Method (ADM) — набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.

- Dynamic Systems Development Method (DSDM) - итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений - Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта. 

- Essential Unified Process (EssUP) - подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).

- Extreme programming (XP) - идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.

- Feature driven development (FDD) - основное ограничение, которое накладывается в рамках данного подхода, это "каждая функция должна быть реализована не более, чем за две недели". Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.

- Getting Real (GR)  - в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность. 

- OpenUP (OUP) - данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.

- lean software development - данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).

- Scrum - один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

2.2 Секрет успеха и Agile-провалы больших компаний

Agile — это действительно передовая и эффективная методология. Но, как говорится, что русскому хорошо, то немцу смерть. Так и Agile. В течение одного года было проконсультировано три стартапа, разрабатывающих ПО в различных областях - от прогрессивной файловой системы до платформы для интернет магазинов. Всем им было достаточно двух-трех недель массированного обучения принципам Agile для того, чтобы перевести процесс разработки на новый лад и выпускать версию раз в две недели.

Совсем по-другому обстояло дело у глобального поставщика телекоммуникационных систем. Компания была на грани срыва поставки нескольких проектов обновления ПО общей стоимостью более $1 миллиона. Причина проста - перевод нескольких компонентов на систему постоянной интеграции. До запуска интеграционных тестов с реальной базой данных все работало хорошо, и, конечно же, все полетело, когда данные были обновлены.

Это не случайность - Agile отлично работает в стартапах, маленьких командах, но на больших проектах, как правило, приводит к большим проблемам: отсрочкам запуска на месяцы и даже полному провалу

Почему это происходит? При разработке по Agile все делается двухнедельными спринтами - в продакшн отправляются небольшие изменения. По статистике, собранной и опубликованной Puppet, лидером управления конфигураций, багов в таких обновлениях содержится в три раза меньше.

На первый взгляд, отлично, однако на самом деле работы у Quality Assurance реально прибавляется, так как при уменьшении количества проблем в три раза скорость поставки увеличивается в 200 раз. Простая математика, и результат не такой уж обнадеживающий - общее количество проблем увеличивается более чем в 60 раз. Очевидно, что при такой нагрузке служба не справляется с тестированием - пропускает серьезные ошибки, не успевает проверить работу системы в целом и прочее.

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов^[6]. И в этом заключается еще один «большой секрет для маленькой компании» - некоторые стартапы и большие ИТ-компании (преимущественно из Кремниевой долины) могут позволить себе нанимать крутых специалистов. И это еще одна причина, почему у них все работает хорошо. Возможно, будь у этих людей в распоряжении просто лопата, а не самая модная методология, они бы все равно сделали все очень круто.

В больших же компаниях работает много людей, и большинство из них - это средние специалисты. Конечно, каждый работодатель стремится к тому, чтобы брать к себе лучших, и HR-служба действительно старается. Однако статистика - штука строгая, но справедливая - все лучшие очень быстро делятся на хороших, средних и не очень хороших. И в конце концов все работают как среднестатистические специалисты. В этом случае проекты будут работать хорошо, только если сама методология это позволяет. Потому что при таком раскладе уже нельзя полностью полагаться на хорошую работу сотрудников.

Да, вышеупомянутые Google, Facebook и Uber - это большие компании. И да, они тоже подвержены «болезням» Agile - время от времени все мы это видим сами или читаем жалобы других пользователей - вчера сервис не работал полдня, сегодня был недоступен полчаса и так далее. Но в этих компаниях цепочки работают почти безупречно, и в случае возникновения проблем команда устраняет их очень быстро. Хотя сейчас проблем становится все больше, и даже в условиях четко отлаженной коммуникации сроки их устранения увеличиваются.

Но все ли могут работать так, как Google? Наверное, банки и другие организации, деятельность которых регламентируется законом, должны всё-таки выстраивать процессы и создавать такую систему, которая сделает эффективной работу любого человека и не допустит серьезных ошибок.

Рассмотрим Agile-провалы больших компаний.

Agile очень привлекателен, и перед ним не смогли устоять не только российские банки, но и многие крупные мировые бренды. И почти все они потерпели неудачу или даже хуже.

Например, в июле 2015 года торги на Нью-Йоркской фондовой бирже были остановлены на четыре часа. Первоначальная версия сбоя основывалась на кибератаке, но проблема оказалась всего-навсего в баге во время очередного обновления. Сложно даже представить, во сколько миллиардов обошлись эти четыре часа простоя центра мировой торговли.

Ладно брокеры - сейчас потеряли миллиард, потом заработали два. Но у авиакомпаний совсем другая история. Примерно так же после банального обновления ПО авиакомпании «Дельта» информация перестала поступать в диспетчерскую систему, и все рейсы пришлось отменить. И здесь, кроме прямых убытков, у авиакомпании возникли репутационные проблемы.

Наверное, один из самых громких провалов применения Agile - это запуск известной американской системы медицинского страхования Obama Care

Для тех, кто не знает, поясню, что суть этой программы заключалась в предоставлении бесплатных страховых полисов для определенных категорий граждан США.

Чтобы получить право на этот полис, нужно заполнить анкету на сайте и дождаться решения от соответствующих служб. Естественно, сразу после запуска на сайт повалили тысячи и тысячи желающих бесплатной медицины, которые заполняли и заполняли анкеты. Но вот беда - они анкеты заполняли (а анкета там «ого-го»- кто подавал на получение американской визы, думаю, может себе представить), но не могли их отправить - падал сервер.

Obama Care «полетела» примерно через полгода после запуска. Для того, чтобы все заработало, пришлось пригласить внешнего специалиста-консультанта, который смог оценить картину целиком и, начав с конца - с продакшена, постепенно собирал части системы воедино и все-таки добился слаженной работы.

Agile плохо описывает процессы управления требованиями, можно сказать, что такое понятие просто отсутствует т.к. гибкая методология разработки не подразумевает под собой долгосрочного планирования (планирование осуществляется на краткосрочную перспективу), как следствие пропущен шаг формирования плана развития продукта или другими словами дорожной карты продукта^[7]. Т.к. планирование краткосрочное (на ближайшую итерацию разработки), а Заказчик по окончанию каждой итерации принимает продукт и выставляет новые требования, сам продукт может поменяться в корни, а выставляемые новые требования зачастую противоречат структуре и архитектуре продукта уже поставляемого клиентам. По большому счету, в случае, если Заказчик не до конца понимает, что хочет увидеть в итоге (конечный продукт), а понимание приходит во время разработки (это случается в 90% случаев), процесс разработки превращается в формализованную и легализованную бюрократию т.е. продукт дорабатывается бесконечно, пока не кончаются деньги, или заказчик не переключается на другой продукт. Справедливости ради, необходимо заметить, что Заказчик знает на что идет и сам решает, платить за разработку продукта или нет, по большому счету команда разработчиков просто выполняет требования заказчика. Однако, реально, в работе это приводит к хаосу, срыву сроков и авралам, что порождает новые требования, которые меняют не в лучшую сторону продукт. Более того, снижается качество разрабатываемого продукта, т.к. Agile определяет подход к разработке, в рамках которого необходимо быстро тушить пожары, наиболее простым и быстрым способом. Код пишется не соблюдая требований платформы, на которой разрабатывается продукт, появляется множество обходных решений и дефектов, а такая конструкция не очень устойчива и не безопасна, растет негодование клиентов от частых сбоев в работе программного обеспечения. Бизнес на выходе получает потери, падает качество планирования.

Некоторые эксперты Agile ассоциируют больше с подходом по совершенствованию уже готового продукта, нежели разработки нового. Сторонников много у гибкой методологии разработки, ровно, как и противников. Последние в свое время даже выпустили Anti Agile Manifesto. Далее в ознакомительных целях, мы приводим содержание двух, наиболее популярных манифестов, противоречащих основному манифесу Agileэ

Глава 3 Решение по управлению Agile проектами на примере методологии Scrum

Следуя основным принципам гибкой разработки (Agile) мы постарались сделать систему управления Agile проектами Devprom AgileTeam инструментом, который сможет по-настоящему упростить работу проектной команды, при этом оставаясь максимально гибким и простым в установке и использовании.

В зависимости от особенностей вашего проекта, размера и возможностей команды вы можете отключить лишние для вас элементы процесса разработки (например, сбор требований, описание тестовых сценариев), не следовать формальным процедурам и получать максимум преимуществ от итерационной разработки с непрерывным и частым выпуском работающих продуктов. Далее описывается реализация основных инструментов гибкой разработки в Devprom AgileTeam, на примере методологии Scrum.

1. Истории пользователей (User stories, Пожелания) (рис.1)

• Пожелания или истории пользователей являются одними из самых базовых инструментов гибкой разработки; они относительно небольшие, удобные для составления, обсуждения, планирования, оценки и последующей работы над ними.
• Каждое пожелание, в зависимости от размера и сложности реализации, в процессе работы команды над ним может как превратиться в полноценное описание требования к системе, так и просто быть декомпозированным на набор задач в итерации.
• Возможности приоритезации позволяют вашей команде сконцентрироваться на наиболее значимых и важных историях пользователей. Оценка трудоемкости каждой истории позволяет планировать сроки ее реализации, тем самым управляя ожиданиями заказчика.

Рисунок 1 - Истории пользователей (User stories, Пожелания)

2. Журналы пожеланий (Product Backlog, Release backlog)

• В журнале пожеланий продукта содержатся все истории пользователей, существующие по продукту, с возможностью быстрой фильтрации по дате добавления, типу, приоритету, состоянию разработки и другим параметрам. Представление в виде простого списка с детализацией позволяет максимально эффективно управлять всем бэклогом продукта.
• Журнал пожеланий релиза предназначен для формирования правильных ожиданий владельца продукта, команды и заказчика за счет простого и удобного механизма управления релизами и переноса пожеланий между ними.
• Группировка пожеланий по компонентам, целям, ожиданиям и другим критериям осуществляется за счет простого механизма тэгов, образующих специализированные "срезы" журнала пожеланий продукта.

Рисунок 2 - Журналы пожеланий

3. Ежедневные митинги (Daily-Scrums)

• Использование ежедневных митингов, особенно в распределенной команде, повышает эффективность процесса разработки и прозрачность проблемных ситуаций. DEVPROM позволяет проводить daily-Scrums в интерактивной форме и сохранять результаты обсуждений для последующего анализа.

4. Итеративная разработка (Iteration Planning)

• Поддержка итерационной разработки с фиксированной продолжительностью итерации.
• Поддержка процесса выпуска работающего продукта по окончанию каждой итерации за счет планирования реализации пожеланий по всем фазам разработки.
• Обеспечение согласованной оценки трудозатрат по реализации пожеланий, поступающей от всех участников команды.

5. Доска задач (Task board)

• Возможность представления задач в итерации (спринте) в форме "доски задач" позволяет быстрее воспринимать текущее состояние дел в итерации за счет визуальной группировки задач в зависимости от их состояния.

Рисунок 3 - Доска задач

6. Скорость команды (Velocity)

• Автоматическое вычисление скорости команды в целом и каждого участника в отдельности на основе выполненных задач. Вычисление скорости по каждой фазе разработки: анализу, реализации, тестированию и документированию.
• Оценка сроков выполнения произвольного набора пожеланий на основании средней скорости команды, прогнозирование необходимого времени, вычисление потенциального смещения сроков окончания релизов и итераций.

7. Burndown диаграмма (Burndown chart)

• Автоматическое построение burndown диаграммы для каждой из итераций проекта.
• Отображение диаграммы при планировании историй пользователей, просмотре итерации и на странице с задачами каждого участника.
• Подробная детализация показателей диаграммы за счет отображения скорости работы по каждой фазе разработки: анализу, реализации, тестированию и документированию.

8. Долгосрочное планирование (Release roadmap)

• Во время планирования карты выпуска версий продукта, часть пожеланий может быть включена в планируемые релизы продукта.
• При этом система сама вычисляет прогнозируемые даты завершения релизов и итераций на основе скорости разработки команды и планируемых оценок трудоемкостей пожеланий.

Рисунок 4 - Долгосрочное планирование

9. Тесное общение (Tight communications)

• Одним из основных моментов в Agile-проекте является активное общение внутри команды. DEVPROM предлагает возможность вести обсуждения любых артефактов проекта, вовлекая при этом каждого участника команды и представителей заказчика.
• Прозрачность выполнения любых изменений в проекте позволяет всем членам команды оперативно реагировать на эти изменения, поднимать проблемные вопросы и следить за ходом их решения.
• Ведение блога проекта с целью уведомления команды об основных договоренностях и результатах. Почтовая нотификация об изменениях в проекте.

10. Ретроспективы (Restrospective meeting)

• Фиксация результатов проведения ретроспектив с использованием общей базы знаний проекта.
• Быстрый доступ к истории ретроспектив, отслеживание реализации выявленных на ретроспективе улучшений.

Оцените, насколько полно Devprom AgileTeam покрывает особенности Agile процессов, с использованием чеклиста настоящего Scrum процесса: Проверка на соответствие правильному Agile

Конечно, ваша команда по-прежнему может использовать Excel для ведения журнала пожеланий продукта, а Jira для трекинга дефектов. И еще множество подручных инструментов для других проектных активностей.

Неужели вам все еще хочется продолжать делать кучу ручной работы, тратя на это ваше драгоценное время? Зачем растрачивать огромное количество энергии, только для того, чтобы обеспечить достаточный уровень коммуникаций в вашей команде и с заказчиком?

Позвольте инструменту делать за вас эту работу, а вы будете заниматься только действительно важными делами, регулярно поставляя заказчику качественный продукт. Независимо от того, сидит ваша команда в одной комнате или находится на разных континентах.

Подведя итог, необходимо отметить, что Agile-философия проста. Agile-принципы разумны. Но переход к реальному применению agile - это серьезный вызов для каждой команды. Требуется не только освоить новый подход к управлению проектами, но также подобрать людей, способных работать в agile режиме.

Заключение

Разработка программного обеспечения (ПО), как и любая другая техническая дисциплина, имеет дело со следующими основными проблемами: качество, стоимость и надежность.

В связи с этим правильная организация процесса разработки программного обеспечения является основой достижения запланированного результата в ожидаемые сроки, с ожидаемым уровнем качества и с адекватным бюджетом. Среди общераспространенных проблем процесса разработки программного обеспечения встречаются следующие:

1. Изменение требований непосредственно в процессе разработки.

2. Нечеткое распределение ответственности за выполняемую работу и ее результат.

3. Наличие непрерывного потока мелких, «быстрых», наваливающихся требований, отвлекающих разработчиков и менеджеров от основного направления работ.

4. Как следствие, срыв сроков, раздувание бюджетов, потеря качества. Для решения задачи успешной организации процесса разработки ПО была создана гибкая методология разработки ПО.

Гибкая методология разработки (англ. Agile software development) – это набор принципов и правил, в рамках которого осуществляется разработка ПО.

Методология Agile – это семейство процессов разработки, а не единственный подход к разработке программного обеспечения. Ценности и принципы Agile методологии закреплены в документе ‘Agile Manifesto’. Agile не включает конкретных практик, а определяет ценности и принципы, которыми руководствуются успешные команды.

Список использованной литературы

1. Бизнес-планирование: Учебник для вузов/ Под ред. В.М Попова, С.И. Ляпунова, С.Г. Млодика. – М.: Финансы и статистика, 2012. – 816 с.

2. Быстрая разработка программ. Принципы, примеры, практика Роберт К. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Издательство: Вильямс. 2017 г. 704 с.

3. Гибкое управление IT-проектами. Руководство для настоящих самураев Джонатан Расмуссон. Издательство: Питер.20212 г. 272 с.

4. Орлова Е.Р. Бизнес-план: Методика составления и анализ типовых ошибок / Е.Р. Орлова. - М.: Омега-Л, 2013. - 168 c.

5. Проектирование информационных систем. Татьяна Гвоздева, Борис Баллод. Феникс. 512с – 2009г.

6. Революционный метод управления проектами Джефф Сазерленд. Издательство: Манн, Иванов и Фербер.2015 г . 288 с.

7. AgileRussia - [Электронный ресурс] - режим доступа: http://agilerussia.ru/practices/внедрение-agile/

8. Гибкая методология разработки (Agile) - [Электронный ресурс] - режим доступа: http://mahamba.com/ru/gibkaya-metodologiya-razrabotki-agile

9. Agile/Scrum для начинающих. Что такое гибкая методология? - [Электронный ресурс] - режим доступа: http://www.pmoffice.by/blog/agile/agile-approach.html

10. РАЗБЕРЕМСЯ С AGILE: ЧТО ТАКОЕ AGILE И КАК ИСПОЛЬЗОВАТЬ В ПРАКТИКЕ БИЗНЕСА - [Электронный ресурс] - режим доступа: http://www.savkinks.ru/agile-management.htm

11. Жертвы Agile - [Электронный ресурс] - режим доступа: https://vc.ru/p/agile-victims

1. Революционный метод управления проектами Джефф Сазерленд. Издательство: Манн, Иванов и Фербер.2015 г. – С. 48-49. ↑

2. AgileRussia - [Электронный ресурс] - режим доступа: http://agilerussia.ru/practices/внедрение-agile/ ↑

3. Agile/Scrum для начинающих. Что такое гибкая методология? - [Электронный ресурс] - режим доступа: http://www.pmoffice.by/blog/agile/agile-approach.html ↑

4. РАЗБЕРЕМСЯ С AGILE: ЧТО ТАКОЕ AGILE И КАК ИСПОЛЬЗОВАТЬ В ПРАКТИКЕ БИЗНЕСА - [Электронный ресурс] - режим доступа: http://www.savkinks.ru/agile-management.htm ↑

5. Гибкое управление IT-проектами. Руководство для настоящих самураев Джонатан Расмуссон. Издательство: Питер.20212 г. – С.89. ↑

6. AgileRussia - [Электронный ресурс] - режим доступа: http://agilerussia.ru/practices/внедрение-agile/ ↑

7. Жертвы Agile - [Электронный ресурс] - режим доступа: https://vc.ru/p/agile-victims ↑