http://aefimov.livejournal.com/210078.html

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

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

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

Конечно, можно открыть 5 разных страниц, на которых изменить добавить комментарий, приложить файл, указать затраты времени и т.п., но все эти изменения будут никак не связаны между собой - определить почему изменился deadline или на что было потрачены вот эти 2 часа можно будет только по косвенным признакам.

И несколько примеров использования этого в реальной жизни:

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

- разработчики используют TrackStudio для общения по ходу проекта, но руководство получать оповещение по каждому комментарию не хочет - хочется одно письмо в день, в котором бы содержалась все важные изменения по проекту за сегодня.
В итоге сделали правило подписки на фильтр, согласно которому в 8 утра отправляется письмо, которое содержит все задачи, которые были "resolved" сегодня и собственно само resolved-сообщение с описанием что было сделано.
Если бы не связь между изменением состояния задачи и комментарием, то как выделить нужный комментарий из переписки по проекту - вопрос.

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

Шансы на то, что вышеупомянутая четверка уложится в 3000 дней - примерно 0.01%, т.е. 1 из 10 тысяч.
Шансы уложиться в 3005 дней - порядка 0.02%. Даже шансы уложиться в 3100 дней относительно невелики - порядка 37%.

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


Демо-программа:
http://www.trackstudio.com/cr/loadapp/Load.java

В result.txt показан результат тестового прогона, видна длина очереди незавершенных задач для каждого работника по дням.
http://www.trackstudio.com/cr/loadapp/result.txt

Например, строка
===
Day: 243 Analyst: 2758 Developer: 20 Tester: 16 Writer: 7
==
означает, что на 243 день аналитику осталось проанализировать 2758 задач, у разработчика висит 20 задач, у тестировщика - 16, а у техписателя - 7.

Что интересно:

1) Аналитик закончил работу на 2970 день и уложился в срок, в то время как техписатель сделал последнюю задачу только на 3121 день.

2) Задачи для работников, находящихся в конце списка, поступают волнами. Например, в районе 300-го дня у техписателя в очереди 15 задач, 523 день - 30 задач, 815 день - 33 задачи, ..., 2531 - 53 задачи. При этом между этими пиками есть длительные периоды времени, когда работы у техписателя нет вообще.
Поэтому запас производительности у работников в конце цепочки должна быть больше, чем у работающих в начале.
Чем цепочка связанных задач длиннее - тем сильнее проявляется этот эффект.

3) Предположим, программист у нас хороший, не лодырь - если в какой-то день у него кончаются задачи, а он может сделать больше, то он сам находит задачи и делает их по своему усмотрению. Но т.к. эти дополнительные функции тоже нужно протестировать и описать, то они создают дополнительную нагрузку на (уже перегруженных!) тестировщика и техписателя, поэтому шансы завершить реализацию исходных 3000 задач за 3100 дней падают с 37% до 22%. При этом время нахождения нужных задач в очереди на тестирование и документирование растет. Стремление загрузить всех людей на 100% и ненужная инициатива самих людей - зло.

4) Дробление задач увеличивает производительность работы команды. Например, разобьем тот же объем работ на 12000 задач (x4), соответственно максимальная производительность работника увеличится с 2 до 8 задач в день (средняя - с 1 до 4 задач в день). Шансы на завершение работы за 3100 дней в этом случае вырастают с 37 до 67%.
При этом дополнительные затраты времени аналитика или программиста на переключение между задачами не снижают производительность команды, т.к. они находятся в начале цепочки. "Оптимизация" загрузки людей в начале цепочки путем создания больших задач - зло.

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

Предположим, в компании работают 4 сотрудника - аналитик, программист, тестировщик и техписатель. Им нужно написать проект, который состоит из 3000 отдельных функций (задач), производительность каждого сотрудника - случайная, 0, 1 или 2 задачи в день (средняя - 1 задача в день).

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

Как думаете, какие шансы на то, что эта четверка уложится в 3000 дней ? Ну, ориентировочно, плюс-минус 5% ?

UPD. Продолжение тут: http://maximkr.livejournal.com/18971.html