Введение
1. Agile
1.1. История появления
1.2. Принципы Agile
1.3. Оценка методики
2. Методологии Agile
2.1. Экстремальное программирование ХР
2.2. Бережливая разработка программного обеспечения
2.3. Scrum
2.4. Crystal Clear
2.6. Dynamic Systems Development Method (DSDM)
2.7. Feature-driven development
2.8. Канбан
Заключение
Список литературы
Введение
Начиная с самых первых программных планов по сейчас, разработ-ка программного обеспечивания была и остаётся недостаточно прогнози-руемым и не всякий раз удачным делом. Наибольшая доля планов по раз-работке программного обеспечения до сих времен заканчивается с выхо-дом за рамки бюджета, сроков, а разработанные в итоге программы не-редко не отвечают требованиям пользователей или не приносят реальной полезности бизнесу.
Гибкие методы — считается прогрессивным ответом программной индустрии на вопрос как увеличить возможность удачного выполнения плана и ублаготворить притязаниям клиента и юзеров.
Постоянно увеличивающиеся требования к информационным систе-мам приводят к их усложнению. Современные информационные системы характеризуются такими особенностями, как:
1. сложность описания (большая численность функций, процес-сов, составляющих элементов, трудные связи меж ними);
2. наличие совокупности плотно взаимодействующих компонен-тов (подсистем), имеющих собственные локальные задачи и цели функцио-нирования;
3. нужность интеграции существующих и заново разрабатывае-мых приложений;
4. отсутствие прямых аналогов, ограничивающее вероятность ис-пользования каких-то типовых проектных заключений и прикладных си-стем;
5. функционирование в разнородной среде на нескольких аппа-ратных платформах;
6. временная протяженность разработки плана информационной системы, обусловленная масштабами организации-заказчика, разной сте-пенью готовности подразделений к внедрению информационной системы, ограниченными возможностями коллектива разработчиков и т. д.;
7. разнородность отдельных групп создателей по уровню квали-фикации и предпочтениям применения инструментальных средств.
Для удачной реализации информационной системы необходимо адекватное описание системы, полные, непротиворечивые функциональные и информационные модели информационной системы. До недавнешнего времени проектирование информационной системы производилось в ос-новном на интуитивном уровне с использованием не формализованных способов, которые основаны на искусстве, практическом опыте создателей. Не считая этого, также в процессе сотворения и функционирования ин-формационной системы, информационные потребности пользователей мо-гут изменяться или же уточняться, и это ещё больше усложняет разработку и сопровождение информационных систем.
Актуальность данной темы состоит в том, собственно, что гибкие способы разработки пробуют освободиться от минусов не формализован-ных способов и посодействовать в организации работы разработчиков программного обеспечения в условии предъявления всё больших требова-ний к информационной системе, скорости и качеству разработки. Еще в условиях всё большей конкуренции на рынке информационных услуг все-гда появляются свежие проекты, гибкие методологии коим позволяют до-биться наибольших результатов за короткое время.
Целью курсовой работы является рассмотрение методов «быстрой» разработки программной системы.
Объект исследования — методологии разработки программных средств.
Предмет исследования – методологии Agile и ХР.
В рамках выполнения работы предстоит решить ряд следующих за-дач
1. Изучить общую информацию об Agile методологиях
2. Изучить Agile-манифест
3. Узнать основные принципы их работы
4. Обозначить решаемые ими задачи
5. Классифицировать Agile методики, сравнить их, выявить достоин-ства и недостатки.
Основными авторы, в научных произведениях которых рассматри-валась проблема исследования Солонин Е. Б., Вольфсон Борис, Кент Бек, Уорд Каннингем, Мартин Фаулер, Бриткин А.И. и другие.
1. Agile
1.1. История появления
Концепты гибкой разработки в первый раз были опробованы между производителями авто в Японии в 80-е годы двадцатого века. В то время эти концепты были взяты производителями в Америке и в их IT-службах.
Как лишь только эти идеи зарекомендовали себя в автопромышлен-ности, они стали применяться и в иных отраслях под воздействием работ, которые были опубликованы в журналах и демонстрировали успешный опыт использования на конференциях, которые посвящены IT.
Одной из самых первых работ, благодаря коим случилось зарожде-ние передовых способов итеративной разработки, считается размещенная в 1985 году статья Барри Боэма «Спиральная модель разработки про-граммного обеспечения», создателя ведущей методики для оценки трудо-затратности разработки ПО.
В начале 90-ых Джефф Сазерленд и Кен Швабер в компании Easel Corp начали применять методологию, которую они именовали Scrum. В способе был применен подход, который применялся в таких не софтвар-ных компаниях, как Fujitsu, Canon и Honda. По Scrum’у протекают трид-цатидневные итерации, называемые спринтами. Еще повышенное внимание уделяется практикам по самоорганизации команд. 1-ая работа о Scrum’е была изготовлена в 1999-ом г.
В середине 90-х фирма Rational начала разработку методологии Rational Unified Process (унифицированный процесс Rational), в базу коей были положены итеративность и инкрементность разработки. Процесс ре-ализован на использовании фактов применения (Use Cases) и включает набор нескольких «наилучших практик» софтовой разработки на все слу-чаи жизни.
В 1994г. группа людей, которые использовали резвую разработку приложений (Rapid Application Development), собралась, для того, чтобы обсудить описание типового итеративного процесса. Спустя некое время это вылилось в методологую DSDM (Dynamic Systems Development Method), которая востребована на ее родине, в Соединенном Королевстве Великобритании.
В 1996г. к проекту Chrysler C3, который был практически прова-лившимся к тому времени, присоединился Кент Бек. Они с Роном Джефф-рисом воспользовались всеми известными ими на тот момент практиками и пришли к выводу, что их объединение приумножает эффект, получаемый от каждой по отдельности. Методология, именуемая далее Экстремальным программированием (XP), быстро стала известна благодаря упору на про-стоту, коммуникацию и преждевременное тестирование, ну и по причине провокационного наименования.
В 1997г. Джефф Де Люка и Питер Коад присоединились к проваль-ному плану по построению большой логистической системы и отлично со-владали с ним при помощи использования итеративной разработки. Они обрисовали личный подход к проектированию в методологии Feature Driven Development (FDD).
В 2001г. семнадцать создателей методологий, разработчиков DSDM, XP, Scrum, FDD и других, собрались, дабы попробовать отыскать чего-нибудь общее в собственных подходах. Итогом стал Манифест гибкой разработки (Agile Manifesto; http://agilemanifesto.org). Оттуда же появился термин Agile (что значит резвый, гибкий), объединяющий все методологии в единый класс. Термин «гибкий» был избран по причине способности от-кликаться на изменения в требованиях при разработке программного обеспечивания под контролем и иметь высокий уровень гибкости. [11]
1.2. Принципы Agile
Agile – семейство подходов в разработке ПО, и главные основы из-ложены в Agile-манифесте. Agile не включает практических рекомендаций, а определяет базисные значения и основы, коими руководствуются успеш-ные команды и определяют базу гибкого подхода к разработке программ-ного обеспечения, но не имеет практических рекомендаций.
Agile Manifesto имеет 4 главные идеи и 12 принципов.
Основными идеями Agile Manifesto являются:
1. Люди и взаимодействие значимее процессов и инструментов.
2. Работающий продукт значимее исчерпающей документации.
3. Сотрудничество с заказчиком значимее согласования критерий до-говора.
4. Готовность к переменам значимее следования начальному плану.
Принципы, которые содержатся в Agile Manifesto:
1. Наивысшей ценностью считается удовлетворение потребностей клиента благодаря постоянной и ранней поставке ценного ПО.
2. Изменение требований приветствуется в том числе и на поздних стадиях разработки. Agile-процессы дают возможность применять конфи-гурации для обеспечивания клиенту конкурентного преимущества.
3. Работающий продукт следует издавать часто, с периодичностью до пары месяцев от пары недель.
4. На протяжении всего плана создатели и представители бизнеса обязаны каждый день трудиться совместно.
5. Над проектом обязаны трудиться профессионалы. Для того, чтобы работа была сделана, необходимо создавать условия, обеспечить помощь и полностью довериться им.
6. Непосредственное общение считается более удобным и действен-ным методом обмена информацией как с самой командой, так и изнутри команды.
7. Работающий продукт – главный показатель прогресса.
8. Инвесторам, разработчикам и пользователям необходимо иметь возможность поддерживать неизменный ритм безгранично. Agile может помочь сделать подобный стойкий процесс разработки.
9. Систематическое внимание к техническому совершенству и каче-ству проектирования увеличивает гибкость плана.
10.Простота- искусство минимизации бесполезной работы- очень важна.
11.Наилучшие запросы, строительные и технические заключения рождаются у самоорганизующихся команд.
12.Команда обязана постоянно разбирать вероятные методы совер-шенствования производительности и в соответствии с этим корректировать стиль собственной работы.
1.3. Оценка методики
Agile-методы проделывают упор на конкретное общение изнутри ко-манды-разработчика. Команда включает «клиента», который определяет запросы к системе (эту роль имеет возможность исполнять менеджер про-екта, бизнес-аналитик или же заказчик), проектировщиков, разработчиков ПО, тестировщиков, тех. писателей и менеджеров. Отдавая предпочтение непосредственному общению, agile-методы сокращают объем письменной документации по сравнению с иными методами.
Гибкий подход к управлению требованиями не предполагает долго-срочных намерений (по сущности, управления требованиями элементарно не существует в этой методологии), но учитывает вероятность для клиента в конце всякой итерации выдвигать свежие запросы, нередко без оглядки на изобретенный продукт.
Считается, что работа в Agile мотивирует создателей решать все про-ектные задачи простым из вероятных методикой, при данном нередко не обращая интереса на корректность кода с точки зрения требований ис-пользуемой программной платформы.[6]
2. Методологии Agile
Есть целый ряд методик, которые держатся основ, которые заявлены в Agile Manifesto, наиболее известными из них являются:
Agile Modeling — набор практик и понятий, которые созданы для быстрого и простого моделирования и документирования в планах разра-ботки программного обеспечивания. Не включает в себя чёткий набор ука-заний по проектированию и не обхватывает тестирование и программиро-вание, не включает вопросы управления планом, развертывания и сопро-вождения системы. Но включает в себя требование к написанию тестов к программе.
Agile Unified Process (AUP) разработана Скоттом Амблером, обри-совывает простую и понятную модель сотворения ПО для бизнес- прило-жений.
Agile Data Method (англ.) — группа итеративных способов разработ-ки ПО, в коих требования и решения достигаются в рамках сотрудниче-ства различных кросс- функциональных команд.
DSDM реализован на концепции резвой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придает особенный смысл длительному участию в процессе пользователя/потребителя.
Экстремальное программирование XP
Feature driven development (FDD) — функционально-ориентированная разработка. Применяемое в FDD понятие функции си-стемы довольно вблизи к понятию прецедента применения, применяемому в RUP, главное различие — это лимитирование: «каждая функция обязана допускать реализацию не больше, чем за 2 недели». Т.е. в случае если сце-нарий применения довольно мал, его возможно считать функцией. В слу-чае если же велик, то его надобно разбить на некоторое количество срав-нительно независящих функций.
Getting Real — итеративный подход, в котором сначала разрабаты-вается интерфейс программы, а затем ее функциональная часть.
Scrum устанавливает правила управления процессом разработки и разрешает использовать уже имеющие место быть практики кодировки, корректируя запросы или же внося тактические изменения. Применение данной методологии выделяет вероятность обнаруживать и ликвидировать отклонения от желанного итога на более ранних шагах разработки ПО.
Экономная разработка программного обеспечения базирована на подходах бережного производства.
2.1. Экстремальное программирование XP
Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из Alige-методологий разработки программного обеспечения. Ав-торами являются Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
XP считается довольно молодой методологией, оценки коей очень противоречивы- от восхищенных до неблагоприятных. Главными принци-пами считаются:
• Простота решений (simplicity).
• Интенсивная разработка маленькими группами (не более 10 чело-век), активное общение в группе и меж группами (communication).
• Обратная связь с заказчиком (feedback), который практически во-влечён в процесс разработки.
• Необходимый уровень смелости (courage) и желание идти на риск.
Первым фактором ускорения разработки является итеративность: разработка ведётся краткими итерациями при наличии интенсивной связи с клиентом.
XP является итеративным процессом разработки, который сам по се-бе не считается революционным. Итерации как этакие предлагается созда-вать краткими, подходящая длительность — две-три недели и не больше одного месяца. За 1 итерацию группа разработчиков должна осуществить некоторое количество свойств системы, любое из коих описывается в поль-зовательской истории (user story). Пользовательские истории в этом случае считаются исходной информацией, на базе коей формируется модуль.
У пользовательских историй в отличии от прецедентов (use case) пользовательская история кратка — один-два абзаца, а у прецедентов- до-вольно подробна, с главным и другими потоками — и так, выходит при-близительно страница + схема (более распространенная формализация в реальное время предложена в UML); ситуации юзеров пишутся самими юзерами (они в XP считаются частью команды) в различии от прецеден-тов, кои, как правило, сообщает системный аналист.
Недоступность формализации описания входных данных плана в XP желают возмещать при помощи интенсивного подключения в процесс раз-работки клиента как полноценного члена команды и за счёт присутствия непрерывного контакта с клиентом (интенсивное взаимодействие и посто-янная поддержка оборотной взаимосвязи). В этом случае extreme является степенью привлечения клиента к программистской кухне, собственно, что обосновано влечением уменьшить сроки разработки за счёт коммуникаций и оборотной взаимосвязи.
Вторым фактором ускорения разработки продукта является присут-ствие небольших групп и парное программирование (когда 2 разработчи-ка ПО совместно делают шифр в 1 совокупном трудовом участке). Всё это направлено на достижение высочайшего уровня общения в группе, а еще на как возможно больше преждевременное обнаружение задач (как про-махов, так, например, и провала сроков).
Цель парного программирования: стабилизация плана, т.к. при этой методологии достаточно высок риск потери кода, причиной которого яв-ляется уход разработчика ПО, который не выдержал активного графика трудовой деятельности. В данной ситуации 2ой разработчик ПО из пары играет роль «наследника» кода, что в традиционных способах реализуется в техдокументации. Важно и то, равно как непосредственно распределены группы в трудовом месте— в XP применяется раскрытое рабочее про-странство, что подразумевает стремительный и независимый допуск абсо-лютно всех к абсолютно всем; как правило, рабочее место создается на ба-зе области.
Третьим фактором ускорения разработки процесса является утвер-ждение 1ого простейшего трудового решения. В этом случае экстремаль-ность способа сопряжена со значительной степенью риска решения, кото-рое обусловлено поверхностностью рассмотрения и строгим временным графиком. Реализуется наименьший набор основных функций системы на 1ой и любой следующей итерации; работоспособность расширяется на любой итерации. [1] XP применяет 5 основных ценностей: общение, легкость, противопо-ложная взаимосвязь, решимость и уважение. На них базируются наборы из двенадцати практик (действий), кои нужно осуществлять с целью свер-шения отличного итога (рис.1). Практики XP никак не устанавливают непосредственно процесс XP, однако XP определяет данные практики — в таком случае осуществление практик никак не гарантирует результата. Ни одна из практик не считается сознательно новейшей, однако в XP они со-браны совместно.
Рисунок 1 – Практики экстремального программирования [15] 
• Планирование процесса (planning game). Вся группа собирается вместе, принимает общее решение о том, какие свойства системы станут выполнены в ближней итерации. Комплект свойств обуславливается поль-зовательскими историями. XP-трудозатратность каждого свойства обу-словливается самими разработчиками ПО.
• Тесное взаимодействие с заказчиком (feed-back, on-site customer). Клиенту необходимо являться членом XP-команды (on-site customer). За-казчик сообщает пользовательские события, подбирает ситуации, какие станут реализованы в определенной итерации, и дает ответы на вопросы, которые касаются бизнеса. Клиенту необходимо являться специалистом в автоматизируемой настоящей сфере. Нужно непрерывное присутствие противоположной ввзаимосвязи с клиентом (feed-back).
• Метафора системы (system metaphor). Оптимальная метафора си-стемы, это значит простота наименования классов и переменных. В насто-ящей жизни поиск метафоры — весьма непростое дело; отыскать отличную метафору нелегко. В каждом случае группа обязана обладать едиными правилами наименования.
• Простая архитектура (simple design). Каждому свойству системы необходимо реализованным как возможно легче. Разработчики ПО в XP-группе трудятся под лозунгом: «Ничего лишнего!». Так применяется 1ое простейшее функционирующее решение, реализуется нужный уровень функциональности в этот период. Этим экономится время разработчика ПО.
• Стандарты кодирования (coding conventions). Эталоны кодирова-ния необходимы для обеспечения иных практик: коллективного владения кодом, парного программирования и рефакторинга. В отсутствии общего стандарта осуществлять данные практики как минимум труднее, а в дей-ствительности в целом нереально: команда будет трудиться в режиме ста-бильной нехватки времени. Подробные стандарты не требуются, следует стандартизировать только лишь значимые вещи. Установление более наи-важных объектов стандартизации в XP индивидуально.[8] • Рефакторинг (refactoring). Рефакторинг является оптимизацией имеющегося кода в сторону упрощения, что учитывает стабильный труд по упрощению кода. Удерживая шифр бесцветным и устанавливая его компоненты единственный раз, разработчики ПО уменьшают количество ошибок, какие позже понадобится ликвидировать. При осуществлении лю-бого новейшего качества системы разработчику ПО необходимо обдумать то, возможно ли облегчить имеющийся шифр и как данное сможет помочь осуществить новейшее качество. Помимо этого, невозможно сочетать ре-факторинг с дизайном: в случае если формируется новейший шифр, ре-факторинг необходимо отсрочить.
• Парное программирование (pair programming) является одним из наиболее популярных XP-практик. Всем разработчикам ПО необходимо трудиться вдвоем: один пишет код, второй глядит. Итак, нужно размещать команду разработчиков ПО в одном месте, это лучше всего осуществить на территории клиента (все нужные члены группы географически будут находится в одном месте); XP более благополучно функционирует в не-разделенных коллективах разработчиков ПО и юзеров.
• 40 часовая рабочая неделя. Разработчик ПО не обязан трудиться больше, чем восемь часов в день. Нужность сверхурочной деятельности (overtime) — это точный индикатор трудности на этой определенной направленности разработки; к тому же клиент не оплачивает сверхуроч-ную работу в XP. Поиски факторов сверхурочной деятельности и их ско-рое предотвращение является одним из главных правил.
• Коллективное владение кодом (collective code ownership). Все раз-работчики ПО в команде XP должны обладать доступом к коду каждой части системы и обязаны вводить перемены во всякий шифр. Неотъемле-мая норма: если разработчик ПО внёс изменения и система уже после дан-ного функционирует неправильно, в таком случае непосредственно данный разработчик обязан откорректировать погрешности. В ином случае функ-ционирование системы уподобится полному беспорядку.
• Частая смена версий (small releases). Минимальной итераци-ей является один день, максимальной- месяц; нежели больше осуществля-ются релизы, этим более недочетов системы станет выявлено. 1ые релизы могут помочь обнаружить минусы в наиболее преждевременных стадиях, затем работы системы расширяется, исходя из тех же пользовательских ис-торий. Так как юзер вводится в процедуру разработки с 1ого релиза, то он дает оценку системы и выдаёт пользовательскую историю + feedback. На базе данного обусловливается последующая итерация: каковым станет но-вейший релиз. В XP всё нацелено на предоставление постоянной оборот-ной взаимосвязи с юзерами.
• Непрерывная интеграция (continuous integration). Интеграция но-вейших элементов системы обязана осуществляться как возможно больше, как минимум один раз в несколько часов. Основным правилом интеграции является то, что интеграцию возможно осуществлять, если все тесты про-текают благополучно. Если тесты не проходят, то разработчику ПО необ-ходимо или внести корректировки и затем интегрировать составные части системы, или не интегрировать их. Правило это строгое и однозначное — если в созданной части системы есть хоть одна ошибка, то интеграцию осуществлять нельзя. Частая интеграция дает возможность скорее приоб-рести готовую систему, взамен того, чтобы расходовать на сборку неделю.
• Тестирование (testing). В отличие от многих других методологий тестирование в XP является одним из основных образующих. Экстремаль-ный подход состоит в том, что тесты пишутся до написания кода. Любой модуль должен обладать unit test — тест этого модуля; итак, в XP испол-няется regression testing (возвратное тестирование, «неухудшение каче-ства» при добавлении функциональности). Большее количество ошибок корректируются на стадии кодирования. Тесты пишут сами разработчики ПО; все программисты имеют право написать тест для каждого модуля. Ещё одним важным принципом является то, что тест определяет код, а не наоборот (такой подход носит название test-driven development), то есть кусок кода кладётся в хранилище тогда и только тогда, когда все тесты прошли благополучно, в ином случае это изменение кода отвергается.
Эти методики собраны воедино не случайно. Непротиворечивость всех этих методик позволяет заметно повысить качество продукта и выпу-стить его точно в срок. [9] Основная прелесть всего экстремального про-граммирования — прогнозируемость и сведение к минимуму затрат на разработку; предоставление заказчику того продукта, который он желает получить на момент выпуска. Также общение и повышение квалификации программистов без отрыва от производства является неотъемлемым плю-сом методики.[14] Однако по мнению автора книги «Экстремальное программирова-ние» Кент Бека, XP довольно сложен для внедрения и подойдет далеко не к каждому проекту и для того чтобы получить выгоду от его внедрения, необходимо с умом пользоваться принципами XP и не в любом проекте.
2.2. Бережливая разработка программного обеспечения
Бережная разработка ПО использует концепции бережливого произ-водства.
Основными принципами являются:
Исключение потерь. Потери — это все то, что не приносит ценности для потребителя. Видов потерь в разработке ПО довольно большое коли-чество: от переключения меж задачами до реализации лишнего функцио-нала. Существует правило 20/80: 20% функционала продукта доставляют 80% ценности клиенту и непосредственно гибкие методологии дают воз-можность эти 20% функционала обнаружить и определить им наибольшую значимость.
Акцент на обучении. Весь процесс формирования ПО практически состоит из обучения: с каждой новой функцией члены группы познают что-то новое. Поэтому, как и для всякого иного инженерного труда, нужно сконцентрироваться на обучении.
Отсроченное принятие решений. Чем позднее будет принято реше-ние, тем больше шансов, что оно будет удовлетворительным до конца проекта.
Максимально быстрая доставка заказчику. Частые сборки програм-мы для тестирования.
Мотивация команды. Все члены группы обязаны иметь интерес к проекту.
Интегрирование. Предоставить целостную информацию клиенту. Стремиться к целостной архитектуре. Рефактеринг.
Целостное видение. Стандартизация, установление отношений меж разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, делать мало, ошибаться быстро; учиться стремитель-но». [19]
2.3. Scrum
Scrum (от англ. scrum – «толкучка») – методология управления про-ектами, которая стремительно применяется при разработке информацион-ных систем для гибкой разработки ПО [5]. Scrum создает упор на высоко-качественном контроле процесса разработки.
В основании управления процессами в Scrum приняты 3 основных принципа: прозрачность, инспекция и адаптация. Прозрачность значит, что все важные аспекты процесса обязаны быть доступными тем, кто за не-го в ответе. Прозрачность требует, чтобы данные нюансы определялись едиными стандартами, а всем членам команды необходимо пользоваться едиными понятиями и терминами. Инспекции ведутся довольно зачастую с целью оперативного раскрытия нежеланных отклонений от определенных целей. Но инспектирование не должно являться до такой степени частым, чтобы препятствовать работе.
Если по результатам инспекции обнаружены отклонения, то нужно как возможно скорее внести коррекцию в продукт, чтобы избежать рас-пространения проблемы на иные элементы системы. [18] Scrum применяется не только для разработки программного обеспе-чения, но и также для большинства процессов по формированию продук-та: от венчурных до маркетинговых продуктов. Scrum, как правило, рас-ширяют инженерными практиками из иных гибких методологий (к приме-ру, практики разработки из экстремального программирования, либо практики анализа и сбора требований из ICONIX).
Scrum достаточно простой. Сначала собственник продукта (product owner) — клиент — составляет перечень требований с расставленными при-оритетами и отдает группе. Затем группа устанавливает, какие из приори-тетных условий она сможет исполнить за месяц. Общая схема работы Scrum изображена на заимствованном из книги Вольфсона Бориса «Гиб-кие методологии разработки» рис. 2.
Рисунок 2 — общая схема Scrum [17]
Корни Scrum лежат в принципах «бережливого производства», непо-средственно с того места взят подтвердивший на практике собственную ре-зультативность принцип подбора условий. Для всякой итерации группа берёт наиболее приоритетные требования и разбивает на множество не-больших вопросов.
Каждый день команда собирается в составе 7 ± 2 человека. На по-добных встречах любой участник разработки повествует о том, что вы-полнено вчера, что необходимо сделать сегодня, также повествует наибо-лее подробно о важных моментах и о возникающих трудностях. В процес-се всеобщего созыва ищутся методы разрешения данных трудностей. По-вседневные сборы группы увеличивают эффективность деятельности, как демонстрирует практическая деятельность.
Команда в Scrum трудится на принципах самоорганизации: самосто-ятельно подбирает, какие работы группа сможет исполнить за итерацию и создает подходящий перечень работ, стремясь подобрать наиболее быст-рый способ формирования приложения. Лидеру группы, мастеру Scrum необходимо обеспечить группе всё нужное для осуществления отобранных задач, но не диктовать, что необходимо проделывать каждому участнику разработки. Стиль управления, при коем менеджер распределяет задачи членов группы, часто задерживает процесс.
При помощи специальных диаграмм мастер следит за процессом итерации, предопределяет объем остальных вопросов и устанавливает ны-нешний статус работ. Наименьшая отчётность дает возможность руково-дителю группы непрерывно прослеживать, что совершается в проекте, га-рантирует абсолютную прозрачность процесса.
В основе Scrum лежит механизм непрерывного улучшения качества разрабатываемого продукта. Одной из главных обязанностей мастера Scrum является определение препятствия к благополучному продвижению проекта вперед и удаление этих преград. Как показала практика, правиль-но реализованная методология Scrum позволяет достичь двенадцати крат-ного улучшения качества результата и четырехкратного увеличения про-дуктивности работы. Но для достижения таких результатов, нужно каж-дый день совершенствоваться. Для фирм это всегда весьма трудно. Scrum обнаруживает все проблемы фирмы и ставит им приоритеты. Мастер Scrum работает с данным перечнем проблем, устремляясь к тому, чтобы команда исправляла ошибки в разработке, а менеджмент — в компании. [7] Scrum устанавливает 3 роли участников процесса:
Владелец продукта (product owner) является лицом, кое устанавлива-ет требования к продукту.
Команда (team) является группой инициативных и самостоятельных разработчиков. Команда Scrum может помочь абсолютно всем членам быть командными игроками. Всегда имеются отличные разработчики, ка-кие не в состоянии контактировать с иными людьми. Но при трудной и масштабной разработке такое невозможно. Необходимы люди, которые работают совместно, в команде.
Мастер Scrum (Scrum master) является лицом, ответственным за ор-ганизационные трудности и надзор соблюдения методологии Scrum. Ма-стер Scrum не является начальником, выдающим указания, а является че-ловеком, который применяет все без исключения собственные способности для содействия эффективной разработке, который способен управлять на собственном примере, воодушевлять людей на труд, выступать в роли тренера, наставника.
Общая схема процесса, протекающего при разработке по Scrum представлена на рис. 3.
Рисунок 3 — Scrum процесс [17]
В методологии Scrum план можно разбить на 3 фазы:
Подготовка (Pregame) – оформляется единый проектный план, обу-словливается перечень основных требований к продукту и разрабатывает-ся первоначальная стадия архитектуры продукта. В период фазы реализа-ции исполняется главное итеративное формирование продукта.
Реализация (Game) разбита на итерации, какие именуются спринтами (Sprint). В следствии любого спринта в продукте реализуется новейший, видимый для собственника продукта, объем функциональности. В завер-шении любого спринта продукция должна основаться в трудоспособном состоянии.
Любой спринт начинается с сессии планирования (Sprint Planning Meeting), в период каковой обусловливается перечень вопросов, какие бу-дут исполнены в протяжение спринта. Повседневно участники проекта со-бираются в скрам-сессии (Daily Scrum Meeting), где сообщают о собствен-ных нынешних планах и трудностях, которые возникли в работе. По окон-чанию спринта ведется демонстрационная сессия (Sprint Review Meeting), в период коей реализованная функциональность демонстрируется собствен-нику проекта.
Завершение (Postgame) — продукт выпускается на рынок.
Проект управляется 3 документами,:
Журнал продукта (Product Backlog) — высокоуровневый перечень технических и многофункциональных требований, которые необходимы для реализации продукта.
Журнал спринта (Sprint Backlog) — детализированный перечень мно-гофункциональных и технических требований, которые необходимы для благополучного окончания итерации.
График спринта (Burndown Chart) включает каждодневное изменение всеобщего объема работ, который остался до окончания итерации.
Вся работа создается при помощи Scrum- процессов:
Скрам-митинг (планерка) – совещание членов группы с перспективой приглашения собственники продукта с целью синхронизации работы группы и обозначения трудностей. Любой участник команды отвечает на 3 вопроса:
1. Что было выполнено с прошлого скрам- митинга?
2. Какие существуют проблемы?
3. Что будет выполнено к последующему скрам-митингу?
Планирование спринта. Главным итогом планирования спринта счи-тается беклог спринта – перечень вопросов, какие группа собирается осу-ществить в рамках спринта (рис.4)
Рисунок 4 — Обратная связь Scrum [17]
2.4. Crystal Clear
Crystal Clear – это легковесная гибкая методология, созданная Али-стером Коуберном (Cockburn, 2004). Она предназначена для небольших команд в 6-8 человек для разработки некритичных бизнес-приложений. Как и все гибкие методологии Crystal Clear больше опирается на людей, чем на процессы и артефакты. [20] Crystal Clear использует семь методов/практик, три из которых яв-ляются обязательными:
1. Частая поставка продукта
2. Улучшения через рефлексию
3. Личные коммуникации
4. Чувство безопасности
5. Фокусировка
6. Простой доступ к экспертам
7. Качественное техническое окружение
В графическом виде практики Crystal Clear представлены на рис. 5:
Рисунок 5 — Методики Crystal Clear [17]
Все практики, как видно, характерны для семейства Agile-методологий. Ведущие консультанты обмениваются информацией о свой-ствах проекта, а не о соблюдаемых процедурах. Они спрашивают о состо-янии проекта: «Имеется ли формулировка задачи и план проекта? Часто ли они добиваются нужного результата? Находятся ли спонсор и различ-ные опытные пользователи в непосредственном контакте с группой?»
Следовательно, отклоняясь от обычного способа описания методоло-гии, имеет смысл спросить группы Crystal Clear об ориентировочных клю-чевых свойствах проекта. «Кристально чистое выполнение» становится до-стижением характеристик, а не следованием процедурам. Есть две причи-ны перехода от процедур к характеристикам:
Процедуры могут не генерировать характеристики. Характеристики более важны. Другие процедуры, отличные от выбранных, могут генери-ровать характеристики для вашей конкретной группы.
Семейство Crystal сосредоточено на трех характеристиках – посто-янная выработка, хорошая коммуникация и отражающее усовершенство-вание, так как они должны присутствовать во всех проектах. Crystal Clear использует преимущества небольшого размера и расстояния между груп-пами, чтобы усилить хорошую коммуникацию до более эффективной ос-мотической коммуникации. Опытные разработчики заметят, что, эа ис-ключением этого изменения, все описанные здесь характеристики приме-нимы к каждому проекту, а не только к проектам с маленькими группами.
Crystal Clear описывается здесь как набор характеристик. Большин-ству описаний методологий недостает важного показателя, отделяющего успешную группу от неуспешной. Группа Crystal Clearопределяет ее со-стояние по настроению группы и характеру коммуникации, а также по сте-пени продуктивности. Присваивание названий характеристикам обеспечи-вает группу слоганами для определения ее ситуации: «В течение некоторо-го времени мы не выполняли отражающее усовершенствование», «Можем ли мы получить более легкий доступ к опытным пользователям?» Сами названия характеристик помогают людям выявлять и обсуждать методы урегулирования текущей ситуации.
2.6. Dynamic Systems Development Method (DSDM)
Методология DSDM (Dynamic Systems Development Method – метод разработки динамических систем) основана на подходе RAD (Rapid Appli-cation Development – быстрая разработка приложений) и включает в себя три стадии. (рис.6):
Предпроектная стадия, на которой авторизуется реализация проекта, определяются финансовые параметры и команда.
Жизненный цикл проекта представляет собой реализации проекта и включает в себя пять этапов.
Постпроектная стадия обеспечивает качественную эксплуатацию си-стемы.
Рисунок 6- Стадии разработки [3]
Жизненный цикл проекта включает в себя пять стадий (первые две фактически объединяются):
1. Определение реализуемости
2. Экономическое обоснование
3. Создание функциональной модели
4. Проектирование и разработка
5. Реализация [13] Цель метода DSDM – соблюдение сроков и бюджета проекта при до-пущении изменений в требованиях к системе во время ее разработки. Как представитель RAD-технологии DSDM фокусируется на проектах инфор-мационных систем, характеризующихся сжатыми сроками и бюджетами.
DSDM входит в семейство гибкой методологии разработки про-граммного обеспечения, а также может применяться для разработок, не входящих в сферу информационных технологий.
В рамках DSDM существуют следующие факторы, которые влияют на успех проекта:
— принятие методики DSDM руководством проекта и всеми его участниками, что обеспечивает мотивацию членов команды с момента за-пуска проекта и до его окончания;
— готовность руководства обеспечить вовлеченность конечных поль-зователей в работу над проектом, включая тестирование и оценивание функциональных прототипов;
— проектная команда должна в итоге стать постоянной, что обеспечи-вает доверие и взаимопонимание внутри нее. Команда обладает правом и возможностью принимать важные решения о проекте без формального со-гласования с руководством, что могло бы отнять много времени;
— DSDM выступает за постоянные продуктивные отношения между разработчиком и заказчиком. Это касается как проектов, разрабатывае-мых внутри самих компаний, так и проектов с привлечением сторонних подрядчиков.[18]
2.7. Feature-driven development
Функционально-ориентированная разработка (Feature Driven Development, FDD) оперирует понятием функции или свойства (feature) си-стемы, достаточно близким к понятию сценария использования, применяе-мому в RUP. Едва ли не самое существенное отличие — это дополнитель-ное ограничение: «каждая функция должна допускать реализацию не более чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией, а если велик, то его надо разбить на несколь-ко относительно независимых функций.
FDD включает пять процессов, причем последние два повторяются для каждой функции:
разработка общей модели;
составление списка необходимых функций системы;
планирование работы над каждой функцией;
проектирование функции;
конструирование функции.
Работа над проектом предполагает частые сборки и делится на ите-рации, каждая из которых реализуется с помощью определенного набора функций.
Разработчики в FDD делятся на «хозяев классов» и «главных про-граммистов». Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения: в XP нет пер-сонально ответственных за классы или методы.[2] Достоинством этой методологии стоит считать изначальную под-держку больших групп разработчиков, так как отдельные функции разра-батываются отдельными мини-командами во главе с ведущим разработчи-ком.
Разделение и координация происходят на этапах 3-4. [21]
2.8. Канбан
Канбан в ИТ основан на производственной системе Тайота. Канбан отличается от скрама в первую очередь ориентированием на задачи, а не на спринты. Т.е. релиз выполняется тогда, когда задача готова, а не закон-чен спринт. Менеджер создает пул задач и расставляет приоритеты, а ко-манда выполняет как можно большее количество задач из данного пула.
Для организации работы команда использует канбан-доску, ее схема представлена на рис. 7.
Рисунок 7 — Доска задач Канбан [17]
Столбцы:
План — задачи, готовые для работы
Аналитика — задачи, для выполнения которых еще нет всего необ-ходимого и требуется отбуждение или обратная связь с другими членами команды
Разработка — задачи собственно в работе
Тестирование — задача тестируется
Готово — задача готова к релизу
Для того чтобы использовать канбан, достаточно следовать всего трём правилам. Таким образом, канбан является самой «не директивной методологией». Это может быть как плюсом, так и минусом, поэтому внедрять и использовать канбан хорошо после Scrum, а еще лучше не от-казываться от полезных практик этого гибкого фреймворка. Таким обра-зом, канбан — это высоко адаптивный инструмент, который требует от ко-манды, решившей использовать его, соответствующего уровня самоорга-низации и дисциплины.
Требуется следовать следующим правилам:
Визуализация разработки. Для этого обычно используют вышеопи-санную доску, размеченную по этапам работы над задачей.
У каждого столбца-состояния команда указывает максимальное количе-ство задач, которые могут в нем находиться. Таким образом, минимизиру-ется переключение между задачами и связанные с этим потери при произ-водстве.
Применение отметок о положении задачи в разработке;
Ограничение количество работ, которые выполняются одновремен-но, и оптимизация процесса в целом. Необходимо отслеживать среднее время задачи и уменьшать его. [10] Преимущества метода Kanban:
Оперативное нахождение проблемных задач;
Вычисление количества времени, требуемого на выполнение средне-статистической задачи;
Время выполнения каждой отдельной задачи уменьшается, так как уменьшается число параллельно выполняемых задач. [4]
Заключение
Зачастую критике agile-подхода подвергается частое пренебрежение создания плана развития продукта. Гибкий подход не подразумевает дале-ко идущих планов, а подразумевает изменчивые требования заказчика, ко-торые могут изменяться от итерации к итерации. Эти изменения не редко противоречат архитектуре уже созданного продукта. Такое периодически приводит к массовым рефакторингам практически на каждой очередной итерации.
Также, считается, что работа в agile мотивирует разработчиков ре-шать все поступившие задачи самым быстрым и простым, из возможных, способом, при этом не обращая внимания на правильность кода с точки зрения архитектуры. Это ведет к снижению качества и накоплению дефек-тов.[16] В гибких методологиях смещены все основные акценты, по сравне-нию с монументальными методологиями. Гибкие меньше ориентированы на документацию, что выражается в меньшем ее объеме. Основная предпо-сылка в том, исходный код — это и есть документация, он должен быть самодокументированным, рассказывать разработчикам все что им следует знать.
Гибкие методологии ориентированы на человека, а не на процесс. В них ясно заявлено о необходимости учитывать в работе природные каче-ства человека.
При разработке ПО основной объем работ приходится на проекти-рование, который является творческим процессом. Любой творческий процесс труднопредсказуем, поэтому прогнозируемость в данном случае может стать недостижимой целью. Кроме того, бывает нельзя составить полную картину требований к ПО, поскольку предметная область меняется очень быстро.
Оценить же длительность процесса разработки ПО тяжело по не-скольким причинам. Во-первых, создание ПО представляет собой работу, которую трудно планировать и оценивать. Во-вторых, исходные материа-лы быстро меняются. В-третьих, немалое зависит от конкретных людей на местах, а людей всегда сложно прогнозировать.
Гибкие процессы адаптируются к условиям разработки приложения, характеру задачи, квалификации пользователей, используемым техноло-гиям.
Тем не менее, они не для всех. Одно из самых серьезных ограниче-ний этих методологий – применение их в больших командах разработчи-ков. Гибкие подходы хорошо использовать в том случае, если неясны тре-бования к системе или они часто изменяются, разработчики достаточно от-ветственны и имеют высокую квалификацию, заказчик согласен принимать активное участие в разработке.
Предсказуемый процесс имеет смысл использовать в том случае, если команда разработчиков насчитывает более 50 человек и заключен кон-тракт с фиксированным объёмом работ.
Принципы Agile полностью меняют представление о разработке про-граммного обеспечения. С ориентированности на последовательность за-ранее продуманных менеджерами шагов фокус смещается на проектную команду как на самоорганизующуюся группу людей, способных решать все проблемы самостоятельно. Это изменение требует от членов команд совершить переворот в собственном сознании, отказаться от администра-тивных командных методов управления и попытаться сформировать абсо-лютно новые для них методы решения проблем.
Некоторые принципы и связанные с ними практики просты и обычно не вызывают трудностей при внедрении — в первую очередь это, конечно, итеративная и инкрементальная разработка. Сокращение продолжитель-ности итерации до месяца и меньше принимается руководством с удоволь-ствием, да и разработчики не видят в этом ничего непонятного или стран-ного.
Куда сложнее обстоит дело с принципами самоорганизации команды и адаптирующегося процесса. Agile-методологии особенно эффективны, если команда самоуправляема и самоорганизуема. Добиться этого на практике непросто, поскольку это фактически означает смену парадигмы мышления: с привычки подчинения на привычку сотрудничества. Все Agile-методологии подчеркивают, что оценивать производительность и успешность внедрения можно только для команды в целом.
В данной работе была рассмотрена вся необходимая для составления представления об Agile информация. В первом разделе была представлена общая информация о гибких методологиях, о основных правилах, мани-фесте, о принципах.
Далее в работе были приведены конкретные методики, которые ба-зируются на правилах Agile, содержащие уже более подробные принципы, указания по работе, набор практик. Для каждой методики была описана вся необходимая для работы по ней информация, плюсы и минусы.
Список литературы
1. Лилия Хаф: Методологии разработки программного обеспече-ния, ч. 2, 2016. – 158-160 с.
2. Алексей Закис: RUP и другие методологии разработки ПО, ч.2, 2012. –145 с.
3. Олег Власов: Гибкое управление проектами и продуктами, М.: «Питер», 2016. – 141 с.
4. Избачков Ю.С., Петров В.Н., Васильев А.А., Телина И.С.: Ин-формационные системы. – СПб.: Питер, 2011. – 655 с.
5. Microsoft Corporation. Microsoft Solutions Framework: Гибкая методология разработки программного обеспечения. Справочное руко-водство. – М. : Русская редакция, 2010. –127 с.
6. Д.В. Карпов: Гибкая методология разработки программного обеспечения», Нижегородский госуниверситет им. Н.И. Лобачевского, 2011. – 227-230 с.
7. Майк Кон Scrum: гибкая разработка ПО — М.: «Вильямс», 2011. —576 с. — ISBN 978-5-8459-1731-7
8. Xенрик Книберг: Scrum и XP заметки с передовой, Киев: InfoQ, 2011. —62 с.
9. Кент Бек: экстремальное программирование, Питер, 2017. —212 с. — ISBN: 978-5-496-02570-6
10. Роберт Шварц: Канбан и точно вовремя на Toyota: Менедж-мент начинается на рабочем месте, 2017. —108 – 117 с.
11. Джонатан Расмуссон: Гибкое управление IT-проектами. Руко-водство для настоящих самураев, Санкт-Петербург; 2012. —165 с. — ISBN 978-5-459-01205-7
12. Коберн, А. Быстрая разработка программного обеспечения / А. Коберн. – М. : Лори, 2016. –314 с.
13. Брауде Э. «Технологии разработки программного обеспече-ния» — СПб.: Питер, 2014. – 655 с.
14. К. Ауэр, Р. Миллер: Экстремальное программирование — СПб.: Питер, 2014. – 368 с.
15. Астелс Д., Миллер Г., Новак М.: Практическое руководство по экстремальному программированию – Вильямс: 2012. – 320 с.
16. Грин Дженнифер, Стеллман Эндрю: Постигая Agile – O’Reilly, 2017. – 650 с.
17. Вольфсон Борис: Электронное открытое издание: Гибкие мето-дологии разработки Версия 1.2, 2012. —10 — 19 с.
18. Солонин E.Б.: Учебное электронное текстовое издание «Со-временные методики разработки информационных систем – Екатеринбург : УрФУ, 2015. – 213 с.
19. Электронные ресурсы http://ru.wikipedia.org/wiki/ Бережли-вая_разработка_программного_обеспечения
20. Электронные ресурсы http://infolific.com/technology/methodologies/crystal-methods/
21. Электронные ресурсы http://ru.wikipedia.org/wiki/Feature_driven_development