Категория:Практики

Практика (practice) — основа описания деятельности, без привязки деятельности ко времени и без привязки деятельностей друг к другу. Практика это описание того, как справиться с каким-то отдельным аспектом (но не всеми!) дисциплин инженерного проекта.

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

Практика для какой-то цели:

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

Практики (processes) в ISO 15288

Стандарт устанавливает практики ЖЦ, которые должны выполняться:

• всегда,
• итерационно,
• рекурсивно.

Метод

см. Метод

Практики объединяются (composition) в другие практики, чтобы охватить больше аспектов. Когда результат такого объединения практик охватывает все аспекты проекта, тогда это уже метод. По-русски чаще всего описание практики оформляют в виде “методических рекомендаций”, “методики”.

Практики, которые составляют метод, должны удовлетворять свойствам:

• однородности (coherency): достижение цели каждой практики даёт вклад в достижение цели всего метода.
• связности (consistency): каждый вход (entry) и результат (result) взаимосвязаны и используются.
• полноты (completeness): достижение целей всех практик означает достижение цели метода и достигает ожидаемого результата.

Эти свойства в начале создания (authoring) метода почти никогда не присутствуют, любой проект начинает набирать практики своего метода по мере понимания ситуации. Каждый проект должен получить свой метод, ни один метод не работает для разных проектов. Так, если проект небольшой, то работа с требованиями может проходить с использованием практики user story, если проект большой, то необходимо уже использовать практику Use Case. Если нужно вести какие-то списки, то “в ворде” можно справиться с текстовым списком не более чем на 400 элементов, а если элементов списка больше, то для его ведения нужно уже использовать какие-то другие практики — другие технологии (базу данных, например), хотя дисциплина ведения списка может остаться той же самой.

"Метод" существенно отличается от "процесса": метод включает в себя всё нужное для выполнения работы:

• продукты (артефакты),
• процессы (жизненные циклы и используемые в них практики),
• организацию (люди и инструменты),
• используемые в работе языки и нотации.

Тем самым "процесс" -- это маленькая (хотя и важная) часть от "метода".

Тем не менее, в англоязычной литературе имеются синонимы для "метода", использующие слово "процесс" с уточнениями: "development process", "delivery process", "software process". Во всех этих случаях слово "процесс" используется для указание на весь жизненный цикл разработки в целом, а не на пошаговое исполнение какой-то последовательности действий.

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

Задача метода - дать исполнителям полное знание о том, что, когда, как и с чем делать.

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

см. также Ситуационная инженерия методов