Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: lnew от 02 Февраля 2011, 17:49:08
-
Вчера пришлось знакомиться с проектом плана разработки ПО с одной из компаний, которая хочет внедрять процесс RUP.
Разбирать этот план, я, естественно не буду. Но впечатление сложилось не очень. И я решил нарисовать для них шпаргалку для планирования разработки одной возможности (feature RUP).
По ходу рисования я немножко поменял цель. Получился не шаблон плана, а диаграмма бизнес-процесса разработки возможности.
Учитывались рекомендации итерационности и инкрементности.
Конечно, процесс имеет дополнительные связи с другими частями плана (и процесса) разработки. Я от них абстрагировался.
На основе диаграммы сделан шаблон MSProject.
(http://)
-
В целом процесс понятен
Я бы дополнил диаграмму условиями в ветвлениях, точнее уточнил.
К примеру, 3 сверху (по счету) ветвление точнее соединение - это что?
После разработки спецификации прецедента - работа заканчивается или разрабатываем проектную модель (если без анализа). Как я понимаю, начинаются параллельные работы, но если необходимо уточнить спецификацию?
Вопросы больше наверно со стороны документов и что брать за основу следующего шага.
-
Ну, я, для затравки, без объяснений выставил.
Возможность обеспечивается множеством прецедентов. Они обрабатываются по плану, в порядке приоритетов (здесь, как будто, один аналитик, по-этому прецеденты модели обрабатываются по-очереди).
Горизонтальная полоса под действием "Разработка спецификации..." - это Fork UML2 (Разветвление на параллельные потоки).
Параллельно выполняются:
- если есть еще прецеденты - аналитик обрабатывает следующий
- полученная спецификация передаются на анализ (если он будет выполняться) или сразу на проектирование
- технический писатель начинает писать руководство пользователя для прецедента
- тестер начинает писать сценарий тестирования прецедента, и т.д.
Системный аналитик "сдает" спецификацию после согласования с заинтересованными лицами и проектировщиками. Ошибка требований, увы, обнаруживается, обычно, при "шапочном разборе", что условно обозначено переходом после действия "Тестирование".
Любое изменение требований подразумевает повторение всей цепочки.
Вообще, при рисовании все комментарии были документированы в свойстве Description.
В частности, там написано, что "разработка" - это "создание", "изменение" или "удаление".
На верхнем уровне описания (Activity) указано, что при обнаружении ошибки процесс переходит к первому Merge.
-
Немного непонятно, компания-то чего хочет: ПО разрабатывать или процесс разработки (RUP?) внедрять?
Чего у Вас не хватает, даже с учетом подмены цели, так это цели. В чем цель? Каковы ресурсы для ее достижения? Каковы ограничения при ее достижении?
От этого и пляшите... А то получается какой-то самопальный велосипед... без колес...
-
Спасибо!
В общем-то о цели шпаргалки я написал: помочь руководителю программного проекта в составлении плана проекта.
По RUP, проект должен реализовать требования, главные из которых - это требования возможностей. Возможности декомпозируются в прецеденты.
RUP поставляет шаблоны MS Project для планов итераций. RMC может сгенерить шаблон для проекта в целом. Но работать с ними достаточно сложно.
Т.к. RUP, смею Вас заверить, знаю достаточно хорошо, я и решил сделать такую картинку, глядя на которую руководитель сможет определить (предположим, в MS Project) задачи проекта для каждой возможности и прецедента (действия диаграммы), установить зависимости между задачами (ребра диаграммы) и назначить исполнителей (я сейчас дорисовываю версию диаграммы с потоками - ролями RUP), сегодня выложу.
Поводом для этой работы послужила встреча-консультация в одной из компаний.
Диаграмма приводит бизнес-процесс разработки возможности в программном проекте. Процесс несколько упрощен по сравнению с глобальным RUP и доведен до реально практического уровня.
Почему выложил на сайт аналитиков?
Аналитики - интеллигенция проекта, часто знают проект лучше руководителя, который занят текучкой, и помогают ему, в том числе - в планировании.
-
я имел в виду цель проекта.
согласитесь, что проекты и цели бывают разные, в зависимости от этого действовать тоже придется по-разному.
-
Извините, процесс разработки плана программного проекта от цели конкретного проекта никак не зависит. От объема, формальности - зависит. А вот от предметной области - практически нет!
(Я имею ввиду объектно-ориентированный проект разработки ПО по RUP (процесс итерационный, инкрементный, базирующийся на use cases).
-
Вы, конечно, продолжайте-продолжайте...
А я, пожалуй, останусь при своем мнении, что если понимать план, как способ реализации всех задач проекта (пусть даже и программного), а не только как план-график в MS Project, то всё-таки существует довольно существенная разница между планами разных проектов... особенно для разных предметных областей.
разве что структуры данных MS Project... ну да - они всегда одинаковы: задача - она задача и есть, ну а содержательную ее составляющую зачем в расчет брать? вдруг она отличаться будет от чего-то... теоретически обоснованного в одной из многочисленных методологий.
-
Дорогой друг!
Целиком с вами согласен: не бывает правил без исключений.
Вам не приходилось сталкиваться с такой книжкой: "Международные правила предупреждения столкновения судов в море"? Толстая такая книжка. Правила посложнее, чем на дороге. Там в одном из последних правил написано примерно следующее: "Ничто в настоящих правилах не освобождает судоводителя от ответственности за происшествие, если под предлогом соблюдения правил он нарушил правила хорошей морской практики".
Аналогично, в Петровском "Морском уставе" было написано: "Здесь правила писаны, а случаев нет!"
И тем не менее, правила, уставы ("технологии") очень помогают в обычных ситуациях, которых большинство!
Использование технологий, шаблонов, "шпаргалок" при разработке ПО существенно сокращает время (о деньгах ни слова!), повышает качество за счет применения проверенных решений, и освобождает голову для решения сложных проблем, которых в нашем деле хватает!
Не хотите использовать проверенные технологии - удачи! Только посложнее жить будет.
А эту "шпаргалку" я рекомендую начинающим руководителя проектов. Не эту версию, я обещаю выставить, наверное, на своем сайте, полное описание.
-
Водолеюшка вернулся :) Ну и всех построил ;)
-
2 Galogen:
Да неее, я не отрицаю шаблонизацию чего-либо, но что-то мне подсказывает (скромн.), что в разработке разных программных продуктов (по крайней мере для разных предметных областей) менеджерами проекта должны использоваться разные (т.е. наилучшим образом подходящие для этих областей) шаблоны. Более того, не все они будут относиться к планам-графикам. А то ведь действительно можно дойти до "управления проектами в MS Project"... :о))
-
А я и не призываю всех использовать один шаблон.
И даже RUP не призывает!
И назвал я свою работу не шаблон, а шпаргалка. Пусть лежит в кармане до случая!
Вот вторая версия. Все то же, но добавлены роли исполнителей.
Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).
-
А я и не призываю всех использовать один шаблон.
И даже RUP не призывает!
И назвал я свою работу не шаблон, а шпаргалка. Пусть лежит в кармане до случая!
Вот вторая версия. Все то же, но добавлены роли исполнителей.
Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).
IMHO для "мета-процесса" и тем более шпаргалки диаграмма сложновата и без пояснительного текста ее воспринимать не просто, особенно на ночь глядя. Множество форков -с распараллеливанием и потом синхронизацией да еще в распределении по ролям затрудняют восприятие. Я бы предложил активнее использовать событийный аппарат, думаю это бы упростило восприятие да собственно саму диаграмму. Другой аспект - реальная ценность такой шпаргалки, о чем пытался сказать тов. Водолей ... я понимаю для чего это может быть полезно, особенно с методологической точки зрения ... но, боюсь, у "полевых командиров" это не вызовет энтузиазма.
-
План не может содержать действий и/или исполнителей и/или трудоемкостей.
Если хотите академическое определение то:
План - нормативное представление, в котором указана последовательность промежуточных и конечных результатов, т.е. зафиксированы состояния, которые проходит исходный материал в процессе его преобразования в конечный продукт.
План создает предпосылки для:
1. Расчленения деятельности и фиксации требований к промежуточным ее состояниям
2. Для сохранения достигнутых результатов на последующих шагах и соотнесения их с конечным продуктом
Если более простыми словами, то:
План - есть совокупность конечных и промежуточных состояний, описанных в терминах достижимости.
Как только вы написали действие вместо результата, все - это более не план. И эта диаграмма перестала быть актуальной, как только вы закончили ее рисовать.
-
жЫрный плюсадин !!!
про то, собственно, и речь толкую...
-
План не может содержать действий и/или исполнителей и/или трудоемкостей.
Если более простыми словами, то:
План - есть совокупность конечных и промежуточных состояний, описанных в терминах достижимости.
Как только вы написали действие вместо результата, все - это более не план. И эта диаграмма перестала быть актуальной, как только вы закончили ее рисовать.
жЫрный плюсадин !!!
про то, собственно, и речь толкую...
Ну, ребята, вы меня уели!!! Поставил бы жирные плюсы, но ...
Есть и другие определения плана:
- План — вершина выпуклого множества решений в симплекс-методе линейного программирования.
- План — муниципалитет в Испании, входит в провинцию Уэска.
- План — сленговое название продуктов конопли, известных также под названием гашиш, используемых как наркотическое средство.
Но, я думаю, эти термины не подходят.
Бытовое понятие плана, пример из реальной жизни:
- Вечер. Двое бегут в магазин. Подбежали - магазин закрыт!
" Что делать будем? Какие планы?".
Это ближе к теме.
Я открыл PMBOK (ANSI/PMI 99-001-2004), там несколько связанных определений, перепечатывать лень!
Поищем, что попроще!
Вот: http://www.klerk.ru/boss/articles/104256/
Цитата из этой статьи:
"Проект позволяет достичь определенного результата в определенные сроки и за определенные деньги. План проекта составляется для того, чтобы определить, с помощью каких работ будет достигаться результат проекта, какие люди и оборудование нужны для исполнения этих работ, в какое время эти люди и оборудование будут заняты работой по проекту. Поэтому проектный план содержит три основных элемента: задачи (task), ресурсы (resource) и назначения (assignment)."
Но и это еще не все:
Та диаграмма, которую я нарисовал, это не план проекта, и даже не шаблон. Это описание стандартного процесса разработки всего одной возможности будущего ПО, шпаргалка, которую (начинающий) руководитель проекта может использовать при рисовании графика в части реализации возможности (задачи и исполнители).
Если хватит терпения, прочитайте, это наверху написано!
Желаю успехов!
-
IMHO для "мета-процесса" и тем более шпаргалки диаграмма сложновата и без пояснительного текста ее воспринимать не просто, особенно на ночь глядя. Множество форков -с распараллеливанием и потом синхронизацией да еще в распределении по ролям затрудняют восприятие. Я бы предложил активнее использовать событийный аппарат, думаю это бы упростило восприятие да собственно саму диаграмму. Другой аспект - реальная ценность такой шпаргалки, о чем пытался сказать тов. Водолей ... я понимаю для чего это может быть полезно, особенно с методологической точки зрения ... но, боюсь, у "полевых командиров" это не вызовет энтузиазма.
Юра, спасибо за конструктивную критику.
Один "полевой командир" (из-за которого и нарисовано) выставил сегодня бутылку пива. Посмотрим, поможет ли ему эта "шпаргалка"!
Использование событий, на мой взгляд, не сильно упростит картину.
Я хотел сделать карточку на А4, которую можно было бы охватить одни взглядом, но получилось очень мелко.
Можно чуть подсократиться, исключив понятие "возможности" и, соответственно, убрав цикл по прецедентам.
Есть самый простой способ:
- у меня инстинкт на уровне спинного мозга: создал модельный элемент - написал краткое описание, т.е. диаграмма описана
- сгенерить SoDA-отчет: диаграмма и текстовое описание процесса
- т.к. "карточка" все равно не получилась, диаграмму декомпозировать с использованием Call Bechavior
Вопрос только, стоит ли овчинка выделки?
Судя по реакции читательской аудитории, стоит.
-
Я открыл PMBOOK (ANSI/PMI 99-001-2004)
Сколько же можно. Где вы вообще это слово гадкое берёте — BOOK?
Нету в аббревиатуре Body Of Knowledge двойного O, ну нету его там.
-
Сколько же можно. Где вы вообще это слово гадкое берёте — BOOK?
Нету в аббревиатуре Body Of Knowledge двойного O, ну нету его там.
Спасибо, что вычитали опечатку! Увы, я не всегда вычитываю, спешу!
Есть еще?