Г-да, по RUP проект разбивается на фазы, каждая фаза в свою очередь разбивается на итерации, итерации состоят из набора рабочих процессов (требования, анализ, проектирование, разработка, тестирование) плюс дополнительные процессы — планирование перед итерацией и оценка — в конце итерации. В теории всё выглядит красиво и хорошо, но когда я начинаю пытаться применить это к практике — возникают затруднения. Поделитесь, пожалуйста, опытом:
1. кто как разбивал проект на итерации?
1.1. как отличаются процессы внутри итерации в зависимости от принадлежности одной, либо другой фазе ?
1.2 отличаются ли процессы внутри итераций в одной фазе ?
1.3 каждый ли процесс выполняется в каждой итерации ?
1.4 планируются ли результаты итерации ?
1.5 что является результатом итерации ?
1.6 планируется ли срок выполнения итерации ?
2. каким образом проект разбивается на фазы ?
2.1. является ли разбиение системы на подсистемы и разбиение реализации подсистем во времени разбиением на фазы, или это ещё один какой-то термин, скажем, этап ?
2.2. планируются ли результаты фазы ?
2.3. что является результатом фазы ?
2.4. планируется ли срок выполнения фазы ?
Спасибо.
29.11.04 12:52: Перенесено из 'Философия программирования'
Здравствуйте, BalTun, Вы писали:
BT>Г-да, по RUP проект разбивается на фазы, каждая фаза в свою очередь разбивается на итерации, итерации состоят из набора рабочих процессов (требования, анализ, проектирование, разработка, тестирование) плюс дополнительные процессы — планирование перед итерацией и оценка — в конце итерации. В теории всё выглядит красиво и хорошо, но когда я начинаю пытаться применить это к практике — возникают затруднения. Поделитесь, пожалуйста, опытом:
Общее замечание — всё зависит от конкретного проекта, команды, заказчика и внешних обстоятельств.
То, что я описываю ниже относится к проекту на полгода-год, для команды в 3-10 человек и при вменяемом заказчике.
BT>1. кто как разбивал проект на итерации?
Обычно итерация от 2 недель до 4-5. Можно и стоит делить на равные временные промежутки, а можно — две-три коротких итерации (развитие) — две длинных (конструирование) и две коротких (передача).
BT> 1.1. как отличаются процессы внутри итерации в зависимости от принадлежности одной, либо другой фазе ?
Чем рашьше — тем больше проектировани и меньше тестирования и чем дальше — тем наоборот — проектирования меньше, тестирования больше. Но тут много неизвестных — например как часто заказчик меняет требования... BT> 1.2 отличаются ли процессы внутри итераций в одной фазе ?
От чего? BT> 1.3 каждый ли процесс выполняется в каждой итерации ?
В общем случае — да. В конкретном — см. выше. BT> 1.4 планируются ли результаты итерации ?
Да, в том и смысл. BT> 1.5 что является результатом итерации ?
Определённый выход в виде функций системы — реализованных в коде, а так же набор других артифактов проекта — запланированных на данную итерацию. BT> 1.6 планируется ли срок выполнения итерации ?
Не просто планируется. Его рекомендуется жёстко фиксировать. Это суть RUP — так как в противном случае теряется контроль за выполнением проекта.
BT>2. каким образом проект разбивается на фазы ?
Общее замечание — фазы носят скорее описательный (возможно контрольный) характер. Т.е. оглядываясь назад ты понимаешь — что вот она завершилась стадия развития, а вот — стадия конструирования. Заранее предвидеть этого не возможно. Тем более что смена фаз может произойти по середине итерации. BT> 2.1. является ли разбиение системы на подсистемы и разбиение реализации подсистем во времени разбиением на фазы, или это ещё один какой-то термин, скажем, этап ?
Это вообще ортогональная — т.е. совершенно не связанная с RUP вещь. Есть декомпозиция системы на модули — а есть вопрос — какие из этих модулей будут реализованы в рамках данной и (возможно и предварительно) — следующей итерации. BT> 2.2. планируются ли результаты фазы ? BT> 2.3. что является результатом фазы ? BT> 2.4. планируется ли срок выполнения фазы ?
См. выше. Повторюсь — фазы — это скорее некий взгляд на состояние проекта, возможно — как средство убедиться что все в порядке. Ни они сами не их "результаты" — никак не планируются. Скажем есть фаза развития — т.е. когда требования к системе активно уточняются, а сама система — активно проектируется. В какой то момент — основное уже ясно — архитектура и контуры системы ясны — остаётся методично воплощать оставшееся. Это собственно и есть переход от фазы развития к фазе конструирования.
Вообще возникает впечатление, что вы пытаетесь воспринять RUP — как классический водопад, т.е. все распланировать заранее — от начала проекта и до его конца...
Андрей, большое спасибо за здравый ответ.
см. ниже
BT>>1. кто как разбивал проект на итерации? AF> Обычно итерация от 2 недель до 4-5. Можно и стоит делить на равные временные промежутки, а можно — две-три коротких итерации (развитие) — две длинных (конструирование) и две коротких (передача).
BT>> 1.1. как отличаются процессы внутри итерации в зависимости от принадлежности одной, либо другой фазе ? AF> Чем рашьше — тем больше проектировани и меньше тестирования и чем дальше — тем наоборот — проектирования меньше, тестирования больше. Но тут много неизвестных — например как часто заказчик меняет требования... BT>> 1.2 отличаются ли процессы внутри итераций в одной фазе ? AF> От чего?
Я имел ввиду от соответствующих процессов в другой итерации этой же фазы, но в свете Вашего описания фазы, видимо этот вопрос отпадает, хотя если есть другие мнения — пожалуйста высказывайте.
BT>> 1.3 каждый ли процесс выполняется в каждой итерации ? AF> В общем случае — да. В конкретном — см. выше. BT>> 1.4 планируются ли результаты итерации ? AF> Да, в том и смысл. BT>> 1.5 что является результатом итерации ? AF> Определённый выход в виде функций системы — реализованных в коде, а так же набор других артифактов проекта — запланированных на данную итерацию.
Т.е. правильно ли я понимаю, что дело происходи примерно так: мы выявляем, что необходимо реализовать определенную функциональность вообще, из этого выделяем приоритетную функциональность и декларируем, что по окончании фазы должна быть реализована эта функциональность? После этого выполняем фазу и в идеале получаем на выходе документацию и код по данной функциональностью, в следующей итерации добавляем реализуемую функциональность и по результатам оценки исправляем реализованную ?
Если так, то в таком случае возникает пара вопросов:
1. как можно определить на этапе планирования первоначальных итераций результат в виде функциональности, если работа на первых итерациях как раз делает наибольший упор на выяснении необходимой к реализации функциональности ?
2. если функциональность реализована, и мы занимаемся следующей, то видимо так скажим следующий планируемый набор действий — уже не итерация, т.к. нет повторения, работы над теми же требованиями, это сродни разбиению на подсистемы, что как мы выяснили не имеет отношения к итерациям. В чём я ошибаюсь ?
BT>> 1.6 планируется ли срок выполнения итерации ? AF> Не просто планируется. Его рекомендуется жёстко фиксировать. Это суть RUP — так как в противном случае теряется контроль за выполнением проекта.
Можно поподробнее о фиксации, что фиксируется, каким образом...
Поясню желания более подробного объяснения:
допустим мы фиксируем в основном время итерации и функциональность, которая должна быть реализована в коде к этому времени. За дело берутся аналитики, выясняют требования, появляются вопросы, они опять выясняют требования, вопросов ещё больше и на вопрос ПМ, готовы ли выходные документы для проектировщиков, либо девелоперов (зависи от проекта и оргструктуры) ответ — не готово, итерация близится к завершению, а результатов в виде кода нет.
Либо другой вариант, того, что выяснили аналитики не хватает на написание какого-то законченного куска кода, либо на то, чтобы можно было показать что-то пользователям, являющимся оценивающими итерацию.
Третий вариант — немного из другой области, но тоже хотелось бы узнать, как решается — аналитики пишут артифакты на небольшой кусок кода, причём если его считать законченным — т.е. чтобы его показать, нужно смастерить определенный UI, как-то довести до целостности код, и видимо при добавлении функциональности 80% того, что сделано придётся изменить, дополняя. Хотя с другой стороны, если бы в конце итерации не нужно было бы оценивать результат, возможно не нужно было бы и создавать UI и приводить код к какой-то целостности... сложно это объяснить чётче, но надеюсь понимаете, что я хочу сказать. Вобщем серьезно увеличиваются трудозатраты.
BT>>2. каким образом проект разбивается на фазы ? AF> Общее замечание — фазы носят скорее описательный (возможно контрольный) характер. Т.е. оглядываясь назад ты понимаешь — что вот она завершилась стадия развития, а вот — стадия конструирования. Заранее предвидеть этого не возможно. Тем более что смена фаз может произойти по середине итерации. BT>> 2.1. является ли разбиение системы на подсистемы и разбиение реализации подсистем во времени разбиением на фазы, или это ещё один какой-то термин, скажем, этап ? AF> Это вообще ортогональная — т.е. совершенно не связанная с RUP вещь. Есть декомпозиция системы на модули — а есть вопрос — какие из этих модулей будут реализованы в рамках данной и (возможно и предварительно) — следующей итерации. BT>> 2.2. планируются ли результаты фазы ? BT>> 2.3. что является результатом фазы ? BT>> 2.4. планируется ли срок выполнения фазы ? AF> См. выше. Повторюсь — фазы — это скорее некий взгляд на состояние проекта, возможно — как средство убедиться что все в порядке. Ни они сами не их "результаты" — никак не планируются. Скажем есть фаза развития — т.е. когда требования к системе активно уточняются, а сама система — активно проектируется. В какой то момент — основное уже ясно — архитектура и контуры системы ясны — остаётся методично воплощать оставшееся. Это собственно и есть переход от фазы развития к фазе конструирования. AF> Вообще возникает впечатление, что вы пытаетесь воспринять RUP — как классический водопад, т.е. все распланировать заранее — от начала проекта и до его конца...
Как раз наоборот, хочу выявить отличия, в чём, надеюсь, мне помогут более опытные коллеги.
По поводу не планирования до конца, если не планировать до конца, а планировать только внутри итерации, то каков критерий достижения достаточно качественного продукта ? Только сроки ? Ведь заказчик в таком случае может постоянно добавлять требования и количество итераций будет стремиться к бесконечности.
Кстати, как определяется, в какой момент подписывается ТЗ, в какой спецификация и другая проектная документация ? Ведь опять же можно до бесконечности наращивать функциональность от итерации к итерации.
Спасибо.
Здравствуйте, BalTun, Вы писали:
BT>>> 1.5 что является результатом итерации ? AF>> Определённый выход в виде функций системы — реализованных в коде, а так же набор других артифактов проекта — запланированных на данную итерацию. BT>Т.е. правильно ли я понимаю, что дело происходи примерно так: мы выявляем, что необходимо реализовать определенную функциональность вообще, из этого выделяем приоритетную функциональность и декларируем, что по окончании фазы должна быть реализована эта функциональность? После этого выполняем фазу и в идеале получаем на выходе документацию и код по данной функциональностью, в следующей итерации добавляем реализуемую функциональность и по результатам оценки исправляем реализованную ?
Всё правильно, но только речь идёт об ИТЕРАЦИИ, а не фазе. Итерация — шаг процесса. Фаза — всего лишь некоторое название промежутка времени, начало и окончание которого могут сопадать, а могут и не совпадать с началом и, особенно, окночанием итерации.
BT>Если так, то в таком случае возникает пара вопросов: BT>1. как можно определить на этапе планирования первоначальных итераций результат в виде функциональности, если работа на первых итерациях как раз делает наибольший упор на выяснении необходимой к реализации функциональности ?
Никак. Вы всё время пытаетесь свести процесс от недетерминированного (т.е. не предсказуемого, по крайней мере полностью) к детерминированному, т.е. проще говоря рассматривать RUP как водопад. Вот что реально можно сделать — распланировать часть функциональности на первую итерацию и, примерно, на следующую, а так же сделать пробный, пилотный план проект в целом. Однако сроки в этом плане — фикция. Он предназначен просто для того, что бы задать направление движения. По окнчанию первой итерации — создаётся подробный план на следующую, возможно — менее детальный — ещё на одну и корректируется с новым видением и накопленным опытом план проекта в целом. Ранее чем 2-3 итерации ни о каком реальном плане проекта в целом говорить просто не реально. Исключение составляют детерминированные проекты — т.е. полностью аналогичные уже сделанным, которые можно распланировать достаточно точно от начала и до конца. Но для таких проектов — RUP — далеко не самое эффективное решение.
BT>2. если функциональность реализована, и мы занимаемся следующей, то видимо так скажим следующий планируемый набор действий — уже не итерация, т.к. нет повторения, работы над теми же требованиями, это сродни разбиению на подсистемы, что как мы выяснили не имеет отношения к итерациям. В чём я ошибаюсь ?
В том, что итерации маленькие (относительно масштабов проекта в целом) — и в чём суть процесса — вы не реализуете полнностью K модулей из N на каждой итерации, получив в итоге целое — как это происходит при создании системы поэтапно и помодульно. Вместо этого в RUP (и UP вообще) — на каждой итерации реализуется большая или меньшая часть функциональности каждого из модулей системы — т.е. одновременна растёт система в целом. И над кадым модулем вы работаете на протяжении нескольких итераций. При этом конечно может получиться, что над какими то модулями в течении итерации работы вообще нет (особенно часто так бывает в начале и конце проекта), или же на данной итерации модуль может быть завершён полностью. Но это исключения из основного правила.
AF>> Не просто планируется. Его рекомендуется жёстко фиксировать. Это суть RUP — так как в противном случае теряется контроль за выполнением проекта. BT>Можно поподробнее о фиксации, что фиксируется, каким образом... BT>Поясню желания более подробного объяснения: BT>допустим мы фиксируем в основном время итерации и функциональность, которая должна быть реализована в коде к этому времени. За дело берутся аналитики, выясняют требования, появляются вопросы, они опять выясняют требования, вопросов ещё больше и на вопрос ПМ, готовы ли выходные документы для проектировщиков, либо девелоперов (зависи от проекта и оргструктуры) ответ — не готово, итерация близится к завершению, а результатов в виде кода нет.
Ошибка в исходной посылке. Требования к текушей итерации фиксируются и на протяжении итерации не меняются. Если некую функцию в срок — т.е. к назначенной дате окончания итерации сделать не успевают — значит её не делают вообще или не делают в полном объеме. НО! В дату окончания итерации обязательно появляется релиз системы и артефакты — результат итерации. В этом СУТЬ UP. Если начать во время итерации сдвигать сроки или изменять требования — контроль над процессом будет полностью или частично утерян.
А вот по зварешению итерации — берутся те требования, которые вытрясли из заказчика аналитики — за прошедшее с начала итерации время, заказчик смотрит на результат и выдвигает новые требования — и из всего этого — формируются требования для следующей итерации.
Кстати именно по этой причине — причине фиксации требований — итерации и должны быть достаточно короткими.
BT>Либо другой вариант, того, что выяснили аналитики не хватает на написание какого-то законченного куска кода, либо на то, чтобы можно было показать что-то пользователям, являющимся оценивающими итерацию.
Вот потому — пишут в течение итерации — что поняли и так как поняли, а потом показывают то, что получилось — заказчику. Это его или устроит или позволит собраться с мыслью.
BT>Третий вариант — немного из другой области, но тоже хотелось бы узнать, как решается — аналитики пишут артифакты на небольшой кусок кода, причём если его считать законченным — т.е. чтобы его показать, нужно смастерить определенный UI, как-то довести до целостности код, и видимо при добавлении функциональности 80% того, что сделано придётся изменить, дополняя. Хотя с другой стороны, если бы в конце итерации не нужно было бы оценивать результат, возможно не нужно было бы и создавать UI и приводить код к какой-то целостности... сложно это объяснить чётче, но надеюсь понимаете, что я хочу сказать. Вобщем серьезно увеличиваются трудозатраты.
Всё правильно и закономерно. Если пользователь не может чётко представить — что ему нужно и сказать об этом Вам — то какой ещё может быть путь, кроме как делать что-то — показывать, корректировать и так до тех пор — пока он не будет доволен? И, естественно, это стоит дороже, чем если бы пользователь, аки провидец сказал сразу и точно всё, что он хочет.
AF>> Вообще возникает впечатление, что вы пытаетесь воспринять RUP — как классический водопад, т.е. все распланировать заранее — от начала проекта и до его конца... BT>Как раз наоборот, хочу выявить отличия, в чём, надеюсь, мне помогут более опытные коллеги. BT>По поводу не планирования до конца, если не планировать до конца, а планировать только внутри итерации, то каков критерий достижения достаточно качественного продукта ? Только сроки ? Ведь заказчик в таком случае может постоянно добавлять требования и количество итераций будет стремиться к бесконечности.
А вот тут зависит от заказчика. Если у него лимит — сроки, значит они и ограничивают качество продукта — что успели — то успели. Пример — Excel 5. Однако как правило лимита в явном виде нет и процесс продолжается до тех пор, пока заказчик не будет доволен или не решит, что результат его устраивает. BT>Кстати, как определяется, в какой момент подписывается ТЗ, в какой спецификация и другая проектная документация ? Ведь опять же можно до бесконечности наращивать функциональность от итерации к итерации.
Именно. Потому ТЗ подписывается на итерацию. Это удобно и Вам и заказчику — так как речь идёт о вполне понятных и обозримых вещах. А функциональность действительно можно наращивать бесконечно, просто в какой то момент заказчик поймёт, что функционала достаточно для эффективного решения его бизнес задач. BT>Спасибо.
>Именно. Потому ТЗ подписывается на итерацию. Это удобно и Вам и заказчику — так как речь идёт о вполне >понятных и обозримых вещах. А функциональность действительно можно наращивать бесконечно, просто в >какой то момент заказчик поймёт, что функционала достаточно для эффективного решения его бизнес задач.
Из сказанного видется такой вывод, что фиксировать сроки и, соответственно, стоимость довольно сложно, но ведь в большинстве своём стоимость фиксируется в начале проекта, также, как и сроки. Что скажете на этот счёт ?
И ещё, правильно ли я понял, что по сказанному получается, что формирование требований как рабочий процесс находится между процессами оценки и планирования, хотя в литературе по RUP этот этап между планированием и проектированием...
т.е. по вашему: оценка->выявление требований и выбор из них для следующего этапа->планирование, фиксация следующей итерации, в частности подписание части ТЗ->проектирование->разработка->тестирование->оценка
по литературе:
оценка->планирование->требования->проектирование->разработка->тестирование->оценка
Здравствуйте, BalTun, Вы писали:
>>Именно. Потому ТЗ подписывается на итерацию. Это удобно и Вам и заказчику — так как речь идёт о вполне >>понятных и обозримых вещах. А функциональность действительно можно наращивать бесконечно, просто в >>какой то момент заказчик поймёт, что функционала достаточно для эффективного решения его бизнес задач.
BT>Из сказанного видется такой вывод, что фиксировать сроки и, соответственно, стоимость довольно сложно, но ведь в большинстве своём стоимость фиксируется в начале проекта, также, как и сроки. Что скажете на этот счёт ?
Большинство начальников воспринимают это именно так. Особенно если они не имели дело с разработками до того. В действительности — если чуть чуть подумать — то сроки и стоимости работ можно фиксировать, только в следующих случаях:
— вы уже делали несколько подобных проектов и можете с высокой точностью распланировать и оценить трудозатраты (что бывает редко), при этом заказчик не влазит по среди проекта с ценными изменениями (что бывает ещё реже)
— вы выставляете сроки и счёт, которые покрывают все возможные затраты по проекту — даже при худшем развитии событий, т.е. проект получается в разы дороже — чем обычно (что бывает крайне редко)
— заказчик в состоянии выдать абсолютно точное ТЗ, которое не будет меняться хоть сколько-нибудь заметно в ходе проекта (очень, очень редко), а вы — имея опыт реализации подобных проектов или хотя бы каждой из частей проекта — можете с высокой точностью оценить затраты (очень сомнительно)
Во всех остальных случаях — т.е. как правило — вы находитесь в ситуации, когда заказчик толком не знает, чего именно он хочет, а вы, естественно по этой причине (как и по ряду других) — не можете ему сказать, когда он это получит и сколько это будет стоить. Итеративных процесс — это выход из данной ситуации — когда вам не надо договариваться о том, о чём вы просто не можете договориться, а когда заказчик может вам платить частями — за итерацию, а вы — показывать ему результаты итераций — сразу же получая от него уточнения, которые позволяют уточнить — что нужно делать.
На практике — и это сильная сторона RUP — уже через пару итераций становятся ясны основные контуры системы — а так же примерные сроки и примераная стоимость (сточностью +/-10%) — и часто оказывается, что это на 50% отличается от первоначальной оценки сроков, стоимости и функционала. Оценка сроков в IT проекте — это тоже работа и её стоимость сопоставима (хотя и меньшая по стоимости) со стоимостью проекта. Вот на первых итерациях её то и делают.
BT>И ещё, правильно ли я понял, что по сказанному получается, что формирование требований как рабочий процесс находится между процессами оценки и планирования, хотя в литературе по RUP этот этап между планированием и проектированием...
Это чистой воды водопадная (детерминированная) терминология. В RUP нет этапов сбора требований и планирования. Вообще нет и принципиально быть не может. Есть процесс сбора требований, планирования, оценки, управления проектом и т.д. — и эти процессы продолжаются с той или иной интенсивностью весь проект. Естественно некоторые процессы интенсивнее в начале, некоторые — в конце, некоторые в середине.
BT>т.е. по вашему: оценка->выявление требований и выбор из них для следующего этапа->планирование, фиксация следующей итерации, в частности подписание части ТЗ->проектирование->разработка->тестирование->оценка BT>по литературе: BT>оценка->планирование->требования->проектирование->разработка->тестирование->оценка
Именно! Вы уверены, что внимательно читали литературу? У вас получилось, что вы сначала планируете, а потом собираетесь выяснять требования — что собственно вы должны были делать? Вы уверены что авторы нормальных книг по RUP стали бы такое советовать?
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, BalTun, Вы писали:
>>>Именно. Потому ТЗ подписывается на итерацию. Это удобно и Вам и заказчику — так как речь идёт о вполне >>>понятных и обозримых вещах. А функциональность действительно можно наращивать бесконечно, просто в >>>какой то момент заказчик поймёт, что функционала достаточно для эффективного решения его бизнес задач.
BT>>Из сказанного видется такой вывод, что фиксировать сроки и, соответственно, стоимость довольно сложно, но ведь в большинстве своём стоимость фиксируется в начале проекта, также, как и сроки. Что скажете на этот счёт ? AF> Большинство начальников воспринимают это именно так. Особенно если они не имели дело с разработками до того. В действительности — если чуть чуть подумать — то сроки и стоимости работ можно фиксировать, только в следующих случаях: AF> — вы уже делали несколько подобных проектов и можете с высокой точностью распланировать и оценить трудозатраты (что бывает редко), при этом заказчик не влазит по среди проекта с ценными изменениями (что бывает ещё реже) AF> — вы выставляете сроки и счёт, которые покрывают все возможные затраты по проекту — даже при худшем развитии событий, т.е. проект получается в разы дороже — чем обычно (что бывает крайне редко) AF> — заказчик в состоянии выдать абсолютно точное ТЗ, которое не будет меняться хоть сколько-нибудь заметно в ходе проекта (очень, очень редко), а вы — имея опыт реализации подобных проектов или хотя бы каждой из частей проекта — можете с высокой точностью оценить затраты (очень сомнительно) AF> Во всех остальных случаях — т.е. как правило — вы находитесь в ситуации, когда заказчик толком не знает, чего именно он хочет, а вы, естественно по этой причине (как и по ряду других) — не можете ему сказать, когда он это получит и сколько это будет стоить. Итеративных процесс — это выход из данной ситуации — когда вам не надо договариваться о том, о чём вы просто не можете договориться, а когда заказчик может вам платить частями — за итерацию, а вы — показывать ему результаты итераций — сразу же получая от него уточнения, которые позволяют уточнить — что нужно делать.
Честно говоря я слабо представляю себе тендер, выигранный с комм. предложением, составленным по такому принципу.И если как Вы говорили выше итерация от 2х недель до 5ти, то получается, что заказчик каждые 2недели — месяц должен подписывать ТЗ и платить за выполненную итерацию ? Это должен быть очень терпеливый заказчик, на мой взгляд.
AF> На практике — и это сильная сторона RUP — уже через пару итераций становятся ясны основные контуры системы — а так же примерные сроки и примераная стоимость (сточностью +/-10%) — и часто оказывается, что это на 50% отличается от первоначальной оценки сроков, стоимости и функционала. Оценка сроков в IT проекте — это тоже работа и её стоимость сопоставима (хотя и меньшая по стоимости) со стоимостью проекта. Вот на первых итерациях её то и делают.
Т.е. первые итерации мы пишем оценку стоимости и сроков, после этого их закрепляем договором и больше не изменяем, или всё-же как-то впоследствии изменяем ?
BT>>И ещё, правильно ли я понял, что по сказанному получается, что формирование требований как рабочий процесс находится между процессами оценки и планирования, хотя в литературе по RUP этот этап между планированием и проектированием... AF> Это чистой воды водопадная (детерминированная) терминология. В RUP нет этапов сбора требований и планирования. Вообще нет и принципиально быть не может. Есть процесс сбора требований, планирования, оценки, управления проектом и т.д. — и эти процессы продолжаются с той или иной интенсивностью весь проект. Естественно некоторые процессы интенсивнее в начале, некоторые — в конце, некоторые в середине.
Вот, кстати, как протикает работа конкретного специалиста внутри итерации, т.е. допустим, что мы запланировали 3 требования на итерации. Сначала аналитики пишут на них спецификацию, потом проектировщики пишут свою спецификацию, потом дизайнеры UI пишут свою спецификацию, потом девелоперы пишут по всему этому код потом тестеры его тестят, да ? Тогда что делают тестеры, когда аналитики пишут спецификацию, что делают дизайнеры UI, когда они отдали UI в разработку ?
BT>>т.е. по вашему: оценка->выявление требований и выбор из них для следующего этапа->планирование, фиксация следующей итерации, в частности подписание части ТЗ->проектирование->разработка->тестирование->оценка BT>>по литературе: BT>>оценка->планирование->требования->проектирование->разработка->тестирование->оценка AF> Именно! Вы уверены, что внимательно читали литературу? У вас получилось, что вы сначала планируете, а потом собираетесь выяснять требования — что собственно вы должны были делать? Вы уверены что авторы нормальных книг по RUP стали бы такое советовать?
Не буду приводить цитаты из книг, по моему более весомо — картинка из первоисточника (RUP). Врут?
Здравствуйте, BalTun, Вы писали:
AF>> Во всех остальных случаях — т.е. как правило — вы находитесь в ситуации, когда заказчик толком не знает, чего именно он хочет, а вы, естественно по этой причине (как и по ряду других) — не можете ему сказать, когда он это получит и сколько это будет стоить. Итеративных процесс — это выход из данной ситуации — когда вам не надо договариваться о том, о чём вы просто не можете договориться, а когда заказчик может вам платить частями — за итерацию, а вы — показывать ему результаты итераций — сразу же получая от него уточнения, которые позволяют уточнить — что нужно делать. BT>Честно говоря я слабо представляю себе тендер, выигранный с комм. предложением, составленным по такому принципу.И если как Вы говорили выше итерация от 2х недель до 5ти, то получается, что заказчик каждые 2недели — месяц должен подписывать ТЗ и платить за выполненную итерацию ? Это должен быть очень терпеливый заказчик, на мой взгляд.
Это так. Вообще в книгах по RUP неявно подразумевается ситуация, когда у Вас уже есть контракт и заказчик, готовый работать в таком стиле. Из жизни — делается следующий трюк: предложение делается как обычно (сроки, цена и т.д.), а дальше заказчик втягивается в процесс — и вот тут RUP не заменим — и если компания работает хорошо — то он будет доволен и у него будет более чем достаточно причин забыть о начальном договоре (например банальное изменение требований)
AF>> На практике — и это сильная сторона RUP — уже через пару итераций становятся ясны основные контуры системы — а так же примерные сроки и примераная стоимость (сточностью +/-10%) — и часто оказывается, что это на 50% отличается от первоначальной оценки сроков, стоимости и функционала. Оценка сроков в IT проекте — это тоже работа и её стоимость сопоставима (хотя и меньшая по стоимости) со стоимостью проекта. Вот на первых итерациях её то и делают. BT>Т.е. первые итерации мы пишем оценку стоимости и сроков, после этого их закрепляем договором и больше не изменяем, или всё-же как-то впоследствии изменяем ?
В общем случае как раз изменяем (уже хотя бы потому, что требования всё время меняются). Просто точность оценок гораздо выше. Хотя, если требования зафиксированы, а каркас системы и наиболее рискованные её части проработаны — то сроки и стоимость можно фиксировать.
AF>> Это чистой воды водопадная (детерминированная) терминология. В RUP нет этапов сбора требований и планирования. Вообще нет и принципиально быть не может. Есть процесс сбора требований, планирования, оценки, управления проектом и т.д. — и эти процессы продолжаются с той или иной интенсивностью весь проект. Естественно некоторые процессы интенсивнее в начале, некоторые — в конце, некоторые в середине. BT>Вот, кстати, как протикает работа конкретного специалиста внутри итерации, т.е. допустим, что мы запланировали 3 требования на итерации. Сначала аналитики пишут на них спецификацию, потом проектировщики пишут свою спецификацию, потом дизайнеры UI пишут свою спецификацию, потом девелоперы пишут по всему этому код потом тестеры его тестят, да ? Тогда что делают тестеры, когда аналитики пишут спецификацию, что делают дизайнеры UI, когда они отдали UI в разработку ?
Ещё раз повторюсь — все процессы идут паралельно. Вы же описали чисто последовательную модель — причём явно срисованную с крупного проекта по водопаду. Да, иногда в очень крупных проектах, где итерация большая — несколько месяцев всё делаеют именно так. Но в обычных проектах с итерацией в месяц-полтора все горздо проще. Аналитики анализируют требования на следующую итерацию, с учётом результатов предидущих итерации и текущей. Проектировщики — разрабатывают архитектуру того, что будет сделано на следующей итерации. Тестеры — тестируют код всё время — что бы находить ошибки сразу, а не устраивать свалку потом. К концу итерации процессы сходятся (за этим должен следить ПМ).
BT>>>т.е. по вашему: оценка->выявление требований и выбор из них для следующего этапа->планирование, фиксация следующей итерации, в частности подписание части ТЗ->проектирование->разработка->тестирование->оценка BT>>>по литературе: BT>>>оценка->планирование->требования->проектирование->разработка->тестирование->оценка AF>> Именно! Вы уверены, что внимательно читали литературу? У вас получилось, что вы сначала планируете, а потом собираетесь выяснять требования — что собственно вы должны были делать? Вы уверены что авторы нормальных книг по RUP стали бы такое советовать? BT>Не буду приводить цитаты из книг, по моему более весомо — картинка из первоисточника (RUP). Врут? BT>
Конечно врут. Точнее не они — а переводчики и интерпретаторы. Ведь понимание этой диаграммы зависит от того, как понимать слово требования — что именно за ним стоит. А стоит за ним сбор требований на следующую итерацию. Более того, диаграмма вообще не совсем верна, т.к. процесс планирования в ней показан один в начале проекта. При том на диаграмме же указано, что есть начальное планирование и есть планирование итераций. Т.е. очевидно стрелка планирования, как и стрелка deployment, кстати, должна быть включена в круг — символизирующий итерацию. Это следует со всей очевидностью из текста. Просто смысл диаграммы немножко другой, нежели подробное и детальное изображение всех этапов процесса. Её смысл — демонстрация основных процессов — костяка, на котором строится RUP. Если посмотреть на неё с такой точки зрения, стновится понятно, что они хотели показать. Основной (но не единственный!) процесс в начале проекта — это планирование. Что они и показали. Там так же есть и предварительные оценки и проектирование и т.д., но основной — планирование. И почему это так вы сами прекрасно объяснили, когда говорили про тендер. Основные процессы во время итераций — это: Оценка результатов предидущей операции, планирование итерации, выбор требований и их анализ на текущую итерацию, анализ выбранных требований и проектирование системы, реализация, затем тестирование во время которого происходит поставка дистрибутива, но оно само продолжается и наконец — оценка результатов итерации. Причём заметьте — надписей больше, чем стрелок. Это не случайно — вам показывают тем самым, что процессы в действительности паралельны. Разработчики не ждут, пока всё будет спроектировано до конца, как только некий кусок спроектирован — они начинают работу над ним, а проектировщики работают дальше.
AF> Ещё раз повторюсь — все процессы идут паралельно. Вы же описали чисто последовательную модель — причём явно срисованную с крупного проекта по водопаду. Да, иногда в очень крупных проектах, где итерация большая — несколько месяцев всё делаеют именно так. Но в обычных проектах с итерацией в месяц-полтора все горздо проще. Аналитики анализируют требования на следующую итерацию, с учётом результатов предидущих итерации и текущей. Проектировщики — разрабатывают архитектуру того, что будет сделано на следующей итерации. Тестеры — тестируют код всё время — что бы находить ошибки сразу, а не устраивать свалку потом. К концу итерации процессы сходятся (за этим должен следить ПМ).
Отлично, единственное, видимо Вы хотели сказать, что только требования опережают итерацию, а остальные процессы уже по данной итерации, т.е. проектировщики создают архитектуру на требования, запланированные на данную итерацию (а не на следующую). А требования пишутся на следующую итерацию (т.к. на эту они уже запланированы) и не только на следующую, т.к. мы не знаем заранее, какие из требований запланируем на следующую итерацию.
Тут возникает более практичный вопрос с учётом всего сказаного плюс этого: AF> Разработчики не ждут, пока всё будет спроектировано до конца, как только некий кусок спроектирован — они начинают работу над ним, а проектировщики работают дальше.
Т.е. получается, что всё-таки есть какая-то единица работы, которую нужно выполнить для того, чтобы передать её в следующий рабочий процесс. Некая единица работы.
Что есть кусок для каждого рабочего процесса внутри итерации? Каким образом отследить готовность каждого такого кусока в каждом рабочем процессе, чтобы его можно было передать в следующий рабочий процесс для того, чтобы так скажим квази-параллелить рабочие процессы.
В голову приходит, что этим куском является юзкейз (функциональное требование). Это так ?
Ну и если так, то видимо не все юзкейзы можно реализовать, тут, видимо, каким-то образом нужно выбирать из того, что описано, спроектировано то, что уже можно реализовать, а для чего ещё нужно описать и спроектировать другой юзкейз.
Здравствуйте, BalTun, Вы писали:
AF>> Ещё раз повторюсь — все процессы идут паралельно. Вы же описали чисто последовательную модель — причём явно срисованную с крупного проекта по водопаду. Да, иногда в очень крупных проектах, где итерация большая — несколько месяцев всё делаеют именно так. Но в обычных проектах с итерацией в месяц-полтора все горздо проще. Аналитики анализируют требования на следующую итерацию, с учётом результатов предидущих итерации и текущей. Проектировщики — разрабатывают архитектуру того, что будет сделано на следующей итерации. Тестеры — тестируют код всё время — что бы находить ошибки сразу, а не устраивать свалку потом. К концу итерации процессы сходятся (за этим должен следить ПМ).
BT>Отлично, единственное, видимо Вы хотели сказать, что только требования опережают итерацию, а остальные процессы уже по данной итерации, т.е. проектировщики создают архитектуру на требования, запланированные на данную итерацию (а не на следующую). А требования пишутся на следующую итерацию (т.к. на эту они уже запланированы) и не только на следующую, т.к. мы не знаем заранее, какие из требований запланируем на следующую итерацию.
Это так, с той поправкой, что при удачном построении процесса требования на следующую итерацию выяснятются до конца текущей, потому аналитики и проектировщики успевают сделать большую часть работы до начала следующей итерации.
BT>Тут возникает более практичный вопрос с учётом всего сказаного плюс этого: AF>> Разработчики не ждут, пока всё будет спроектировано до конца, как только некий кусок спроектирован — они начинают работу над ним, а проектировщики работают дальше.
BT>Т.е. получается, что всё-таки есть какая-то единица работы, которую нужно выполнить для того, чтобы передать её в следующий рабочий процесс. Некая единица работы. BT>Что есть кусок для каждого рабочего процесса внутри итерации? Каким образом отследить готовность каждого такого кусока в каждом рабочем процессе, чтобы его можно было передать в следующий рабочий процесс для того, чтобы так скажим квази-параллелить рабочие процессы. BT>В голову приходит, что этим куском является юзкейз (функциональное требование). Это так ?
Не совсем. UC может быть очень большим и реализовываться на протяжении многих итераций. Это типичная ситуация в крупных финансовых системах. Я понимаю чего вы хотите — структурировать работу и получить критерии для оценки завершённости некоего фрагмента работы. Но здесь всё зависит от конкретного проекта — от того, какова архитектура, степень связанности отдельных фрагментов работы, их зависимостей друг от друга, а так же от частей, которые были сделаны на предидущих и запланированны на следующие итерации. В общем случае для конкретного проекта на этот вопрос можно ответить проведя компонентную или функциональную декомпозицию проекта.
BT>Ну и если так, то видимо не все юзкейзы можно реализовать, тут, видимо, каким-то образом нужно выбирать из того, что описано, спроектировано то, что уже можно реализовать, а для чего ещё нужно описать и спроектировать другой юзкейз.
Так бывает, если каждый UC — это отдельный модуль, причём слабосвязанный с остальными. Но это увы бывает редко.
AF> В общем случае для конкретного проекта на этот вопрос можно ответить проведя компонентную или функциональную декомпозицию проекта.
Функциональная декомпозиция, это и есть разбиение на юзкейзы, как я понимаю.
А компонентная декомпозиция — что понимается под компонентом ? Если компонент как модуль что-ли или dll какая-нибудь, то тогда не получится параллельных рабочих процессов, потому что куски довольно большие, а следующий рабочий процесс по-моему невозможно выполнять пока не выполнен предыдущий по тому же куску.
Или может есть возможность как-то параллелить, не разбивая на куски ?
Здравствуйте, BalTun, Вы писали:
AF>> В общем случае для конкретного проекта на этот вопрос можно ответить проведя компонентную или функциональную декомпозицию проекта.
BT>Функциональная декомпозиция, это и есть разбиение на юзкейзы, как я понимаю.
Не верно. UseCase — варианты использования — это не функции. UC — это некие обобщённые семейства сценариев использования системы. Например может быть UC "оплата покупки" — который может в конкретном случае развиваться по тому или иному сценарию и задействовать разные функции системы. Например — функцию ввода наличных, выдачи сдачи и печати чека. Некоторые функции могут быть реализованы — а UC до конца — нет. Очень советую почитать это
.
BT>А компонентная декомпозиция — что понимается под компонентом ? Если компонент как модуль что-ли или dll какая-нибудь, то тогда не получится параллельных рабочих процессов, потому что куски довольно большие, а следующий рабочий процесс по-моему невозможно выполнять пока не выполнен предыдущий по тому же куску.
BT>Или может есть возможность как-то параллелить, не разбивая на куски ?
Именно. Мне кажется вы исходите из предположения детерминированного процесса — всё спроектировано заранее — как мост — и далее это всё без каких либо изменений существующего кода — как кирпичик за кирпичиком складывается в единое готовое целое.
Но если бы такое было возможно — RUP был бы не только не нужен, а даже вреден. То, что вы используете RUP — уже предполагает, что спроектировать всё и сразу вы не можете. А значит система растёт постепенно — как дерево — и код, написанный на одних итерациях — дописывается или вовсе переписывается на следующих. Смысл маленькой итерации именно в том, что бы не надо было делать черезмерно большой работы по проектированию. Вы не пытаетесь угадать, как оно будет пять итераций спустя — а проектируете исходя из требований текущей (и, может быть, последующей итерации). Естественно это может потребовать переделки кода на последующих итерациях. НО! Если вы поняли требования пользователя (или он вам их изложил) изначально верно — по крайней мере основные — и не было грубых ошибок в проектировании, то глубоко систему менять не придётся. Если требования были неверными изначально, или же были грубые просчёты в проектировании — то как раз в RUP — поскольку изначальные затраты на проектирование гораздо ниже, чем при полном проектировании всего и вся — и результат получается раньше — цена правки ошибок тоже ниже. Кроме того, что бы дополнительно понизить риски — в RUP рекомендуется реализовывать наиболее рискованные части проекта (технологически, архитектурно, по производительности и т.д.) на ранних итерациях.
> BT>В голову приходит, что этим куском является юзкейз (функциональное требование). Это так ? > Не совсем. UC может быть очень большим и реализовываться на протяжении многих итераций. Это типичная ситуация в крупных финансовых системах.
Вот здесь аккуратнее. Один прецедент действительно можно реализовывать в течение нескольких итераций, но при этом нужно помнить, что в конце каждой итерации реализация прецедента должна быть функционально завершена — в объёме, определённом на стадии планирования итерации.
AF> UseCase — варианты использования — это не функции. UC — это некие обобщённые семейства сценариев использования системы. Например может быть UC "оплата покупки" — который может в конкретном случае развиваться по тому или иному сценарию и задействовать разные функции системы. Например — функцию ввода наличных, выдачи сдачи и печати чека. Некоторые функции могут быть реализованы — а UC до конца — нет. Очень советую почитать это
.
Спасибо, почитаю. По-моему то, что Вы описали — просто юзкейзы различных уровней абстракции, и ещё это юзкейзы, связанные отношениями include, или extend.
BT>>А компонентная декомпозиция — что понимается под компонентом ? Если компонент как модуль что-ли или dll какая-нибудь, то тогда не получится параллельных рабочих процессов, потому что куски довольно большие, а следующий рабочий процесс по-моему невозможно выполнять пока не выполнен предыдущий по тому же куску.
BT>>Или может есть возможность как-то параллелить, не разбивая на куски ? AF> Именно. Мне кажется вы исходите из предположения детерминированного процесса — всё спроектировано заранее — как мост — и далее это всё без каких либо изменений существующего кода — как кирпичик за кирпичиком складывается в единое готовое целое. AF> Но если бы такое было возможно — RUP был бы не только не нужен, а даже вреден. То, что вы используете RUP — уже предполагает, что спроектировать всё и сразу вы не можете. А значит система растёт постепенно — как дерево — и код, написанный на одних итерациях — дописывается или вовсе переписывается на следующих. Смысл маленькой итерации именно в том, что бы не надо было делать черезмерно большой работы по проектированию. Вы не пытаетесь угадать, как оно будет пять итераций спустя — а проектируете исходя из требований текущей (и, может быть, последующей итерации). Естественно это может потребовать переделки кода на последующих итерациях. НО! Если вы поняли требования пользователя (или он вам их изложил) изначально верно — по крайней мере основные — и не было грубых ошибок в проектировании, то глубоко систему менять не придётся. Если требования были неверными изначально, или же были грубые просчёты в проектировании — то как раз в RUP — поскольку изначальные затраты на проектирование гораздо ниже, чем при полном проектировании всего и вся — и результат получается раньше — цена правки ошибок тоже ниже. Кроме того, что бы дополнительно понизить риски — в RUP рекомендуется реализовывать наиболее рискованные части проекта (технологически, архитектурно, по производительности и т.д.) на ранних итерациях.
Всё это хорошо, но всё-же я не представляю, как конкретно реализовать такой процесс, в котором всё архи-параллельно... Это что получается, все сидят себе и делают, делают, делают, абсолютно не обращая внимания на то, что закончено, а что нет? Т.е. проектировщик берет не готовый документ, который аналитик правит (может быть даже в данный момент) и начинает на основе этого документа что-то проектировать, а в это время его документ открывает разработчик и пишет по первому предложению, которое написал проектировщик код... А тестирощик уже тестирует первый недописанный оператор без закрытой скобки разработчика... в соответствии с документами проектировщика (которые он за время, пока разработчик писал половину оператора, которую успел оттестировать тестировщик) который он уже успел поменять, потому что понял, что не правильно понял недописанное требование аналитика, которое тот успел поправить...
Извините за смешной, на мой взгляд, пример, но по-другому не могу представить.
Вобщем какая-то законченность должна быть по-моему в информации, передаваемой между людьми...
Здравствуйте, speedballer, Вы писали:
>> BT>В голову приходит, что этим куском является юзкейз (функциональное требование). Это так ? >> Не совсем. UC может быть очень большим и реализовываться на протяжении многих итераций. Это типичная ситуация в крупных финансовых системах.
S>Вот здесь аккуратнее. Один прецедент действительно можно реализовывать в течение нескольких итераций, но при этом нужно помнить, что в конце каждой итерации реализация прецедента должна быть функционально завершена — в объёме, определённом на стадии планирования итерации.
Естественно. Я просто имел в виду — что UC в общем случае нельзя использовать как единицу определения объёма работы во время итерации. Особенно как малую единицу.
AF> Естественно. Я просто имел в виду — что UC в общем случае нельзя использовать как единицу определения объёма работы во время итерации. Особенно как малую единицу.
Это почему это нельзя? Вполне можно, это самая что ни на есть реальная строчка в структурной декомпозиции работ (бр-р... WBS) и в плане проекта. Если один работы по одному UC распределены на несколько итераций, следует чётко указать, какие именно работы в отношении этого UC будут выполнены. Не вижу, чему бы это противоречило.
AF>> UseCase — варианты использования — это не функции. UC — это некие обобщённые семейства сценариев использования системы. Например может быть UC "оплата покупки" — который может в конкретном случае развиваться по тому или иному сценарию и задействовать разные функции системы. Например — функцию ввода наличных, выдачи сдачи и печати чека. Некоторые функции могут быть реализованы — а UC до конца — нет. Очень советую почитать это
. BT>Спасибо, почитаю. По-моему то, что Вы описали — просто юзкейзы различных уровней абстракции, и ещё это юзкейзы, связанные отношениями include, или extend.
В данном (возможно не очень хорошем примере) — да. Но может ведь быть и такие функции системы — выполнение файла скрипта, проверка скрипта на ошибки, контроль стабильности соединения — которые вообще не имеют выхода на пользователя и являются именно функциями системы (особенно вещи вроде контроль соединения, проверка целостности данных и т.п.) Хотя конечно теоретически систему можно разбить на actor'ов — для которых это UC — но это уже больше похоже на извращение и скорее будет тормозить, а не ускорять процесс.
AF>> Именно. Мне кажется вы исходите из предположения детерминированного процесса — всё спроектировано заранее — как мост — и далее это всё без каких либо изменений существующего кода — как кирпичик за кирпичиком складывается в единое готовое целое. AF>> Но если бы такое было возможно — RUP был бы не только не нужен, а даже вреден. То, что вы используете RUP — уже предполагает, что спроектировать всё и сразу вы не можете. А значит система растёт постепенно — как дерево — и код, написанный на одних итерациях — дописывается или вовсе переписывается на следующих. Смысл маленькой итерации именно в том, что бы не надо было делать черезмерно большой работы по проектированию. Вы не пытаетесь угадать, как оно будет пять итераций спустя — а проектируете исходя из требований текущей (и, может быть, последующей итерации). Естественно это может потребовать переделки кода на последующих итерациях. НО! Если вы поняли требования пользователя (или он вам их изложил) изначально верно — по крайней мере основные — и не было грубых ошибок в проектировании, то глубоко систему менять не придётся. Если требования были неверными изначально, или же были грубые просчёты в проектировании — то как раз в RUP — поскольку изначальные затраты на проектирование гораздо ниже, чем при полном проектировании всего и вся — и результат получается раньше — цена правки ошибок тоже ниже. Кроме того, что бы дополнительно понизить риски — в RUP рекомендуется реализовывать наиболее рискованные части проекта (технологически, архитектурно, по производительности и т.д.) на ранних итерациях. BT>Всё это хорошо, но всё-же я не представляю, как конкретно реализовать такой процесс, в котором всё архи-параллельно... Это что получается, все сидят себе и делают, делают, делают, абсолютно не обращая внимания на то, что закончено, а что нет? Т.е. проектировщик берет не готовый документ, который аналитик правит (может быть даже в данный момент) и начинает на основе этого документа что-то проектировать, а в это время его документ открывает разработчик и пишет по первому предложению, которое написал проектировщик код... А тестирощик уже тестирует первый недописанный оператор без закрытой скобки разработчика... в соответствии с документами проектировщика (которые он за время, пока разработчик писал половину оператора, которую успел оттестировать тестировщик) который он уже успел поменять, потому что понял, что не правильно понял недописанное требование аналитика, которое тот успел поправить... BT>Извините за смешной, на мой взгляд, пример, но по-другому не могу представить. BT>Вобщем какая-то законченность должна быть по-моему в информации, передаваемой между людьми...
На самом деле, если смотреть на процесс в целом — то это именно так и есть. НО! Дело в том, что в вашей схеме вы упустили важный момент — механизм синхронизации. А он довольно прост. Если взять некую типичную итерацию, то: уже есть каркас системы (более или менее постоенный), проектировщик достраивает (или меняет) некий кусок этого каркаса. Так как итерация маленькая — проектирование много времени занимать не должно. В это время разработчики естественно ждут. (Если же проектирование требует значительного времени — то проектировщики должны заниматься им на следующую итерацию.) Кроме того — это уже зависит от ситуации — могут быть не зависимые куски — которые можно выдавать по мере завершения разработчикам.
Здравствуйте, speedballer, Вы писали:
AF>> Естественно. Я просто имел в виду — что UC в общем случае нельзя использовать как единицу определения объёма работы во время итерации. Особенно как малую единицу.
S>Это почему это нельзя? Вполне можно, это самая что ни на есть реальная строчка в структурной декомпозиции работ (бр-р... WBS) и в плане проекта. Если один работы по одному UC распределены на несколько итераций, следует чётко указать, какие именно работы в отношении этого UC будут выполнены. Не вижу, чему бы это противоречило.
Так можно сделать. Но в данном случае речь шла о меньшей единице работы — которую можно использовать в маштабе нескольких дней, а то и часов реализации.
