05:00 - 08:30 Сон.
08:30 - 08:50 Завтрак, обед, ужин.
08:50 - 09:30 *
09:30 - 09:50 Common Agenda. : Daily Meeting.
09:50 - 10:00 *
10:00 - 11:10 TimeTracker. : Отчёт.
11:10 - 11:20 Agile. : [agileee.org].
11:20 - 11:30 *
11:30 - 11:40 Работа. : Разное.
11:40 - 12:20 Agile. : [agileee.org].
12:20 - 12:30 Дневник. : Ежедневник.
12:30 - 13:00 Apache Ant.
13:00 - 13:30 Scrum. : Backlog Review Meeting.
13:30 - 14:00 Scrum. : "Ready to develop" state.
14:00 -

---

{12:26} Сегодня, впервые за много лет, я оказался без своего дневника. Обычного, бумажного. Я его попросту не нашёл. Наверное, Максимка куда-то засунул. Потому приходится писать изначально здесь, в электронном, от которого я уже успел отвыкнуть.
Хотя много не напишу. :) Эх, было же когда-то много времени...

---

[Apache Ant. [ant.apache.org].]
{12:37} Цель? Более глубоко изучить Ant. Общие знания у меня есть, простой билд создать могу. Хочется знать больше. Что для этого нужно сделать?
Во-первых, взять в TLW команде их билды и разобраться, как они работают. Миша там хорошую работу провёл, использовал много нетривиальных решений. Интересно будет их проработать.
Во-вторых, почитать чего-нибудь дополнительно. Лучший вариант - книга на русском языке.
{12:50} Книги не обнаружил. Разве что по слишком старой версии. Ладно, обойдусь официальной документацией.

---

[Scrum. : Backlog Review Meeting.]
{12:57} Натолкнулся на такой, вот, совет. Ближе к окончанию спринта проводить митинг относительно списка заданий проекта. Что в этом полезного? С какой целью нужно его проводить?
Задания спринта всегда чётко определёны. Остальные задания из списка проекта этим похвастаться не могут. Но ведь спринт скоро заканчивается. Какие задания будут включены в следующий спринт? Это решает Владелец Продукта. А что, если он сделает это в последний момент? Тогда до начала нового спринта не останется времени на выяснение деталей, из-за чего выполнение заданий подвержено различным рискам.
Если просмотреть задания из списка проекта заранее, до окончания нынешнего спринта, и указать Владельцу Продукта на необходимость дополнить задания из списка необходимой информацией, то шанс начать новый спринт без задержки становится более вероятным.
Таким образом, в спринт должно быть заложено время на рассмотрение заданий, не относящихся к нему. Как это организовать?
Так как на эти задания нельзя выделить слишком много времени, то, вероятно, основная нагрузка должна ложиться на плечи Владельца Продукта. Можно сказать, что в данном случае Команда даёт задания Владельцу Продукта, целью которых является уточнение требований, благодаря которым задания будут выполняться более качественно и без задержек.
Наш нынешний Список Заданий Проекта выглядит плохо. Задания не прописаны правильно. В бОльшей части нужно догадываться о том, что они подразумевают.

---

[Scrum. : "Ready to develop" state.]
{13:34} Перед тем, как приступить к выполнению задания, нужно ясно видеть цель, к которой должны привести результаты. Пользовательские истории, которые записаны в Списке Заданий Проекта, далеко не всегда предоставляют достаточную информацию для этого. Приходится затрачивать дополнительные усилия для выяснения всего необходимого. Если задание уже попало в спринт, который стартовал, то времени не так уж и много. В связи с этим часто возникают ситуации, когда разработчики домысливают то, что не указано явно. Если это домысливание оказалось неправильным, то происходит рассинхронизация полученного результата и ожиданиями заказчика. Как этого избежать? Вернее, попытаться избежать?
Идея такая. Все задания, которые планируются на ближайший спринт(ы), должны обладать статусом "Ready to develop". Критерии присвоения такого статуса вырабатываются совместно Командой и Владельцем Продукта.
Например, должна быть чётко определена цель задания. Она может быть описана в виде Представления Результата (How to Demo). С нею должны быть согласны обе стороны.
Ещё пример, задание должно быть задано в виде пользовательской истории, написанной по шаблону "Я как [РольПользователя] хочу [ПредметХотения] для того чтобы [ПричинаХотения]".
Ещё критерии - наличие значения приоритета от Владельца Продукта и оценки сложности от Команды.
Наверное, можно придумать что-то ещё.

---