39 Kommentare zu “Entwicklungsmethoden in der Praxis”

1. Oliver/// schrieb:

   ohne selbst Erfahrung gesammelt zu haben, würde ich es Abhängig machen vom Thema.
   Sprich: Einfache “Commodity” Enticklungen, ja. Bei etwas hypigeren und wirklich neuen Ideen definitiv nicht.
   Unzählig viele Stories von Kunden und Partner habe ich gehört, bei denen die Entwicklung unterm Strich teurer und ineffizienter war als wenn sie es Hierzulande entwickeln liesen.
   Bin gespannt auf Ihre weiteren Erfahrungen.

   Kommentiert am 06-Dez-07 um 7:11 am | Permalink

2. Juergen schrieb:

   Ich persönlich habe 3 Jahre mit Programmierern in Shanghai gearbeitet. Die größte Hürde waren die kulturell bedingt unterschiedlichen Vorstellungen von was wichtig ist und was nicht – der nicht niedergeschriebenen, informellen Informationen. Was tun, wenn etwas nicht klar verständlich spezifiziert ist und der Mitarbeiter selber entscheiden muß? Kleine, klar umrissene Aufgaben mit Testscripten haben sich als sehr praktikabel erwiesen. Neue, kreative Entwicklungen mit vielen Änderungen waren immer sehr nervenaufreibend.

   Kommentiert am 06-Dez-07 um 10:20 am | Permalink

3. Oliver/// schrieb:

   Testscripting als Bestandteil agiler Softwareentwicklung (abgeleitet aus extreme Programming) ist methodisch aber nicht leicht zu vermitteln.
   Selbst bei uns schaffen es viele analytisch denkende Informatiker -aus unterschiedlichen Gründen- nicht immer zuerst die Testcases zu erstellen und erst dann zu entwickeln. Mach -wie schon erwähnt- auch nicht immer Sinn.
   Danke für das interessante Thema.
   Gruss vom Bodensee
   Oliver

   Kommentiert am 06-Dez-07 um 10:57 am | Permalink

4. Reto Hartinger schrieb:

   Vielleicht muss ich präzisieren:

   1. Die Mitarbeiter sind meine Angestellten – werden von mir entlöhnt und nicht contracted.

   2. Sie sind lokalisiert und betreut von der Firma in Indien, die die Basissoftware gemacht hat, auf welcher der Dienst (SaaS) aufsetzt.

   3. Die Firma welche die Basis-Software liefert ist an meiner Firma beteiligt und arbeitet bereits 6 Jahre in Indien – geführt von einem Schweizer.

   Diese zwei Punkte sollten es ein bisschen einfacher machen (sollten) vor allem aber auch günstiger. Ich bin mir bewusst, dass die Junior mindestens 6 Monate brauchen, um wirklich effizient zu werden.

   Ich habe Erfahrung mit einem Team in Russland, dass wir fest gemietet hatten. Die waren super Cracks – aber wir einfach zu doof, ihnen jeweils die Dinge so zu präzsieren dass wir das bekommen haben was wir wollten. Und auch in der Usabilty. Wir hätten (und hatten) aber dasselbe Problem auch in der Schweiz mit Schweizern gehabt (nur einfach teurer).

   “Die größte Hürde waren die kulturell bedingt unterschiedlichen Vorstellungen von was wichtig ist und was nicht – der nicht niedergeschriebenen, informellen Informationen”.

   Genau das haben wir auch – an dem arbeiten wir daran. Von Vorteil ist, dass wir mit Leuten arbeiten, die dieses Problem schon seit 6 Jahren kennen. Die Inder machen anscheinend immer alles zu perfekt – z.B wird immer alles validiert – eben auch dort wo es dies gar nicht braucht. Ein Inder sagt grundsätzlich nicht nein – man muss hören wie er ja sagt um zu erfahren ob es ein nein ist.

   Kommentiert am 06-Dez-07 um 2:17 pm | Permalink

5. Christof Moser schrieb:

   Hoi Reto

   Also “z.B wird immer alles validiert – eben auch dort wo es dies gar nicht braucht” ist meiner Meinung nach schon ein falscher Ansatz. Wird etwas von Anfang an richtig (validierbar) programmiert, hat man nachher weniger Aufwand, weniger Probleme = weniger Kosten.

   Die bereits genannten Gründe haben auch mich bisher davon abgehalten, auf Fremdressourcen aus dem Ausland zuzgreifen. Der grösste Mangel ist ganz klar die Qualität des Codes.

   Kommentiert am 06-Dez-07 um 4:15 pm | Permalink

6. Pierre Rappazzo schrieb:

   Was kosten die Inder in Schweizer / Mannstunden? Ich arbeite mit Ostdeutschen in virtuellen Arbeitsgruppen (wenn nötig) zu Euro 20 bis 35. Mache gute Erfahrungen.

   Kommentiert am 06-Dez-07 um 4:35 pm | Permalink

7. Michael Marth schrieb:

   Hi Reto,

   meine persoenlichen Erfahrungen mit SW Entwicklung in Indien (mit Projekten in aehnlichen Groessenordnungen):

   1 hohe Fluktuation der Mitarbeiter
   2 hohe Kommunikationsaufaende
   3 hoehere Spezifikationsaufaende
   4 Code Qualitaet schlecht

   Deine Testscripts sind interessant, aber fuehren zu 3) (*) und verhindern 1) und 4) nicht.

   Fuer den langfristigen Erfolg Deines Projekts duerfte auch wichtig sein, wie lange die 3 Seniors an Bord bleiben. Wenn alle drei in einer Woche gehen (schon erlebt), verlierst Du eine Menge Zeit (und Geld).

   Ich habe deutlich bessere Erfahrungen mit osteuropaeischen Partnern (geringere Fluktuation, bessere Qualitaet)

   Gruesse
   Michael

   (*) ausser Du arbeitest sonst auch mit Testskripts

   Kommentiert am 06-Dez-07 um 4:43 pm | Permalink

8. ajay mathur schrieb:

   Ja Reto, wir outsourcen der Coding Teil unser Software seit längere Zeit sehr erfolgreich nach India. Ich persönlich habe auch der Vorteil der Kulturaffinität, da ich selber meine “roots” in Indien habe. Deine Erfahrung kann ich jedoch bestätigen.

   Grundsätzlich sind einige wesentlicher Unterschied zwischen Schweiz/West-Europa und India zu beachen (abgesehen von der kulinarischen…). Die Ausbildung der Software Entwickler. Hier werden in mehrjährige Studium in (Fach-)Hochschulen bzw. in der Berufslehre Informatiker ausgebildet die fähig sein sollten alle Arbeiten von der Konzept bis zur Ergebnisabnahme zu leisten. In India ist Focus der Ausbildung vorwiegend auf die Programmierung. “give me the exact specs and I’ll code it for you”. Deine beschriebene Vorgehensweise nimmt rücksicht darauf.

   Ein weiterer Unterschied ist die strenge Hirarchie der Indische Firmen wo der Coder (meisten) der Status von einen Handwerker geniesst. Die Coder-Fluktuation bei IT-Firmen ist hoch und liegt jährlich zwischen 15% und 30%, je nach Firma.

   Kommentiert am 06-Dez-07 um 4:59 pm | Permalink

9. Anne Gasser schrieb:

   Bonjour Reto

   Je ne pense pas qu’il s’agisse d’un problème culturel entre la Suisse et l’Inde. Le problème est, selon mon expérience, que nous,côté Business nous ne parlons et ne pensons de la même manière que les développeurs…

   Ce qui pour nous est logique ne l’est pas forcément pour l’autre partie. Comme toi, je pensais que les présentations PPT suffisaient, mais non tout doit être écrit sous forme de Use cases et ce jusque dans les moindres détails (procédure souhaitée, quid si cela ne répond pas correctement, connection avec d’autres uses cases). Sans quoi nos développeurs “tuen blöd”….

   Une fois programmé il faut tout tester, tout documenter car de toute façon le risque est élevé que je ne reçoive pas ce que j’ai souhaité. Car une fois le projet “genemigt” toute erreur n’est pas considérée comme bug mais comme “change request”…..

   Aujourd’hui je me pose la question, si cela ne vaudrait pas plus la peine de travailler avec des Indiens. Car pour être confrontée avec les mêmes problèmes, les honoraires sont bien moindres.

   A bon entendeur! Salut!

   Kommentiert am 06-Dez-07 um 5:04 pm | Permalink

10. Oliver/// schrieb:

    Ich würde aus dieser Erkentnis heraus diferenzieren: Entwicklung von Businesssoftware mit tiefem fachlichen Prozessverständnis ist evtl. weniger für Fernost-Outsourcing geeignet, da ein vergleichsweise hoher Kommunikations- und Konzeptionsaufwand notwendig ist (wir haben inzwischen nur noch einen Programieranteil von 36%) – als Softwarehaus.
    Am Besten wir warten mal ab, welchen Web-2.0 Dienst Reto aus dem Hut zaubert und wie seine Resümee dann ausfällt.

    Kommentiert am 06-Dez-07 um 5:09 pm | Permalink

11. Martin Prange schrieb:

    Halo Reto – behalte das bei, die Testscripte sind unabkoemmlich.

    Eine grosse, bankenaehnliche Firma in Luxemburg hat ca. um 2002
    ein inhouse entwickeltes Softwareprodukt nach Indien ausgelagert.

    Nachdem es ca. 3,4 Sahre zu einem re-insourcing Beschluss kam, stellte sich heraus, die SW war nicht einmal mehr automatisch deploybar.
    Ich habe (kleine! ) Teile des Code gesehen der zwar mit “sprechenden” Identifiern ausgestattet war aber auf jegliche, “unnoetige” Unterstrukturierung verzichtete.
    Der Code war groesstenteils unwartbar.

    Das ist es aber u.a. exakt, was vermieden werden muss.

    Andere Faktoren beeinflussen o.a. Wichtigkeit naturlich:
    Wie hoch ist der Innovationsfaktor?
    Wie lang soll diese Applikation denn leben?
    Wird die Codequalitaet gemessen?
    Gibt’s ueberhaupt ein High-Level Design (Softwarearchitekt) ?

    Gruss
    Martin Prange

    Kommentiert am 06-Dez-07 um 5:14 pm | Permalink

12. Daniel Bruckhoff schrieb:

    Macht das Sinn das man das in Indien machen muss. Verliert man da nich in der Schweiz Arbeitsplätze?

    Kommentiert am 06-Dez-07 um 5:20 pm | Permalink

13. Reto Hartinger schrieb:

    @ Daniel: “Macht das Sinn das man das in Indien machen muss. Verliert man da nich in der Schweiz Arbeitsplätze?”

    Im Gegenteil. Es wird in der Schweiz hochwertige Arbeitsplätze schaffen, da ich das Projekt in der Schweiz kaum auf die Beine bringen könnte (weil ich ja auch die Basissoftware aus Indien brauche und die nicht noch zusätzlich programmieren könnte).

    Es wird Stellen geben – wohl auch für Informatiker. Aber erst wenn das ganze so ziemlich gut steht. Es wird auf der ganzen Welt Arbeitsplätze generieren aber auch Arbeitsplätze abbauen. Man wird viel effizienter arbeiten können. Das ermöglicht Firmen profitabler zu machen, die dann in ihren Branchen wiederum wachsen und Leute einstellen können. Die Arbeitsplätze werden einfach verlagert.

    Aber keine Angst – die Software (bzw. das SaaS Internet Portal) wird unterschätzt werden. Die Konkurrenz wird es belächeln, um später rechts überholt zu werden. Darin habe ich Erfahrung ;-)

    Das schöne an neuen Technologien: wer sie nicht nutzt, kann ausgebremst werden. Egal wie gross und mächtig das Unternehmen zurzeit ist, egal wie gross der Marktanteil ist.

    Aber hoffentlich rutscht die Diskussion nicht von der Entwicklung ab.

    Kommentiert am 06-Dez-07 um 5:37 pm | Permalink

14. Ajay Mathur schrieb:

    Hey hey hey, ho ho ho!

    I think it’s not just a matter of culture differences and worker attrition that make it so difficult for us to get the best benefit of the resources that are available internally or internationally.

    It’s more a case of how software development is percieved and conducted (remember the term “quick and dirty” or even better, “quick and working”?). Some old bad habits, maybe???

    I’ve read a number of comments about how time-consuming and tedious it is to define requirements and define specs… and then you have to explain it all to somebody with an accent, eh?

    People, wake up and smell the coffee…

    Multiple studies have indicated that roughly 50% of the defects identified on software projects can be traced back to errors in the requirements. One analysis of the potential return on investment from better requirements suggests that requirements errors can consume between 70% and 85% of all project rework costs. It can cost up to 110 times more to correct a requirements defect found in operation than it would if that same defect had been discovered during requirements definition. A survey (done way back in 2001) “confirms that e-projects are time-compressed, intensive and mission-critical efforts with poorly defined requirements.

    The top three risks threatening the success of the e-projects surveyed were:
    • Unstable, constantly changing requirements (66%)
    • Poor requirements specification (55%)
    • Client behavior, such as approval delays, requirements changes and poor communication (42%)

    Even though project teams often do not think they have the time to effectively elicit and capture requirements (and write specs), they always seem to find the time, people and money to fix problems found in a delivered product.

    This applies to Switzerland, Germany, India, Russia, Singapore, Fiji,… wherever software work is conducted.

    By the way, which jobs are you talking about that may get killed in Switzerland due to software development outsourcing??

    To you, all the poor jobless Java or C coder; Any Java or C coder who lost his job due to outsourcing may immediately apply for a job in our company. jobs@axes-systems.com

    Kommentiert am 06-Dez-07 um 6:34 pm | Permalink

15. Joerg Resch schrieb:

    Hallo,
    das meiste ist schon gesagt/kommentiert, ein paar persönliche Erfahrungen möchte ich dennoch beisteuern, wenn auch nicht mit Indien. Von 1995 bis 2001 habe ich in Sibirien eine Software-Entwicklungsabteilung mit zuletzt etwa 100 Entwicklern aufgebaut. Wir haben zunächst in PHP, später dann in Java, eine Anwendung realisiert.
    Vorweg: Die verteilte Arbeit an einem Softwareprojekt mit hochwertigem Resultat funktioniert, das lebt uns die Open Source jeden Tag von neuem vor.
    Aber: In meiner Erfahrung waren es (gemessene) 75% der gesamten Aufwände, die mit dem eigentlichen Coding nichts zu tun hatten. Ein kleinerer Teil dieser non-Coding Aufwände ist der geografischen Verteilung geschuldet, der größere Teil fällt immer an. So ist beispielsweise die Erstellung von Testframes für eine Anwendung mit durchschnittlicher Komplexität mindestens ebenso aufwendig wie das anschließende “befüllen” derselben mit Code Und natürlich auch sehr viel schwieriger, denn damit findet die eigentliche Umsetzung vom der Idee zu einer Software statt. Das anschließende Coding ist ein Stück mathematisches Handwerk, bei dem es fast schon egal ist, ob es sich um einen low-level Bluetooth-Treiber oder um einen Social Graph Webservice handelt.
    Wir haben dieses mathematische Handwerk in Russland gesucht und in einer Qualität gefunden, wie das hierzulande nach wie vor nur in Ausnahmefällen der Fall ist. Allerdings nicht als fertige Struktur, die mussten wir selber aufbauen.
    Zur Entwicklungsmethodik: Nach einigem rumprobieren stellten wir konsequent auf pair programming um. Die Entwickler wurden von lokalen Projektleitern nach der Scrum Methodologie geführt. Ander konnten wir auch gar nicht, denn unser Ansatz war, sagen wir mal, sehr agil: Wir wußten lange Zeit nicht so recht, in welche Richtung wir die Anwendung entwickeln sollen und haben unsere Vorstellungen mehrfach täglich revidiert ;)
    Ohne die inhaltlichen Beiträge der Entwickler wären wir komplett aufgeschmissen gewesen. Ohne deren Wissen um Open Source und die konsequente Nutzung von Open Source Komponenten hätten wir alle möglichen Räder vielfach neu erfunden.

    Kommentiert am 06-Dez-07 um 7:38 pm | Permalink

16. Daniel Niklaus schrieb:

    Scheitern Projekte, beschwören Manager, Berater und Wissenschaftler immer wieder die allseits bekannten Prinzipien des Projektmanagements.

    * Die Ziele hätten klarer definiert werden sollen
    * Die Risiken hätten besser analysiert werden sollen
    * Die Planung hätte detaillierter erfolgen sollen
    * Die Überwachung hätte noch besser erfolgen sollen
    * Die Mitarbeiter hätten mehr kommunizieren sollen

    Doch vielleicht stimmt das alles überhaupt nicht.

    Klassisches Projektmanagement funktioniert nur bei klar definierten Problemen. Aber heutige Probleme sind schlecht definiert, interdisziplinär, äusserst komplex. Zudem ändern oft während des Projekts die Anforderungen.

    5 Faustregeln, wie Projekte in Zukunft gestaltet werden können:.

    1. Die Verantwortlichen verzichten auf eine genaue Definition von Zielen und legen nur einen breiten Zielkorridor fest.
    2. Das Projektteam beginnt mit der Arbeit, bevor alle Aspekte des Vorhabens zu Ende gedacht sind. Die Phasen Problemanalyse, Massnahmenerarbeitung und Umsetzung sind nicht voneinander getrennt.
    3. Es wird auf Projekt- und Lenkungsausschüsse verzichtet und stattdessen mit wechselnden Gruppen gearbeitet.
    4. Die zuständigen Führungskräfte sollen die in Projekten üblichen Machtspiele nicht verkürzen, sondern zulassen.
    5. Die Verantwortlichen arbeiten mit Erfolgssurrogaten (surrogat=annähernder Ersatz), weil sich bei komplexen Projekten ein objektiver Erfolg meist nicht nachweisen lässt.

    Kommentiert am 06-Dez-07 um 8:10 pm | Permalink

17. ThomasKolb schrieb:

    Das ist spannend!

    Eine bescheidene Frage:

    In wie fern sind bzw könnte Extreme-Programming förderlich sein?
    Ist das kulturell bedingt schwieriger oder im Gegenteil idealer Einsatzbereich?

    Kommentiert am 06-Dez-07 um 8:15 pm | Permalink

18. Pierre Rappazzo schrieb:

    Meine Frage nach den Kosten, ist noch nicht beantwortet. Ich kann mir kaum vorstellen, dass sich bei einem so kleinen Projekt das Outsourcing in einen anderen Kulturkreis lohnt. Als Währung schlage ich eine Resulat-Stunde vor. Eine Resultat-Stunde ist das Resultat, das durch einen mittelmässigen Schweizer Codierer in einer Stunde erzielt wird. Also was kostet in Indien eine Resultat-Stunde.

    Kommentiert am 06-Dez-07 um 8:44 pm | Permalink

19. Reto Hartinger schrieb:

    Ich bezahle für die 5 novizen etwa soviel wie für einen programmierer hier

    die Resultatsunde ist ein guter Vorschlag. Wir hatten mit search.ch ja ein Team in Russland (im gleichen Ort übrigens wie Jörg Resch und Stephan Widmer) gehabt. Deren Codequalität und vor allem deren Programmierkenntnisse war weit über derer eines normalen Programmierers hier. Die Inder kann ich noch nicht beurteilen. Ich werde die Quodequalität später vom besten Programmierer den ich kenne einmal beurteilen lassen. Mal sehen was er sagt. Ich habe von ihm einmal die Software-Architektur beurteilen lassen. Die fand er gut. Wir programmieren übrigens so, dass das Teil auch läuft wenn Javascript disablet ist oder nicht richtig funktioniert. Somit könnte das Teil auf vielen Maschinen laufen.

    Kommentiert am 06-Dez-07 um 9:02 pm | Permalink

20. Joerg Resch schrieb:

    Kostenvorteile durch das Outsourcing von Programmierleistungen sind von Europa aus ganz sicher erreichbar. Nicht nur wegen des hohen Euro-Kurses, sondern auch hinsichtlich Produktivität und Qualität. Wir haben traditionell gute Ingenieure, können perfekt Stahl walzen, Autos, Uhren oder Maschinen bauen. Aber Softwareentwicklung?? Die Stadt Novosibirsk in Sibirien bildet an ihren unterschiedlichen Universitäten doppelt so viele Informatiker aus wie das bevölkerungsreichste deutsche Bundesland Nordrhein-Westfalen mit seinen 18 Millionen Einwohnern.

    Kommentiert am 07-Dez-07 um 9:18 am | Permalink

21. Daniel Niklaus schrieb:

    Ja, ja, die Entwicklerwelt ist so schön einfach:
    “die Codequalität vom besten Programmierer beurteilen”. Wie beurteilt er die Codequalität? Ob der Code schön dokumentiert ist, sauber Objektorientiert oder richtig schnell ist? Hat er dann auch die Aufgabe richtig verstanden, um die “richtigen” Qualitäten zu beurteilen und wenn er sie beurteilt hat, was machst du mit dem Resultat?

    Das mit der Testperson finde ich eine gute Idee, muss man sich leisten können. Oder wird es ohne hervorragende Qualitätskontrolle später gar teurer? Wahrscheinlich ist die Testperson eine sehr gute Investition.

    Die Art, wie diese Person testet, deutet auf ein simples Programm hin. Ich habe A und es gibt nur einen Weg zu B. Was passiert aber, wenn es von A nach B mehrere Wege gibt. Und wenn die Software so flexibel ist, dass man auch nach C gehen kann, über A und B. Vielleicht gar über D. Dann sind die Testscripts eine gute Sache, aber halt nur ein kleiner Teil der Gesamtlösung, weil die Komplexität zu gross wird, als dass sie noch jemand erfassen kann. Geschweige denn ein Team richtig erfasst.

    Blenden wir beim Testen die kleinen Dinge aus wie; Betriebssysteme, Browserversionen, Sprachpakete, Sicherheitseinstellungen, Bildschirmauflössungen, Rückwärtskompatibilität, unerwartete Veränderungen bei zukünftigen Browsern und last but not least; neue und andere Anforderungen an die Software, welche erst beim Entwickeln entdeckt werden.

    Willkommen in der Softwareentwicklung – wenn jemand ein Patentrezept hat; ich könnte es gebrauchen ;-)

    (schön, dass es hier einmal technisch wird)

    Kommentiert am 07-Dez-07 um 9:20 am | Permalink

22. Reto Hartinger schrieb:

    @Dani: “die Codequalität vom besten Programmierer beurteilen”. Wie beurteilt er die Codequalität?

    Er hat genug Erfahrung die Wichtigkeit der erwähnten Punkte einschätzen zu können. Ich denke, dass er vor allem sieht – auf welcher Qualität die Programmierer sind und wie man die Performanz erhöht und was wer tun muss – ja und er kann sogar auch sagen wie (kommt besser an als nur ein Rumgemotze von Nichtprogrammierern). Das ist etwa so wie wenn ich auf einen Businessplan schaue – ich sehe die Schwachpunkte in Strategie, Businessmodell und der Umsetzung und kann sagen was zu tun ist und konkret helfen mit Kontakten, Massnahmen etc.

    “Das mit der Testperson finde ich eine gute Idee, muss man sich leisten können.”
    Wir können uns die Testperson nicht nicht leisten. Alles andere wäre schlicht zu teuer. Da wir kein Testscript ablaufen lassen sondern eine echte Person Dinge ausführen lassen, wird sie flexibel auf die von Dir angesprochenen Probleme reagieren (hoffentlich).

    Nein – das Patentrezept habe ich natürlich auch nicht. Aber ich weiss, dass ich sowas wie ein Fussballteam habe. Es sind Leute mit unterschiedlichen Fähigkeiten die das Zusammenspiel lernen müssen. Sie spielen gegen eine andere Manschaft die laufend ihre Taktik ändern kann. Wir kennen im Vorneherein weder die Spielstärke des Gegners noch die Varianten die er drauf hat. Genau wie beim Fussball ist es aber nicht so, dass das schwächste Glied die Stärke des Teams und das Endresultat bestimmt, sondern wie wir unsere Stärken einsetzen können. Ob Rombus oder Vertikale die Stärke ist, müssen wir finden. Wir müssen nur ein Tor mehr erzielen als unser Gegner und das arme Schwein kämpft nämlich mit den gleichen Problemen.

    Kommentiert am 07-Dez-07 um 9:41 am | Permalink

23. Olivier Roth schrieb:

    Ich denke, in diesem Projekt bestehen zwei Kommunikations-Herausforderungen:

    a) Business (Mgr, Marketing) – IT
    hier sind Missverständnisse über das WAS an der Tagesordnung (Business-seitig existieren oft Erwartungshaltungen über nicht beschriebene „state of the art“-Features, wenig Kenntnis über Prozesse und insbesondere Ausnahmen) – häufig kann das nur anhand eines Prototyps geklärt werden. Ich stimme betreffend Beschreibung der Anforderungen Ajay Mathur absolut zu. Nur sollen die Anforderungen in vielen Fällen mit Vorteil iterativ definiert werden.

    b) Europa – Indien
    hier kommen neben den WAS-Fragen auch noch vermehrt die WIE-Fragen auf: wie wird kommuniziert, z.B. wenn man etwas nicht versteht, wenn ein Fehler gemacht wird, wie wird gearbeitet/entwickelt (Coding standards, Versioning, Documentation, gemeinsam genutzte Objekte etc.) etc. – hier sind kleine Arbeitspakete (Units) mit klaren und (schnell) überprüfbaren Vorgaben (z.B. Testscripts – Unit testing) notwendig. Auch Code-Review der ersten (!) Teilresultate ist absolut notwendig.

    Eine weitere Herausforderung erwarte ich (ist allerdings sehr von der Anwendungsart abhängig) im Bereich der Integration: wie werden die Units erfolgreich zu einem Ganzen gefügt? Nebst einer gescheiten Architektur (!) sind hierfür notwendig: Tests der Interfaces zwischen den Units, eine Testumgebung, in der Units einzeln oder im Verbund getestet werden können und eine Leitung vor Ort, die Zweck, Anforderungskatalog und Stand der Entwicklung zu 100% kennt.

    Da Ihr nicht nachkommt mit Spezifizieren, erwarte ich eine grosse Unsicherheit betreffend Anforderungen. Ihr müsst deshalb genügend Ressourcen für Iterationen einplanen. Entsprechende Entwicklungsmethoden sind x-fach beschrieben worden und mittlerweile vielerorts erfolgreich angewendet worden.

    Good luck!

    Kommentiert am 07-Dez-07 um 10:03 am | Permalink

24. Pierre Rappazzo schrieb:

    Vielleicht bin ich etwas altmodisch, aber testen ist für mich Chefsache.

    Ich bin zuversichtlich, dass Berni ;-) den Code schon richtig beurteilen wird.

    Aber um dich etwas unter Druck zu setzen, sag uns doch hier, bis wann du uns zum Beta-Test einlädst :-)

    Kommentiert am 07-Dez-07 um 10:04 am | Permalink

25. Reto Hartinger schrieb:

    Es ist unglaublich, wie viele gute Inputs ich von Euch bereits bekommen habe. Besten Dank.

    Zum Betatest werde ich einladen sobald ich denke, dass ich für das Produkt gerade stehen kann. Ich denke, dass ihr es lieben und der Eine oder Andere es einsetzen wird.

    Vielleicht sind meine Vorstellungen aber einfach zu weit weg von Powerpoint, Testscript und Code und ich muss das Teil wieder kübeln. Dass es gelingt – programmiertechnisch, usabilitymässig, Marktakzeptanz, Finanzierung, Businessmodell und Executing, liegen bei 25 %.

    Kommentiert am 07-Dez-07 um 10:12 am | Permalink

26. Pierre Rappazzo schrieb:

    @Joerg Resch: Wie sind eigentlich die Sprachkenntnisse der Novosibirsker?

    Kommentiert am 07-Dez-07 um 10:15 am | Permalink

27. Pierre Rappazzo schrieb:

    @Reto: Du drückst dich ;-) Du weisst ein Projektplan hat immer auch ein zeitliches Ende. Dieses kannst du zwei Mal nach hinten verschieben und dann kannst du abbrechen, weil du nie fertig wirst.

    Kommentiert am 07-Dez-07 um 10:18 am | Permalink

28. Stephan Widmer schrieb:

    Hallo Samichlaus
    Interessantes Thema. Wir hatten dazumals beim Aufbau von Ricardo unser Programmiererteam in Novosibirsk (tiefstes Russland). Wie bereits von Dir beschrieben, hatten wir dort Zugriff auf die vollen Kracks mit Goldmedaillenabschluss von den besten Unis etc. Wir haben klein angefangen und remote gemanaged und festgestellt, dass es einfach so nicht ging. Uns wurden Termine versprochen obwohl vermutlich für den Programmier schon klar war, dass er diese nicht einhalten kann. Wir haben uns kurzerhand entschlossen einen Schweizer nach Sibirien zu schicken der 2 Jahre lang die Programmierer geführt hat (er ist immer noch einer meiner besten Freunde:)). Im weiteren haben wir in die Infrastruktur investiert damit die Russen überhaupt vernünftig arbeiten konnten (redundate Internet Leitung etc.). Selber sind wir alle 2 Monate hochgeflogen. Zu guter letzt hatten wir an die 70 FTE und waren sehr produktiv. Ein grosses Problem war für uns die Loyalität, d.h. für etwas mehr Lohn sind die Leute einfach nicht mehr bei uns aufgetaucht und haben bei einer anderen Firma angefangen zu arbeiten. Suma sumarum hat sich das ganze Unterfangen so gelohnt, wir hätten die Plattform niemals in der Schweiz finanzieren können und hätten dazumals auch nicht genügend Programmierer gefunden. Bei kleineren Projekten finde ich Dein Vorgehen mit wöchentlichen Zielen sehr praktikabel.

    Kommentiert am 07-Dez-07 um 10:25 am | Permalink

29. Martin Prange schrieb:

    Well, beim 1:5 Verhaeltnis ( ich haette 1 : 7 geschaetzt ) wuesste ich nicht mehr ob sich das auf die Dauer mit den Overhaed rechnet, Reto.

    Kommentiert am 07-Dez-07 um 1:55 pm | Permalink

30. Franco Dal Molin schrieb:

    Gute Diskussion! Unsere Erfahrung mit Teams in Ukraine, Bulgarien und Indien spricht im Moment für die Ukraine (Kharkov). Es sind ja immer Trade-off Entscheide zu fällen zwischen Distanz, Verfügbarkeit guter Entwickler am Markt, Preise, Zeitzonen, Kulturunterschiede, usw. Kharkov ist eine grosse Unistadt mit ca. 20 Unis und 400′000 Studenten. Nur eine Zeitzone weit weg. Man kommt da über Wien gut hin. Noch nicht so hart “umkämpft” und teuer wie Kiev. Insgesamt sind wir recht zufrieden.

    Methodik ist wichtig, aber hier bitte nur das Minimum, dafür sollte sie gut “verinnerlicht” sein und vom remote Team getragen werden. Ein iteratives, agiles Vorgehen ist wünschenswert. Es gibt einem einfach schneller Feedback und Korrekturmöglichkeiten. Eine gute Vorlage hierfür ist “openUP” (http://epf.eclipse.org/wikis/openup/index.htm). So wie beschrieben ist die Methodik für co-located Teams optimiert, d.h. mit remote Management muss man noch mehr Wert auf offene, direkte und häufige Kommunikation legen. Vor Ort Besuche alle 3-4 Monate sind ein Muss. Auch sauberes Requirements Engineering (Dokumente) gekoppelt mit einem sehr kompetenten Technical Lead (”Senior”) vor Ort sind zentrale Erfolgsfaktoren. Gewisse Prozess und Methodikschulungen sind immer nötig.

    Das Testcase-driven Development ist eine gute bottom-up Vorgehenstechnik aus dem “Extreme Programming” Ansatz und vor allem dann effektiv, wenn noch 2-3 andere Punkte eingehalten werden, so wie kontinuierliches Builden und automatische Unit Regressionstests. Ich würde es aber aber nicht auf die dogmatische Spitze treiben. Aus Product- und Projectmanagement Sicht scheint mir ein Use-Case-getriebenes Vorgehen (d.h. Use-Cases als kleinste Einheit für die Spezifizierung, Schätzung, Planung, und Test/Abnahme) eine gute und auch für Offshore Entwicklung praktikable Vorgehensweise.

    Kommentiert am 07-Dez-07 um 4:15 pm | Permalink

31. Andreas Graf schrieb:

    Ich möchte hier mal noch einen anderen Aspekt einbringen:
    Qualität, Produktivität und Fluktuation hängen zu einem grossen Teil vom Managment inkl. Einstellungsprozess ab.
    Meine Beobachtung ist, dass dies im Outsourcing oft von Betriebswirtschaftern gemacht wird. In der Schweiz stellt man auch nicht einfach mal ein paar Entwickler an und probiert das mal aus.
    Passiert aber im Outsourcing, da man meint bei tieferen Kosten sich Experimente eher erlauben zu können => Planspiele.
    Wir betreiben in Novosibirsk seit 8 Jahren erfolgreich ein Entwicklungszentrum mit 20 Entwicklern. Ich kenne jeden persönlich mit seinen Stärken und Schwächen und bin regelmässig Vorort und wir bieten den Mitarbeitern wie das auch hier üblich ist, attraktive Arbeitsbedingungen (keine Galeeren Ruderer).
    Unsere Fluktuation liegt im normalen Rahmen wie ich das auch aus der Schweiz kenne, sie ist sogar etwas tiefer da in Russland heiraten und kinderkriegen viel früher stattfindet als bei uns => Stabilität ist wichtig.
    Meine persönliche Schlussfolgerung:
    Wer es schafft in der Schweiz ein Entwicklungsteam aufzubauen und erfolgreich zu betreiben schafft es auch in fernen Landen sofern er bereit ist Vorort auch persönlich regelmässig präsent zu sein und einen lokalen Manager hat mit dem man sich sehr gut versteht und auf Augenhöhe kommunizieren kann.
    Bei uns ist das ein Deutscher Ingenieur der mit einer Russin verheiratet ist (Einstellungsprozess).
    Codequalität und Entwicklungsmethoden sind Diskussionen die meiner Meinung nach nichts mit Outsourcing zu tun haben.
    Das ist etwa so wie die Diskussion welche Uni nun die besseren Leute produziert. Es gibt bei allen gute und schlechte. Man muss halt die guten auswählen.
    Was zählt sind Resultate.

    Kommentiert am 08-Dez-07 um 11:11 am | Permalink

32. Daniel Niklaus schrieb:

    Hallo Andreas

    Ein hervorragender Beitrag. Mach doch diesen als eigenständigen Blogeintrag und dann diskutieren wir über Einstellungskriterien von Entwicklern.

    Kommentiert am 08-Dez-07 um 11:41 am | Permalink

33. Markus Hegi-Nagavkar schrieb:

    Keine Patentrezepte – Fighting complexity -

    Mit grossem Interesse habe ich Eure Kommentare gelesen –
    Wir sind mittlerweile 7 Jaher hier in Pune (Indien) mit einem Team zwischen 30 und 60 Angestellten. Ich selber bin 50% in Indien (6 Wochen Rhytmus). Wir arbeiten am Projekt mit Reto seit 3 Monaten.

    Kulturelle Faktoren spielten am Anfang eine grosse Rolle, mittlerweile hat sich das Team gut eingespielt und kurlturelle Eigenheiten & Missverstäntnisse sind nur noch ein klener Teil.

    Die Fluktuation ist ein Hauptproblem: Speziell für kleinere Firmen hier. Zu einem gewissen Grad kann man dem mit speziellen Verträgen entgegenwirken (Bonus für langes Bleiben)

    Methodik ist gut, verlangsamt jedoch den Entwicklungsprozess, und “kills the innovation”. Als Produktefirma orientieren uns an Extreme Programming Prinzipien. Damit machten wir die besten Erfahrungen – auch wegen dem pragmatischen, auf Innovation ausgerichteten Approach. Für das Produkt haben wir eine high-Level Dokumentation, meist in PowerPoint, im Übrigen fokusieren wir auf den Source Code als Dokumentation. Mit dem Projekt mit Reto war das Problem, dass die ppts zu grob waren und die Entwickler unsicher über die Spezifikationen waren. Deswegen arbeiten wir in Projekten oft mit Testscripts.

    Ein Testscript besteht bei uns aus einem Hauptscript (oft weniger als 20%) und diversen Nebenscripten:
    - Das Hauptscript wird vor der Implementation geschrieben und der Programmierer kann seine Funktionalität laufend prüfen.
    - Die Nebenskripte entstehen während und nach der Implementation und enthalten spezielle Konditionen, wie: ohne JavaScript, Validierungen von Extremwerten, Umgekehrte Reihenfolge etc.
    Nach jedem Release (also auch dann, wenn das Feature nicht verändert wurde), werden alle Haupskripte ausgeführt, und vor jedem grossen Release werden dann auch alle Nebenskripte getestet.

    Schlussendlich jedoch ist das Hauptproblem immer die Komplexität, und dieser ist selten mit Theorie beizukommen. Der Hauptfokus speziell bei komplexen und langfristigen Projekten sollte immer auf SIMPLIFICATION, der Reduktion von Komplexität liegen. Dies gilt insbesondere für die Methodik!

    Kommentiert am 12-Dez-07 um 4:52 pm | Permalink

34. Internet Briefing Blog / Einfache, komplizierte und komplexe Probleme in der Entwicklung schrieb:

    [...] sucht die goldene Antwort auf die Frage; “welches ist die richtige Entwicklungsmethode“. Die intensive Diskussion zeigt, die Frage stellen sich auch andere Mitglieder im Club. Ein [...]

    Kommentiert am 17-Dez-07 um 1:19 am | Permalink

35. Bloglinks am 20. Dezember « Cyrus Warrick - Blog schrieb:

    [...] Entwicklungsmethoden in der Praxis bei Internet Briefing Blog [...]

    Kommentiert am 20-Dez-07 um 6:30 pm | Permalink

36. Internet Briefing Blog / Das war das Internet Briefing 2007 schrieb:

    [...] Entwicklungsmethoden in der Praxis Mein Blog wieder ohne Werbung – dank Google [...]

    Kommentiert am 28-Dez-07 um 4:15 pm | Permalink

37. Internet Briefing Blog / Wie es Blogeinträge mit Diskussionen in die Zeitung schaffen schrieb:

    [...] Entwicklungsmethoden in der Praxis [...]

    Kommentiert am 30-Jan-08 um 2:18 pm | Permalink

38. DEMANDIT blog schrieb:

    Wie Blogs in den Medien stattfinden…

    In unserem Internet-Briefing-Blog fand kürzlich eine Diskussion zum Thema Entwicklung statt. Kurz darauf veröffentlichte die Computerworld den passenden Artikel dazu. Seite 1/Seite 2
    Clevere Journalisten werden in Zukunft Blogs für eine schnelle …

    Kommentiert am 03-Feb-08 um 10:57 pm | Permalink

39. Blogger Portraits – Reto Hartinger schrieb:

    [...] glaube es ist der über Outsourcing – er ist dann auch in der Computerworld [...]

    Kommentiert am 18-Jan-10 um 9:50 am | Permalink

Schreibe einen Kommentar