Czytaj książkę: «Системный аналитик за неделю»

Глава 1. Основы профессии: кто такой системный аналитик.

Кто же такой системный аналитик? Какова его роль в компании? Какими soft и hard skills должен обладать?

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

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

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

Задача аналитика — это превращение информационного хаоса в организованную систему , а идей заказчика в прототип будущего проекта.

Ключевые обязанности, определяющие роль системного аналитика:

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

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

Тестирование и обеспечение качества: Системные аналитики обеспечивают соответствие разработанных систем указанным требованиям, проводя комплексное тестирование. Они сотрудничают с командами разработчиков для выявления и исправления любых дефектов программного обеспечения перед развертыванием.

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

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

Hard skills.

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

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

Языки программирования: Знание таких языков программирования, как Java, C++, Python или SQL, необходимо для понимания и разработки эффективных программных решений.

Управление базами данных: Умение проектировать и управлять базами данных имеет решающее значение для эффективного анализа и хранения данных.

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

Сеть: Для устранения неполадок и обслуживания сетевых инфраструктур необходимо хорошее понимание сетевых принципов и протоколов.

Жизненный цикл разработки программного обеспечения (SDLC): знакомство с методологиями SDLC, такими как Agile или Waterfall, важно для управления и реализации успешных проектов.

Soft skills

Soft skills важны для системного аналитика, чтобы преуспеть в своей роли. Soft skills для продвижения в роли системного аналитика:

Решение проблем: Системные аналитики часто сталкиваются со сложными проблемами, требующими аналитического мышления и творческого решения проблем. Способность разбивать сложные проблемы на части и разрабатывать эффективные решения имеет решающее значение.

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

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

Управление временем: определение приоритетов задач и эффективное управление временем имеют решающее значение для соблюдения сроков выполнения проектов и своевременной поставки решений.

Внимание к деталям: системные аналитики должны обращать внимание даже на самые мелкие детали, чтобы обеспечить точность и надежность своей работы.

Способности решения проблем: Системные аналитики сталкиваются со сложными проблемами. Их навыки решения проблем позволяют им творчески подходить к препятствиям и разрабатывать инновационные решения.

Деловая хватка: Понимание бизнес-процессов, стратегий и целей имеет решающее значение для системных аналитиков. Эти знания помогают им согласовывать технологические решения с организационными целями.

Преимущества системного аналитика для бизнеса:

Повышение эффективности: Системные аналитики оптимизируют бизнес-процессы, выявляя неэффективность и внедряя эффективные решения. Это приводит к повышению производительности, снижению затрат и повышению общей эффективности.

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

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

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

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

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

Успех в работе преуспевающего аналитика это:

50% технические навыки. Не останавливайтесь на месте в своем образовании, чтобы идти в ногу со временем и быть успешным на пути к карьере системного аналитика;

50% коммуникация. Учитесь коммуницировать с коллегами и стейкхолдерами, так как это половина успеха преуспевающего аналитика

Глава 2. Процесс разработки ПО. Waterfall. Системный анализ в Agile командах

Что такое разработка программного обеспечения?

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

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

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

Жизненный цикл разработки программного обеспечения (SDLC) — это пошаговый процесс, который команды разработчиков используют для создания высококачественного, экономически эффективного и безопасного программного обеспечения. Несмотря на множество нюансов, жизненный цикл разработки программного обеспечения обычно складывается из перечисленных ниже типичных этапов:

- Планирование и анализ

- Разработка дизайна

- Выполнение (построение модели, кода)

- Тестирование

- Развертывание

- Обслуживание(оптимизация, документация)

Планирование и анализ

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

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

Разработка дизайна

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

Построение модели

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

Построение кода

Используя знания, полученные в результате моделирования, команды разработчиков программного обеспечения начинают писать код, который превращает проекты в функционирующий продукт. Традиционно написание кода — это ручной процесс, но организации все чаще используют искусственный интеллект (ИИ) для помощи в генерации кода и ускорения процесса разработки.

Тестирование

Обеспечение качества (QA) выполняется для проверки дизайна программного обеспечения. Тесты ищут недостатки в коде и потенциальные источники ошибок и уязвимостей безопасности. Команды DevOps используют автоматизированное тестирование для непрерывного тестирования нового кода на протяжении всего процесса разработки.

Развертывание

Интеграция, развертывание или выпуск программного обеспечения означает, что программное обеспечение становится доступным для пользователей. Развертывание включает в себя настройку конфигураций базы данных и сервера, закупку необходимых ресурсов облачных вычислений и мониторинг производственной среды. Команды разработчиков часто используют решения «инфраструктура как код» (IaC) для автоматизации предоставления ресурсов. Такая автоматизация помогает упростить масштабирование и сократить расходы.

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

Оптимизация

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

Документация

Ведение подробного учета процесса разработки ПО помогает разработчикам и пользователям устранять неполадки и использовать приложения. Оно также помогает поддерживать ПО и разрабатывать протоколы тестирования.

Модели разработки программного обеспечения

Модели разработки ПО — это подход или метод, который команды используют для разработки ПО.

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

Рассмотрим наиболее распространенные модели разработки программного обеспечения.

Waterfall Model.

Waterfall — это традиционная модель разработки программного обеспечения, которая устанавливает ряд каскадных линейных шагов от планирования и сбора требований до развертывания и обслуживания. В подходе «The Waterfall» весь процесс разработки программного обеспечения делится на отдельные фазы. В каскадной модели , как правило, результат одной фазы выступает в качестве входных данных для следующей фазы последовательно.

Основные принципы каскадной методологии.

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

2. Строгая проектная документация. Каждый этап разработки подробно описан в проектной документации. Каскадной модели присуще строгое следование намеченному плану;

3. Жесткая последовательность этапов. Каскадная модель запрещает пропуск этапов, либо возвращение к предыдущим этапам;

4. Любые изменения должны быть согласованы с заказчиком и задокументированы;

5. Тестирование и выявление ошибок происходит только после окончания разработки;

После утверждения ТЗ, заказчик не участвует в процессе создания продукта.

Этапы Waterfall Model:

1. Сбор и анализ требований (Planning and Requirements Analysis) . В рамках этого этапа осуществляется сбор и документирование требований к программному продукту в документе спецификации требований. Этап включает в себя общение с заказчиком и конечными пользователями для понимания их потребностей.

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

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

4. Тестирование и интеграция (Testing & Deployment). В рамках этого этапа происходит проверка качества программного продукта с помощью различных видов тестирования, включая модульное, интеграционное, функциональное и другие виды. После тестирования ПО выпускается в продакшн. Оно устанавливается на целевой сервер или распространяется конечным пользователям.

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

Каждый этап следует строго один за другим, без возврата на предыдущие стадии.

Основные преимуществ каскадной модели:

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

Легко управлять благодаря жесткости модели. Каждая фаза имеет определенные результаты и процесс обзора.

Фазы обрабатываются и завершаются по одной за раз.

Хорошо подходит для небольших проектов, где требования хорошо понятны.

Четко определенные этапы.

Процесс и результаты хорошо документированы.

Основные недостатки каскадной модели:

Рабочее программное обеспечение создается только на поздних этапах жизненного цикла.

Неподходящая модель для длительных и сложных проектов.

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

Трудно измерить прогресс на отдельных этапах.

Невозможность удовлетворить меняющиеся требования.

Корректировка объема работ в течение жизненного цикла может привести к завершению проекта.

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

Waterfall подойдёт, если:

Заказчик хорошо понимает, что хочет. У него есть проработанная концепция, которая не изменится.

Заказчик хочет заранее знать точные сроки и результаты каждого этапа.

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

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

Команда уже делала аналогичный проект.

Agile

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

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

Ценности Agile:

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

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

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

Это не значит «работать по Agile — работать без документов». В agile-командах тоже есть документация, но на неё не тратят огромное количество времени и ресурсов.

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

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

Даже если есть план проекта, в него, почти наверняка, со временем придётся внести изменения — в этом суть Agile.

Основополагающие принципы Agile-манифеста:

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

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

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

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

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

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

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

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

Постоянное внимание к техническому совершенству и качествупроектирования повышает гибкость проекта.

Простота — искусство минимизации лишней работы — крайне необходима.

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

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

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

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

Методология agile появилась в 2001 году, когда был издан Манифест Agile. С тех пор появилось множество agile-платформ, таких как Scrum, Kanban, бережливое производство и экстремальное программирование (XP). В основе каждой из этих платформ лежат главные принципы методологии agile: работа частыми итерациями, непрерывное обучение и обеспечение высокого качества. Scrum и XP пользуются популярностью среди команд разработчиков, а Kanban предпочитают команды, ориентированные на оказание услуг, например ИТ-отделы или отделы кадров.

Остановимся на Scrum и Kanban.

Scrum.

Scrum — это методика гибкого управления проектами, которая помогает командам структурировать свою работу и управлять ею с помощью набора ценностей, принципов и практик.

В основе определения Scrum лежат эмпирический подход и бережливое мышление. Эмпирический подход предполагает, что знания приходят из опыта, а решения принимаются на основе наблюдений. Бережливое мышление сокращает потери и сосредотачивается на главном. Методика Scrum по своей сути является эвристической. В ней центральное место занимают постоянное обучение и адаптация к изменчивым факторам. Согласно Scrum, команда не знает всего в начале проекта, но будет развиваться, извлекая уроки из опыта. В структуре Scrum заложена та свобода, с которой команды приспосабливаются к меняющимся условиям и требованиям пользователей. Рабочий процесс предусматривает изменение приоритетов и короткие циклы релизов, что способствует постоянному обучению и совершенствованию команды.

Участники scrum-команды.

Состав scrum-команды предполагает три конкретные роли: владелец продукта, scrum-мастер и команда разработчиков.

Владелец продукта Scrum.

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

О владельцах продукта можно сказать следующее:

- Они формируют бэклог продукта.

- Они тесно сотрудничают с руководством компании и командой, чтобы все понимали значение рабочих задач в бэклоге.

- Они дают команде четкие указания, какие функциональные возможности продукта внедрить следующими.

- Они решают, когда поставлять продукт, стремясь делать это чаще.

Scrum-мастер

Scrum-мастера следят за применением принципов Scrum в своих командах. Они обучают команды, владельцев продуктов и остальную компанию тонкостям scrum-процесса и стараются оптимизировать применение этой практики.

Команда разработчиков Scrum

На scrum-команды ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные scrum-команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос: в команде должно быть столько участников, чтобы им хватало двух пицц.

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

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

Артефакты Scrum

Артефакты Scrum — это важная информация, используемая scrum-командой при описании продукта и работы, необходимой для его создания. В Scrum существует три артефакта: бэклог продукта, бэклог спринта и инкремент с вашими критериями готовности.

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

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

Инкремент (или цель спринта) — это пригодный для использования конечный продукт по итогам спринта. Его часто определяют как принятые в команде критерии готовности продукта, контрольную точку, цель спринта.

Церемонии Scrum

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

Спринт. Это фактический промежуток времени, в течение которого scrum-команда совместно работает над созданием инкремента. Спринт длится от 1 до 4 недель.

2. Ежедневное scrum-совещание, или стендап. Это короткое ежедневное собрание, которое для удобства проводится в одно время (как правило, утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, однако это лишь рекомендация. Такое собрание еще называют ежедневным стендапом, что подчеркивает его краткость. Ежедневное scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, помнил о цели спринта и располагал планом работы на ближайшие сутки.

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

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