Показано с 271 по 283 из 283
-
20.02.2009, 17:06 #271
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
А для этого были продукты Rational Например, Rational Clear Quest.
Впрочем, минимальный issue tracking поддерживает и MS Project на узле проекта (по-крайней мере, назначение, статус и прочее).
Но в целом согласен, что у MS нет решения даже по defect tracking, не говоря уже про issue. И это issue.
-
20.02.2009, 17:07 #272
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от GRANT
Если у вас правильно составлен тест-план, нет необходимости в плане проекта (MSP) отслеживать все дефекты - сделали "фриз" по модулю и отмечаете в MSP исполнение.
Что касается Agile - там вообще классические PM-методы неприменимы - используется своя методика.
-
20.02.2009, 18:54 #273
- Регистрация
- 20.02.2009
- Сообщений
- 25
Если у вас правильно составлен тест-план, нет необходимости в плане проекта (MSP) отслеживать все дефекты - сделали "фриз" по модулю и отмечаете в MSP исполнение.
Вот представьте Александр план по созданию ПО со следующими этапами (этапы идут не последовательно, а относительно запараллелены).
- Сбор требований
- Утверждение
- Создание дизайна (архитектуры)
- Кодирование
-Тестирование
- Багфиксинг
-UAT (приемка закзачиком через тестирование)
Руководитель проекта, должен отслеживать прогресс выполнения данных этапов и в зависимости от ситуации затормаживать или перетасовывать задачи. Что бы знать ситуацию, он должен получать в свой "MS Project" свежую информацию, а где ее взять? Обычно он получает их из устных или в лучшем случае из письменных отчетов техническим менеджеров. Но где гарантия того, что информация правильная? Например при запросе на изменение (change request), растановка сил в проекте изменится, при этом один технический менеджер который получил запрос на изменение будет петь по новому, а другой которого пока изменение не коснулось, будет петь старые песни.
К чему это я, а к тому что если PM занимается на проекте не только планированием, но и реальным управлением в процессе проекта, то он должен иметь доступ к оперативным данным по динамике активностей на проекте, более того доступ долже обеспечиваться прозрачными методами, исключающий "политический-человеческий" фактор.
В моем понимании такой доступ должен обеспечиваться посредством неких информационных инструментов, более того должен присутсвовать экспорт данных из этих систем в систему управления планированием и управлением для принятия управленческих решений минуя "человеческий фактор" в цепочке передачи данных.
Вот поэтому сейчас на рыноке IT отрасли появились системы класса ALМ (Aplication lifecycle management), которые объединяют в себе функционал как планирования так и трекинга (контроля). И по сути поддерживающие весь жизненный цикл проекта.
Например к таким системам относятся - CollabNet EE , LUXproject ,Polarion ALM,
Последний раз редактировалось GRANT; 20.02.2009 в 19:05.
-
20.02.2009, 19:26 #274
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от GRANT
Концепцию ALM придумали в Borland примерно в 2001г. И она была реализована в их пакете Borland ALM (StarTeam, CaliberRM и проч.). В 2002 я все смотрел в московскм офисе Borland - когда выбирал для своей компании стратегию управления изменениями ... правда потом в силу субьективных причин мы все таки работали на убогом ClearQuest.
-
20.02.2009, 20:54 #275
- Регистрация
- 27.11.2005
- Сообщений
- 293
Сообщение от GRANT
-
20.02.2009, 23:54 #276
- Регистрация
- 20.02.2009
- Сообщений
- 25
Жуть какая - описываете случай полного отсутствия управления проектом разработки.
-
21.02.2009, 00:06 #277
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от Владимир Либерзон
Мне кажется, у GRANT сейчас перед глазами MS Project
MS Project - вообще не РМ система, просто внешне похож.
Это однопользовательский продукт, что бы там кто не говорил. В нем можно обдумывать не очень большие проекты или неглубоко детализированные портфели. Когда Гантт не умещается в двух листах А4, Проджект кончается.
Я встречал планирование на Проджекте, как корпоративный стандарт. В чистом виде самообман, этим можно только стены украшать.
Продукт-это когда каждый участник проекта имеет набор конкретных заданий. Ему не нужно знать, что и как связано (и уж тем более-почему). Он просто обязан выполнить задание качественно\в срок и ввести в систему данные обратной связи. Все.
Интерфейс файла заданий должен быть наглядным, конечно, и у исполнителя, и у планировщика\РП.
Кому интересно-вышлю, как это сделано в Искре. Как до рабочего компа доберусь.Последний раз редактировалось Михаил_Шустер; 21.02.2009 в 00:16.
-
21.02.2009, 00:14 #278
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от GRANT
В Спайдере тоже видел, но лучше пусть ВИ сам расскажет
-
21.02.2009, 12:23 #279
- Регистрация
- 27.11.2005
- Сообщений
- 293
Сообщение от Михаил_Шустер
Если PM не может внести изменения в другие проектные области, то скорее всего это не его области, а значит речь идет о программе или портфеле проектов, и тогда решение и соответствующий пересчет графиков принимается на уровне портфеля.
На уровне портфеля известны задачи, взаимосвязи, ресурсы и пр. по всем проектам организации. При внесении изменений перепланируется портфель в целом.
Но пока CR не рассмотрен и не принят, изменения вообще-то не вносятся.
В любом варианте речь идет об управлении изменениями - регламентах и технологиях. Это не подменяет необходимости планировать проекты и управлять ресурсами. Ограничиться системой управления изменениями можно в маленьких проектах при ручном планировании, а речь идет о тысячах изменений и большом числе участников.
И вообще серьезные проекты разработки довольно большие. У нашего американского клиента проект разработки одной программы по гос заказу состоял из более 6000 работ с несколькими десятками (точнее около сотни) исполнителей в Штатах и Индии. И, кстати, расписание, составленное Спайдером, оказалось на четыре месяца короче расписания MS Project за счет оптимального распределения ресурсов. И это был только один из проектов портфеля. И в таких проектах фиксацией изменений не обойтись.
-
21.02.2009, 13:32 #280
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Иногда бывает, люди пользуются системой, которая им на не нужна. А всего-то нужно навести элементарный порядок в том, что они делают.
-
21.02.2009, 14:21 #281
- Регистрация
- 27.11.2005
- Сообщений
- 293
Сообщение от Михаил_Шустер
-
22.02.2009, 00:54 #282
- Регистрация
- 20.02.2009
- Сообщений
- 25
И, кстати, расписание, составленное Спайдером, оказалось на четыре месяца короче расписания MS Project за счет оптимального распределения ресурсов.
-
22.02.2009, 02:48 #283
- Регистрация
- 27.11.2005
- Сообщений
- 293
Сообщение от GRANT
График был достаточно детальным, чтобы результаты показывались достаточно часто (длительности операций не более недели при проекте в восемь месяцев), сбор сложностей не представлял - исполнители регулярно вводили статусы своих работ и все это сливалось в единую модель автоматически, запросы на изменения рассматривались руководством и в случае принятия вносились изменения в графики работ всех исполнителей в результате пересчета расписания при измененных оценках длительности и/или изменениях состава оставшихся работ (централизованно).
В общем, с точки зрения управления проектом никаких особенностей не наблюдал.
И конечно велся Issue Register и Risk Register, в расписании и бюджете были заложены резервы на риски и проблемы.Последний раз редактировалось Владимир Либерзон; 22.02.2009 в 03:17.