🗊 Презентация Методологии разработки ПО. (Лекция 18)

Нажмите для полного просмотра!
Методологии разработки ПО. (Лекция 18), слайд №1 Методологии разработки ПО. (Лекция 18), слайд №2 Методологии разработки ПО. (Лекция 18), слайд №3 Методологии разработки ПО. (Лекция 18), слайд №4 Методологии разработки ПО. (Лекция 18), слайд №5 Методологии разработки ПО. (Лекция 18), слайд №6 Методологии разработки ПО. (Лекция 18), слайд №7 Методологии разработки ПО. (Лекция 18), слайд №8 Методологии разработки ПО. (Лекция 18), слайд №9 Методологии разработки ПО. (Лекция 18), слайд №10 Методологии разработки ПО. (Лекция 18), слайд №11 Методологии разработки ПО. (Лекция 18), слайд №12 Методологии разработки ПО. (Лекция 18), слайд №13 Методологии разработки ПО. (Лекция 18), слайд №14 Методологии разработки ПО. (Лекция 18), слайд №15 Методологии разработки ПО. (Лекция 18), слайд №16 Методологии разработки ПО. (Лекция 18), слайд №17 Методологии разработки ПО. (Лекция 18), слайд №18 Методологии разработки ПО. (Лекция 18), слайд №19 Методологии разработки ПО. (Лекция 18), слайд №20 Методологии разработки ПО. (Лекция 18), слайд №21 Методологии разработки ПО. (Лекция 18), слайд №22 Методологии разработки ПО. (Лекция 18), слайд №23 Методологии разработки ПО. (Лекция 18), слайд №24 Методологии разработки ПО. (Лекция 18), слайд №25 Методологии разработки ПО. (Лекция 18), слайд №26 Методологии разработки ПО. (Лекция 18), слайд №27 Методологии разработки ПО. (Лекция 18), слайд №28 Методологии разработки ПО. (Лекция 18), слайд №29 Методологии разработки ПО. (Лекция 18), слайд №30 Методологии разработки ПО. (Лекция 18), слайд №31 Методологии разработки ПО. (Лекция 18), слайд №32 Методологии разработки ПО. (Лекция 18), слайд №33 Методологии разработки ПО. (Лекция 18), слайд №34 Методологии разработки ПО. (Лекция 18), слайд №35 Методологии разработки ПО. (Лекция 18), слайд №36 Методологии разработки ПО. (Лекция 18), слайд №37 Методологии разработки ПО. (Лекция 18), слайд №38 Методологии разработки ПО. (Лекция 18), слайд №39 Методологии разработки ПО. (Лекция 18), слайд №40 Методологии разработки ПО. (Лекция 18), слайд №41 Методологии разработки ПО. (Лекция 18), слайд №42 Методологии разработки ПО. (Лекция 18), слайд №43 Методологии разработки ПО. (Лекция 18), слайд №44 Методологии разработки ПО. (Лекция 18), слайд №45 Методологии разработки ПО. (Лекция 18), слайд №46 Методологии разработки ПО. (Лекция 18), слайд №47 Методологии разработки ПО. (Лекция 18), слайд №48 Методологии разработки ПО. (Лекция 18), слайд №49 Методологии разработки ПО. (Лекция 18), слайд №50 Методологии разработки ПО. (Лекция 18), слайд №51 Методологии разработки ПО. (Лекция 18), слайд №52 Методологии разработки ПО. (Лекция 18), слайд №53 Методологии разработки ПО. (Лекция 18), слайд №54 Методологии разработки ПО. (Лекция 18), слайд №55 Методологии разработки ПО. (Лекция 18), слайд №56 Методологии разработки ПО. (Лекция 18), слайд №57 Методологии разработки ПО. (Лекция 18), слайд №58 Методологии разработки ПО. (Лекция 18), слайд №59 Методологии разработки ПО. (Лекция 18), слайд №60 Методологии разработки ПО. (Лекция 18), слайд №61 Методологии разработки ПО. (Лекция 18), слайд №62 Методологии разработки ПО. (Лекция 18), слайд №63 Методологии разработки ПО. (Лекция 18), слайд №64 Методологии разработки ПО. (Лекция 18), слайд №65 Методологии разработки ПО. (Лекция 18), слайд №66 Методологии разработки ПО. (Лекция 18), слайд №67 Методологии разработки ПО. (Лекция 18), слайд №68 Методологии разработки ПО. (Лекция 18), слайд №69 Методологии разработки ПО. (Лекция 18), слайд №70 Методологии разработки ПО. (Лекция 18), слайд №71 Методологии разработки ПО. (Лекция 18), слайд №72

Содержание

Вы можете ознакомиться и скачать презентацию на тему Методологии разработки ПО. (Лекция 18). Доклад-сообщение содержит 72 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации


Слайд 1


Manual QA course Lecture 18. Методологии разработки ПО.
Описание слайда:
Manual QA course Lecture 18. Методологии разработки ПО.

Слайд 2


Waterfall. Самая старая методология разработки ПО. Описана в 1970 году Винстоном Ройсом. Подразумевает последовательное прохождение всех стадий,...
Описание слайда:
Waterfall. Самая старая методология разработки ПО. Описана в 1970 году Винстоном Ройсом. Подразумевает последовательное прохождение всех стадий, каждая из которых должна полностью завершиться до начала предыдущей.

Слайд 3


Waterfall.
Описание слайда:
Waterfall.

Слайд 4


Waterfall. Плюсы. Легок для понимания и использования; Детально структурирован; Задает стабильные требования к продукту; Проекты легко...
Описание слайда:
Waterfall. Плюсы. Легок для понимания и использования; Детально структурирован; Задает стабильные требования к продукту; Проекты легко контролируются; Качество имеет первоочередный приоритет.

Слайд 5


Waterfall. Минусы. Все требования должны быть определены до начала разработки; Дорого и медленно; Чувствителен к изменениям; Мало возможностей...
Описание слайда:
Waterfall. Минусы. Все требования должны быть определены до начала разработки; Дорого и медленно; Чувствителен к изменениям; Мало возможностей повлиять на цели проекта; Зачастую проблемы выявляются на этапе тестирования; Много документации (в том числе и технической), которая непонятна конечному пользователю и заказчику.

Слайд 6


Waterfall. Когда применять? Требования к продукту предельно ясны и стабильны; Известны используемые технологии и инструменты; Проект большой,...
Описание слайда:
Waterfall. Когда применять? Требования к продукту предельно ясны и стабильны; Известны используемые технологии и инструменты; Проект большой, дорогой, сложный; Примеры: ПО для адронного коллайдера; ПО для космической промышленности.

Слайд 7


Agile. Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, которая...
Описание слайда:
Agile. Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, которая характеризуется акцентом на людях и их взаимодействии, рабочем продукте, а также на гибкости и реагировании на изменения.

Слайд 8


Agile. В основе гибкой методологии лежит итеративный процесс разработки. Работа над проектом проходит циклами (длительность 1-4 недели) и...
Описание слайда:
Agile. В основе гибкой методологии лежит итеративный процесс разработки. Работа над проектом проходит циклами (длительность 1-4 недели) и подразумевается что в конце каждого цикла выпускается новая готовая версия продукта. Дальше идет анализ полученных результатов и планируется работа над следующим циклом, и так далее

Слайд 9


Agile vs Waterfall. Agile методология является альтернативой waterfall модели (водопадный или каскадный процесс разработки).
Описание слайда:
Agile vs Waterfall. Agile методология является альтернативой waterfall модели (водопадный или каскадный процесс разработки).

Слайд 10


Agile vs Waterfall. В каскадной модели есть ряд определенных этапов процесса разработки и разработчик последовательно переходит от одного этапа к...
Описание слайда:
Agile vs Waterfall. В каскадной модели есть ряд определенных этапов процесса разработки и разработчик последовательно переходит от одного этапа к другому. Каскадная модель разработки подразумевает, что переход к новому этапу разработки начинается только после полного завершения предыдущей

Слайд 11


Agile vs Waterfall.
Описание слайда:
Agile vs Waterfall.

Слайд 12


Agile. Начало. Активное вхождение Agile в массы началось после подписания Agile Manifesto 11-13 февраля 2001 года на лыжном курорте в штате Юта США....
Описание слайда:
Agile. Начало. Активное вхождение Agile в массы началось после подписания Agile Manifesto 11-13 февраля 2001 года на лыжном курорте в штате Юта США. Этот манифест подписали представители таких методологий как Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM)

Слайд 13


Agile. Почему появился? Заказчик не может сформировать четкие требования; Новые технологии усилили конкуренцию в бизнесе; Заказчики и разработчики не...
Описание слайда:
Agile. Почему появился? Заказчик не может сформировать четкие требования; Новые технологии усилили конкуренцию в бизнесе; Заказчики и разработчики не удовлетворены процессом взаимодействия;

Слайд 14


Agile. Основные идеи. Люди и взаимодействие важнее процессов и инструментов; Работающий продукт важнее исчерпывающей документации; Сотрудничество с...
Описание слайда:
Agile. Основные идеи. Люди и взаимодействие важнее процессов и инструментов; Работающий продукт важнее исчерпывающей документации; Сотрудничество с заказчиком важнее согласования условий контракта; Готовность к изменениям важнее следования первоначальному плану.

Слайд 15


Agile vs Waterfall. То есть, не отрицая важности того, что справа, мы всё таки больше ценим то, что слева
Описание слайда:
Agile vs Waterfall. То есть, не отрицая важности того, что справа, мы всё таки больше ценим то, что слева

Слайд 16


Agile Manifesto. Особенность в том, что в манифесте не описаны какие либо действия или правила, а описаны только основные принципы, на базе которых...
Описание слайда:
Agile Manifesto. Особенность в том, что в манифесте не описаны какие либо действия или правила, а описаны только основные принципы, на базе которых может строиться подход к разработке.

Слайд 17


Agile Manifesto. Принципы. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного...
Описание слайда:
Agile Manifesto. Принципы. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

Слайд 18


Agile Manifesto. Принципы. Изменение требований приветствуется, даже на поздних стадиях разработки.
Описание слайда:
Agile Manifesto. Принципы. Изменение требований приветствуется, даже на поздних стадиях разработки.

Слайд 19


Agile Manifesto. Принципы. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
Описание слайда:
Agile Manifesto. Принципы. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

Слайд 20


Agile Manifesto. Принципы. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
Описание слайда:
Agile Manifesto. Принципы. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

Слайд 21


Agile Manifesto. Принципы. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте...
Описание слайда:
Agile Manifesto. Принципы. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

Слайд 22


Agile Manifesto. Принципы. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так...
Описание слайда:
Agile Manifesto. Принципы. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

Слайд 23


Agile Manifesto. Принципы. Работающий продукт — основной показатель прогресса.
Описание слайда:
Agile Manifesto. Принципы. Работающий продукт — основной показатель прогресса.

Слайд 24


Agile Manifesto. Принципы. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
Описание слайда:
Agile Manifesto. Принципы. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.

Слайд 25


Agile Manifesto. Принципы. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Описание слайда:
Agile Manifesto. Принципы. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Слайд 26


Agile Manifesto. Принципы. Простота - искусство не делать лишней работы
Описание слайда:
Agile Manifesto. Принципы. Простота - искусство не делать лишней работы

Слайд 27


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

Слайд 28


Agile Manifesto. Принципы. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать...
Описание слайда:
Agile Manifesto. Принципы. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Слайд 29


Agile Manifesto. Принципы. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного...
Описание слайда:
Agile Manifesto. Принципы. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Простота — искусство минимизации лишней работы — крайне необходима. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Слайд 30


Agile. Преимущества. Частые релизы — требования не успевают устаревать, частью функционала уже можно пользоваться; Фиксированная длина итераций —...
Описание слайда:
Agile. Преимущества. Частые релизы — требования не успевают устаревать, частью функционала уже можно пользоваться; Фиксированная длина итераций — можно предсказывать скорость работы команды с учетом рисков; Команда сама оценивает задачи — оценки реалистичны, команда мотивирована выполнить свои обязательства; Команда самоуправляемая — 10 голов учтут больше чем одна очень умная; В конце каждой итерации процесс работы оценивается и вносятся улучшения; Команда кроссфункциональная — границы отделов компании не являются препятствием при сотрудничестве, разнообразные навыки сочетаются и происходит синергия.

Слайд 31


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

Слайд 32


Agile. Применение. Не каждой команде может подойти применение гибкой методологии. Для некоторых проектов будет удачной и водопадная модель.
Описание слайда:
Agile. Применение. Не каждой команде может подойти применение гибкой методологии. Для некоторых проектов будет удачной и водопадная модель.

Слайд 33


Agile. Применение Не всегда применение гибких методологий может дать положительный эффект. Agile может негативно сказаться на эффективности: В...
Описание слайда:
Agile. Применение Не всегда применение гибких методологий может дать положительный эффект. Agile может негативно сказаться на эффективности: В проектах, которые являются инфраструктурными и имеют очень сложный процесс поддержки; В проектах, где подтверждение технического задания требует очень длительного формального цикла; Если нет обратной связи с конечным пользователем системы или нет возможности у команды провести экспертизу в предметной области; Если команда состоит из недостаточно квалифицированных специалистов, которые не готовы к изменениям и внедрению прогрессивных подходов.

Слайд 34


Agile. Scrum. Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для...
Описание слайда:
Agile. Scrum. Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.

Слайд 35


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

Слайд 36


Agile. Scrum. Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени....
Описание слайда:
Agile. Scrum. Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Длительность одного спринта от 2 до 4 недель.

Слайд 37


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

Слайд 38


Agile. Scrum. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец...
Описание слайда:
Agile. Scrum. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок. Для оценки объёма работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка фиксируется в бэклоге проекта.

Слайд 39


Agile. Scrum. Беклог проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих...
Описание слайда:
Agile. Scrum. Беклог проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Беклог проекта открыт для редактирования для всех участников скрам-процесса.

Слайд 40


Agile. Scrum. Беклог спринта (англ. Sprint backlog) — содержит функциональность, выбранную владельцем проекта из беклога проекта. Все функции разбиты...
Описание слайда:
Agile. Scrum. Беклог спринта (англ. Sprint backlog) — содержит функциональность, выбранную владельцем проекта из беклога проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день команда оценивает объём работы, который нужно проделать для завершения спринта.

Слайд 41


Agile. Scrum. Диаграмма сгорания задач (Burndown chart) - диаграмма, показывающая количество сделанной и оставшейся работы. Обновляется ежедневно с...
Описание слайда:
Agile. Scrum. Диаграмма сгорания задач (Burndown chart) - диаграмма, показывающая количество сделанной и оставшейся работы. Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График должен быть общедоступен.

Слайд 42


Agile. Scrum. Существуют разные виды диаграммы: Диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся...
Описание слайда:
Agile. Scrum. Существуют разные виды диаграммы: Диаграмма сгорания работ для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте. Диаграмма сгорания работ для выпуска проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до выпуска продукта (обычно строится на базе нескольких спринтов).

Слайд 43


Agile. Scrum. Диаграмма отображает завершенный спринт. Показывает оставшиеся нерешённые задачи и трудозатраты, необходимые для их завершения в...
Описание слайда:
Agile. Scrum. Диаграмма отображает завершенный спринт. Показывает оставшиеся нерешённые задачи и трудозатраты, необходимые для их завершения в расчёте на 21 рабочий день.

Слайд 44


Agile. Scrum. Burndown chart.
Описание слайда:
Agile. Scrum. Burndown chart.

Слайд 45


Agile. Scrum. Burndown chart.
Описание слайда:
Agile. Scrum. Burndown chart.

Слайд 46


Agile. Scrum. История спринта (Sprint Story) - требуемую функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история...
Описание слайда:
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 planning meeting. Выполняется всей командой перед началом спринта; Команда выбирает требования из Product backlog и...
Описание слайда:
Agile. Scrum. Ритуалы. Sprint planning meeting. Выполняется всей командой перед началом спринта; Команда выбирает требования из Product backlog и формирует Sprint backlog; Команда декомпозирует требования на задачи; Каждая задача проходит оценку; Во время встречи PO отвечает на вопросы команды.

Слайд 48


Agile. Scrum. Ритуалы. Sprint planning meeting. Структура. Представление и пояснение PO списка требований; Вопросы со стороны команды; (Перерыв);...
Описание слайда:
Agile. Scrum. Ритуалы. Sprint planning meeting. Структура. Представление и пояснение PO списка требований; Вопросы со стороны команды; (Перерыв); Декомпозиция требований на задачи; Оценка задач. В начале проекта может занимать 5 -6 часов. Но со временем будет более оперативной, примерно 2 - 3 часа.

Слайд 49


Agile. Scrum. Ритуалы. Daily meeting. Проходит ежедневно в одно и тоже время, и в одном и том же месте; встреча проходит только стоя; Длительность не...
Описание слайда:
Agile. Scrum. Ритуалы. Daily meeting. Проходит ежедневно в одно и тоже время, и в одном и том же месте; встреча проходит только стоя; Длительность не более 15 минут; Каждый должен всего на 3 вопроса: Что делал вчера? Что буду делать сегодня? Какие есть проблемы?

Слайд 50


Agile. Scrum. Ритуалы. Sprint review. По завершению каждого спринта команда должна провести демонстрацию полученного результата.
Описание слайда:
Agile. Scrum. Ритуалы. Sprint review. По завершению каждого спринта команда должна провести демонстрацию полученного результата.

Слайд 51


Agile. Scrum. Ритуалы. Sprint review. Команда зачитывает требования из Sprint backlog; По каждому критерию приемки происходит демонстрация...
Описание слайда:
Agile. Scrum. Ритуалы. Sprint review. Команда зачитывает требования из Sprint backlog; По каждому критерию приемки происходит демонстрация полученного результата; Каждый вопрос PO, записывается для ответа на них позже; Каждое новое требование PO, записывается, для включения его в Product backlog.

Слайд 52


Agile. Scrum. Ритуалы. Retrospective. Ритуал направлен на обмен опытом внутри команды, проводится после Sprint review.
Описание слайда:
Agile. Scrum. Ритуалы. Retrospective. Ритуал направлен на обмен опытом внутри команды, проводится после Sprint review.

Слайд 53


Agile. Scrum. Ритуалы. Retrospective. Какие решения должна принять команда, чтобы сделать процесс более предсказуемым; какие проблемы мешают...
Описание слайда:
Agile. Scrum. Ритуалы. Retrospective. Какие решения должна принять команда, чтобы сделать процесс более предсказуемым; какие проблемы мешают выполнять взятые на себя обязательства; Как улучшить взаимодействие с PO; Какие ошибки совершает команда и почему.

Слайд 54


Agile. Scrum. Roles. Свинья идёт по дороге. Курица смотрит на неё и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает:...
Описание слайда:
Agile. Scrum. Roles. Свинья идёт по дороге. Курица смотрит на неё и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдёт, — отвечает свинья, — ведь тогда я полностью посвящу себя проекту, а ты будешь вовлечена только частично».

Слайд 55


Agile. Scrum. Roles. «Свиньи» полностью включены в проект и в скрам-процесс: Скрам-мастер (Scrum Master) — проводит совещания (Scrum meetings) следит...
Описание слайда:
Agile. Scrum. Roles. «Свиньи» полностью включены в проект и в скрам-процесс: Скрам-мастер (Scrum Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера. Владелец продукта (Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Скрам-команда (Scrum Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Никто, кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

Слайд 56


Agile. Scrum. Roles. Product owner. Формирует требования; Приоритезирует требования; Корректирует приоритеты на каждом спринте; Несет персональную...
Описание слайда:
Agile. Scrum. Roles. Product owner. Формирует требования; Приоритезирует требования; Корректирует приоритеты на каждом спринте; Несет персональную ответственность за ценность требований; Отвечает за взаимодействие с рынком; Только один человек.

Слайд 57


Agile. Scrum. Roles. Scrum Master. Следит за корректным применением Agile - принципов; Организует работу команду и обеспечивает ее всем необходимым;...
Описание слайда:
Agile. Scrum. Roles. Scrum Master. Следит за корректным применением Agile - принципов; Организует работу команду и обеспечивает ее всем необходимым; Защищает команду, несет ответственность за ее эффективность; Только один человек.

Слайд 58


Agile. Scrum. Roles. Scrum Master. Не назначает людей на задачи - это делает сама команда; Не заставляет делать людей работу - это ответственность...
Описание слайда:
Agile. Scrum. Roles. Scrum Master. Не назначает людей на задачи - это делает сама команда; Не заставляет делать людей работу - это ответственность команды; Не указывает PO, какие требования писать к продукту - это ответственность PO.

Слайд 59


Agile. Scrum. Roles. Team. Кросс - функциональная; Взаимозаменяемая; Самоорганизующаяся; С фиксированным составом (в ходе спринта); 4 - 8 человек.
Описание слайда:
Agile. Scrum. Roles. Team. Кросс - функциональная; Взаимозаменяемая; Самоорганизующаяся; С фиксированным составом (в ходе спринта); 4 - 8 человек.

Слайд 60


Agile. Scrum. Roles. Team. Определяет продолжительность спринта; Емкость команды; Трудоемкость требований, которые будут реализованы в спринте;...
Описание слайда:
Agile. Scrum. Roles. Team. Определяет продолжительность спринта; Емкость команды; Трудоемкость требований, которые будут реализованы в спринте; Очередность выполнения задач.

Слайд 61


Agile. Scrum. Roles. Дополнительные роли (Ancillary roles) в методологии скрам. «Куры» Пользователи (Users) Клиенты, Продавцы (Stakeholders) — лица,...
Описание слайда:
Agile. Scrum. Roles. Дополнительные роли (Ancillary roles) в методологии скрам. «Куры» Пользователи (Users) Клиенты, Продавцы (Stakeholders) — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review). Управляющие (Managers) — люди, которые управляют персоналом. Эксперты-консультанты (Consulting Experts)

Слайд 62


Agile. Scrum. Планирование спринта (Sprint Planning Meeting) Происходит в начале новой итерации Спринта. Из бэклога проекта выбираются задачи,...
Описание слайда:
Agile. Scrum. Планирование спринта (Sprint Planning Meeting) Происходит в начале новой итерации Спринта. Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда; На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах; Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи; Обсуждается и определяется, каким образом будет реализован этот объём работ; Продолжительность совещания ограничена сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п. (первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из бэклога продукта; (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют бэклог спринта

Слайд 63


Agile. Scrum. Ежедневное совещание (Daily Scrum meeting) начинается точно вовремя; все могут наблюдать, но только «свиньи» говорят; длится не более...
Описание слайда:
Agile. Scrum. Ежедневное совещание (Daily Scrum meeting) начинается точно вовремя; все могут наблюдать, но только «свиньи» говорят; длится не более 15 минут; проводится в одном и том же месте в течение спринта. В течение совещания каждый член команды отвечает на 3 вопроса: Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта? Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта? Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

Слайд 64


Agile. Scrum. Скрам над скрамом (Scrum of Scrums) Проводится после ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать работу,...
Описание слайда:
Agile. Scrum. Скрам над скрамом (Scrum of Scrums) Проводится после ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам совещании плюс следующие вопросы: Что каждая команда сделала с момента предыдущего ежедневного совещания? Что каждая команда сделает к следующему ежедневному совещанию Есть ли проблемы, мешающие или замедляющие работу каждой команды? Нужно ли другой команде сделать что-то из задач вашей команды?

Слайд 65


Agile. Scrum. Обзор итогов спринта (Sprint review meeting) Проводится в конце спринта. Команда демонстрирует прирост функциональности продукта всем...
Описание слайда:
Agile. Scrum. Обзор итогов спринта (Sprint review meeting) Проводится в конце спринта. Команда демонстрирует прирост функциональности продукта всем заинтересованным лицам. Привлекается максимальное количество зрителей. Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт). Нельзя демонстрировать незавершенную функциональность. Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта.

Слайд 66


Agile. Scrum. Ретроспективное совещание (Retrospective meeting) Проводится в конце спринта. Члены команды высказывают своё мнение о прошедшем...
Описание слайда:
Agile. Scrum. Ретроспективное совещание (Retrospective meeting) Проводится в конце спринта. Члены команды высказывают своё мнение о прошедшем спринте. Отвечают на два основных вопроса: Что было сделано хорошо в прошедшем спринте? Что надо улучшить в следующем? Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения). Ограничена одним-тремя часами.

Слайд 67


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

Слайд 68


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

Слайд 69


Kanban.
Описание слайда:
Kanban.

Слайд 70


Kanban. Основные принципы Канбан Доски: Визуализация рабочего процесса; Ограничение работы, которая находится в процессе; Перемещение задач от...
Описание слайда:
Kanban. Основные принципы Канбан Доски: Визуализация рабочего процесса; Ограничение работы, которая находится в процессе; Перемещение задач от колонки к колонке; Мониторинг, адаптация и оптимизация;

Слайд 71


Kanban. Отменяется разработка по фазам; Пользовательские истории больше, но их меньше; Оценка задач сводится к минимуму или убирается совсем;...
Описание слайда:
Kanban. Отменяется разработка по фазам; Пользовательские истории больше, но их меньше; Оценка задач сводится к минимуму или убирается совсем; Внимание переходит со скорости разработки на продолжительность цикла.

Слайд 72


Вопросы и ответы
Описание слайда:
Вопросы и ответы



Похожие презентации
Mypresentation.ru
Загрузить презентацию