Check-In Policy Builder für TFS 2010

Endlich ist es soweit: Auf Basis des (großartigen) Feature Builder Power Tools (dem Nachfolger des inoffiziellen Blueprints-Projektes aus dem Jahr 2009) für Visual Studio 2010 habe ich den Check-In Policy Builder erstellt – ein Tool, das mir hilft Check-In Policies für den TFS zu schreiben. Nicht, dass das schwer wäre – aber es gibt ein paar Schritte, die vielleicht einfach etwas lästig sind und jetzt automatisch gehen. Momentan noch als Version 0.7 – ich freu mich über Feedback.

Hier geht’s zum Check-in Policy Builder.

Dinge, die ich an IE9 Beta mag

Ich nutze seit einiger Zeit IE 9 Beta. Meine I love Opera Kategorie ist vorerst trotzdem noch gültig. Dennoch gibt es so einige Dinge, die ich an IE9  Beta wirklich mag. Die will ich der Welt natürlich nicht vorenthalten.

1. Der Farbwechsel des Navigationsbuttons

Der Rückwärts-Button wechselt abhängig von der besuchten Seite die Farbe.. Das ist zwar sinnlos, aber irgendwie schick.  (Und funktioniert auch nur, wenn man einen Link auf die Seite aufruft.) Das sieht dann ungefähr so aus:

2. Der schnelle Start

IE9 startet schnell. Das ist gut. Mehr muss man nicht wissen.

3. Die Anzeige der Ladezeiten für Add-Ins

Wenn IE9 nicht schnell startet, liegt es wahrscheinlich an einem Add-In. An welchem? Das sagt einem IE9 selbst. Hier hat man dann auch die Möglichkeit die Schuldigen abzuschalten.

Auch, wenn das alles keine Killerfeatures sind: Die gute Nachricht dabei ist: Ich vermisse gerade noch fast nix. D.h. ich kann problemlos IE 9 beta nutzten, statt meiner alten Liebe Opera. Dadurch hat IE9 echte Chancen im Alltag als Standardbrowser zu bestehen. Ein bisschen was fehlt mir aber trotzdem noch, nämlich:

1. Die  (anpassbare!) Adressleistensuchfunktion (bekannt aus Opera und Chrome)

2. Die Mausgesten (auch wenn ich gar nicht mehr so oft mit Mäusen arbeite)

3. Die “Roll-Over-Tabs” (ich weiß nicht, wie das wirklich heißt, wenn man eine Maus hat, ist das aber der Hit!)

Aber vielleicht kommt davon ja noch was. Vielleicht in der Beta zwei. Oder in RTM. Die Adressleistensuchfunktion möchte ich auf jeden Fall nicht mehr missen. Den Rest brauch ich nur, wenn ich auch einen Maus hab…

MSDN Webcasts für Visual Studio 2010

Freudige Neuigkeiten für alle VS2010 Fans: Es gibt einen ganzen Sack voll neuer MSDN Webcasts, die über eine ansprechende Silverlight-App von Christian Binder und Dariusz Parys gebrowsed werden können. Einige der Webcasts habe ich beigesteuert, einen zum Thema Architekturvalidierung und einen zum Thema Code-Visualisierung. Hoffe es hilft ein bisschen bei der Orientierung in diesem umfangreichen Themengebiet…

Edit: Vielleicht nicht zwangsweise informativ, aber immerhin amüsant ist das Announcement auf der  offiziellen Visual Studio Website (Monitore te salutant). :-)

Die Cloud ist kein Spielzeug

Windows Azure ist leider kein Spielzeug. Denn das Pricing Modell ist so undurchsichtig, dass man als Dev jegliche Lust verliert überhaupt das Spielen damit anzufangen. Nicht nur, dass es unglaublich schwierig ist, im Voraus abzuschätzen, wieviel Geld man verbraten würde, wenn man eine “produktive” Anwendung in die Cloud hebt, es gibt auch keinen Limiter oder eine Notbremse, um  die Kosten irgendwie zu begrenzen, wenn man nur mal sehen will, was geht.

Zum Vergleich: Wenn ich bei meinem Hoster Webspace anmiete, oder bei meinem Telefonanbieter einen DSL Anschluss will oder einen Datentarif für’s Handy, dann will ich unter Umständen gedeckelte Kosten. Im Gegenzug kann ich damit rechnen, dass meine Leitung gedrosselt wird, wenn ich nach den ersten Tagen des Monats fast das halbe Internet übers Mobiltelefon heruntergeladen habe. Dies nehme ich aber bewusst in Kauf, damit ich auch nach der ersten Rechnung noch mein Frühstücksbrötchen finanzieren kann.

Bei Windows Azure ist das zum heutigen Zeitpunkt nicht so – für produktive, kommerzielle Anwendungen würde es wahrscheinlich auch kein sinnvolles Szenario sein, da ja dort gerade dann Geld verdient wird (nicht nur durch Microsoft, sondern auch durch die in der Cloud gehostete App) wenn viel passiert, also, wenn viel Traffic herrscht. Für die Entwickler Community ist der fehlende Kostendeckel aber ein Problem: Bei Windows Azure kann ich nicht nur konfigurativ, sondern gerade auch programmatisch dafür sorgen, dass ich mehr mehr Rechenpower aus den Microsoft Containern bekomme – in Form von weiteren VMs, die dynamisch hochgefahren werden. Das heißt: Wenn ich falsch programmiere, verbrate ich durch einen einzigen Programmierfehler unter Umständen sehr viel Geld – auch wenn letztlich niemand die Anwendung benutzt – ich wollte ja nur spielen. Und das ist nur einer von vielen denkbaren Fällen und vielleicht sogar noch der unwahrscheinlichste. Ebenso ist es möglich, dass ich schlichtweg vergesse mein Cloud-VM-Cluster abzuschalten oder die Kosten schlichtweg nicht im Blick habe und erst feststelle, wie viel Stunden Rechenzeit ich gebraucht habe, wenn die Rechnung kommt.

Wunschkonzert

Was ich mir wünsche, wäre also eine Art Flatrate: Meinetwegen X€ im Monat für monatlich Y Stunden Rechenpower auf maximal Z VMs plus ein bisschen Traffic. Wenn ich die Grenzen überschreite wird die Bandbreite für “Nutztraffic” reduziert, die Rechenpower meinetwegen auch, aber ich will noch weiterhin vernünftig darauf entwickeln können und meine Anwendung testen können – und natürlich, dass keine weiteren Kosten entstehen. Und: Klaro, ich werde keine kommerziellen Anwendungen darauf hosten, das darf natürlich in die AGBs… ich will ja nur spielen.

Für die Community ist es vielleicht nur ärgerlich, für Windows Azure kann diese Unzulänglichkeit doch bedeutend sein: Spätenstens seit David Chappells Vortrag über IT Innovations bei der Teched 2009 wissen wir ja, dass man gute Ideen nicht nur haben (Idea) und umsetzen muss (Implement), sondern dass man auch Menschen dazu bringen muss diese einzusetzen (Inject). Microsoft war bisher nicht zuletzt im letzten Punkt sehr gut. Aber momentan ist das Pricing für die Cloud leider alles anders als förderlich, was diesen letzten Punkt angeht. Ich hoffe das ändert sich – letzlich steht und fällt der Erfolg für Microsofts Cloud Lösung vielleicht genau mit den Leuten, die sie heute noch nicht ausprobieren – einer breiten Basis in der Community und einem Haufen erstklassiger Entwickler.

Scrum Template für TFS 2010? HIer isses!

Wie schon in einem alten Blogposting erwähnt stellt Microsoft selbst jetzt ein Scrum Prozess Template für den TFS zur Verfügung. Bisher war dieses bereits als Beta verfügbar. Ich bin gespannt, ob die Strukturierung der Workitems über den Workitem-Typen “Sprint” nur als Übergangslösung zu sehen ist, oder ob das die neue Stoßrichtung für Dev11 vorgibt. Bisher wurde die Sprintzugehörigkeit ja ausschließlich über Attribute geregelt. Aus eigener Erfahrung weiß ich, dass das immer wieder für heiße Diskussionen sorgt. Da das Template kostenlos über die VS Gallery kommt, empfehle ich, sich das Ganze einfach mal anzusehen.

Finale!

Dass die Bilder auf Google’s Internetseite je nach Tagesgeschehen und Jahreszeit ab und an mal geändert werden, dürfte ja jedem schon mal aufgefallen sein. Aktuell zu sehen: Ein Fußballstadion und die Fähnchen der Finalisten. Schätze in ein paar  Stunden ist es wieder weg… für alle die zu spät kommen:

Scrum in WM-Zeiten

Wenn die WM gut läuft, dann hat das schon mal Auswirkungen auf Fortschrittsgraphen jeglicher Art…

You are here!

Opera 10.60 bietet jetzt die Möglichkeit andere Opera User zu finden. Ich bin mir noch nicht im Klaren darüber, was es bringt, aber es ist auf jeden Fall witzig. Und die Genauigkeit ist beängstigend. Hier bin ich:

Letzter Aufruf: Dot-Net-Day

Jeder, der immer noch nicht weiß, was er an diesem Wochenende treiben soll, dem sei der .Net-Day Franken ans Herz gelegt. Wann? Morgen! Mehr Info gibt’s hier. Hingehen! Wir sehn uns dort.

Cloaking is a Private Thing

Visual Studio versteckt ja so einige Perlen, die man erst nach und nach entdeckt. Eines dieser mitunter wertvollen – aber auch reichlich unbekannten Features  - ist das “Cloaking”. Wie geht das, was ist darunter zu verstehen, wofür ist es gut?

Wie geht’s? 
Man kann im Visual Studio – unter Verwendung von Team Foundation Server als Quellcodeverwaltungssystem –. beliebige Ordner und Branches im Source Control Explorer über das Kontextmenü “Cloaken”. Einfach Ordner anwählen, rechte Maustaste, Cloak. Die Inhalte der Folder werden dann im SourceControl Explorer ausgegraut dargestellt.

Was bewirkt das?
Das hat zu Folge, dass die “gecloakten” Inhalte nicht mehr vom Team Foundation Server nachgeladen werden – auch wenn zum Beispiel auf den übergeordneten Ordner ein “Get Latest” ausgeführt wird.

Wer braucht das?
Man stelle sich die Situation vor, dass man als Mitglied eines Entwicklungsteams bestimmte Bereiche der Quellcodeverwaltung schlicht und ergreifend nicht benötigt. Zum Beispiel, weil darin Quellcode für Komponenten entwickelt wird, mit denen man nie in Berührung kommt, und deren Schnittstellen einem auch herzlich egal sein können. Oder Branches, auf denen man eben gerade nicht arbeitet. Oder es liegen dort zwar Dateien, diese sind aber nicht für das Produkt selbst, sondern für die Herstellung der Binaries relevant – zum Beispiel Buildskripte. Dann ist genau der richtige Zeitpunkt um zu “Cloaken”.

Welchen Vorteil bringt es?
Das Cloaken bringt folgenden Vorteile mit sich:
1. Zeitersparnis – beim Ausführen des “Get Latest” Befehls werden gecloakte Unterordner nicht mit vom Server geladen. Unterm Strich geht’s also schneller, bis man die neueste Version der benötigten Files auf seiner lokalen Platte hat.
2. Bandbreitenersparnis. Aus genau dem gleichen Grund. Aus eigener Erfahrung kann ich berichten, dass Bandbreite in vielen Firmen noch ein wesentlich limitierender Faktor ist, als man im Jahr 2010 erwarten würde. Gut also, wenn man hier auf einfache Weise was sparen kann.
3. Plattenplatzersparnis – es werden weniger Files geladen. Man kann also, wenn es sinnvoll ist, gewisse gemappte Folder einfach nie getten – nicht mal einmalig. Bei riesigen Quellcodebeständen spart man sich so haufenweise Plattenplatz. Natürlich geht das nur dann, wenn man den entsprechenden Quellcode nicht doch lokal benötigt…

Gibt’s auch Nachteile?
Ja. Größter Nachteil ist, dass man genau wissen muss, was man tut. Es ist zwar einfach zu bedienen, aber man muss sich bewusst sein, dass die gecloakten Files zwar noch physikalisch auf der Platte liegen (wenn sie überhaupt schon da waren)  – d.h. sie können auch referenziert werden (bspw Dlls) – aber die neueste Version eben nicht mehr automatisch vom Server geladen wird (was ja auch Sinn und Zweck ist). Wenn man also mal “vergisst”, dass man Cloaking verwendet hat, läuft man Gefahr Inkonsistenzen zu produzieren. Also: Mit Bedacht wählen was gecloakt wird – natürlich kann man es jederzeit wieder rückgängig machen.

Wen betrifft meine Cloaking-Einstellung eigentlich?
Sehr gute Frage, die immer wieder gestellt wird und bereits mit der Überschrift dieses Posts beantwortet wird: “Cloaking is a private thing” – man trifft diese Einstellung also immer nur für sich alleine und immer nur für jeweils genau einen Workspace zur gleichen Zeit. Das ist eigentlich auch sehr logisch. Den Ordner BuildProcessTemplates beispielsweise kann so ziemlich jeder im Team gefahrlos cloaken,  bis auf diejenigen, die tatächlich daran arbeiten – also eben z.B. der Buildmanager. Eine Entscheidung auf Teamebene was geclaokt wird und was nicht wäre also ziemlich sinnlos.
Das gleiche gilt für Workspaces: Die Einstellungen für Cloaking kann für den Laptop zuhause grundlegend anders sein, als die Einstellung für den Arbeitsplatzrechner im Büro.

TFS Powertools: TFPT – Unable to determine the source control server

Kurzversion:  Um das Problem zu lösen, braucht Ihr mit TFS2010 den Parameter “/collection”. Unter TFS 2008 “/server”.

Langversion: An dieser Stelle mal ein kleiner Hinweis für alle, die die Team Foundation Powertools auch über die Kommandozeile benutzen wollen - ich stolpere selbst oft genug und immer wieder darüber. Man will ein Kommando abfeuern und um sich zu versichern, was man tun muss, gibt man erstmal nur “tfpt” ein. Ergebnis: Siehe Screenshot.

Nächster Schritt: Zum Beispiel eine Query absetzen. Also, laut Screenshot ungefähr sowas eingeben:

tfpt query /wiql”Select [System.Id]  from WorkItems“

Aber – so leicht ist es nicht! Man bekommt folgende Fehlermeldung: Unable to determine the source control server.

Was ist schiefgelaufen? Man hat doch scheinbar alles richtig gemacht – auch tfpt query /help bringt nicht mehr Infos.

Die Lösung

Ok, was muss man also tun?

Schritt 1: Googlen (oder Bingen), auf (zum Beispiel) diesen Blog-Eintrag stoßen, lesen.

Schritt 2: Den fehlenden Parameter angeben, der irgendwie NIRGENDWO beschrieben ist: /collection . Kleiner Hinweis an dieser Stelle:  Bei VS 2008 hieß der Parameter noch /server, da es ja die Collections noch nicht gab. Entsprechend hat man auch nur die URL des Servers übergeben. Jetzt ist es die URL der Collection.

So heißt der Befehl in meinem Fall also richtig:

tfpt query /wiql:"Select [System.Id]  from   WorkItems" /collection:http://mrblonde:8080/tfs/DefaultCollection

Natürlich müsst Ihr “mrblonde” noch mit Eurem eigenen Servernamen ersetzen und auch den Collectionnamen anpassen.

Und so schaut das Ergebnis aus:

Wunderbar. Hoffe geholfen zu haben

Scrum Process Template für Team Foundation Server 2010

Heute wurde auf der Teched in New Orleans das erste offizielle Scrum Prozess Template für Visual Studio 2010 / Team Foundation Server 2010  vorgestellt – und zwar nicht von Drittherstellern, sondern von Microsoft selbst. Man konnte zwar schon bisher Scrum mit dem eingebauten MSF for Agile abbilden, 100% passend war es aber ohne eigene Modifikationen nicht. Momentan ist die verfügbare Version noch im Beta Status, einen geplanten Relase Termin habe ich noch nirgendwo gefunden. Wer mehr wissen will, ist gut beraten den entsprechenden Blogeintrag von Brian Harry zu lesen.

Was ist cool an Visual Studio 2010?

Wer es schon immer wissen wollte – hier die Antwort. Das Video ist das Ergebnis einer spontane Aufnahme einiger Arbeitskollegen, die versuchen auf die Frage “Was ist cool an Visual Studio 2010?” eine Antwort zu geben. Das Video ist auch zu finden als Video Response im offizellen Developerstories YouTube Channel . Ungestellt und genauso unvorbereitet. Und trotzdem wahr. Enjoy!

ALM – ab welcher TeamGröße lohnt es sich?

Bei der Diskussion über Application Lifecycle Management (beispielsweise, aber nicht zwingend auf Basis von Microsoft Visual Studio 2010) taucht immer wieder die gleiche Frage auf: Wann ist ein Team groß genug, damit es sich lohnt über ALM nachzudenken?

Die Antwort ist eigentlich relativ einfach. Mindestteamgröße: 1 Person. Es lohnt sich also immer. Und überall. Mag sein, dass es unglaubwürdig scheint. Ein Beispiel folgt sogleich. Wichtig ist vorab eines zu beachten: ALM ist nicht gleich ALM. Entscheidend ist, dass man sich über die Prinzipien von ALM im Klaren ist – dann kann man sich die Stücke rauspicken, die einen weiterbringen.

Ein Beispiel aus meinem eigenen Erfahrungsschatz

Als jemand, der beruflich mit SW-Entwicklung zu tun hat, ist man ja Ansprechpartner Nummer eins für die ganze (potentiell sehr große) Verwandtschaft und Bekanntschaft, wenn es darum geht “nur ganz schnell” mal “eine kleine” Website zu basteln. Und weil man ja nicht so sein will, sagt man eben mal “Ja” und tut’s. Das Basteln von privaten Homepages entspricht in vielerlei Hinsicht der Entwicklung einer kommerziellen Software. Größter und vielleicht einziger Unterschied ist: Der Ersteller sieht dafür kein Geld. Der Rest verläuft eigentlich wie immer …

Alles wie immer

Ihr glaubt es nicht? Hier ein Auszug…

1. Der Auftraggeber hat am Anfang überhaupt keinen Plan, was er überhaupt will. Fest steht allerdings, dass die Website am Ende supersexy sein muss.

2. Der Auftraggeber weiß noch nicht mal wofür er die Website eigentlich will. Es ist also vollkommen unklar, ob er ein Gästebuch, ein Fotoalbum oder irgendeine Art User-Authentifizierung braucht. (Oder nichts von alledem.) Klar ist nur: Am besten alles mal einbauen, damit er danach sagen kann, dass er’s doch nicht will.

3. Der Auftraggeber hat keinen Schimmer von der Technik. Es hilft nix irgendwas zu erklären. Das einzige was den Auftraggeber dazu bringen wird irgendwann mal zu sagen “Gut” oder “Schlecht” ist, wenn er die fertige Seite vor sich hat und feststellt, was überflüssig ist.

Entscheidet selbst, inwieweit das Euren Erfahrungen aus dem “echten” Berufsleben entspricht…

Die Anforderungen

Um sich das Leben nicht unnötig schwer zu machen, müssen wir nach gesundem Menschenverstand unter Berücksichtigung der obigen Punkte ungefähr folgendermaßen vorgehen, um zum Ziel zu kommen.

1. Den Auftraggeber frühzeitig in die “Lösung” einbinden.
2. Feedback ermöglichen und strukturiert sammeln und ebenso strukturiert abarbeiten.
3. Eine Möglichkeit finden, dem Auftraggeber heute nachzuweisen, dass er die Meinung von vorgestern gestern verworfen und heute wieder für gut befunden hat.
4. Aus genau diesem Grund eine Möglichkeit schaffen, den Quellcodestand von gestern wieder herzustellen – und dann auch zu wissen, was da eigentlich schon implementiert war.
5. Sich Schritt für Schritt vortasten.
6. Die Übersicht bewahren. Das heißt, genau wissen was erledigt ist, was wichtig ist, was nichtig ist.

Moment. Das klingt doch irgendwie nach ... irgendeiner Art Arbeitspaketverwaltung jenseits von Post-Its und Emails und vielleicht sogar iterativem Vorgehen? Nach Nachverfolgbarkeit und Reproduzierbarkeit?

Die Lösung

Struktur in den Arbeitspaketen? Workitems! Feedback? Workitems! Requirement Tracking? Workitems! Und schon sind wir mittendrin in der wunderbaren Welt von ALM. Und am Rande: Die Technologie des Produkts ist uns zu diesem Zeitpunkt noch absolut egal!

Das Beispiel ist übrigens nicht frei erfunden, sondern ich bin tatsächlich dazu übergegangen auch im Privaten (im konkreten Fall ein PHP-Projekt) mit Workitems und Team Foundation Server 2010 als ALM Plattform zu arbeiten.  Die sieht zwar nicht zwangsweise der “Kunde”, ich pflege die  gesammelte Information selbst in den TFS ein. Meine Erfahrung bisher: Alles supi. Übersicht ohne Ende. Kein Stöbern mehr in alten Mails, kein Wühlen in Post-Its oder anderen Zettelwirtschaften. Und gleichzeitig die hervorragende Möglichkeit Quellcodeänderungen auf Workitems zurückzuführen. Durchgehendes Nachverfolgen von Anforderungen im TFS  - klingelt da was?  Ich musste auch keinen separaten Server installieren: Microsofts TFS Basic läuft auch unter Windows 7 und Windows Vista. Sonst noch Wünsche?

Natürlich ist Workitem Management und Quellcodeverwaltung nicht alles, was ALM ausmacht. Es ist vielmehr nur der Anfang - aber das schöne ist ja: Man braucht nicht immer gleich alles. Ich zum Beispiel muss mir bei meinen privaten Projekten kaum Sorgen machen über Termine. Sie werden fertig, wenn sie fertig werden. Dafür sind sie auch privat.

Das ist in den wenigsten anderen Fällen so. Wenn im Privaten unter diesen “weichen” Rahmenbedingungen allerdings schon der Nutzen spürbar ist, alleine dadurch, dass ich eine Quellcodeverwaltung und ein anständiges Workitem Management etabliert habe und mir Gedanken über die Qualität meines Codes mache – wie hoch darf man dann erst den Nutzen ansetzen, wenn es wirklich ums Geld geht? Und um’s Geld geht’s nun mal, sobald ein Entwickler das Entwickeln anfängt.  

Vielleicht ändert sich das irgendwann bei mir auch einmal und meine privaten Projekte müssen plötzlich höhere Anforderungen erfüllen. Dann nehme ich eben noch die Planungskomponente des TFS auf Basis von Excel und Project dazu. Oder ich möchte noch wertvolles und aktuelles Reporting – das wird spätestens wichtig, wenn es um Geld und Zeit geht. Oder ich lass mal ein bisschen automatisiert die Web-UIs testen, um Zeit zu sparen und gegen Regression gefeit zu sein. Muss ich dann auf eine neue ALM Plattform? Nein, mein TFS bringt’s mit und ich aktiviere es, wenn ich es benötige. Check-In Policies um die Qualität oben zu halten? Oh, ganz vergessen: Hab ich eh schon eingeschalten… hilft mir ja selbst am meisten. Und wenn man den TFS sowieso schon nutzt, bekommt sie ja ohnehin geschenkt…

Fazit

Wie gesagt: Mindestgröße ist 1 Person. Schon da kann es sich spürbar lohnen. Und spürbar heißt, dass die Beteiligten leichter/schneller/besser  arbeiten können. Verundet oder verodert. Man braucht nicht immer alles, was irgendwelche Tools hergeben. Man entscheidet selbst, was weiterhilft. Aber wissen muss man schon was es noch gibt und was noch geht. Sonst weiß man ja auch nicht, was man beruhigt weglassen darf…

Kühe sind super!

Und wenn ich eine wäre, würde ich mich dafür einsetzen, dass es Milch nur noch in Gallonen gibt. Schluss mit den mickrigen 1 Liter Tetra Packs. Der Vorteil für den Konsumenten wäre, dass die Milch endlich mal zum Frühstücken (/Abendessen/Mittagessen/Zwischendurchessen) reicht – ohne, dass man eine neue aufmachen muss. Außerdem gibt es dann auch wieder ein praktisches Mundstück, was das direkte Züzeln an der Packung erheblich erleichtert. Obwohl man schon ordentlich Maßkrugstemmen üben muss, um überhaupt einen Schluck aus dem Pot zu kriegen, ohne sich komplett vollzuschütten. Es lebe die Milch Gallone! Natürlich nur im fettreduzierten Format (hier im Bild 2%), knapp oberhalb der “Schmeckt-wie-weißes-Wasser”-Grenze.

Auch die Kuh profitiert von Milch in Gallonen: Das Melken geht schneller, weil der Bauer nicht so oft absetzen muss.

Doppelte Datenhaltung - mal anders

Dass doppelte Datenhaltung oder “Datenredundanz” sehr leicht zu Inkonsistenzen führt, weiß jeder, der mal einen Datenbankengrundkurs besucht hat und irgendetwas über “Normalisierung” gehört hat. Dass Datenbanken nicht der einzige Bereich ist, für den das gilt, sondern, dass es auch Zeitungsartikel treffen kann, hat die FAZ am 29.5.2010 bewiesen – auf dem Titelblatt wurde in zwei Artikeln die gleiche Geschichte erzählt – einmal mit korrekten Angaben, einmal mit einer Null mehr als beabsichtigt.

So verstehen’s auch Laien. (Und jetzt keine Wortwitze über unsere Ministerin, bitte…)

Durchgängiges Requirement Tracing mit Visual Studio 2010 ALM

Wenn man Software Entwicklung betreibt kann man das auf unterschiedlichste Arten tun. Im Allgemeinen ist das abhängig davon, was man macht und wofür man es macht. Ein privates Tool wird wohl eher einem pragmatischen Entwicklungsansatz folgen. Ein professionelles Produkt sollte bestimmte Qualitätsrichtlinien einhalten. Ein kommerzielles Medizinprodukt muss unter vom Gesetzgeber vorgegebenen Qualitätsrichtlinien entwickelt worden sein – hier ist also sogar nicht nur die Qualität im Produkt sondern auch auf dem Weg dahin entscheidend. Anderenfalls darf das Produkt nicht verkauft werden.

Die Anforderung an Anforderungsmanagement aus der Q-Sicht

Einer dieser Qualitätsansprüche bei der Entwicklung von Medizinprodukten ist es, Anforderungen über den ganzen Entwicklungsprozess, also vom Anforderungsdokument  bis in den Code hin zu Testplänen nachverfolgbar zu machen. Das heißt überspitzt gesagt, es muss von jeder Zeile Code aus möglich sein, zu sagen, warum sie codiert wurde und wo sie getestet ist. Umgedreht muss es zu jeder Anforderung möglich sein, die Codezeile zu finden, die sie implementiert.

Ich mag jetzt gar nicht darüber schreiben, ob das sinnvoll ist, oder nicht. Die Frage wird abhängig davon, mit wem man darüber spricht sehr kontrovers diskutiert. Es gibt die Partei, die hier von Überregulierung, Behördentum und Bürokratie spricht und es gibt die Partei, die bei medizinischer Software einfach höchste Qualität erreichen will und dafür eben schonmal den Holzhammer auspackt. Je nachdem, ob man die Software gerade entwickelt und dadurch Leidtragender ist oder selbst (z.B. als Patient – also erst recht Leidtragender :-) ) auf funktionierende medizinische Software angewiesen ist, sind beide Positionen zumindest nachvollziehbar.

Was bisher geschah…

Die Ansätze, die zur Erreichung der durchgängigen Nachvollziehbarkeit in der Vergangenheit verfolgt wurden, haben zwar das Problem gelöst, waren aber meist für den jeweiligen Entwickler mit einem gewissen Zusatzaufwand verbunden – ohne einen gleichzeitigen Mehrwert in der täglichen Arbeit zu bieten.

Eine Möglichkeit ist zum Beispiel die Arbeit mit sogenannten “Requirement Keys”. Dabei wird jeder Anforderung ein eindeutiger sogenannter “Requirement Key” zugeordnet. Der Key lautet dann meist ungefähr so: RK_FEATURE_1234_5678. Überall wo ein Dokument oder Code oder ein Testplan für dieses Requirement entsteht wird dann eben ins entsprechende Kapitel des Textes dieser Key manuell eingefügt. Um sicherzustellen, dass kein Key vergessen wurde, gibt es Tools, die wiederum nichts anderes tun, als die entsprechenden Dokumente auf genau diese Keys hin zu durchsuchen. Wenn einer fehlt, meckern die Tools. Das hat in der Vergangenheit gut funktioniert, die gefürchteten Q-Audits, die über Leben und Tod eines Medizinprodukts am Markt entscheiden können erfolgreich absolviert werden. Aufwand für die Entwicklungsabteilung: Ja. Mehrwert? Kaum.

Der Ansatz in VS2010 und Team Foundation Server

Es muss aber doch auch anders gehen. Aufwand zu leisten, um eine Prüfung zu bestehen erinnert ein bisschen an die alten Schultage in denen man Texte auswendig gelernt hat, ohne den Inhalt zu verstehen – um gute Noten zu erhalten. Wenn ich heute Aufwand leiste, will ich nicht eine gute Note dafür – ich will einen echten Vorteil, einen Mehrwert. Bin ich mit der Meinung alleine? Hoffentlich nicht.

In Microsoft Visual Studio 2010 in Verbindung mit Team Foundation Server gibt es zur Verwaltung von beliebigen Arbeitspaketen  sogenannte “Work Items”, die auf die persönlichen Bedürfnisse anpassbar sind. Mit VS 2010 kann man diese bequem in Verbindung miteinander setzen. Wenn man einmalig Requirements und Testfälle sowie die zugehörigen Implementierungstasks verlinkt erhält man ein durchgängiges Requirement Tracing – for free. Es ist zu jedem Zeitpunkt möglich, sich von einer Anforderung zu den Testfällen und zurück zu hangeln. Moment – da war noch was mit dem Quellcode! Ahja – wenn ich meine Checkins auf TFS immer fleißig mit einem  Workitem assoziiere, bekomme ich eine durchgängige Tracability auch im Code – und zwar nicht pro File, Klasse oder Methode – sondern pro Zeile! Mehraufwand: Kaum!  Mehrwert: JA!

 

Der Mehrwert

Bei der Frage nach dem Mehrwert, unterscheidet sich die Tracability auf Basis von verlinkten, hierarchischen Workitems zum Arbeiten mit Keys wesentlich! Der “alte” Mechanismus auf Basis von Keys ist zwar ausreichend für eine erfolgreiche Zertifizierung, bietet aber darüberhinaus kaum praktischen Nutzen – im Gegenteil: Pflege und Suche nach Keys sind eher hinderlich.

Durch die auf Changesets verlinkten Workitems in VS2010 bekommt die Entwicklungsabteilung ein sehr mächtiges Werkzeug an die Hand. Wer kennt die Situation nicht, in der man wissen will, aus welchem Grund eine Zeile Code geschrieben wurde? Heute wird einmal auf “Annotate” geklickt und wir finden den Schuldigen. Mit VS2010 sogar unabhängig von Branch- und Merge-Vorgängen. Und heute muss man sich auch nicht mehr Gedanken darüber machen, was sich der “Schuldige” dabei gedacht hat, oder was er erreichen wollte – einfach mal schauen, welche Work Items mit dem Checkin vernüpft sind, schon finden wir den entsprechenden Kundenwunsch dahinter. Und wenn wir uns dann fragen, ob das jemals getestet wurde, hangeln wir uns eben ein bisschen weiter. Also nochmal für alle: Mehrwert? Riesig!

Na, wenn das die Prüfer von LGA, FDA und Konsorten mal nicht zufrieden stellt…

Default Foto Model

Man stelle sich vor: Jemand soll fotografiert werden, man hat aber nicht viel Zeit und will deshalb vorher noch schnell überprüfen, ob mit der Belichtung alles passt. Erschwerend kommt hinzu, dass der “jemand”, der fotografiert werden soll, man selbst ist.

Was tun? Meine Lösung: Ein Default Foto Model. Siehe Bild. Reicht allemal um Schatten im “Gesicht” zu erkennen. Mit Rändern unter den Augen und Nase wird es allerdings schwieriger.

Thinkpad: Trackpoint Scrolling

Diesen Blogeintrag schreibe ich aus zwei Gründen: Erstens, damit ich selbst weiß wo die enthaltene Information zu finden ist. Zweitens, damit alle, die vor dem gleichen Rätsel standen wie ich hier die Lösung erfahren.

Mein Problem:

Mein X200 Thinkpad hat einen kleinen Knubbel in der Tastatur. IBM/Lenovo nennt das einen “Trackpoint”. Wenn man diesen in eine Richtung drückt und gleichzeitig die middlere “Maustaste” auf dem Notebook, dann kann man damit nach oben und unten scrollen. Das funktioniert eigentlich sehr gut, allerdings hat es  in manchen Anwendungen nicht funktioniert – was tierisch nervt, wenn man sich erstmal dran gewöhnt hat.

Die Lösung  schaut folgendermaßen aus (Quelle):

Man muss manuell die tp4table.dat anpassen. Die liegt ungefähr in C:\Program Files\Lenovo\TrackPoint.

Auf diese Weise kann man dann z.b. Google Earth das Ein- und Auszoomen beibringen – einfach folgenden Schnipsel ins File schreiben:

; GoogleEarth
*,*,googleearth.exe,*,*,*,WheelStd,1,9

In Lightroom klappt’s noch nicht 100%, aber zumindest kann man durch die Bilder scrollen, wenn man folgendes eingibt:

; Lightroom
*,*,lightroom.exe,*,*,*,WheelVkey,0,9

Hoffe irgend jemandem wurde geholfen…

So geht das Ende.

Traurig, traurig. Die alten Potters haben ihre letzen Konzerte gespielt und verabschieden sich nun für immer von der Bild- und Tonfläche. Ich war ein paar mal Live dabei und auch auf diesem Blog finden sich hier und da und auch noch hier Bilder davon. Den versprochenen Teil 4 wirds wohl nie geben. Wer bis heute immer noch nicht begriffen hat, wie grandios diese Band war und wissen will, was er verpasst hat, kann sich heute nochmal selbst davon überzeugen lassen.

Gleichzeitig bin ich natürlich stolz wie Oskar, dass ich meine eigene Band unter diesen Umständen auf der Startseite der Potters wiederfinde. Wir waren auf der Bordsteinkanten-Tour eine der Support-Bands. Ich glaube, damals waren ungefähr 8 (!) zahlende Gäste anwesend. Eigentlich unvorstellbar, wenn man überlegt, dass neben den Potters auch noch The Robocop Kraus aufspielten…