Wie kann ich ein schlecht strukturiertes Softwareentwicklungsmodell überwinden?

Ich bin in die Firma eingetreten, an der ich gerade als Frischer arbeite. Aufgrund der begrenzten Anzahl von Fachleuten in der GIS-Softwareentwicklung und da ich einer von ihnen war, wurde ich direkt als Projektmanager eingestellt.

Ich war mit Java und GIS ziemlich vertraut und habe selbst motivierte Recherchen zu standortbasierten Diensten durchgeführt, jedoch nicht mit Projektmanagement und strukturierter Softwareentwicklung. Es war ein Jahr nach meinem Abschluss als Geologie-Spezialist und im vergangenen Jahr arbeitete ich als Akademiker an einer Universität.

Dank des Interesses, das ich bei der Arbeit hatte, ergab sich eine Gelegenheit, und schließlich wurde ich auch für die Business Intelligence-Abteilung des Unternehmens verantwortlich gemacht. Die Firma glaubte an mich. Ich selbst habe Data Warehousing und BI-Konzepte studiert und konnte GIS auch erfolgreich mit BI kombinieren.

Außerdem arbeite ich derzeit mit zwei Entwicklern an unserem BI-Tool in C # WPF, wo ich manchmal auch die Rolle eines Entwicklers spiele (was mir gefällt).

Ich habe mich sehr bemüht, gute Methoden für die Softwareentwicklung mit agilem Projektmanagement anzuwenden, aber es war nicht sehr erfolgreich. Obwohl ich in Bezug auf ein Produkt an gut gestalteten Code glaube, bekomme ich aufgrund des Mangels an technischen Kenntnissen meines CEO (der direkt über mir steht) normalerweise nicht die dafür erforderliche Zeit. Die Zeit, die benötigt wird, wird durch den Mangel an Fachwissen in der spezifischen Codierungssprache insgesamt (zum Beispiel WPF im Gegensatz zu Java) erheblich verlängert. Es gibt auch kein Versionskontrollsystem.

Ich habe es sehr satt, wie die Dinge laufen, da sie nicht strukturiert sind, und ich denke die meiste Zeit darüber nach, wie ich die Dinge strukturieren kann. Ich hoffe, dass Sie mit guter Berufserfahrung mir helfen können, diese Situation zu überwinden.

Wir hatten ein ähnliches Problem (natürlich ohne die technischen Details) in der Firma, in der ich vor ungefähr zwei Jahren arbeite.

Sie müssen es nur Schritt für Schritt tun. Versuchen Sie nicht, die agile Softwareentwicklung in Eile zu übernehmen. Es gibt viel zu lernen und anzuwenden. Lassen Sie sich auch nicht vom Mangel an Fachwissen stürzen.

Bauen Sie langsam (aber so schnell wie möglich: P), stetig und sicher.

Ich würde die nächsten Schritte empfehlen (dazu wechseln Sie möglicherweise für eine Weile vom Management zur Entwicklung, aber das sollte in Ordnung sein).

1. Lernen Sie ein gutes Versionskontrollsystem und lernen Sie es gut. Persönlich würde ich Git oder Quecksilber empfehlen. Zu beiden gibt es eine Menge Dokumentation.
2. Bauen Sie einen soliden Kern auf Praktiken und Mustern auf . Lesen Sie Bücher, lesen Sie Blogs, schauen Sie sich Screencasts mit den Teammitgliedern an. Dies wird der Entwicklung eine neue Atmosphäre geben.
3. Lernen Sie TDD / BDD und versuchen Sie, es im neuen Code sowie im alten Code anzuwenden , den Sie möglicherweise berühren, wenn Sie eine neue Funktion ausführen.
4. Haben Paar Programmierung . Zwei Köpfe denken besser als einer und auch 4 Augen sind besser als 2 :).
5. Informieren Sie sich über die neuesten und am häufigsten verwendeten Tools in der Community der Sprache, die Sie gerade entwickeln. Erfahren Sie mehr über sie und versuchen Sie, einige davon in das Projekt aufzunehmen. Sehen Sie, wie diese gebaut wurden und lernen Sie.
6. Verwenden Sie Scrum . Iterationen, Geschichten, Handlungspunkte, Hindernisse sind alles Konzepte, mit denen Sie sich vertraut machen sollten. Scrum hat sich für mich als der beste Workflow für die Softwareentwicklung und -verwaltung erwiesen. Wenden Sie es an und lernen Sie aus den täglichen Erfahrungen.
7. Lehren Sie mit gutem Beispiel . Die meisten Anfängerentwickler sind bestrebt, neue Dinge zu lernen, aber auch einige von ihnen sind sehr faul. Wie auch immer, zeigen Sie ihnen die neuen Dinge, die Sie gelernt und angewendet haben, und hoffentlich kitzelt das ihr Gehirn.

Stellen Sie nach Möglichkeit auch einen Berater ein, damit dieser den Prozess überprüfen und bessere Ratschläge geben kann.

Sei nicht faul oder entmutigt. Lernen Sie einfach aus Ihren Fehlern und probieren Sie verschiedene Ansätze aus. Dies ist nur der Anfang!

Bearbeiten:

Hier sind einige der Links und Bücher, die ich in letzter Zeit gelesen / benutzt habe ...

Git lernen: Pro Git

Dies sind einige der Blogs, die ich empfehlen würde (die meisten sind .NET-orientiert):

• Java-Blogs
• Karl Seguins Blog und seine Grundlagen der Programmierreihe.
• CodeBetter.com
• Code gedacht
• Los Techies
• Codierer reinigen
• Und auch dieser Link zu einer Stapelüberlauffrage.

Bücher finden Sie in der Liste Buiding A Solid Programming Core auf Amazon. Ich würde auch diese empfehlen:

• Code reinigen
• Agile Softwareentwicklung, Prinzipien, Muster und Praktiken
• Fast jedes Buch aus dem Pragmatischen Bücherregal

Als Manager ist es Ihre Aufgabe , die Zeit zu erhalten, die erforderlich ist, um ein Projekt ordnungsgemäß abzuschließen. Wenn Sie sich an den CEO wenden, stellen Sie sicher, dass Sie alle Zahlen haben , die Sie stützen, und begründen Sie, warum Schätzungen so lang sind wie sie. Es liegt in Ihrer Verantwortung als Manager , dem CEO verständlich zu machen , warum es n Stunden / Tage / Wochen dauert , um eine bestimmte Aufgabe zu erledigen. Dies kann manchmal schwierig sein, aber ich habe noch keinen CEO getroffen, der möchte , dass sein Unternehmen scheitert, und ich wette, wenn Sie es so ausdrücken (wenn alles andere fehlschlägt), kann er seine Einstellung ändern.

Wenn der CEO nicht bereit ist, Ihnen die für die Erledigung von Aufgaben erforderliche Zeit zu gewähren, sollten Sie meiner Meinung nach bereit sein, entweder einen anderen Job zu übernehmen oder sich auf kontinuierliche Todesmärsche vorzubereiten. Erklären Sie dem CEO als letzten Ausweg den Burnout, der zweifellos von unrealistischen Erwartungen herrührt.

Allerdings müssen Sie auch sicherstellen, dass Ihre Entwickler Ihnen genaue Schätzungen liefern (enorm schwierig, fast unmöglich ohne ordnungsgemäße technische Entwürfe, die auch irgendwo vorhanden sein sollten).

Agile ist nicht in allen Entwicklungsbereichen gut. Funktioniert für einige Projekttypen, schlägt bei anderen kläglich fehl. Möglicherweise müssen Sie einige verschiedene Methoden ausprobieren, bevor Sie eine finden, die gut funktioniert .

Richten Sie die Versionskontrolle ein . Wirklich, es dauert 5-10 Minuten, um Git einzurichten, ein paar Minuten, um die grundlegenden Operationen zu erledigen, und ein oder zwei Tage Lesen, um die fortgeschritteneren Konzepte zu verbessern.

Hmm, ich bin mir nicht sicher, ob ich dich bei einem Agile / XP-Event in Toronto getroffen habe - das kommt mir bekannt vor

Es klingt wie Sie eine Pause brauchen. Nehmen Sie sich ein langes Wochenende, betrinken Sie sich, wenn Sie möchten, und vergessen Sie die Arbeit für ein paar Tage.

Beruhige dich. Autodidakt ist gut, und nur weil eine Methodik mit den beteiligten Persönlichkeiten nicht funktioniert, heißt das nicht, dass Sie es falsch machen, und es ist kein persönlicher Fehler.

Es gibt eine (Beta) pm.stackexchange.com-Website, die sich an das Projektmanagement richtet. Möglicherweise erhalten Sie dort nützliche Ratschläge / Unterstützung - aber behalten Sie die Frage auf jeden Fall auch hier.

Weiter zu den Technikfreaks:

Es gibt kein Versionskontrollsystem

Geben Sie eine als oberste Priorität ein. Ich bevorzuge zentralisierte Systeme wie SVN (Subversion) gegenüber Git / Mercurial, da ein gestohlener Laptop lokal nicht so viel Geschichte hat. Besonders wichtig, wenn etwas Supergeheimes (wie Passwörter und SSH-Schlüssel) versehentlich eingecheckt wurde. Aber es ist Geschmackssache. Nichts verschwendet mehr Zeit als Fehler bei der manuellen Versionskontrolle - z. B. das Zurücksetzen des Codes auf das, was Sie denken.

Viel Glück

Es hört sich so an, als hätten Sie mehrere Probleme: 1. Kommunikation mit nicht-technischen Führungskräften, damit diese Ihr Verbesserungsprogramm unterstützen; und 2. das Verbesserungsprogramm für den Erfolg vorantreiben.

Der schwierigste Teil von Nummer 1 besteht darin, sich einfach daran zu erinnern, dass die Geschäftsleitung häufig nicht an den Details Ihrer Arbeit interessiert ist. (Wenn dies der Fall wäre, würden sie es selbst tun, anstatt es Ihnen zu übergeben!) Es klingt so, als ob die große Hürde das „Warum“ ist, und Sie sollten sich CMM 1.1 ansehen, um eine Beschreibung der geschäftlichen Vorteile einer Prozessverbesserung zu erhalten Programm. Ob Sie CMM oder etwas anderes verwenden, um Ihren Prozess tatsächlich zu verbessern, spielt für diese Diskussion keine Rolle. Nur die Daten aus der Carnegie-Mellon-Studie, die zeigt, dass ausgereiftere Unternehmen Projekte schneller und mit weniger Variationen in der Lieferzeit liefern.

Es gibt viele Wege zum Erfolg bei der Prozessverbesserung, alle sind in der Regel sehr lang. Die Erfahrung mit CMM zeigt, dass es 8 bis 10 Jahre dauern kann, bis Sie von Stufe 1 auf 5 wechseln. Die Erfahrung mit 6 Sigma zeigt, dass jede Iteration einige Verbesserungen bringt, aber mehrere Iterationen erforderlich sind, um die meisten potenziellen Probleme zu beseitigen, und bis Sie dazu kommen 6 Sigmen der Qualität, die Arbeit wird völlig anders erledigt, ohne das Risiko eingehen zu müssen, alles auf einmal zu ersetzen.

Wenn es einen in Ihrer Branche üblichen Ansatz zur Qualitätsverbesserung gibt, nehmen Sie sich die Zeit, um herauszufinden, wie er auf Software zutrifft, und verwenden Sie ihn, damit der Rest des Unternehmens von etwas erfährt, mit dem er bereits vertraut ist und das er unterstützt. Wir können stundenlang über bestimmte Softwaretools und -praktiken sprechen, aber CEOs, die keine Software sind, werden dies schnell beheben. Sprechen Sie über die Standardpraktiken der Branche, und er wird munter, weil Sie seine Sprache sprechen. Wenn Sie über Software in den branchenüblichen Begriffen sprechen, wird er relevante Fragen stellen, um Ihre Herausforderungen und Ihre Pläne zur Verbesserung der Unternehmensergebnisse besser zu verstehen.

Auf diese Weise werden Sie nicht jede Bitte um Unterstützung gewinnen, aber Sie werden wahrscheinlich viel weniger leere Blicke und mehr Gewinne erhalten!

Viel Glück, Sir!

Alle Ihre Vorschläge sind in der Tat sinnvoll und in vielen Unternehmen der richtige Weg. Aber sie sind nicht universell, besonders bei Teams, die nicht so erfahren sind. Der Grund, warum dies nicht der Fall ist, ist, dass für die Einrichtung und Wartung - sogar für die Versionskontrolle - ein gewisser Arbeitsaufwand erforderlich ist, von dem viele annehmen würden, dass er für jedes Softwareprojekt Tabelleneinsätze darstellt. Da sie etwas Arbeit benötigen, müssen sie auch einen gewissen Nutzen bringen. Und es kann sein, dass dies in Ihrer speziellen Situation nicht der Fall ist! Oder zumindest sehen die Leute, die mit der Entscheidungsfindung beauftragt sind, den Nutzen nicht!

Wie andere darauf hingewiesen haben, müssen Sie:

• Versuchen Sie, die Praktiken der Reihe nach zu übernehmen. Versuchen Sie nicht alle auf einmal, da dies die Menschen überwältigen wird.
• Sie müssen eine gute Reihenfolge dafür herausfinden. Ich würde mit der Versionskontrolle beginnen. Gehen Sie dann auch mit einfacheren. Sobald die Leute darauf vertrauen, dass Sie gute Entscheidungen treffen und die Vorteile erkennen, werden sie mit größerer Wahrscheinlichkeit riskantere Änderungen vornehmen.
• Erstellen Sie ein solides Argument dafür, warum etwas implementiert werden muss. Bei 2-3 Entwicklern, die den Fortschritt für Endbenutzer ständig sichtbar machen, ist es schwierig, beispielsweise die Einführung einer ausgefeilteren Entwicklungsmethode zu rechtfertigen. Sie werden eher als prozessorientiert als als ergebnisorientiert angesehen.
• Denken Sie daran, wen Sie überzeugen müssen. Die Entwickler? Der Geschäftsführer?