Zur Zeit wird gefiltert nach: Mind Map
Filter zurücksetzen

06.03.2012
23:26

Mein Einstieg in Kanban

Zukünftig will ich verstärkt mit der Unterstützung von Kanban arbeiten. Primär erhoffe ich mir Vorteile im Bereich der ständigen Verbesserung, Entwicklungseffizienz und der Lokalisierung von Zeitfressern, sowie ein nützliches Hilfsmittel für "Continuous Delivery".

Seit knapp 3 Wochen visualisiere ich so meine Arbeit und versuche anhand des Value Stream Mapping die Effizienz zu ermitteln. Innerhalb der nächsten Wochen werde ich wohl ein paar tiefere Einblicke haben. Ein grober Überblick befindet sich in folgendem Mind Map.

Sharepoint 2010 - Business Prozesse mit Workflows

In meinen ersten Beitrag habe ich ja schon über die interessanten Nebeneffekte von Sharepoint berichtet. Auch diese Woche hatte ich wieder Nebeneffekte, die schon arg Grenzwertig waren. Eine Technolgie, die sich als Zeitfresser entpuppte war Linq to Sharepoint.

Meine Best Practice - Empfehlung: Nicht einsetzen für Business-Anwendungen, die ihren Namen gerecht werden wollen und auch einiges an Daten zu verwalten haben.

Details und Workaround-Frickelein werden folgen.

Zurzeit bin ich immer noch in der dritten Phase und ich glaube, dass es nach dieser Phase drei mögliche Wege gibt, die von Entwicklern eingeschlagen werden. Aktuell gehe ich tiefer in die Materie zu Workflows ein. Seit der PDC 2008 habe ich mich dazu entschieden, Microsoft-Technologien nur noch systematisch anzugehen, da der pragmatische Weg in meinen Augen unkontrollierbar geworden ist. Linq to Sharepoint hat mich zusätzlich darin bestärkt, hier habe ich zu sehr auf die Aussagen von Sharepoint MVP´s vertraut. Kommt nicht wieder vor.

Im Bereich der Workflows habe ich die möglichen Ansetze und Varianten im nachfolgenden Mind Map festgehalten. Hier muss ich zugeben, dass mich dieser Bereich von Sharepoint sehr interessiert.  

Metaprogramming in .NET

Es gibt viele Ansätze, um mehr Flexibilität in den Entwicklungsprozess zu bekommen, einer davon ist Metaprogrammierung. Dabei handelt es sich meist um ein zusätzliches Level in Softwaresystemen, das zu mehr Flexibilität beitragen soll. In .NET gibt es dafür mehrere Ansätze. Aus diesem Grund habe ich damit angefangen, ein Mindmap zu erstellen, da mich das Thema schon seit längeren interessiert und in diversen Projekten auf die eine oder andere Weise begleitet hat.

Neben T4 wird aus meiner Sicht auch das Rosyln-Projekt ein interessanter Kandidat werden, weil es die typischen Anforderungen wie lesender, schreibender Zugriff ermöglicht und durch die Kombination mit statischem Code die Änderung der Semantik zulassen soll. Bin gespannt.

Leider wird die CTP erst Mitte Oktober bereitgestellt, werde auf jeden Fall damit spielen. ;-) Aktuell gibt es einen kleinen Ausblick im 3. Teil der Build-Präsentation Future directions for C# and Viusal Basic  von Anders Hejlsberg (ab der 40. Minute). 

Cloud Security aus der Marketingperspektive

Ich habe mir die 3 teilige Webcastserie zu Sicherheitsgedanken in der Cloud angesehen und daraus ein grobes Mindmap erstellt. Eins vorweg, diese Serie reicht nicht aus, um sich mit der Cloud-Sicherheit auseinanderzusetzen. Ich werde mich jetzt auf die Suche nach Literatur von Gray-Hats machen, um einen objektiveren Überblick zu erhalten. ;-) Gut ich gebe es zu, die habe ich schon längst, aber noch nicht vollständig gelesen.

Gut an der Serie ist, dass sie die 3 Bereiche Kunde, Applikation und Cloud im Bezug auf die Sicherheit betrachtet. Weniger gelungen finde ich allerdings die Sicherheitsaspekte des Cloud Providers, da wird im Bezug auf Azure mit Fachchinesisch um sich geworfen, damit lässt sich das Management nur schwer überzeugen.

Der eigentliche Schwerpunkt liegt dann auch auf der Anwendungssicherheit und diese vermittelt einen soliden Eindruck. Nur sollten diese Punkte bei der Entwicklung von Webanwendungen jeden Entwickler bekannt sein, leider ist dies nicht so. In der Folge kann hier die Gefahr eines Ping Pong's zwischen Applikations- und Cloud-Provider bestehen.

In dieser Hinsicht freue ich mich auf den Tag, an dem bei Gesprächen unter Entwicklern Begriffe wie SDL, CIA, AAA usw. zum Grundwortschatz gehören und nicht mit einem "Hää" beantwortet werden. Bei SOLID funktioniert es ja auch.

04.04.2011
21:51

Review Theorie und Praxis und warum es trotzdem schief geht.

Ich habe mal wieder meine alten Aufzeichnungen überfolgen und dabei folgendes Mindmap im Bereich der Prüf-/Testarten gesichtet. ;-) Dieses hat jetzt schon mind. 5 Jahre auf den Buckel.

Interessant an dem Thema ist der Unterschied von Theorie und Praxis. Im Bereich der statischen Prüfverfahren konnte ich so wieder einiges lernen. ;-)

Im letzten Randprojekt lief es folgendermassen ab:

Der Review wurde an eine Firma im Auftrag gegeben, die faktisch von Schulung, Training, Eigene Projekte, Unterstützung von Firmen alles macht. Sollte ich nochmal so eine Situation erleben, werde ich mich vorher genauer erkundigen, ob die Methoden religiös praktiziert werden.

Bleiben wir mal bei der Theorie. Die Herausforderung, das "Team" war interdisziplinär. Laut Lehrbuch würde man das Team aufbauen. Der Teambildungsprozess mit den typischen Phasen Forming, Storming, Norming und Performing wurde schon mal nicht durchlaufen. Zugegeben, man kann nicht immer nach Lehrbuch arbeiten, da häufig auch zu viel Ideologie im Spiel ist, aber die Grundprinzipien sollten in einem Projekt erkennbar sein.

Die Folgen davon:

  • Es gab keine intensiven Beziehungen zwischen den Projektbeteiligten. Versuche wurden mit der Begründung Single Point of Contact an den wichtigen Schnittstellen abgewürgt.
  • Ein Gemeinschaftsgeist für das Projekt bestand auch nicht. Die Folge hiervon, es kam weder ein Team noch eine Arbeitsgruppe zustande, eher ein Gegeneinander.

Dieser Punkt liegt eigentlich in der Verantwortung der Projektleitung und zeigt das Theorie und Praxis zwei Welten darstellen können.

Wie sah nun die Theorie beim Review aus:

TheoriePraxis
Hauptziel eines Reviews ist die frühzeitige Erkennung von Fehlern.Der Review wurde in der letzten Hermes-Phase angeordnet und die Anforderungsspezifikation diente nicht als primäre Grundlage.
Die Prüfung soll den Autor des Quellcodes unterstützen.Die "Wir können alles Firma" stellte eine Liste mit Kritikpunkten bereit, die Anfangs mehrdeutige Aussagen und zum Ende keine Aussagen zur Verbesserung für den Autor bereitstellte. Lediglich 2 Hinweise waren wirklich brauchbar, da diese auf der Integrationsumgebung messbar waren.
Ergebnis ist eine Mängelliste mit dem entsprechenden Status.Von 4 möglichen Vorgehensmodellen und Methoden, nutzte die "Wir können alles Firma" die Gelegenheit ihr Vorgehensmodell als den Quasi-Standard zu erklären und Werbung für ihre Methode zu machen. Natürlich wurde die Gelegenheit nicht ausgelassen, ein Grüppchen für sich zu gewinnen. Bei diesem Projekt war das auch nicht schwierig. Das eigentliche Ziel wird dabei ersichtlich und muss von mir nicht ausgeschrieben werden.

Abschliessend kann man sagen, das in jeden Witz auch ein wenig Wahrheit liegt:

Theorie ist, wenn man alles weiss und nichts klappt. Praxis ist, wenn alles funktioniert und keiner weiss warum. In diesem Projekt waren Theorie und Praxis vereint, nichts funktionierte und keiner wusste warum. ;-)

Das Projekt hat aber auch ein Vorteil: Nachdem ich dieses "Chaos" erlebte, schätze ich die langjährigen Geschäftspartner noch mehr. ;-)

Translate this page

Kategorien