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

Принципы ООП очень хорошо описаны тут: 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. О хорошем дизайне.

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

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



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

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

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

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

Во-первых, это означает, что множество публичных методов каждого класса надо мыслить как открытое 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. Работа с багами.

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



Хорошие баги

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

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

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

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

Плохие баги

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать полностью...

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать полностью...

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

Введение

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

Определения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать полностью...

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

В этом документе я попытался описать наиболее раздражающие меня недостатки настольных инструментов планирования проектов. Таких, как 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 методов их критики называют «размывание контекста задачи» или «размывание бизнес целей проекта». ..

Читать полностью...

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

Привет всем.

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

Введение 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	Правки для большей юридической точности	Кузьмин Роман Михайлович

Читать полностью...