DevTechBlog

Errinnerst du dich an das letzte Projekt, bei dem es keine Änderungswünsche und auch keine Abgabeänderung gab? Falls du das nicht kannst ist es auch nicht schlimm. Bei den Projekten bei denen ich beteiligt war, gab es vielleicht ein oder zwei die zum geplanten Termin auch abgeschlossen wurden.

In vielen Fällen tauchten bei fortschreitenden Status immer neue Wünsche auf, die im Vorfeld nicht bedacht werden konnten. Das ist im Grunde nichts schlimmes und kann auch meistens mit den Auftraggebern geklärt werden. Um diesen Umstand gerecht zu werden, haben sich auch Agile Entwicklungsmethoden durchgesetzt. Also ist zumindest für die Entwickler alles geklärt.

Wie passt aber diese Unsicherheit mit den Gegebenheiten im Verkauf und Erwartungen von Kunden zusammen.

Was ich unter Gegebenheiten im Verkauf verstehe

Als Kunde möchte ich zu einem von festgelegten Zeitpunkt ein “fertiges” Produkt erhalten. Als Verkäufer möchte ich dem Kunden zu diesem Zeitpunkt ein “fertiges” Produkt liefern. Diese Darstellung ist sehr vereinfacht aber sicher treffend.

Es muss deshalb auch vom Verkauf auf diese Unsicherheiten in der SW-Entwicklung hingewiesen werden und vom Kunden akzeptiert werden.

Das Hilfsmittel Ticketsystem und Milestones/Releases

Um möglichst schnell Rückmeldung und ein Produkt auszuliefern, haben sich Milestones bestens gewehrt. Dadurch hat der Kunde sehr schnell einen Einblick in den aktuellen Stand und kann auch auf Bereiche hinweisen die noch einer Bearbeitung bedürfen.

Ticketsystem kommt ins Spiel

Ab dem ersten Milestone entwickelt sich hier ein Ticketsystem als große Hilf.  Die Kunden können die Änderungswünsche, Ungereimtheiten und Rückmeldungen sofort erfassen und können sicher sein, dass ihre Rückmeldungen auch bearbeitet werden.

In Besprechungen können auch die zu bearbeitenden Tickets für neuen Milestones definiert werden.

Termine über größere Zeiträume

Über einen längeren Zeitraum können Termine selten eingehalten werden. Das liegt zum einen an der schlechten Planbarkeit von neuen Funktionen, als auch an der Wartung von bestehenden Projekten. Dieser Wartungsaufwand kann sehr schnell eintreten und mitunter auch einiges an Ressourcen binden.

Bei der Einführung von Trackingtools kommt es zwangsläufig zu Änderungen des bestehenden Arbeitsablauf und mit unter auch zu einigen Reibungen.

Vorweg nach ca. einem Monat arbeit mit MantisBT, ist es aus dem Arbeitsablau nicht mehr weg zu denken.

Aber zuerst zurück zum Start, da gab es gleich mehrere Punkte:

• in welcher Detailstufe und welchem Unfang ist Ticket ein Task oder ein Projekt
• darf man gleich Ticket an Bearbeiter zuweisen
• wer legt die Reihenfolge der Bearbeitung fest.

Zur Detailstufe

Es ist immer schwer zu beschreiben bis auf welche Teilbausteine eine Aufgabe zerlegt werden soll. Wir trafen die einfache Regel, dass jedes Ticket, das eine geschätzte Bearbeitungszeit von mehr als 16 Stunden hat, geprüft wird ob nicht mehrere Tickets daraus erstellt werden.

Für die andere Richtung haben wir eine Schwellzeit von 1 Stunde eingeführt, damit sich Anlage und Verwaltung für Ticket auch lohnt.

Zuweisung von Tickets

Ticketsysteme unterstützen natürlich auch die direkte Zuweisung zwischen den Mitarbeitern. Sinn kann es jedoch nur machen, wenn ein Projektleiter alle Tasks zugewiesen bekommt und dann die Verteilung übernimmt.

Dadurch hat der Projektleiter eine Übersicht und es besteht eine weitere Kontrolle, ob Aufgaben überhaupt in dieser Form sinnvoll sind.

Planung von Abarbeitung

Sind die Tickets einmal zugwiesen sieht es in Mantis mit der Planbarkeit relativ schlecht aus. Es gibt in diesem System keine Zeitplanung. Nur über Priorität kann eine Reihung festgelegt werden.

Als Krücke können regelmäßige Besprechungen helfen, in denen die zu bearbeitenden Tickets definiert werden.  Es hat sich auch als positiv herausgestellt die Auftraggeber bei diesen Besprechungen teilnehmen zu lassen.

Vorteile von Ticketsystem

Generell haben sich durch die Einführung hauptsächlich Vorteile ergeben.

• Es kann genau gesagt werden welche neuen Funktionen, Fehlerbehebungen in Zeitraum erledigt wurden.
• Die Kunden sind zufriedener, da sie die Aufgaben mitbestimmen.
• Die von einzelnen Mitarbeitern zu erledigenden Arbeitsmengen sind besser abgeschätzbar und Engpässe leichter zu finden.
• Durch Anzahl der erledigten Tasks und Zeitraum ergibt sich ein guter Bearbeitungsdurchschnitt , der Schätzung von offenen Arbeitsleistungen erleichtert.
• Auch die erbrachten Leistungen sind besser in Fehlerbehebung und neue Funktionen gegliedert.

Persöhnlich bin ich mehr als froh, dass wir endlich ein derartiges System eingeführt haben. Es hat sich dadurch bereits wesentlich die Arbeitsleistung und auch die Zufriedenheit unserer Kunden verbessert.

Jedem Software Entwickler sind sicher mehrere Tools zum Verwalten von Anfragen und Fehlern bekannt. Sollte dem nicht so sein, solltes du das schleunigst nachholen!

Geht es aber darum ob auch in Firma oder Gruppe ein Tool verwendet wird,um Aufgaben geordnet zu erfassen, sieht die Sache plötzlich ganz anders aus.

Da gibt es derartig viele Ansichten was ein Tool alles können sollte, um auch für alle Möglichkeiten nutzbar zu sein, dass Zweifel aufkommen ob überhaupt jemand ein derartiges Tool verwendet. In unserem Fall reichten die Meinungen von minimaler Ticketerfassung bis zur Überlösung von Zeiterfassung automatisch über Ticketerledigung und Verknüpfung von Loginzeiten.

Es sei für jeden dahingestellt ob eine Überlösung realistisch ist oder doch eher am Ziel Aufgaben und Fehler zu Verwalten vorbei geht.

Um all jenen die noch vor der Wahl stehen, etwas Hilfe zu bieten beschreibe ich den Werdegang unserer Entscheidungshilfe.

Am Start standen folgende Tools zur Auswahl:

• MS SharePoint mit Erweiterung für Aufgabenliste
• FogBugz als Installation
• MantisBT

Nur das letztere davon ist ein OpenSource Projekt, die anderen sind von kommerziellen Anbietern.

Ausscheidungsgründe für MS SharePoint war für uns Problematik von Rechten. In SharePoint konnten die Rechte, wer Ticket bearbeiten kann, nicht fein genug gesteuert werden. Dieses Produkt ist eine Verteilungsplattform und nicht auf unterschiedliche Rechte in Seite zugeschnitten.

FogBugz bekam von uns die besten Bewertungen. Sollte jedoch, wegen Wunsch auf Unterstützung durch lokalen Partner bei Einführung, doch nicht das Rennen machen.

Mantis war auf den ersten Blick nicht das Tool unserer Wahl. Es sieht von Aufmachung nicht nach viel aus, kommt in Übersicht mit fünf Bereichen daher, die einen das Gefühl der Unübersichtlichkeit geben und hat in Standardeinstellung mitunter eigenwillige Farbkombinationen.

Bei genauerem Hinsehen bietet es jedoch wesentlich mehr als man vermuten würde.

Besondere Features:

• Einrichtung von beliebig vielen Projekt Ebenen
• Leichte Erstellung von zusätzlichen Feldern
• Filtermöglichkeiten auf alle Standardfelder
• speichern von Filtern
• Permalink auf Ansicht mit Filter
• Sehr feine Einstellbarkeit von Rechten
• Mehrsprachigkeit (auch Deutsch)
• Personalisierbarkeit bei Login, Logo,…

Für das Tool sprach auch die schnelle Einrichtbarkeit und die Möglichkeit von lokaler Unterstützung durch lokalen Partner. Schließlich kann man immer noch ein anderes Tool erwerben, falls uns einige Funktionen besonders abgehen.

Mich würde natürlich Interessieren welche Tools bei euch zur Auswahl stehen oder bereits im Einsatz sind.

In einem InfoPath-Formular auf den aktuellen Benutzer zugreifen zu können scheint gar nicht so einfach zu sein, wie man glauben möchte.

Als weitere Schwierigkeit kam in meinem Fall dazu, auch noch die Destination Rule in K2-Aktivity richtig damit zu verbinden.

Grund dafür war, Formular geht an Gruppe und wird dann von einem Anwender bearbeitet, der den weiteren Workflow zugewiesen bekommt.

Funktioniert hat das mit folgender Hilfestellung:

1. Beschreibung von Abfrage auf WebService aus Regel

2. Hinweis in k2underground

Das Feld welches ich ausgelesen habe war “AccountName” enthielt domain\username und konnte direkt als Destinationuser verwendet werden.

Meine ersten kleinen Formulare konnte ich schon erstellen. Wie in jeder unbekannten Anwendung bin ich gleich auf kleine Hindernisse gestoßen.

Haupthindernis war, aus einer “Wiederholenden Tabelle” in der die Start- und Endzeiten von Bearbeitungsschritten eingetragen werden, die Arbeitsdauer in Stunden zu berechnen.

Für alle die ebenfalls Berechnungen in InfoPath-Formularen durchführen wollen eine kleine Beschreibung.

Regel anlegen

Bei gewünschtem Feld welches Berechnung anstößt Eigenschaften öffnen.

Dann über “Regeln…”->”Hinzufügen”

Regel Aktion “Aktion hinzufügen”:

Aktion “Den Wert eines Felds setzen” und Feld wählen.

Über Formelbutton Dialog für Formeln öffnen und Formel eingeben. In diesem Fall wird Zeit im Format 00:00:00 aufgeschlüsselt und mit eigenem Feld gegen gerechnet.

(((number(substring(../my:Ende, 1, 2)) * 3600) + (number(substring(../my:Ende, 4, 2)) * 60)) – ((number(substring(., 1, 2)) * 3600) + (number(substring(., 4, 2)) * 60))) div 3600

Man sollte das Kennzeichen “XPath bearbeiten” verwenden, um die Felder besser angeben zu können. Das Zeichen “.” steht für aktuelles Feld.

Bedingungen

Damit keine Fehler wegen leerer Werte auftreten sollte über “Bedingung festlegen..” folgende Regeln definiert werden:

• aktuelles Feld   -> ist nicht leer
• zweites Feld      -> ist nicht leer
• Überprüfung auf Muster aktuelles Feld -> entspricht dem Muster -> Benutzerdefiniertes Muster (\d{2}:\d{2}:\d{2}) \d steht für beliebige Zahl
• Als Abschluss kann noch geprüft werden ob Ergebnis größer 0 ist, damit keine minus Zeiten entstehen. Dazu den gleichen Ausdruck wie zur Berechnung nehmen und Abfrage >= 0 anfügen.

Gesamte Ansicht des Ausdruckes:

(number(substring(../my:Ende, 1, 2)) * 3600 + number(substring(../my:Ende, 4, 2)) * 60 – (number(substring(., 1, 2)) * 3600 + number(substring(., 4, 2)) * 60)) div 3600 >= 0

Wenn vom Feld “Ende” aus ebenfalls die Berechnung angestoßen werden soll kann müssen dort die gleichen Schritte ausgeführt werden.

Ändern muss sich dann nur der Wert von ../my:Ende auf ../my:Start.

Es scheint als würde es wirklich wahr und wir richten einen SharePoint-Server ein.

Bei den ersten Tests kam es zu einer kleinen Fehlermeldung beim aktivieren von Websitefeatures:

Office SharePoint Server Veröffentlichungsinfrastruktur meldete bei Aktivierung “Zugriff verweigert”

Dazu fand ich folgenden Befehlt zur Korrektur:

stsadm -o activatefeature -name PublishingResources -url <yourwebsiteUrl>

Zu finden war die Datei im Verzeichnis:

\Programme\Gemeinsame Dateien\Microsoft Shared\web server extension\12\BIN\

Danach konnte das Feature manuell gestartet werden.

Eigentlich auch so eine Aufgabe die einfach ist, wenn man sich nur daran erinnern kann wie man es beim letzten mal gemacht hat.

Die meisten MySQL-Clients zeigen in ihrer Resultliste die Werte nicht als UTF-8 an, sondern eher als Windows-1252.

Auch bei Exportfunktionen auf angezeigt Daten wird mitunter nicht mehr original Zeichensatz verwendet.

Durch einen direkten Export kann das jedoch umgangen werden.

select bezeichnung
from artikel
Into OUTFILE ‘/outdir/artikel.txt’

File wurde durch diesen Befehl richtig als UTF-8 gespeichert und alle Zeichen sollten richtig angezeigt werden. Ein großer Nachteil, sollte man nicht die Möglichkeit haben auf Filesystem am Server zugreifen zu können, funktioniert diese Lösung nicht. Das File wird direkt am Server im angegebenen Verzeichnis abgelegt.

Es gibt dazu sicher mehrere Möglichkeiten aber diese reicht für mich aus. Falls jemanden noch andere Möglichkeiten bekannt sind, einfach als Kommentar festhalten.

Im EDV-Bereich gibt es Aufgaben die man nur sehr selten auszuführen hat und bei denen man sich mit Sicherheit nicht mehr daran erinnern kann wie es funktioniert hat.

So war es heute wieder so weit, ich durfte alle Zertifikate für unsere internen Webseiten austauschen. Leider ist der Mitarbeiter der das vor ein paar Jahren das letzte mal gemacht hat nicht mehr in der Firma und ich habe die Aufgabe erben dürfen.

Downloaden und Build von OpenSSL erstellen

Der erste Schritt war openssl zu besorgen und mittels Cygwin zu kompilieren. Dieser Arbeitsgang war erstaunlich einfach und auch Paketinstallation in Cygwin durch erneutes ausführen des Setupfiles war nicht schwierig. Benötigte Pakete waren “make” und zur Sicherheit alle möglichen “gcc”-Varianten und gcc-migWN.

Von Cygwin aus Source-Verzeichnis von openSSL wählen und folgende Befehle in cygwin ausführen:

$ ./Configure mingw
[...]
$ make
[...]
$ make test
$ make install

Erstellen von signiertem File

In meinem Fall ein selbst signiertes.

openssl genrsa -des3 -out pass.key 1024
openssl rsa -in pass.key -out server.key
openssl req -new -key server.key -x509 -out server.crt -days 999

Das ganze sind nur Beispielwerte die unbedingt auf eigene Bedürfnisse zugeschnitten sein sollten.

Beim Anlegen ist zu beachten, dass “Common Name (eg, YOUR name)” für Domainnamen steht.

Am Apache Server

Wird im Apache nur eine URL bzw. nur ein Zertifikat benötigt kann ein normales Zertifikat mit CN “www.mydomain.com” erstellt werden. Da aber schon mydomain.com als unterschiedliche URL gewertet wird kommt das fast nicht vor.

Leider unterstützt die Apache SSL-Config nur IP-VirtualHosts. Falls man diese Möglichkeit nicht hat, kann zumindestens für Subdomains bei CN Wildcard “*.mydomain.com” hinterlegt werden. Dadurch bekommen alle Subdomains das gleiche Zertifikat und erkennen die Zusammengehörigkeit durch die Domain.

Die Apache config sieht in etwas so aus:

<VirtualHost _default_:443>
DocumentRoot “/Apache2/htdocs”
ServerName www.mydomain.com:443
ServerAdmin support@mydomain.com
ErrorLog logs/error.log
TransferLog logs/access.log

SSLEngine on
SSLCertificateFile conf/ssl/server.crt
SSLCertificateKeyFile conf/ssl/server.key

</VirtualHost>

So hoffentlich vergesse ich das bis zum nächsten Mal nicht.

Zum ausprobieren, wie sich Release bedienen läßt, wo die Unterschiede und mögliche Vorteile zu MonoRails liegen, bin ich noch nicht gekommen.

Nachdem was ich bei Haacked gelesen habe, wird erstellen von Patches nicht möglich sein. Dadurch besteht fast Notwendigkeit ein unofficial Projekt-Portal zu starten, in dem Patches für die jeweilige Version eingepflegt werden können.

Bin gespannt ob sich dazu Community findet, falls nicht werden einige Vorteil von open Source Projekten für Microsoft MVC ungenutzt bleiben.
Auf jeden Fall werde ich ein Auge offen halten und darüber berichten, sollte es zu einem derartigen Projekt kommen.

Es war wieder einmal so weit, mein Wissen reicht laut Vorgesetzten bei Punkt SharePoint nicht aus. Wir haben zwar noch keinen SP-Server im Einsatz, aber anscheinend ist das in Planung.

Als Draufgabe gab es auch gleich K2 Blackpoint Workshop um das Paket abzuschließen.

Zu K2 Blackpoint gebe ich hier jetzt (geschult) meine Meinung zum Besten. Das Ziel von K2 Blackpoint ist es die Worfklows für SP leichter konfigurierbar zu machen und dazu die Übersichtlichkeit zu verbessern. Laut Werbung sind diese Workfolws so einfach zu gestalten, dass sogar eine Person ohne IT-Hintergrund sie erstellen kann.

In der von mir in den letzten Tagen gelebten Realität sah das jedoch anders aus. Zwar ist es richtig, es wird kein Code benötigt um Workflow erstellen zu können. Jedoch ist auch die Gegenrichtung ist zutreffend, auch kein eigener Code, bis auf Einbindung von WebServices, ist erlaubt. Das jedoch Personen ohne IT-Hintergrund das Einrichten eines Workflows mit K2 schaffen glaube ich nicht.

Meine Gründe für die Annahme:

• InfoPath Formulare und Zuordnung von Datenquellen auf Dropdown-Felder geht über SmartObjects und Befüllung wird über ‘Rules’ gesteuert. Selbst für die, die Unterstützung durch Vortragenden hatten, bedurfte es einiger Versuche bis Felder befüllt und auch Abhängigkeiten zwischen den Dropdown realisiert waren.
• SmartObjects, dahinter versteckt sich ein Kernstück von K2. Mit Hilfe dieser SmartObjects kann auf Listen oder Bibliotheken in SharePoint zugegriffen werden. Um diese jedoch auch bis ins Formular zu bringen braucht man K2Studio. Hier können die verfügbaren Methoden und Parameter für Aufruf gewählt werden . Danach öffnet man das InfoPath-Formular und hängt das ganze an ein Control. Wird das ganze auch noch in mehreren Activities benötigt kann dieser Schritt gleich mehrfach gemacht werden.
• Fehlende Übersicht über Events. Es werden zwar alle Activity-Punkte angezeigt und auch alle Events zu den Actvities.
  Was aber fehlt ist Übersicht über Events und Prüfung ob auch alle gleich aktualisiert wurden.
  Bsp.: Wird bei jeder Activity ein Dokument-Speichern-Event benötigt, kann bei ändern des Speichervorgangs Aktualisierung in jedem Speicherevent notwendig sein.

Schon alleine aus der Länge der einzelnen Beschreibungen pro Punkten, ist für mich ersichtlich das da noch einiges Verbesserungswürdig ist.

Zum Glück sind wir erst bei Version 1 und der Release ist noch mehr als neu. Dadurch habe ich Hoffnung, dass sich noch einiges verbessern wird.

Sollte das Produkt bei uns wirklich in Verwendung kommen, gibt es hier sicher noch einige Posts zu dem Thema, vielleicht sind die Anforderungen im Produktivsystem dann auch nicht so aufwändig, wie Übungsbeispielen die auf alle Optionen eingehen wollen.