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

Версия от 11:08, 13 ноября 2015; Admin (обсуждение | вклад) (Новая страница: «Практика (practice) — это описание того, как справиться с каким-то отдельным аспектом (но не в…»)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

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

[[Категория:Дисциплины|Дисциплина = набор альф, уровень учебника (”дисциплина грузится в голову”).

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

Практика = дисциплины + технология.

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

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

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

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

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

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

Подкатегории

В этой категории отображается 2 подкатегорий из имеющихся 2.

Комментарии