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

×


Проблема с документированием(Прочитано 23439 раз)
Re: Проблема с документированием Ответ #15 : 20 Ноября 2012, 19:25:03
подписанный с заказчиком КП делется на requirements, каждый проект живёт под requirement, под ним задачи на предложение по реализации, HLA, ПМИ, разработку по модулям, подсистемам и прочее формируются в виде leadtask.
Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
А вы смотрели примеры по ссылке Process Guide, которая образуется в корне сайта проекта TFS (шаблон CMMI 5.0) сразу после его создания?



Re: Проблема с документированием Ответ #16 : 21 Ноября 2012, 10:50:08
Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
А вы смотрели примеры по ссылке Process Guide, которая образуется в корне сайта проекта TFS (шаблон CMMI 5.0) сразу после его создания?
КП - это коммерческое предложение. да, мы по CMMI работаем, но через задницу :)
извините, разве вы не согласны, что в ТФС работа с требованиями совершенно неудобна, или скорее невозможна, ибо ничего с этими ворк айтемами больше сделать нельзя. ни матрицу трассирования создать, ни вменяемое дерево трассировок, кроме как классические чайльд-парент. а плодить айтемы под каждую хотелку, а потом таски под каждый реквайрмент - мы с нашей спецификой только месяцев пять будем тратить на заведение и манагерство всей этой эпичной структуры.
может, это работает для сравнительно небольших проектов с явными границами автоматизации. у нас своя специфика - в год мы  выпускаем 2-3 релиза, в которые набиваются все задачки, которые заказчик смог пропихнуть за оговоренный бюджет и срок. соответственно поток хотелок и требований у нас мощн, порывист и беспощаден :) в виду того, что OSS/BSS решение одного немаленького оператора связи - очень и очень сложная система и релизы, как правило, затрагивают комплексно все подсистемы.

конечно нам, как аналитикам и архитектуре, хотелось бы упростить жизнь и иметь полноценную СУТ. на базе ТФС бесполезно даже пытаться рассматривать управление требованиями в том объёме, в котором нам приходится работать с ними.
может, конечно, я не прав и есть способ забодать ТФС в этом плане, но, когда я плотно исследовал этот вопрос, я на него нашёл только отрицательный ответ - мелкософт сами признаются, что полноценного функционала СУТ в ТФС нет.
открыт для обсуждения :)
признаться вы меня своим вопросом про process guide поставили в тупик. поковырялся, что-то не нашёл. бегло в инете тоже не нашёл.



Re: Проблема с документированием Ответ #17 : 21 Ноября 2012, 11:32:06
поковырялся. если скриптами долбить таски-требования и выгружать во внешние системы для управления и ведения связей, то жить, в принципе, можно попробовать :)
но всё-равно это криво и убого, на мой взгляд.



Re: Проблема с документированием Ответ #18 : 21 Ноября 2012, 13:43:47
сообщение устарело
« Последнее редактирование: 06 Июня 2016, 17:18:58 от pmle »
Ставлю крестики на ноликах © pmle



Re: Проблема с документированием Ответ #19 : 21 Ноября 2012, 13:48:40
сообщение устарело
« Последнее редактирование: 06 Июня 2016, 17:19:03 от pmle »
Ставлю крестики на ноликах © pmle



Re: Проблема с документированием Ответ #20 : 21 Ноября 2012, 15:32:56
Коллеги, привет. Спасибо за конструктивные ответы. TFS никто не будет ставить.

Про ЧТЗ. В этом на мой взгляд нет смысла, так как разработчикам все равно придется читать гору документации

Про системы  управления требованиями - подумаю. Будут ли еще серебряные пули?



Re: Проблема с документированием Ответ #21 : 21 Ноября 2012, 18:28:31
извините, разве вы не согласны, что в ТФС работа с требованиями совершенно неудобна, или скорее невозможна, ибо ничего с этими ворк айтемами больше сделать нельзя. ни матрицу трассирования создать, ни вменяемое дерево трассировок, кроме как классические чайльд-парент.
Для этого линки типа Affects / Affected by рекомендуется использовать.
Навскидку из форумов: http://blogs.objectsharp.com/post/2012/02/22/Requirements-Traceability-in-Visual-Studio.aspx
С учетом трассировок в TFS все хорошо, с визуализацией - действительно, не очень.
http://mickyd.wordpress.com/2011/06/19/team-foundation-server-has-great-traceability-until-you-need-to-report-on-it/
Но никто не мешает найти какой-нибудь плагин к студии, или написать свой плагин для нужной визуализации. БД TFS имеет достаточно простую структуру и хорошо документирована, сам сервер легко интегрируется, особенно легко - со всеми микрософтовскими продуктами.

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

может, это работает для сравнительно небольших проектов с явными границами автоматизации. у нас своя специфика - в год мы  выпускаем 2-3 релиза, в которые набиваются все задачки, которые заказчик смог пропихнуть за оговоренный бюджет и срок. соответственно поток хотелок и требований у нас мощн, порывист и беспощаден :) в виду того, что OSS/BSS решение одного немаленького оператора связи - очень и очень сложная система и релизы, как правило, затрагивают комплексно все подсистемы.
Так ведь поток требований и его беспощадность вроде бы не уменьшается и не увеличивается от того, в какую систему вы его записываете? Он только от бюджета зависит...

мелкософт сами признаются, что полноценного функционала СУТ в ТФС нет.
Ну, они обычно так признаются, когда их просят показать, как реализован функционал, например IBMовской линейки FocalPoint -> Doors. Если с чем попроще сравнивать, то спорят :)

признаться вы меня своим вопросом про process guide поставили в тупик. поковырялся, что-то не нашёл. бегло в инете тоже не нашёл.
Это я ошибся, конечно, не process guide, а Process Guidance. Самая нижняя ссылка в левой колонке сайта проекта TFS, после Team Web Access, Dashboards и т.д.
Ведет по умолчанию (если проект не кастомизирован) для проекта, сделанного по шаблону CMMI 5.0 на ссылку:
http://msdn.microsoft.com/en-us/library/dd997574(VS.100).aspx
Там надо начинать с Artifacts (CMMI).



Re: Проблема с документированием Ответ #22 : 22 Ноября 2012, 11:20:45
С Cradle мы связывались. не впечатлил он моё руководство.
у нас требования к интеграции не только в том, чтобы сынтегрить две системы, но и в том, чтобы не сломать существующую аналитику в тфс - отчёты, выгрузки и прочее.
Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS. вчера нам показали архитектуру. вроде всё очень даже устраивает.
что до остальных вопросов - да, мы не ведём учёт атомарных требований в тфс. это чудовищно, понимаю, но это так :)
Каждый аналитик на своей задаче как ему удобно ведёт учёт требований. или не ведёт. полная демократия)
я пришёл сюда год назад и инициировал эту бучу с RRC.
как костыли перед внедрением СУТ, предложил руководству использовать excel для управления требованиями и генерации реквайрментов в тфс под задачами. кто-то впечатлился, кто-то нет. у нас специфика особая - мы иногда даже предложения по реализации пишем вообще без требований :-) 
что до трассировок в ТФС - это надо потратить довольно много времени и написать все скрипты для минимизации заведения айтемов в нём. под это нет внутреннего заказчика у нас, ибо "и так работает" и требования мы не учитываем в тфс. но если IBM не нашёл бы решения, то, скорее всего к этому бы мы и пришли - продумали актуальную иерархию артефактов тфс с учётом трассирования, визуализировали и прочее.
под любое усовершенствование, внедрение или пересмотр существующего функционала внутри компании-разработчика всегда должен быть внутренний заказчик(потребность в усовершенствовании/Изменении) без этого все предложения обречены на провал.




Re: Проблема с документированием Ответ #23 : 22 Ноября 2012, 13:22:05
Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS.
Ага, ну тогда расскажите потом, как оно на практике синтегрировалось, и сколько времени и человеко-месяцев понадобилось. Будет интересен ваш опыт.
У нас интеграция / миграция TFS <-> существующие системы сейчас от 3 до 5 человек требует, и уже поболе 5 человеко-лет затрат скушала. (Согласно оценкам руководства, идет успешо).




 

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