🤦 👵🏾 📝 Sammlung von Anforderungen für ein Softwareprojekt

Entwicklung ... es ist wie eine Droge - sie schreiben ein System, sie schreiben es, weil es schnell geht. Und dann stellt sich plötzlich heraus, dass „Unterhalt“ bezahlt werden muss. Und jede Änderung im System führt zu einem Berg von Fehlern. Aber schon zu Beginn des letzten Jahrhunderts hat der große Kurt Gödel dies vorausgesehen und strikt bewiesen, dass wir selbst in der Arithmetik nicht genug Intelligenz haben, um alle seine Gesetze ohne Widersprüche auszudrücken. Und beim Programmieren und noch mehr - wir werden anfangen, auf unsere Füße zu treten und verwirrt zu werden. Was im Allgemeinen passiert: Entweder schaltet sich der Laptop ein und startet nachts neu, dann machen mobile Anwendungen Fehler, so dass sie aus der Tasche fallen und sich zerstreuen, schimpfen und auf dem Boden quietschen.

Und wie gefällt dir die modische Beta-Version von allem und jedem jetzt? Bald werden die Flugzeuge anscheinend in Alpha-Beta-Versionen erscheinen.

Aber Sie können fehlerfrei programmieren, damit sich die Seele freut und es nicht nur angenehm ist, mit dem Kunden Bier zu trinken, sondern auch sicher!

In dieser Reihe von Veröffentlichungen zu verschiedenen Aspekten der Softwareentwicklung werde ich versuchen, einen minimalistischen Satz von Werten und Regeln zu erstellen, die zum einen im Kopf einer durchschnittlichen Person stehen und zum anderen normalerweise ... mit dem geringsten Aufwand und der geringsten Zeit gewinnen können. Lassen Sie uns heute offen über das Sammeln von Anforderungen für ein Softwaresystem sprechen.

Theater, Theater überall. Aber die Softwareentwicklungsbranche wird zweifellos davon profitieren, wenn alle Teilnehmer des Prozesses die Wahrheit sagen, erstens zu sich selbst, und zweitens wird niemand unsystematische Emotionen und Dienste für Cthulhu unterstützen.

Sie müssen nicht weit gehen, um Beispiele zu finden - offene Entwicklungsmodelle und ihr Erfolg (nicht unbedingt gemeinnützig) zeigen überzeugend:

Klarheit, Offenheit, Mut
Diskussion mit Community und Client
schnelle Problemidentifikation und -lösung

sowie die fairste Kommunikation, die auf Vertrauen und gegenseitigem Respekt basiert - führen Sie eine Softwarelösung, zum Beispiel eine Website, zum Erfolg.

Die Welt verändert sich aktiv. Horizontale Kommunikation findet mit Lichtgeschwindigkeit statt, und wenn wir nicht lernen, wie man diese neue Waffe benutzt, werden wir definitiv verlieren. Aber schauen Sie sich zuerst um.

Woher kamen die „heiligen Kriege“ in der Programmierung?

Alles ist einfach. Es reicht aus, sich an den Schulkurs der Geometrie zu erinnern. Das wissenschaftliche Verständnis der Welt, in der wir leben, basiert auf ... dem Glauben an "unveränderliche Wahrheiten" = Axiome, zum Beispiel, dass "parallele Linien sich nicht schneiden" oder an der Anzahl der Primzahlen in einem Bereich (obwohl dies ein Satz ist, aber es der Hund arbeitet, aber niemand versteht warum).

Es ist unmöglich, das Axiom zu beweisen, es bleibt nur zu glauben, dass es immer funktioniert. Wir können jedoch nicht zum Ereignishorizont des Schwarzen Lochs fliegen und nachsehen. Und erklären Sie, warum die Wechselwirkung zwischen Photonen auch viel schneller als die Lichtgeschwindigkeit übertragen wird .

Zahlreiche wissenschaftliche Theorien verwenden Axiome für die logische Schlussfolgerung von Theoremen, und so weiter und so werden dicke Bücher mit einer bestimmten Garantiezeit geboren. Infolgedessen, und das ist nicht mehr lustig, wurde Fermats großer Satz in den neunziger Jahren so bewiesen , dass nur eine Handvoll von Personen mit einer ausgezeichneten Sonderausbildung den Beweis verstehen kann, der in der Lage ist, Dutzende Seiten eines feinen Textes mit Formeln unter dem Mikroskop zu schaufeln :-) Deshalb fahren sie fort Suche nach "echten", einfachen und schönen Beweisen.

Selbst in scheinbar einfacheren, arithmetischeren Versuchen wurde wiederholt versucht, die Axiome in Ordnung zu bringen - aber die Dinge sind immer noch da ...

In ähnlicher Weise stellen die Programmiersprachen und -technologien, auf denen wir Websites, mobile Anwendungen und Informationssysteme erstellen, auch eine Reihe von Axiomen oder Referenzpunkten dar, an die Sie zuerst „glauben“ müssen und auf denen die Grundlage der Technologie aufgebaut ist. Es ist jedoch unmöglich zu beweisen, dass sie wahr sind (obwohl es manchmal immer noch möglich ist: Versuchen Sie, eine Website in C ++ zu schreiben, und sehen Sie, wie viel Zeit und Geld Sie verlieren).

In der Welt von Java / C # und anderen maßgeblichen und seriösen, modernen, stark typisierten Sprachen mit statischer Typisierung müssen Sie beispielsweise nur annehmen und "glauben", dass die Welt aus Psychopathen besteht, die zu Gewalt und Verlust der Selbstidentifikation neigen, und daher eine Reihe von Axiomen. tut alles, um den Entwickler nicht nur vor Kollegen, sondern auch vor sich selbst zu schützen (natürlich scherze ich).

Das Ergebnis sind Softwaresysteme, die seit langem aus Eisen und Beton hergestellt werden und dann mit Hunderten von Autotests abgedeckt werden. Infolgedessen kann sich herausstellen, dass die Geschäftsanforderungen zum Zeitpunkt des Abschlusses der Bauarbeiten längst veraltet sind, Atomwaffen verboten sind und ein Bunker mit 100-Meter-Wänden zerstört wird sofort ins Museum. Aber oft funktioniert eine solche Wahrnehmung der Welt gut, zum Beispiel bei der Entwicklung eng spezialisierter Systeme oder wenn die Fehlerkosten sehr hoch sind (Banken usw.).

In der Welt der dynamischen Sprachen mit strenger / nicht strenger Typisierung (PHP, JavaScript, Python, Ruby) ist die Menge der Axiome perfekt, vom Wort „vollständig“ bis zum anderen:

Wir sind umgeben von klugen Leuten, die sofort richtig und ordentlich schreiben
Verfolgungswahn (Ändern des Typs einer Variablen unterhalb der Liste, Zugriff auf versteckte Klassenmitglieder durch einen anderen Entwickler mit „böswilliger“ Absicht, vorausschauendes tiefgreifendes Code-Refactoring usw.) - eine Krankheit, die Sie versuchen müssen, schnell wiederherzustellen
Hardware wird immer billiger, daher müssen Sie das Programm nur in Teilen kompilieren und dann, falls erforderlich
Je mehr Code, desto mehr Fehler. Der Code sollte daher sofort gut lesbar, klar, präzise und sexy sein

In der Welt der funktionalen Sprachen wie Haskell / OCaml müssen Sie Folgendes glauben:

Jede Aufgabe kann durch Funktion ausgedrückt werden
Variablen, Zyklen und Veränderlichkeit - führt zu Fehlern (das ist eigentlich so)
Programmierung - für Auserwählte und zum analytischen Denken geneigt

Daher beginnt anstelle einfacher Krückenskripte, die „erstellt, überprüft, entschieden und vergessen“ wurden, echte wissenschaftliche Arbeit am Arbeitsplatz, und die Suche nach den „Funktionen Gottes“ ist sehr interessant, um die Website auszudrücken ... mit einer Reihe von Funktionen ohne Variablen, wow!

Natürlich übertreibe ich, aber ohne Feuer gibt es keinen Rauch. Obwohl dieser Ansatz bei einigen Aufgaben einwandfrei funktioniert und niemand einen besseren Ansatz gefunden hat.

"Kreuzzüge" bei der Verwaltung von Softwareprojekten

Im Bereich des Projektmanagements ist die Situation noch stärker von pseudowissenschaftlicher Dunkelheit bedeckt. Und der Grund ist bekannt: eine offensichtliche, auf der Oberfläche liegende, einfache und prägnante Lösung für die Stirn:

verstehen, was der Kunde will
ziehen Sie Spezialisten an und bewerten Sie den Arbeitsaufwand
Code schreiben

in Wirklichkeit funktioniert es aus irgendeinem Grund nicht :-)

Erfahrene Teilnehmer in den Projektteams sind sich bewusst, dass der Kunde oft, kitschig, nicht weiß, was er will, weil er von Emotionen überwältigt ist und mathematische Probleme in der Schule kopiert, was schließlich zu einer teilweisen „Atrophie des Teils des Gehirns“ führte, der für den logisch konsistenten Ausdruck seines Gehirns verantwortlich ist Gedanken. Mit poetischen Opussen, Lippenstiftzeichnungen und Noten von Gitarrenakkorden anstelle von technischen Anforderungen für die Website erhöhen Spezialisten, die weinen, um nicht über Impotenz zu lachen, die Schätzungen des Arbeitsaufwands um eine Größenordnung, führen eine Steuer für Unzulänglichkeiten ein und so weiter.

Verzeihen Sie mir unter diesen Bedingungen des Mangels an strenger Logik und Begierde, indem Sie meinen Kopf für den beabsichtigten Zweck verwenden, als ob es sprunghaft zu schrecklichen unwissenschaftlichen Missbräuchen im Stil von Astrologie / Numerologie / Pranyozhenie und Wahrsagerei auf Kaffeesatz kommt.

Missbräuche werden normalerweise von sehr selbstbewussten Menschen aktiv ausgenutzt, die gut überzeugen können und die den „Code“ nie hatten (ja, ich spreche von der falschen Agilität).

Sie sagen, dass in einigen Teams vor dem Sprint selbst die leidenschaftlichsten Fans uns Ingenieure zur Urintherapie zwingen, entschuldigen Sie mich :-) Diese „Praktiken“ selbst werden jedoch oft von sehr erfahrenen Entwicklern erstellt, die sie wie kein anderer richtig anwenden können.

Hier gefällt mir die Analogie mit den Nunchakus sehr gut - es scheint eine einfache Waffe zu sein, aber nur wenige können sie richtig einsetzen und die meisten werden verletzt. Tut mir leid, Sie wissen, was Sie selbst sind.

Ein weiterer Mythos ist die Austauschbarkeit

Manchmal versuchen sie uns von der Austauschbarkeit der Ingenieure zu überzeugen. Es ist bekannt, dass Sie, um ein gutes und tiefes Verständnis der Softwaretechnologie zu erlangen, viele Bücher erneut lesen, Dutzende von Kursen anhören , mehrere hundert Probleme lösen und an fünf Softwareprojekten teilnehmen müssen, von denen mindestens eines die Ziellinie erreicht hat. Als nächstes beginnt das Experiment, das nach mindestens 5 Jahren den Encoder - Specialist macht.

Normalerweise arbeitet der Entwickler ständig an Projekten und spricht fließend eine oder zwei Programmiersprachen und verwandte Technologien. Der Erfolg und das berufliche Wachstum eines Ingenieurs liegt gerade in seiner engen Spezialisierung, weil Zusätzlich zu den Sprachen selbst ist es notwendig, sich eingehend mit Systembibliotheken zu befassen, die oft sehr zahlreich sind und deren Dokumentation sehr umfangreich ist.

Das Problem ist, dass es aus irgendeinem Grund in Mode ist, keine Bücher zu lesen, sondern sie zu googeln und abzuschreiben, ohne das Gehirn einzubeziehen, während man in sozialen Netzwerken und Smartphone-Benachrichtigungen mental masturbiert.

Es wird immer schwieriger, einen echten Spezialisten zu finden, der langsam aber sicher systematisch von unten nach oben lernt und die Lücken in seinem eigenen Wissen schließt. Der Markt ist leider voller "Autodidakten" mit ... "verwöhnten Händen".

Was tun? Empfohlene Überlebenswerte

Erstens besteht kein Grund zur Verzweiflung und es ist sehr wichtig, sich keinen Emotionen hinzugeben. Es ist wichtig zu verstehen, dass Entwicklung in erster Linie strenge Mathematik (normalerweise auf Schulebene) und Logik mit Metriken ist, bei denen Sie mit Terver und Intuition mit vorrangigen Risiken und „nassen“ Chefs im Kindesalter umgehen müssen.

Früher haben wir Online-Spiele gespielt und es hat gut geklappt - also mach weiter, nur anstelle von Chefs hast du Softwareprojekte und statt Bugs - zerg!

Es ist immer möglich und notwendig, Risiken nüchtern zu managen, und erfahrungsgemäß startet ein Softwareprojekt, wenn es „systematisch und wissenschaftlich“ durchgeführt wird, entweder pünktlich oder es wird schnell klar, warum die Rakete nicht startet und was / wen, speziell das Problem.

In Anbetracht des Vorstehenden wird empfohlen, sich an die folgenden Werte des eng wissenschaftlich-empirischen Ansatzes zu halten, die sich eng mit der bekannten Hymne an den gesunden Menschenverstand überschneiden - " Python Zen " und " Agiles Manifest ":

Suchen Sie nach der einfachsten und klarsten Lösung
Je klarer desto korrekter
Es wurde schwierig - es bedeutet irgendwo einen Pfosten und Sie müssen weiter suchen
Arroganz - aus Unsicherheit oder einer schwierigen Kindheit
Die Fähigkeiten des menschlichen Gehirns sind begrenzt, insbesondere unter dem Einfluss von Hormonen und in einigen Zeiträumen sogar
Von Alkohol und Rauchen - wir werden intensiv langweilig
Wir neigen dazu, selbst das, was wir gut und in jüngerer Zeit wussten, schnell zu vergessen
Streben Sie nach maximaler Transparenz und Offenheit
Respektiere einander
Ermutigen Sie den schnellstmöglichen Aufstieg und die Diskussion von Problemen im größtmöglichen Kreis - idealerweise sofort
Ziehen Sie Schlussfolgerungen und treten Sie nicht 3,14 Mal hintereinander auf den Rechen :-)

Anforderungserfassung

Nachdem wir einige Geheimnisse und Merkmale von Trends in der Softwareentwicklung kennengelernt haben, werden wir sicher weitermachen - wir werden lernen, wie man die Anforderungen an das System richtig zusammenstellt.

Kann der Kunde grundsätzlich denken?

Nichts lustiges - es ist immer noch eine normale Situation. Und der Kunde ist in diesem Zusammenhang ein kollektives Konzept. Versuchen Sie zunächst, das Niveau des logischen Denkens und die Fähigkeit zur Konzentration der Kundenvertreter zu bewerten. Mit wem wirst du arbeiten und wer wird dir helfen? Mögliche Optionen:

Politische Partei. Es ist zum Beispiel notwendig, ein Webprojekt bis zum Datum zu erstellen, weil jemand etwas will / versprochen hat ... Die Anforderungen sind vage, niemand kennt die Details und wer wusste - wird vor langer Zeit aufhören. Das Projekt wurde von einem Team gesägt, das gegangen war, und es war fast unmöglich zu verstehen, was sie sahen. An den Wänden - getrocknete Gehirne, möglicherweise vom Selbstmord eines führenden Programmierers. Der Code ist schlecht und zerbrechlich, er riecht so, dass es deine Augen verletzt. In einer solchen Situation versuchen sie oft, das „heilige Opfer“ zu finden, entschuldigen Sie mich, das für die nächsten sechs Monate verantwortlich gemacht werden kann, und ... suchen nach einem neuen. Angstgefühl, Depression und Unterdrückung der Offenheit des Prozesses mit einer Beimischung von Blut auf den Lippen. Die Wahrscheinlichkeit, eine Softwarelösung rechtzeitig zu erstellen, ist zwar gering, aber immer noch vorhanden - wenn Sie dies erneut auf einem vorgefertigten Framework mit vorgefertigter Dokumentation tun. Normalerweise der einzige Weg und kein anderer Weg.
Sie kommunizieren mit Kundenvertretern und verstehen, dass es für Menschen aufrichtig schwierig ist, ihre eigenen Gedanken, die nach dem dritten Satz verwirrt sind, konsequent / formal auszudrücken, zu wiederholen und sich im Kreis zu bewegen. Nach 15 Minuten Dialog beginnen Beschwerden über Kopfschmerzen. Gelächter ist zu hören, die Atmosphäre der Party, das Selfie, das Leben war erfolgreich ... Aber die Wünsche sind im Allgemeinen verständlich und aufrichtig - Sie müssen ihnen nur ein bisschen helfen, um genau zu erkennen. Die Wahrscheinlichkeit eines Starts ist hier normalerweise höher als in Absatz 1, aber auch hier hilft normalerweise die Verwendung der am besten vorgefertigten Box-Lösung mit vorgefertigter Dokumentation und typischen Szenarien.
Der Kunde versteht gut, was er will und versucht, seine eigenen Gedanken und Wünsche logisch und konsequent auszudrücken. Dabei hilft ihm ein nicht verwirrter Analytiker, der die Gedanken des Managements darlegt und als seine eigenen ausgibt. Das Kundenteam hat auch mindestens einen Experten in seinem Fachgebiet (lustig, aber dies ist immer noch eine ziemlich seltene Situation). In diesem Fall ist die Wahrscheinlichkeit, das Problem programmgesteuert zu unterstützen und zu lösen, sehr hoch. Hier können Sie sich an der Gestaltung, gemeinsamen Diskussion des Glossars, von Objektmodellen, Datenmodellen, Datenflüssen und Lasttestszenarien beteiligen. Höchstwahrscheinlich können Sie die Anforderungen in angemessener Zeit erfassen.

Ein weiterer wichtiger Punkt ist es, so vertrauensvolle Beziehungen wie möglich zum Kunden aufzubauen, Ihre Offenheit und Ihren Wunsch zu zeigen, dem Kunden zu helfen, seine Gedanken klar auszudrücken. Oft hilft eine Art von Schulung, bei der Kundenvertretern erklärt wird, wie sie mit den folgenden Tools zur Anforderungserfassung arbeiten:

Allgemeines Glossar
Ein logisches Datenmodell, in dem strenge Multiplizitätsbeziehungen zwischen Glossarelementen eingeführt werden (eins zu eins, eins zu viele, viele zu viele)
Rollen und verwenden Sie Ketten, die zeigen, wer das System wie verwendet

Alarme, die auf bevorstehende Probleme bei der Erfassung von Anforderungen hinweisen:

Kundenvertreter übersetzen die "Pfeile" miteinander und können die beiden Wörter nicht verbinden. Es gibt viele Emotionen. Es wird empfohlen, das Problem so schnell wie möglich zu eskalieren und auf eine höhere Ebene zu gelangen. Andernfalls werden Sie als "heiliges Opfer" mit einem Kult des Chaos konfrontiert Ruhestand / Mutterschaftsurlaub. Das Arbeiten unter solchen Bedingungen auf Agile ist äußerst gefährlich. Es ist besser, strenge technische Anforderungen zu schreiben und in kleinen Schritten vorzugehen
Kundenvertreter antworten wie folgt: Oh, Ihr Kopf tut weh, aber Sie sind schlau, ein „Programmierer“, also machen Sie es richtig. Hier müssen Sie verlangen, einen Experten auf dem Gebiet zu finden, der für die Antworten im Namen des Kunden und so schnell wie möglich verantwortlich ist. Oder siehe Absatz oben.
Sie ziehen es vor, nicht über Probleme zu sprechen (unlesbarer Code, fehlende Dokumentation für die wichtigsten Geschäftsprozesse), weil Geld ausgegeben, Positionen erhalten, Boni ausgesprochen und Risiken ausgesprochen werden kann zu einer intensiven Reinigung des Personals führen (trotzdem „versteht“ jeder, und hier rollen die Ingenieure das Fass) - es ist schwierig, hier Ratschläge zu geben, auf das tatsächliche Wetter zu reagieren

Auch in den oben genannten klinischen Fällen hilft die Entwicklung einer vorgefertigten Box / Cloud-Lösung mit vorgefertigter Dokumentation sehr. Ein solcher Ansatz verringert das Risiko plötzlicher Kursänderungen um 180 Grad um Größenordnungen. Garantien sind aber schon weniger.

Bei einem angemessenen Ansatz des Kunden, dem Wunsch, Sie zu lernen und zu verstehen, dem aufrichtigen Wunsch, ein Projekt rechtzeitig zu starten und weiterzuentwickeln, hilft die gleichzeitige Nutzung mehrerer Technologieplattformen sehr. Das Entwerfen ist nicht mehr beängstigend - Sie haben das Gefühl, dass der Kunde die Verantwortung für das Sammeln von Anforderungen zu 100% mit Ihnen teilt, und Sie können versuchen, es gut zu machen. Sie - versichern sich gegenseitig und kämpfen gemeinsam mit der Komplexität:

PHP-Website mit Framework, Boxed-Lösung
Predictive Analytics in Python
Eine mobile Anwendung, entweder auf einer einzigen Plattform , die überall funktioniert, oder wir schreiben für jedes Gerät

Verschwenden Sie keine Zeit!

Wenn für 2-3 Wochen, in extremen Fällen, anderthalb Monate, das Gefühl nicht vergeht, dass Sie an dem Stück „Chatten Sie mit einem klugen Blick und nehmen Sie sich Zeit und legen Sie alles auf jemanden“ teilnehmen, ziehen Sie den Stoppkran, setzen Sie den Zug in Brand und schreien Sie laut an schreien: "Geh nach Hause, Kinder! Leistung ist vorbei. "

Vereinbaren Sie im Ernst ein Treffen mit dem Management des Kunden und bestehen Sie darauf, angemessene Mitarbeiter in das Projektteam aufzunehmen, die die Funktionsweise des Unternehmens genau verstehen und in der Lage sind, streng gestellte Fragen der Ingenieure zu beantworten. Oder kündigen - manchmal ist dies der richtige Schritt: Retten Sie Ihr Gesicht und wachsen Sie als Spezialist auf.

Checkliste

Infolgedessen können wir den Anforderungserfassungsprozess als erfolgreich betrachten, und es ist sinnvoll, fortzufahren, wenn Sie zusammen mit dem Kunden die folgenden Artefakte innerhalb weniger Wochen vorbereiten konnten:

Glossar mit 50-150 Domain-Begriffen
Logisches Datenmodell mit Glossarbegriffsbeziehungen
Anwendungsfälle mit Glossarbegriffen
Für komplexe Algorithmen - Flussdiagramme oder Aktivitätsdiagramme von UML
Softwaresystemschnittstellen, die den oben genannten Punkten nicht logisch widersprechen
Sie haben sich für eine Reihe von Axiomen entschieden, die Ihre Einstellung zur Welt beschreiben = gewählte Softwaretechnologie. Hier fühlen sich viele aus Liebe zur Kreativität zum Sadomasochismus und dem Wunsch hingezogen, das Rad neu zu erfinden - bekämpfen Sie diesen Wunsch. Entscheiden Sie: Entweder ist die ganze Welt voller schmutziger Tricks und Psychopathen und Sie bauen einen Bunker, der einem UFO-Angriff standhält, oder die Entwickler möchten Ihnen aufrichtig helfen. Die beste Technologie und eine Reihe von Axiomen: ein entwickeltes Framework oder eine vorgefertigte Box-Lösung - das Risiko, nicht zu starten, nimmt um Größenordnungen ab (erfahrungsgemäß starten Projekte mit 95% und mehr)
Sie haben das Softwaresystem durch den Kunden, sich selbst, durch Ihr Gehirn verpasst, und nirgendwo gibt es schlammige Stellen oder emotionalen Matsch. Wenn es solche potenziell verdorbenen Orte gibt (und dies geschieht in der Regel immer), nehmen Sie sie in den Risikomanagementplan auf und sprechen Sie sie bei jedem Projekttreffen aus. Und erwarten Sie, dass Sie gerahmt werden und fragen Sie, wie Sie es verpasst haben

Wenn die oben genannten Artefakte für den angegebenen Zeitraum nicht gesammelt werden konnten und es nur Papiere gibt, die den fünften Punkt abdecken, wie z. B. vagen TK-Lippenstift, werden Analysten nicht miteinander kooperieren, Experten auf dem Fachgebiet werden auf Kundenseite nicht erwartet, Probleme werden vertuscht und die Atmosphäre der Fensterdekoration herrscht und "Nur gute Nachrichten" - packen Sie Ihre Sachen: Wahrscheinlich lassen sie Sie nicht fliegen, die Erkundung des Mondes wird auf unbestimmte Zeit verschoben und Sie befinden sich in einer Theateraufführung wird nicht verteilt. "

Um echten Erfolg zu erzielen, ist es sehr, sehr wichtig, Softwaresysteme wirklich zu lieben, sich dem Sammeln von Anforderungen und dem Design in vollen Zügen zu widmen, Raketen einen frühen Start zu wünschen, mit einem Kunden Bier zu trinken, sich gegenseitig zu vertrauen und die Worte von Edsger Dijkstra ständig zu wiederholen: „Einfachheit ist der Schlüssel Zuverlässigkeit "!

Mit dem Coming of all wünschen wir Ihnen viel Glück bei der Implementierung von Softwareprojekten.

Sammlung von Anforderungen für ein Softwareprojekt - ohne Schnitte