Achtung: Diese Methode ist nicht zu empfehlen, wenn du noch nicht genug Erfahrung hast oder effizient arbeiten willst, mir macht es so halt am meisten Spaß.
1. Mal schlampig die Hauptfunktionen implementieren (die, bei denen ich nicht 100% weiß, wie sie funktionieren sollen) und alles zum Laufen bekommen (häufig als Konsolenanwendung oder ne form mit ein paar Buttons, ...)
2. Anfangen, die wichtigsten Klassen, welche als Basis für andere dienen werden, zu implementieren
3. Von den Basisklassen bis zu den Klassen, auf die man später zugreifen will alles von unten hoch implementieren. Evtl. manche Funktionen, welche sich später ohne Probleme in die Architektur integrieren lassen erstmal weg lassen, falls man noch grundlegende Probleme bei der Architektur bemerken sollte.
4. UI machen (keine Fehlerbehandlung, keine Überprüfung der Felder - nur Grundfunktionen)
5. Die restlichen Klassen, die bei Schritt 3 übrig geblieben sind, implementieren
6. UI verbessern: Eigene Controls, wo es Sinn macht, bei Bedarf Code aus der Form auslagern
7. Fehlertesting & Weitergabe an Betatester, falls das Programm was größeres ist oder es auf Funktionen zugreift, welche auf verschiedenen Systemen Bugs haben könnten. Auch Testen in einer VM mit WinXP, 7, 8, 10 (wobei ich auf XP keine Rücksicht mehr nehme, wer kein .NET Framework 4.5 hat kanns halt net benutzen - ich mag die kleinen Ergänzungen und ohne das 4er laufen viele Libraries net).
8. Wenn ich der Meinung bin, dass das Programm einen allgemeinen Nutzen hat und ziemlich fertig ist, hier im Showroom veröffentlichen und auf Feedback hoffen.

Wg. den "Qualitätsanforderungen":
Alle möglichen Fehler in Usereingaben sollten irgendwie gehandelt werden, bevor eine (ungehandelte) Exception geworfen wird, für eine Beta ist es aus meiner Sicht ok, den Standard-Fehlerdialog zeigen zu lassen um genauere Fehlerberichte zu bekommen. Kommentare sind zwar schön und gut, sind aber auch Arbeitsaufwendig. Deswegen mache ich sie eigentlich nur, um Abschnitte in einer Methode zu markieren oder um auf spezielle Codestellen hinzuweisen. XML-Dokumentation ist ein Muss, wenn man eine Library macht.

Das sind so die wichtigsten Sachen, die mir gerade einfallen

• Ausführlich überlegen, was die Anwendung machen soll/was sie sein soll und was sie nicht sein soll. Mache ich meistens Abends beim einschlafen
  
• UI machen, meistens sogar sehr ausführlich, weil mir das sehr viel Spaß macht
  
• Mir bestimmte Funktionen mit einem Bleistift auf einem Blatt aufzeichnen
  
• Die Klassen schreiben und direkt an die Steuerelemente binden, also ohne ViewModel, mit Events
  
• Wenn alles grob funktioniert, das ViewModel schreiben
  
• Alles andere nach und nach hinzufügen
  
• Meistens habe ich, wenn eigentlich fast alles funktioniert, keine Lust mehr, weil es ja geht, aber veröffentlichen würde ich es in dem Zustand auch nicht.
  
• Sowas wie UpdateSystem.Net oder Exceptionless hinzufügen. Also der allerletzte Feinschliff

Man muss natürlich bedenken, dass ich in WPF programmiere.