Obszary TFS, definicja i konfiguracja optymalna

Question

Po migracji do TFS 2010 zastanawiałem się, jaka jest najlepsza lub najszerzej akceptowana definicja lub konfiguracja dla obszaru?

Jedyny przydatny artykuł, który mogę znaleźć w Internecie to this one i jest to, co bym uznał za poprawny. Pomyślałem jednak, czy którekolwiek z poniższych stwierdzeń jest rzeczywiście szerzej akceptowane.

• obszarach za pomocą funkcjonalności biznesowej
• obszarach za pomocą technologii
• Obszary po warstwie systemowej
• Obszary fizyczną lub geograficznej lokalizacji

Answer 1

To naprawdę zależy od produktu/projektu, który budujesz, przypuszczam, że został udostępniony jako symbol zastępczy ogólnego przeznaczenia, który może uzyskać znaczenie z kontekstu zespołu & z misji zespołu.
Potrafię sobie wyobrazić projekty, w których ignorowanie go na sumę całkowitą byłoby również idealnym rozwiązaniem.

Nasza początkowa struktura TeamProject faktycznie zignorowała Obszary dla naszego flagowego produktu, który tworzymy w Kolekcji zespołu. Spowodowało to zgłoszenie koszmaru, ponieważ potrzebowaliśmy go na poziomie platformy (TeamCollection), a nie jego odrębnej części (Projekt zespołowy). Kiedy zdaliśmy sobie sprawę z tego problemu, przeszukaliśmy artykuł: &, znaleziony artykuł: this, który zmusił nas do zmiany kursu: obecnie korzystamy z obszarów TFS w ramach jednego projektu zespołowego &, co najlepiej pasuje do naszej sytuacji.
W naszym obszarze Wszechświata = wyraźna linia dystrybucji w ramach platformy.

Answer 2

Obszary moim zdaniem jest to mechanizm grupowania, z Obszary możesz grupować swoje wortytemy w dowolny sposób.

Uważam, że wszystko, co pasuje do twojego procesu rozwoju i/lub zwiększa produktywność, jest w porządku.

Wszystkie twoje pozycje na liście są prawidłowymi typami obszarów, widziałem je wszystkie w projektach.

Ale zbyt głęboka hierarchia nie jest naprawdę pomocna, ponieważ jeśli utworzysz stanowisko pracy, musisz wybrać/wybrać odpowiedni obszar.