Файл: Кафедра ивс курсовой проект дисциплина Управление программными проектами Тема Agile в it приняла Головачёва В. Н.. (оценка) (фамилия, инициалы).docx

Министерство образования и науки Республики Казахстан

Карагандинский государственный технический университет

Кафедра: ИВС

КУРСОВОЙ ПРОЕКТ

Дисциплина: Управление программными проектами

Тема: Agile в IT
Приняла:

______________ Головачёва В. Н..

(оценка) (фамилия, инициалы)
____________________________

(подпись) (дата)
Выполнил:

Айтпеков В.В..

(фамилия, инициалы)
18/6-160  .

(шифр зач. книжки)

Караганды 2020

Министерство образования и науки Республики Казахстан

Карагандинский Государственный Технический Университет

Факультет ФИТ "УТВЕРЖДАЮ"
Кафедра ИВС Зав. Кафедрой _______

(подпись)

"___" ________ 20___г.

ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ
по дисциплине " Управление программными проектами "


Студенту Айтпеков В.В. группы ВТ-18-3
Тема «Agile в IT.»
Исходные данные:________Метод. указания к курсовому проекту
____________________________________________________________

__________________________________________________________________

__________________________________________________________________

Задание выдано "_____" __________________________________ 20__ г.
Руководитель Головачёва В. Н. подпись
Студент Айтпеков В. В. подпись

Содержание

---

1. Введение

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.» - закон Хофштадтера.

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии, где новые детали по очереди добавляются в последовательные фазы.
Вместо того чтобы ждать, пока будут поочередно завершены все этапы (фазы), Ройс предложил применять фазовый подход. Суть его в том, что изначально собираются все требования, необходимые для проекта, после чего завершается вся архитектура, создается дизайн, записывается код и т.д.

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы.
Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

2. 
   Теоретическая часть
   

1. 
   История возникновения Agile
   

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

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

---

Некоторые корни гибкого подхода тянутся вглубь веков, к сформулированному в 1620 году Френсисом Бэконом (Francis Bacon) научному методу. Однако логичнее считать стартовой точкой развития Agile 30-е годы ХХ века, когда физик и статистик Уолтер Шухарт (Walter Shewhart) из Лаборатории Белла (Bell Labs) начал применять циклы Планируй-Делай-Изучай-Действуй (Plan-Do-Study-Act) для улучшения продуктов и процессов. Шухарт передал основы такой итеративно-инкрементальной разработки своему ученик, Уильяму Эдвардсу Демингу (W. Edwards Deming), который популяризировал этот метод во время восстановления Японии после второй мировой войны. (Сейчас метод носит его имя – прим. пер.) Компания Toyota наняла Деминга чтобы обучить сотни менеджеров компании, что привело к созданию знаменитой Производственной системы «Toyota» (Toyota Production System) – первоисточник современного «бережливого» производства. Итеративный и инкрементальный подход активно использовались также в разработке сверхзвукового самолёта Х-15 в 1950-е.

В 1986, Хиротака Такеучи, один из авторов этой статьи, совместно со своим партнёром Икуджиро Нонакой (Ikujiro Nonaka) опубликовали в журнале «Harvard Business Review» статью под названием “The New New Product Development Game”. Изучая компании, лидировавшие на рынке инноваций и опережавших своих конкурентов, авторы выявили командно-ориентированный подход, полностью менявший классический процесс разработки продукта. Он применялся при создании знаменитых “Xerox”, автомобильных двигателей “Honda” и фотокамер “Canon”. В этом подходе, вместо классической «эстафеты» по передаче продукта по этапам от одного функционального специалиста к другому, применялся подход, похожий на игру в «регби», когда команда продвигается по дистанции как единое целое, постоянно передавая мяч друг другу.

В 1993 году ещё один автор данной статьи, Джефф Сазерленд, столкнулся с невыполнимой задачей: Компания «Easel Corporation», занимавшаяся разработкой софта, должны были менее чем за шесть месяцев успеть разработать замену своему самому основному продукту. У Джеффа уже был опыт работы с нестандартными методологиями, такими как быстрая разработка приложений, объектно-ориентированная разработка и Цикл PDSA, а также работы с автономными креативными исследовательскими группами (“skunkworks”). Его идеей было создать креативную группу типа skunkworks (см. Справку), но прямо в штаб-квартире организации, сочетая плюсы автономности и интеграции. И он начал с того, что прочитал всё, что смог найти о повышении производительности организации. Он прочёл сотни статей, поговорил с десятками ведущих менеджеров продуктов. В ходе этого исследования его заинтересовали несколько оригинальных идей.

---

Справка: Skunkworks (дословно: «скунсодельня», «вонючая фабрика») — автономная исследовательская группа, которая создается внутри организации для решения какой-либо сложной творческой задачи и функционирует практически без формального контроля сверху. Выражение было использовано американской авиастроительной компанией Lockheed Martin Corporation, чья исследовательская лаборатория находилась рядом с заводом пластмассы, который издавал ужасный запах; эта лаборатория Lockheed характеризовалась высокой степенью автономии, самостоятельным бюджетом, секретностью от всей остальной организации и смогла произвести весьма радикальные инновации в области конструкции самолетов; сами сотрудники лаборатории называли себя Skunk Works и впоследствии это имя было закреплено за лабораторией формально.

Одна из оригинальных идей пришла из Лаборатории Белла, той самой, где родился Цикл Деминга (PDSA). В статье о работе команды Borland Quattro Pro рассказывалось о пользе коротких ежедневных встреч команды. Авторы утверждали, что это улучшает синхронизацию и повышает производительность команды. Но ключевая концепция Сазерлендом была взята из статьи Нонаки и Такеучи о «регбийном» подходе, несмотря на то, что он относился скорее к производству, нежели к сфере ИТ. Взяв множество идей из различных источников Сазерленд создал новый способ разработки софта, дав ему название «Scrum» в честь аналогии с регби. Метод Scrum позволил ему успешно завершить практически невозможный проект в срок, в рамках бюджета и с небывало низким количеством багов. Он объединился со своим коллегой Кеном Швабером (Ken Schwaber) для формализации подхода и в 1995 году Scrum был представлен всему миру.

Конечно, Швабер и Сазерледн были не одиноки в своих поисках инновационных методов работы. Век информации наступал стремительно. Подрывные технологии сметали «медленных» игроков с рынка. Стартапы и руководители компаний искали способы выжить в нестабильной турбулентной среде. Софт стал неотъемлемой частью практически каждого бизнеса, и многие талантливые разработчики трудились над тем, чтобы сделать методы разработки более гибкими.

В 2001 году, 17 разработчиков, которые называли себя «организационными анархистами» встретились в городе Сноубёрд (Snowbird, Utah) чтобы поделиться идеями повышения эффективности. Сазерленд и другие сторонники Scrum были среди них. Но в группу входили приверженцы нескольких конкурирующих подходов: экстремального программирования (ХР), crystal, adaptive software development (ASD), feature-driven development (FDD); и dynamic-systems-development method (DSDM). Все эти подходы были известны как «лёгкие» фреймворки, потому что они используют более простые правила и процессы для быстрой адаптации к изменяющейся среде. Но не всех участников устраивала существующая терминология и название «лёгкие фреймворки».

---

Несмотря на разногласия, участники в конце концов выбрали новое название для движения: Agile. Название подсказал один из участник, который тогда читал книгу Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer. В этой книге даётся 100 примеров компаний, включая АВВ, Federal Express, Boeing, Bose и Harley-Davidson, которые придумывали оригинальные способы бороться с неопределённостью и турбулентностью среды. После того, как имя было выбрано, участники съезда сформулировали знаменитый «Agile-манифест разработки программного обеспечения» (Manifesto for Agile Software Development), в котором были сформулированы ключевые ценности и принципы, которые разделили все участники. С 2001 года, все техники разработки, разделяющие эти ценности называются гибкими методологиями Agile.

После публикации Манифеста, Agile движение стало набирать популярность. Манифест был опубликован на сайте и любой желающий мог подписать его в знак поддержки принципов гибкой разработки. Спустя год члены оригинальной группы и присоединившиеся последователи собрались снова чтобы решить, как лучше распространять свои идеалы среди профессионального сообщества. Все согласились писать статьи и выступать с лекциями по Agile. Часть захотели создать рабочую группу. Сейчас эта группа превратилась в Альянс Agile, в котором сейчас состоит почти 30, 000 человек.

Между тем, гибкие методологии продолжали развиваться. В конце 1980х начале 1990х исследователи из Массачусетского Технологического Университета (MIT) стали изучать японские производственные системы, особенно систему Toyota. Они использовали термин «lean» («бережливый») для описания методов улучшения производительности системы за счёт избавления от различных потерь (muda), неравномерности выполнения работы (mura) и перегрузки сотрудников или оборудования (muri). Методики бережливого производства не рассматривались на собрании в Сноубёрде, и многие специалисты долгое время отказывались причислять их к Agile и рассматривать как гибкие методики. Но со временем сторонники lean сконцентрировались на более близком взаимодействии с клиентами и, в конце концов, Agile-специалисты пришли к принятию lean, kanban, и их гибридам (таким, как Scrumban или lean scrum) в качестве практического воплощения ценностей и принципов Agile.

У успеха много отцов, и у Agile богатая родословная. И хотя разнообразное «семейное древо» зачастую вызывает жаркие споры среди приверженцев гибких методологий, два факта совершенно очевидны. Во-первых, корни Agile уходят за пределы ИТ-сектора. Во-вторых, «ветви» Agile будут разрастаться широко за пределы разработки программного обеспечения, и затронут работу практически каждой компании во многих отраслях.

---