0% нашли этот документ полезным (0 голосов)
46 просмотров6 страниц

Qa Lecture2

Документ описывает основные аспекты IT-проектов, включая их характеристики, управление проектами и роли участников. Также рассматриваются методологии Agile и Scrum, их принципы и структура, а также ключевые термины в IT-сфере. Важное внимание уделяется процессам управления проектами и взаимодействию между участниками для достижения успешных результатов.

Загружено:

belo4kaaly
Авторское право
© © All Rights Reserved
Мы серьезно относимся к защите прав на контент. Если вы подозреваете, что это ваш контент, заявите об этом здесь.
Доступные форматы
Скачать в формате PDF, TXT или читать онлайн в Scribd
0% нашли этот документ полезным (0 голосов)
46 просмотров6 страниц

Qa Lecture2

Документ описывает основные аспекты IT-проектов, включая их характеристики, управление проектами и роли участников. Также рассматриваются методологии Agile и Scrum, их принципы и структура, а также ключевые термины в IT-сфере. Важное внимание уделяется процессам управления проектами и взаимодействию между участниками для достижения успешных результатов.

Загружено:

belo4kaaly
Авторское право
© © All Rights Reserved
Мы серьезно относимся к защите прав на контент. Если вы подозреваете, что это ваш контент, заявите об этом здесь.
Доступные форматы
Скачать в формате PDF, TXT или читать онлайн в Scribd

IT-проекты

Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг
или результатов.
IT - проект – это проект в сфере создания, внедрения или применения информационных
технологий.
Все проекты обладают определенным набором свойств:
1.​ Временная ограниченность проекта
У любого проекта есть четкое начало и четкое завершение. Завершение наступает, когда
выполняется одно из условий:
-​ достигнуты цели проекта;
-​ осознано, что цели проекта не будут или не могут быть достигнуты;
-​ исчезла необходимость в проекте .
Большинство проектов предпринимается для достижения устойчивого, длительного
результата.
2.​ Уникальность результатов
3.​ Последовательная разработка
Последовательная разработка означает развитие проекта по этапам и протекание по
шагам.
Например, для проекта создания информационной системы (ИС) некоторого предприятия
можно выделит следующие этапы:
− Обследование предприятия и построение его функциональной модели.
− Составление технического задания.
− Проектирование ИС.
− Реализация ИС средствами некоторой системы программирования.
− Тестирование работоспособности ИС и устранение обнаруженных ошибок.
− Ввод ИС в эксплуатацию и сдача заказчику.
4.​ Выполняется людьми
5.​ Ограничена доступность ресурсов
В качестве ресурсов могу выступать люди, материальные и технические средства.
6.​ Планируются, исполняются и управляются
Примерами IT- проектов являются :
-​ Разработка нового программного продукта;
-​ Разработка новой IT- услуги;
-​ Разработка, приобретение или внедрение новой или усовершенствованной
информационной системы;
По каким причинам инициируются проекты:
-​ требования рынка (создание зомби игрушек, потому что на них есть большой
спрос)
-​ нужды компании (большая компания, нужно написать проект для управления
персоналом)
-​ нужды заказчика (тут все понятно)
-​ технический прогресс (появилась новая приставка PS5 - нужно пилить под нее,
появился телефон с челкой - нужно пилить под него)
-​ требования законодательства (нельзя хранить данные про карточки пользователей -
нужно вынести платежную систему на сторонний ресурс)
Понятие управления проектами
Управление проектами – это приложение знаний, навыков, инструментов и методов к
операциям проекта для удовлетворения предъявляемых к проекту требований .
Управление проектами выполняется при помощи совокупности процессов
управления проектами :
-​ инициации,
-​ планирования,
-​ исполнения,
-​ мониторинга и управления,
-​ завершения.
Менеджер проекта – это лицо, ответственное за достижение целей проекта.
В управление проектом входят:
-​ определение требований;
-​ установка четких и достижимых целей;
-​ уравновешивание противоречащих требований по качеству, содержанию, времени и
стоимости;
-​ коррекция характеристик, планов и подхода в соответствии с мнением и
ожиданиями различных участников проекта.
Менеджеры проектов часто говорят о " тройном ограничении" - содержании проекта,
времени и стоимости, – которое приходится учитывать при согласовании разнообразных
требований проекта.
Качество исполнения проекта зависит от уравновешивания этих трех факторов.
Участники проекта – это лица или организации, активно участвующие в проекте, либо на
чьи интересы могут повлиять результаты исполнения или завершения проекта.
Участники могут влиять на цели и результаты проекта.
Команда управления проектом должна выявить участников проекта, определить их
требования и ожидания и управлять их влиянием, чтобы обеспечить успешное завершение
проекта.
Ключевые участники любого проекта:
-​ Менеджер проекта. Лицо, ответственное за управление проектом.
-​ Заказчик/пользователь. Лицо или организация, которые будут использовать продукт
проекта.
-​ Исполняющая организация. Предприятие, чьи сотрудники непосредственно
участвуют в исполнении проекта.
-​ Члены команды проекта. Группа, которая выполняет работы по проекту
(Developers, QAs. e.g.)
-​ Команда управления проектом. Члены команды проекта, непосредственно занятые
в управлении его операциями (Team Lead).
-​ Спонсор. Лицо или группа лиц, предоставляющая финансовые или материальные
ресурсы для проекта.
Менеджеры проекта должны управлять ожиданиями участников проекта, что может быть
достаточно сложно, так как у участников проекта могут быть разные или
противоположные цели.
Роли в IT
[Link]
Бизнес-аналитик (BA - Business Analysis) — это специалист, который исследует
проблему заказчика, ищет решение и оформляет его концепцию в форме требований, на
которые в дальнейшем будут ориентироваться разработчики при создании продукта.
([Link]
Project Manager — это специалист, чьей главной задачей является управление проектом в
целом: проектирование и расстановка приоритетов, планирование выполнения задач,
контроль, коммуникации, а также оперативное решение проблем.
([Link]

Agile and Scrum


Aджайл — это подход к разработке программ. Философия Aджайл через четыре главные
ценности:

●​ люди и взаимодействия важнее процессов и инструментов;


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

Ценности и принципы Aджайл-манифеста подразумевают адаптацию под каждую


конкретную ситуацию. Поэтому Aджайл находит воплощение в разных фреймворках.
Один из самых популярных среди них — Скрам. Согласно опросу за 2015 год (2015 State
of Scrum Survey Report) от ScrumAlliance, Скрам широко применяется и будет применяться
в разных бизнес-отраслях для успешной разработки различных проектов.

«Скрам — это фреймворк управления, согласно которому одна или несколько


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

«В Скраме есть система ролей, встреч, правил и артефактов. В этой модели за создание и
адаптацию рабочих процессов отвечают команды».

«В Скраме используются итерации фиксированной длины, называемые Спринтами. Они


обычно занимают 1-2 недели (до 1 месяца). Скрам команды стремятся создавать готовый к
поставке (качественно протестированный) Инкремент продукта в каждой итерации».

.([Link]

КАК РАБОТАЕТ СТРУКТУРА СКРАМА


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

РОЛИ В СКРАМЕ
В Скраме три роли, которые вместе образуют Скрам команду:

●​ Владелец Продукта — Этот человек доносит потребности кастомера/стейкхолдера


до Команды разработки, но не отвечает за техническую сторону процесса.
Владелец Продукта также отвечает за пользовательские истории и определяет их
приоритетность.
●​ Команда разработки выполняет все технические задачи по разработке. Команда
кроссфункциональна и отвечает за анализ, дизайн, программирование,
тестирование, техническую коммуникацию и т. д. В этом она руководствуется
пользовательскими историями и их приоритетностью.
●​ Скрам-Мастер помогает Владельцу Продукта и Команде разработки выполнять
работу без препятствий и отвлекающих факторов. Вся коммуникация людей вне
команды с Командой разработки проходит через Скрам-Мастера. (Иногда Скрам
команды взаимодействуют в формате Скрама Скрамов, то есть собрания со
Скрам-мастерами каждой команды).

ВСТРЕЧИ В СКРАМЕ
Есть четыре типа Скрам-мероприятий:

●​ Планирование Спринта (Sprint Planning) — в нём участвуют все члены Скрам


команды. На этом мероприятии презентуют Продукт. Также каждый член команды
может высказаться о том, что его интересует или беспокоит. В ходе встречи
назначаются приоритеты и проводятся оценки сроков.
●​ Ежедневный Скрам (Daily Scrum) — Скрам-мероприятия, которые проходят
ежедневно во время спринтов. Они короткие (до 15 минут) и предназначены для
того, чтобы спланировать дневное расписание Команды разработки. Здесь можно
обсудить рабочие сложности или прояснить пользовательские истории. Встреча
обязательна для Команды разработки в полном составе. Скрам-мастер может на ней
присутствовать.
●​ Обзор Спринта (Sprint Review) — демонстрация действующего продукта,
разработанного во время спринта. Это мероприятие проходит в конце спринта и
предназначено в первую очередь для того, чтобы в подробностях показать
достигнутое стейкхолдерам.
●​ Ретроспектива Спринта (Sprint Retrospective) — это своего рода вскрытие,
обсуждение того, как команда справилась во время спринта и как можно повысить
качество её работы в будущем.

Дополнительно к этим типам мероприятий иногда во время спринта команды могут


проводить уточнение бэклога (Backlog Refinement) — обсуждать элементы бэклога и
готовиться к следующему спринту. В рамках этой встречи можно обсудить
приоритетность элементов и разделить элементы бэклога на более мелкие составляющие.

IT - Словечки

Бэкап (BackUp) — это предварительно созданная копия данных для восстановления в


случае потери оригинальных данных (резервная копия).
Билд (Build) - версионированная сборка программного обеспечения. Представим, что
программист или команда программистов, в течении своей работы решает выпустить
новую версию ПО с какими-то новыми функциями или исправлениями, или просто по
времени (например договорились в пятницу выпустить новую версию). Весь сделанный к
этому моменту код помечается (версионируется), архивируется, тестируется и собирается
(build) в законченный продукт. Это и есть билд.
Дедлайн (Deadline) — последний срок, предельный срок, дата или время, к которому
должна быть выполнена задача.
Settings - настройки
On-Site - работать напрямую на заказчика с другой страны, вместе с ним в офисе.
Off-site - работать на прямую на заказчика или не на прямую с другой страны, но не в
логации заказчика.
Meeting - совещание IT- коллег по любому вопросу.
Refactoring - оптимизация кода написаного программистами или автоматизаторами.
Cancel - отмена.
Reject - отклонить.
Hands-on - доказаный ваш опыт, который вы применяли где-то на проектах.
Valid - правильный, корректный, тот который подходит.
Device - устройство.
Capacity - вместимость.
Specification (spec, спека) - структурированный набор требований (функционал,
производительность, конструктивные ограничения и атрибуты) к программному
обеспечению и его внешним интерфейсам.
Evidence - доказательство.

Вам также может понравиться