Блог Романа Кузьмина

О качестве

2012-02-03T22:44:00.000-08:00

Точнее об управлении качеством в IT проектах

Наивное представление о качестве

Сводится к тому, что есть качественные вещи (и это круто), и есть некачественные (и это ужасно). Надо все делать качественно и все будут счастливы. Применяя такой подход, неизбежно приходишь к выводу, что , спецодежду нужно шить из меха норки, поскольку "качественно". В реальных проектах так никто не поступает

Чуть более продвинутое представление о качестве

Первый шаг к управлению качеством - понять, что

Качество определяется целью. Есть параметры важные для достижения цели, а есть все остальные
Качество измеримо
Для достижения цели не всегда нужно высокое качество

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

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

Если для достижения целей проекта достаточно иметь качество 80% то именно такое качество и надо обеспечивать с самого начала.

Чтобы понять, почему это не всегда так, рассмотрим

Жизненный цикл программной системы

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

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

А значит маленькая и огромная программы с одинаковым уровнем качества 80% - абсолютно не одинаковы с точки зрения стоимости их развития. В первой будет скажем 50 недочетов, а во второй, если она в 100 раз больше их будет уже 5000. Все недочеты влияют друг на друга, создавая множество "степеней свободы". Поэтому, считая сложность системы, нужно не складывать недочеты, а перемножать - рост функции "сложность(количество недочетов)" - экспоненциален. А чем выше сложность - тем больше будет новых недочетов.

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

Можно сказать и проще - программист Вася Пупкин может осмыслить систему если в ней есть не более 50 недочетов. В системе из 100 строк кода 50 недочетов будет соответсовать 50% му качеству. В системе из миилиона строк - 99.995%

Вывод - с ростом сложности и размеров системы планка качества должна повышаться, для достижения тех же показателей затрат.

Но это еще не все. Есть еще

Закон стоимости повышения качества

Который, звучит так "повышать качество намного дороже, чем его поддерживать"

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

Управление качеством

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

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

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

Ступенчатое повышение качества

Обычно мы поступаем так:

Имеем систему из 10000 строк кода. В ней 100 недочетов. Вася Пупкин перестал осознавать эту систему целиком из-за возросшей сложности. Требуется понизить сложность до приемлемого уровня. Вопрос - как это сделать?

Плохой ответ - исправить 50 недочетов.

Хороший ответ - разделить систему на две слабосвязанные подсистемы.

Тогда в каждой будет 50 недочетов и Вася Пупкин, описанный выше, справится со сложностью в обоих случаях.

Почему первый ответ плох -

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

Планирование качества

Планируя качество надо представлять

Срок жизни системы
Ее предполагаемый объем
Целевую функцию затрат на ее создание (какие затраты мы хотим минимизировать)

Исходя из этого можно планировать

Несколько этапов развития системы
Рефакторинг - пересмотр архитектуры системы с дроблением ее на модули в конце каждого этапа
Планку качества, оптимальную для каждого этапа

Зачем нужен план

Совершенно не для того, чтобы с ним сверяться! Все равно все пойдет не так.

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

Он нужен для оценки решений, принимаемых в процессе управления проектом.

Он помогает понять реальную стоимость каждого решения и осознанно ей управлять.

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

P.S. Очевидно, если вы пишете систему управления для атомной станции, реактивного истребителя или чего-то в том же духе, рассуждения будут "несколько" другими :-)

Разработка больших систем. Часть 5. Про хаки и рефакторинг.

2011-07-19T23:16:00.000-07:00

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

Например, при создании программы, где есть пользователи и есть механизм их удаления не вовремя вспомнили, об опасности удаления аккаунта главного администратора системы. А поскольку сроки поджимали, то в программе появился код:

if(“admin”.equals(username)) {

          showError(“Can't delete admin”);

          return;

}

Как известно, в СССР секса не было.

Аналогично, в идеальной системе нет хаков.

Потому, что в идеальном мире:

· Есть неограниченное количество времени, для проведения любого количества рефакторингов

· Не существует сроков, при нарушении которых, пропадает всякий смысл в дальнейшей разработке

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

За последние 15 лет, мне такие проекты, к сожалению, не попадались.

Поэтому, скажу крамольную вещь: в реальных проектах хаки имеют право быть.

При этом, аналогично «плохим» и «хорошим» багам, существуют «плохие» и «приемлемые» хаки. Для поддержания большой программной системы в стабильном состоянии, важно уметь отличать одни от других: стабильные системы не содержат «плохих» хаков.

Плохие и приемлемые хаки

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

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

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

Так вот приемлемым будет только такой хак, который ЯВНО СЛОМАЕТСЯ при выполнении любого из таких условий. «Явно сломается» - значит жестко упадет один из основных use-кейсов, и это не сможет пройти незамеченным для тестировщиков.

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

if(!accountExists(“admin”)) {

  throw new RuntimeException(“No admin exists”);

}

или лучше


   assert(accountExists(“admin”));

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

Энтропия и рефакторинг

Два факта:

1. Попытки немедленно уничтожать каждый приемлемый хак приводят к неприемлемому удорожанию проекта

2. Чрезмерное увеличение количества приемлемых хаков приводят к переусложнению кода и резкому снижению его понятности

Количество хаков в коде - это величина, которую необходимо постоянно отслеживать. Для каждого проекта опытным путём находится максимально допустимое количество хаков. При превышении этого количества необходимо делать рефакторинг.

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

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

Разработка больших систем. Часть 4. Принципы ООП.

2011-07-19T03:15:00.001-07:00

Принципы ООП очень хорошо описаны тут: http://www.oodesign.com/design-principles.html (правда по английски).

Их всего 5.

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

Принцип open-close

Класс должен быть закрыт для модификаций, но открыт для расширений.

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

Принцип инверсии зависимостей

Состоит из двух утверждений:
1. Высокоуровневые модули не должны зависеть от низкоуровневых модулей. И те и другие должны зависеть от абстракций.
2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций (конкретизируя их)

По сути, именно абстракции задают контракты. Отсутствие зависимостей между модулями — это перефразированное утверждение, приведенное в третей части «каждый класс - самостоятельная сущность, которая НИЧЕГО не знает о внутреннем строении других классов».
Второе утверждение говорит о первичности контрактов (абстракций) относительно деталей их реализаций. Иными словами, контракт не должно волновать, каким образом он будет выполнен.

Принцип сегрегации интерфейсов

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

Пример плохого интерфейса

interface HrenovaTucha {
  void sentToPrinter(String text);
 Image scan();
 void burnCD(Image cd)
}

Что мне делать, если у меня нет сканера?

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

Принцип единственной зоны ответственности

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

Принцип подменяемости Лискова

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

Другими словами — класс наследник обязан соблюдать контракт класса-родителя. Однако наследник имеет право расширить контракт, введя новые методы. И полное право изменить способ выполнения контракта, перегрузив существующие методы.

Разработка больших систем. Часть 3. О хорошем дизайне.

2011-07-18T00:39:00.000-07:00

Как было упомянуто, одной из причин «плохих» багов является неверная архитектура приложения. И, хотя построение архитектуры является обязанностью архитектора, а не разработчика, разработчику полезно бывает уметь видеть стандартные ошибки в архитектуре и отличать правильную архитектуру от неправильной. Хотя бы для того, чтобы не испортить правильную архитектуру своими изменениями.

Здесь очень коротко изложу основные принципы дизайна.

Принцип отсутствия скрытых зависимостей

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

Смысл: если этот принцип не соблюдается, то любое «неполное» изменение автоматически приводит к плохому багу.

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

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

Во-вторых, каждый класс должен также относиться к тем классам и интерфейсам, которые он использует: он не должен ничего предполагать об их внутреннем строении. Он пользуется их публичным API от которого ожидает разумного поведения (исполнения их контракта). Если поведение неразумно — это повод исправить «неразумный» класс, в соответствии с контрактом, а не подстроиться под это неразумное поведение.

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

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

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

Упражнение

Назовите плохие методы в данном классе. Скажите, почему они плохие.

class AlertManager {
public List searchAlerts(String query);
public List searchAlerts2(String query);
public void processAlerts(List alerts);
public List doSearchAndThenDeleteAlertsIfBad(String query);
public Map getInternalAlertMap();
public Alert getAlertById(String id);
public void putAlert(String id,Alert alert);
}

Принцип одного контракта

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

Другими словами, из двух взаимодействующих классов ОДИН (в данном случае класс Б) определяет ВЕСЬ контракт взаимодействия. А другой управляет, оставаясь в рамках этого контракта.

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

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

Принцип 80-20

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

Например, был метод

doSearch(String query);

А вам хочется сделать из него метод

doSearch(String query,boolean useNewAdvacedApproach, double weightForDescriptionField,SpecialSearchParameters params);

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

Принцип незавоевания

Ваша библиотека, API , компонент (и вообще что угодно) НЕ ДОЛЖНО конфликтовать с использованием стандартных способов разработки, существовавших до вас. Другими словами - дополняйте, но не подменяйте. Должно допускаться "смешанное" кодирование: с использованием вашего API и стандартного вместе.

Этот принцип проще показать на примере.

Классический пример - ненавидимый мною проект Apache Cayeene. В этой ORM системе авторы додумались до требования наследовать все объекты модели от их собственных классов. Очевидно, что если вы возьмете две библиотеки, написанные столь блестящим образом, и решающие разные задачи (например Cayeene и столь же глупую библиотеку, служащую, скажем для сериализации объектов), то вы не сможете совместить их в одном приложении. Или одна или другая завоюет его все.

Разработка больших систем. Часть 2. Работа с багами.

2011-07-15T01:12:00.000-07:00

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

Хорошие баги

К хорошим багам относятся разного рода опечатки, сделанные по причине того, что люди не являются роботами. (Например, разного рода NPE и т д). Другой вид хорошего бага, локальная логическая ошибка в определенном месте кода, которая влияет только на это место. (Например, вместо “>” поставили “<” или немного неверно предсказали поведение внешнего компонента, и, поэтому, неверно интерпретировали его результат).

Общими признаками хороших багов является:

• Повторяемость (они всегда возникают при одних и тех же условиях)
• Локальность (они относятся только к одному объекту и никак не затрагивают другие объекты)

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

Плохие баги

Признаками плохого бага являются

• Трудноуловимость (он возникает иногда и никто не знает, как его повторить)
• Не локальность. (Если его нашли, способ его исправления не очевиден, поскольку он влияет на множество компонентов системы)

Мне известно три причины плохих багов:

• Неверный дизайн (архитектура) приложения
• Неправильно вносимые изменения (см. главу про изменения)
• Гены разработчика

(Последняя причина не является устранимой на современной стадии развития науки. )

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

Работа с разными типами багов

Первое, что необходимо сделать, это выяснить, является ли баг хорошим или плохим. Для этого надо понять его причину и проверить, является ли она следствием локальной ошибки. Т. е. может ли проблема быть устранена исправлением этой ошибки в одном месте и не приведет ли это к каким-либо побочным эффектам. Хорошим критерием является такой: если автор бага сходу скажет, что он тупо ошибся – то баг, скорее всего, хороший. Если же автор имел какие-то причины написать именно так, то перед вами плохой баг.

Правка хорошего бага

Сводится к исправлению тупой ошибки и проверке, что баг более не появляется.

Внимание: если после этого исправления баг не исчез, его следует рассматривать, как плохой!

Правка плохого бага

Проводится в точности также, как и внесение изменения! (см главу про внесение изменений).

Разработка больших систем. Часть 1. Внесение изменений.

2011-07-14T06:08:00.000-07:00

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

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

Начну с первой (исторически) части - как делать (и как НЕ делать) изменения в большой программной системе.

Внесение изменений

Как вносить изменения (или исправления) в сложную систему.

Неверный способ

1) Найти место для внесения изменения
2) Внести изменение
3) Проверить работает ли
4) Если нет, перейти к пункту 2

Почему этот способ не работает

Нет анализа исходной точки

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

Пример из жизни: Было замечено, что некий продукт работает слишком медленно, если число отображаемых объектов превышает 6000. Разработчик не разобрался в существующем коде и приделал к нему кэш. При этом, поскольку кэш там уже был, получилось двойное кэширование, которое никак не повлияло на скорость работы, однако усложнило систему и внесло в нее ряд нетривиальных багов.

Когда анализ исходной точки не проводится, система начинает покрываться корявыми «наростами». А потом эти наросты – новыми наростами. В какой-то момент невозможно понять что система делает вообще.

Нет анализа конечных целей

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

Пример из жизни: Заказчиком была поставлена задача добавить к системе полнотекстовый поиск. Закзачик сделал акцент на том, что этот поиск позволит искать внутри описания объектов. При этом он не отметил, что поиск , работает в несколько раз быстрее, чем ранее применявшееся фильтрование в памяти, а также , что поиск может быть использован ВМЕСТО фильтрования, что повысит скорость работы системы в несколько раз. Пропуск фазы анализа конечной цели привел к тому, что полнотектовый поиск был приделан нарядус фильтрованием. И, хотя и позволил искать внутри описания объектов, никак не увеличил скорость работы. Именно это неверное решение привело к возникновению в будущем задачи про 6000 медленных объектов (см выше).

Нет гарантии, что изменение будет работать всегда

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

На самом деле, этот процесс гарантирует в точности обратное.

Образный пример – вы приносите в сервисный центр сломанный аудиоплэйер. Который включается через раз и иногда зависает. Ждете неделю. Потом вам его возвращают с диагнозом «неисправность не обнаружена». И все потому, что девочка-приемщик включила плэйер, подержала его включенным 2 минуты, и он за это время не завис.

Правильный способ внесения изменений

Вероятно, уже понятно, что неверный способ внесения изменений (также известный, как «запинывание») приводит к очень плохим результатам. Как минимум, все изменения , внесенные таким образом, потом вычищает и переписывает более опытный специалист, как максимум, проект убивается и становится не управляемым.
Теперь опишу правильный способ внесения изменений.

ДАО изменений

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

Процесс выглядит так:

1) Понять цели вносимого изменения
2) Описать, как должна работать система после внесения изменения
3) Понять, как система работает сейчас, какие аспекты она учитывает
4) Предложить метод перехода из состояния «сейчас» в состояние «надо»
5) Встать в позицию критика и объяснить, почему предложенный способ – полное говно
6) Вернуться в конструктивную позицию и перейти к пункту 4

На третьей-четвертой итерации вам не удастся выполнить пункт (5). Значит, пора переходить к реализации:

7) Реализовать выбранный метод, снабдив его комментариями, описывающими ваш ход мысли – почему такое изменение приведет к нужным результатам
8) Проверить реализацию с учетом всех аспектов, которые могут влиять на изменение (разные входные данные, секьюрити и т п). Здесь иногда надо написать юнит тест (если напрямую проверить не получается). А иногда, если требуется много проверок, можно написать инструкцию для тестера – включить в нее все действия, которые тестер должен выполнить.
9) Важно: если при проверках все идет не так, как было вами предсказано, НЕОБХОДИМО понять, почему это так. Ни в коем случае не списывать на случайность.
10) Задача считается сделанной, если вы видите, что переход в нужную точку состоялся и прекрасно понимаете как все работает после этого изменения.

Процессы, проекты и российские компании

2009-09-15T07:52:00.001-07:00

Введение

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

Определения

Задача – однократно выполняемая за короткое время работа одного исполнителя (то есть, каждое новое задание выполняется одним сотрудником по каждый раз новым или модифицированным правилам);

Функция – регулярная работа одного работника, выполняемая по известным ему правилам (то есть, каждое новое задание выполняется одним сотрудником, но всегда по установленным, повторяющимся, известным ему правилам);

Проект – однократно выполняемая работа многих исполнителей за длительное время (то есть, каждое новое задание выполняется многими сотрудниками, по каждый раз заново сформулированным правилам и алгоритмам);

Процесс – это регулярно выполняемая работа многих исполнителей по четко зафиксированным правилам и алгоритмам.

Отличия процессов от проектов

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

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

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

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

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

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

Далее стоит отметить разницу в подходах к контролю деятельности при процессном и проектном управлении:

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

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

Таким образом, автоматизация управления процессами отличается от автоматизации управления проектами подходами к планированию и контролю деятельности. Причем разница существенна и применение систем управления процессами для управления проектами, либо наоборот — неэффективно.

Автоматизация проектов и автоматизация процессов

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

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

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

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

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

Но часто ли в реальной жизни мы сталкиваемся с чистыми процессами и чистыми проектами?

Организация деятельности в средней российской компании

Рассмотрим классический пример, взятый из статьи, посвященной процессам и проектам:

Пример:

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

Но представьте, что в какой-то момент времени, Вам необходимо закупить нечто, что Вы никогда не закупали, и при этом, не ясно как это нечто закупить. Например, Вам потребовалось сырье, которое производится лишь в одной стране мира, представительства и поставщика данного производителя в РФ нет, и не ясно как его можно вообще купить? Что Вы будете делать в этой нестандартной ситуации?

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

Андрей Борисов, старший консультант компании TOPs, г. Москва.

Что мы здесь видим? Идет процесс — от него отделяются проекты, их результаты встраиваются обратно в процесс. Таким образом, в деятельности средней компании есть и процессы и проекты. Более того, они связаны между собой, обмениваются результатами и в целом их можно рассматривать совокупно, как деятельность , имеющую признаки и процесса и проекта.

Пример является характерным, по крайней мере для российских средних компаний.

Что получается при применения классической процессной автоматизированной системы для управления такой деятельностью? Одно из двух:

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

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

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

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

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

Тогда какая нужна система?

В идеале, было бы иметь систему, способную обрабатывать оба вида активностей — периодические и нестандартные.

Недостатки планировщиков

2009-07-17T04:37:00.001-07:00

В этом документе я попытался описать наиболее раздражающие меня недостатки настольных инструментов планирования проектов. Таких, как MS-Project Standard (не путать с сервером), OpenWorkbench или OpenProj.

Очень интересно, услышать Ваше мнение по этому поводу.

WBS versus календарный график

В жизни существует две независимых «топологии» над набором задач проекта:

Иерархическая структура задач (в которой деление на подзадачи происходит естественным образом)
Распределение задач по вехам, или по версиям системы. Здесь две подзадачи одной задачи вполне могут попасть в разные вехи. Например, если одна подзадача крайне важна, а вторая — незначительная «фича»

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

Такое положение дел иногда приводит к тому, что планировщики начинают использовать некорректно, заменяя WBS структурой вроде следующей:

Первая версия

Разработка

Разработка фичи 1

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

Тестирование фичи 1

Вторая версия

Разработка

Разработка фичи 2

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

Тестирование фичи 2

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

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

Разработка

Разработка фичи 1

Разрапотка фичи 2

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

Тестирование фичи 1

Тестирование фичи2

Веха — версия 1, зависит от (Разработка фичи 1, Тестирование фичи 1)

Веха — версия 2, зависит от (Разработка фичи 2, Тестирование фичи 2)

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

Дополнительным неудобством является тот факт, что вехи являются задачами. Ничем от них не отличаются. Поэтому увидеть какие вехи зависят от данной задачи очень сложно. Вехи перечисляются в списке ВСЕХ задач, которые зависят от данной. (Кроме того тут опять появляется вопрос о транзитивных зависимостях, которые просто так не увидишь)

Ну и напоследок — нет простого способа найти задачи, не попадающие ни в одну веху (опять проблема транзитивных задач)

О них, кстати, подробнее:

Транзитивные зависимости между задачами

Ни в одном планировщике нет способа увидеть все задачи, зависимые от данной или все — зависящие от данной. То есть есть возможность увидеть только список непосредственно зависимых (или зависящих). А вот зависимых от зависимых (и тд) — нельзя никак. Часто это оказывается неудобным.

Наиболее яркий пример неудобства — это выставление этих самых зависимостей при планировании проекта из 100 и более задач. Практически нет удобного способа убедиться что все зависимости выставлены правильно. Вполне может оказаться что задача 32 зависит от задачи 44, но мы эту зависимость не указали, потому что решили, что она и так есть — транзитивная. Может быть она даже была, но в какой то момент пропала. Отследить это, не видя транзитивных зависимостей, крайне сложно.

Можно возразить, что надо-де вставлять все зависимости напрямую и не полагаться на транзитивные. Но вот пример — задача «Подготовительные активности» в которой 30 подзадач. И задача «Разработка» в которой еще 50 подзадач. Станете вы вставлять полторы тысячи прямых зависимостей для каждой из 50ти задач по разработке от каждой из 30ти подготовительных задач? А проходить по списку подготовительных задач, искать зависимые для каждой из них и переносить каждую из этих зависимостей в каждую из 50 ти задач разработки? А поддерживать целостность такого плана?

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

Личные планы

Другим забавным неудобством планировщиков является трудность в просмотре личного плана — плана работы для одного человека. Нечто подобное реализовано только в OpenWorkbench в виде фильтра по ресурсам (людям), скрывающим все задачи, в которых данный человек не участвует.

Это уже кое-что. Но. Было бы очень неплохо видеть на этом графике входящие и исходящие зависимости задач этого человека от других задач. Чтобы при планировании было видно где график работы Васи Пупкина может «поплыть» не по его вине, а из-за задержки другого члена команды. С другой стороны, чтобы этот самый Вася видел, на какие задачи ему стоит обратить внимание, чтобы не «удружить» своему товарищу.

А еще мне не хватало возможности выбрать ни одного, а несколько человек в этом фильтре. Скажем двоих — чтобы посмотреть зависимости между их задачами.

Молчаливый и настойчивый Искусственный интеллект

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

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

12:21.22 — Попытка сдвинуть задачу такую-то ранее 12го августа пресечена, поскольку 12е августа — дата старта нашего проекта.

12:21.45 — Пользователь Вася изменил длительность задачи такой то, поэтому теперь работа пользователя Пети, который будет эту задачу делать увеличилась и составила 24 часа вместо ранее запланированных 16ти.

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

При этом, особо важные сообщения можно показывать сразу же — в виде всплывающих подсказок, клик по которым открывал бы всё тот же лог.

Информационная атака

Очень симпатично смотрятся примеры работы с планировщиками, взятые из разных tutorial-ов. Типа проект «постройка дома» мило делится на 15 задачек, вроде «заказ гвоздей» иди «заливка фундамента».

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

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

А если план меняется (как это всегда бывает в жизни), да к тому же менять его надо именно вам?

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

Например, есть такая задача менеджера как осмысление взаимных зависимостей различных частей проекта. В реальности, далеко не все подзадачи вообще имеют какие-либо зависимости. Так почему же менеджер должен видеть всю тысячу задач, чтобы осмыслить скажем 30 зависимостей? В данной ситуации было бы очень полезно уметь скрыть ненужные задачи.

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

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

Кстати, пункт «Личные планы» тоже из этой оперы. Это срез информации необходимый для оценки плана работ каждого участника проекта.

Статичность

Почти все перечисленные выше проблемы (кроме проблемы Искусственного интеллекта) имеют один общий корень. Я бы назвал его статичностью планирования. Проблема эта сложилась исторически:

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

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

План управления проектом

2008-10-14T03:03:00.000-07:00

Привет всем.

Недавно, впервые в нашей практике, русскоязычный заказчик потребовал от нас план управления проектом. С одной стороны - здорово. Значит уровень отечественных заказчиков вырос. С другой - готового шаблона на русском языке в Интернетах не нашел. Пришлось писать (или переводить?) самостоятельно. Результат - ниже. Надеюсь, кому-нибудь сэкономит время :-)
Замечу, что приведенный здесь документ - это все таки не шаблон, а именно русскоязычный пример.
Красным цветом выделено то, что в Вашем случае точно надо будет заменить.

Введение 2
Краткое описание проекта 2
Контекст, цели и задачи проекта 2
Список артефактов, которые будут получены в процессе работы над проектом 2
Организационная структура проекта 3
Участники проекта и их ответственность 3
Процесс управления проектом 3
Стартовые активности 3: Оценка 3; Выбор персонала 3; Ресурсы 4; Обучение персонала 4
Планирование работ 4: Предварительное расписание 4; Распределение персонала и ресурсов 4; Планируемый бюджет 4
Контроль проекта 4: Управление требованиями 4; Управление расписанием и бюджетом 5; Управление качеством 5; Управление коммуникациями 5; Управление метриками 7; Управление рисками 7
Закрытие проекта 8
Процесс разработки 8
Жизненный цикл проекта 8
Технические средства разработки 8
Инфраструктура 8
Процесс приемки продукта 9
Служебные процессы 9
Управление конфигурациями 9
План тестирования 9
Документирование 9
Процессы обеспечения качества 10
Процесс аудита кода проекта 10
Процесс работы с проблемами 10
Процесс управления контрактами 11
Процесс улучшения процессов 11
Версии документа 12

Введение

ООО «Заказчик», именуемое в дальнейшем «Заказчик», в лице директора Иванова Ивана Ивановича, действующего на основании Устава, с одной стороны, и ООО «Софтария» в лице директора, Кузьмина Романа Михайловича действующего на основании Устава, именуемое в дальнейшем « Исполнитель», с другой стороны, - в дальнейшем по отдельности или вместе именуемые «Сторона», «Стороны», -согласовали следующий план работы над проектом «Мегапроект».

Данный документ описывает план управления проектом «Мегапроект». Оперативное управление проектом осуществляется менеджерами Исполнителя.

Краткое описание проекта

Контекст, цели и задачи проекта

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

Список артефактов, которые будут получены в процессе работы над проектом

В результате работы над проектом должны быть произведены и переданы Заказчику следующие продукты:

Исходные коды программного обеспечения «Мегапроект» (Должны находиться в системе контроля версий SVN, установленной на территории Заказчика
Дистрибутив программного обеспечения
Инструкция по сборке дистрибутива из исходных кодов, находящихся в системе контроля версий.
Инструкция по установке дистрибутива
Руководство для администратора системы

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

Техническое задание на разработку системы (SRS)
Критерии приемки проекта
Календарный план разработки
Бюджет проекта
Документ, описывающий архитектуру проекта (SAD)
База данных учета изменений (это не документ, а база данных системы ISSUE Tracking JIRA)
И данный документ — план управления проектом

Организационная структура проекта

Участники проекта и их ответственность

Со стороны Заказчика в проекте участвуют исполнители следующих ролей:

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

Со стороны Исполнителя в проекте участвуют

Менеджер проекта — выстраивание процессов управления проектом, решение важных вопросов, контроль процесса, внесение корректив.
Лидер команды — управление оперативной деятельностью проекта согласно заданным процессам.
Аналитик — уточнение требований к проекту
Разработчики проекта — разработка архитектуры, написание кода, тестирование результатов друг друга
Эксперт - аудитор — выполнение независимого аудита кода
Тестировщики — выполнение независимого тестирования

В данном проекте возможно совмещение некоторых ролей, при этом недопустимо совмещение роли разработчика и тестировщика.

Процесс управления проектом

Стартовые активности

Оценка

Согласована с Заказчиком и определена в ТЗ

Выбор персонала

В выполнении данного проекта со стороны Исполнителя планируется участие следующих специалистов.

Пелевин Дмитрий Олегович — Лидер команды, Старший разработчик
Рудер Иван Давыдович — Аналитик, Разработчик
Кузьмин Роман Михайлович — Менеджер проекта
Чуркин Иван Валерьевич — Эксперт-аудитор

Тестировщики на этой стадии проекта не определены. Будут выбраны в зависимости от наличия свободного времени.

Ресурсы

Рабочие станции разработчиков и ПО, необходимое им для работы предоставляет Исполнитель.

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

Заказчик предоставляет доступ к системе Issue Tracking-a JIRA.

Заказчик предоставляет доступ к системе класса Team Collabortaion (возможно Confluence, коль скоро используем JIRA).

Исполнитель также предоставляет сервер для сборки версий системы и систему Continuum, в качестве системы непрерывной интеграции(CI)

Обучение персонала

В рамках проекта необходимо выделение бюджета и времени для обучения разработчиков технологии Мегатехнология.

Планирование работ

Предварительное расписание

Первый релиз проект должен выйти 20 августа 2010 года

Распределение персонала и ресурсов

См. выше.

Планируемый бюджет

Бюджет проекта составляет 3 миллиона долларов.

Контроль проекта

Управление требованиями

Изменение требований инициируется Представителем Заказчика в виде создания нового Issue в JIRA и назначения Аналитика ответственным за него.

Аналитик ответственен за выполнение оценки влияния каждого изменения на проект. Изменение может

Увеличить бюджет проекта
Увеличить календарный срок проекта
Внести в проект новые риски

В обязанности аналитика входит написание комментария к Issue с указанием влияния изменения на проект и внесения одной из своих рекомендаций

Внести изменение в текущую итерацию проекта
Внести изменение в следующую итерацию проекта
Не вносить изменение вообще

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

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

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

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

Управление расписанием и бюджетом

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

Оплата работ Заказчиком производится ежемесячно. Оплачиваются задачи, законченные на момент выставления счета. Счет включает детализацию по задачам и их бюджетам.

Управление качеством

Управлять качеством — значит добиваться таких качественных показателей продукта, при которых он наиболее точно соответствует Business Case. (В отличие от процесса обеспечения качества, описанного в разделе «Служебные процессы», управление качеством не является синонимом повышения качества. Иногда, в процессе управления качеством, может быть принято решение, наоборот, понизить качество той или иной составляющей проекта, с целью сокращения времени выхода на рынок или уменьшения стоимости проекта)

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

Управление коммуникациями

В качестве средств коммуникации в проекте используются следующие:

Система Issue Tracking — JIRA
Система Team Collaboartion (Confluence или любая WIKI-based система)
Электронная почта
Телефон

JIRA используется для

Управления требованиями (issue report) — см.управление требованиями.
Создания и отслеживания состояния отчета об ошибке (bug-rpeort)
Постановке задач разработчикам

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

Электронная почта используется как средство привлечь внимание участника проекта к дискуссии или Issue в системе Issue tracking либо когда необходимо решить административный или технический вопрос (например, у кого-то просрочен пароль в JIRA). Другое использование электронной почты — предоставление представителю заказчика еженедельных отчетов о состоянии дел в проекте. Вопросы по проекту, ответы на которые важны для дальнейшей разработки, никогда не задаются посредством электронной почты.

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

В таблице перечислены наиболее распространенные типы информации и способы их передачи.

Тип информации	Средство коммуникации	Источник информации	Адресат информации
Новое требование об изменении	JIRA	Представитель Заказчика	Аналитик
Отчет об ошибке	JIRA	Любой участник	Лидер команды
Подтвержденное требование об изменении	JIRA	Аналитик	Лидер команды
Подтвержденное требование об изменении	Email	Аналитик	Менеджер проекта
Задача на исполнение	JIRA	Лидер команды	Разработчик, Тестировщик, Аудитор, Аналитик
Отчет об исполненной задаче	JIRA	Разработчик, Тестировщик, Аудитор, Аналитик	Лидер команды
Обсуждение вопросов, касающихся проекта	Confluence	все	все
Еженедельный отчет	Email	Лидер команды	Менеджер проекта, Представитель Заказчика
Запрос о доступе к инфраструктуре	Email	все	Администратор Инфраструктуры
Отчет о проблеме (эскалация)	Email	Участники проекта	Менеджер проекта, Лидер команды
Отчет о проблеме (эскалация)	Email	Менеджер проекта	Представитель Заказчика
Отчет о проблеме (эскалация)	Email	Закзачик	Менеджер проекта
Отчет о проблеме (эскалация)	Email, телефон	Представитель Заказчика, Менеджер проектов	Главный заказчик

Управление метриками

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

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

Сравнение текущего плана и факта (с указанием, успеваем ли мы по графику)

Перечисляются недооцененные и переоцененные задачи и задачи, ошибочно не включенные в изначальный план ( с целью дальнейшего анализа)

Управление рисками

На стадии планирования проекта определены следующие риски:

Непонимание бизнес цели проекта Исполнителем (может привести к не идеальной реализации)
Нарушения в работе распределенной команды, вызванные задержками со стороны персонала Заказчика
Нарушения работы, вызванные неготовностью оборудования и сервисов, предоставляемых заказчиком
Болезнь одного из ключевых членов проектной команды
Неправильная оценка ожидаемой нагрузки на сервер
Плохая пригодность технологии Мегатехнология к созданию Мегапроекта

По данным рискам:

Риск	Вероятность	Важность	Вредный эффект	Стратегия предотвращения	Стратегия преодоления
Нарушения работы, вызванные неготовностью оборудования и сервисов	Низкая	Средняя	Календарные задержки и увеличение бюджета.	По возможности, подготовить резервный вариант для JIRA и Confluence	Временно использовать другие средства коммуникации. Временно прекратить делать commit-ы в SVN
Болезнь одного из ключевых членов проектной команды	Низкая	Средняя	Календарные задержки	Продумать возможные замены.	Заменить заболевшего.

В обязанности менеджера проекта входит отслеживание возникновения как идентифицированных так и непредвиденных рисков.

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

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

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

Закрытие проекта

При закрытии проекта должны пройти следующие фазы:

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

Процесс разработки

Жизненный цикл проекта

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

Работающие версии будут создаваться в результате относительно коротких итераций (в терминологии Scrum — спринтов). Длина одного спринта будет от недели до трех недель. Результат итерации — работающая версия с четко определенной функциональностью будет помечаться в SVN путём создания ветки (branch).

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

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

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

Технические средства разработки

Разработка ведется на Java 1.6 под ОС Windows XP с применением Eclipse IDE и Tortoise SVN в качестве Svn-клиента.

Для планирования итераций используется JIRA.

Инфраструктура

См Ресурсы

Процесс приемки продукта

Основным критерием приёмки продукта является его пригодность для решения бизнес-задач (соответствие Business Case).

Формальные критерии — соответствие функциональным и нефункциональным требованиям.

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

Служебные процессы

Управление конфигурациями

Процесс сборки дистрибутива проекта будет осуществляться при помощи системы maven.

Будет написана краткая инструкция по сборке, позволяющая собрать дистрибутив из любой версии, находящейся в системе контроля версий. Для сборки необходимо будет:

рабочая машина с выходом в интернет
java 1.6
maven
СУБД Mysql

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

План тестирования

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

Тестировщики тестируют только версии — результаты итераций. Результаты тестируются согласно плану итерации. Отдельный документ — тест план не создаётся.

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

Документирование

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

Из них создаются и согласуются единожды на стадии планирования проекта:

Техническое задание на разработку системы (SRS) — (Дальнейшие изменения фиксируются лишь в JIRA.)

Могут пересматриваться в исключительных случаях

Документ, описывающий архитектуру проекта (SAD)
Данный документ (план управления проектом)

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

Критерии приемки проекта
Календарный план разработки
Бюджет проекта

Изменяются ежедневно:

База данных учета изменений (это не документ, а база данных системы ISSUE Tracking JIRA)

Создаются еженедельно:

Отчеты о состоянии проекта.

Отчеты включают в себя —

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

Процессы обеспечения качества

На обеспечение должного уровня качества направлены следующие действия:

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

Процесс аудита кода проекта

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

Важно отметить, что в качестве критериев качества кода предполагается использовать критерии, выработанные нашей компанией совместно с немецким партнером (Brox IT Solutions) и используемые при разработке ПО для европейских корпораций (Siemens, Volkswagen, Дойче Телеком, Credit Suisse). Данные критерии доступны на английском языке в виде WIKI. По желанию Заказчика, к ним будет предоставлен доступ.

Процесс работы с проблемами

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

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

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

Процесс управления контрактами

В данном проекте отсутствует

Процесс улучшения процессов

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

Версии документа

Дата	Версия	Описание	Автор
17.07.2008	1.0	Первая версия	Кузьмин Роман Михайлович
15.08.2008	1.1	Уточненная версия	Кузьмин Роман Михайлович
15.08.2008	1.2	Правки для большей юридической точности	Кузьмин Роман Михайлович

Технологии управления проектами

2008-07-05T18:37:00.000-07:00

Привет, Все !

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

На сегодня есть конспекты - про PMBOK, PRINCE2, CMMI, 6 сигм, MSF и Scrum (они уже опубликован ы ниже)

Что такое Scrum

2008-07-04T23:29:00.000-07:00

Очередной конспект семинара о методологии управления проектами. На этот раз рассматриваем Scrum - один из, так называемых, гибких (agile) методов.

В отличие от таких всеобъемлющих подходов к управлению проектами, как, например, PRINCE2, Scrum изначально предназначался для разработки IT проектов. При этом Scrum больше ориентирован на сам процесс разработки, чем на процесс управления. С моей точки зрения, эта технология хорошо дополняет любой из процессов управления, и может быть с ним интегрирована при разработке очень больших IT проектов. (В сравнительно небольших IT проектах она самодостаточна)

Конспект семинара предоставлен моим коллегой Антоном Сальником

Оглавление

Введение

Концепция Scrum

Роли

Product Owner

Scrum Master (Скрам Мастер)

Scrum Team

Практики

Sprint

Daily Scrum Meeting

Sprint Review Meeting

Sprint Abnormal Termination

Артефакты

Product Backlog

Sprint Backlog

Burndown Chart

Выводы

Введение

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

Термин Scrum был впервые озвучен в работе Хиротаки Такеучи и Икуджиро Нонака, где авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схватки (scrum) в регби, которая назначается при нарушении правил или остановке игры. Джеф Сазерленд использовал эту работу при создании методологии для корпорации Easel в 1993 году, которую по аналогии и назвал Scrum, а Кен Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 году работу на конференции Object-Oriented Programming Systems, Languages & Applications.

Основа Scrum — итеративная разработка. Scrum определяет:

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

Каждую итерацию можно описать так: планируем — фиксируем — реализуем — анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки.

Концепция Scrum

Формальная часть Scrum состоит из трех ролей, трех практик и трех основных документов.

Роли

В методологии Scrum всего три роли.

Product Owner
Scrum Master
Team

Product Owner

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

Обязанности владельца продукта таковы:

Отвечает за формирование product vision
Управляет ожиданиями заказчиков и всех заинтересованных лиц
Координирует и приоритизирует Product backlog
Предоставляет понятные и тестируемые требования команде
Взаимодействует с командой и заказчиком
Отвечает за приемку кода в конце каждой итерации

Scrum Master (Скрам Мастер)

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

Основные обязанности Scrum Master-а таковы:

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

Scrum Team

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

Обязанности команды таковы:

Отвечает за оценку элементов баклога
Принимает решение по дизайну и имплементации
Разрабатывает софт и предоставляет его заказчику
Отслеживает собственный прогресс (вместе со Скрам Мастером).
Отвечает за результат перед Product Owner

Практики

Sprint

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней).

Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Подготовка к первой итерации, называемой спринт (Sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (Product Backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (Sprint Planning Meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности. Важно, чтобы Scrum-команда выбирала первые по приоритету требования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирование спринта. Scrum-команда разбивает выбранные требования на задачи, необходимые для его реализации. Эта активность в идеале не должна занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, — журнал спринта (Sprint Backlog). Необходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.

Каждый спринт представляет собой маленький «водопад». В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта.

Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Daily Scrum Meeting

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

Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды

Что сделано вчера?
Что будет сделано сегодня?
С какими проблемами столкнулся?

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда, например

Обсудить проблему с отрисовкой контрола
Петя и Вася
Сразу после скрама

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

Sprint Review Meeting

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

Затем цикл замыкается, и начинается планирование следующего спринта

Sprint Abnormal Termination

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

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

Артефакты

Product Backlog

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

Sprint Backlog

Журнал спринта содержит функциональность, выбранную владельцем продукта из журнала продукта. Все функции разбиты по задачам, каждая из которых оценивается командой. Разбивка на задачи должна быть сделана таким образом, чтобы выполнение одной задачи занимало не больше двух дней (считается, что менее детальная, например, полдня, разбивка приводит к более грубой оценке, чем приемлема в большинстве проектов, использующих методологию Scrum). Разбивка на задачи поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала спринта сравнивается с первичной оценкой в журнале продукта. Если существует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журнала спринта.

Burndown Chart

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

Выводы

Плюсы:

Простота и легковестность;

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

Product Backlog

Sprint Backlog

Sprint Burndown chart

Что такое MSF

2008-07-03T06:33:00.000-07:00

Продолжаю публиковать конспекты семинаров по методологиям управления проектами.

Этот посвящен MSF. Автором семинара является мой коллега Антон Сальник. Конспект опубликован с его согласия.

Оглавление

Введение

Структура MSF

Модель проектной группы

Ролевые кластеры

Масштабирование модели проектной группы

Модель процессов

Вехи и фазы

Итеративный подход

Фазы и вехи модели процессов MSF

Фаза выработки концепци (Envisioning)

Фаза планирования (Planning)

Фаза разработки (Development)

Фаза стабилизации (Stabilizing)

Фаза внедрения(Deploying)

О чем еще рассказывается в модели процессов

Дисциплина управления проектами

Дисциплина управления рисками

Дисциплина управления подготовкой

Новые версии MSF

Литература

Масштабирование проектных групп

Таблица совместимости ролей

Введение

Microsoft Solutions Framework, далее MSF, представляет собой подход компании Microsoft к управлению IT-проектами. В данном обзоре будет рассмотрена версия 3.0 данной методологии, опубликованная в июне 2002 года.

Структура MSF

Технология MSF состоит из двух моделей:

Модель проектной группы;
Модель процессов.

И трех дисциплин:

Дисциплина управления проектами;
Дисциплина управления рисками;
Дисциплина управления подготовкой.

Все они довольно подробно описаны в 5 whitepapers [1]. Рассмотрим все эти части более детально.

Модель проектной группы

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

К основным принципам и ключевым концепциям, определяющих проектную группу MSF относятся:

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

Распределение ответственности при фиксации отчетности.
Нацеленность на необходимый заказчику конечный результат;
Наличие у сотрудников необходимых полномочий;
Открытое общение;
Установка на отсутствие дефектов;
Стремление к совершенствованию;
Гибкость и готовность к переменам;
Заинтересованность и энтузиазм.

Ролевые кластеры

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

Модель проектной группы MSF определяет шесть ролевых кластеров. Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Одна роль (или один кластер) может быть представлена одним или несколькими сотрудниками, в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера.

Управление продуктом

Цель: Удовлетворенные заказчики.

Область компетенций:

Маркетинг;
Бизнес-отдача (бизнес-приоритеты);
Представление интересов заказчика;
Планирование продукта.

Управление программой

Цель: Достижение результата в рамках проектных ограничений.

Область компетенций:

Управление проектом;
Выработка архитектуры решения;
Контроль производственного процесса;
Административные службы.

Разработка

Цель: Создание продукта в соответствии со спецификацией.

Область компетенций:

Технологическое консультирование;
Проектирование и осуществление реализации;
Разработка приложений;
Разработка инфраструктуры.

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

Цель: Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены.

Область компетенций:

Планирование тестов;
Разработка тестов;
Отчетность по тестам.

Удовлетворение потребителя

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

Область компетенций:

Обеспечение технической поддержки;
Обучение;
Эргономика;
Графический дизайн;
Интернационализация;
Общедоступность (обеспечение возможности работы для пользователей с ограниченными физическими возможностями);

Управление выпуском

Цель: Беспроблемное внедрение и сопровождение продукта.

Область компетенций:

Инфраструктура;
Сопровождение;
Бизнес-процессы;
Управление выпуском готового продукта.

Принципы MSF формируют такой подход к управлению проектами, при котором:

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

Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!

Масштабирование модели проектной группы

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия.

В одном ролевом кластере может быть много людей;
Один человек может взять на себя несколько ролей;
Большие коллективы:
- создаем группы направлений;
- создаем функциональные группы;
Малые коллективы:
- смотрим таблицу совместимости ролей (из таблицы можно сделать вывод, что минимальный размер команды – 3 человека: удовлетворение потребителя, управление продуктом, Тестирование; Управление программой и выпуском; Разработка);

Модель процессов

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений, а именно описывает последовательность действий, осуществляемых в ходе реализации проекта.

Модель процессов MSF объединяет в себе принципы каскадной и спиральной моделей.

Тремя особенностями модели процессов MSF являются:

Подход, основанный на фазах и вехах.
Итеративный подход.

Вехи и фазы

Занимая центральное место в методологии MSF, вехи используются как опорные точки для планирования и мониторинга хода проекта.

MSF вводит два типа вех: главные (major) и промежуточные (interim). Они имеют следующие особенности:

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

Итеративный подход

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

Фазы и вехи модели процессов MSF

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

Для каждой фазы модели процессов MSF определяет:

Что (какие артефакты) является результатом этой фазы;
Над чем работает каждый из ролевых кластеров на этой фазе;

Фаза выработки концепци (Envisioning)

Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка документа общего описания и рамок проекта (vision/scope document).

Веха: Концепция утверждена.

Результаты:

Общее описание и рамки проекта (vision/scope document).
Документ оценки рисков (risk assessment document).
Описание структуры проекта (project structure document).

Рекомендуемые промежуточные вехи:

Ядро проектной группы сформировано
Черновой вариант концепции проекта составлен

Фаза планирования (Planning)

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

Веха: Планы проекта утверждены.

Результаты:

Функциональная спецификация;
План управления рисками;
Сводный план и сводный календарный график проекта.

Рекомендуемые промежуточные вехи:

Верификация технологий;
Базовая версия функциональной спецификации создана;
Базовая версия сводного плана проекта создана;
Базовая версия сводного календарного графика проекта создана;
Среды разработки и тестирования развернуты.

Фаза разработки (Development)

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

Веха: Разработка завершена.

Результаты:

Исходный и исполнимый код приложений;
Скрипты установки и конфигурирования;
Окончательная функциональная спецификация;
Материалы поддержки решения;
Спецификации и сценарии тестов.

Рекомендуемые промежуточные вехи:

Концепция подтверждена;
Билд 1 завершен;
Билд 2 завершен;
Билд n завершен.

Фаза стабилизации (Stabilizing)

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

Веха: Готовность решения утверждена

Результаты:

Окончательный продукт (golden release);
Документация выпуска (release notes);
Материалы поддержки решения;
Результаты и инструментарий тестирования;
Исходный и исполнимый код приложений;
Проектная документация;
Анализ пройденной фазы (milestone review).

Рекомендуемые промежуточные вехи:

Точка конвергенции (В точке конвергенции (bug convergence) становится заметен существенный прогресс в устранении ошибок, то есть скорость устранения ошибок начинает превосходить скорость их обнаружения. Точка конвергенции дает проектной группе возможность понять, что процесс тестирования близится к концу.
Точка достижения нуля (Точка достижения нуля (zero-bug bounce) – это момент, когда впервые все выявленные ошибки оказываются устраненными.)

Версии-кандидаты
Контрольное тестирование завершено
Тестирование приемлемости для потребителей завершено
Пилотное внедрение завершено

Фаза внедрения(Deploying)

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

Веха: Внедрение завершено.

Результаты:

Информационные системы эксплуатации и поддержки;
Процедуры и процессы;
Базы знаний, отчеты, журналы протоколов (logbooks);
Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта;
Отчет о завершении проекта (project close-out report);
Окончательные версии всех проектных документов;
Показатели удовлетворенности заказчика и потребителей;
Описание последующих шагов.

Рекомендуемые промежуточные вехи:

Ключевые компоненты развернуты;
Внедрение на местах завершено;
Внедренное решение стабилизировано.

О чем еще рассказывается в модели процессов

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

Дисциплина управления проектами

Носителем профессиональных управленческих навыков и организатором работы команды в MSF является ролевой кластер “Управление программой”. Однако типовые управленческие обязанности при этом распределяются среди лидеров всех ролевых кластеров проектной группы.

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

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

Распределение ответственности по управлению проектом среди лидеров групп

Для лидеров групп и ролевого кластера «Управление программой» инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS. Иерархическая структура работ (WBS) — это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.

Дисциплина управления рисками

Дисциплина управления рисками MSF заимствует хорошо известную модель процесса непрерывного управления рисками, разработанную Software Engineering Institute (SEI). При этом интерпретация этой модели дается в контексте опыта Microsoft. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием шестишагового процесса для успешного активного управления рисками. Этот процесс включает в себя:

Выявление рисков (risk identification) – это фаза, позволяющая членам проектной группы вынести на обсуждение всей команды факты наличия рисков.
Анализ рисков (risk analysis) – это фаза преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритизация рисков (risk prioritization) позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы.
Планирование рисков (risk planning) выполняется исходя из информации, полученной на этапе их анализа, и имеет своей целью выработку стратегий, планов и конкретных шагов.
Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов.
Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения.
Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия.

Дисциплина управления подготовкой

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

Определение

Проектные сценарии (scenarios).
Квалификационные требования (competencies).
Профессиональные навыки (proficiencies).

Оценивание

Измерение знаний, умений, способностей (measure knowledge, skills, abilities).
Анализ несоответствий (analyze gaps).
Создание учебных планов (create learning plans).

Корректировка

Обучение (train).
Мониторинг прогресса (track progress).

Осмысление

Анализ результатов (review results).
Управление знаниями (manage knowledge).

Новые версии MSF

Новая версия MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. MSF for CMMI Process Improvement - это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д. Данная версия выглядит, как облегченный вариант 3.0 и ориентирована на продукты Microsoft, а именно Visual Studio 2005 Team System и MS Project.

Литература

Модель процессов MSF, версия 3.1;
Модель проектной группы MSF, версия 3.1;
Дисциплина управления рисками MSF, версия 1.1;
Дисциплина управления проектами MSF, версия 1.1;
Дисциплина управления подготовкой MSF, версия 1.1.

Ресурс: http ://www .microsoft .com /rus /msf

Масштабирование проектных групп

Таблица совместимости ролей

Что такое CMMI

2008-07-02T10:26:00.000-07:00

Продолжаю публиковать конспекты семинаров о методологиях управления проектами.

Хотя этот семинар не о методологии, он о CMMI, а эта модель является скорее набором критериев, чем методологией.

У этого конспекта есть и еще одно отличие от предыдущих. Его подготовил не я.

Я благодарю Алену Федосееву за разрешение опубликовать этот материал в моём блоге.

Оглавление

Что такое СММ

Что такое CMMI

Поэтапный подход

Непрерывный подход

Пример применения CMMI

Определения

Процессные области (Process Area)

Что такое СММ

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

То есть:

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

Результатом работы SEI (Института системного инжиниринга при Университете Карнеги-Меллона) стало появление модели CMM (Capability Maturity Model) для разработки программного обеспечения (версия 0.6 была опубликована в 1990 г., версия 1.0 – в 1991 г., версия 2 – в 1997 году).

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

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

Что такое CMMI

Целью разработки CMMI явилось желание его создателей избежать проблем, связанных с использованием различных моделей CMM. Начиная с 1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:

- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software – SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard – EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model – IPD-CMM)

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

Поэтапный подход

В CMM на соответствие уровню зрелости оценивались ВСЕ процессы организации. Если представлять это диаграммой, то это выглядит следующим образом:

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

Модель зрелости процессов выглядит следующим образом:

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

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

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

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

Уровень зрелости 3 – определенный уровень. В этом случае процессы определены. Установлены стандарты в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Присутствует более детальное описание всех процессов, в котором лучше раскрываются связи и зависимости, знание которых позволяет улучшить управление.

Уровень зрелости 4 – количественно-управляемый уровень. На данном этапе достигнуты все цели предыдущих уровней. Выбраны способы, которые при использовании статистических методов и других количественных техник позволяют контролировать качество выполнения процессов. Самое главное отличие этого этапа от предыдущего заключается в предсказуемости эффективности процессов и возможности ею (эффективностью) управлять.

На уровне 4 определенные процессы количественно контролируются с помощью соответствующих средств и техник.

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

Непрерывный подход

CMMI предоставляет 2 подхода – 2 модели:

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

На диаграмме это выглядит следующим образом:

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

Уровень устойчивости	Название уровня
0	Незавершенный уровень
1	Выполненный уровень
2	Управляемый уровень
3	Определенный уровень
4	Количественно-управляемый уровень
5	Оптимизированный уровень

Разумеется, большинство крупных IT-компаний выбирают именно поэтапное представление. Получив уровень повыше, можно аргументированно объяснять клиенту почему эта компания предпочтительнее, чем компания-конкурент. Однако трудоемкость на проекте, который использует CMMI модель, как минимум увеличивается на 10%-20%.

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

Пример применения CMMI

Определения

Область процессов (Process Area) – набор связанных практик данной области, исполняются для достижения ряда целей, которые считаются важными в контексте улучшения процессов в данной области.

В CMMI области процессов одинаковы для непрерывной и поэтапной репрезентации.

Практики (practices) – это действия, производимые для достижения поставленных целей в данной области процессов.

Практики являются основным конструктивным элементом на основе, которого построена модель CMMI.

Специфические цели (specific goals) – цели, конкретизирующие основную (общую) цель

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

Специфические практики (specific practices) – практики, выполнение которых способствует достижению специфических целей.

Общие практики (generic practices) – практики, выполнение которых способствует достижению общих целей.

Субпрактики (subpractices) – представляют собой детализированные описания, поясняющие специфические и общие практики.

Процессные области (Process Area)

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

Уровень	Описание	Процессные области
5 Оптимизирующий	Continuous Process Improvement	Organizational Innovation and Deployment Causal Analysis and Resolution
4 Количественно управляемый (измеримый)	Quantitative Management	Organizational Process Performance Quantitative Project Management
3 Определенный	Process Standardization	Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management for IPPD Risk Management Integrated Teaming Integrated Supplier Management Decision Analysis and Resolution Organizational Environment for Integration
2 Управляемый	Basic Project Management	Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management
1 Начальный

Вот типичный пример описания специальной цели для процессной области Requirements Management:

SG 1: Requirements are managed and inconsistencies with project plans and work products are identified.

А вот описание специальной практики:

SP 1.3: Manage Requirements Changes. Manage changes to the requirements as they evolve during the project.

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

GG2: The process is institutionalized as a managed process.

Что здесь подразумевается под управляемым процессом? Если вкратце, то это такой процесс, который планируется и выполняется согласно существующей стратегии компании; для выполнения данного процесса нанимаются люди с соответствующими навыками и у которых есть все необходимое для успешного выполнения данного процесса. Кроме того, этот процесс контролируется, проверяется и оценивается согласно своему описанию.

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

GP 2.1: Establish an Organizational Policy

Establish and maintain an organizational policy for planning and performing appropriate process.

GP 2.2: Plan the Process

Establish and maintain the plan for performing appropriate process.

GP 2.3: Provide Resources

Provide adequate resources for performing appropriate process, developing the work products, and providing the services of the process.

GP 2.4: Assign Responsibility

Assign responsibility and authority for performing the process, developing the work products, and providing the services of appropriate process.

GP 2.5: Train People

Train the people performing or supporting appropriate process as needed.

GP 2.6: Manage Configurations

Place designated work products of appropriate process under appropriate levels of configuration management.

GP 2.7: Identify and Involve Relevant Stakeholders

Identify and involve the relevant stakeholders of appropriate process as planned.

GP 2.8: Monitor and Control the Process

Monitor and control appropriate process against the plan for performing the process and take appropriate corrective action.

GP 2.9: Objectively Evaluate Adherence

Objectively evaluate adherence of appropriate process against its process description, standards, and procedures, and address non-compliance.

GP 2.10: Review Status with Higher Level Management

Review the activities, status, and results of appropriate process with higher level management and resolve issues.

6 сигм

2008-06-30T09:12:00.000-07:00

Продолжаю публиковать конспекты семинаров, посвященных методологиям управления проектами. Сегодня пишу о системе 6 сигм (Six Sigma)

Оглавление

Введение в 6 сигм

Статистические основы «Шесть Сигм»

DMAIC (Define-Measure-Analyze-Improve-Control) — методология улучшения существующих процессов.

DFSS — (Design for six sigma) — методология создания новых процессов.

Организационная схема

Принципы 6 сигм

Программное обеспечение для 6 сигм.

Что мне показалось полезным

Практические наработки по числовым методам

Умение сделать и продвигать брэнд

Подход «сверху вниз» к оцениванию проекта

Введение в 6 сигм

Как отмечают многие специалисты, в 6 сигмах нет ничего оригинального. Тоесть это — компиляция ранее имевшихся подходов.

Фактически 6 сигм можно описать четырьмя утверждениями (наиболее сложно — первое, наиболее важно - третье)

Для оценки качества проекта используется средней сложности мат модель, основанная на нормальном распределении отклонения качества изделия от идеала. Модель в итоге выражает количество бракованных изделий через отношение максимально допустимого отклонения от идеала к среднему отклонению. Среднее отклонение называется сигмой. Отношение, к которому надо стремиться по мнению авторов методологии равно 6ти. Отсюда — 6 сигм. При этом отношении количество брака на миллион изделий — 3,4. (Для сравнения при отношении равном трем — 66800 дефектов.)

Вся эта мат модель сама по себе НИЧЕГО не предлагает в плане улучшения качества, потому что в нее не заложено никаких методов собственно улучшения. Грубо говоря, все что следует из этой модели, (которая разрекламирована как ЯДРО подхода) это такой факт: Нужно стремиться выпускать изделия, которые в 6 раз лучше самых плохих допустимых изделий и тогда все будет здорово и никакие случайности будут не страшны. Таким образом, сама мат модель НИКАК не используется в процессе работы над проектом, а служит симпатичной иллюстрацией и придает подходу солидности. (используется только эта цифра 6, полученная раз и навсегда из модели)
Для собственно улучшения процессов, ничего особенного не предлагается. Точнее утверждается, что методология основана на постановке агрессивных краткосрочных целей в борьбе за долгосрочные цели. Что вся работа по улучшению состоит из маленьких проектиков, каждый из которых строится согласно циклу, с умным названием DMAIC (Define-Measure-Analyze-Improve-Control). Подобный же цикл используется в туче других подходов.
Реальным смыслом и рациональным зерном подхода является стремление к полной измеримости всех факторов, влияющих на конечный результат и к построению модели зависимости количества дефектов от каждого из факторов. С последующим выявлением групп, от которых каждый фактор зависит и планированием мероприятий по улучшению наиболее значимых факторов. Создается полное ощущение, что так называемые, черные пояса по 6 сигм — это стандартные хорошие управленцы с некоторым перекосом в сторону измеримости процессов. А все остальное — антураж, созданный для повышения их рыночной стоимости.
Для придания цветистости и зарабатывания на подходе денег, придуманы степени крутости с цветными поясами, как в карате и создана целая индустрия по подготовке этих поясов за большие деньги.

При этом, все вышесказанное не умаляет достоинств специалистов по 6 сигм. Многие из них — очень сильные управленцы. Скорее стоит говорить об удачном маркетинге, сделавшем термин 6 сигм раскрученным. Я бы говорил о 6 сигм, как об одной из профессиональных школ управления с акцентом на применение численных методов. Стоит отметить также большой набор математических моделей проектов, проверенных специалистами этой школы на практике. Эти модели отличает простота и практическая применимость. Хотя, многие из моделей созданы вовсе не в рамках 6 сигм. Хорошие специалисты по 6 сигм являются фактически специалистами в области управления проектами и в области прикладной математики (в основном численных методов и статистического анализа)

Далее немного подробнее.

Статистические основы «Шесть Сигм»

Этот раздел написан не мной, а взят с сайт www.six-sigma.ru. Переписывать своими словами смысла не было. Раздел носит справочный характер и рассказывает подробнее о математической модели из которой получена цифра 6 (из названия методологии). Раздел рассчитан на любознательных, желающих понять эту модель. Практического смысла в этом, как уже отмечалось, не много.

Любой процесс может быть представлен в виде математической модели, где основными параметрами результата процесса выступают среднее значение и стандартное отклонение. Параметр среднее значение отвечает на вопрос как работает процесс в среднем и обозначается символом µ (мю). Стандартное отклонение показывает степень вариабельности результата процесса и обозначается символом σ (сигма).

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

Рисунок 1. Типичный вид плотности и функции нормального распределения

Геометрически, хорошая наглядная картина получается, рассматривая плотность нормального распределения, где среднее значение – это пик плотности распределения, а стандартное отклонение

определяется как расстояние между средним значением и точкой перегиба кривой (рис 2).

Рисунок 2. Среднее значение и стандартное отклонение

Свойства нормального распределения:

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

Рисунок 3. Чем больше сигм процесса укладывается между средним значением и ближайшим контрольным пределом, тем меньше дефектов имеет процесс. Процесс работает на уровне 2,6 сигмы.

Из статистического обоснования известно, что при уровне процесса 4,5 сигм, из миллиона единиц продукции, дефектов будет не более 3,4, и это условие выполняется для стабильных процессов. В настоящих же условиях, поведение процессов может меняться со временем года, временем суток и т.п. (рис. 4).

Рисунок 4. Изменение процесса с течением времени.

Основываясь на эмпирических данных, исследователи пришли к выводу, что отклонения процесса, вызванные его естественной нестабильностью, дают отклонения качества на уровне 1,5 сигма. Таким образом, если целевой уровень качества составляет 4,5 сигма (3,4 дефекта на миллион возможностей), то с учетом перестраховки 1,5 сигма на отклонения, необходимо обеспечивать уровень качества 6 сигм.

Рисунок 5. Уровень качества 6 Сигм.

Таблица пересчета % в сигма уровни с учетом 1,5 сигма сдвига и ДНМВ:

Чем меньше сигм — тем больше дефектов. Оптимальное число сигм — 6. При котором число дефектов на миллион операций — 3,4

При сигма = 3 дефектов будет уже 66800. А при единице — 690 тысяч....

%	Сигма уровни	Дефектов на миллион возможностей	%	Сигма уровни	Дефектов на миллион возможностей
99.9997	6.00	3.4	93.3200	3.00	66800
99.9995	5.92	5	91.9200	2.90	80800
99.9992	5.81	8	90.3200	2.80	96800
99.9990	5.76	10	88.5000	2.70	115000
99.9980	5.61	20	86.5000	2.60	135000
99.9970	5.51	30	84.2000	2.50	158000
99.9960	5.44	40	81.6000	2.40	184000
99.9930	5.31	70	78.8000	2.30	212000
99.9900	5.22	100	75.8000	2.20	242000
99.9850	5.12	150	72.6000	2.10	274000
99.9770	5.00	230	69.2000	2.00	308000
99.9670	4.91	330	65.6000	1.90	344000
99.9520	4.80	480	61.8000	1.80	382000
99.9320	4.70	680	58.0000	1.70	420000
99.9040	4.60	960	54.0000	1.60	460000
99.8650	4.50	1350	50.0000	1.50	500000
99.8140	4.40	1860	46.0000	1.40	540000
99.7450	4.30	2550	43.0000	1.32	570000
99.6540	4.20	3460	39.0000	1.22	610000
99.5340	4.10	4660	35.0000	1.11	650000
99.3790	4.00	6210	31.0000	1.00	690000
99.1810	3.90	8190	28.0000	0.92	720000
98.9300	3.80	10700	25.0000	0.83	750000
98.6100	3.70	13900	22.0000	0.73	780000
98.2200	3.60	17800	19.0000	0.62	810000
97.7300	3.50	22700	16.0000	0.51	840000
97.1300	3.40	28700	14.0000	0.42	860000
96.4100	3.30	35900	12.0000	0.33	880000
95.5400	3.20	44600	10.0000	0.22	900000
94.5200	3.10	54800	8.0000	0.09	920

DMAIC (Define-Measure-Analyze-Improve-Control) — методология улучшения существующих процессов.

Тот же самый сайт www.six-sigma.ru так описывает эту методологию:

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

Основные цели каждого из этапов:

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

DFSS — (Design for six sigma) — методология создания новых процессов.

В отличие от методологии DMAIC подход DFSS (Design for Six Sigma) применяется при разработке новых продуктов или услуг в соответствии с критериями и принципами «Шести сигм».

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

Одна из наиболее распространенных методологий, которые применяются в данном подходе это DMADV:

Define - Определение

Определение цели и масштабов проекта и требований заказчика (как внешнего так и внутреннего).

Measure - Измерение

Измерение потребностей и спецификаций клиентов. Бенчмаркинг в данной отрасли.

Analyze - Анализ

Анализ параметров процесса для достижения соответствия требованиям заказчиков.

Design - Проектирование

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

Verify – Проверка

Проверка разработанного процесса, в том числе на его соответствие нуждам клиента.

Проекты DFSS осуществляются по тем же принципам и с опорой на ту же инфраструктуру, что и проекты совершенствования DMAIC.

Проекты осуществляют межфункциональные команды.

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

На самом деле большой разницы между DMAIC и DMADV я не заметил. Improve-Control в применении к существующим процессам против Design — Verify в применении к вновь сконструированным. Похоже на тавтологию.

Организационная схема

В основе орг схемы -

руководящий совет - который планирует стратегию внедрения, осуществляет выбор и утверждение проектов. Руководство проходит минимальный курс обучения, необходимый для контроля и управления программой «Шесть сигм».
За поддержку проекта и его результаты будет отвечать «чемпион» - один из представителей высшего руководства. Чемпионы проходят 1-2 дневный ознакомительный курс обучения, где большое внимание уделено выбору проектов.
есть парни с цветными поясами, которые овладели статистическими методами и опытом ведения проектов по 6ти сигмам. «Продажа» поясов — основной бизнес консультантов, специализирующихся в этой теме. Собственно, поясов два — черный и зеленый. Отличаются крутизной. Последнее время появляются еще белый и желтый, которые, как я понял, щедро дают людям, что-то слышавшим о 6 сигмах и что-то из этого понявших соответственно.

Принципы 6 сигм

Чистой воды слоганы (кроме принципа №2) , подобранные, чтобы принципов было ровно 6 (по числу сигм) , но все же вот они:

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

Программное обеспечение для 6 сигм.

Есть много готового софта для работы по 6 сигм.

Список здесь. http://www.six-sigma.ru/page_207.html

Что мне показалось полезным

Практические наработки по числовым методам

Ребята с черными поясами наработали немалый опыт применения конкретных числовых методов (например, методов Монте Карло) и массу эмпирических уравнений, которым подчиняются численные характеристики проектов. Они проверили все это статистически и имеют готовые методы, которые позволяют на основе ранее сделанных организацией проектов найти различные коэффициенты, характерные для этой организации и далее, подставив их в уравнения, получать, например, весьма достойные оценки для проектов (в том числе IT проектов).

Хорошо об этом написано , например , в статье (http://software.isixsigma.com/library/content/c030514a.asp)

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

В математике ребята в целом не очень сильны, поэтому уравнения простые и очень приблизительные, но я чувствую, что они полезны.

Умение сделать и продвигать брэнд

Стоит подробнее изучить — как именно авторам удалось, не придумав ничего нового, раскрутить торговую марку «6 сигм» до такой степени. Наработки могут быть полезны в раскрутке своего продукта.

Подход «сверху вниз» к оцениванию проекта

Кроме широко используемого нами подхода снизу вверх (когда проект бьется на задачи и оценивается, а затем оценки суммируются используя PERT + находится критический путь и дается календарная оценка), специалисты по 6 сигм (на самом деле не только они, конечно) активно используют подход сверху вниз, когда оценка дается исходя из числовых характеристик проекта, который надо сделать (к-во строк кода, кэйсов, функций, объектов и т п) и количественных характеристик проектной команды (которые получаются с использованием статистических методов). Подход и используемая математика хорошо описан в той же самой статье (см выше). Очень удобен при раскрутке проекта и наборе статистических данных. Понравилось, что при оценке используются, например эмпирические знания о количестве людей, необходимых на разных стадиях проекта, что позволяет избежать глупых ошибок с оценка длительности проекта (типа проект в человеко-год делается 3мя людьми за 4 месяца). Забавно, что график «потребления людей» практически одинаков для всех проектов и выглядит примерно так:

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

Что такое PRINCE2

2008-06-29T01:18:00.000-07:00

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

Оглавление

Введение

Личные впечатления

Об описание методологии

Процесс и активности

Организационная структура

Business case oriented

О продуктах и проектах

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Управления людьми

Управления поставками и контрактами

Воды

Введение

PRINCE2 — английский стандарт на ведение проектов. Изначально создан для IT проектов, потом расширен для использования в любых проектах.

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

Особенностью стандарта является его масштабируемость. В каждой стадии и подстадии описано, какую ее часть можно опустить, если проект маленький и гигантский масштаб процессов не требуется. С одной стороны, это очень мило, с другой, отмечается появление большого количества так называемых PINO (Prince in name only) проектов, в которых опущено почти все, но они гордо зовутся сделанными по методологии PRINCE2.

Личные впечатления

Писано Itшниками и для Itшников, что бы там не говорили про пригодность для любого проекта.

Причем Itшниками практикующими. Авторы имели личный опыт управления IT проектами. А к самому документу отнеслись как к софту. Очень четко его написали. Воды (в отличие от PMBOK) почти нет. Нет также пространных размышлений что с одной стороны важно то, с другой это, и нужно обладать опытом, чтобы бла бла (этим также изобилует PMBOK)

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

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

Стандарт является методологией, пригодной к непосредственному использованию для выполнения проектов (по крайней мере IT проектов).

Об описание методологии

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

Начато с того что там 8 стадий процесса (например старт проекта, стратегическое управление проектом) и 8 компонентов/аспектов (планирование, управление изменениями и т п).

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

Затем описаны связи между активностями (в итоге получаем некую «трехмерную сеть», как оно в жизни и бывает). Указаны какие из 8ми компонентов (аспектов) являются актуальными для каких из 45ти подстадий. Забавно, что у каждой из 45 подстадий есть уникальный идентификатор из одной буквы (первая в названии стадии) и цифры — (порядковый номер в стадии). Сразу видно руку Itшников. :-)

Наконец, для трех важных компонентов (Планирование, управление изменениями и управление качеством) даны уже пошаговые инструкции - техники, как это можно делать. Ключевое слово — МОЖНО. На самом деле «техники» - конкретные пошаговые инструкции могут быть разными, в рамках стадий. При описании процессов даны все важные моменты, о которых надо помнить, выбирая (или придумывая) ту или иную технику. Очень похоже на интерфейсы и имплементации — процессы это интерфейсы, техники — имплементации. Три стандартные техники — дефолтовые имплементации. Имплементации, кстати, вполне себе пригодные к непосредственному использованию.

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

Процесс и активности

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

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

А при описании активностей часто попадаются ссылки на другие активности, которые должны идти в параллель и с которыми надо обмениваться информацией (артефактами)

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

Организационная структура

Интересен подход PRINCE к оргструктуре проекта.

Есть менеджер проекта в традиционном понимании.

Есть совет проекта (project board), перед которым регулярно отчитывается менеджер. Состоит из 3х человек — Заказчика, Главного пользователя и Главного специалиста. Совет проекта ответственен за принятие стратегических решений. Менеджер проекта обязан отслеживать возможные проблемы и предлагать совету альтернативные решения. Совет решает — какой путь лучше.

Есть служба project assurance цель которой предоставлять независимое мнение о проекте с точки зрения тех же трех групп людей — заказчиков, пользователей и специалистов (в предметной области)

Служба готовит три отчета — buniness report, user report & technical report.

В первый входит отчет о финансовом состоянии проекта и выгодности проекта в целом.

Во второй — отслеживание того, насколько хорошо выполняются требования пользователей

В третий — насколько хорош проект в технологическом плане — туда ли он движется.

В маленьких проектах роль project assurance выполняет совет проекта. В больших это — отдельная группа.

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

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

Стадии и компоненты

Стадии:

Starting Up a Project (SU)

Смысл стадии — понять, а надо ли вообще проект делать. Описать причины проекта в документе Мандат Проекта. Выбрать подход к выполнению проекта.
Initiating a Project (IP)

Здесь описывается Бизнес Кейс проекта, формируется орг структура. Планируется сроки и цена проекта.
Planning (PL)

Планирование и перепланирование проекта. Идет все время жизни проекта.
Directing a Project (DP)

Стратегическое управление проектом. Выполняется Project Board-ом на основе документов, предоставленных менеджером проекта и Project Assurance. Менеджер обязан отслеживать возможные риски и возможности проекта и формулировать вопросы к PB. Желательно, чтобы на них можно было ответить да или нет. PB принимает решения. Причем каждый член PB должен отстаивать свой аспект — бизнес, usability и технологический соответственно.
Controlling a Stage (CS)

Стандартные активности по ежедневному управлению проектами при помощи контура управления. Осуществляются менеджером проекта.
Managing Product Delivery (MP)

Активности по обеспечению создания нужных продуктов в нужные моменты времени. Осуществляются менеджером проекта.
Managing Stage Boundaries (SB)

Активности по подготовке и предоставлению информации Project Boardу.
Closing a Project (CP)

Активности по контролируемому закрытию проекта.

Компоненты :

Business case
Организация
Контроль
Управление рисками
Управление конфигурациаями

Планы
Управление качеством
Управление изменениями

Business case oriented

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

О продуктах и проектах

Забавен «рекурсивный» подход, продвигаемый авторами PRINCE. Например, вместо выделения скажем прототипирования в отдельный этап проекта, утверждается что проекты могут состоять из проектов и прототипирование — отдельный проект, который можно делать по методологии PRINCE. Как отдельный проект может быть выделен проект по пониманию, а нужно ли вообще наш проект делать и тп. Явно прослеживается стремление к обобщению и борьба с расползанием, которого так много в PMBOK

Аналогично, термином «продкут», называют как сам продукт, который надо произвести, так и любую его часть, а также существующие продукты, которые надо задействовать при производстве и продукты, которые при производстве произвести придется (например любой проектный документ — тоже продукт, а написание его можно считать проектом, который можно делать по методологии PRINCE) :-)

При планировании, вместо традиционного WBS используют PBS — Product Breakdown Structure, которая разбивает целевой продукт на непересекающиеся подпродукты (в том числе и проектная документация туда входит)

Чего в PRINCE нет

Описания техник для остальных 5ти из 8ми компонентов

Тоесть для

Business case
Organisation
Controls
Management of Risk
Configuration management

Хотя первые три «разжеваны» очень хорошо, а вторые две сильно зависят от характера проекта.

Для остальных трех техники описаны:

Plans
Quality Management
Change control

Управления людьми

Остаётся вне контекста, кроме описания орг. Структуры. Ничего про мотивацию и т п

Управления поставками и контрактами

Утверждается что, например, заключение контракта - проект, который надо делать по методологии PRINCE2 (см о продуктах и проектах)

Воды

Никаких лишних рассуждений за жизнь