Отправляет email-рассылки с помощью сервиса Sendsay

Программирование, просто о сложном

Рассылка закрыта

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Сентябрь 2009   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Сергей

Статистика

41 подписчиков
0 за неделю
←   Все выпуски   →

Программирование, просто о сложном


Программирование

Просто о сложном

Формирование Product backlog-а проекта

Здравствуйте, уважаемые читатели.

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

И так, мы переходим к организации нашей работы.

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

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

Ознакомившись с требованиями, команда создала следующий список (Product Backlog):

№01 Базовая работа с каталогами (MD, RD, CD), сложность – 3

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

№02 Базовая работа с файлами (MF, DEL), сложность – 1, зависит от №01
№03 Удаление дерева (DELTREE), сложность – 1
№04 Копирование (COPY), сложность – 2
№05 Перемещение (MOVE), сложность – 1, зависит от №04

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

Кстати, вы наверно заметили, что команда еще ничего не знает, что придется реализовывать hard links и soft links. Заказчик обрадует их об этом позже.

В существующем Product backlog-е Product Owner должен выставить приоритеты.
Предположим, что приоритеты оказались следующие:

№01 Базовая работа с каталогами (MD, RD, CD), сложность – 3
№03 Удаление дерева (DELTREE), сложность – 1
№04 Копирование (COPY), сложность – 2
№05 Перемещение (MOVE), сложность – 1, зависит от №04
№02 Базовая работа с файлами (MF, DEL), сложность – 1, зависит от №01

Согласно приоритетам команда будет набирать задания в Sprint Backlog. Длина следующего Sprint-а - неделя. В неделе 5 рабочих дней. Практического опыта работы над этим проектом у нас еще нет, поэтому берем заданий на суммарную сложность 5.
В Sprint взяты задания:

№01 Базовая работа с каталогами (MD, RD, CD), сложность – 3
№04 Копирование (COPY), сложность – 2

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

С уважением,
Сергей.

Анонсы будущих рассылок

  • Первая итерация разработки.
  • Неожиданные изменения требований Product Owner-ом. Рефакторинг кода и как быть к нему готовым.
В избранное