Презентация Методологии разработки ПО. (Лекция 18) онлайн
На нашем сайте вы можете скачать и просмотреть онлайн доклад-презентацию на тему Методологии разработки ПО. (Лекция 18) абсолютно бесплатно. Урок-презентация на эту тему содержит всего 72 слайда. Все материалы созданы в программе PowerPoint и имеют формат ppt или же pptx. Материалы и темы для презентаций взяты из открытых источников и загружены их авторами, за качество и достоверность информации в них администрация сайта не отвечает, все права принадлежат их создателям. Если вы нашли то, что искали, отблагодарите авторов - поделитесь ссылкой в социальных сетях, а наш сайт добавьте в закладки.
Презентации » Устройства и комплектующие » Методологии разработки ПО. (Лекция 18)
Оцените!
Оцените презентацию от 1 до 5 баллов!
- Тип файла:ppt / pptx (powerpoint)
- Всего слайдов:72 слайда
- Для класса:1,2,3,4,5,6,7,8,9,10,11
- Размер файла:4.89 MB
- Просмотров:77
- Скачиваний:1
- Автор:неизвестен
Слайды и текст к этой презентации:
№5 слайд
![Waterfall. Минусы. Все](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img4.jpg)
Содержание слайда: Waterfall. Минусы.
Все требования должны быть определены до начала разработки;
Дорого и медленно;
Чувствителен к изменениям;
Мало возможностей повлиять на цели проекта;
Зачастую проблемы выявляются на этапе тестирования;
Много документации (в том числе и технической), которая непонятна конечному пользователю и заказчику.
№8 слайд
![Agile. В основе гибкой](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img7.jpg)
Содержание слайда: Agile.
В основе гибкой методологии лежит итеративный процесс разработки. Работа над проектом проходит циклами (длительность 1-4 недели) и подразумевается что в конце каждого цикла выпускается новая готовая версия продукта. Дальше идет анализ полученных результатов и планируется работа над следующим циклом, и так далее
№10 слайд
![Agile vs Waterfall. В](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img9.jpg)
Содержание слайда: Agile vs Waterfall.
В каскадной модели есть ряд определенных этапов процесса разработки и разработчик последовательно переходит от одного этапа к другому. Каскадная модель разработки подразумевает, что переход к новому этапу разработки начинается только после полного завершения предыдущей
№12 слайд
![Agile. Начало. Активное](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img11.jpg)
Содержание слайда: Agile. Начало.
Активное вхождение Agile в массы началось после подписания Agile Manifesto 11-13 февраля 2001 года на лыжном курорте в штате Юта США. Этот манифест подписали представители таких методологий как Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM)
№29 слайд
![Agile Manifesto. Принципы.](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img28.jpg)
Содержание слайда: Agile Manifesto. Принципы.
Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки.
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
Работающий продукт — основной показатель прогресса.
Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
№30 слайд
![Agile. Преимущества. Частые](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img29.jpg)
Содержание слайда: Agile. Преимущества.
Частые релизы — требования не успевают устаревать, частью функционала уже можно пользоваться;
Фиксированная длина итераций — можно предсказывать скорость работы команды с учетом рисков;
Команда сама оценивает задачи — оценки реалистичны, команда мотивирована выполнить свои обязательства;
Команда самоуправляемая — 10 голов учтут больше чем одна очень умная;
В конце каждой итерации процесс работы оценивается и вносятся улучшения;
Команда кроссфункциональная — границы отделов компании не являются препятствием при сотрудничестве, разнообразные навыки сочетаются и происходит синергия.
№33 слайд
![Agile. Применение Не всегда](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img32.jpg)
Содержание слайда: Agile. Применение
Не всегда применение гибких методологий может дать положительный эффект. Agile может негативно сказаться на эффективности:
В проектах, которые являются инфраструктурными и имеют очень сложный процесс поддержки;
В проектах, где подтверждение технического задания требует очень длительного формального цикла;
Если нет обратной связи с конечным пользователем системы или нет возможности у команды провести экспертизу в предметной области;
Если команда состоит из недостаточно квалифицированных специалистов, которые не готовы к изменениям и внедрению прогрессивных подходов.
№34 слайд
![Agile. Scrum. Scrum от англ.](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img33.jpg)
Содержание слайда: Agile. Scrum.
Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.
№35 слайд
![Agile. Scrum. Скрам Scrum это](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img34.jpg)
Содержание слайда: Agile. Scrum.
Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
№37 слайд
![Agile. Scrum. В отдельных](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img36.jpg)
Содержание слайда: Agile. Scrum.
В отдельных случаях, к примеру согласно скрам-стандарту компании Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении.
№38 слайд
![Agile. Scrum. С другой](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img37.jpg)
Содержание слайда: Agile. Scrum.
С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта.
№39 слайд
![Agile. Scrum. Беклог проекта](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img38.jpg)
Содержание слайда: Agile. Scrum.
Беклог проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Беклог проекта открыт для редактирования для всех участников скрам-процесса.
№40 слайд
![Agile. Scrum. Беклог спринта](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img39.jpg)
Содержание слайда: Agile. Scrum.
Беклог спринта (англ. Sprint backlog) — содержит функциональность, выбранную владельцем проекта из беклога проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объём работы, который нужно проделать для завершения спринта.
№42 слайд
![Agile. Scrum. Существуют](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img41.jpg)
Содержание слайда: Agile. Scrum.
Существуют разные виды диаграммы:
Диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
Диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).
№46 слайд
![Agile. Scrum. История спринта](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img45.jpg)
Содержание слайда: Agile. Scrum.
История спринта (Sprint Story) - требуемую функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам так и заказчикам.
Остановка спринта (Abnormal Termination) - остановка спринта может быть произведена раньше срока его планового окончания в исключительных ситуациях. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить владелец проекта, если исчезает необходимость в реализации цели спринта. После остановки спринта проводится совещание с командой, где обсуждаются причины остановки. После этого начинается новый спринт.
Покер планирование (Planning Poker)
Очки за пользовательскую историю (Story Points) - абстрактная метрика оценки сложности истории, которая не учитывает затраты в человеко-часах. Обычно используют одну из следующих шкал: ряд Фибоначчи (1,2,3,5,8,13,21,34,55); линейную шкалу (1,2,3,4 … n); степень двойки (1,2,4,8 … 2n); размеры одежды (XS, S, M, L, XL).
Задачи истории спринта (Sprint Story Tasks) - добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).
Критерий готовности (Definition of Done (DoD)) - критерии, определяющие степень готовности элемента из журнала пожеланий пользователя.
Скорость команды (Velocity) - общее количество очков, набранных командой за предыдущий спринт. Данная метрика помогает команде понять, сколько историй она может сделать за один спринт.
№47 слайд
![Agile. Scrum. Ритуалы. Sprint](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img46.jpg)
Содержание слайда: Agile. Scrum. Ритуалы. Sprint planning meeting.
Выполняется всей командой перед началом спринта;
Команда выбирает требования из Product backlog и формирует Sprint backlog;
Команда декомпозирует требования на задачи;
Каждая задача проходит оценку;
Во время встречи PO отвечает на вопросы команды.
№48 слайд
![Agile. Scrum. Ритуалы. Sprint](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img47.jpg)
Содержание слайда: Agile. Scrum. Ритуалы. Sprint planning meeting. Структура.
Представление и пояснение PO списка требований;
Вопросы со стороны команды;
(Перерыв);
Декомпозиция требований на задачи;
Оценка задач.
В начале проекта может занимать 5 -6 часов. Но со временем будет более оперативной, примерно 2 - 3 часа.
№51 слайд
![Agile. Scrum. Ритуалы. Sprint](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img50.jpg)
Содержание слайда: Agile. Scrum. Ритуалы. Sprint review.
Команда зачитывает требования из Sprint backlog;
По каждому критерию приемки происходит демонстрация полученного результата;
Каждый вопрос PO, записывается для ответа на них позже;
Каждое новое требование PO, записывается, для включения его в Product backlog.
№54 слайд
![Agile. Scrum. Roles. Свинья](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img53.jpg)
Содержание слайда: Agile. Scrum. Roles.
Свинья идёт по дороге. Курица смотрит на неё и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдёт, — отвечает свинья, — ведь тогда я полностью посвящу себя проекту, а ты будешь вовлечена только частично».
№55 слайд
![Agile. Scrum. Roles. Свиньи](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img54.jpg)
Содержание слайда: Agile. Scrum. Roles.
«Свиньи» полностью включены в проект и в скрам-процесс:
Скрам-мастер (Scrum Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера.
Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
Скрам-команда (Scrum Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Никто, кроме команды не может вмешиваться в процесс разработки на протяжении спринта.
№61 слайд
![Agile. Scrum. Roles.](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img60.jpg)
Содержание слайда: Agile. Scrum. Roles. Дополнительные роли (Ancillary roles) в методологии скрам.
«Куры»
Пользователи (Users)
Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).
Управляющие (Managers) — люди, которые управляют персоналом.
Эксперты-консультанты (Consulting Experts)
№62 слайд
![Agile. Scrum. Планирование](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img61.jpg)
Содержание слайда: Agile. Scrum.
Планирование спринта (Sprint Planning Meeting)
Происходит в начале новой итерации Спринта.
Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах;
Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
Обсуждается и определяется, каким образом будет реализован этот объём работ;
Продолжительность совещания ограничена сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
(первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из бэклога продукта;
(вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют бэклог спринта
№63 слайд
![Agile. Scrum. Ежедневное](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img62.jpg)
Содержание слайда: Agile. Scrum.
Ежедневное совещание (Daily Scrum meeting)
начинается точно вовремя;
все могут наблюдать, но только «свиньи» говорят;
длится не более 15 минут;
проводится в одном и том же месте в течение спринта.
В течение совещания каждый член команды отвечает на 3 вопроса:
Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта?
Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта?
Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)
№64 слайд
![Agile. Scrum. Скрам над](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img63.jpg)
Содержание слайда: Agile. Scrum.
Скрам над скрамом (Scrum of Scrums)
Проводится после ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам совещании плюс следующие вопросы:
Что каждая команда сделала с момента предыдущего ежедневного совещания?
Что каждая команда сделает к следующему ежедневному совещанию
Есть ли проблемы, мешающие или замедляющие работу каждой команды?
Нужно ли другой команде сделать что-то из задач вашей команды?
№65 слайд
![Agile. Scrum. Обзор итогов](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img64.jpg)
Содержание слайда: Agile. Scrum.
Обзор итогов спринта (Sprint review meeting)
Проводится в конце спринта.
Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам.
Привлекается максимальное количество зрителей.
Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
Нельзя демонстрировать незавершенную функциональность.
Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта.
№66 слайд
![Agile. Scrum. Ретроспективное](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img65.jpg)
Содержание слайда: Agile. Scrum.
Ретроспективное совещание (Retrospective meeting)
Проводится в конце спринта.
Члены команды высказывают своё мнение о прошедшем спринте.
Отвечают на два основных вопроса:
Что было сделано хорошо в прошедшем спринте?
Что надо улучшить в следующем?
Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
Ограничена одним-тремя часами.
№67 слайд
![Kanban. Канбан метод](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img66.jpg)
Содержание слайда: Kanban.
Канбан — метод управления разработкой, реализующий принцип «точно в срок» и способствующий равномерному распределению нагрузки между работниками. При данном подходе, весь процесс разработки прозрачен для всех членов команды. Задачи по мере поступления заносятся в отдельный список, откуда каждый разработчик может извлечь требуемую задачу.
№68 слайд
![Kanban. Канбан основан на](/documents_6/41d39a04b0fa082fe2b901007e6fcfa8/img67.jpg)
Содержание слайда: Kanban.
Канбан основан на четырех основных принципах:
Опора на существующие методы разработки
Канбан начинается с существующих методов разработки и стимулирует в них дополнительные изменения.
Предварительная договоренность о проведении важных изменений
Команда разработчиков должна учитывать, что постоянные изменения — это способ улучшить существующий процесс разработки, однако проведение глобальных перемен имеет большой риск. Канбан поощряет небольшие и эволюционные изменения.
Уважение к существующему порядку, ролям и обязанностям
Поощрение инициативы
Приветствуются проявления инициативы каждого разработчика.
Скачать все slide презентации Методологии разработки ПО. (Лекция 18) одним архивом:
Похожие презентации
-
Гибкие методологии разработки программного обеспечения
-
Разработка приложений на платформе . NET. Лекция 10
-
Стандарты, методологии разработки ПО, описания БП используемые в работе
-
Примеры разработки программ. (Лекция 14)
-
Разработка моделей, инструментальные средства моделирования систем. Язык моделирования GPSS. (Лекция 2. 8)
-
Сравнение методологий разработки программ по степени формальности и отношению к каскадной или итеративной разработке
-
Технология и процесс разработки ПО. Лекция 5
-
Технология и процесс разработки ПО. Лекция 6
-
Предмет и задачи программной инженерии. Критерии качества программного продукта и процесса разработки. (Лекция 1)
-
Методы разработки параллельных программ при использования интерфейса передачи сообщений mpi–2 (Лекция 8)