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

• Название: Кафедра ивс курсовой проект дисциплина Управление программными проектами Тема Agile в it приняла Головачёва В. Н.. (оценка) (фамилия, инициалы)
• Анкор: Курсовая работа по IT-проектам
• Дата: 16.04.2023
• Размер: 1.11 Mb.
• Имя файла: Айтпеков В..docx
• Тип: Курсовой проект; #1065481

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

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

Кафедра: ИВС

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

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

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

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

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

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

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

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

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

Караганды 2020

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

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

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

(подпись)

"___" ________ 20___г.

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


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

__________________________________________________________________

__________________________________________________________________

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

Содержание

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

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

Факультет ФИТ "УТВЕРЖДАЮ" 2

Кафедра ИВС Зав. Кафедрой _______ 2

(подпись) 2

"___" ________ 20___г. 2

ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ 2

по дисциплине " Управление программными проектами " 2

2

Студенту Айтпеков В.В. группы ВТ-18-3 2

Тема «Agile в IT.» 2

Исходные данные:________Метод. указания к курсовому проекту ____________________________________________________________ 2

Задание выдано "_____" __________________________________ 20__ г. 2

Руководитель Головачёва В. Н. подпись 2

Студент Айтпеков В. В. подпись 2

1.Введение 4

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

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

2.2. Agile-подход к планированию 9

2.3. Многоуровневость планирования 10

2.4. Состояние удовлетворенности 12

2.5. Оценка размера 14

2.7. Методы оценки 15

2.8. Покер планирования 16

3.Практическая часть 20

3.1. Внедрение Agile в работу компании 20

3.2. Изменения в работе компании 21

3.3. 3 принципа найма новых людей в команду 23

3.4. Внедрение кросс-дисциплины t-shape 24

3.5. Обучение Product Owner 25

3.6. Внедрение пользовательского взгляда 26

3.7. Использование микросервисов 27

3.8. Итоги внедрения Agile 28

4.Заключение 29

Список литературы 30

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 будут разрастаться широко за пределы разработки программного обеспечения, и затронут работу практически каждой компании во многих отраслях.

2.2. Agile-подход к планированию

И без того трудная задача оценки и планирования разработки нового продукта дополнительно осложняется нашими ошибочными представлениями о проектах. Макомбер (Macomber, 2004) подчеркивает, что ни в коем случае нельзя рассматривать проект исключительно как выполнение ряда последовательных этапов.

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

В agile-проекте этот поток новых возможностей и знаний служит основой для управления текущей работой. Новые знания, генерируемые в процессе выполнения проекта, могут относиться к продукту или к проекту. Новые знания о продукте помогают нам получать больше информации о том, каким должен быть продукт. Новые знания о проекте — это информация о команде, используемых технологиях, рисках и т.п. Мы зачастую не учитываем эти новые знания и не планируем возможность их получения. Как результат, процесс планирования строится на допущении о том, что нам уже известно все необходимое для получения точного плана. В мире разработки программного обеспечения такое случается редко, если вообще случается. Уорд Каннигем заметил, что «это больше планирование того, что вы хотите узнать, а не того, что [продукт] получится в конце» (Van Schooenderwoert, 2004). Я часто сравниваю традиционный взгляд на проект с 10-километровым забегом. Вы точно знаете, как далеко находится финишная черта, и ваша цель заключается в том, чтобы ее достичь максимально быстро. В agile-проекте мы не знаем точно, далеко ли финиш, но нередко известно, что достичь его нужно как можно ближе к известной дате. Agile-проект больше похож на гонку по времени, а не на забег на 10 км: вам нужно пробежать как можно больше за 60 минут. Иначе говоря, команда agile-проекта знает, когда финиширует, но не знает, какой результат покажет. Когда мы признаем, что результат — это нечто неизвестное и не поддающееся выяснению заранее, планирование становится процессом определения и пересмотра задач, который ведет к достижению долгосрочной цели.

2.3. Многоуровневость планирования

При постановке задач и их пересмотре важно помнить, что мы не можем видеть дальше горизонта и что точность плана быстро снижается по мере того, как мы все дальше уходим за черту, до которой видим. Допустим, вы стоите на палубе небольшого судна и ваши глаза находятся на высоте 2,7 м над уровнем воды. Расстояние до горизонта в этом случае составляет примерно 6 км. Если вы планируете 30-километровое путешествие, то вам необходимо составить план на перспективу как минимум в пять раз дальше горизонта, который составляет 6 км. Поскольку вы не можете видеть дальше горизонта, нужно периодически осматриваться и корректировать свой план. Проект оказывается в зоне риска, если планирование выходит за пределы горизонта составителя плана и не предусматривает возможности осмотреться, определить новый горизонт и внести изменения. Необходима последовательная разработка плана. Agile-команды достигают этого, осуществляя планирование для трех четко определенных горизонтов — релиз, итерация и текущий день. Взаимосвязь между этими (и другими) горизонтами планирования показана в виде так называемой луковицы планирования на рис.1.



Рисунок 1 – луковица планирования

Большинство agile-команд интересуют только три наиболее низких уровня луковицы планирования. При планировании релиза учитываются пользовательские истории или темы, которые создаются для нового релиза продукта или системы. Цель планирования релиза — это поиск приемлемых ответов на вопросы об объеме, календарном графике и ресурсах для проекта. Планирование релиза осуществляется в начале проекта, однако это не разовое действие.

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

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

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

2.4. Состояние удовлетворенности

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

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

Случается, однако, что все условия удовлетворенности владельца продукта выполнить невозможно. Команда может создать лучший в мире текстовый процессор, но у нее нет возможностей сделать это к следующему месяцу. Если приемлемое решение найти не удается, условия удовлетворенности необходимо менять. По этой причине планирование релиза и выяснение условий удовлетворенности владельца продукта являются итеративными процессами, как показано на рис. 2

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

Как и планирование релиза, планирование итерации является итеративным процессом. Владелец продукта и команда обсуждают различные пути достижения условий удовлетворенности для итерации.



Рисунок 2 – условия удовлетворённости определяют ход планирования и итерации

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

2.5. Оценка размера

Agile-команды разделяют оценку размера и оценку срока. Для демонстрации разницы приведу такой пример: представьте, что мне нужно переместить большую кучу земли из одного угла двора в другой. Я могу посмотреть на эту кучу, прикинуть возможности 36 своих инструментов (лопаты и тачки) и прямо сказать, что работа займет пять часов. При такой оценке я не делаю расчетов размера, а сразу перехожу к определению срока.

Допустим теперь, что я пошел другим путем: посмотрел на кучу и оценил ее величину. На основе ее размеров я прихожу к выводу, что объем земли составляет примерно 8,5 м³ . Это моя оценка размера данного проекта. Однако оценка одного лишь размера бесполезна в этой ситуации. Нам нужно узнать, сколько времени займет перемещение земли. Поэтому необходимо преобразовать оценку размера (8,5 м³ ) в срок.

Из ярлыка на моей тачке следует, что ее вместимость составляет 0,17 м³ . Разделив 8,5 м³ на 0,17 м³ , я определяю, что для перемещения земли мне потребуется 50 ездок. По моим прикидкам, для погрузки земли на тачку уйдет 3 минуты, для перемещения тачки на другой конец двора и выгрузки земли — 2 минуты, а на возврат с пустой тачкой к куче — 1 минута. Всего одна ездка займет 6 минут. Поскольку мне нужно сделать 50 ездок, расчетный срок работы составит 300 минут, или 5 часов.



Рисунок 3 – оценка срока выполнения проекта

2.7. Методы оценки

«Давать предсказания очень трудно, особенно когда они касаются будущего». Нильс Бор, датский физик.

Чем больше сил и средств мы вкладываем во что-то, тем лучше результат. Верно? Возможно, но нередко для получения приемлемых результатов требуется лишь часть этих затрат.

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



Рисунок 4 – затраченные усилия

2.8. Покер планирования

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

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

Перед началом процесса каждому оценщику дают колоду карт. На каждой карте написана одна из возможных оценок. Оценщик может получить, например, колоду карт, на которых написано 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Карты необходимо подготовить до начала игры в покер планирования, а цифры, написанные на них, должны быть достаточно крупными, чтобы разглядеть их с другого конца стола. Карты можно сохранить и использовать в следующей сессии покера планирования.

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

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

Чаще всего в этот момент оценки различаются очень сильно. На деле это совсем неплохо. Когда оценки различаются, оценщики с максимальным и минимальным результатами объясняют причину своего выбора. Очень важно, чтобы здесь на оценщиков не обрушилась критика. Нам нужно лишь выяснить, что заставило их прийти к такому мнению. Например, оценщик с максимальным результатом может сказать: «Ну, чтобы протестировать эту историю, нам нужно создать мок-объект. На это может уйти целый день. Кроме того, я не уверен, что стандартный алгоритм сжатия будет эффективен, а раз так, то нам, возможно, придется писать новый». Оценщик с минимальным результатом может сказать: «Я полагал, что мы будем хранить эту информацию в XML-файле — это было бы легче, чем создавать базу данных. К тому же я не подумал об увеличении объема данных — это может стать проблемой».

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

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

Правильная продолжительность дискуссии

Предварительное обсуждение дизайна всегда полезно для оценки. Вместе с тем чересчур длительное обсуждение приводит к слишком сильному смещению команды вправо по кривой «усилия/точность» (рис. 6.1). Существует простой способ поддержать дискуссию, но не дать ей затянуться.

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

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

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

Для этого команду разбивают на две или три группы, в каждой из которых должно быть не менее трех оценщиков. Очень важно, чтобы оценки всех групп были согласованными. То, что ваша группа оценивает в три пункта или идеальных дня, должно соответствовать тому, что моя группа оценивает так же. Чтобы добиться этого, все группы должны совместно попрактиковаться в покере планирования на протяжении часа или немного дольше. Пусть они оценят порядка 10–20 историй. Позаботьтесь о том, чтобы у каждой группы был экземпляр этих историй с оценками и чтобы группы использовали их в качестве базы для оценки других историй.
Почему покер планирования работает

Во-первых, покер планирования сводит вместе мнения нескольких экспертов и позволяет получить общую оценку. Поскольку эти эксперты образуют кроссфункциональную команду, представляющую все дисциплины софтверного проекта, они более компетентны в сфере оценки, чем кто-либо другой. На основе тщательного анализа литературы по оценке программного обеспечения Йоргенсен (Jørgensen, 2004) пришел к выводу, что «оценивать задачи должны те, кто наиболее компетентен в их выполнении».

Во-вторых, в процессе игры в покер планирования возникает живой диалог, и оценщики обращаются к мнению коллег для подтверждения своих оценок. Это повышает точность оценки, особенно когда дело касается объектов со значительным уровнем 54 неопределенности (Hagafors and Brehmer, 1983). Обращение за подтверждением оценок в определенной мере компенсирует недостаток информации (Brenner at al., 1996). Это очень важно в agile-проекте, поскольку оцениваемые пользовательские истории нередко намеренно составляются нечетко.

В-третьих, исследования показывают, что усреднение индивидуальных оценок дает лучшие результаты (Hoest and Wohlin, 1998), как и коллективное обсуждение оценок (Jørgensen and Moløkken, 2002). Коллективное обсуждение является основой покера планирования, а такие обсуждения ведут к усреднению различных индивидуальных оценок.

Наконец, покер планирования работает, потому что это занятие доставляет удовольствие.

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

3.1. Внедрение Agile в работу компании

Так как я являюсь сотрудником одной из IT компаний в нашем городе. Могу на собственном примере донести процесс изменения механизмов работы компании с внедрением Agile в наши проекты, а также на уровне всей компании.
Проблемы, которые предстояло решить:

• 
  Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервисов.
  

• 
  «Сакральные» знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.
  

• 
  Низкая скорость разработки и низкое качество продуктов.
  

• 
  Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.
  

• 
  Текучка среди разработчиков. Молодые специалисты зачастую уходили, не проработав в компании даже года. Это проблема всего рынка.
  

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

3.2. Изменения в работе компании

В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо — Product Owner.

«Расстались с руководителями»

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.
Важно!

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

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

Дальше команда делает маленькие шаги. К примеру, принимает решение сделать backend — разобраться, как эти данные будут храниться и показываться, как будет выглядеть меню. То есть разрабатывается простой, примитивный продукт, с которым тем не менее уже могут взаимодействовать пользователи. После этого приступают к следующему шагу разработки.


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

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

То есть если разработчики говорят, что надо работать над фичей, они должны объяснить, как эта фича принесет компании деньги.



В Agile нет места хаосу, каждое нововведение должно быть четко обосновано

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

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

3.3. 3 принципа найма новых людей в команду

Мотивация

Человек должен объяснить, почему хочет работать в компании. Если у него нет никакой цели в жизни, никакого плана — это плохой знак, его надо будет «качать».

Насколько вписывается в ценности компании

Среди ценностей Ticketland есть получение удовольствия от работы. Если новичок мрачный (очень многие IT-специалисты мрачные, брутальные, суровые), не реагирует на шутки, не может адаптироваться к изменению ситуации, то, наверное, ему и всей команде будет трудно, даже если он отличный специалист.

Достаточно ли у него знаний, навыков

Для разработчиков есть специальные тесты и отдельные люди, которые задают нужные вопросы.

3.4. Внедрение кросс-дисциплины t-shape

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



Схематическое отображение t-shape

К примеру, если человек занимается продажами, он может прокачать другой навык — создание наглядных презентаций. Также можно начать писать блог для клиентов или совершать выездные консалтинг-сессии. Чем больше смежных навыков освоит сотрудник, тем лучше он сможет показать себя в качестве специалиста в основной деятельности.

3.5. Обучение Product Owner

Это человек, который умеет находить общий язык с людьми, работать в команде, понимает технологии и знает, как с ними взаимодействовать. Product Owner — связующее звено между бизнесом, разработчиками и пользователями. Таких специалистов на рынке труда сейчас мало, поэтому многие компании выращивают их самостоятельно.



Положение Product Owner в бизнес-процесса и в команде
Ключевые навыки Product Owner:

• 
  обладает видением продукта;
  

• 
  является владельцем бэклога продукта;
  

• 
  умеет расставлять приоритеты;
  

• 
  управляет ожиданиями заинтересованных лиц;
  

• 
  представляет пользователя;
  

• 
  взаимодействует с командой;
  

• 
  принимает продукт.
  

3.6. Внедрение пользовательского взгляда

То есть каждое обновление рассматривается не только со стороны бизнеса, но и со стороны пользователя.



Схематическое отображение пользовательской истории

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

3.7. Использование микросервисов

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



Разница между монолитной архитектурой проекта и использованием микросервисов
Раньше в компании все работало монолитно. Любая хранимая процедура могла поменяться, и дальше становилось невозможно разобраться в процессах. Когда начали работать в микросервисах, данные перестали путаться и теряться, новым специалистам было легче в них разобраться.
Так, в компании полностью виртуализировали структуру, своих тяжелых серверов практически не осталось. Это и дешевле, и удобнее: если нужна дополнительная мощность, она появляется сразу. Все должно быть учтено при создании архитектуры. Это и есть микросервис. Рассмотрим основные преимущества и недостатки их использования:
ПРЕИМУЩЕСТВА

• 
  Независимое обновление
  
• 
  Масштабирование
  
• 
  Возможность экспериментов
  
• 
  Простота
  
• 
  Поддержка любым разработчиком
  

НЕДОСТАТКИ

• 
  Сложно выкатывать
  
• 
  Сложно тестировать
  
• 
  Распределительная система
  
• 
  Сложно эксплуатировать
  
• 
  Несогласованная БД 
  

3.8. Итоги внедрения Agile

После того, как в проектах и в целом в компании была введена методология Agile, процессы изменения работы были увидены сразу. Связь между разработчиками и проект менеджерами была в несколько раз увеличена вследствие необходимости увеличения кругозора всех сотрудников в компании. Сроки на выполнение определённой задачи увеличились на 15-20% из-за особенностей гибкости и большей свободы разработчиков.


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

2. Заключение

Важность инвестирования в культуру и изменения на пути к Agile невозможно переоценить. Agile – это, прежде всего, мышление.

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

Цель agile-планирования заключается в итеративном поиске оптимального ответа на общий вопрос разработки продукта — какие функции какими ресурсами и за какое время можно реализовать. Agile-подход к оценке и планированию позволяет успешно дать ответ на этот вопрос по следующим причинам: планы составляются на разных уровнях и часто пересматриваются, они строятся на основе функций, а не задач; сначала оценивается размер, а потом на основе оценки размера определяется срок; используются небольшие истории, обеспечивающие постоянный поток работы, а незавершенная работа ликвидируется в конце каждой итерации; прогресс измеряется на уровне команды, а не индивидуального исполнителя; неопределенность признается и учитывается при планировании.

Список литературы

Майк Кон, Agile: оценка и планирование проектов, 2018
Agile Project Management for Dummies, Mark C. Layton 2015
Abdel-Hamid, Tarek K. 2010. Adapting, Correcting, and Perfecting Software Estimates: A Maintenance Metaphor. IEEE Computer 26 (3): 20–29.
Ambler, Scott W. 2014. Less Is More. Software Development, November.
Anderson, David. 2014. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall.
СПРАВКА

На кафедре ИВС КарГТУ проведён сравнительно-сопоставительный анализ контрольных работ КП по дисциплине Управление программными проектами ст. группы ВТ-18-3 Айтпеков В.В. с фондом контрольных работ по КП. В результате анализа совпадений с фондом контрольных работ КП не обнаружено.
Оригинальность работы составляет: 83,52%

Вр.и.о. зав.кафедрой ИВС Калинин А.А.



Пояснительная записка
В этом курсовом проекте была изложена такая тема, как «Agile в IT».

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

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