Форум Сообщества Аналитиков

×


Шпаргалка руководителю проекта(Прочитано 23498 раз)
Вчера пришлось знакомиться с проектом плана разработки ПО с одной из компаний, которая хочет внедрять процесс RUP.
Разбирать этот план, я, естественно не буду. Но впечатление сложилось не очень. И я решил нарисовать для них шпаргалку для планирования разработки одной возможности (feature RUP).
По ходу рисования я немножко поменял цель. Получился не шаблон плана, а диаграмма бизнес-процесса разработки возможности.
Учитывались рекомендации итерационности и инкрементности.
Конечно, процесс имеет дополнительные связи с другими частями плана (и процесса) разработки. Я от них абстрагировался.
На основе диаграммы сделан шаблон MSProject.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Шпаргалка руководителю проекта Ответ #1 : 02 Февраля 2011, 19:34:29
В целом процесс понятен
Я бы дополнил диаграмму условиями в ветвлениях, точнее уточнил.

К примеру, 3 сверху (по счету) ветвление точнее соединение -  это что?

После разработки спецификации прецедента - работа заканчивается или разрабатываем проектную модель (если без анализа). Как я понимаю, начинаются параллельные работы, но если необходимо уточнить спецификацию?

Вопросы больше наверно со стороны документов и что брать за основу следующего шага.

«Сделай первый шаг, и ты поймешь, что не все так страшно.»
-- L. A. Seneca --



Re: Шпаргалка руководителю проекта Ответ #2 : 02 Февраля 2011, 20:20:13
Ну, я, для затравки, без объяснений выставил.

Возможность обеспечивается множеством прецедентов. Они обрабатываются по плану, в порядке приоритетов (здесь, как будто, один аналитик, по-этому прецеденты модели обрабатываются по-очереди).

Горизонтальная полоса под действием "Разработка спецификации..." - это Fork UML2 (Разветвление на параллельные потоки).
Параллельно выполняются:
- если есть еще прецеденты - аналитик обрабатывает следующий
- полученная спецификация передаются на анализ (если он будет выполняться) или сразу на проектирование
- технический писатель начинает писать руководство пользователя для прецедента
- тестер начинает писать сценарий тестирования прецедента, и т.д.

Системный аналитик "сдает" спецификацию после согласования с заинтересованными лицами и проектировщиками. Ошибка требований, увы, обнаруживается, обычно, при "шапочном разборе", что условно обозначено переходом после действия "Тестирование".
Любое изменение требований подразумевает повторение всей цепочки.

Вообще, при рисовании все комментарии были документированы в свойстве Description.
В частности, там написано, что "разработка" - это "создание", "изменение" или "удаление".
На верхнем уровне описания (Activity) указано, что при обнаружении ошибки процесс переходит к первому Merge.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Шпаргалка руководителю проекта Ответ #3 : 03 Февраля 2011, 19:54:20
Немного непонятно, компания-то чего хочет: ПО разрабатывать или процесс разработки (RUP?) внедрять?
Чего у Вас не хватает, даже с учетом подмены цели, так это цели. В чем цель? Каковы ресурсы для ее достижения? Каковы ограничения при ее достижении?
От этого и пляшите... А то получается какой-то самопальный велосипед... без колес...
Лью воду...



Re: Шпаргалка руководителю проекта Ответ #4 : 03 Февраля 2011, 21:04:21
Спасибо!

В общем-то о цели шпаргалки я написал: помочь руководителю программного проекта в составлении плана проекта.

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

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

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

Почему выложил на сайт аналитиков?
Аналитики - интеллигенция проекта, часто знают проект лучше руководителя, который занят текучкой, и помогают ему, в том числе - в планировании.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Шпаргалка руководителю проекта Ответ #5 : 03 Февраля 2011, 21:07:59
я имел в виду цель проекта.
согласитесь, что проекты и цели бывают разные, в зависимости от этого действовать тоже придется по-разному.
Лью воду...



Re: Шпаргалка руководителю проекта Ответ #6 : 03 Февраля 2011, 21:16:31
Извините, процесс разработки плана программного проекта от цели конкретного проекта никак не зависит. От объема, формальности - зависит. А вот от предметной области - практически нет!
(Я имею ввиду объектно-ориентированный проект разработки ПО по RUP (процесс итерационный, инкрементный, базирующийся на use cases).
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Шпаргалка руководителю проекта Ответ #7 : 03 Февраля 2011, 21:52:43
Вы, конечно, продолжайте-продолжайте...
А я, пожалуй, останусь при своем мнении, что если понимать план, как способ реализации всех задач проекта (пусть даже и программного), а не только как план-график в MS Project, то всё-таки существует довольно существенная разница между планами разных проектов... особенно для разных предметных областей.
разве что структуры данных MS Project... ну да - они всегда одинаковы: задача - она задача и есть, ну а содержательную ее составляющую зачем в расчет брать? вдруг она отличаться будет от чего-то... теоретически обоснованного в одной из многочисленных методологий.
Лью воду...



Re: Шпаргалка руководителю проекта Ответ #8 : 03 Февраля 2011, 22:39:44
Дорогой друг!

Целиком с вами согласен: не бывает правил без исключений.

Вам не приходилось сталкиваться с такой книжкой: "Международные правила предупреждения столкновения судов в море"? Толстая такая книжка. Правила посложнее, чем на дороге. Там в одном из последних правил написано примерно следующее: "Ничто в настоящих правилах не освобождает судоводителя от ответственности за происшествие, если под предлогом соблюдения правил он нарушил правила хорошей морской практики".

Аналогично, в Петровском "Морском уставе" было написано: "Здесь правила писаны, а случаев нет!"

И тем не менее, правила, уставы ("технологии") очень помогают в обычных ситуациях, которых большинство!

Использование технологий, шаблонов, "шпаргалок" при разработке ПО существенно сокращает время (о деньгах ни слова!), повышает качество за счет применения проверенных решений, и освобождает голову для решения сложных проблем, которых в нашем деле хватает!

Не хотите использовать проверенные технологии - удачи! Только посложнее жить будет.

А эту "шпаргалку" я рекомендую начинающим руководителя проектов. Не эту версию, я обещаю выставить, наверное, на своем сайте, полное описание.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Шпаргалка руководителю проекта Ответ #9 : 03 Февраля 2011, 22:41:25
Водолеюшка вернулся :) Ну и всех построил ;)



Re: Шпаргалка руководителю проекта Ответ #10 : 03 Февраля 2011, 22:56:30
2 Galogen:
Да неее, я не отрицаю шаблонизацию чего-либо, но что-то мне подсказывает (скромн.), что в разработке разных программных продуктов (по крайней мере для разных предметных областей) менеджерами проекта должны использоваться разные (т.е. наилучшим образом подходящие для этих областей) шаблоны. Более того, не все они будут относиться к планам-графикам. А то ведь действительно можно дойти до "управления проектами в MS Project"... :о))

Лью воду...



Re: Шпаргалка руководителю проекта Ответ #11 : 03 Февраля 2011, 23:48:55
А я и не призываю всех использовать один шаблон.
И даже RUP не призывает!
И назвал я свою работу не шаблон, а шпаргалка. Пусть лежит в кармане до случая!

Вот вторая версия. Все то же, но добавлены роли исполнителей.

Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Шпаргалка руководителю проекта Ответ #12 : 04 Февраля 2011, 00:43:19
А я и не призываю всех использовать один шаблон.
И даже RUP не призывает!
И назвал я свою работу не шаблон, а шпаргалка. Пусть лежит в кармане до случая!

Вот вторая версия. Все то же, но добавлены роли исполнителей.

Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).

IMHO для "мета-процесса" и тем более шпаргалки диаграмма сложновата и без пояснительного текста ее воспринимать не просто, особенно на ночь глядя. Множество форков -с распараллеливанием и потом синхронизацией да еще в распределении по ролям затрудняют восприятие. Я бы предложил активнее использовать событийный аппарат, думаю это бы упростило восприятие да собственно саму диаграмму. Другой аспект - реальная ценность такой шпаргалки, о чем пытался сказать тов. Водолей ... я понимаю для чего это может быть полезно, особенно с методологической точки зрения ... но, боюсь, у "полевых командиров" это не вызовет энтузиазма.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Re: Шпаргалка руководителю проекта Ответ #13 : 04 Февраля 2011, 10:50:16
План не может содержать действий и/или исполнителей и/или трудоемкостей.

Если хотите академическое определение то:
Цитировать
План - нормативное представление, в котором указана последовательность промежуточных и конечных результатов, т.е. зафиксированы состояния, которые проходит исходный материал в процессе его преобразования в конечный продукт.
 План создает предпосылки для:
1. Расчленения деятельности и фиксации требований к промежуточным ее состояниям
2. Для сохранения достигнутых результатов на последующих шагах и соотнесения их с конечным продуктом

Если более простыми словами, то:
План - есть совокупность конечных и промежуточных состояний, описанных в терминах достижимости.
Как только вы написали действие вместо результата, все - это более не план. И эта диаграмма перестала быть актуальной, как только вы закончили ее рисовать.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Re: Шпаргалка руководителю проекта Ответ #14 : 04 Февраля 2011, 12:10:31
жЫрный плюсадин !!!
про то, собственно, и речь толкую...

Лью воду...




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19