Agil (SCRUM, XP, FDD, ...), Wasserfall, RUP, ... Warum sollte ein kleines Unternehmen die Anschaffung eines solchen Systems überhaupt stören? Warum nicht jedes Projekt bis zur Fertigstellung hacken (mit einer üblichen Teamgröße von 1 ~ 2).Warum sollte ein Software-Entwicklungsprozess eingeführt werden?
Ich bereite eine kurze Präsentation gegen das Argument vor, würde aber gerne hören, was alle denken.
Ooh, meine Lieblingsfrage. Immer wenn SDLC auftaucht, lautet die passende Antwort immer: "Es kommt darauf an!" :) Ich hasse diese Antwort genauso wie alle anderen, also lasst uns tiefer graben.
Wenn Ihre Projekte von einer einzelnen Person und sehr kurz (d. H. < 3 Monate) verwaltet werden können, dann ist wahrscheinlich kein formaler Prozess sinnvoll. GRUNDSÄTZE einiger Prozesse sind wichtig, aber der größte Teil der Zeremonie kann gefahrlos fallen gelassen werden. Zum Beispiel würde ich auf eine Agile-y-Art immer noch Karten mit technischen Geschichten (ein Satz oder so), User Stories (ein oder zwei Sätze), Aufgaben usw. verfolgen, also würde ich den Ball auf nichts fallen lassen . Ich würde Iterationen nicht unbedingt machen, nur Rolling-Wave. Wenn Sie wissen, dass Sie ein hartes Datum für eine Beta/Vorschau/was auch immer haben, können Sie Ihre Welle entsprechend planen, indem Sie die Priorität der Karten wählen, an denen Sie Woche für Woche arbeiten.
Ein Vorteil des SOME-Prozesses ist, dass Sie wahrscheinlich einige Planungs-/Verwaltungsartefakte hinterlassen (rückgängig gemachtes Karten, Backlog usw.). Wenn Sie oder jemand anderes die Entwicklung des Projekts fortsetzen müssen, können Sie sie erneut auswählen leicht.
Ein Projekt 6mo und älter mit 2 oder mehr Leuten sollte auf jeden Fall einen Prozess haben, der verhindert, dass die Dinge zu chaotisch und nicht synchron zwischen den Teammitgliedern werden. Stand-ups sind hier genauso wichtig wie Aufgabenkarten und Verantwortlichkeit.
All dies Zeug ist übrigens Projektmanagement/Prozess. Selbst bei einem 1-Mann-Team würde ich immer noch Quellcodeverwaltung, Continuous Integration, TDD usw. verwenden. Dies ist eine Notwendigkeit für Qualitätssoftware, unabhängig davon, welchen Prozess Sie für die Aufgabenzuweisung verwenden.
"hacken weg" ist ein Entwicklungsprozess, es ist einfach nicht einer, der leicht verfolgt oder vorhergesagt wird!
der Punkt des Verfahrens ist die Konsistenz und Berechenbarkeit
Wahrheit. Während Software Engineering Reuslts sind immer noch weitgehend unvorhersehbar, nach einer Methodik, die sagt, "Test your stuff" kann die Dinge ein bisschen vorhersagbarer produzieren :) –
@ chadmyers 'Antwort ist viel besser. Eine Checkliste/Bag-o-Tricks ist viel flexibler als eine starre "Methodik" –
Konsistenz ist der Schlüssel. Wenn Sie von Projekt zu Projekt nur "hacken", dann braucht ein Mitarbeiter (oder besonders ein neuer Mitarbeiter) eine längere Zeit, um mit einem Projekt Schritt zu halten, als wenn Standards und Konventionen vorhanden sind. Es spielt keine Rolle, welche Standards/Methoden Sie wählen, solange Sie sich für ein Team entscheiden, das für Ihr Team funktioniert und es konsistent nutzt.
Aber wäre ein "Framework" in einem solchen Fall nicht relevanter? – tamersalama
Wenn der "Hacking-away" -Prozess es dem kleinen Unternehmen ermöglicht, das zu liefern, was der Kunde wünscht, und zu einem Preis, mit dem der Kunde zufrieden ist, sollte sich das Unternehmen natürlich keine anderen Verfahren zulegen.
Natürlich ist das Problem, dass das Hacken, selbst in einem kleinen Unternehmen, die Herstellung dieser Ergebnisse erschwert. Auch wenn das Unternehmen oder seine Anwendungen wachsen wollen, wird Hacking schnell unhaltbar.
Sie verwenden einen Softwareprozess, um Zeit und Ressourcen für das Projekt zu verwalten. "Hacking away" ist in Ordnung für ein Projekt mit einer Person, bei dem es Ihnen egal ist, ob das, was Sie produzieren, überbudget ist, vergangene Deadlines liefert und nicht wirklich die Kundenanforderungen erfüllt *. Für Projekte, die sich um diese kümmern, wird ein Software-Prozess als Management-Ebene eingeführt.Die Manager können dann den Entwicklungslebenszyklus effektiver überwachen, sich auf die als kritisch, wichtig usw. identifizierten Aufgaben konzentrieren, dem Kunden Rückmeldung darüber geben, in welchem Stadium sie sich befinden, und all den anderen Dingen, die für Entwickler, Manager und Manager unwichtig erscheinen Kunden lieben, weil es zeigt, dass wir tatsächlich etwas tun, das sie nützlich finden :)
* Ich schlage nicht vor, dass diese immer Konsequenzen für das Hacken sind oder dass ein strukturierterer Prozess sie entfernen wird. Sie sind besser als "höheres Risiko" Bereiche der Hacking-Methode genannt und daher ein Projekt, das hackt und hackt und Hacks ziemlich egal, ob sie auftreten oder nicht :)
Ich denke, der gleiche Grund wie dort ist ein Prozess, um Autos zu bauen und Häuser zu bauen?
Die Übernahme eines Entwicklungsprozesses kann reduzieren, wie oft Sie sagen: "Oh, hätte daran gedacht".
Wenn ein "hacken" Projekt scheitert dies geschieht:
"lazy programmers, they should work harder""next time I will really do unit testing" oder "we should have taken *this* tools or *that* language...""Bye everybody, I'm leaving"Und wenn Ein laufendes "Hacken" -Projekt verzögert sich, Manager neigen dazu, mehr Leute zum Projekt hinzuzufügen. Von there ist das Sprichwort: "I need this baby in a month send me nine women!"
Die heikle Sache ist, einen bestehenden Prozess für Ihr Unternehmen und Team anzupassen:
Unabhängig davon, ob Sie es realisieren, haben Sie bereits einen Entwicklungsprozess. Der wichtigste Punkt des Blicks in die weite Welt der Prozesse ist, zu lernen, dass andere Wege gefunden haben, ihre Arbeit produktiver zu machen. Vielleicht kannst du es auch!
Prozessverbesserung ist die Grundlage des Prozesses. Der Sinn eines Prozesses liegt darin, zu lernen, wie man sich systemisch verbessern kann, damit Verbesserungen die Arbeit nicht in Schutt und Asche legen.
Die Tatsache, dass Sie nur zwei Leute im Team haben, ist nicht die Eintrittsbarriere. Ich verwende Lean-Prinzipien und Kanban auch bei Projekten, die ich als Ein-Mann-Team mache. Ich kann davon profitieren, weil ich von ihnen gelernt habe, und von diesem Lernen wurde mein Geist für produktivere Wege geöffnet, die ich mir in der Vergangenheit nicht vorgestellt hatte.
Wenn Sie bereits das Gefühl haben, dass Sie nichts mehr zu verbessern haben, dann brauchen Sie wahrscheinlich nicht in Prozesse zu schauen, die außerhalb Ihrer Arbeit liegen. Wenn Sie sich wirklich so fühlen, versuchen Sie, Ihren emotionalen Zustand im Detail zu beobachten, wenn Sie Gedanken im Kopf haben, Entwicklungsprozesse zu erforschen.Wenn Sie gerade den kleinsten Moment des Stresses haben, wenn Sie das tun, könnten Sie vor der Wahrnehmung der Arbeit zurückschrecken und nicht vor dem Nutzen, von der Arbeit und der Erforschung anderer zu lernen. Dieser inhärente psychologische Rückstoß ist nicht ungewöhnlich, aber er ist selten hilfreich, wenn er mit einer bedeutungsvollen Frage konfrontiert wird.
Ich denke, dass alles, was automatisiert werden kann, auch für 1-Mann-Teams existieren muss, da es praktisch kostenlos ist und viel Ärger erspart. – rshimoda