Принципы XP. Трудности при практическом внедрении XP
Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающаяся в проверке одним программистом кода, написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный код.
Принципы XP
· Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое – 1-2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.
· Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.
· Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении XP методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве – в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.
· Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
· Достаточная степень смелости и желание идти на риск.
Проблемы:
непонимание менеджментом необходимости внедрения процессного подхода как идеологии; •
неготовность к серьезным изменениям в структуре управления компанией (и в организационной структуре); •
построение системы процессов, неадекватной реальному бизнесу компании; •
непонимание того, зачем нужна регламентация процессов и как правильно это делать; •
ошибки при создании системы показателей, увязке процессов и показателей; •
отсутствие необходимого терпения, желания и ресурсов, необходимых для реальной оптимизации процессов; •
неумение организовать управление процессами; •
3. Главные идеи Scrum. Качественное описание методологии.
| Методология Scrum | гибкая методология разработки программного обеспечения, которая представляет собой итеративный процесс. |
| Рабочий элемент | запись, которая создается в Visual Studio Team Foundation Server для задания определения, назначения, приоритета и состояния элемента работы. |
| Элементы задела работы продукта | список пользовательских требований, которые определяют функциональность продукта, в методологии Scrum. |
| Элемен тработы | краткое описание функций продукта, в методологии Scrum. |
| Спринт | набор задач, запланированных на выполнение определенный период времени, в методологии Scrum. |
| Владелец продукта | член Scrum-команды, который отвечает за всё, что связано с потребительскими качествами программного продукта. |
| Руководитель | член Scrum-команды, который отвечает за состояние и координацию проекта, продуктивность команды и устранение препятствий, мешающих проекту. |
| Член команд | член Scrum-команды, который наравне с другими членами команды отвечает за разработку программного продукта высокого качества. |
| Невыполненная работа по продукту | список элементов работы (пользовательских описаний функциональности), которые необходимо выполнить при создании программного продукта. |
| Незаконченная работа | список элементов работы планируемого спринта. |
Методология Scrum представляет собой итеративный процесс разработки программного обеспечения [43]. При такой разработке для программного продукта создается много последовательных выпусков, в которых постепенно добавляется требуемая функциональность. Итеративный подход позволяет по завершению текущего итерации продемонстрировать заказчику работоспособный программный продукт, возможно с ограниченной функциональностью, получить отзыв, замечания и дополнительные требования, которые будут учтены в следующих итерациях. Основными артефактами в методологии Scrum являются рабочие элементы, отчеты, книги и панели мониторинга
Scrum (/skrʌm/[1][2]; англ. scrum «схватка») — методология гибкой разработки ПО. Методология делает акцент на качественном контроле процесса разработки.
Кроме управления проектами по разработке ПО, Scrum может также использоваться в работе команд поддержки программного обеспечения, или как подход к управлению разработкой и сопровождению программ: Scrum of Scrums.
4.Спецификация требований
Спецификация требований программного обеспечения (англ. Software Requirements Specification, SRS) — законченное описание поведения программы, которую требуется разработать.
Включает ряд пользовательских сценариев (англ. use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям, спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества, или проектные ограничения).
· Введение
· Цели
· Соглашения о терминах
· Предполагаемая аудитория и последовательность восприятия
· Масштаб проекта
· Ссылки на источники
· Общее описание
· Видение продукта
· Функциональность продукта
· Классы и характеристики пользователей
· Среда функционирования продукта (операционная среда)
· Рамки, ограничения, правила и стандарты
· Документация для пользователей
· Допущения и зависимости
· Функциональность системы
· Функциональный блок X (таких блоков может быть несколько)
· Описание и приоритет
· Причинно-следственные связи, алгоритмы (движение процессов, work flows)
· Функциональные требования
· Требования к внешним интерфейсам
· Интерфейсы пользователя (UX)
· Программные интерфейсы
· Интерфейсы оборудования
· Интерфейсы связи и коммуникации
· Нефункциональные требования
· Требования к производительности
· Требования к сохранности (данных)
· Критерии качества программного обеспечения
· Требования к безопасности системы
· Прочие требования
Идентификация риска
Идентификация рисков – это выявление рисков, способных повлиять на проект, и документальное оформление их характеристик. Это итеративный процесс, который периодически повторяется на всем протяжении проекта, поскольку в рамках его жизненного цикла могут обнаруживаться новые риски.
В качестве источника информации при выявлении рисков могут служить различные доступные контрольные списки рисков проектов ранее разработанных, которые следует проанализировать на применимость к данному конкретному проекту.
Идентификация риска заключается в систематическом выявлении и изучении рисков, которые характерны для данного вида деятельности.
Идентификация начинается с определения опасностей, угрожающих данному предприятию. Опасность — понятие, схожее с риском, но все же отличное от него. Опасность — это сочетание обстоятельств, которые могут вызвать негативные последствия. Риск — ве-
вероятность того, что это произойдет. Иначе говоря, риск — это просчитанный потенциал ущерба, который заключает в себе опасность для данного лица. Между опасностью и риском находятся события или действия, которые являются своеобразным механизмом реализации риска.
Таким образом, для идентификации рисков необходимо изучение всех компонентов, их сопровождающих:
опасностей, которые могут привести к неблагоприятному результату;
- ресурсов предприятия, которые могут пострадать от рисков;
факторов, увеличивающих или уменьшающих вероятность реализации рисков;
ущербов, в которых выражается воздействие риска на ресурсы.
В состав ресурсов предприятия входят имущество, кадры, денежный капитал. При этом для каждой группы ресурсов выделяются свои специфические риски. Например, для имущественного блока характерны традиционные риски, связанные с опасностью огня, стихийных бедствий, кражи. Но наряду с ними возрастает опасность технологических и технических рисков, связанных с отказами техники, прерыванием технологических процессов, воздействием новых технологий. К имущественному блоку ресурсов тяготеют также риски нарушения условий материального обеспечения производства, связанные с его закрепленностью за ограниченными источниками сырья и сбоями в производственной кооперации.
Риски по кадровой составляющей ресурсов предприятия включают потенциальные ущербы двух видов.
Во-первых, это ответственность работодателя по вопросам охраны труда и претензиям, поступающим в адрес его рабочих и служащих со стороны потребителей. Во-вторых, это внешние риски, касающиеся жизни и здоровья отдельных групп сотрудников и связанные с исполнением ими своих служебных обязанностей.
Капитальная составляющая ресурсов включает в себя риски ответственности и финансовые риски, выходящие за пределы ответственности предпринимателя. Риски ответственности представляют собой риски финансовых потерь, вызванных гражданской ответственностью предприятия за качество продукции, за экологическую безопасность используемых технологий. Собственно финансовые риски связаны с непредвиденными убытками, наступающими вследствие простоя предприятия, неплатежеспособностью покупателя продукции, превышением стоимости проекта над согласованной в контракте, наконец, просто с мошенничеством и обманом, не столь уж редкими в предпринимательской деятельности.
Совместное воздействие всех этих факторов определяет потенциал результирующих убытков и те затраты, которые может нести организация в случае их осуществления.
Для идентификации рисков необходима информация, которую можно получать различными способами, включая их комбинации (рис. 3.4).
Ранжирование рисков
представляет собой самый простой анализ рисков. Суть этого метода-заключается в обследовании рисков с точки зрения их количественных характеристик, с тем чтобы выявить, какие из них более серьезны по размерам возможного ущерба, а какие — менее серьезны, какие более вероятны, какие — менее.
В результате использования даже таких достаточно простых методов можно построить матрицу рисков и перейти к решению вопроса о контроле над ними.
Один из самых важных моментов в оценке риска — группировка рисков по соотношению размеров возможного ущерба и частотности. Это соотношение обычно представляется треугольником рисков (рис. 3.5).
Рис. 3.5. Треугольник Хайнрича (группировка рисков по серьезности ущербов и их частоте)
Самый низкий уровень представлен наиболее частыми ущербами, небольшими по размерам. Средний уровень — убытки менее частые, но более серьезные по размерам. Верхний слой — катастрофические, достаточно редкие ущербы. Если в отношении первых двух типов ущербов предприятие может полагаться на собственные возможности покрытия, то это невозможно при катастрофических ущербах. Их серьезность ставит под угрозу сохранение предприятия, и финансовые ресурсы для ликвидации последствий ущерба могут быть найдены только на основе внешнего страхования. Поэтому для предприятия полезна даже самая простая количественная оценка рисков.
Вероятность и серьезность ущербов оценивается по шкале коэффициентов, которые могут определяться экспертами на базе прошлого опыта.
Наряду с обычной оценкой вероятности по возможности следует учитывать годовую частотность рисков. Это важно для определения финансовых источников покрытия ущербов.
Серьезность ущербов оценивается баллами от 0 до 10. За середину шкалы — 5 баллов — принимается уровень убытков, размеры ниже которых не оказывают существенного негативного влияния на годовые итоги деятельности компании. По значительной части имущественных рисков может быть дана денежная оценка ущерба.
Планирование управления риском
Управление рисками это определенная деятельность, которая выполняется в проекте от его начала до завершения. Как и любая другая работа в проекте управление рисками требует времени и затрат ресурсов. Поэтому эта работа обязательно должна планироваться. Планирование управления рисками — это процесс определения подходов и планирования операций по управлению рисками проекта. Тщательное и подробное планирование управления рисками позволяет:
· выделить достаточное количество времени и ресурсов для выполнения операций по управлению рисками,
· определить общие основания для оценки рисков,
· повысить вероятность успешного достижения результатов проекта.
Планирование управления рисками должен быть завершено на ранней стадии планирования проекта, поскольку оно крайне важно для успешного выполнения других процессов.
В соответствии с исходными данными для планирования управления рисками служат:
· Отношение к риску и толерантность к риску организаций и лиц, участвующих в проекте, оказывает влияние на план управления проектом. Оно должно быть зафиксировано в изложении основных принципов и подходов к управлению рисками.
· Стандарты организации. Организации могут иметь заранее разработанные подходы к управлению рисками, например категории рисков, общие определение понятий и терминов, стандартные шаблоны, схемы распределения ролей и ответственности, а также определенные уровни полномочий для принятия решений.
· Описание содержания проекта подробно описывает результаты поставки проекта и работы, необходимые для создания этих результатов поставки.
· План управления проектом, формальный документ, в котором указано, как будет исполняться проект и как будет происходить мониторинг и управление проектом.
План управления рисками обычно включает в себя следующие элементы:
· Определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте.
· Распределение ролей и ответственности. Список позиций выполнения, поддержки и управления рисками для каждого вида операций, включенных в план управления рисками, назначение сотрудников на эти позиции и разъяснение их ответственности.
· Выделение ресурсов и оценка стоимости мероприятий, необходимых для управления рисками. Эти данные включаются в базовый план по стоимости проекта.
· Определение сроков и частоты выполнения процесса управления рисками на протяжении всего жизненного цикла проекта, а также определение операций по управлению рисками, которые необходимо включить в расписание проекта.
· Категории рисков. Структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации. Такую структуру можно разработать с помощью составления иерархической структуры рисков (Рисунок 25).
· Общие подходы для определения уровней вероятности, шкалы воздействия и близости рисков на проект.
Рисунок 25. Пример иерархической структуры рисков проекта
Шкала оценки воздействия отражает значимость риска (Таблица 2) в случае его возникновения. Шкала оценки воздействия может различаться в зависимости от потенциально затронутой риском цели, типа и размера проекта, принятыми в организации стратегиями и его финансовым состоянием, а также от чувствительности организации к конкретному виду воздействий.
Еще одной важной характеристикой риска является близость его наступления. Естественно, что при прочих равных условиях рискам, которые могут осуществиться уже завтра, следует сегодня уделять больше внимания, чем тем, которые могут произойти не ранее, чем через полгода. Для шкалы оценки близости риска может быть применена, например, следующая градация: очень скоро, не очень скоро, очень нескоро.
Методика управления рисками
Для получения перечня проектных рисков руководитель проекта или риск-менеджер может воспользоваться следующими методами:
1. Использование базы известных рисков. Поскольку на выходе каждого проекта имеется отчёт о выполнении, частью которого должно быть описание рисков проекта, все такие описания в конечном итоге собираются в централизованной базе рисков, которую можно использовать как первичный источник для наполнения перечня рисков для конкретного проекта. Ответственный за управление рисками просматривает базу рисков и выбирает из неё те записи, которые применимы к текущему проекту.
2. Мозговой штурм проектной команды. Ответственный за управление рисками собирает всю проектную команду (единоразово или на периодической основе в целях пересмотра перечня рисков) и проводит мозговой штурм на тему «Риски проекта». Данный метод позволит учесть риски, видимые с точки зрения аналитиков, проектировщиков, разработчиков, тестировщиков и других ролей в проектной команде, которые могут быть не видны руководству.
3. Диверсионный анализ. Специально приглашённые эксперты или участники проектной команды ставят себя на место «злоумышленников» (заказчика, аудиторов, ревизоров, государственных органов регулирования и т. д.) и пытаются с этой точки зрения посмотреть на то, каким образом можно навредить проекту. Данный метод может совмещаться с мозговым штурмом.
4. STEEP-анализ. Если применимо, то ответственный за управление рисками может использовать анализ окружения проекта по пяти категориям: социальные, технологические, экономические, экологические и политические факторы. Впрочем, для конкретных проектов может быть применима только часть перечисленных факторов, равно как и найтись иные факторы (например, правовые, кадровые и т. д.).
5. Метод Дельфи. Взамен мозгового штурма проектной команды можно воспользоваться методом Дельфи. Для этих целей необходимо привлечь достаточное количество экспертов (от 10 до 20) из разных областей и аспектов, касающихся проекта. Желательно привлечение независимых экспертов, в этом случае результаты станут более объективными. Все эксперты должны работать независимо друг от друга и сдавать свои ответы в письменном виде. Ответственный за управление рисками координирует деятельность экспертов, структурирует их ответы, готовит промежуточные и окончательный результаты работы экспертной группы.
6. Карточки Кроуфорда. Если проведение исследований рисков методом Дельфи нецелесообразно для проекта, то можно использовать так называемые карточки Кроуфорда, для работы с которыми привлечь от 5 до 10 экспертов. Каждый эксперт должен десять раз ответить на вопрос ответственного за управление рисками «Какой риск является наиболее важным в этом проекте?», при этом каждый эксперт работает независимо, и ответы одного эксперта не должны повторяться. После сбора всех карточек ответственный за управление рисками проводит анализ, структуризацию, классификацию и составление перечня рисков.
Данный список методов не является полным, и руководитель проекта или риск-менеджер может использовать весь свой опыт и знания для составления перечня рисков.