02_Методологии_разработки_ПО_Agile,_Waterfall,_и_другие

Содержание

Слайд 2

Что будем изучать?

Ключевые роли в проектной команде
Основные модели жизненного цикла разработки ПО
Методология

Что будем изучать? Ключевые роли в проектной команде Основные модели жизненного цикла разработки ПО Методология Agile
Agile

Слайд 3

Ключевые роли в проектной команде

Stakeholders (стейкхолдер)
Project Manager (проектный менеджер)
Business analyst (бизнес аналитик)
UI/UX

Ключевые роли в проектной команде Stakeholders (стейкхолдер) Project Manager (проектный менеджер) Business
designer (UI/UX дизайнер)
Developers (разработчики)
QA

Слайд 4

Stakeholders

Stakeholders (заинтересованная сторона, причастная сторона) – понятие, которое описывает человека, группу лиц

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

Теория управления стейкхолдерами

Слайд 5

Project Manager (PM)

Project Manager – это специалист, чьей главной задачей является управление

Project Manager (PM) Project Manager – это специалист, чьей главной задачей является
проектом в целом: проектирование и расстановка приоритетов, планирование выполнения задач, контроль, коммуникации, а также оперативное решение проблем.
Основная обязанность и ответственность PM – довести идею заказчика до реализации в установленный срок, используя существующие ресурсы. В рамках этой задачи PM’у необходимо построить план разработки, организовать команду, настроить процесс работы над проектом, обеспечить обратную связь между командами и заказчиком, устранять помехи для команд, контролировать качество и поставку продукта в срок.

Карьера в IT: должность Project Manager

Слайд 6

Обязанности PM’а:
— составление плана проекта и ведение проектной документации;
— согласование сроков и

Обязанности PM’а: — составление плана проекта и ведение проектной документации; — согласование
анализ возможный рисков;
— участие в подборе и утверждении проектной команды;
— определение требуемых ресурсов и рабочей среды, их распределение внутри команды;
— постановка рабочего процесса в команде (разработка, тестирование, работа с требованиями);
— определение и отслеживание должной приоритетности выполнения задач;
— отслеживание нагрузки задачами и прогресса по задачам каждого разработчика;
— отслеживание сроков выполнения задач;
— удерживание команды в рабочем состоянии, мотивация команды;
— создание прозрачной среды общения между всеми участниками процесса;
— отслеживание удовлетворенности проектом со стороны команды;
— решение всевозможных конфликтных ситуаций внутри команды и в связке заказчик-команда;
— общение с заказчиком, управление его ожиданиями;
— предоставление заказчику отчетности о ходе выполнения задач и проекта в целом;
— презентация заказчику готовых решений, демо-версий, прототипов.

Слайд 7

Business Analyst (BA)

Бизнес-аналитик – это специалист, который исследует проблему заказчика, ищет решение

Business Analyst (BA) Бизнес-аналитик – это специалист, который исследует проблему заказчика, ищет
и оформляет его концепцию в форме требований, на которые в дальнейшем будут ориентироваться разработчики при создании продукта.

Карьера в IT: должность Бизнес-аналитик

Слайд 8

В круг обязанностей бизнес-аналитика входит:
Анализ бизнес-потребностей заказчика;
Составление требований к будущему продукту (общение

В круг обязанностей бизнес-аналитика входит: Анализ бизнес-потребностей заказчика; Составление требований к будущему
с заинтересованными лицами –разработчиками, клиентами, конечными пользователями);
Анализ требований (применение различных методологий и нотаций – прототипирование, анкетирование, опрос, мозговой штурм, анализ существующих документаций, конкурентов);
Анализ проблемных областей и предложения для улучшения;
Формализация требований (разделение требований на функциональные, не функциональные, написание спецификации требований);
Управление требованиями (обработка запросов на изменение, анализ и описание влияния на существующие требования);
Трансляция требований между разработчиками и клиентом.

Слайд 9

UI/UX дизайнер

UI/UX дизайнер – это креативный специалист, который проектирует пользовательские интерфейсы. UI

UI/UX дизайнер UI/UX дизайнер – это креативный специалист, который проектирует пользовательские интерфейсы.
и UX – это два разных профиля дизайна, но чаще всего задачи по обоим направлениям тесно связаны между собой, а потому их делает один универсальный специалист.
UI (User Interface) – пользовательский интерфейс
UX (User experience) – пользовательский опыт

Карьера в IT: должность UX/UI дизайнер

Слайд 10

UI-дизайнер отвечает за визуализацию приложения, делая его удобным и функциональным. Дабы продукт

UI-дизайнер отвечает за визуализацию приложения, делая его удобным и функциональным. Дабы продукт
с комфортом воспринимался глазами пользователя, специалист UI отвечает за подбор форм, цветов и других параметров. Что касается UX-дизайнера, он в большей степени ответственен за функциональность дизайна. В итоге: приложением легко и удобно пользоваться.
Ключевые обязанности UX/UI дизайнера:
Cбор информации о проекте и его аудитории;
Проектирование пользовательских сценариев;
Разработка стиля, составление инструкций по шрифтам, цветам и размерам;
Создание макетов и прототипов;
Отрисовка интерфейса в графических редакторах.

Слайд 11

Developers

К масштабным проектам, где требуется техническое управление в первую очередь подключается руководитель

Developers К масштабным проектам, где требуется техническое управление в первую очередь подключается
группы разработчиков (Team Lead).
В числе его задач:
Формирование сплоченной команды, ее микроклимата и корпоративной культуры;
Определение стратегии разработки: формирование кодстайла, достижение запланированной производительности, обеспечение требований безопасности, выбор правильного архитектурного решения;
Распределение задач между членами команды, контроль их выполнения, соблюдение сроков и других требований, проведение кодревью.

Слайд 13

QA engineer

QA engineer – это специалист по обеспечению качества, деятельность которого направлена

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

Слайд 14

Внутри процесса QA выделяют процесс Quality Control – контроль качества продукта. QC-специалисты

Внутри процесса QA выделяют процесс Quality Control – контроль качества продукта. QC-специалисты
анализируют результаты тестирования и отвечают за выявление и уничтожение дефектов в продукте.
Еще более узкая специальность в рамках QA/QC – тестировщик ПО, который проверяет готовый продукт на наличие ошибок (багов) и несоответствие требованиям, и затем документирует найденные дефекты и пути их воспроизведения. Тестирование – это один из этапов обеспечения и контроля качества.
В Украине различия между должностями QA и тестировщика смазаны, и на практике это одно и то же. Хотя теоретически тестировщик тестирует продукт как результат, а QA работает над обеспечением процессов, которые могут повысить качество ПО в целом.

Слайд 15

Выделяют 4 основные роли:
Test Analyst – занимается статическим тестированием требований: проверяет, насколько

Выделяют 4 основные роли: Test Analyst – занимается статическим тестированием требований: проверяет,
они полны, однозначны, непротиворечивы и т. д.
Test Designer – создает набор тестов на базе требований, планирует конфигурации, необходимые для тестирования.
Test Executor – выполняет заранее подготовленные тесты, документирует найденные ошибки и шаги их воспроизведения.
Test Manager – скорее управленец, чем инженер. Планирует и контролирует работы, связанные с тестированием: оценки сроков, работу над планом-графиком, контроль покрытия требований тестами, постановку задач членам команды, коммуникацию со стейкхолдерами.
Карьера в IT: должность QA engineer

Слайд 16

Automation QA engineer

AQA engineer – это специалист по обеспечению качества продукта, который

Automation QA engineer AQA engineer – это специалист по обеспечению качества продукта,
использует программные средства для создания тестов и проверки результатов выполнения.
Основная задача AQA – создавать автоматические скрипты, которые будут проверять работу программы на основании тест-кейсов, написанных manual QA. Это помогает сократить время тестирования и упростить его процесс.
AQA обладает навыками программиста и логикой тестировщика одновременно:
— Как и QA-инженеры или тестировщики, AQA мониторит качество продукта на различных этапах его разработки, тестирования и эксплуатации.
— Как и программисты, AQA занимается разработкой, только он создает продукт, чтобы проверить написанное программистами.
Другими словами, программисты – создают, тестировщики – ломают, а автоматизаторы – создают, чтобы сломать.
Карьера в IT: должность QA Automation engineer

Слайд 17

Жизненный цикл программного обеспечения

Жизненный цикл программного обеспечения (ПО) – период времени, состоящий

Жизненный цикл программного обеспечения Жизненный цикл программного обеспечения (ПО) – период времени,
из нескольких этапов, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этапы могут называться по-разному и дробиться на более мелкие стадии.
Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.
Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

Слайд 18

Модель жизненного цикла ПО

Модель жизненного цикла ПО – структура, определяющая последовательность выполнения

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

Слайд 19

Основные модели разработки ПО

Waterfall (каскадная модель или «водопад»);
V-model – V-образная модель, разработка

Основные модели разработки ПО Waterfall (каскадная модель или «водопад»); V-model – V-образная
через тестирование;
Incremental Model – инкрементная модель;
Iterative Model – итеративная (или итерационная) модель;
Spiral Model – спиральная модель;

Слайд 20

Каскадная модель (waterfall)

Основная суть модели Waterfall в том, что этапы зависят друг

Каскадная модель (waterfall) Основная суть модели Waterfall в том, что этапы зависят
от друга и следующий начинается, когда закончен предыдущий, образуя таким образом поступательное (каскадное) движение вперед.

Слайд 21

Когда использовать каскадную методологию?
Только тогда, когда требования известны, понятны и зафиксированы;
Противоречивых требований

Когда использовать каскадную методологию? Только тогда, когда требования известны, понятны и зафиксированы;
не имеется;
Нет проблем с доступностью программистов нужной квалификации;
В относительно небольших проектах.
«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов, на основе которых можно написать требования к новому ПО.
При работе с каскадной моделью основная задача – написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.

Слайд 22

Преимущества каскадной модели:
Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты,

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

Слайд 23

V-модель

Это усовершенствованная каскадная модель, в которой заказчик с командой разработки одновременно составляют

V-модель Это усовершенствованная каскадная модель, в которой заказчик с командой разработки одновременно
требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.
V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.

Difference between V-model and W-model in software testing.

Слайд 24

Преимущества V-модели:
Каждая стадия имеет конкретные результаты;
Более высокие показатели по сравнению с каскадной

Преимущества V-модели: Каждая стадия имеет конкретные результаты; Более высокие показатели по сравнению
моделью по причине того, что тестирование начинается на ранних этапах;
Экономия времени по сравнению с каскадной моделью может достигать 50%;
Отлично подходит для небольших проектов, где все требования к продукту очевидны сразу;
Полноценная реализация доступных ресурсов.
Недостатки V-модели:
Отсутствие гибкости, как и в случае с каскадной моделью. Вносить изменения на поздних этапах будет трудно и дорого
Сама разработка начинается строго с началом соответствующей стадии, то есть, никаких прототипов на ранних этапах не разрабатывается
Контроль рисков затруднен: нет определённого способа решения критических проблем, обнаруженных на этапе тестирования

Слайд 25

Итерационная модель

Итерационная модель предполагает разбиение проекта на части (этапы, итерации) и прохождение

Итерационная модель Итерационная модель предполагает разбиение проекта на части (этапы, итерации) и
этапов жизненного цикла на каждом их них. Каждый этап является законченным сам по себе, совокупность этапов формирует конечный результат.
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробные требования.

Слайд 26

Преимущества итерационной модели:
Быстрый выпуск минимального продукта даёт возможность оперативно получать обратную связь

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

Слайд 27

Инкрементная модель

Принцип, который лежит в основе инкрементной модели, подразумевает расширение возможностей, достраивание

Инкрементная модель Принцип, который лежит в основе инкрементной модели, подразумевает расширение возможностей,
модулей и функций приложения.
Буквальный перевод слова инкремент: «увеличение на один». Это «увеличение на один» применяется в том числе для обозначения версий продукта.
Если в каскадной модели по сути есть два состояния продукта: «ничего» и «готовый продукт», то с появлением итерационных моделей стало применяться версионирование продукта.

Слайд 28

Преимущества инкрементной модели:
Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает

Преимущества инкрементной модели: Не нужно вкладывать много денег на начальном этапе. Заказчик
создание основных функций, получает продукт, «выкатывает» его на рынок – и по итогам обратной связи решает, продолжать ли разработку.
Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.
Недостатки инкрементной модели:
Отсутствие гибкости, как и в случае с каскадной моделью. Вносить изменения на поздних этапах будет трудно и дорого.
Сама разработка начинается строго с началом соответствующей стадии, то есть, никаких прототипов на ранних этапах не разрабатывается.
Контроль рисков затруднен: нет определённого способа решения критических проблем, обнаруженных на этапе тестирования.

Слайд 29

Итерационная модель

Инкрементная модель

Итерационная модель Инкрементная модель

Слайд 30

Спиральная модель

Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию

Спиральная модель Отличительной особенностью этой модели является специальное внимание рискам, влияющим на
жизненного цикла.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нём уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
определение целей;
оценка и разрешение рисков;
разработка и тестирование;
планирование следующей итерации.

Спиральная модель

Слайд 31

Гибкая методология разработки

Гибкая методология разработки (англ. agile software development) – обобщающий термин

Гибкая методология разработки Гибкая методология разработки (англ. agile software development) – обобщающий
для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения (Agile Manifesto) и 12 принципах, лежащих в его основе.
Ценности Agile Manifesto

Слайд 32

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

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

Слайд 33

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

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

Слайд 34

Преимущества и недостатки Agile

Главные достоинства Agile – быстрота, адаптивность и фокус на

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

Слайд 35

Недостатки Agile являются прямым следствием его достоинств:
снижение важности регламентирующей и технической документации

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

Слайд 36

Методология Scrum

Методология Scrum – это набор правил для организации гибкого рабочего процесса,

Методология Scrum Методология Scrum – это набор правил для организации гибкого рабочего
который заключается в командном подходе, работе итерациями, фокусировке на цели каждой итерации и нестандартном распределении обязанностей внутри коллектива.
Scrum — итеративный подход. Итерации называются «спринтами», их длительность определяется на старте проекта и фиксирована до конца. Обычно спринты длятся от двух до четырех недель (очень редко — одну неделю). Чем они короче, тем легче работать с изменениями.
В классической методологии Scrum существуют 3 базовых роли:
Product owner – представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
Scrum master – роль, которая обеспечивает эффективную реализацию методики Scrum.
Development team – это люди, выполняющие работу. Сперва можно подумать, что под командой разработчиков подразумеваются только программисты, но это не так. Согласно руководству по Scrum, команда разработчиков может состоять из людей самых разных профессий, в том числе дизайнеров, тестировщиков, программистов и т. д.

Слайд 38

User story (пользовательская история) – это короткое, понятное всем описание того, какая

User story (пользовательская история) – это короткое, понятное всем описание того, какая
функция или свойство требуется продукту.

Слайд 40

Артефакты Scrum

Product Backlog (также называется общим бэклогом, глобальным бэклогом, или просто бэклогом)

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

Слайд 41

Sprint Backlog – это список задач, которые команда должна выполнить за один

Sprint Backlog – это список задач, которые команда должна выполнить за один спринт.
спринт.

Слайд 43

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

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

Слайд 44

Scrum meetings

Sprint planning meeting
На этом митинге решается судьба спринта. На нём присутствуют

Scrum meetings Sprint planning meeting На этом митинге решается судьба спринта. На
Scrum-мастер, Product Owner и команда разработки. Владелец продукта рассказывает, какой результат хочет видеть в конце спринта. Разработчики выясняют нужные моменты во избежание миллиона вопросов, которые могут появиться в процессе. Команда разбирается с нагрузкой. Исходя из всего этого определяется цель спринта. Так проходит первая часть митинга. Во второй части команда составляет спринт бэклог – задачи, которые нужно реализовать.
Длительность митинга зависит от длительности спринта. На собрание по планированию выделяется по 2 часа на каждую неделю в спринте. Если определяем, что спринты будут длиться 2 недели, то на планирование нужно выделить 4 часа.

Слайд 45

Daily Scrum Meeting
Ежедневное собрание, которое помогает синхронизироваться членам команды. Именно синхронизироваться, а

Daily Scrum Meeting Ежедневное собрание, которое помогает синхронизироваться членам команды. Именно синхронизироваться,
не пожаловаться, похвастаться или обвинить всех в этом мире.
Вопросы, которые хоть и повторяются из митинга в митинг, но которые очень помогают понять текущую ситуацию по прогрессу:
Что было сделано?
Что запланировано?
Есть ли проблемы, и что может помочь?

Слайд 47

Sprint review meeting
Всё, что происходило в спринте, было ради этого. Ревью –

Sprint review meeting Всё, что происходило в спринте, было ради этого. Ревью
двигатель дальнейшего прогресса. Команда разработки наглядно показывает, что было сделано за спринт.
Если показать невозможно, то объясняют, как говорится, на пальцах. Такое бывает, когда сделаны технические задачи, которые продемонстрировать не получится, но без которых ничего или не будет работать, или будет, но плохо. После формируются предложения, мнения, жалобы и видение дальнейшего развития. Всё это берется в расчет на следующий спринт.

Слайд 48

Sprint review meeting
Команда собирается, чтобы выяснить:
Что было хорошо?
Что было плохо?

Sprint review meeting Команда собирается, чтобы выяснить: Что было хорошо? Что было

Что можно улучшить?
Ретро проводится в последний день спринта. Не существует каких-то четких временный рамок. Обычно на этот митинг потребуется 45 минут, умноженные на количество недель в спринте.

Слайд 50

Методология Kanban

Методология Kanban – это система постановки задач, при которой все этапы

Методология Kanban Методология Kanban – это система постановки задач, при которой все
проекта визуализируются на специальной доске. Члены команды могут видеть текущее состояние задачи на любой момент времени. Это предполагает полную прозрачность работы.
Имя файла: 02_Методологии_разработки_ПО_Agile,_Waterfall,_и_другие.pptx
Количество просмотров: 55
Количество скачиваний: 1