Powers of 10

Wir erkennen, dass die größeren Strukturen aus kleineren aufgebaut sind, die wiederum aus kleineren Strukturen bestehen, usw.

Andersherum: je größer unser Betrachtungsabstand wird, desto mehr verschwimmen oder verschwinden die Details der kleineren Strukturen. Wenn wir eine Straße überqueren wollen, schauen wir nach rechts und links und halten Ausschau nach einem herannahenden Auto. Wir interessieren uns nur für das „Muster“ Auto. Typ, Farbe, Räder, Insassen also die kleineren Strukturen des Autos sehen wir nicht.

Wenn wir die Vorgänge in unserem Sonnensystem betrachten, interessieren uns die Kontinente auf der Erde nicht. Die Kontinente haben einfach eine kleinere Granularität als die Planeten. In unserer Beobachtung reduzieren wir unser Stern- und Planetensystem auf die Himmelskörper. Die Kontinente fallen unter die Wahrnehmungsschwelle.

Mit anderen Worten: Wir reduzieren die Komplexität des Systems „Sonnensystem“ auf dessen Strukturelemente „Himmelskörper“. Komplexität und die systemische Betrachtungsweise der Welt sind untrennbar miteinander verbunden.Die allgemeine Systemtheorie beschäftigt sich damit.

Den Wald vor lauter Bäumen sehen

Wenn wir den Wald vor lauter Bäumen nicht sehen, haben wir uns in der inneren Struktur des Systems Wald verloren. Wenn wir das große Ganze, den Wald, wiedererkennen wollen, müssen wir einen Schritt zurück treten, also Abstand bekommen.

Was ich kann, das kann ich! Ja, klar. Aber wie komme ich dahin? Wie komme ich zum Können? Der Weg scheint steinig und die meiste Zeit bergauf zu führen. Der Weg heißt Lernen. Gepflastert ist er mit Wissen. Das Vorwärtskommen ist die Erfahrung. Beides ist nötig, der Weg und das Voranschreiten. An den Zollstellen entrichten wir unser Lehrgeld aber am Ende wartet die Belohnung. Das Können.

Können warten am Ende des Wegs.

Lernen als Individuum

Wenn ich allein vor einer Aufgabe stehe, dann denke ich darüber nach, wie ich diese Lösen könnte. Wenn mir nichts einfällt, schaue ich im Internet nach oder frage jemand, der sich damit auskennt. Habe ich dann eine Idee, wie ich das Problem angehen kann, mache ich mich an die Arbeit. Das Ergebnis schaue ich mir an, und überlege, ob ich damit zufrieden bin. Wenn ja? Super. Wenn nicht, dann muss ich noch mal ran, bis es passt.

Individuelles Lernen

Ich lerne, indem ich mein Wissen verwende und ein Problem löse. Mit der Erfahrung, die ich beim Problemlösen sammle, erweitere ich mein Wissen und Können.

Lernen als Team

Was passiert, wenn ein Team, also mindestens zwei Beteiligte, eine Aufgabe lösen müssen? Wenn sie die Aufgabe schon tausendmal lösen mussten, dann denken sie nicht lange nach, sondern erledigen diese einfach. Sie sind ein eingespieltes Team. So wie die Techniker in der Formel 1.

Können in Aktion. Ein eingespieltes Team.

Wenn die Aufgabe aber neu ist oder in dieser Form noch nie gestellt wurde? Dann muss sich das Team gemeinsam eine Lösung überlegen. Das heißt, die Teammitglieder müssen miteinander kommunizieren. Sie werfen ihr Wissen in einen Topf, ziehen eventuell noch einen Experten zu Rate und machen sich an die Arbeit. Sie müssen sowohl einzeln als auch gemeinsam die Ergebnisse überprüfen und bewerten.

Teamlernen

Ein Team lernt, indem es das gemeinsame Wissen nutzt und ein Problem löst. Mit der Erfahrung die das gesamte Team beim Problemlösen sammelt, erweitert jedes Teammitglied und damit das gesamte Team sein Wissen und Können. Die Kommunikation zwischen den Teammitgliedern spielt dabei die wesentliche Rolle.

Werden Teams größer oder sitzen räumlich getrennt, dann ist die Kommunikation schwieriger und es gelten die gleichen Mechanismen wie beim Lernen als Organisation.

Lernen als Organisation

Wenn verschiedene Teams ähnliche Aufgaben lösen müssen, dann wäre es sinnvoll, wenn ein Team auf das Wissen und die Erfahrungen der anderen Teams zugreifen kann. Organisationen stehen vor der Aufgabe, das Wissen einzelner Personen oder Teams für andere Teams oder Personen zugänglich zu machen. Da nicht mehr, wie in Teams, Jeder mit Jedem reden kann, um sich Rat zu holen oder Erfahrungen zu vermitteln, müssen andere Strukturen geschaffen werden. Es muss eine Art Über- oder Organisatiosgehirn bereitgestellt werden, das Jeder anzapfen kann.

Lernen als Organisation

Eine Organisation lernt, indem sie das Wissen aller Personen und Teams nutzt, um Probleme zu lösen. Die Erfahrungen, die beim Problemlösen gesammelt werden, werden wiederum allen Personen und Teams bereitgestellt und vermittelt. Wesentlich sind dabei das Medium, das den Wissensspeicher der Organisation bildet und die Kommunikation mit diesem Speicher.

Lernen ist Reflexion und Veränderung

Der Ausgangspunkt in allen drei Szenarios ist vorhandenes Wissen. Durch die Erfahrungen die beim Lösen der Aufgaben gesammelt werden und der Reflexion darüber wird das vorhandene Wissen verändert. Es wird entweder umstrukturiert oder ergänzt.

Software Entwicklung ist Lernen

„Software development is an exercise in learning“ beginnt Allan Kelly sein Buch „Changing Software Development: Learning to Become Agile„. Er fährt fort mit „The process of learning and changing is an exercice in knowledge creation. Knowledge itself is learning with action…“.

Er identifiziert drei Bereiche in denen wir durch Software-Entwicklung unser Wissen erweitern:

• Fachwissen, das Wissen der Anwender in ihrer Fachdomäne, für die die Software entwickelt wird.
• Werkzeugwissen, das Wissen wie Programmiersprachen und -werkzeuge einzusetzen sind.
• Prozesswissen, das Wissen wie bei der Software-Entwicklung vorzugehen ist.

Ich ergänze die Liste noch um:

• Architekturwissen, das Wissen, wie Anwendungen „konstruiert“ werden.

Zu allen Wissensbereichen ist Wissen verfügbar. Es steckt in den Köpfen der Menschen, in den Werkzeugen die sie benutzen oder in allen denkbaren analogen und digitalen Medien. Dieses Wissen kann aber immer nur ein Ausgangspunkt sein. Damit dieses Wissen einen Wert hat, egal ob für einen Einzelnen, für ein Team oder für eine Organisation muss es veränderbar sein. Veränderbar, damit es Erfahrungen aufnehmen kann. Veränderbar, damit daraus eine Fähigkeit, ein Können wird.

Wissensgesellschaft?

Wir sind Wissensarbeiter, das Notebook verrät uns!

Wir sind Wissensarbeiter. Wissen ist aber nur die halbe Miete. Wissen ist der Weg. Die Steine einzusammeln, die den Weg pflastern, nutzt nichts. Der Weg will gegangen sein. Nicht der Weg ist das Ziel, sondern das Gehen. Das Können wartet erst am Ende.

Was sind die Kriterien, um die empfundene Zu- oder Abneigung gegen Prozesse zu erklären? Intuitiv würde ich antworten: „Solange Prozesse meine Arbeit unterstützen und erleichtern finde ich sie gut aber wenn Prozesse mich in meiner Arbeit behindern, verzichte ich sehr gern darauf.“.

Ich versuche mich der Antwort durch zwei Hintertürchen zu nähern. An der ersten Tür steht: Systemtheorie.

Software Entwicklung als Soziotechnisches System

Dass Software gemeinsam mit dem Computer auf dem sie läuft, als System bezeichnet wird, ist so in unserem Sprachgebrauch aufgegangen, dass wir nicht mehr darüber nachdenken.

Ein System als Blackbox

Von Außen betrachtet ist ein System eine Blackbox, die auf unsere Eingaben (Input) irgendwie reagiert (Output). Wie dabei das Innere aussieht (Struktur) und was im Inneren vor sich geht (Verarbeitung) bleibt uns verborgen.

Wenn wir die Softwareentwicklung als Blackbox betrachten, würde es so aussehen:

Das System der Softwareentwicklung

Wir füttern diese Box mit Kundenwünschen und bekommen ein Softwareprodukt geliefert, dass (im Idealfall) diese Wünsche erfüllt. Wenn wir einen Blick in diese Box werfen, sehen wir Menschen, die an Computern sitzen und in Gemeinschaftsarbeit die Kundenwünsche in ein Softwareprodukt verwandeln. Während wir beim Computersystem von einem rein technischen System sprechen, wird die Softwareentwicklung als Soziotechnisches System bezeichnet. Die innere Struktur wird durch Menschen, Technologien und Prozesse gebildet.

Die innere Struktur eines Soziotechnischen Systems wird durch Menschen, Technologien und Prozessen gebildet.

Entropie – das Maß der Unordnung in einem System

An der zweiten Hintertür steht Entropie. Entropie wird als physikalische Zustandsgröße zur Beschreibung von Systemen verwendet. Für uns reicht es, wenn wir sie uns als Ordnung bzw. Unordnung vorstellen. Mein Arbeitsplatz am Freitag ist ein System mit hoher Entropie = hoher Unordnung und der „Pragmatische Programmierer“ spricht von Software Entropie und davon dass Software vergammelt.

Mein Arbeitsplatz am Freitag

Das Finanzamt ist ein gutes Beispiel für eine Einrichtung mit niedriger Entropie = hoher Ordnung.

Behörden als Einrichtungen großer Ordnung

Fluch oder Segen?

Eins fällt in beiden Beispielen auf. Richtig produktiv ist niemand. Ich brauche die meiste Zeit, um das Chaos zu beherrschen während die Beamten damit beschäftigt sind, die Ordnung aufrecht zu erhalten. Ich würde mehr auf die Reihe bekommen, wenn ich meinen Schreibtisch aufräumen würde und unsere Steuererklärungen würden schneller bearbeitet werden, wenn die Gesetze und Verfahren einfacher wären. Grafisch würde das so aussehen:

Einfluß der Ordnung / Unordnung auf die Produktivität

Interessanter Weise ist die Produktivität sowohl bei maximaler Unordnung als auch bei maximaler Ordnung am geringsten. Für die Softwareentwicklung bedeutet das, dass ganz links das Chaos und ganz rechts die formale Einhaltung von Arbeitsabläufen die Produktivität bremsen. Da die meisten Menschen etwas Sinnvolles in ihrem Leben leisten möchten, und sich am wohlsten fühlen, wenn sie „etwas geschafft“ haben, nimmt das subjektive Wohlbefinden (bezogen auf die Arbeit) zur Mitte hin zu. Da die Entropie in unserem System der Softwareentwicklung von den drei Strukturelementen Menschen, Technologien und Prozesse abhängt, können wir daraus ableiten, wie Prozesse von den beteiligten Personen empfunden werden:

Subjektives Empfinden von Prozessen

Auf der linken Seite helfen geordnetere Arbeitsabläufe, produktiver und damit zufriedener zu sein. Prozesse werden als Segen empfunden. Wenn das Prozessspiel aber weiter getrieben wird, kippt die Stimmung. Die Produktivität sinkt und damit auch das Wohlbefinden. Prozesse werden als sinnlos und als Behinderung angesehen. Sie werden zum Fluch!

無駄 (sprich: Muda)

Damit ein System etwas leisten kann, muss Energie zugeführt werden. Das ist beim Auto genauso wie in der Software  Entwicklung. Leider wird diese Energie nur zum Teil in nutzbare Leistung umgesetzt. Der Rest ist Verschwendung (Muda)! Aber selbst die Verschwendung kann noch einmal in notwendige und in unnötige Verschwendung unterteilt werden. Notwendig ist z.B. die Beleuchtung des Autos auch wenn sie nicht zur Fahrleistung beiträgt. Aber wenn zu wenig Luft auf den Reifen ist und dadurch mehr Sprit verbraucht wird ist das unnötige Verschwendung. 

Verwendung der zugeführten Energie

Wenn wir uns anschauen, wofür die Energie in der Software Entwicklung verbraucht wird, dann sehen wir, dass links und rechts in den „Produktivitätstälern“ gleich wenig Energie in die Wertschöpfung fließt. Der Energieverbrauch der Verschwendungsarten ist allerdings unterschiedlich. Während auf der linken Seite, dem Chaostal, die Unnötige die Oberhand hat, verschlingt im Ordnungstal die Notwendige Verschwendung die meiste Energie.

Energiebilanz im Verhältnis zur Entropie

Wenn wir nun den Berg aus dem Chaostal erklimmen wollen, müssen wir uns zwangsläufig mit der unnötigen Verschwendung auseinander setzen. Hier helfen uns Mery und Tom Poppendieck, die die Konzepte des Lean Product Development für die Software Entwicklung (Lean Software Development) aufbereitet haben.

Mt. Fuji

Das erste und wichtigste Prinzip der Lean Philosophie ist: Beseitige die Verschwendung (Muda)! Noch einmal: Verschwendung ist das, was keinen Wert für den Kunden erzeugt. Die größte und offensichtlichste Verschwendung sind also Dinge die produziert (oder mit auf den Berg getragen werden) und nicht gebraucht werden. Tolle Features, die niemals ein Anwender aufrufen wird. Diese Funktionen kosten nicht nur bei ihrer Herstellung Zeit, sie vergrößern auch die Komplexität der Anwendung. Da sich die Komplexität leider nicht linear auf die Kosten auswirkt sondern exponentiell, tragen also unnötige Funktionen exponentiell zur Verschwendung bei.

Wir wollen noch verweilen, die Aussicht ist so schön.

Nachdem wir uns von dem unnötigen Ballast befreit haben und auf dem Gipfel angekommen sind, wollen wir so schnell nicht wieder herunter. Die Aussicht ist so toll und der Abstieg ist nicht gut für die Knie.

Sonnenaufgang auf dem Mt. Fuji.

Aber was, wenn wir keine Wahl haben? Wenn Gesetzgeber oder Auftraggeber eine höhere Ordnung verlangen? Auch wenn akzeptiert wird, dass Softwareentwicklung in bestimmten Branchen aufwendiger und teurer ist, wird auch hier der Kostendruck immer größer. Wie kann verhindert werden, dass die Produktivität durch Ansteigen der Ordnung sinkt? Warum kann sie nicht auch weiter steigen?

Dilemma: Sinkende Produktivität bei steigender Ordnung

Um im Tal der Ordnung produktiver zu sein, muss auch hier die Verschwendung minimiert werden. Aber im Gegensatz zur Unnötigen Verschwendung im Chaostal, hat hier die Notwendige Verschwendung die Oberhand. Die Energie wird also benötigt, um die geforderte Ordnung aufrecht zu erhalten. Aber vielleicht sind ja die Maschinen und Verfahren veraltet, die zur Erhaltung der Ordnung verwendet werden? Vielleicht ist deren Wirkungsgrad so miserabel, das wir an die Anfänge der Dampfmaschine erinnert werden.

Wir begeben uns also wieder auf die Suche nach Dingen, die keinen Wert für den Kunden erzeugen. Das könnten z.B. Managementberichte sein, die benötigt werden, um das Projekt zu lenken. Die Notwendigkeit des Berichts ist begründet aber die Art und Weise, wie dieser Bericht erstellt wird, ist die pure Energieverschwendung. Wenn wir auf einen Berg steigen, nehmen wir sicherlich etwas zu trinken mit aber wir überlegen uns gut, ob wir für eine Tagestour 10 Liter Wasser nach oben tragen wollen oder ob wir nicht mit einem Liter auskommen und lieber etwas Geld mitnehmen, um uns oben mit einem frisch gezapften Bier zu belohnen.

Lösung: Energieaufwand für unterstützende Tätigkeiten verringern.

Wenn es uns gelingt, den Energieaufwand für die notwendigen, ordnenden Prozesse zu verringern, dann steigt nicht nur die Produktivität, auch die Prozesse werden nicht mehr als Arbeitsbehinderung, als Fluch wahrgenommen.

Selbstähnlichkeit

Eine mögliche Betrachtungsweise unserer Welt ist die Systemsicht. Die Welt besteht aus Systemen, die wiederum aus Systemen zusammengesetzt sind. Die Teilsysteme stehen untereinander in Beziehung und kommunizieren miteinander. Deshalb ist das Gesamtsystem mehr als nur die Summe der Subsysteme.

Im Großen wie im Kleinen (Selbstähnlichkeit)

Für die Software Entwicklung ist das kleinste System ein Programmierer, der an seinem Rechner eine Software erstellt. Er überlegt sich dafür, wie er vorgehen muss und wie er seine Arbeit organisiert. Ein Team besteht aus mehreren „kleinsten Systemen“. Hier müssen sie sich gemeinsam Gedanken machen, wie sie bei der Realisierung vorgehen. Das lässt sich weiter fortsetzen auf größere Projekte an denen mehrere Teams arbeiten oder auf Software Firmen, die mehrere Projekte gleichzeitig abwickeln. Die Strukturen sind gleich und damit gelten auch die gleichen Gesetze. Die Schwierigkeit besteht in der Beherrschung der steigenden Komplexität.

Visual Studio 2008 Professional Edition Microsoft comes with five code metrics. Maintainability Index, Cyclomatic Complexity, Depth of Inheritance, Class Coupling and Lines of Code. There are a lot of other software metrics but Microsoft picked and shipped only these main indicators. It’s a good set to start measuring code. For the need of more details you can use additional tools like NDepends which brings 82 metrics you can get lost in.

How to run Code Metrics?

Open a solution and choose Calculate Code Metrics for Solution from the Analyze Menu.

This Code Metrics Results view shows an overview and lets you drill down. You can filter and export the results to Excel as well as open a Work Item from a result list item.

How to integrate Code Metrics in Code Analysis?

First you have to enable Code Analysis for your Visual Studio projects.

Then you make sure these Maintainability Warnings are enabled:

• CA1506: Avoid excessive class coupling
• CA1505: void unmaintainable code
• CA1502: Avoid excessive complexity
• CA1501: Avoid excessive inheritance

How to define a Check-in Policy for Code Metrics?

If you need a check-in policy for code metrics? The guys from The Visual Studio Code Analysis Team Blog describes how to activate that policy.

What’s the meaning of these Metrics?

A good overview provides the blog entry.

If you want to present the metrics to your management the Code Analysis Team gives you a few good arguments.

Lines of Code

Indicates the approximate number of lines in the code. The count is based on the IL code and is therefore not the exact number of lines in the source code file. A very high count might indicate that a type or method is trying to do too much work and should be split up. It might also indicate that the type or method might be hard to maintain. (Source: MSDN)

Microsoft uses the Physical LOC. The difference to the Logical LOC describes Patrick Smacchia in his blog.

Class Coupling

Measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration. Good software design dictates that types and methods should have high cohesion and low coupling. High coupling indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types. (Source: MSDN)

Depth of Inheritance

Indicates the number of class definitions that extend to the root of the class hierarchy. The deeper the hierarchy the more difficult it might be to understand where particular methods and fields are defined or/and redefined. (Source: MSDN)

Cyclomatic Complexity

Measures the structural complexity of the code. It is created by calculating the number of different code paths in the flow of the program. A program that has complex control flow will require more tests to achieve good code coverage and will be less maintainable. (Source: MSDN)

Wikipedia: Cyclomatic Complexity

Maintainability Index

Calculates an index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability.
(Source: MSDN)

Microsoft uses a range between 0 and 100 in difference to the SEI definition with a range from 171 to an unbounded negative number.

Books

• Professional Team Foundation Server (wrox)
  • Chapter 11: Administering and Customizing Work Items
• Pro Visual Studio 2005 Team System (Apress)
  • Chapter 5: Team Work Item Tracking
• Managing Projects with Visual Studio Team System (Microsoft Press)

Articles

• MSDN Magazin: Team System – Work Item Tracking
• MSDN Technical Article: Work Item Tracking in Visual Studio 2005 Team System
• dotnetpro (04/2006): Visual Studio Team System
• dotnetpro (06/2006): Visual Studio Team System
• dotnetpro (09/2007): Process Templates anpassen
• Customizing the Assigned To field on a Work Item Type
• Populating Lists on Work Items from an External Source
• Team Foundation Server Team Project Limits – Work Items
• Changing the list of Builds in Work Item Tracking
• Implementing custom validations in work item form
• Custom work item controls (I, II, III)
• Managing Lots of Work Item Queries

Blogs

• Teams WIT Tools
• Naren Datha’s Blog
• Brian A White’s Blog
• MSMVP.COM: Work Item Tracking

Customizing

• MSDN Library: Customizing Work Item Types
  • Work Item Type Customization Overview
  • Overview of Work Items and Work Item Types
  • Customizing Work Item Types on an Existing Project
  • Work Item Type Contents
  • High-Level Structure of a Work Item Type
  • How to: Create a New Work Item Type
  • Defining Work Item Type Fields
  • Defining Work Item Workflow
  • Defining the Work Item Form
  • Work Item Type Definition Localization and Globalization
  • Adding Integration Fields in Work Item Types
  • Work Item Type Schema Reference
• TFS Guide
  • Work Items Explained
  • Guidelines: Project Managemet / Work Items
  • Practices at a Glance: Project Management / Project Management
• Work Item Query Language (WIQL)

Extensibility

• TFS SDK: Work Item Tracking Extensibility
• TFS SDK: Reference

Trainings

Hands on Lab

• Visual Studio 2005 Team System Basic Training (Level 200)
  • Module 7: Team Explorer
• Visual Studio 2005 Team System Deep Dive Training (Level 300) – not public
  • Module 5: Team Foundation Server Extensibility
  • Module 7: Team Projects & Process Template Customization

Tutorial

• Team Foundation Work Item Tracking Walkthroughs
  • Walkthrough: Tracking Work Items
  • Walkthrough: Adding Links and Attachments to Work Items
  • Walkthrough: Creating a Work Breakdown Structure from Requirements in Microsoft Project
• Customizing Work Item Types on Team Foundation Server
  • Walkthrough: Make Basic Customizations to a Work Item Type
  • Walkthrough: Make Advanced Customizations to a Work Item Type
  • Walkthrough: Administer Fields in a Work Item Type

Web Casts

• Designing a New Work Item Type Definition and Form (Level 200)
• Visual Studio Team System (Teil 5-10) – Work-Items (Level 200)
• Managing Change with Visual Studio 2005 Team Foundation Server Work Item Tracking (Level 300)
• Managing Work with Visual Studio 2005 Team System (Level 400)

Presentations

TechEd 2005

• DEV 461 – Microsoft Visual Studio 2005 Team System: Advanced Project Management and Reporting in Visual Studio 2005 Team System
• DEV 463 – Microsoft Visual Studio 2005 Team System: Maximizing Collaboration with Team Foundation Server

Microsoft Technical Summit 2006

• Customizing and Extending TFS

TechEd 2006

• DEV327: Visual Studio 2005 Team Foundation Server (Part 1): Applying Version Control, Work Item Tracking and Team Build to Your Software Development Project
• DEV429: Visual Studio 2005 Team Foundation Server (Part 2): Developing Custom Process Templates, Work Item Types and Policies

TechEd 2007

• DEV322: Microsoft Visual Studio Team Foundation Server (Part 1 of 2): Applying Work Item Tracking and Version Control to Application Lifecycle Management (PPT)
• DEV336: Microsoft Visual Studio Team Foundation Server (Part 2 of 2): Customizing Team Foundation Server for Application Lifecycle Management (PPT)

Support

Forum

• Team Foundation Server – Work Item Tracking

Tools

• TFS Power Tools: Work Item Templates
  • Work Item Templates: Introduction
  • Work Item Templates: Buld Edit
  • Work Item Templates: Advanced Tips 
• Custom Controls for Work Item Tracking (CodePlex)
  • Screenshot Controls
  • Webbrowser Control
  • MultiValue Control
• TFS Quick Search (CodePlex)
  quick search of all/any terms against fields Title, Description and History.
• Search Work Items (CodePlex) (Blog)
  quickly and easy search work items
• TFS Work Item Explorer (CodePlex)
• TeamCompanion for Microsoft Outlook 2007
• TeamLook – Manage WorkItems within Outlook
• Work Item Tracking RSS Feed
• Outlook macro to create work item and changeset hyperlinks
  • Updated for Outlook 2007
• Team System Outlook Addin 
• Web Forms for Submitting Issues to Team Foundation Server
• TFS Work Item Hierarchy
• TFS Migration and Synchronization Toolkit (CodePlex) (Blog)
  one-way / biderectional synchronizing between workitem tracking and other systems
• SnagIt Output for Microsoft Visual Studio Team System
  add screenshots to Work Items
• Work Item Creator (CodePlex) (Video)
  supports hierachical Work Items
• Dashboard Creator Tool Part I, Part II, Part III, Part IV
• TFS Issue Tracker (CodePlex)
• TFS Allert (CodePlex)
• TFS Timesheet (CodePlex)
• TFS Event Subscription Tool (CodePlex)
• TFS Tray Icon Client (CodePlex)
• TFS Work Item Hierachy – Custom Control (CodePlex)
• Requirements Manager for VSTS and MindManager Pro 7 
  (for MM Pro 6) (blog)
  Use MindManager to create software requirements documents and turn those requirements into work items on Microsoft Visual Studio Team System. The requirements map then becomes a bi-directional link to the work items.
• Event Subscription Tool (CodePlex) (blog)
  GUI for bissubscribe.exe usable at Client.
• Borland CaliberRM
  Enterprise-Software-Requirements-Management-System
• Project Server 2007 VSTS Connector
  integrate the project management capabilities of VSTS with Project Server 2007
• List of Bug and Defect Tracking Tools