Kann ein Freiberufler agile Entwicklung nutzen?

Ich möchte die Art und Weise, wie ich Software entwickle, verbessern. Ich möchte schneller und einen tollen Code entwickeln! Heute benutze ich die Wasserfallmethode als Freiberufler und schreibe Webinhalte (Websites, Systeme usw.). Gibt es eine Möglichkeit, die agile Entwicklung (XP, SCRUM usw.) auf diese Weise zu nutzen? Ich weiß nichts über agile Entwicklung. Wo soll ich anfangen? Vielen Dank.

... Mit Ausnahme der Paarprogrammierung. ;-)

Im Ernst, ich bin auch freiberuflich tätig und benutze so oft ich kann agile Techniken. Das funktioniert bei mir sehr gut. Ich mache großen Gebrauch von TDD,

Niemand nutzt irgendwo 100% von XP oder Scrum, aber jeder nutzt Teile davon und versucht, so viel wie möglich für sie zu übernehmen. Meiner Meinung nach geht es Ihnen umso besser, je mehr Sie adoptieren.

Was ich am meisten vermisse, ist die Paarprogrammierung. Die Art und Weise, wie Sie das überwinden, ist

1. Besuchen Sie viele Benutzergruppensitzungen.
2. Finden Sie ein paar Leute, die Sie als Entwickler respektieren.
3. Bitten Sie sie, Sie beim Kaffee oder beim Schreiben von Code zu treffen. Geben Sie ihnen gelegentlich einen Teil Ihres Stundenlohns, wenn Sie dies für notwendig halten, oder reagieren Sie einfach auf die Arbeit an ihrem Code.
4. Besuche oder gründe einen Hack Club wie diesen: http://www.DallasHackClub.org .

Hier sind einige Ressourcen, die ich benutze:

• Extreme Programming - eine schnelle, aber gründliche Online-Anleitung für XP.
• Ein toller Scrum-Überblick .
• Fantastisches und kurzes Buch . Perfekt für dich!

Ich würde also sagen, dass Agile als Freiberufler drei "großartige Punkte" hat:

1. Für größere Kunden arbeiten / rechnen Sie in Iterationen. Am Ende der Iteration kann der Kunde die Arbeit am Projekt fortsetzen oder das Projekt beenden (dh es hat sein Ziel erreicht). Ich weiß (aus Erfahrung), dass ich nicht mehr als ein paar Wochen abschätzen kann, und Pay-per-Iteration sorgt auch dafür, dass der Cashflow ankommt. Es macht keinen Spaß, im sechsten Monat eines dreimonatigen Projekts zu sein und zu warten um das Projekt zu beenden, so können Sie bil ...

2. Agil bedeutet Veränderung. Ich habe eine Menge Festgebotsprojekte durchgeführt (von denen Sie glauben, dass sie mit Wasserfall zu tun haben), bei denen ich aufgrund einer Kundenanfrage mitten im Zyklus Geld verloren habe. Es kommt zu einer Änderung: Der Kunde kann ein Ticket deklassieren, um andere Aufgaben schneller erledigen zu können, oder Sie haben eine falsche Prognose abgegeben und nicht so viel erledigt, wie Sie gehofft hatten.

3. Gute Tools für die Zusammenarbeit mit Kunden. Meine Standardschätzung (für etwas, das kleiner als der Arbeitsaufwand einer Iteration ist) besteht eigentlich aus einer Reihe von verhaltensgesteuerten Entwicklungsschritten, die sich aus den Erwartungen des Kunden ergeben. Ich sende dies an den Kunden und sage "Ist das richtig?". Es stellt sicher, dass alle auf derselben Seite sind.

4. Einfachste Sache, die möglicherweise funktionieren könnte. Es ist etwas, an das Sie denken sollten, wenn Sie arbeiten: Haben Sie keine Angst, zum Kunden zurückzukehren und zu sagen: "Das wäre viel einfacher (oder mächtiger oder was auch immer), wenn wir es so machen würden ... "

5. Scrum ist wichtig. Ich schicke meinen Kunden gerne jeden Tag eine E-Mail, an dem ich an ihrem Projekt arbeite. Das ist wie mein Gedränge für sie: "Woran ich heute gearbeitet habe", "Was / Wann werde ich als nächstes an ihrem Projekt arbeiten?", "Steht mir etwas im Weg?" Und "Insgesamt, wie geht es voran?" ? "

6. Testgetriebene Entwicklung ist auch als einzelner Programmierer sehr nützlich. Meine "Schätzungen mit darin enthaltenen BDD-Geschichten" helfen mir, diesen Prozess zu unterstützen.

Eine gute Möglichkeit, Ihre Agile-Reise zu beginnen, besteht darin, Ihren Workflow mit einem Kanban-System einzurichten.

Wir haben einfach 3 Schwimmbahnen:

1. Unsere To-Do's oder Backlog
2. Woran wir arbeiten oder sind in Bearbeitung
3. Dinge, die wir vervollständigen oder erledigen.

Dieser einfache agile Workflow ist ein guter Einstieg.

Im Hinblick auf die Codierung würde ich die Verwendung von Test Driven Development (TDD) empfehlen . Wir haben in unseren Artikel viele großartige Links aufgenommen, die TDD beschreiben, aber wir werden sie hier erneut kopieren:

Weitere Informationen finden Sie in den folgenden Ressourcen:

• AgileData.org - Eine großartige Ressource für testgetriebene Entwicklung.
• JamesShore.com - Ein weiterer großer Zusammenbruch für TDD
• Net Tuts - Eine lustige Einführung in TDD, die ich mag!
• Artima - Interview mit Martin Fowler
• Games From Within - Eine gute Fallstudie zu TDD
• DaniWeb - Einführung in TDD für Entwickler
• Mark Levison - Artikel über TDD

Als Einzelperson ist es am besten, wenn Sie sich agilen Methoden als etwas nähern, das Ihnen dabei hilft, herauszufinden, was für Sie am besten funktioniert . Sie sind da, um Ihnen zu helfen, das "Es gibt keinen Löffel" -Plateau zu erreichen, aber wie genau das passieren wird, liegt ganz bei Ihnen und was Sie am Ende finden, wird sich mit einigen Methoden auf verschiedenen Ebenen noch stark überschneiden Es wird etwas ganz Deines sein.

Da Sie versuchen, einen eigenen Weg zu finden, um Ihre allgemeine Effektivität zu verbessern, finden Sie hier einige Hinweise, die Ihnen helfen können, zumindest nicht dieselben Fehler zu machen, die ich gemacht habe:

Verzichten Sie so lange wie möglich auf alle Softwarelösungen, die ausschließlich auf agile Methoden abzielen.

Die Tatsache, dass sie besser für die Zusammenarbeit im Team geeignet sind, spielt keine Rolle. Der Versuchung widerstehen. Sie boxen sich nicht auf eine Art und Weise, wie Sie Dinge tun, und hoffen dann, dass die Übernahme zum Besten führt. Es ist nicht so, es frustriert dich nur. Sie finden zunächst Ihre Vorgehensweise und suchen dann eine geeignete Softwarelösung. Am Ende habe ich Whiteboards (angefangen mit einem, jetzt habe ich zwei in meinem Zimmer) zum Verfolgen / Entwickeln von Geschichten und für die Pomodoro-Technik | verwendet To Do Today- Liste, um meine Entwicklungsaufgaben zu verfolgen, und es ist verdammt noch mal 2011. Halten Sie sich an die Grundlagen, bis einige Benutzeroberflächen wie die aus Iron Man 2 oder fliegende Autos angezeigt werden.

Reflexion, Reflexion, Reflexion

Dies wurde mir klar, dass dies der wichtigste Teil jeder einzelnen Methodik für einen Einzelnen ist. Es geht darum, diesen Workflow zu entwickeln, der Ihnen eine ganzheitliche Sicht auf Ihr Projekt gibt, damit Sie auf leicht handhabbare Weise verfolgen können, was zu tun ist und wann schlechte Entscheidungen selten getroffen werden und auffallen, damit sie schnell geändert werden können bevor sie Schaden anrichten ... aber Sie können es nicht einfach von der Stange nehmen. Fangen Sie irgendwo an. Sie bleiben dabei, solange es funktioniert. Investieren Sie in die Verfolgung der Guten, der Schlechten und der Mittelmäßigen. Verbessern Sie Ihre Annahmen und passen Sie die Vorgehensweise entsprechend an. Nur so können Sie sich verbessern.

Informieren Sie sich über Termine, und konzentrieren Sie sich darauf, wie schnell Sie Ihre Aufgaben erledigen

Ich war wahrscheinlich wie der nächste, als ich anfing, Datteln nachzujagen. Burnout-Charts? Früher habe ich sie als eine Möglichkeit gesehen, meine Entwicklungsspur anhand von Fristen zu visualisieren. Es ist eine Leistung, kein Schätzmodell. Die Zeit ist da, um Ihre Effektivität zu messen, indem Sie über die Arbeit nachdenken, die Sie innerhalb eines bestimmten Zeitrahmens geleistet haben, und nicht nur über einen blöden Wert, um die Entfernung vor dem Beeinträchtigen der Fristen darzustellen. Die Realität ist, dass Dinge erledigt werden, wenn sie erledigt sind, und Ihre Methodik sollte dies berücksichtigen.

Abweichung entsprechend

Wer sagt am Ende, dass Sie User Stories verwenden müssen oder irgendetwas, von dem wir wissen? Denk nicht so. Wenn Sie es leichter haben, in Features zu denken, müssen Sie sich auf jeden Fall der globalen Entwicklergemeinschaft entziehen und es auf Ihre Art und Weise tun, denn am Ende kommt es nur darauf an, Dinge zu erledigen. Wenn Sie am Ende das Gefühl haben, etwas falsch zu machen, gratulieren Sie - Sie sind gerade zu dem Schluss gekommen, dass es Zeit ist, zu etwas anderem zu springen. Es geht um das Was, nicht um das Wie.

Ich würde antworten: "Wie möchten Sie die Art und Weise, wie Sie Software entwickeln, verbessern?". Was sind für Ihr Geschäftsmodell die größten Probleme bei der Anwendung der Wasserfallmethode?

Ist Ihr Ziel eine schnellere Entwicklung, robusteren Code, eine bessere Wiederverwendung, die Erfüllung / Anpassung an sich ändernde Anforderungen usw.? Es gibt verschiedene Methoden, um verschiedene Probleme zu lösen.

Natürlich kann die Anwendung einer anderen Entwurfsmethode als der von Waterfall sehr nützlich sein, um den Lebenszyklus eines Projekts in Abhängigkeit von Ihren Geschäftsanforderungen effektiv zu verwalten. Für eine agile Entwicklung stehen eine Vielzahl von Ressourcen online zur Verfügung. Ich würde AUP (Agile Unified Process) untersuchen, das TDD (Test Driven Development) enthält. Dies kann beim Erstellen / Verwalten großer skalierbarer Systeme äußerst hilfreich sein.

Es gibt keine einheitliche Methode, und dies ist der Hauptgrund für die große Anzahl unterschiedlicher Ansätze. Ich würde anfangen, darüber nachzudenken, wo sich die Engpässe in Ihrem Entwicklungsprozess befinden, und dann versuchen, eine neue Methode zu entwickeln, um dies zu überwinden.

Halten Sie zum Beispiel häufig die Fristen nicht ein? Führen neue Funktionen eine große Anzahl von Fehlern ein? Verursachen neue Anforderungen eine tiefgreifende Sanierung? Erfordert das Unternehmen, dass regelmäßig arbeitende Systeme vorgestellt werden? Check out: Agile , Iterative und Agile Intro .