Projektmanagement: Team Foundation Server mit Project und Excel – Teil 1

„Projektmanagement ist für Projektmanager. Quellcodeverwaltung ist für Entwickler.“ Diese Doktrin bestimmt den allgemeinen Tenor in der Softwareentwicklung. Doch wer übernimmt das Projektmanagement während der Arbeit mit einem Team Foundation Server? Oftmals der Entwickler, da Projektmanager sich hier einfach nicht „zuhause“ fühlen.

Viele Projektmanager können sehr gut mit Werkzeugen wie PowerPoint, Excel und Project umgehen, sind jedoch nicht in der Bedienung des TFS geschult. Somit bleibt die Pflege und das Management der Entwicklungsprojekte innerhalb vom TFS dem Entwickler überlassen, obwohl dies eigentlich die Aufgabe des Projektmanagers wäre. image

Neben der Zuständigkeitsfrage ist das doppelte Erledigen von Aufgaben zeitraubend. Der Projektmanager beobachtet den Fortschritt der Projekte auf Basis manuell gepflegter
Diagramme. Deren Pflegeaufwand könnte eingespart werden,  da alle notwendigen Daten sowie fertige Reports und auch Trendaussagen vom TFS bereits frei Haus geliefert werden.

Damit jeder mit dem Werkzeug arbeiten kann, welches er beherrscht und darüber hinaus am besten für seine Arbeit geeignet ist, bietet sich die Nutzung der Integrationsfeatures an, welche die Zusammenarbeit zwischen dem TFS und Microsoft Project mühelos gelingen lässt. Der zentrale Dreh- und Angelpunkt ist dabei das Work Item-Tracking.

Eins der zentralen Probleme ist die fehlende Übersicht über den Verlauf einzelner Work Items Arbeitsaufgliederungszeitplan in Team Explorerinnerhalb des TFS. Microsoft Project hingegen bietet diese Möglichkeit und durch die Nutzung der Integrationsfeatures kann Microsoft Project nicht nur zum Betrachten der Work Items, sondern auch zum Anlegen dieser verwendet werden.

Im Rahmen dieser Artikelserie werde ich diverse Aspekte der Zusammenarbeit zwischen dem TFS, Microsoft Project und Microsoft Excel erläutern und Wege aufzeigen wie Probleme, die in der Kommunikation zwischen Projektmanager und Entwickler bestehen, gelöst werden können.

Die Serie gliedert sich inhaltlich in folgende Abschnitte:

  • Projektmanagement mit dem TFS – Ein Anfang mittels Work Item-Tracking
  • Alles in einer Hand. Entwicklungsprojekte planen mit Microsoft Project
  • Jetzt wird’s ernst: Zeit- und Ressourcenverwaltung
  • Planung ersetzt das Chaos durch den Irrtum: Agil bleiben mit Microsoft Project
  • Von Experten für Experten: Anpassung von Microsoft Project Feldzuordnungen

Projektmanagement mit dem TFS: Ein Anfang mittels Work Item-Tracking

Im Rahmen dieses Artikels werde ich mich vorzugsweise auf den Top-down Modellierungs-Prozess beziehen.

Im Zentrum des Projektes steht das Ziel des Projekts, das durch das Abarbeiten der Work Items umgesetzt werden soll. Das Work Item stellt somit den Schnittpunkt der zu erledigenden Aufgaben und dem Code dar. Mit Work Items kann der Projektleiter das Erreichen des Projektzieles besser planen und die Teammitglieder haben eine Übersicht der zu erledigenden Aufgaben. Je nachdem welche Art von Softwareentwicklungsmodell man verfolgt (MSF for Agile Software Development, MSF for CMMI Process Improvement, Scrum) unterscheidet sich die Art der Work Items sowie die Arbeitsweise der Teammitglieder.

Bevor mit dem Schreiben des Quellcodes begonnen werden kann, muss ein Teamprojekt im TFS existent sein. Davon ausgehend, dass der Projektleiter auch als Projektadministrator innerhalb des TFS fungiert, legt dieser das Teamprojekt an. Dabei selektiert der Projektadministrator die im Team verwendete Prozessvorlage für das Softwareentwicklungsmodell und bestimmt welche Teamprojektsammlung für das neue Projekt verwendet werden soll.

Wenn das Projekt angelegt ist, können die Teammitglieder dem Projekt zugeordnet werden. Sollte der TFS in einer Umgebung mit einem Active Directory betrieben werden, empfiehlt es sich, die Benutzerberechtigungen über AD-Gruppen zu steuern. Einige Gruppen werden vom TFS automatisch für ein neues Teamprojekt definiert: Lesezugriff (Readers), Schreibzugriff (Contributors), Administratoren (Project Administrators) und eine interne Gruppe zum Buildmanagement (Build Services).

Steht der imageGrundaufbau des Projektes, muss dieses nun nur noch mit den zu erledigenden Aufgaben gefüllt werden: den Work Items. Im Visual Studio wird dies über den Team Explorer realisiert. Sobald eine Verbindung zu der entsprechenden Teamprojektsammlung besteht, können für das ausgewählte Projekt Work Items angelegt werden.

Soll Quellcode an den TFS übergeben werden sollen, kann man diese Änderung mit einem Work Item verbinden. Zudem kann eine solche Zuordnung durch den Projektadministrator als verpflichtend gesetzt werden. In dem Work Item müssen dann die Zeiten erfasst werden (noch verbleibende Zeit und benötigte Zeit), damit im späteren Verlauf eine Auswertung über die effektive Zeit des Projektes gemacht werden kann.

Die Möglichkeiten in der Softwareentwicklung mit TFS, Excel und Project

Bei sehr umfangreichen Projekten wird man schnell feststellen, dass die Übersicht der Work Items im Visual Studio nicht mehr ausreicht.Arbeitsaufgliederung von Aufgaben in Excel Für die Erfassung oder um die Aufgabenplanung bei kleineren Projekten (~200 Work Items) tabellarisch darzustellen kann Excel eine große Hilfe sein. Mit Hilfe des Work Item Addins können die Work Items aus dem TFS nach Excel importiert und dort offline bearbeitet werden. Das hat mehrere positive Effekte: Zum einen können Änderungen an den Arbeitsaufgaben gemacht werden, ohne dass eine aktive Verbindung zum TFS bestehen muss und zum anderen, dass die Übersicht wesentlich besser ist, als im Visual Studio. Natürlich kann man auch Auswertungen über Excel machen. Die Änderungen können jederzeit an den TFS übertragen werden. Hierbei werden nur geänderte oder neue Arbeitsaufgaben an den TFS übertragen. Für den Projektmanager bietet Microsoft Project eine ähnliche Funktionalität: Man kann aus den vorhandenen Work Items einen Projektplan erzeugen lassen und erhält schnell und einfach einen Überblick über das gesamte Projekt. Da der Projektmanager oftmals mit Microsoft Project besser umgehen kann, als mit dem Visual Studio, kann er die Work Items auch einen Projektplan ausarbeiten und diesen dann an den TFS weitergeben. Auch in Project muss für die Synchronisation eine Verbindung zum TFS vorhanden sein. Die Offline-Funktionalität stellt somit sowohl bei Excel, als auch bei Project eine gute Möglichkeit für Präsentationen wie z. B. einen Kundenworkshop für Fehlerdiagnosen dar.

Somit ergeben sich die folgenden Punkte:

Mit Excel

  • können zeitsparend Massenoperationen vorgenommen werden
  • können die Work Items in einer tabellarischen Hierarchie Betrachtet und Bearbeitet werden

Mit Project

  • existiert ein vertrautes Tool zum Betrachten und Bearbeiten von Projektplänen
  • können Gant-Charts erstellt und Kollisionen der Work Items überwacht werden

Zusammen stellen der TFS, Excel und Project ein sehr mächtiges Werkzeug zum Verwalten von Projekten dar.

Die Projektplanung mit Project und Excel werde ich im nächsten Blogartikel dieser Serie demonstrieren.

INotifyPropertyChanged - Das Elend hat (fast) ein Ende

Mit Visual Studio 2012 kommen neue Compiler und das .NET Framework 4.5 daher. Soweit nichts Ungewöhnliches. Natürlich gibt es auch jede Menge neue Sprachfunktionen und Bibliotheken. Besondere Aufmerksamkeit verdienen dabei die sog. Caller Info Attributes, die mit Visual Studio 2012 eingeführt werden und mit denen dem Entwickler ein eleganter Weg geöffnet wird, das PropertyChanged Event auszulösen.

Zur Auffrischung: Das Interface INotifyPropertyChanged stellt sicher, dass das PropertyChanged Event implementiert wird. Sind Klassen datengebunden, erfährt das Framework so, dass sich die Daten geändert haben. Im Setter eines jeden Properties muss dazu dieses Event ausgelöst werden; die Crux dabei ist allerdings, dass die PropertyChangedEventArgs dazu einen String-Parameter mit dem Namen des jeweiligen Properties verlangen.

Sollte sich im Nachhinein der Name ändern, kann wird es zu unerwartetem Verhalten kommen, wenn nicht daran gedacht wurde, auch den Magic String im Property Setter zu aktualisieren. Speziell dieses Thema ist mitunter schon viel diskutiert und auch in Form eines Coding Dojos der dotnetpro verarbeitet worden (Stichwort: “Unit Tests”).

Der folgende Code zeigt vereinfacht das klassische Vorgehensmodell:

 1:  public class Person : INotifyPropertyChanged
 2:  {
 3:     public event PropertyChangedEventHandler PropertyChanged;
 4:  
 5:     public string Name
 6:     {
 7:         get { return name; }
 8:         set
 9:         {
 10:             if (value != name)
 11:             {
 12:                 name = value;
 13:  
 14:                 // Call OnPropertyChanged whenever the property is updated
 15:                 RaisePropertyChanged("Name");
 16:             }
 17:         }
 18:     }
 19:  
 20:     private void RaisePropertyChanged(string member)
 21:     {
 22:         var handler = PropertyChanged;
 23:  
 24:         if (handler != null)
 25:         {
 26:             handler(this, new PropertyChangedEventArgs(member));
 27:         }
 28:     }
 29:  
 30:     private string name;
 31: }

 

Es ist nicht schwer sich vorzustellen, wie aufgebläht der Code wird sobald es nicht mehr nur um ein, sondern um spürbar mehr Properties geht.

Das .NET Framework 4.5 bietet hierfür eine Lösung an, indem es mit den neuen Caller Info Attributes einer aufgerufenen Methode Informationen über den Aufrufer quasi frei Haus mitzuliefert. Das folgende Beispiel verdeutlicht das anhand des CallerMemberName Attributs:

 1: protected void RaisePropertyChanged([CallerMemberName] string member = "")
 2: {
 3:   var handler = PropertyChanged;
 4:  
 5:   if (handler != null)
 6:   {
 7:     handler(this, new PropertyChangedEventArgs(member));
 8:   }           
 9: }

Der Methode RaisePropertyChanged muss nun nicht mehr der Name des Properties übergeben werden. Durch das Attribut CallerMemberName, das im NameSpace System.Runtime.CompilerServices enthalten ist, geschieht dies implizit.

Eine Möglichkeit, um nun die neue RaisePropertyChanged Methode nicht in jeder Klasse implementieren zu müssen, ist übrigens ganz einfach die Vererbung.

 1: public abstract class BaseBO : INotifyPropertyChanged
 2: {
 3:     public event PropertyChangedEventHandler PropertyChanged;
 4:  
 5:     protected void RaisePropertyChanged([CallerMemberName] string member = "")
 6:     {
 7:         var handler = PropertyChanged;
 8:  
 9:         if (handler != null)
 10:         {
 11:             handler(this, new PropertyChangedEventArgs(member));
 12:         }           
 13:     }
 14: }

 

Damit reicht es aus, die betroffenen Klassen einfach von der Klasse BaseBO abzuleiten (bei uns werden i.d.R. Fachobjekte an Views gebunden, daher der Name: BO = Business Object). Das reduziert den Aufwand für die Entwicklung von datengebundenen Klassen auf ein Minimum.

Und nun?

Und nun werden noch Wetten angenommen, ob in .NET 5 dann endlich einzelne Properties bis hin zu Klassen mit der Anweisung dekoriert werden können, dass die Properties im Falle einer Änderung das Event selbstständig auslösen sollen. AOP hat es bereits vorgemacht.

Stefan Lieser hat übrigens vor einiger Zeit in die Lambda-Trickkiste gegriffen und schon vor .NET 4.5 eine Lösung aufgezeigt, ohne Magic Strings das PropertyChanged Event auszulösen. Mehr dazu auf seinem Blog.

Distributed Kanban. Wenn nicht ich… wer dann?

Was war zuerst da? Henne oder Ei? Mittlerweile ist die Antwort auf die Frage zwar weitestgehend bekannt, aber dennoch stellt sie eines klar: Irgendetwas ist immer zuerst da. Der Rest kommt dann schon. Irgendwann.

Auf Kanban bezogen könnte das z.B. so aussehen: Ihr Team ist bereits ein wenig in die Jahre gekommen hat bereits viele Jahre Erfahrungen in der Entwicklung von Enterpriseapplikationen und zeigt sich skeptisch in Hinsicht auf neumodische Verfahren zur Arbeitsorganisation? Kanban klingt zu sehr nach einem klingonischen Altbier denn einer schlanken Methode, Blockaden im Arbeitsfluss aufzudecken und Überlast greifbar zu machen? Dann hilft vielleicht Distributed Kanban.

Wenn nicht ich… wer dann?

Distributed KanbanEiner muss anfangen. Und manchmal hilft es, wenn man selbst derjenige ist. Wer sonst wäre besser dazu geeignet, den effektiven Nutzen von Kanban im Softwareentwicklungsprozess positiv zu demonstrieren? Und das geht so:

  1. Auf dem eigenen Whiteboard wird passend zu dem laufenden Projekt eine klassische Kanban Aufteilung vorgenommen
  2. Es wird ein Template mittels Word erstellt auf dessen Basis Sets an Kanban Karten ausgedruckt werden können
  3. Lustige Avatare, auf bunte Magnete geklebt erhöhen den individuellen Spaßfaktor

Und was dann? Dann organisiert man seine eigene Arbeit (z.B. WorkItems) auf seinem eigenen Whiteboard. Auch ohne Tools starten zu müssen, Abfragen zu erstellen oder “Moment, ich suche das mal eben raus…” antworten zu müssen auf die Frage: “Wie ist der Stand der Dinge?”, die der Teamleiter bevorzugt morgens um 7:55 Uhr zu stellen pflegt, reicht ein Blick auf das eigene Whiteboard, um alle Fragen beantworten zu können. Und sobald zu viele Aufgaben den Weg in das eigene Büro finden, lässt sich sofort darauf reagieren. Die Erfahrung der Greifbarkeit, oder Neudeutsch: Haptik wird schnell auch die Kollegen neugierig machen.

Und wenn das nicht reicht, brechen die lustigen Avatare auf jeden Fall das Eis. Der überwiegende Teil des Teams antwortet mit “Ja, ich weiß.”, wenn der Ehepartner ein Telefongespräch mit “Ich liebe Dich!” beendet? Dann sind vielleicht Starwars-Charaktere empfehlenswert. Auf Regressionsfehler reagieren die Kollegen mit einem lautstarken “D’oh!”… wie wäre es mit Simpsons-Figuren? Sehr beliebt und aufgrund der meist runden Form von Tafelmagneten sind auf jeden Fall auch die Bewohner der illustren Stadt Southpark.

Sobald weitere Kollegen einsteigen – selbst wenn es zunächst nur deshalb geschieht, damit auch sie die coolen Magnete bekommen – dann können Karten sogar untereinander ausgetauscht werden, falls ein anderer Entwickler Arbeitspakete übernimmt (“distributed”).

Und wenn einmal die Hemmschwelle überschritten ist, wird endlich ein großes Kanban-Board für das gesamte Team eingeführt.

Aber egal wie Sie es anstellen: Fangen Sie an!

Stubs und Shims. Microsoft Fakes erklärt.

Microsoft geht mit der Visual Studio 11 Beta im April auf eine Roadshow durch verschiedene Großstädte. Im Rahmen der Veranstaltung werden mehrere Quick-Hit Videos veröffentlicht, die die neuen Features kurz und knackig vorstellen.

Wer interessiert ist: Vielleicht gibt es noch Tickets (die Teilnahme ist kostenlos!).

Fakes ist natürlich auch dabei. Neben den Möglichkeiten einfacher Stubs werden in dem Video auch die sogenannten Shims vorgestellt. Der Clou bei dieser Möglichkeit: Visual Studio baut die Umleitungen in die eigenen Delegate während des Compiler-Laufes direkt in den MSIL Code ein. So kann auch Code isoliert werden, der z.B. auf statische Properties aus dem .NET Framework selbst zugreift. 

Das Quick-Hit Video mit einer Übersicht über Microsoft Fakes gibt es auf vimeo zu sehen unter http://vimeo.com/40860649.

Das Microsoft Fakes Isolation Framework ist ein Mocking Framework, das als neues Feature direkt in Visual Studio 11 Beta integriert wurde, um speziell im Kontext von Unit-Tests Abhängigkeiten durch Attrappen zu ersetzen und so zu simulieren. Dadurch wird der zu testende Code sauber isoliert und kann unabhängig von anderen Komponenten und variablen Daten getestet werden. Das Quick-Hit Video  zeigt im Detail, was das bedeutet und welche Möglichkeiten Fakes dazu bereithält.

Ein Maulwurf in Visual Studio 11: Das Microsoft Fakes Isolation Framework

Mittlerweile ist die Verfügbarkeit der Visual Studio 11 Beta hinreichend bekannt. Was aber die wenigsten wissen: Unter der Haube steckt noch einiges mehr, als Microsoft aktuell bewirbt. Und dazu gehört z.B. Microsoft Moles.

Pardon. Ich meine natürlich das Microsoft Fakes Isolation Framework. Noch nie davon gehört? Das ist kaum verwunderlich. Sucht man danach im Internet, trifft man aktuell höchstens auf zwei Referenzen. Zum einen die Landing Page auf Microsoft Research für Pex & Moles und zum anderen auf die vorläufige Hilfe zu Visual Studio 11 auf MSDN. Dass letztere kaum auffindbar ist, wenn nicht gezielt danach gesucht wird, leuchtet ein. Und da die Hilfe zum jetzigen Zeitpunkt weder vollständig noch korrekt ist, stellt TOP TECHNOLOGIES hiermit das Microsoft Fakes Isolation Framework kurz vor und demonstriert mit einer funktionierenden Solution, wie man damit jetzt schon umgehen kann.

Am Ende dieses Artikels gibt es eine Zip-Datei mit der Solution zum Herunterladen.

More...

Der Neue und das Windows Phone…

Verkaufsstart des neuen iPads, der ideale Moment um sich über etwas völlig anderes zu unterhalten!

profilbild_twitDer geneigte Leser dieses Blogs wird sofort merken: “Das ist ja gar nicht der Christian, der da schreibt!” Stimmt, ich bin der Marcus, ebenfalls Mitarbeiter der TOP TECHNOLOGIES CONSULTING GmbH im Bereich der Softwarearchitektur und -entwicklung und werde von nun an hier und da ein paar Beiträge beisteuern. Meine Themenschwerpunkte werde vermutlich in Richtung Windows Phone Development und Windows Installer XML gehen aber wie so oft sind Ziele dazu da, um angepasst zu werden. Lassen wir uns also gemeinsam überraschen, was alles kommen wird. 

 
Da bin ich doch vor 2 Wochen mit 2 Kollegen in Darmstadt auf der BASTA! Spring 2012 gewesen, um unter anderen einen sehr guten Windows Phone Workshop von Max Knor zu besuchen und treffe da natürlich auch wieder Dariusz Parys. Er trug an dem Abend ein Shirt mit dem “I love Windows Phone” Branding. Leider konnte er mir so ein Shirt nicht organisieren, dennoch hat es mich irgendwie inspiriert mit dem Thema Entwicklung für Windows Phone endlich einen entscheidenden Schritt voran zu kommen. Ich nutzte damit die Woche, um neben der Konferenz auch an meiner ersten App zu schreiben, die sich auch allmählich der Vollendung nähert. Weitere Informationen dazu in den nächsten Wochen.

Controls für die Welt

Eine vernünftige App Entwicklung bedarf natürlich auch einigen vernünftigen Controls und insbesondere einer vernünftigen Dokumentation, wie diese zu verwenden sind. Auf der Suche danach landet man für gewöhnlich beim “Silverlight for Windows Phone Toolkit”. Ohne dem Toolkit ist die Windows Phone Entwicklung gefühlt unmöglich, da die Control-Basisausstattung dem Kühlschrank eines Studenten entspricht: “Voller Hoffnung bald gefüllt zu werden”.

Um die dann aufkommende Frage zu beantworten, wie die Controls denn überhaupt eingesetzt werden, bietet sich das aktuellste – kostenlose – Ebook “Windows Phone Toolkit In Depth 2nd edition” von Boryana Miloshevska an. Das Buch versteht sich selbst als ein umfassendes Begleitwerk für jeden, der an Silverlight für Windows Phone Entwicklung interessiert ist und dafür das genannte Toolkit verwendet. Es werden sämtliche Controls in aller Tiefe beschrieben:

  • Was können sie
  • Wie werden sie eingebunden
  • Best Practices für die Verwendung
  • Beispielcode

...und alles for free! Wer ernsthaft Apps für Windows Phone entwickeln möchte, kommt um dieses Buch eigentlich gar nicht herum, mit Ausnahme er ist gewillt sich die Nächte mit Bing und Co. zu vertreiben, um sich das Wissen manuell anzueignen.

Wenn Metro draufsteht, sollte auch Metro drin sein!

Controls und das Wissen wie sie implementiert werden ist in der Windows Phone Welt aber nicht das Einzige was man braucht um Apps zu schreiben, die sich einfach gut anfühlen. Microsoft hat mit Windows Phone Metro eingeführt; für die Einen eine Richtlinie, die auf Jack Sparrow Art mal mehr oder weniger gut umgesetzt wird, für die Anderen beinahe schon ein Lebensgefühl.

Wer Metro sieht, weiß sofort dass es Metro ist, es besticht durch seine Leichtigkeit und Übersichtlichkeit. Man hört auch immer wieder, dass jetzt jeder hübsche Apps entwickeln kann, weil Metro dafür ganz von alleine sorgt, aber genau da wird Jack Sparrow zum Piraten, denn wer sich nicht an die Standards hält, hat ganz schnell eine App produziert, die eben doch gruselig aussieht. Metro-ähnlich aber irgendwie nicht so ganz.

Jeff Wilcox hat dafür einen Metro Designguide für Entwickler veröffentlicht, der wunderbar zusammenfasst woran man alles denken sollte, wenn seine App zum richtigen Metroversum gehören soll. Ich habe mich bei meiner App auch zunächst gefragt, warum die Texte eigentlich so weit links sind und nicht bündig dort, wo ich sie erwartet hätte. Muss ich etwa die Margins verändern? Nein! Einfach das Style Attribut des TextBlock Controls anpassen und auf “PhoneTextNormalStyle” setzen und schon ist der Text dort, wo er hin gehört. Jeff hat hier sehr viele Themen zusammengefasst und auf einer Seite veröffentlich, die sich auch prima ausdrucken lässt, was bei der offiziellen Microsoft Dokumentation aufgrund ihrer vielen Subpages eher aufwändig ist.

Zusammengefasst ...

...lässt sich also sagen, dass der ambitionierte Windows Phone Entwickler anfangen wird Spaß zu haben, wenn die ersten guten Rezensionen für seine App eingehen. Hält er sich an die Design Standards, dann wird dies alleine dadurch schon sehr schnell passieren. Alles was er somit braucht sind das Windows Phone Toolkit, das dazugehörige Ebook und der Metro Designguide – “Zum Mitnehmen bitte!”  ;-)

Visual Studio lautet die Frage.

42 lautet die Antwort. Das ist die Anzahl der Pixel, die Microsoft durch die UI-Verschlankung in der Höhe eingespart hat. 42 Pixel mehr, um zwei weitere Zeilen mit Code einblenden zu können. Vergessen wir allerdings einmal kurz diese zwei Zeilen und wenden uns der gesamtheitlichen Frage nach der Veränderung der UI zu.

[…] the cut, copy and paste toolbar commands have been removed since we know from our instrumentation data that the majority of developers use the keyboard shortcuts for these commands.

Instrumentation data ist hier das Stichwort. Microsoft macht nichts einfach so. Niemals. Icons werden nicht einfach verändert, weil es eine neue Doktrin gibt (auch wenn sie Metro heißt). Schaltflächen werden nicht einfach entfernt, weil irgendein Mitarbeiter meint, das wäre besser so.

For example, during usability studies with the new toolbar settings, many users have noticed the Navigate Forward and Backward buttons and have assumed that this was new functionality added to the product when in fact this capability has been in the product for a number of releases.

iconographyUsability studies. Instrumentation. Zu Deutsch: Microsoft fragt uns Entwickler. Sie sammeln Daten über unser Nutzungsverhalten (wenn wir das akzeptieren; und wer kennt den Toast, der einen nach der Installation des Visual Studio 2010 danach fragt, nicht?). Und nach der Analyse kommt die Feststellung: Die Icons sind zu bunt, die Linien und Gradienten zu auffällig, die Anzahl der Schaltflächen zu hoch und das führt dann halt dazu, dass die UI einer Schönheitskurz unterzogen werden muss.

Schönheit liegt dabei zwar im Auge des Betrachters, aber wenn jemand bei Microsoft so viel Humor hat, dass die Antwort auf alle diese Fragen 42 lautet, dann kann ich mich nur darauf mit einem Schmunzeln freuen. Und an alles andere werden wir uns mit der Zeit sowieso gewöhnen.

Im Visual Studio Blog gibt es eine enorm umfangreiche Übersicht über Änderungen und Verbesserungen, inkl. Screenshots und Erläuterungen zu den Hintergründen. Wer mehr wissen will, klickt hier.

Preview: Team Foundation as a Service

Dass Microsoft vorhat, den Team Foundation Server auch als Cloudservice anzubieten, ist erst einmal nichts Neues. Dass vor kurzem eine erste Preview veröffentlicht wurde, haben viele aber noch nicht bemerkt.

Unter http://www.tfspreview.com ist es nun möglich, sich für die Preview zu registrieren. Falls man einer der Glücklichen ist, der bereits über einen Invitation-Code verfügt, präsentiert sich nach Anlegen eines Team Projektes die Website wie folgt:image

Die Authentifikation führt gegenwärtig über eine Windows Live ID.

TIPP: Wer über mehrere Live IDs verfügt und Probleme damit hat, sich anzumelden, da die Website sich nicht davon überzeugen lässt, die ID zu wechseln, probiere einfach mal den InPrivate-Modus des Internet Explorers.

Von hier aus kann die URL zur TFS Instanz eingesehen, so wie neue Team Projekte angelegt werden. Der Rest dient eher dem Erlernen des Umgangs mit dem TFS, bietet eine Feedback-Möglichkeit und – ganz typisch einer Preview – einen Bereich zum Erstellen eines Invitation Codes, der sich fünf Mal verwenden lässt.

Drei Invitations stünden noch zur Verfügung. Wer also daran interessiert ist, schreibe einfach einen Kommentar. Ansonsten der Wink mit dem Zaunpfahl: In Kürze startet in Darmstadt die diesjährige BASTA! Spring. Christian Binder wird dort durch die ALM Days führen und sicherlich auch weitere Invitation Codes verteilen.

Custom Windows Forms Controls und die ToolBox. Spass beiseite...

Wer schon einmal ein eigenes Control entwickelt hat, kennt die Situation eventuell: Wie bekomme ich das Control sauber in die ToolBox?

Wer sogar in einem Team arbeitet fragt sich mitunter auch: Wie verteile ich meine Controls an mein Team?

Gleich vorweg: Dieser Blogpost behandelt das Problem, dass es mit dem Visual Studio 2010 SP1 SDK unmöglich erscheint, VSIX-Pakete mit ToolBox Controls für .NET 3.5 Projekte zu erstellen (oder besser: Projekte, die auf eine Runtime früher als .NET 4.0 setzen).1

Das Intro nimmt es bereits vorweg: Ein mögliches Werkzeug, um Controls zu verteilen, nennt sich VSIX. Dabei handelt es sich um ein Paketformat von Microsoft, das im Prinzip nichts weiter ist, als eine ZIP komprimierte Datei deren Inhalt sich neben den zu verteilenden Assemblies auch aus Konfigurations- und Metadaten zusammensetzt. Am meisten hat der Entwickler natürlich Spass an solchen Daten, wenn es dafür eine Konfigurationsoberfläche gibt. Und die gibt es tatsächlich!

More...

TFS 2010. Schädling oder Pfau?

200px-DoNotFeedTroll_svgVor kurzem wurde von einigen renommierten Softwareentwicklern und –architekten ein Blogpost von Derek Hammer via Twitter verbreitet, in dem Derek feststellt, dass sich der Team Foundation Server zerstörerisch auf unsere Entwicklungskapazitäten auswirkt.

Neben der generalisierten Aussage “TFS Sucks” geht Derek allerdings auch im Einzelnen auf die Standbeine des Microsoft ALM Werkzeuges ein: Version Control, Bug Tracking, Project Management, Build System und Integration.

Während ich einige seiner Kritikpunkt nachvollziehen kann, sehe ich andere wiederum eher kritisch. Mein Feedback auf Twitter, es handele sich hier um gefährliches Halbwissen zog entsprechend die Nachfrage von Ralf Westphal nach sich, ob ich argumentativ den TFS “gebührend zu einem Pfau der technischen Führerschaft und Offenheit” machen könne. Obwohl es nicht meine Absicht war, den Eindruck zu erwecken, es handele sich beim Team Foundation Server um einen Pfau (ganz gleich ob führend oder offen), habe ich natürlich nichts dagegen, dennoch einige Halbwahrheiten näher zu beleuchten.

More...

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS