Google-Pages: Webspace für Gmailer

Februar 28th, 2006 by eric kubitz | Posted in Web 2.0 | 12 Comments »

Google geht - wen wundert’s - unter die Webhoster. War eigentlich höchste Zeit. Schick allerdings, wie das realisiert wurde: Mal wieder extrem einfach zu bedienen - aber mit allen notwendigen Freiheiten.

Mit einigen recht geschmackvollen Templates startet der Einsteiger bei Google Pages in kurzer Zeit und mit wenig technischen Know How. Die Profis können direkt im HTML-Code herumfummeln und haben auf diese Weise alle Möglichkeiten.

Voraussetzung für eine Google-Page ist ein Gmail-Konto zu dem hierzulande eine Einladung notwendig ist (Wer noch kein Konto hat, kann von mir eine Einladung bekommen. Mail genügt).  Ein negativer Eindruck: Ziemlich naiv geht Google mit der URL der Page um: Der wird aus dem Gmail-Namen und "googlepages.com" zusammengebaut. Ergo lässt sich auch die Gmail-Adresse sofort rückfolgern. Ein gefundenes Fressen für Spammer. Einziger Schutz: Wer ein Gmail-Konto für die Mail hat, kann sich ein zweites eröffnen und damit einen passenden Pages-Namen generieren.

Wie es damit weiter gehen wird, lässt sich schnell zusammenfantasieren: AdSense-Anzeigen werden per Knopfdruck integrierbar sein, Google-Videos natürlich auch, dann ein kleines Geo-Targeting der aktuellen Besucher über Maps und schließlich eine Einbindung von Google-Base-Angebote. Was noch? Wir können gespannt sein. 

Ach ja: Warum habe ich diesen Beitrag in die Kategorie Web 2.0 gepackt? Wo ist das "kollaborierende Element" in den Pages? Na ja, "Myspace" ist ja wohl der meist genannte "Web 2.0"-Dienst im vergangenen Jahr. Ich glaube, Google Pages ist die direkte Konkurrenz..

Breaking Info: Voraussetzungen für Extreme Programming

Februar 4th, 2006 by eric kubitz | Posted in Projekte | 2 Comments »

Welche Voraussetzungen machen Extreme Programming überhaupt möglich? Die Methoden und Regeln bei dieser Agilen Methode sind ja tatsächliche "extrem". Deshalb wurde ich in den vergagenen Tagen immer wieder mit der Aussage konfrontiert: "Das ist a schön und nett - funktioniert aber nur im Labor und bei amerikanischen Buch-Autoren. Ich kann davon gar nichts lernen."

Ich halte eine solche pauschale Ablehnung für falsch und möchte deshalb darauf eingehen - bevor ich mich mit wie versprochen damit beschäftige, was wir "normalen" Projektmanager von Extreme Programming lernen können. Es gibt in den zahlreichen Unterlagen im Internet zu XP einige sehr konkret genannte Rahmenbedingungen, die selbst begeisterte Extreme Programmer als Voraussetzung für das Gelingen eines XP-Projektes bezeichnen:

• Die richtige Firmenkultur. Mit Agilen Methoden werden Sie nur in den Unternehmen eine Chance haben, in denen die Mitarbeiter (und die Unternehmensführung!) aufgeschlossen sind und unkonventionellen Vorgehensweisen eine Chance geben. Sie glauben, weil Sie in einer Internet-Company arbeiten, ist das wohl der Fall? Nun, ich kenne eine Menge super-spießiger New-Economy-Manager. Seien Sie sich also nie sicher…
• Hohe Sozialkompetenz. Liebe Entwickler, das ist nicht böse gemeint. Aber eine ganze Menge Techniker sind einfach nicht teamfähig. Sie können (und wollen?) in der Gemeinschaft ihre Stärken nicht aktivieren - und manche behindern damit dann sogar das ganze Team bei der Arbeit. Der Management-Trainer Fredmund Malik betont immer wieder, dass die ganz großen Werke (z.B. Beethovens 9. Symphonie oder Maradonnas Super-Tore) von Einzelpersonen geschaffen wurden und nicht von Teams.
• Kleine Teams. Mein Lieblings-Kommentator hier im Weblog, Nicolas Kübler, hat es beim letzten XP-Eintrag schon dazu geschrieben. Die maximale XP-Team-Stärke liegt bei 10 bis 15 Entwicklern. Sind es mehr, wird die Kommunikation leiden - und damit die gesamte Aufstellung.
• Geringes Risiko. In einem High-Risk-Proekt, bei dem in der Risiko-Analyse womöglich sogar von "politischen Rahmenbedingungen" die Rede ist, sollte der Proektleiter sich und das Team absichern und traditionell mit einer detaillierten Anforderung vorgehen.
• Gewaltenteilung. Das gefällt mir besonders gut. Von beiden Seiten muss akzeptiert werden, dass der Kunde die Business-Entscheidungen trifft und die Entwickler für die Technik zuständig sind. Hat z.B. der Kunde dezidierte technische Phantasien oder das Team möchte eigentlich ein anderes Produkt entwickeln, sollte man von XP die Finger lassen.
• Nähe. Das Team und der Kunde müssen nah beieinander sitzen. Es ist nicht unbedingt notwendig, dass alle ständig in einem Flur zu finden sind. Aber die enge Kommunikation funktioniert nun mal nur direkt.
• Erfahrung. Mit einem Haufen Berufseinsteiger ist XP wohl sehr riskant. (wobei ich der Meinung bin, dass das schon auch gut gehen kann.)
• Technische Grundlagen. Die Teams arbeiten auf funktionierenden technischen Systemen, die zu jedem Zeitpunkt und an jedem Ort automatisierte Tests in der Entwicklungsumgebung zulassen.

So, ich bin gespannt, ob ich hierauf Wiederspruch erhalte. Natürlich freue ich mich auch über weitere notwendige Rahmenbedingungen.

Projektmanager gesucht!

Januar 28th, 2006 by eric kubitz | Posted in Über diesen Blog | 1 Comment »

Jetzt mal was ganz Besonderes: Ein Hinweis auf eine Stellenanzeige zum Junior-Projektmanagmer für CHIP Xonio Online.

Die Stelle ist für alle, die eine Projektmanagement-Ausbildung und/oder Berufserfahrung haben, sicher "bewerbenswert". Technisches Verständnis ist wichtig aber ein guter Auftritt und ein gutes Teamverständnis ebenso. Und, hey, wir benötigen jemanden, der zuverlässig ist und mit großer Genauigkeit ans Werk geht.

Extreme Ideen fürs Projektmanagement?

Januar 22nd, 2006 by eric kubitz | Posted in Projekte | 4 Comments »

Was können wir Projektmanager vom "Extreme Programming" lernen? Ich glaube eine ganze Menge - denn "XP" ist eine moderne und erfolgsorientierte Methode, deren Regeln gerde durch ihre Klarheit auch in andere Bereiche übertragbar sind.

Doch ein Schritt nach dem anderen. Im folgenden Artikel stelle ich die mir wichtig erscheinenden Werte, Methoden und Regeln von XP vor. Erfahrene Software-Entwickler werden die Aufzählung unvollständig und an manchen Stellen auch etwas frei interpretiert finden. Das mag daran liegen, dass ich hier keinen Kurs in "Extreme Programming" mache, sondern schauen will, wie viel XP auch für Nicht-Software-Projekte gut ist. Los geht’s:

Die höchsten Werte in XP sind:

• Kommunikation: Da das Scheitern der meisten Projekte vermutlich auf zwischenmenschlichen Problemen beruht, ist im Extreme Programming die Kommunikation extrem Wichtig. Sei es bei den täglichen Meetings, beim Pärchen-Programmieren und beim Kunden vor Ort (siehe unten).
• Einfachheit: Wenn es zwei Möglichkeiten gibt, ein Problem zu lösen, wird immer die einfacherere Möglichkeit vorgezogen - auch wenn sie vielleicht nicht alle möglichen zukünftigen Entwicklungen verweg nimmt. Es wird immer genau das implementiert, was heute gebraucht wird; denn morgen kann die Anforderung schon eine andere sein.
• Feedback: Die Entwickler und Kunden erhalten gegenseitig z.B. bei den Akzeptantztests Feedback. Das ist vertrauensfördernd und verstärkt die Kommunikation.
• Mut: Ja, genau. Mit Mut soll jedes Projektmitglied erkannte Probleme angehen. Auch wenn es schwer fällt, andere auf Fehler hinzuweisen oder eigene Fehler öffentlich zu machen. Mut wird übrigens auch dann benötigt, wenn überflüssiger Code entfernt werden muss.
• Lernen, Respekt und Qualität: Auch diese Werte werden bei XP immer wieder genannt. Warum diese Werte wichtig sind (nicht nur beim Programmieren), kann hoffentlich jeder meiner Leser selber sagen…

Daneben gibt es eine Vielzahl von Prizipien und Regeln. Ich habe die ausgesucht, die meiner Meinung nach für das "normale" Projektmanagement von Wert sind. 

• Inkrementelle Vorgehensweise: Große Änderungen bergen (zu) große Risiken. Deshalb werden beim Extreme Programming die Dinge kontinuierlich in kleinen Schritten verändert.
• Änderungen sind positiv: Grunsätzlich sind Änderungen gut. Und es muss gute Gründe geben, bei einem Änderungswunsch (des Kunden bzw. eines Kollegen) am Bisherigen festzuhalten.
• Qualitätsarbeit: Das ist die Voraussetzung für gute Ergebnisse und - nicht zu vergessen - für eine hohe Identifikation im Team.
• Lernen lehren: Von doktrinären Aussagen und Vorgaben wird grundsätzlich abgesehen. Lernen und "besser werden" stehen im Zentrum und nicht das Wissen um eine denkbare Perfektion.
• Experimentieren, spielen: "Dienst nach Vorschrift" ist der Tod des Projektes und etwas Risikobereitschaft beim Experimentieren ist entscheidend für den Projekterfolg.
• Verantwortung übernehmen: Verantwortung wird nicht beim anderen abgelegt sondern akzeptiert. Natürlich darf auch bei XP nicht jeder machen was er will. Aber es ist unmöglich, gegen das innere Gefühl der Team-Mitglieder zu arbeiten.
• Reisen mit leichtem Gepäck: Alle überflüssigen Projektvorgaben werden vermieden.
• Ehrliches Messen: Nur bei ehrlichen Schätzungen und dem offenen Kommunizieren von Ergebnissen und dem Fortschritt lässt sich das Projekt erfolgreich abschließen.
• Einfaches Design: Da man davon ausgeht, dass sich Kundenanforderungen ändern werden, wird nicht nach dem besten und langlebigsten Design gesucht, sondern nach dem einfachsten. Das Design muss alle Anforderungen erfüllen und alle Tests bestehen. Mehr aber nicht.
• Refactoring: Wenn festgestellt wurde, dass das Design kompliziert geworden ist, wird das geändert. Beim Refactoring werden keine neuen Features programmiert sondern ausschließlich vereinfacht. Und zwar von ständigen Tests begleitet.
• Programmieren in Paaren: Vermutlich die bekannteste Regel im Extreme Programming. Zwei Programmierer arbeiten mit einer Tastatur und einer Maus an einem Rechner. Der eine ist der Fahrer, der andere der Beifahrer. Wie das funktionieren kann, sollten Entwickler woanders nachlesen.
• Kunde vor Ort: Der Kunde ist jederzeit leicht zu erreichen und ansprechbar. Er soll Fragen beantworten und Prioritäten setzen. Dazu verfügt er über realtives Fachwissen und ist entscheidungsbevollmächtigt.
• Gemeinsame Codeverantwortung: Es gibt keinen Codeteil für den nur eine Person verantwortlich ist. Wird Code integriert und besteht er die Tests ist er fortan "Allgemeingut".
• Programmierstandards: Namenskonventionen, Formatierungsvorgaben und weitere Standards werden exakt befolgt.
• Kontinuierliche Integration: Die Code-Teile werden nicht am Ende eines längeren Prozesses sondern alle paar Stunden integriert (und getestet). Dabei dürfen nicht zwei Programmierer(-pärchen) gleichzeitig integrieren.
• (Fast) keine Dokumentation: Neben einer ordentlichen Inline-Dokumentation im Code gibt es keine "externe" Dokumentation. Diese wäre bei den vielen Änderungen schwer zu aktualisieren und würde ohnehin zu viel Zeit kosten.
• Testen, Testen, Testen: Das Testen des Codes und der Ergebnisse hat im Extreme Programming höchste (!) Priorität. Und zwar bei der Erstellung der Funktionalität mit automatisierten Tests (bitte an anderen Orten genauer nachlesen) aber auch der Akzeptanztest mit dem Kunden.
• Tägliches Stand-Up-Meeting: 5 Minuten, jeder berichtet, was er gestern getan hat und auf welche Probleme er gestoßen ist. Probleme werden angesprochen aber nicht gelöst.
• Metaphern: Mittels eines Bildes werden komplizierte Sachverhalte vereinfacht beschrieben. Wichtig ist eine gemeinsame Sprache. Auch das Endprodukt (Projektziel) wird in einer für alle einheitlichen Metapher beschrieben. Idealerweise kann außerdem jeder Programmteil mit einer Metapher beschrieben werden.
• Überstunden sind Planungsfehler: Eine hohe Beanspruchung im Entwicklungsprozess wirkt sich auf die Leistungsfähigkeit aus und sollte vermieden werden.

Und im nächsten Artikel schauen wir mal, was wir davon für unser Projektmanagement brauchen können.

Podcast: Das Abenteuer Leben

Januar 20th, 2006 by eric kubitz | Posted in Leben | 2 Comments »

Versprochen, am Wochenende werde ich mich wieder  mit agilem Proektmanagement beschäftigen. Aber einen "Lebenstipp" muss ich noch los werden: Die Podcasts des selbst-so-genannten Edutainment-Portals "Das Abenteuer Leben". Das ist eine Gruppe von Trainern, die unter der Federführung von Hans Jürgen Walter Podcasts zu ihren Themen produzieren und veröffentlichen. Themen sind derzeit "Das Abenteuer Leben", "Das Abenteuer Kommunikation", "Das Abenteuer Lernen", "Das Abenteuer Verkaufen", "Das Abenteuer Kreativität" und "Das Abenteuer Präsentieren". Die Podcasts erscheinen so wöchentlich wie möglich - so, dass fast jeden Tag ein neuer auf dem iPod wartet.

Ja, da plaudern langjährige, erfahrene Trainer aus dem Nähkästchen - und zwar auf einem verblüffend hohen Niveau (inhaltlich wie technisch). Ich kenne nichts Vergleichbares im deutschsprachigen Raum. Die Podcasts lohnen sich für alle, die sich beruflich oder privat mit Kommunikation beschäftigen. Und wer tut das nicht?

Man muss schon ein wenig los lassen, um einzutauchen. Aber ich habe derzeit auf jeder Heimfahrt aus dem Büro meine iPod-Köpfhörer auf und lausche am liebsten Hans-Jürgen Walter in seinen Themen "Leben" und "Kommunikation". Bemerkenswert persönlich und angenehm sind seine meist etwa 20 Minuten langen Sendungen. Aber auch die anderen Trainer (Maria Sommer, Helge Thomas, Günter Hübner, Timo Off) haben etwas zu sagen und tun dies sehr professionell.

Ach ja, zu allen Podcasts bzw. zu den Themen gibt es auf der Webseite von "Das Abenteuer Leben" außerdem noch Hintergrund-PDFs, Hörbücher und ein Forum. Ja, und diese Infos kosten teilweise ein paar Euro. Die Podcasts dagegen sind (noch) kostenlos. Aber das wird sich vermutlich demnächst ändern. Das jedenfalls würde ich mir von Hans-Jürgen Walter und seinem Team wünschen. Denn fest steht, dass ein solches Niveau nicht langfristig gehalten werden kann, wenn es keine Einnahmen gibt - Werbeeffekt für die Trainer hin oder her. Also ich bin bereit, für mein tägliches "Abenteuer Leben" auch zu zahlen  bevor ich irgendwann darauf verzichten muss.

Web 2.0: Kollaborierte Musik mit MusicStrands

Januar 16th, 2006 by eric kubitz | Posted in Web 2.0 | 3 Comments »

"Wenn dir dieser Titel gefällt, solltest du dir unbedingt mal den hier anhören." Was wir seit Jahren bei den Buchempfehlungen von Amazon schätzen, nennt sich jetzt "Web 2.0" und beruht auf dem Verbinden des Geschmackes vieler Menschen zu einer Empfehlung.

Na ja, das ist jetzt irgendwie schlecht formuliert - aber ich habe diese Web-2.0-Kategorie erst heute eröffnet und übe folglich noch

Jedenfalls habe ich mich dank meines neuen iPods (dazu irgenwann mehr) in den letzten Tagen auch viel mit Musik beschäftigt und meine alten CD rausgeholt. Aber eigentlich möchte man ja mal was Neues hören. Aber wo finden? Das Problem ist doch, dass im Radio immer nur der gleiche Mist kommt und die Musikhändler (auch iTunes & Co.) weder das ganze Programm haben noch einem irgendeine Navigation bieten. Es gibt Ansätze - aber auch die sind irgendwie ziemlich lausig.

Nun, Yahoo-Radio ist eine gute Idee - aber erstens ärgert mich die Nicht-Unterstützung von Firefox, zweitens kann ich nicht den ganzen Tag lang lila Browserfenster auf meinem Desktop ertragen und drittens habe ich es versucht und nach drei Stunden Bewerten von irgendwelchen Songs habe ich kapituliert.

Viiiieeeeel eleganter (auch farblich) ist dagegen MusicStrands. Das ist eine kleine Software, die sich auf den MP3-Sofwareplayer deiner Wahl einklinkt (solange der iTunes oder Media Player heißt) und dir zu jedem Titel, der gerade läuft Musik empfiehlt, die bei Bedarf an-angehört werden kann. Außerdem können bei MyStrands fleißig Wiedergabelisten getauscht und darin gestöbert werden.

Es darf auch "getaggt" werden. Das ist so etwas Ähnliches, wie das öffentliche Verschlagworten seiner eigenen Informationen mit einfachen Begriffen. Wenn ich zum Beispiel meinen Jack-Johnson-Titeln den Tag "Alternative" mitgebe, dann können die anderen User unter "Alternative" eben auch diese Titel finden. Dazu gehören dann auch diese knuffigen Mindmaps mit den dicken und dünnen Worten. Werden gerade viele "Classical"-Tags an den MusicStrands-Server geschickt, dann erscheint dieses Wort fetter als "Instrumental". Was soll das? Es sind halt eben mehr Leute hier, die sich für "Classical" interessieren, deshalb sollten die das auch schneller finden.

Na ja, ein wenig gewöhnungsbedürftig ist das schon. Aber ich habe festgestellt, dass es sich lohnt, die Gewohnheiten ein wenig zu verändern - und dafür vom Geschmack der vielen anderen Internet-User zu profitieren.

Das Wissen der Masse

Januar 14th, 2006 by eric kubitz | Posted in Projekte | 2 Comments »

Es gibt eine “Intelligenz der Masse”, das steht fest. Als 1968 die USS Scorpion auf dem Grund des Atlantiks verschwand, stocherten die Bergungsschiffe zunächst erfolglos in einem riesigen Seegebiet. Den Durchbruch brachte der Aufruf an viele Wissenschaftler verschiedener Fachrichtungen, augrund der spärlich vorliegenden Informationen einen Tipp über den Verbleib des Bootes abzugeben. Der Mittelwert der abgegebenen Ergebnisse lag nur 200 Meter naben der Stelle, wo das U-Boot gefunden wurde. Zauberei?

Ich beziehe mich hier auf einen super-guten Artikel des Heftes “Wissen” der Süddeutschen Zeitung. Darin finden sich nicht nur schöne Beispiele für diese Intelligenz der Masse - sondern auch die Hintergründe. Aber erst noch ein schöner Fall: Als 1986 die Raumfähre Challenger verunglückte, gab es zunächst nur spärliche Informationen. Trotzdem strafte die Börse (und damit die Menschen dahinter) schon nach wenigen Stunden den Aktienwert der Firma Morton Thiokol, Hersteller der Trägerrakete, ab. Die Aktien der anderen am Challenger-Projekt beteiligten Unternehmen blieben nahezu stabil. Erst sechs Monate nach dem Unglück bestätigte eine Kommission, das von Thiokol stammende Dichtungsringe die Unglücksursache seien.

Hey, die Aktien-Händler wurden von einer mysthischen, kollektiven Vorahnung erfasst! Oder? Vermutlich nicht, man kann das auch anders erklären: Ein Aktienkurs ist die gemittelte Schätzung der Marktteilnehmer. Mit einer großen Grundmenge, bei hoher Heterogenität der Gruppe und - dank der Dollars dahinter - mit einer hohen Aufmerksamkeit der beteiligten Personen. Sind diese Faktoren gegeben, können selbst bei einer lausigen Informations-Lage offensichtlich gute Voraussagen gemacht werden. In dem U-Boot-Beispiel von oben, lag der Mittelwert sogar präsziser als der beste Einzeltipp.

Hier also die executive Summary, wie man das “Wissen der Masse” anzapft:

• Wir brauchen einen Haufen Menschen.
• Die Gruppe muss möglichst heterogen aufgebaut sein um das “Group-Thinking-Problem” zu umgehen, bei dem ähnliches Wissen auf gleich Weise verarbeitet wird.
• Die Teilnehmer müssen sich unabhängig entscheiden können. Hat der Chef (oder andere “gut kommunizierende Mit-Teilnehmer) soeben seine Meinung geäußert und kräuselt bei jeder anderen Interpretation die Stirn, werden die Ergebnisse nicht sonderlich gut sein.
• Die Frage sollte relevant für die Teilnehmer sein. Schließlich geht es nicht darum, dass jeder einfach mal so seine Meinung sagt, sondern um das “Wissen” der Teilnehmer. Und dazu muss nachgedacht werden (z.B. weil es um Geld geht).

Stimmen diese Rahmenbedingungen, kann man tatsächlich davon ausgehen, dass diese Gruppe (oder das Team, der Markt, die Teilnehmer) nahezu prophetische Weisheiten verkündet.

Liest sich alles ganz plausibel und einfach. Ist es aber nicht. Denken Sie doch beim nächsten Brainstorming oder im nächsten Team-Meeting mal dürber nach…