Страница 10 из 10 ПерваяПервая ... 678910
Показано с 271 по 283 из 283
  1. #271

    По умолчанию

    А для этого были продукты Rational Например, Rational Clear Quest.
    Впрочем, минимальный issue tracking поддерживает и MS Project на узле проекта (по-крайней мере, назначение, статус и прочее).
    Но в целом согласен, что у MS нет решения даже по defect tracking, не говоря уже про issue. И это issue.

  2. #272
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от GRANT
    Хорошо, вопрос на засыпку - как вы в MS Project будите отслеживать статус задач по управлению требованиями и дефектами и при этом оперативно вести change management проекта?
    То есть конечно можно их вести вручную (так было до недавнего времени, например с помощью специальных автоматических систем собираем требованиям и устраняем дефекты и потом данные о выполнении этих работ собираем в MS Project ручками, долго, упорно и с ошибками (человеческий фактор). А если требований и дефектов под несколько тысяч, и команды распределенные, как вы статус по ним вычислять будите в MS Project?
    А вы случаем не смешиваете Project Management и Change Management (частным случаем которого является Requirement Management)? Вообще-то, это разные области и софт соответственно под них разный.
    Если у вас правильно составлен тест-план, нет необходимости в плане проекта (MSP) отслеживать все дефекты - сделали "фриз" по модулю и отмечаете в MSP исполнение.

    Что касается Agile - там вообще классические PM-методы неприменимы - используется своя методика.

  3. #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.

  4. #274
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от GRANT
    Вот поэтому сейчас на рыноке IT отрасли появились системы класса ALМ (Aplication lifecycle management), которые объединяют в себе функционал как планирования так и трекинга (контроля). И по сути поддерживающие весь жизненный цикл проекта.
    Например к таким системам относятся - CollabNet EE , LUXproject ,Polarion ALM.
    Гм. Я ушел из софтверной отрасли в 2003г - похоже сейчас проблемы те же, что были и тогда. Интересно, что же делалось в отрасли 5 лет? :-Р
    Концепцию ALM придумали в Borland примерно в 2001г. И она была реализована в их пакете Borland ALM (StarTeam, CaliberRM и проч.). В 2002 я все смотрел в московскм офисе Borland - когда выбирал для своей компании стратегию управления изменениями ... правда потом в силу субьективных причин мы все таки работали на убогом ClearQuest.

  5. #275

    По умолчанию

    Цитата Сообщение от GRANT
    Например при запросе на изменение (change request), растановка сил в проекте изменится, при этом один технический менеджер который получил запрос на изменение будет петь по новому, а другой которого пока изменение не коснулось, будет петь старые песни.
    Жуть какая - описываете случай полного отсутствия управления проектом разработки.

  6. #276
    Кандидат
    Регистрация
    20.02.2009
    Сообщений
    25

    По умолчанию

    Жуть какая - описываете случай полного отсутствия управления проектом разработки.
    Жуть, не жуть, а проза жизни. Происходит это потому, что PM не может оперативно внести изменения связанные с CR сразу в несколько проектных областей. Ведь как происходит CR? Прийдя к PM'у он уходит на согласование в команду аналитиков, что бы понять, новое это требование или модификация существующего (для того что бы оценить трудозатраты и принять решение, платный это CR или нет). Но при этом группа разработчиков продолжает реализовывать требование на которые пришел CR и даже может быть уже идет тестирование и багфиксинг. То есть в идеале, как только аналитики поняли изменение какого требования произошло, тут же должна пойти цепная реакция на всю команду. На PM'а для внесения изменения в план, далее тут же идет изменение пула задач (при этом PM или технический менеджер должен точно знать кто из разработчиков реализовывал старый функционал), на тестировщиков об отменен активностей по тестированию старого функционала завязанного на отмененное требование (опять же должны точно знать, кто ведет тестирование старого функционала). Вот тут то и происходит дисконект, особенно если команды распределенные.

  7. #277
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    2,723

    По умолчанию

    Цитата Сообщение от Владимир Либерзон
    Жуть какая - описываете случай полного отсутствия управления проектом разработки.
    Ага. И я в недоумении.
    Мне кажется, у GRANT сейчас перед глазами MS Project
    MS Project - вообще не РМ система, просто внешне похож.
    Это однопользовательский продукт, что бы там кто не говорил. В нем можно обдумывать не очень большие проекты или неглубоко детализированные портфели. Когда Гантт не умещается в двух листах А4, Проджект кончается.
    Я встречал планирование на Проджекте, как корпоративный стандарт. В чистом виде самообман, этим можно только стены украшать.
    Продукт-это когда каждый участник проекта имеет набор конкретных заданий. Ему не нужно знать, что и как связано (и уж тем более-почему). Он просто обязан выполнить задание качественно\в срок и ввести в систему данные обратной связи. Все.
    Интерфейс файла заданий должен быть наглядным, конечно, и у исполнителя, и у планировщика\РП.
    Кому интересно-вышлю, как это сделано в Искре. Как до рабочего компа доберусь.
    Последний раз редактировалось Михаил_Шустер; 21.02.2009 в 00:16.

  8. #278
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    2,723

    По умолчанию

    Цитата Сообщение от GRANT
    Происходит это потому, что PM не может оперативно внести изменения связанные с CR сразу в несколько проектных областей
    Понятно. Мы практикуем корректировку или пересмотр плана. Считается, что инструмент позволяет пересмотреть план на одном-двух совещаниях. Изменение до утверждения хранится в модельной базе. В ней формируются "конфликт сроков" и "конфликт стоимости"; есть хитрости в деталях.

    В Спайдере тоже видел, но лучше пусть ВИ сам расскажет

  9. #279

    По умолчанию

    Цитата Сообщение от Михаил_Шустер
    В Спайдере тоже видел, но лучше пусть ВИ сам расскажет
    Да чего тут рассказывать? Мне вообще проблема не понятна.
    Если PM не может внести изменения в другие проектные области, то скорее всего это не его области, а значит речь идет о программе или портфеле проектов, и тогда решение и соответствующий пересчет графиков принимается на уровне портфеля.
    На уровне портфеля известны задачи, взаимосвязи, ресурсы и пр. по всем проектам организации. При внесении изменений перепланируется портфель в целом.
    Но пока CR не рассмотрен и не принят, изменения вообще-то не вносятся.

    В любом варианте речь идет об управлении изменениями - регламентах и технологиях. Это не подменяет необходимости планировать проекты и управлять ресурсами. Ограничиться системой управления изменениями можно в маленьких проектах при ручном планировании, а речь идет о тысячах изменений и большом числе участников.

    И вообще серьезные проекты разработки довольно большие. У нашего американского клиента проект разработки одной программы по гос заказу состоял из более 6000 работ с несколькими десятками (точнее около сотни) исполнителей в Штатах и Индии. И, кстати, расписание, составленное Спайдером, оказалось на четыре месяца короче расписания MS Project за счет оптимального распределения ресурсов. И это был только один из проектов портфеля. И в таких проектах фиксацией изменений не обойтись.

  10. #280
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    2,723

    По умолчанию

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

  11. #281

    По умолчанию

    Цитата Сообщение от Михаил_Шустер
    Иногда бывает, люди пользуются системой, которая им на не нужна. А всего-то нужно навести элементарный порядок в том, что они делают.
    И это правда.

  12. #282
    Кандидат
    Регистрация
    20.02.2009
    Сообщений
    25

    По умолчанию

    И, кстати, расписание, составленное Спайдером, оказалось на четыре месяца короче расписания MS Project за счет оптимального распределения ресурсов.
    Владимир Иосифович, и как потом PM собирал информацию с распределнных команд о статусах + удостоверивался, что информация поставленная ему достоверная?

  13. #283

    По умолчанию

    Цитата Сообщение от GRANT
    Владимир Иосифович, и как потом PM собирал информацию с распределенных команд о статусах + удостоверивался, что информация поставленная ему достоверная?
    Как удостоверивался, что информация достоверная, сказать не могу. Я хоть и общался с руководителем этой компании (Protech Solutions) и менеджером проекта, но такого вопроса не задавал.
    График был достаточно детальным, чтобы результаты показывались достаточно часто (длительности операций не более недели при проекте в восемь месяцев), сбор сложностей не представлял - исполнители регулярно вводили статусы своих работ и все это сливалось в единую модель автоматически, запросы на изменения рассматривались руководством и в случае принятия вносились изменения в графики работ всех исполнителей в результате пересчета расписания при измененных оценках длительности и/или изменениях состава оставшихся работ (централизованно).
    В общем, с точки зрения управления проектом никаких особенностей не наблюдал.
    И конечно велся Issue Register и Risk Register, в расписании и бюджете были заложены резервы на риски и проблемы.
    Последний раз редактировалось Владимир Либерзон; 22.02.2009 в 03:17.

Страница 10 из 10 ПерваяПервая ... 678910

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •