Sie müssen auswählen, welche Software Sie benötigen: pünktlich geschrieben oder von hoher Qualität

Ich hoffe, dass ich Ihre Aufmerksamkeit mit einer so provokanten (und zugegebenermaßen übertriebenen) Überschrift erregen konnte. Gut. Lassen Sie es mich jetzt etwas eleganter und weniger verlockend umformulieren:

Grundsätzlich kann Software entweder pünktlich oder gut geschrieben werden, aber nicht beide gleichzeitig *

* außer in einigen Fällen in den bestehenden Hochleistungsteams

Seit einigen Monaten denke ich darüber nach, warum die Erstellung hochwertiger Software nicht gut zu den geschätzten Daten und der Planung im Allgemeinen passt. Während meiner Karriere habe ich Projekte gesehen, die auf einer Vielzahl von Modellen aufgebaut waren (kaskadierend, wirklich flexibel, flexibel-kaskadierend), und alle hatten eines gemeinsam: Egal an welchem ​​Projekt wir arbeiten, wenn es „ auf wissenschaftlicher Ebene“ durchgeführt wurde ( d.h. wir haben uns keine schmutzigen Tricks erlaubt, aufgrund derer wir später Albträume haben würden), dann haben wir immer die Fristen gebrochen.

Auf der anderen Seite bedeutete dies, dass das Projekt, wenn es „pünktlich“ geliefert wurde, zwangsläufig sein Volumen reduzieren oder so viele Ecken abschneiden musste, dass sich während der Implementierung Berge technischer Schulden ansammelten, was praktisch garantierte, dass das Projekt kurz danach neu geschrieben werden musste starten. Daher begann ich mich zu fragen: Können wir wirklich davon ausgehen, dass das Projekt „pünktlich“ geliefert wurde, wenn wir als Ergebnis eine hässliche, unbequeme Unterstützung haben, die mit Fehlern gefüllt ist und ehrlich gesagt eine hässlichere Version des Codes im Vergleich zu dem, was wir ursprünglich hatten? versucht zu tun?

Übersetzt nach Alconost

Ich hatte Gelegenheit, an Projekten ohne feste Fristen zu arbeiten. Ja, formell „Fristen“ waren da, aber weit entfernt von Stahlbeton. Jeder hat verstanden, dass unsere Fristen flexibel sind und dass Qualität wichtiger ist als die pünktliche Lieferung des Produkts. Bei diesen Projekten haben wir die beste Software bekommen, es gab die zufriedensten Entwickler, und im Allgemeinen gehörten diese Projekte zu den erfolgreichsten unter allen, an denen ich arbeiten musste. Aber wir alle wissen, dass solche Projekte sehr selten sind, sonst hätte ich das alles nicht geschrieben.

Warum ist es so schwierig, die Arbeit zu planen und gute Software herauszugeben, wenn die Fristen fest sind? Ich denke, das liegt hauptsächlich an Kreativität , Können und Unvorhersehbarkeit .

Kreative Seite der Programmierung

Ich bin der Meinung, dass Softwareentwicklung per Definition eine kreative Aktivität ist . Natürlich gibt es Entwickler, die dieselben trivialen Aufgaben ausführen, aber sie haben nur Arbeit, bis jemand herausgefunden hat, wie sie ihre Arbeit automatisieren können. Sie werden sie nicht beneiden, und das Thema dieses Artikels ist völlig anders.

Für mich ist es etwas Besonderes , etwas Neues zu schaffen und nach originellen Lösungen zu suchen, um auf Herausforderungen zu reagieren. Deshalb fühle ich mich zur Softwareentwicklung berufen und glaube nicht, dass ich der einzige bin. Tatsächlich denke ich, dass Kreativität der Hauptgrund ist, warum Entwickler ihre Arbeit genießen. Meine Erfahrung zeigt, dass immer dann, wenn ich unter Bedingungen arbeitete, unter denen strenge und unveränderliche „Praktiken“ (ob es sich um einen technologischen Stapel, Prozesse, Vorschriften usw. handelte) eingehalten wurden, weniger Raum für Kreativität vorhanden ist Ich war - je weniger mich diese Arbeit faszinierte. "Wenn sie am Ende schon alles für sich selbst entschieden haben, warum brauchen sie mich dann?" - Ich dachte. Andererseits war ich viel erfüllter, inspiriert von solchen Arbeiten (in denen ich auch am produktivsten war), in denen es relativ wenige Anweisungen von oben gab, Raum für Kreativität gab und man mir vertraute, technische Entscheidungen selbst zu treffen.

Es ist wichtig anzumerken, dass zusätzliche kreative Freiheit dazu führt, dass auf dem Weg zu einer Lösung zwangsläufig mehr Versuch und Irrtum stattfinden wird - und das ist normal. Es scheint einigen, dass Sie einfach die perfekte Lösung a priori (im Voraus) kennen können, ohne eine einzige Codezeile zu schreiben. Im Gegenteil, ich bestehe darauf, dass im kreativen Prozess der Weg zur Lösung einer Aufgabe (dies gilt nicht nur für Software) zu basteln ist : Es ist unmöglich, alles im Voraus sicher zu wissen; Im Gegenteil, Sie lernen in der Praxis, sortieren nach und nach neue Optionen aus und halten sich an die, die funktionieren, verfeinern Ihre Entscheidung (und übergeben sie möglicherweise schrittweise an Kunden, wenn Sie nach einer „flexiblen“ Methodik arbeiten), bis Sie damit zufrieden sind.



Denken Sie nur daran, wie oft es gedauert hat, eine Komponente sorgfältig auf Papier zu entwerfen. Erst dann hat es sich gelohnt, mit der Implementierung zu beginnen, um das Design vollständig zu überarbeiten. Es wird immer unbekannte Unbekannte in diesem Geschäft geben , und Sie können sie identifizieren und nur a posteriori (tatsächlich) damit umgehen , Ihre Lösung programmieren und nicht viel Zeit damit verbringen, zu theoretisieren und nicht so zu tun, als könnten wir im Voraus perfekte Informationen besitzen. Eine solche Improvisation passt nicht gut zu geschätzten Daten.

Darüber hinaus ist es, wie bei anderen kreativen Aktivitäten, nützlich, beim Programmieren einen strategischen Aufschub zu üben - dieser Begriff wurde zuerst von Adam Grant vorgeschlagen, der behauptet, dass er häufig nicht auf Anfrage erstellt, im Gegenteil, Kreativität kommt als „Push-Benachrichtigung “ von Ein Prozess, der im Hintergrund in Ihrem Kopf abläuft:

„Regelmäßig zögernde Mitarbeiter widmen normalerweise mehr Zeit dem abweichenden Denken, und Kuratoren bewerteten sie häufiger als kreativer als Kollegen. Aufschub fördert nicht immer die Kreativität: Wenn ein Mitarbeiter nicht sicher genug ist, ein großes Problem zu lösen, bleibt er aufgrund des Ausrutschens einfach zurück. Wenn eine Person jedoch eine ausreichende Leidenschaft für das Geschäft hat und neue Ideen herausgibt und dann die Aufgabe verschiebt, kommt sie zu kreativeren Lösungen . "
- Grant, Adam. "Originale: Wie Nonkonformisten die Welt bewegen"

Auch dies wird den Befürwortern der zentralen Planung nicht gefallen , die versuchen, jede Minute in Softwareentwicklungsprojekten vorauszusehen und zu messen.


Milchstraße , Mars und Meteor

Programmierkenntnisse

Die besten Entwickler, die ich kenne, sind qualifizierte Handwerker. Beherrschung ist ein charakteristisches Merkmal guter Software: Sie erstellen etwas, das funktioniert, und Sie erstellen es auf die bestmögliche Weise - es ist relativ einfach, etwas zu erstellen, das funktioniert, aber es ist sehr schwierig - es wird nicht nur funktionieren, sondern auch den Test der Zeit bestehen.

Da Sie ein Meister sind, spricht die Qualität Ihrer Arbeit von Ihnen . Für Sie ist Qualität wichtiger als Quantität, denn Sie möchten nicht als Autor von govnokod anerkannt werden, selbst wenn Sie den Produktmanager zufriedenstellen, Ihrem Programm einen externen Glanz verleihen und es mit einer Reihe abscheulicher Überraschungen füllen könnten - ich nenne diesen Ansatz Kinder Surprise Development . Sie wissen, dass es richtig ist, genügend Zeit für einen Fall aufzuwenden und ein gutes Programm zu schreiben. Widerstehen Sie also dem Druck, es schneller zu machen, denn Sie wissen, dass je mehr Krücken Sie jetzt einrichten, desto kürzer Ihr Code ist und desto mehr Probleme damit verbunden sind Geschäft.


Augen bluten

Handwerkskunst ist mit Sorgfalt verbunden : Wir kümmern uns um hervorragende Arbeit, um diejenigen, die unseren Code nach uns pflegen müssen, um unsere Kunden, die mit unserem Programm einfach zu bedienen sein sollten, um Teamkollegen usw. Sie tun dies, weil Sie kein Arschloch sind und weil Sie wissen, dass Sie dies tun sollten, wenn Sie sich für den Erfolg des Projekts interessieren.

Kurz gesagt, ein guter Ingenieur hat eine schwierige Aufgabe: sich um die Qualität zu kümmern - was auf lange Sicht zu spüren sein wird - in einer Welt, in der alles schnell erledigt werden muss.

In der Praxis drückt sich dies in ähnlichen Dingen aus:

• Finden Sie die richtige Kombination zwischen Kapselung, Erweiterbarkeit, Skalierbarkeit usw. - Auch hier ist ein iterativer Ansatz durch Ausprobieren erforderlich, da es niemandem gelingt, beim ersten Versuch die beste Lösung zu finden.
  
• Nehmen Sie sich Zeit für das Refactoring, wenn Sie auf einen schändlich schlechten Code stoßen.
  
• Schreiben Sie gute, vollständige Tests - vielleicht sogar TDD
  
• Programmieren Sie gemeinsam mit einem Kollegen
  

Es ist unnötig zu erwähnen, dass es unmöglich ist, all dies im Voraus zu planen. Ein ähnlicher Ansatz hilft Ihnen daher immer noch nicht, die Fristen einzuhalten.

Ihre Vorhersagen sind falsch

"Selbst wenn es klare Anforderungen gibt - und es scheint, dass dies nie passiert, ist es fast unmöglich zu berechnen, wie lange es für einen bestimmten Job dauert, da wir dieses Problem noch nie zuvor gelöst haben." Wenn Sie sich entscheiden, geben Sie einfach das Ergebnis. "
- Ron Jeffries, NoEstimates Movement

Softwareprojekte sind komplexe Systeme : Sie werden von Menschen erstellt und tragen daher den Eindruck zwischenmenschlicher Beziehungen, Motivation, Kommunikationsprobleme und der menschlichen Psychologie im Allgemeinen - all dies ist sehr schwer in der Tabelle zu modellieren und zu quantifizieren, wenn Sie an meiner Meinung interessiert sind. Softwareprojekte sind daher sehr schwer zu modellieren (und daher vorherzusagen). Dies erklärt Nassim Taleb am besten in seinem Buch „ Anti-Fragility“ :

„Komplexe Systeme sind stark voneinander abhängig (was schwer zu erkennen ist) und nichtlineare Reaktionen. „Nicht linear“ bedeutet, dass wenn Sie beispielsweise die Medikamentendosis oder die Anzahl der Arbeiter in der Fabrik verdoppeln, die Rendite nicht doppelt so hoch ist, sondern entweder viel mehr oder viel weniger. Das soll nicht heißen, dass zwei Wochenenden in Philadelphia zweimal angenehmer sind als eines - das kann ich aus eigener Erfahrung sagen ... “
- Nassim Nicholas Taleb, Anti-Fragilität

Schlimmer noch, da Zeit kein negativer Wert sein kann, verzögern ungeplante „Überraschungen“ wahrscheinlich den Abschluss des Projekts, anstatt es näher zu bringen, da es eine Asymmetrie der Ergebnisse gibt:

„Zeit ist kein negativer Wert, was bedeutet, dass ein dreimonatiges Projekt nicht in einem Zeitraum von null oder negativ umgesetzt werden kann. Auf der Zeitachse, die sich von links nach rechts bewegt, häufen sich daher Fehler rechts und nicht links an. Wenn die Unsicherheit linear ist, würden wir sehen, dass einige Projekte deutlich früher als geplant abgeschlossen werden (da wir manchmal viel früher und manchmal viel später an einem Ort ankommen). Aber in Wirklichkeit ist es nicht so. "
- Nassim Nicholas Taleb, Anti-Fragilität

Dies ist eine schlechte Nachricht, da Unsicherheit garantiert ist und sich selbst kleine Fehler bei der Bewertung einzelner Aufgaben im gesamten Projekt exponentiell ansammeln. Darüber hinaus betrachten wir hier den besten Fall, wenn die Fristen von den Entwicklern selbst nach sorgfältiger Abwägung des Timings festgelegt werden. Die Realität ist jedoch viel absurder: In den meisten Fällen legt das „Unternehmen“ die Fristen so fest, wie es ihm gefällt, und nur dann nehmen Ingenieure die Angelegenheit auf, die planen, alle Anforderungen für diesen willkürlich festgelegten Zeitraum zu erfüllen. Der Fall ist so ungeheuerlich, als würde man ein Haus vom Dach aus starten, nicht vom Fundament aus, oder einen Karren vor ein Pferd stellen.


Gute Frage

Hier einige Beispiele, die die Nichtlinearität der Softwareentwicklung und die daraus resultierenden Rückkopplungsschleifen demonstrieren:

• Sie haben einmal vorgeschlagen, dass die API, an die Sie binden möchten, memberId akzeptiert, tatsächlich jedoch nur memberId . Fügen Sie dem geschätzten Zeitraum von 4 Tagen hinzu, dass Sie den API-Code umgestalten müssen. Danach benötigen Sie eine separate Überprüfung, für die wir weitere 2 Tage hinzufügen.
  
• Die Aufgabe, die wir in zwei Tagen lösen wollten, dauert eine Woche, da einer der Kollegen Sie im Überprüfungsprozess zwingt (und es richtig macht), den ekelhaften Code, der lange in den Startlöchern gewartet hat, umzugestalten und zu optimieren.
  
• Denken Sie an diese einmalige Aufgabe, wenn Sie nur eine neue Opportunity implementieren mussten. Es stellte sich jedoch heraus, dass Sie dafür die Abhängigkeit aktualisieren müssen, was 4 Tage dauerte, und dieser Vorgang löste eine Kettenreaktion mit der Aktualisierung anderer Abhängigkeiten und einer ganzen Reihe von Abhängigkeiten während der Montage aus.
  

Sind wir vermasselt?

Wir spielen dieses Spiel einfach aus Trägheit weiter mit Bewertungen und Planungen, um uns zu vergewissern: Wir haben angeblich die Kontrolle über die Situation. In Wirklichkeit kontrollieren wir jedoch nichts. Die Erfahrung zeigt, dass Softwareprojekte unvorhersehbar sind. Ich denke, es ist besser, sich auf das Geschäft zu konzentrieren, als zu planen - #NoEstimates , wer ist bei mir? Dies wird jedoch in vielen Organisationen natürlich nicht funktionieren: "Sie können es nicht einfach nehmen und die Ingenieure den Ball laufen lassen, damit niemand sie kontrolliert." Es muss Rechenschaftspflicht geben! “ Ich habe verstanden.


Sagst du das nicht

Was ist dann zu tun? Ich denke, dies läuft darauf hinaus, die Kluft zwischen der Welt der Tische und der Welt der IDE zu verringern, um den Ingenieuren ein Höchstmaß an Kreativität, Flexibilität und Freiheit zu bieten, um Meisterschaft zu zeigen. Gleichzeitig müssen sie jedoch verantwortungsbewusst die Versprechen einhalten und die Erwartungen der Projektbeteiligten erfüllen. Technischer Manager (Engineering Manager) - der beste Spezialist für den Bau solcher Brücken, der auch die Lücke zwischen den beiden Welten schließen kann. Diese Arbeit ist nicht einfach, aber notwendig. So gut spricht Aaron Longwell in ihrem Artikel über sie:

„Da technische Manager an der Grenze zwischen Unternehmen und Technikern leben, müssen sie die Widersprüche zwischen Erwartungen und Realität lösen. Sie sind wie eine Hebelaufhängung, die in verschiedene Richtungen gezogen wird: Sie kann auf beiden Seiten einrasten. Wenn das Geschäft gewinnt, werden die Entwickler zu Tode getrieben. Wenn die technischen Überlegungen die geschäftlichen überwiegen, verabschieden Sie sich vom Budget und den Fristen. In jedem Fall ein Fehler. Ein erfolgreicher Software-Projektmanager findet Wege, flexibel zu handeln. nachgeben, nicht brechen und die Reibung allmählich auflösen. Der Leadership as Service-Ansatz kann Ihnen helfen, flexibler zu werden. “
- Aaron Longwell, Warum Softwareentwicklung Servant Leaders erfordert

Es ist auch sehr wichtig, eine starke Vertrauensbeziehung zwischen Produktion und Ingenieuren aufzubauen. Wenn es Vertrauen gibt, können Sie die Fristen ehrlich und gewissenhaft aushandeln. Wenn Sie bereits bewiesen haben, dass Ihr Team gute Software herstellt, sollten Sie einen ziemlich guten Ruf haben, und die Stakeholder sollten Ihnen vertrauen und verstehen, dass wenn Sie außerhalb des Zeitplans liegen, dies aus guten Gründen und für das Gemeinwohl gilt.

Ein weiterer „Trick“, den ich persönlich als Manager verwendet habe, bestand darin, keine bestimmten Daten zu benennen, da diese unweigerlich zu harten Fristen führen. Es ist besser, unscharfe Daten anzugeben, zum Beispiel "drei bis fünf Wochen". In diesem Fall, wenn Sie sich einer solch wackeligen Frist nähern, fügen Sie hinzu: "im April oder Mai", was leicht als "Zwischen dem 15. April und dem 3. Mai" Anfang April interpretiert werden kann, um den 10. April herum kann es sich in "Bis 20" verwandeln April "usw. In diesem Fall zerlegen Sie sich nicht und kommunizieren nicht mit Kollegen. Das Team bietet die Flexibilität der Bedingungen, die zur Lösung der unvermeidlichen unvorhergesehenen Probleme erforderlich sind.

Denken Sie schließlich daran, dass der Entwickler für die technische Qualität des ausgestellten Produkts verantwortlich sein sollte und nicht andere interessierte Parteien. Es ist ganz natürlich, dass es zu Reibungen zwischen Organisationen kommt, die auf den ersten Blick von unterschiedlichen Anreizen geleitet werden. In diesem Fall ist es am wichtigsten zu beachten, dass Sie alle (vermutlich) ein gemeinsames Ziel haben: dem Kunden in kürzester Zeit qualitativ hochwertige Software zur Verfügung zu stellen. Anscheinend können nur gute Entwickler in diesem Sinne denken und verstehen, dass es wichtig ist, den trügerischen Ansatz „eins, zwei - und fertig!“ Zu vermeiden, der auf lange Sicht der langsamste ist.

Abschließend möchte ich sagen, dass dies ein lösbares, wenn auch komplexes (und allgemeines) Problem ist. Ich würde sagen, wenn Ihr Manager oder Ihre Organisation Ihrer Meinung nach nicht geneigt ist, gute Software zu schreiben, müssen Sie darüber sprechen und versuchen, sie zu ändern. Wenn dies fehlschlägt, suchen Sie einen anderen Job.

Über den Übersetzer

Der Artikel wurde von Alconost übersetzt.

Alconost lokalisiert Spiele , Anwendungen und Websites in 70 Sprachen. Muttersprachliche Übersetzer, Sprachtests, Cloud-Plattform mit API, kontinuierliche Lokalisierung, Projektmanager rund um die Uhr, jedes Format von Zeichenfolgenressourcen.

Wir machen auch Werbe- und Schulungsvideos - für Websites, die verkaufen, Image, Werbung, Schulung, Teaser, Expliner, Trailer für Google Play und den App Store.

Weitere Details