3.2 Преимущество Модели быстрого прототипирования

(17 слайд).

• 
  Взаимодействие заказчика с системой начинается на раннем этапе разработки;
  
• 
  Демонстрации разрабатываемого продукта сводит к минимуму количество неточностей в требованиях;
  
• 
  В процесс разработки можно внести новые или неожиданные требования пользователя;
  
• 
  Модель представляет собой формальную спецификацию, воплощенную в рабочую модель.
  
• 
  Модель позволяет выполнять гибкое проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла;
  
• 
  При использовании модели образуются постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему заказчики чувствуют себя уверенно; (18 слайд)
  
• 
  Ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки;
  
• 
  Возможность наблюдать ту или иную функцию в действии пробуждает очевидную необходимость в разработке функциональных дополнительных возможностей;
  
• 
  Благодаря меньшему объему доработок уменьшаются затраты на разработку;
  
• 
  Обеспечивается управление рисками;
  
• 
  Документация сконцентрирована на конечном продукте, а не на его разработке;
  

3.3 Недостатки модели быстрого прототипирования

(19 слайд)

• 
  Модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о "разработанном на скорую руку" методе;
  
• 
  С учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания.
  
• 
  Иногда в результате использования модели получают систему с низкой рабочей характеристикой, особенно если в процессе ее выполнения пропускается этап подгонки;
  
• 
   При использовании модели решение трудных проблем может отодвигаться на будущее.
  
• 
  На итерационном этапе прототипирования быстрый прототип представляет собой частичную систему. Если выполнение проекта завершается досрочно, у конечного пользователя останется только лишь частичная система;
  
• 
  Несовпадение представлений заказчика и разработчиков об использовании прототипа может привести к созданию другого пользовательского интерфейса;
  
• 
  Заказчик может предпочесть получить прототип, вместо того, чтобы ждать появления полной, хорошо продуманной версии; (20 слайд)
  
• 
  Если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана;
  
• 
  Прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл "кодирование — устранение ошибок" (code-and-fix cycle)
  
• 
  Разработчики и пользователи не всегда понимают, что когда прототип превращается в конечный продукт, все еще существует необходимость в традиционной документации, когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки, перед менеджером программного проекта возникает соблазн пойти им навстречу.;
  
• 
  На заказчиков может оказать негативное влияние тот факт, что они не располагают информацией о точном количестве итераций, которые будут необходимы;
  
• 
   На разработку системы может быть потрачено слишком много времени, так как итерационный процесс демонстрации прототипа и его пересмотр могут продолжаться бесконечно без надлежащего управления процессом;
  
• 
  Структурные методы не используются, чтобы не помещать выполнению анализа.
  

---

3.4 Область применения

(21 слайд)

1. 
   Требования к программному продукту заранее неизвестны;
   
2. 
   Требования не постоянны или неудачно сформулированы;
   
3. 
   Требования необходимо уточнить;
   
4. 
   Нужна проверка концепции;
   
5. 
   Существует потребность в пользовательском интерфейсе;
   
6. 
   Выполняется новая, не имеющая аналогов разработка;
   
7. 
   Разработчики не уверены в том, какое решение следует выбрать.
   

4. Agile методологии

(22 слайд)

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

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

Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

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

И даже гибкий фреймворк Scrum, который по определению «не является процессом, техникой или методом», все же предписывает применять несколько ролей, мероприятий и артефактов. Каждый элемент Скрама является обязательным для его успешного использования.

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

4.1 Ценности Agile

(23 слайд)

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. 
   люди,
   
2. 
   работающий продукт,
   
3. 
   сотрудничество с заказчиком,
   
4. 
   готовность к изменениям.
   

---

4.2 Люди и их взаимодействие важнее процессов и инструментов

(24 слайд)

Чтобы люди работали эффективнее, процессы и инструменты не должны их ограничивать. В Agile ни процесс, ни тем более программный инструмент не диктует, что людям делать. Более того, они сами решают, как менять процессы/инструменты своей работы.

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

4.3 Работающий продукт важнее исчерпывающей документации

(25 слайд)

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

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

4.4 Сотрудничество с заказчиком важнее согласований условий контракта

(26 слайд)

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

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

4.5 Готовность к изменениям важнее, чем следование плану

(27 слайд)

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

---

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

Что касается готовности к изменениям со стороны представителей заказчика (клиента), то в такой ситуации они могут пожертвовать чем-то запланированным (но менее ценным) ради новых возможностей. Готовность заказчика оперативно жертвовать какой-то частью запланированного также нужна в ситуации, когда исполнители столкнулись с непредвиденными проблемами в ходе разработки.
4.6 Agile сложнее, чем 4 ценности

(28 слайд)

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

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

---

4.7 Кратко о том, что входит в Agile сегодня

(29 слайд)

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

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

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

Помимо того, обязательно присутствуют владелец продукта (фокусируется на ценности продукта, решает, что делать в первую очередь) и scrum-мастер (фокусируется на эффективности работы команды, помогает команде улучшать рабочие процессы и решать внешние проблемы). Никто из них не диктует разработчикам, как именно работать. Scrum образуют самоорганизующуюся команду.

Работа по Scrum строится на «спринтах» — это периоды продолжительностью от 7 до 30 дней, всё зависит от состава команды и проекта. На каждый спринт формируют свою цель, по которой и подводят результаты. Следующий спринт начинается после завершения предыдущего независимо от его результатов — если, конечно, спонсор не принимает решение о завершении работы над продуктом.

В Scrum-командах есть следующие роли:

(30 слайд)

1. 
   Владелец продукта. Несёт ответственность за максимизацию ценности продукта. Этот человек точно знает, что необходимо реализовать в первую очередь.
   
2. 
   Scrum-мастер. Его задача — организовать в команде работу в соответствии с руководством по Scrum и чтобы никто не мешал команде самостоятельно и комфортно решать поставленные задачи.
   
3. 
   Developers. Группа людей, обладающих всеми знаниями и навыками, необходимыми для достижения цели. Они определяют, как именно достигать цели, отвечают за качество продукта и ежедневную адаптацию плана внутри спринта.
   

Владелец продукта, Scrum-мастер и Developers составляют одну общую команду. В руководстве по Scrum 2020 года не выделяется отдельно команда разработки. Команда состоит из 5–9 человек — если людей будет больше, это усложнит взаимодействие между звеньями, а это негативно скажется на эффективности работы.

---

Смотрите также файлы

• Сабаты таырыбы лагер поэмасындаы Аан бейнесі.docx

• Практическая работа 2.docx

• Ю. Власов вспоминает в 1959 году на Варшавском чемпионате по тяжелой атлетике в борьбе за золотую медаль я столкнулся с американцем Джимом Бредфордом и едва не проиграл. Он буквально подавил меня в первом ж.docx

• Основными признаками понятия "измерение" не являются Необходимость проведения эксперимента.docx

• Ответ 1 Правоотношения между работником и работодателем относятся к трудовым отношения. Определение есть в ст.docx