Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
35 Cards in this Set
- Front
- Back
- 3rd side (hint)
|
"Gründe für Einführung von inkrementeller Entwicklung"
|
"Prüfung: Requirements/Spezifikationen passend zu Unternehmenszielen?
Problem: Betriebsblindheit der Projektteilnehmer durch Spezifikation * durch Experten - Verfügbarkeit, Kosten, ""Notwendigkeit"" Fehler zu finden * durch phasenorientierte Implementierung - Ergebnisse erst nach langer Zeit sichtbar, teure Fehlversuche, Requirements Drift während Entwicklung unberücksichtigt Lösung: Prüfung durch inkrementelle Entwicklung" |
""
|
|
|
"Wie funktioniert Scrum im allgemeinen?"
|
"Aus dem **Product Backlog** werden User Stories für den **Sprint Backlog** ausgewählt. Diese werden in einem **Sprint** realisiert. Zusätzlich gibt es täglich ein 15-minütiges **Daily Scrum**.
Nach jedem **Sprint** gibt es eine Retrospektive, in der der letzte Sprint betrachtet wird, um daraus Erkenntnisse für den nächsten Sprint zu gewinnen. Am Ende eines jeden Sprints steht ein Stück lauffähige Software." |
""
|
|
|
"Wie funktioniert die Entwicklung bei Scrum?"
|
"Aus dem **Sprint Backlog** werden User Stories in konkrete Tasks ausgeführt, die dann umgesetzt werden. Am sogenannten **Planning Board** kann jederzeit jeder Entwickler einsehen, welche Aufgaben zugeteilt, in Bearbeitung oder abgeschlossen sind."
|
""
|
|
|
"Woraus besteht ein Daily Scrum?"
|
* Was habe ich seit dem letzten DS getan?
* Was werde ich bis zum nächsten DS tun? * Was behindert mich? * 15 Minuten, stehend, freihändig, fester Zeitpunkt * keine Diskussion * vom Scrum Master geleitet " |
""
|
|
|
"Woraus bestehen Review und Retrospektive am Ende eines Sprints?"
|
"**Review**
* Vorführung Ergebnis des Sprints (lauffähige Software) * Prüfung durch Kunden * Änderungen im Product Backlog dokumentieren * Unerledigte Anforderungen zurück ins PB **Retrospektive** * Feedback zum Prozess (nicht zum Produkt) * wichtige Ereignisse während des Sprints notieren -> Gruppierung und Bewertung (gut/schlecht) * Lösung für bessere Organisation entwickeln |
|
|
|
"Was ist eine User Story?"
|
"Karte (ursprünglich Papier), die ein Feature der Software darstellt.
Inhalt: Titel, [Nummer], Beschreibung, Ansprechpartner, [Priorität][Schätzung] Umfang: Gerade so detailliert, dass Schätzung möglich ist Schema der Beschreibung: <Aktion> |
|
|
|
"Was ist ein Use Case?"
|
"Diagrammtyp aus der UML.
High-Level-Beschreibung eines einzelnen Systems aus Nutzersicht * Welche Funktionen bietet das System seinen Nutzern und Nachbarsystemen? * Wie unterstützt das System die Geschäftsprozesse? Keine Implementierungsdetails oder detaillierten Datenflüsse! " |
""
|
|
|
"Welchen Nachteil hat ein Festpreisprojekt?"
|
* Kunde will Festpreis, weiß aber nicht genau, was das fertige Produkt genau können soll
* Erstmal wird spezifiziert, eine vollständige Spezifikation ist weder sinnvoll noch wirtschaftlich * Entweder ist Festpreis-Dienstleister unglücklich oder kassiert mit Change Requests ab -> keine nachhaltige Kundenbeziehung |
|
|
|
"Wie können Festpreisprojekte um agile Methoden erweitert werden?"
|
* Initiale Benennung von Anforderungen als User Stories (daraufhin double blind Budget-Schätzung)
* Für jeden Sprint relevante Features werden detaillierter beschrieben * Ergebnis: Frühe lauffähige, aber nicht vollständige Version |
""
|
|
|
"Welche Regeln gelten für einen Sprint?"
|
* Fixer Umfang
* Umpriorisierung zwischen Sprints möglich, auch neue Anforderungen * Fortlaufende Kontrolle über die Projektziele auf Seiten des Kunden |
""
|
|
|
"Inwiefern findet sich der Festpreis in agiler Vorgehensweise wider?"
|
* Aus Schätzung der User Stories einzeln, des Zielbudgets und des Zieltermins wird priorisiert und aufsummiert ->
kein fester Preis, aber Orientierungspunkt * Orientierungspunkte (Aufwandssumme und Zieltermin) konstant transparent gemacht * Änderung von User Stories immer mit Blick auf OP -> |
|
|
|
"Inwieweit ist die Wertorientierung berücksichtigt?"
|
* Nutzen einer SW ergibt sich aus Aufwänden für Entwicklung/Betrieb & qualitativen Veränderungen in Geschäftsprozessen
* User Stories erzwingen zielgerichtete Auseinandersetzung (einzelne überschaubare Teilprozesse) * Ständige Priorisierung bewirkt konstante Ausrichtung am Nutzen * Durch Risikoverteilung wird auch Dienstleister am Nutzen ausgerichtet |
""
|
|
|
"Welche Besonderheiten umfasst die ""kommerzielle agile Entwicklung""?"
|
* Niedrig priorisierte Req. werden spät spezifiziert und vllt. weggelassen (->
kein unnötige Spezifikationsaufwand) * Jederzeit neue Stories möglich * Kunde kann jederzeit aussteigen, wenn zufrieden * Schlanke Lösung für Dienstleister * Vertrauensvoller Umgang zwischen Kunde/Dienstleister notwendig * Einigkeit über gemeinsame Risiken * Wirtschaftliches Risiko wird verteilt |
|
|
|
"Wie kann das agile Vorgehen abgerechnet werden?"
|
* Am Ende jeder Iteration
* Abnahme pro User Story (qualitätsgerecht geliefert?) * Normaler Tagessatz innerhalb von Schätzung, niedrigerer Tagessatz für Fehlerbehebung, Overspend * Feste Deadline pro Sprint * Grundpauschale für ständige, administrative Tätigkeiten * Abbruch nach jeder Iteration möglich oder Definition von nächster Iteration |
""
|
|
|
"Was muss man bei Schätzungen beachten?"
|
* Gefühlte Sicherheit deutlich höher als tatsächliche (kein ""bin mir zu 90% sicher"")
* Keine Spontanschätzungen, da immer geraten - besser diskutieren * Bewusste Bandbreite wählen, die Unsicherheit widerspiegelt |
""
|
|
|
"Was bedeuten Ziel, Schätzung, Zusage und Plan?"
|
* Ziel: Fixwert durch externe Faktoren (Budget, Deadline, ...)
* Schätzung: Vorläufige Vorhersage eines künftigen Wertes/Wertebereichs * Zusage: Festlegung auf einen künftigen Fixwert * Plan: Vorgehensvereinbarung, um Zusage zu erreichen |
""
|
|
|
"Unter- oder Überschätzung? Was ist besser und wie ist die Realität?"
|
"Überschätzung besser, da Mehraufwand ...
* niedriger als bei Unterschätzung * durch erforderliche Arbeit begrenzt * durch Projektmanagement handhabbar Problem in Realität: Schätzungen meistens 20-30% zu optimistisch * Übersehene funktionale und nicht-funktionale Anforderungen * Übersehene Entwicklungsaktitvitäten (Einarbeitung, Konfigurationsmanagement, ...) * Übersehene andere Aktivitäten (Urlaub, Krankheit, ...) |
""
|
|
|
"Inwiefern lässt sich ein Projektplan verkürzen?"
|
"Ohne Weglassen von Features nicht. Verkürzung (d.h. Erhöhung der Teamgröße) steigert den Aufwand, aufgrund von
* höherem Einarbeitungs-/Koordinationsaufwand * größerem Potential von Missverständnissen * zu wenig parallelisierbare Aufgaben Verlängerung (d.h. Reduzierung Teamgröße) sehr wohl möglich: * geringerer Kommunikationsaufwand * stärkere Sequenzialisierung ->frühere Fehlererkennung -> |
|
|
|
"Welche Vorteile bieten genaue Schätzungen?"
|
* Referenzwerte
* höhere Qualität durch weniger Stress * bessere Kooperation mit Plänen anderer Geschäftsbereiche * finanzielle Sicherheit * kompetenteres Image der Entwickler * frühe Risikowarnung bei Divergenz Ziel< |
->
|
|
|
"Welche Unsicherheiten gibt es?"
|
* Unscharfe Infos über Projekt
* Unscharfe Infos über Fähigkeiten der ausführenden Personen * Ständige Veränderung (Ziele, Rahmenbedingungen, Stakeholder, ...) * in der Methodik begründete Unschärfen |
""
|
|
|
"Was ist der Cone of Uncertainty?"
|
"Besagt die Schwankung der Schätzung während des Projektverlaufs. Diese ist anfangs sehr groß (zwischen 25-400%) und wird über die vollständigen Anforderungen (67%-150%) bis zum detaillierten Design (90%-110%) immer schmaler.
Dies allerdings nicht von alleine, Quellen der Unsicherheit müssen aktiv beseitigt werden." |
""
|
|
|
"Wie wird mit Unsicherheit in agilen Projekten umgegangen?"
|
* Regelmäßige Überprüfungen der Richtung
* Anfangs großer Entscheidungsspielraum, der nach und nach eingeschränkt wird * Unschärfe wird im Projektverlauf verringert |
""
|
|
|
"Welche Unterschiede bestehen zwischen phasenorientierer und agiler Herangehensweise bzgl. Schätzung/Zeitplanung?"
|
"Bei traditioneller Herangehensweise sind Features festgelegt, der Aufwand der Phase wird geschätzt und ein Zeitplan festgelegt.
Bei agiler Heransgehensweise hingegen wird der Zeitplan festgelegt, dann der Aufwand der Features geschätzt und somit der Inhalt des nächsten Zeitabschnitts festgelegt." |
""
|
|
|
"Wie ist die grundsätzliche Vorgehensweise beim Feature Driven Development (FDD)?"
|
"Über eine Zeit von max. 6 Monaten wird in den //ersten 2-3 Wochen// zunächst
*ein Gesamt-Modell erstellt, *daraus eine Feature-Liste, * daraus ein Plan je Feature. Jedes Feature wird dann in //je zwei Wochen// entworfen und entwickelt. FDD ist geeignet für eine Teamgröße von 10-50 Personen." |
""
|
|
|
"Welche Feedbackschleifen existieren in agilen Methoden und welche Fragen beantworten sie?"
|
"{
* **Sprint, Daily Scrum:** Entwickeln wir die richtigen Dinge? * **CI, Unit Testing, Pair Programming:** Entwickeln wir Dinge richtig? * **Planning Board:** Durchschnittlicher Durchsatz und Flaschenhälse }" |
""
|
|
|
"Was sind die 5 zentralen Werte des XP?"
|
* Kommunikation: Ständiger Austausch, Akzeptanz unterschiedlicher Meinungen
* Einfachheit: einfachste Lösung wird realisiert * Feedback: durch (1) gibt es Feedback zu Fortschritt und Akzeptanz der Ergebnisse * Mut: offene Kommunikation erfordert Mut, explizite Benennung eines ""Sprechers"" der alle ""Beschwerden"" weitergibt * Respekt: auch Nicht-Experten kommen zu Wort, unterschiedliche Meinungen werden akzeptiert |
""
|
|
|
"Welche Prinzipien gibt es beim XP?"
|
* Menschlichkeit
* Wirtschaftlichkeit * Beidseitiger Vorteil * Selbstgleichheit * Verbesserungen * Vielfältigkeit * Reflexion * Lauffähigkeit & kontinuierlicher Projektfortschritt * Gelegenheiten wahrnehmen * Redundanzen vermeiden * Fehlschläge hinnehmen * Qualität * Kleine Schritte * Akzeptierte Verantwortung |
""
|
|
|
"Welchen Zweck erfüllen die XP-Praktiken?"
|
* Konkrete Maßnahmen aus Werten und Prinzipien abgeleitet
* ""Best Practices"" * kein Allheilmittel, müssen angepasst werden * sind nicht notwendigerweise neu * scheinen trivial und werden unterschätzt * einige gehören mittlerweile zum ""guten Ton"", nicht nur in XP-Projekten Beispiel: TDD, einfaches Design, CI, kleine Iterationen" |
""
|
|
|
"Wie ist das grundsätzliche Vorgehen bei Test-driven Development (TDD)?"
|
* Testfall erstellen
* Testfall schlägt fehl * Feature programmieren * alle Testfälle erfolgreiche * Refactoring * Testfälle bleiben erfolgreich * s. (1) |
""
|
|
|
"Was ist Test-driven Development im Allgemeinen?"
|
* 2003 von Kent Beck entwickelt
* Grundkonzept aus XP * Testfälle als ausführbarer Code * Möglichst kleine Verbesserungen sind Teil jedes Tests * Testfall wird minimal gelöst * Keine Funktionalität ohne Testfall |
""
|
|
|
"Wie sind Testfälle organisiert?"
|
"In Cases und Suites.
* Pro Applikationsklasse eine Testklasse * Unterschiedliche Fixtures: Aufteilung nach gemeinsamer Fixture-Nutzung * Tests von mehreren A-Klassen werden ausgelagert in eigene T-Klassen Testklassen werden in Suites gruppiert (pro Package eine Testsuite), diese wiederum in eine übergeordnete Suite." |
""
|
|
|
"Welche Granularität ist für Testfälle empfehlenswert?"
|
* Es werden nur public-Methoden getestet. Nichts was funktionieren ""muss"" wird getestet, bspw. Getter/Setter.
* Es wird nur Funktionalität getestet, nicht explizit nach Methoden (nicht notwendigerweise disjunkt). * Es werden typische Situationen getestet, sowie orthogonal (d.h. andere Tests werden als korrekt vorausgesetzt) |
""
|
|
|
"Was muss man bei Testfällen für verteilte Systeme beachten?"
|
* Laufzeitumgebung zur Entwicklungszeit unbekannt
* Verhalten von Nachbarsystemen unsicher * Verhalten der Infrastruktur unsicher * Komplexe Abhängigkeiten schlecht für Unit Testing |
""
|
|
|
"Was muss man bei Testfällen für mobile Systeme beachten?"
|
* Kontext um Größenordnungen komplexer
* Sprunghafte Kontextveränderungen * Unzuverlässige Emulatoren * Automatisierung schwierig |
""
|
|
|
"Was beschreibt das Organizational Pattern?"
|
"?????"
|
""
|
