Mal eines kaufen. Die ersten zwölf Seiten kann man sich auf der Buch-Website online schon mal anschauen.

Benutzer Feedback
Um Details bei den Mockups, wie auch bei dem ersten finalen Design, einzuholen hat die Design Agentur ZURB ein perfekter kleiner Webservice eingerichtet. Der Service nennt sich Verify.  Verifiy kann Klicktest und Memorytest durchführen. Bei diesen Tests werden Design oder Mockups gezeigt und abgefragt an was der Tester sich erinnern kann. Insgesamt sind acht verschieden Testtypen verfügbar. Für 8 US$ kann man sich ein Konto für einen Monat einrichten und Kunden oder andere Testpersonen einladen. Einen Beispiel Verify-Klicktest kann man sich hier einmal anschauen.

Minimal Master Pages
Es ist wohl unbestritten, dass es einfacher ist mit einer leeren Masterpage zu beginnen statt die v4.master von SharePoint Server zu beginnen. Eine solche Master Page zu erstellen haben  verschiedene Leute in Angriff genommen. Randy Drisgill hat seine gut kommentierte Arbeit auf Codeplex gestellt. Kyle Schaeffer hat eine Version geschaffen die nur das absolute Minimum beinhaltet das es braucht um eine SharePoint Master Page zu rendern.

Design Ideen, Prinzipien  und How To E-Books
Das Web ist voll mit How Tos aller Art. So auch im Design Bereich. Hier ein drei E-Books die mir aufgefallen sind:

Stephan Hay – The Design Funnel. A Manifesto for Meaningfuel Design
Stephan Hay stellt eine Methode vor wie man von der often wagen und unklaren Vorstellungen des Kunden zu einem klaren und soliden Design kommt.

Jacob Cass – Type Classification Handbook
Für alle die den Unterschied zwischen Arial und Calibri nicht kennen. Diese E-Book lernt einem die zehn Grundtypen der Schriftklassifikation. In ein paar Seiten hat man alles was man über Typografie wissen muss.

Peter Pixel - Introduction to Good Usability
Dieses E-Book ist vor allem für Leute die noch nicht viel im Bereich Webdesign gemacht habe. Es gibt einige Ideen über Interface Elemente und deren gebrauch, sowie die häufigsten Fehler in deren Anwendung

Anderes was ich immer wieder brauche
Blindtext Generator
Lorem Ipsum in allen Sprachen mit diversen Optionen um das richtige „Look and Feel“ zu bekommen.

Pattern Tap
Diverse Design-Sammlungen in Themen gestaffelt. Brauche man eine Idee für eine 404-Error Seite, kann man schnell entsprechend Pattern Tap Collection durchstöbern.

Icon Finder
Icons sind nicht einfach zu finden. Noch schwieriger ist die richtige Lizenzierung der Icons zu finden. Icon Finder kombiniert (wo möglich) diese Informationen.

Design Drifter
Ein reiner SharePoint Designer der sich nur um Themen rund um SharePoint Server Design beschäftig.

Color Scheme Designer
Wer vom Kunden ein paar CI-Farben bekommt rätsel immer wieder, mit welchen Farben nun Links, Markierungen und Auszeichnungen am besten wirken. Color Sheme Designer hilft hier die passenden Farben gemäss der Farbenlehre zu finden.

Das anspruchsvolle Credo der Konferenz “Collaboration Days” ist ‘creating hands-on value’. Der Anspruch besteht darin, direkt verwendbares Wissen zu vermitteln, sowohl durch die Vorträge als auch via Austausch mit Kollegen und “Gleichgesinnten”. Dass dies gelingen wird, sieht man an der breiten Palette von Themen wie auch an den Sprechern die sich für diese Konferenz zur Verfügung gestellt haben.

Apropos Sprecher. Auch ich werde eine Session, rund um Informationsarchitektur und SharePoint Server 2010,  halten. In diesem Sinne hoffe ich, dass ich viele bekannte Gesichter sehen werde.

Wer sich noch nicht angemeldet hat, sollte das schleunigst tun. Habe gehört, dass es nicht mehr viele Plätze hat.
In diesem Sinne danke an die SharePoint Community Schweiz und bis bald in Luzern

Nina Wilhelm hat sich dazu Gedanken gemacht und uns die Vorschläge präsentiert. Um es kurz zu machen, wir sind begeistert. Trotzdem möchten wir von Euch auch ein paar Feedbacks haben. Also los, sagt uns ob Nina mit diesen Vorschlägen auch Euern Geschmack trifft und was wir sonst noch an der Seite verbessern könnten!

Home

Beitrag

Suche

Wer also wissen will wie das Buch entstanden ist, was darin enthalten ist und warum man es zwingend kaufen muss, sollte sich den Podcast 126 von Michael Greth zu Gemüte führen.

Genau da setzt das Seminar an. Es richtet sich an Entscheidungsträger, die den Nutzen von Enterprise 2.0-Konzepten für ihr Unternehmen/Team einschätzen sowie die wichtigsten Aufgaben bei der Einführung eines „Collaboration Workplaces“ kennen lernen wollen.

Die Inhalte des Seminars basieren auf den Ergebnissen des Forschungsprojektes IMPACT, das in Kooperation von Microsoft Deutschland, OSN und des Business 2.0 – Center for Innovations in Business Processes an der Universität St. Gallen durchgeführt wurde.

Alle Informationen zum Seminar finden Sie hier zum Durchklicken und zum Download.

Nach fast einem Jahr Arbeit ist es nun endlich soweit. Das Buch, das Reiner Ganser und ich geschrieben haben, ist im Handel verfügbar. Der Titel „Erfolgreiche Portalprojekte mit Microsoft SharePoint, Praxishandbuch für die erfolgreiche Steuerung von SharePoint-Projekten“ beschreibt sehr genau, was der Inhalt des Buches ist.

Das Ziel des Buches ist, unsere Erfahrung in den Bereichen

• Chancen und Herausforderungen erkennen und Projekte erfolgreich steuern
• Intranetportal- und Zusammenarbeitstechnologien für Projektmanager

herauszuarbeiten und mit Tipps und Erfahrungen zu versehen. Die Nutzung der Microsoft Office SharePoint-Technologien bietet neue Möglichkeiten für die Zusammenarbeit in Organisationen. Diese Tools wirken sich aber auch rückkoppelnd auf die Organisationsform und die Zusammenarbeit der Mitarbeiter aus. Dieses Buch soll die Eckpunkte und Chancen, aber auch die Gefahren zeigen, die ein SharePoint-Projekt mit sich bringt. Als Ziele einer SharePoint-Einführung werden meist auch Stichworte wie Zusammenarbeit, Kommunikation, Communitys, Knowledge Management, Wiki, Blog und weitere Web 2.0-Begriffe genannt. So verändern diese Projekte die Art der Zusammenarbeit nachhaltig und machen Platz für tiefgreifende Veränderungen im Unternehmen. Dies betrifft die Art, wie Menschen Informationen austauschen, mit Prozessen und Informationen umgehen und letztendlich, wie sie mit sich und anderen umgehen werden. Diese Punkte sind für den Erfolg von Portalprojekten von SharePoint von zentraler Bedeutung.

Das Buch ist bei MS Press erschienen. Es kann direkt dort oder bei Amazon erstanden werden.

Im Grunde genommen ist das Agile-Software Development Framework nichts anders als eine schlaue Art, Teams, Personen und deren Aufgaben zu organisieren. Es beinhaltet Elemente aus dem Projektmanagement, Team-Führung, Aufgabenmanagement und Psychologie. Agile verbindet diese Elemente zu einem Paket, welches die Ausführung und die Übersicht von komplexen Aufgaben stark vereinfacht.

Agile development process

Eines der grossen Vorteile von Agile ist, dass man dieses Framework völlig auf die eigenen Arbeitsgewohnheiten anpassen kann. Es ist unmöglich, Agile falsch anzuwenden. Man entscheidet wohl eher, wie oft und wie intensiv man die Agile Methodik anwenden will.
Es gibt vielleicht Methoden in Agile, die nicht auf Ihre Unternehmensphilosophie oder Arbeitsweise passen. So what? Man lässt sie einfach weg oder passt die Methoden an. Ein Beispiel: es gibt eine Methode um die Komplexität von Aufgaben zu bestimmen, die sich “Estimation poker” (Engl. Schätzungs-Poker) nennt. Estimation Poker ist eine spielerische Art, ein mehr oder weniger langweiliger Prozess interessant und spannend zu machen. Wie Estimation Poker funktioniert, werde ich unten noch erklären. Estimation Poker mag vielleicht nicht allen passen. Dann macht man die Schätzungen der Aufgaben einfach anders.

Elemente des Agile Framework

Epic: Epics sind längere, komplexe Aufgaben. Epics können kleine Projekte, Subprojekte oder Aufgaben sein, die mehrere Wochen benötigen um fertig gestellt zu werden. Zum Beispiel die Erstellung einer komplexen MOSS 2007 Farm-Architektur könnte man in die Kategorie Epic werfen.

User Stories: Innerhalb von Epics werden User Stories definiert. Diese User Stories sind gruppierte Aufgaben, die im Bezug zueinander stehen. In der Regel wird die Komplexität von User Stories bewertet. Man einigt sich auf eine Skala von Werten (meistens die Fibonacci Zahlenreihe) um der Komplexität einer Story eine Gewichtung zu geben. Die Komplexität (Story points) aller Userstories innerhalb eines Epics werden summiert und somit wird die Gesamtkomplexität des Epics ausgerechnet.
Die Evaluation einer neuen SSO Technologie kann man als User Story bezeichnen.

Tasks: User Stories werden in einzelne genau definierte Tasks (Aufgaben) unterteilt. Jede Aufgabe muss so klar definiert sein, dass einzelne Aufgaben innerhalb des Teams weitergegeben werden können. Für jede Aufgabe wird der Aufwand in Stunden geschätzt. Die Summe der Stunden aller Tasks ergeben die Anzahl Stunden für die User Story. Die Summe der Stunden aller User Stories ergibt die Anzahl Stunden eines Epics. Beispiel für einen Task: Die Dokumentation einer Applikation oder Teile der Applikation.

Scrum:  Scrumming ist wohl die Essenz des Agile-Frameworks. In den Scrums (deutsch: Gedränge) treffen sich Teammitglieder, Teams oder sogar das ganze Unternehmen für Planung, Kommunikation, Retrospectives (deutsch: Rückblicke), Zeitrapportierung, usw. Der Hauptunterschied zwischen Scrums und konventionellen Meetings besteht darin, dass der Informationsfluss viel strukturierter abläuft als in „normalen“ Meetings. Bei jeder Art von Scrum ist genau definiert, was der Informations-Input ist und was dabei heraus schauen soll. Im Scrum dreht sich grundsätzlich alles um den „Sprint“. In einem Daily Scrum werden täglich Informationen zum laufenden Sprint ausgetauscht. Man kann sogar so weit gehen, dass man stündlich Micro-Scrums abhält um hochkomplexe Aufgaben im Team zu bewältigen.

Sprint: Das Agile Gegenstück zum Scrum ist der Sprint. In einem Sprint geschieht die eigentliche Magie . Sprints sind zeitlich begrenzte Arbeitsphasen. In Sprints werden die geplanten Aufgaben erledigt. Teammittglieder suchen sich eine passende User Story für den Sprint aus und arbeiten die dazu gehörigen Aufgaben ab. Daily Scrums sind dazu da, den Fortschritt der Arbeit an den User Stories zu rapportieren oder an andere Teammitglieder weiterzugeben.

Burndown chart: Für jede Aufgabe wird der Aufwand in Anzahl Stunden geschätzt. Während des Sprints rapportiert die Person die verbrauchten Stunden für den Task. In einem Burndown Chart werden die geschätzten und effektiv verbrauchten Stunden für eine Aufgabe gegenüber gestellt. Anhand des Burndown-Charts kann man die Aufgabenerledigungs-Geschwindigkeit (Velocity) des ganzen Teams ablesen.

Sample burndown chart

Retrospective: Ist ein Sprint zu Ende, wird ein Retrospective-Meeting einberufen. In diesem Meeting hat man die Möglichkeit, Positives oder Negatives über den vergangenen Sprint auf den Tisch zu bringen und zu gewichten. Normalerweise laufen Retrospectives so ab: Jedes Teammitglied überlegt sich für „Stop doing“, „Keep on doing“ und „Start doing“ Items aus. Diese Items werden gesammelt und dann gewichtet. Normalerweise bekommt man pro Kategorie drei Stimmen. Für jene „Stop doing“ Items, welche nur eine Stimme kriegen werden Verbesserungs-Massnahmen diskutiert. Ergebnisse von Retrospectives werden immer an das Mittlere oder sogar höhere Kader kommuniziert.

Backlog: Eine Liste von User Stories sortiert nach Priorität und kategorisiert nach Projekt oder Projekt-Team. Im Backlog werden alle anfallenden Arbeiten für das Aktuelle Projekt (oder was auch immer) gesammelt und verwaltet. Jedes Entwickler Team, jede Abteilung und sogar das ganze Unternehmen hat seinen eigenen Backlog.

Estimation poker: Dies ist eine tolle Methode, eine trockene und eher mühselige Aufgabe in eine spannende und produktive Sitzung zu verwandeln. Es geht darum, im Team die Komplexität von User Stories zu bestimmen. Man nimmt eine User Story vom Backlog und diskutiert die Story im Team, bis alle ein gemeinsames Verständnis der Story haben. Danach denkt sich jedes Mitglied im Kopf eine Zahl aus, die seines Ermessens der Komplexität der User Story entspricht. Auf ein Zeichen hin zeigt jedes Teammitglied mittels Estimation Poker Karten oder Post-It Zettel die Zahl, die für die User Story angedacht wurde. Jene Zahl, die überwiegend erscheint, wird als Komplexität für die User Story angenommen. Weichen die Estimations zu sehr voneinander ab, kann man davon ausgehen, dass die User Story nicht ganz einheitlich verstanden wurde.

Sprint Demo: Für jeden Sprint werden Sprint-Ziele definiert. Die Arbeit, um diese Ziele zu erreichen, werden jeweils nach einem Sprint während einer Demo-Sitzung anderen Teams demonstriert. In diesen Demositzungen haben Teams aus anderen Abteilungen die Möglichkeit, in die Arbeit anderer Teams einzusehen und zu kommentieren und ggf. Synergien zu erzeugen. Sprint Demos sind in der Regel für alle Mitarbeiter des Unternehmens offen. Es empfiehlt sich jedoch, die Sprint Demo Sitzung in eine allgemeine und technische Demo aufzuspalten.

Scrum Wall: Die Scrum-Wall ist das Herzstück eines jeden Teams, welches mit dem Agile-Framework arbeitet. Die Scrum-Wall konsolidiert alle wichtigsten Informationen für den aktiven Sprint. Dank der Scrum Wall behalten alle mitglieder des Teams die Übersicht über die Laufenden, anstehenden und erledigten Aufgaben.

Sample scrum wall

Scrum Master: Der Scrum Master erledigt neben seinen Sprint-Aufgaben administrative Aufgaben um die Informationen vor, während und nach einem Sprint in die richtigen Kanäle fliessen zu lassen. Der Scrum Master koordiniert die Tasks, Scrums und Reporting der verbrauchten Stunden.

Product Owner: Der Product Owner ist mit anderen Worten der Kunde des Agile-Teams. Der Product Owner erstellt und priorisiert die User Stories und gibt dem Team vor, welche Aufgaben zu erledigen sind und warum.

Somit habe ich euch die wichtigsten Begriffe des Agile-Frameworks etwas näher gebracht. Wie oben schon erwähnt steht es jedem Team frei, auch nur wenige Elemente des Agile anzuwenden oder es auch völlig ganz wegzulassen. Jedoch gibt es heutzutage schon viele Software-Entwicklungs Unternehmen, die dieses Zusammenarbeits-Framework verwenden.
Man kann dieses Framework auch auf ganz andere Arbeiten anwenden. Wir haben dieses Framework sogar schon benutzt um ein komplexes Konzept zu schreiben. Stündlich haben wir ein Scrumming gemacht, weitere Aufgaben verteilt und die Arbeiten rapportiert.
Mit dieser Methode haben wir innerhalb eines Tages in einem Dreierteam ortsunabhänig ein sehr kompliziertes und umfangreiches Konzept geschrieben. Dies hat wunderbar geklappt und hat uns viel Zeit eingespart.

Falls ihr mehr über Agile und Scrum erfahren möchtet: Trainings, Ressourcen, Artikel und Zertifikate für Agile und Scrum findet man hier.

Auf jeden Fall: ich persönlich bin ein Fan dieses Frameworks, weil die Regeln einfach zu verstehen und anzupassen sind und man trotz den Regeln selbstständig und flexibel arbeiten kann.

Michael Greth hat über einen meiner Vorträge einen Podcast gemacht. Er hat den ersten Vortrag „The „fuzzy tail“ – wie entwickelt man ein Suchkonzept?“ komplett aufgenommen und gestern, ebenfalls komplett, bereitgestellt. Wer also Lust hat, den Vortrag noch einmal zu hören, kann das jetzt in Ruhe noch einmal tun.

Der Podcast ist via iTunes oder direkt auf SharePointPodcast.de zu beziehen.

So und hier ist es. Leider ein bisschen unscharf, aber man kann nicht alles haben!

Vielen Dank an Alle die in München an der SharePoint Konferenz waren. Ich hatte viele interessante und lustige Gespräche. Ein „merci“ aus der Schweiz. Bist zum nächsten Jahr.

PS: Das Bild in Originalauflösung liegt auf meinem SkyDrive.