Schon mal was von SCRUM gehört?

Posted on 2012/02/05

Hier ist ein kleines FAQ über SCRUM:
(Alle Angaben ohne Gewähr auf Richtigkeit oder Vollständigkeit)

  1. Was ist SCRUM?
  2. Was sind „traditionelle“ Vorgehensmodelle?
  3. Was wird an klassischem Projektmanagement kritisiert?
  4. Was ist das agile Manifest?
  5. Was sind die Eigenschaften der agilen Methoden?
  6. Was ist der Unterschied zwischen User Storys und Use Cases?
  7. Was ist die „empirische Prozesssteuerung“?
  8. Was sind die Komponenten der empirischen Prozesssteuerung?
  9. Wie funktioniert SCRUM?
  10. Was sind die Rollen in SCRUM?
  11. Was sind die Aufgaben des Product Owners?
  12. Was sind die Aufgaben des SCRUM-Masters?
  13. Kann ein SCRUM Master auch Entwickler sein?
  14. Was sind die Aufgaben des Teams?
  15. Wie wird ein Team aufgebaut?
  16. Wie werden SCRUM-Meetings abgehalten?
  17. Wie läuft ein Sprint ab?
  18. Wann wird ein Sprint abgebrochen und was folgt?
  19. Wie lange dauert ein Sprint?
  20. Was ist ein Sprint Planning Meeting?
  21. Wann ist ein Produktinkrement fertig?
  22. Was ist ein Daily Scrum?
  23. Kann ein SCRUM Master für mehrere Teams zuständig sein?
  24. Was ist ein Sprint Review Meeting?
  25. Was ist ein Retrospektive Meeting?
  26. Was ist ein Release?
  27. Was ist ein Product Backlog?
  28. Was sind gute Anforderungen?
  29. Wie werden die Anforderungen priorisiert?
  30. Was ist eine User Story?
  31. Was ist ein Sprint Backlog?
  32. Was ist ein Sprint Burndown Diagramm?
  33. Was ist ein Burndown Diagramm?
  34. Warum ein ein Release-Plan?
  35. Wann wird der Release Plan erstellt?
  36. Wie wird ein Release Plan erstellt?
  37. Was ist ein Hindernisbericht?
  38. Was ist ein Sprint Endebericht?
  39. Grundlegendes zur Aufwandsschätzung:
  40. Was ist der Effekt der Retrospektiven Kohärenz?
  41. Was beeinflusst die Aufwandsschätzung?
  42. Wie ordnet man User Storys?
  43. Was sind Story Points?
  44. Unterschied „ideal“ und „elapsed“ time?
  45. Was ist Planning Poker?
  46. Wie produktiv ist mein Team?
  47. Gefahren für große, verteilte Projekte:
  48. Empfehlung für den Aufbau solch großer Projekte:
  49. Was ist der Unterschied von Komponenten Teams und Feature Teams?
  50. Umgang mit mehreren Product Ownern und SCRUM Master:
  51. SCRUM of SCRUMS:
  52. Wie berechne ich die Kosten für ein Projekt?
  53. Wie kann so ein Vertragsverhältnis zwischen Firmen entstehen?
  54. Was nützen agile Methoden und wann können sie eingesetzt werden?
  1. Was ist SCRUM? ↑
    • Vorgehensmodell und Kollektion von Arbeitstechniken, Rollen und Methoden für agiles Projektmanagement.
    • Wenig Vorschriften
    • Teams organisieren sich selbst und tragen Verantwortung
    • Das Vorgehen passt sich durch Retrospektive an
  2. Was sind „traditionelle“ Vorgehensmodelle? ↑
    • RUP
    • Prince2
    • V-Modell
  3. Was wird an klassischem Projektmanagement kritisiert? ↑
    • Anforderungsänderungen zu teuer
    • zu viel Bürokratie
    • zu spätes Kundenfeedback
    • Kunde bekommt nicht was er will, sondern was im Vertrag steht
    • „überzogene“ Designs
    • macht keinen Spaß, nicht Menschen gerecht, vernachlässigt Kompetenzen der Entwickler
    • zu teuer, schwierig, träge
  4. Was ist das agile Manifest? ↑
    • Individuen und Interaktionen wichtiger als Prozesse und Tools
    • Funktionierende Programme wichtiger als ausführliche Dokumentation
    • Stetige Zusammenarbeit mit dem Kunden steht über Verträge
    • Änderungen wichtiger als Festhalten am festgelegten Plan
  5. Was sind die Eigenschaften der agilen Methoden? ↑
    • Kunde ist Teil des Entwicklungsprozesses
    • Team ist für Ergebnis verantwortlich
    • Team organisiert sich selbst
    • Kommunikation statt Dokumentation
    • Kleine Teams 5-8 Personen
    • Team braucht gemeinsamen Raum
    • Inkrementelles, iteratives Vorgehen
  6. Was ist der Unterschied zwischen User Storys und Use Cases? ↑
    • User Storys sind kurze Beschreibungen der Funktionalität aus Sicht der Kunden. Kann Teil eines Use Cases sein. Für Planung verwendet. Schneller geschrieben. Leichter lesbar. Leichter zu warten. Abarbeitung in einer Iteration.
    • User Cases modellieren die Interaktion zwischen Nutzer und System. Viel detailierter. Enthält Diagramme.
  7. Was ist die „empirische Prozesssteuerung“? ↑
    • Wichtige Faktoren der Entwicklung sind extrem unberechenbar: zu entwickelnde Anforderungen, Zusammenarbeit, Interaktion mit den Menschen
    • Definierte Prozesssteuerung bezeichnet einen Prozess der stetig einen Qualitätsanspruch innerhalb definierter Grenzen erreicht. Kann dies aufgrund der Komplexität nicht erreicht werden, kommt die Empirische Prozesssteuerung zum Einsatz.
    • SCRUM verwendet die empirische Prozesssteuerung.
  8. Was sind die Komponenten der empirischen Prozesssteuerung? ↑
    • Sichtbarkeit: Keine Täuschungen und Fehlinterpretationen. Alles ist offen und transparent. Voraussetzung für Inspektion.
    • Inspektion: Zyklische Untersuchung, dass keine inakzeptablen Abweichungen entstehen.
    • Anpassung: Ständige Justierung des Prozesses, so dass innerhalb der Toleranz gearbeitet wird.
  9. Wie funktioniert SCRUM? ↑
    • Das Projekt wird in drei bis vierwöchige Iterationen (Sprints) unterteilt.
    • Am Beginn einer Iteration untersucht das Team welche Arbeiten durchzuführen sind.
    • Team sucht diejenigen aus, die sie bis zum Ende der Iteration fertig bringen können.
    • Team arbeitet autark und eigenverantwortlich.
    • Timeboxing: Wenn die Iteration endet, wird nicht mehr weiterentwickelt, egal ob die Arbeit fertiggestellt wurde oder nicht!
  10. Was sind die Rollen in SCRUM? ↑
    • Das Team entwickelt auslieferbare, fertige Produktinkremente, der Product Owner steuert das Projekt und der SCRUM Master stellt sicher, dass der Prozess reibungslos abläuft.
  11. Was sind die Aufgaben des Product Owners? ↑
    • Vertritt alle Stakeholder des Projekts
    • Verantwortung für das Product Backlog
    • Priorisiert die Anforderungen
    • Definiert Release Plan
    • Verantwortlich für die Wertmaximierung des Projekts
    • Verantwortlich für Budgetierung
    • Hilft dem Team die Anforderungen zu verstehen
    • Product Owner muss verfügbar sein.
    • Product Owner muss bevollmächtigt sein.
  12. Was sind die Aufgaben des SCRUM-Masters? ↑
    • Verantwortlich für den SCRUM Prozess
    • Fungiert als Coach und hilft SCRUM richtig einzusetzen
    • Fördert, schult und schützt das Team und beseitigt Hindernisse
    • Definiert Vorgehensweise, Meetings, Artefakte und Terminologie
    • Aktualisiert den Fortschritt des Teams und sorgt für Transparenz der Informationen
    • Stellt Zusammenarbeit von Team und Product Owner sicher
    • Ist nicht der Projektleiter (den gibt es nicht mehr)!
  13. Kann ein SCRUM Master auch Entwickler sein? ↑
    • Eher nicht, da seine Rolle ein Full Time Job ist.
    • Kann aber Commitment mit dem Team abgeben oder in Notfall mit entwickeln.
  14. Was sind die Aufgaben des Teams? ↑
    • Eigenschaften: Bevollmächtigt, autonom, eigenverantwortlich, selbst organisiert, interdisziplinär besetzt, klein (5-8 Personen)
    • Teamgröße kann sich nur zwischen den Sprints ändern.
    • Selbstständige Planung und Ausführung der Arbeit
    • Team muss sich selbst entwickeln, kann aber unterstützt werden.
  15. Wie wird ein Team aufgebaut? ↑
    • Forming: Teambildung
    • Storming: Erkennen und lösen von Konflikten
    • Norming: Aufgabenverteilung
    • Performing: Zusammenarbeit
    • Schlecht fürs Team: Fehlendes Vertrauen, Angst vor Konflikten, fehlendes Commitment, Kein Gesamtbild vor Augen
    • Erfolgsfaktor: Vertrauen und gegenseitiger Respekt
  16. Wie werden SCRUM-Meetings abgehalten? ↑
    • Teilnahme nur von den richtigen Personen
    • Genau definieren: Ziel des Meetings, Agenda, Dauer
    • Pünktlichkeit
    • Timebox
    • Retrospektive
    • Maximal 1-seiteges Protokoll
  17. Wie läuft ein Sprint ab? ↑
    • Sprint umfasst: Planning Meeting – Daily Scrum (wiederholend) – Review Meeting – Retrospective Meeting.
    • Sprintziel definieren.
  18. Wann wird ein Sprint abgebrochen und was folgt? ↑
    • Wenn ein Sprint nicht „überlebensfähig“ ist.
    • Product Owner oder SCRUM Master können Sprint abbrechen
    • Es folgt Sprint Retrospective Meeting.
    • Abbruch soll Ausnahme bleiben.
  19. Wie lange dauert ein Sprint? ↑
    • Dauer sollte ca. 30 Kalendertage umfassen.
    • Dauer ist abhängig von der Leistungsfähigkeit des Teams, Stillhaltens des Managements und des Kunden
  20. Was ist ein Sprint Planning Meeting? ↑
    • Teilnehmer: Product Owner, SCRUM Master, Team
    • Festlegung der zu leistenden Arbeit in der nächsten Iteration
    • Maximal 8h.
    • Aufteilung in zwei Teile
    • Erster Teil
      • Updaten des Product Backlogs: Prioritäten, Aufwand, Status
      • Definition des Sprint Ziels in Worten. Warum? Was?
      • Klärung der Product Backlog Anforderungen
      • Auswahl der Anforderungen durch das Team (Team Commitment)
    • Zweiter Teil:
      • Team plant Sprint voraus.
      • Planung der Aufgaben (nicht Anforderungen) im Sprint Backlog
  21. Wann ist ein Produktinkrement fertig? ↑
    • Es ist fertig wenn es
      • analysiert und designed
      • entwickelt und umgesetzt
      • refactored und reviewed
      • dokumentiert
      • lauffähig
      • getestet
      • Qualitätskriterien erfüllt und
      • auslieferbar ist.
  22. Was ist ein Daily Scrum? ↑
    • Daily SCRUM ist ein tägliches, 15 Minuten dauerndes Meeting des Teams und des SRCUM Masters (Product Owner optional)
    • Ziel: Synchronisation des Teams und der Aufgaben
      • Wer hat was gemacht?
      • Wer macht was bis zum nächsten Daily SCRUM?
      • Wer kann weiterhelfen?
      • Feedback?
      • ABER: Keine Diskussion, nur Vorstellung
    • Mitteilung von Hindernissen an den SRCUM Master
    • Timebox
    • Sprint Backlog und Burndown Diagramm müssen aktualisiert sein.
    • SCRUM Master redet i.d.R. nicht.
  23. Kann ein SCRUM Master für mehrere Teams zuständig sein? ↑
    • Am Anfang nicht, mit mehr Erfahrung dann ja (1-3 Teams)
  24. Was ist ein Sprint Review Meeting? ↑
    • Durchführung am Ende jedes Sprints
    • Timebox von 4h
    • Teilnehmer: Team, Product Owner, SCRUM Master, optional Stakeholder
    • Ziel:
      • Begutachten der Ergebnisse
      • Team präsentiert Ergebnisse (!) ->Verantwortung
      • Kontrolle, Transparenz
    • Vorbereitung:
      • Maximal 1h pro Entwickler
      • Keine PowerPoints sonder Live-Demo
      • Nicht fertig, nicht zeigen!
    • Ablauf:
      • Intro vom SCRUM Master
      • Sprint Erfahrungsbericht:
        • Was war das Ziel?
        • Was wurde erreicht?
        • Was nicht und warum?
        • Was wurde gelernt?
    • Live Demo:
      • Am besten am Entwicklerschreibtisch: Sauber Schreibtisch, Einblick in Entwicklung, Authentizität, positiver Effekt auf Kunden, mehr Vertrauen des Kunden
    • Abschluss:
      • Protokollierung. Rückfluss ins Product Backlog
      • Stakeholder geben Feedback!
  25. Was ist ein Retrospektive Meeting? ↑
    • Erfolgt zwischen Review und Planning Meeting
    • Timebox: 3-4h
    • Teilnehmer: Team, Product Owner, SCRUM Master
    • Ziel:
      • Was lief gut?
      • Was lief schlecht?
      • Was kann besser gemacht werden?
    • Steigerung der Produktivität und Qualität
    • Auswertung der Ergebnisse und Schlussfolgerungen
    • Betrachtung des Prozessverlaufs und der Beziehungen aller Beteiligten
  26. Was ist ein Release? ↑
    • Ein Release ist ein Software-Stand/Version die von Stakeholdern produktiv eingesetzt werden kann
    • Dauer eines Zyklus 13 Wochen
    • Der Release-Zyklus ermöglicht eine strategische Planung, da globale Aussagen getroffen werden können
  27. Was ist ein Product Backlog? ↑
    • Erstellt durch Product Owner
    • Enthält funktionale und nicht-funktionale Anforderungen nach Prioritäten sortiert
      • Priorisierung nach Kundennutzen: Wert, Abhängigkeiten, Nutzen
      • Wichtige Anforderungen sind detailierter zu beschreiben
      • Anforderungen werden geschätzt
      • Anforderungen werden nicht vollständig erfasst und nicht präzise spezifiziert (wie bei der klassischen Softwareentwicklung)
    • Lebendes Dokument: Neue Anforderungen werden aufgenommen, sie werden geändert, neu priorisiert und gelöscht (Aber nicht während dem Sprint!)
  28. Was sind gute Anforderungen? ↑
    • Einfach und verständlich formuliert
    • unabhängig von anderen Anforderungen
    • verhandelbar
    • nützlich
    • schätzbar
    • klein und überschaubar
    • testbar
    • Verhältnis: 1 Product Backlog Item entspricht 5 Sprint Backlog Items
  29. Wie werden die Anforderungen priorisiert? ↑
    • Nicht nur nach Nutzwert, sondern auch nach Informationsverfügbarkeit
    • „Wann willst du wissen, wann du ein Problem hast?“
    • Umsetzung der Spezifikation ist nicht gleich erfolgreiches Projekt.
    • Je höher die Priorisierung, desto höher die Wahrscheinlichkeit der Realisierung
  30. Was ist eine User Story? ↑
    • Beschreibung eines Szenarios aus Sicht des Anwenders
    • Stammt von Extreme Programming
    • „As a user <type of user>, I want <capability> so that <business value>“
    • Je besser die Entwickler die Anforderungen des Kunden verstehen, desto besser können sie die Arbeit umsetzen.
  31. Was ist ein Sprint Backlog? ↑
    • Enthalten die Aufgaben des Teams aus dem Product Backlog für diesen Sprint
    • Die Anforderungen werden in Aufgaben herunter gebrochen
    • Wird im zweiten Teil des Sprint Planning Meetings erstellt.
    • Planung für die durchzuführenden Aufgaben des Teams
    • Eine Aufgabe soll an einem Tag abarbeitbar sein
    • Es können mehrere Leute an einer Aufgabe arbeiten
    • Verantwortliche Entwickler sollen für die Aufgaben eingetragen werden
  32. Was ist ein Sprint Burndown Diagramm? ↑
    • Zeigt den Betrag des verbleibenden Arbeitsaufwandes über den gesamten Zeitraum im Sprint
    • Verhältnis zwischen Arbeitsaufwand und Fortschritt
    • Wird vom Team dokumentiert und gepflegt
  33. Was ist ein Burndown Diagramm? ↑
    • siehe Sprint Burndown Diagramm, nur über gesamten Projektzeitraum
  34. Warum ein Release-Plan? ↑
    • Erstellt von Product Owner, optional Team
    • Bessere Transparenz durch Zeit und Kostenrahmen
    • Ermöglicht vorausschauende Projektsteuerung
    • Optimale Arbeitsorganisation
    • Enthält:
      • Vision, Grund für das Projekt
      • Product Backlog
  35. Wann wird der Release Plan erstellt? ↑
    • Nach initialem Erstellen des Product Backlogs, inklusive Schätzung und ermittelten Risiken
    • Wenn die Entwicklungsgeschwindigkeit des Teams festgestellt wurde.
  36. Wie wird ein Release Plan erstellt? ↑
    • Zeitraum zur Umsetzung der Anforderungen bestimmen
    • Bestimmung der Reihenfolge anhand der Priorisierung
    • Festlegen der Releases
    • Aktualisierung am Ende jedes Sprints
  37. Was ist ein Hindernisbericht? ↑
    • Dokumentation aller aufgetretenen Hindernisse mit Datum und entsprechender Lösung und Datum der Beseitigung
  38. Was ist ein Sprint Endebericht? ↑
    • Es enthält für jeden Sprint die wichtigsten Daten des Sprints und dokumentiert die Anzahl der geplanten und der abgenommenen Anforderungen(durch Product Owner).
    • Erfassung v on:
      • Datum Sprint Anfang und Ende
      • Beteiligte Personen
      • Verfügbarkeit
      • Fehlzeiten
      • Für jede Anforderung:
        • Bezeichnung
        • Erbracht?
        • Abgenommen?
        • Beurteilung
        • Bemerkung
    • Geschwindigkeit
    • Metriken:
      • Sprint Burndown Diagramm
      • Hindernisbericht
      • Qualitätsmerkmale
  39. Grundlegendes zur Aufwandsschätzung: ↑
    • Menschen sind schlecht beim schätzen
    • Verwenden von relativen Zeiteinheiten
    • Skalierung funktioniert nicht und nicht linear
    • Eine Schätzung bleibt immer eine Schätzung!
    • Angst beeinflusst Schätzung
  40. Was ist der Effekt der Retrospektiven Kohärenz? ↑
    • Retrospektive Kohärenz bedeutet, dass sich in komplexen Systemen Ursache und Wirkung stetig entwickeln. Wir wissen auch am Ende warum, jedoch ist es sehr schwer, dies methodisch zu reproduzieren. Lösung: kurz anhalten, prüfen, anpassen, schauen ob die Richtung stimmt!
    • Die Schätzung dient daher nur als grober Anhaltspunkt für die Priorisierung und Einteilung der Sprints
  41. Was beeinflusst die Aufwandsschätzung? ↑
    • Projektgröße
    • Art der Software
    • Sprache
    • Personen
    • Erfahrung
  42. Wie ordnet man User Storys? ↑
    • 1. Hohes Risiko, hoher Wert
    • 2. Niedriges Risiko, hoher Wert,
    • 3. Niedriges Risiko, niedriger Wert
    • 4. Hohes Risiko, niedriger Wert
  43. Was sind Story Points? ↑
    • Numerischer Wert, der die relative Größe der Anforderung hinsichtlich Aufwand, Komplexität und Risiko der Anforderung zuordnet
    • Stellt den Komplexitätsunterschied der User Storys dar
    • Start: Die kleinste Story bekommt 1 Punkt
    • Werteskala z.B. Fibonacci Zahlen
    • Vorteile:
      • Relativer Vergleichswert
      • Fördern Team-Gedanken
      • Trennen Größenschätzung von Bearbeitungsdauer
      • einfach und schnell
  44. Unterschied „ideal“ und „elapsed“ time? ↑
    • Ideal time ist die komplette Arbeitszeit: 8h a day, 40 a week
    • elapsed time ist die effektive Arbeitszeit, ohne Emails und Meetings
  45. Was ist Planning Poker? ↑
    • Ein Spiel zum Schätzen der User Storys
    • Kombiniert die Methoden der Expertenschätzung, der Analogiemethode und Zerlegung.
    • effektiv, effizient
    • Ablauf:
      • Vorlesen der Story
      • Klärung der Fragen
      • Jeder schätzt für sich
      • Vergleich der Schätzungen
      • Bei Abweichung: kurze Diskussion, dann neue Schätzung
  46. Wie produktiv ist mein Team? ↑
    • Produktivität ist die Anzahl der Story Points die das Team in einer definierten Zeiteinheit umsetzt.
    • Anhand festgelegter Multiplikatoren können Best- und Worst Case Szenarien für die Produktivität berechnet werden.
  47. Gefahren für große, verteilte Projekte: ↑
    • Keine Identifizierung gemeinsamer Ziele
    • Kommunikationsprobleme
    • Zu hohe Erwartungen der Produktivität
    • Technische Probleme
  48. Empfehlung für den Aufbau solch großer Projekte: ↑
    • Ein Team muss Grundlagen für Vergrößerung und Verteilung schaffen. Betreffend Management und Entscheidungen und Infrastruktur .
    • Klärung der verteilten Organisation: verteilte SCRUM- Meetings und Rollen
    • Langsam wachsen: Erst alle 2-3 Sprints das Team vergrößern
    • Mit Produktivitätsdelle rechnen
  49. Was ist der Unterschied von Komponenten Teams und Feature Teams? ↑
    • Komponententeams (Benutzeroberfläche): Hohe Integrität, keine Code-Duplizierung, Team besteht aus Spezialisten, klare Verantwortung
    • Keine Anforderung kann vollständig vom Team bearbeitet werden, Fokussierung auf Subsystem, Probleme der Schnittstellendefinition, hoher Integritätsaufwand, nur so schnell wie das langsamste Team
    • Feature Teams: Setzen ganze Anforderungen um, interdisziplinär besetzt, unabhängig, einfache Integration
    • Integrität schwieriger, Teams müssen Interdisziplinär sein, langsame Entwicklungsgeschwindigkeit am Anfang
  50. Umgang mit mehreren Product Ownern und SCRUM Master: ↑
    • Jedes Team hat eigenen SCRUM-Master und Product Owner
    • SCRUM Master muss lokal verfügbar sein
    • Es bildet sich ein Team von Product Ownern inklusive Marketing und Vertriebsrepräsentanten, aus denen sich ein Chief Product Owner finden muss der die Gesamt Verantwortung trägt
    • Trotzdem nur ein Release Plan
    • Sprints können auch asynchron stattfinden
  51. SCRUM of SCRUMS: ↑
    • Analogie in Form von projektweiten DailyScrums:
      • Was hat mein Team erreicht?
      • Was wird mein Team bis zum nächsten SCRUM of SCRUMS erreichen?
      • Was sind die Hindernisse?
    • Moderation durch ChiefProductOwner
    • Feste Zeitdefinition, vor allem bei weltweiten Projekten
    • Protokollierung beugt Stille-Post Effekte vor
    • Personenaustausch an verschiedenen Standorten
  52. Wie berechne ich die Kosten für ein Projekt? ↑
    • SCRUM gibt hier nichts vor
    • Kein Requirements Prozess
    • Genauen Zeitplan erst am Ende des Planning Meetings des letzten Sprints
    • Seriöse Angebote sind nicht möglich!
  53. Wie kann so ein Vertragsverhältnis zwischen Firmen entstehen? ↑
    • Offenheit der Partner
    • Kunde bekommt bessere Qualität und genau das was er will
    • Flexibilität bringt Probleme: Mögliche Leerzeiten, schwieriger zu planen,
    • Lösung? Vereinbarung eines Basispakets (Gewissheit, dass davor nicht abgebrochen wird)
  54. Was nützen agile Methoden und wann können diese eingesetzt werden? ↑
    • Sparen richtig eingesetzt Kosten
    • Verkürzen Entwicklungszeit
    • Steigern Qualität
    • Motivierend fürs Team
    • Erfordern andere KULTUR
    • Können nicht immer eingesetzt werden:
      • große Teams
      • kritische Anforderungen
      • feste Verträge (Bund?)
    • Agilität wird häufig für Geschäftemacherei missbraucht: Vertriebsargument

What Others Are Saying

  1. Foo 2012/02/05 at 18:49

    Was für eine schöne Zusammenfassung :-)

  2. Bar 2012/02/05 at 21:32

    Ich finde Scrum of Scrums falsch

  3. bar 2012/02/06 at 08:40

    ganz toll!

  4. tural 2012/02/26 at 08:11

    “Kunde bekommt nicht was er will, sondern was im Vertrag steht”

    Vereinbart der Kunde im Vertrag nicht das, was er will?

  5. Patrick 2012/02/26 at 08:38

    Hallo tural,

    ja das ist nicht ganz eindeutig formuliert. Gemeint ist, dass der Kunde normalerweise ein Problem hat, bei dem er aber selber am Anfang eines Projekts meistens gar nicht genau weiß, wie die Lösung dazu aussieht (“was er will”). Der Kunde will, dass sein Problem gelöst wird und nicht das “was im Vertrag steht” (evtl. weiß er ja auch nicht was technisch möglich ist oder das es bereits Lösungen auf dem Markt gibt).

    Grüße,
    Patrick

  6. Diethmar 2012/03/01 at 15:14

    Hallo,
    ich bin eigentlich eher durch Zufall auf Ihre Seite gekommen. Nachdem ich mich ein wenig durchgelesen habe, muss ich sagen Ihre Seite gefällt mir sehr. Ich werde in Zukunft öfters mal vorbei schauen!

    Viele Grüße aus Sinsheim

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>