В настоящий момент трекер успешно фиксирует факт движения задачи (инцидента), при этом еще фиксируются важные изменения в задаче - назначение рамочной задачи, прикрепление документа из электронного архива и т.п. Но для успешного управления необходимы не только фактические данные, не только история, но и планы, т.е. образ будущего. Далее мы рассмотрим один аспект планирования - назначение срока задаче.
2. Что есть исполнение планового срока?
Пусть задаче назначен срок. Как понять, исполнен он или нет? Какое событие, происходящее с задачей, должно фиксировать момент фактического наступления запланированного события? Прежде всего считаем, что:
- у задачи планируется только одна контрольная точка на ее маршруте.
- попадание задачи в любое финальное состояние является наступлением запланированного события, если оно не наступило раньше (не отмечено в задаче как наступившее).
Но одних финальных состояний недостаточно для отслеживания сроков задачи. К примеру, в трекере модельной оснастки наступлением срока будет считаться еще и переход в состояние "Поставить на контроль в 1С", поскольку реально задача будет завершена только после акта разметки, т.е. когда по этой оснастке будет выпущена отливка. Но планируем мы только время изготовления, так что как факт наступления срока добавляем следующую возможность:
- первое попадание задачи в одно из выделенных состояний.
В задаче заводим реквизит факт наступления срока типа "дата", туда записываем эту дату. Кроме того, пишем служебный коммент, в котором отмечаем это событие.
Назначение события как факта исполнения делаем не для задачи, а для диаграммы. Т.е. мы не можем установить, что задача 1 считается исполненной при попадании в состояние 7, а задача 2 - при попадании в состояние 5; нет, правило устанавливается на уровне диаграммы: задача считается исполненной при попадании в любое из состояний 5, 6, 8. Реализовать это можно установкой флажка в состоянии.
3. Виды сроков
Срок типа "конкретная дата" не очень удобен - для отдаленных планов это слишком большая конкретика, удобнее планировать "в ноябре", "в 3 квартале" и т.п. Фактически задаче мы назначаем интервал времени. Поскольку задачи понимаются как нечто достаточно элементарное, то для крупных временных интервалов можно считать, что задача должна начаться и завершиться в этом периоде (требуется еще продумать этот момент).
Мы рассматриваем следующие календарные сроки:
- Дата
- Неделя (№ недели в году + год)
- Месяц (+ год)
- 1-4 неделя месяца (экзотика, но у нас используется в планировании производства)
- 1-3 декада месяца (у нас не используется и пока не делаем)
Кроме календарных сроков, т.е. имеющих жесткие привязки к календарю (дату начала и дату конца), удобно планировать по условным этапам или итерациям. Эти периоды не обязательно имеют даты начала/конца, но мы считаем, что они имеют определенную длительность - к примеру, по две недели. Тогда мы можем спланировать проект и оценить его трудоемкость и сроки в условных периодах, не зная еще даты запуска проекта (начальной даты первого периода). Этап/итерация это специальный объект со следующими свойствами:
- этапы рассматриваются сразу рядами: А1, А2 ... Аn. Относительно этапов в ряду считаем, что они идут один за другим и не пересекаются. Нам потребуется несколько рядов этапов для того, чтобы иметь возможность планировать независимые проекты.
- каждый этап имеет дату начала и дату конца (привязка к календарю), но они могут быть и на начальном этапе планирования будут пустыми. То есть мы создаем ряд этапов, раскидываем задачи проекта по этапам и потом устанавливаем конкретные даты этапам, причем не обязательно всем - можно только начальным, а более поздние пока без календарной привязки.
- для ряда этапов устанавливаем единую плановую длительность этапа - две недели, месяц - как выберем.
4. Назначение сроков задаче
Задаче могут быть назначены несколько сроков из разных рядов: к примеру, месяц Март и 12-я неделя года, этап А3 и этап В8. Из каждого ряда может быть назначен только один срок (что естественно, поскольку периоды в ряду не пересекаются). При назначении срока проверяем, не вступает ли он в конфликт с уже назначенными сроками: так при назначении срока "12-я неделя" мы должны проверить, что она пересекается со сроком "Март".
При назначении этапов А3 и В8 если у них указаны даты начала и конца, то проверяем, если не указаны - можем назначать.
По сути сроком задачи будет пересечение всех назначенных ей сроков, т.е. для задачи можно вычислить дату начала и дату конца. Эти даты не редактируются вручную, а пересчитываются при назначении срока задаче (в том числе при отцеплении задачи от ранее назначенного срока: был Март, сменили на Апрель или вообще убрали привязку к месяцу).
Дата начала не несет особого смысла - мы можем начать задачу и раньше, можем и позже. Важной является лишь дата конца и именно по ней мы будем определять, уложилось ли фактическое выполнение (см. п. 2) или нет.
5. Назначение срока этапу
Сроки этапов подчиняются следующим правилам:
- Этапы в ряду не пересекаются и идут по возрастанию
- При назначении дат начала и конца этапа необходимо учитывать уже назначенные сроки задач, входящих в эти этапы
Второе правило рассмотрим подробнее. При назначении дат начала и конца этапу они должны быть такими, чтобы ни у одной из входящих в этап задачи не возникло несовместимых сроков. Для этого по всем срокам всех задач этого этапа считаем C1 = max(ДатаНачалаk) и C2 = min(ДатаКонцаk). Условиями совместимости дат этапа с уже назначенными сроками будут:
- ДатаНачалаЭтапа < C2
ДатаКонцаЭтапа > C1
6. Специальные операции с рядами этапов
Ограничения предыдущего пункта все равно не позволяют однозначно вычислить даты этапов, а кроме того не проверяется совместимость соседних этапов. Для этого добавляем еще граничные условия от соседних этапов - этапы должны быть последовательны и не пересекаться. У нас есть три варианта расчета:
- Расчет от более ранних этапов к более поздним - расчет от старта проекта
- Расчет от более поздних этапов к ранним - успеть к сроку
- Пересчет единичного этапа, предшествующий и следующий этапы считаем фиксированными
Для рядов этапов надо предусмотреть назначение дат исходя из начальной даты (начала первого этапа) и установленной длительности этапа в ряду. Это удобно, если запускаем новый проект и никакие сроки задачам еще не назначены. Если уже назначены какие-то другие сроки, то сначала надо проверить, не возникнет ли с ними конфликтов.
Также следует предусмотреть при изменении даты начала/конца этапа изменение дат соседних этапов в ряду: либо увеличение/сокращение длительности, либо сдвиг последующих этапов.
7. Взаимозависимость задач
Кроме описанных выше сроков полезно уметь учитывать взаимозависимость задач. К примеру, задача 56 требует того, что описано в задаче 48. Это не значит, что для начала задачи 56 требуется, чтобы была завершена задача 48 - часто достаточно выполнения только части ее. Поэтому рассматриваем эту зависимость как "начало-конец": задача 56 не может завершиться без того, чтобы началась задача 48. на языке сроков это означает следующее: в любом ряду этапов или календарных сроков (месяцев, недель), которые назначены обеим задачам, этап задачи 48 не может быть позже этапа задачи 56. Здесь мы неявно считаем, что задачи достаточно невелики и полностью укладываются в рассматриваемые этапы. Если рассматриваемые этапы достаточно велики (хотя бы неделя), то это вполне корректное предположение.
Соответственно, необходимо сделать следующие механизмы:
- Указание задаче списка предшествующих задач
- Построение дерева зависимых и зависящих задач
- Проверка корректности сроков зависимых задач относительно ряда календарных сроков или ряда этапов - т.е. проверяем, правильно ли раскиданы задачи по месяцам или по этапам
