In meinem letzten Artikel habe ich bereits das Thema Scrum kurz angerissen. In dieser Präsentation habe ich die Konzepte von agilen Methoden und insbesondere von Scrum etwas genauer erklärt. Bei Gelegenheit werde ich noch eine Tonspur hinzufügen und einen Slidecast daraus machen. Also viel Spaß damit.
Wer kennt es nicht, der Kunde reicht ständig Anforderungen nach, da er die Gesamtanforderungen nicht kennt. Das Projektteam wird ständig bei der Arbeit unterbrochen und der Kunde ist mit den Ergebnissen nicht zufrieden. So, oder so ähnlich habe ich es in einem meiner letzten Projekte erlebt. Für die zweite Phase musste nun ein Vorgehensmodell her, das auf solche Belange eingeht.
Auf der JAX habe ich auch die agile Lego Hour besucht und damit erstmals einen Einblick in die agilen Methoden bekommen. Ich habe mich nun etwas mit Scrum auseinander gesetzt und werde es für die zweite Phase dieses Projekts einsetzen.
Scrum ist ein leichtgewichtiges Prozessmodell das in Japan zur Produktentwicklung entstanden ist. Kern von Scrum ist das “Product Backlog”, in dem die einzelnen Anforderungen des Kunden beschrieben werden. Der Kunde ist der “Product Owner” und pflegt zusammen mit dem Team das “Product Backlog”; er vergibt die Prioritäten für die anfallenden Aufgaben, welche dann in dem sogenannten “Sprint” abgearbeitet werden. Die Sprints sind Entwicklungszyklen, welche mit zwei bis vier Wochen sehr kurz gehalten sind. Bei der täglichen Zusammenkunft (Daily Scrum) treffen sich die Entwickler (Scrum Team) und entscheiden die nächsten Schritte. Hierbei wird geklärt: “Was habe ich gestern gemacht?”, “Was mache ich heute?” und “Welche Hindernisse sind aufgetreten?”. Das Meeting sollte nicht länger als 15 Minuten gehen. Mit dem “Sprint Burndown” wird visualisiert wie das Projekt voranschreitet Transparenz geschaffen.
In der Ausgabe Nr 13 der Zeitschrift ct ist ein Artikel über Scrum zu finden, der einen guten Überblick der agilen Methoden bietet. Außerdem kann ich noch die Seite von Alexander Kriegisch empfehlen. Dort habe ich mich in das Thema eingelsen.
In kürze werde ich hier berichten wie erfolgreich das Projekt mit der agilen Methode wirklich war.
Web 2.0 ist in aller Munde. Das haben inzwischen auch viele Unternehmen erkannt und versuchen nun die Technologien für die sich nutzbar zu machen. Also entstand schnell der Begriff Enterprise 2.0. Da ich mich in den letzten Wochen gezielt mit dem Thema auseinander gesetzt habe, bin ich über einen Beitrag von Bernd Schmitz gestoßen, in dem er sehr ausführlich den Weg zu Enterprise 2.0 schildert. Es handelt sich um eine Anleitung, wie sie mit zehn Maßnahmen erfolgreich Web 2.0 in ihr Unternehmen integrieren. Die Maßnahmen erstrecken sich über die Bereiche:
Systemverfügbarkeit
Security
Top Down
Usability
Unternehmenskultur
Training
Koordinierung
Consulting
Budget
Integration
Hier wird umfassen erklärt was alles notwendig ist, um ein modernes Unternehmen zu sein, das Web 2.0 Technologien einsetzt und lebt.
Auf der Suche nach Enterprise 2.0 Technologien habe ich einen interessanten Beitrag zu RSS-Feeds gefunden. Der Beitrag ist für alle gedacht, die bisher noch keine Erfahrungen mit Feeds haben und einen kurzen Überblick erhalten wollen.
Die Jungs von commoncraft haben noch mehrere solcher Videos, die ich mir in nächster Zeit mal etwas näher ansehen werde.
Auf meiner Suche nach Mashup-Tools bin ich auf Apatar gestoßen. Apatar ist eine Open-Source ETL (extract, transform, load) Lösung von der gleichnamigen Firma, die auch kostenpflichtigen Support für das Produkt anbietet. Die Lösung selbst steht unter der GPL.
Laut Hersteller biete Apatar Verbindungen zu Salesforce.com, SugarCRM, MySQL, Oracle, Microsoft Excel, Microsoft SQL Server, Microsoft Access, GoldMine, Sybase, PostgreSQL, CSV, Compiere ERP, XML, RSS, ATOM, FTP, POP3, LDAP, WebDav, jeglicheDatenbank über JDBC, Amazon S3, Flickr und viele mehr. Die Daten können aggregiert, vermischt, gefiltert und sonst wie verarbeitet werden. Für komplexe Datenbankabfragen kann ein SQL-Editor benutzt werden.
Der Clou ist allerdings der grafische Editor mit dem die Datenquellen konfiguriert werden. Dieser biete auch Nicht-IT-Mitarbeitern die Möglichkeit Mashups zu erstellen. Der Datenmix kann anschließend über Feeds (RSS/Atom) weiter verarbeitet und in das Unternehmensportal oder Wiki eingefügt werden.
Mashups beziehen ihre Daten von verschiedenen Quellen, transformieren sie und stellen sie in einem anderen Kontext dar.DiesesKonzept verfolgt die Enterprise Application Integration (EAI) ebenfalls. Die Unterschiede liegen in der Umsetzung. Während EAI von der IT-Abteilungmittels Bus-Systemen umgesetzt wurde, werden Mashups im Frontend von den Usernumgesetzt. Bei der EAI ist also die IT im Mittelpunkt bei den Mashups der Benutzer. Beispiele dafür gibt es genug:Google Mashup Editor, Google Maps API, Yahoo! Pipesusw.Wie können nun Unternehmen von dieser Art der Anwendungsintegration profitieren?
Für die Umsetzung eines Mashups gibt es aus architektonischer Sicht viele Lösungsmöglichkeiten. Wenn man allerdings die beiden „Extreme“ unterscheidet, spricht man von Server-Side Mashup und von Client-Side Mashup. Diese lassen sich noch weiter unterscheiden, wie in dem Blog von Dion Hinchcliffe zu lesen. Wenn also die IT-Ableitung eines Unternehmens Server-Side Mashups erstellt bedient Sie sich Frameworks, die das agile erstellen von Web 2.0-Anwendungen erleichtern.Die bereits bestehenden Anwendungen müssten nur mit APIs angereichert werden, damit eine Integration möglich ist. Hierfür bieten sich RESTful Webservice an, die in der Server-Side Mashup integriert werden.Aber auch andere Technologien lassen sich einfach integrieren. RSS/ATOM Feeds, SOAP-Webservices oder Screen scraping um nur einige davon zu nennen. Durch das „Mashen“ solcher Dienste bestenfalls aus Legacy-Anwendungen kann im Frontend mittels AJAX eine neue Anwendung entstehen, die Geschäftsprozesse abbildet, leicht erweiterbar ist und nicht so komplex wie der Serviceorientierte Ansatz. Man kann also davon ausgehen, dass Mashups ein leichtgewichtiger EAI-Ansatz ist.