Comment surmonter un modèle de développement logiciel mal structuré?

J'ai rejoint l'entreprise actuellement sur laquelle je travaille en tant que fraîcheur. En raison du nombre limité de personnes qualifiées dans le développement de logiciels SIG, et comme je faisais partie de l'un d'eux, j'ai été directement recruté en tant que chef de projet.

J'étais assez familier avec Java et SIG, et j'ai fait des recherches motivées sur les services basés sur la localisation, mais pas avec la gestion de projet et le développement de logiciels structurés. C'était un an après mon diplôme de spécialisation en géologie et l'année précédente, je travaillais comme universitaire dans une université.

Grâce à l'intérêt que je portais au travail, une opportunité s'est présentée et j'ai finalement été nommé responsable du département Business Intelligence de l'entreprise. L'entreprise a cru en moi. J'ai moi-même étudié les concepts d'entreposage de données et de BI et j'ai réussi à combiner le SIG avec la BI également.

De plus, je travaille actuellement avec deux développeurs sur notre outil de BI dans C # WPF, où je joue également le rôle de développeur à certains moments (ce que j'aime).

J'ai essayé très fort d'adopter de bonnes méthodologies de développement logiciel avec une gestion de projet agile, mais cela n'a pas été très réussi. De plus, même si je crois en un code bien conçu en ce qui concerne un produit, en raison du manque de connaissances techniques de mon PDG (qui est directement au-dessus de moi), je n'ai généralement pas le temps nécessaire pour le faire. Le temps pris est considérablement amélioré par le manque d'expertise que nous avons dans le langage de codage spécifique dans son ensemble (par exemple WPF opposé à Java). Il n'y a pas non plus de système de contrôle de version en place.

Je suis extrêmement fatigué de la façon dont les choses se déroulent car elles ne sont pas structurées et je trouve la plupart de mon temps à penser à travailler à la façon de structurer les choses. J'espère que vous, les gars possédant une bonne expérience professionnelle, pourrez m'aider à surmonter cette situation.

Nous avons eu un problème similaire (sans les détails techniques, bien sûr) dans l'entreprise dans laquelle je travaille il y a environ deux ans.

Vous avez juste besoin de le faire une étape à la fois. N'essayez pas d'adopter le développement logiciel agile à la hâte. Il y a beaucoup de choses à apprendre et à appliquer. Ne laissez pas le manque d'expertise vous abattre non plus.

Construisez lentement (mais aussi vite que possible: P), régulièrement et sûrement.

Je recommanderais les prochaines étapes (pour ce faire, vous pouvez passer de la gestion au développement pendant un certain temps, mais ça devrait aller)

1. Apprenez un bon système de contrôle de version et apprenez-le bien. Personnellement, je recommanderais git ou mercurial. Il y a beaucoup de documentation sur les deux.
2. Construisez un noyau solide sur les pratiques et les modèles . Lisez des livres, lisez des blogs, regardez des screencasts avec les membres de l'équipe. Cela donnera un nouvel air au développement.
3. Apprenez TDD / BDD et essayez de l'appliquer dans le nouveau code , ainsi que dans l'ancien code que vous pourriez toucher lors d'une nouvelle fonctionnalité.
4. Faites la programmation par paires . Deux têtes pensent mieux qu'une, et aussi 4 yeux valent mieux que 2 :).
5. Découvrez les outils les plus récents et les plus utilisés dans la communauté de la langue que vous développez actuellement. Découvrez-les et essayez d'en inclure certains dans le projet. Voyez comment ils ont été construits et apprenez.
6. Utilisez Scrum . Les itérations, les histoires, les points d'histoire, les obstacles sont tous des concepts avec lesquels vous devez vous familiariser. Pour moi, Scrum s'est avéré être le meilleur flux de travail pour le développement et la gestion de logiciels. Appliquez-le et apprenez de chaque expérience quotidienne.
7. Enseignez par l'exemple . La plupart des développeurs débutants sont impatients d'apprendre de nouvelles choses, mais certains d'entre eux sont également très paresseux. Quoi qu'il en soit, montrez-leur les nouveaux trucs que vous avez appris et appliqué et qui, espérons-le, vous chatouilleront le cerveau.

Aussi, si possible, engagez un consultant juste pour qu'il puisse vérifier le processus et donner de meilleurs conseils.

Ne soyez pas paresseux ou découragé. Apprenez simplement de vos erreurs et essayez différentes approches. Ce n'est que le début!

Éditer:

Voici quelques-uns des liens et des livres que j'ai lus / utilisés récemment ...

Git d' apprentissage: Pro Git

Voici quelques-uns des blogs que je recommanderais (la plupart d'entre eux sont orientés .NET):

• Blogs Java
• Blog de Karl Seguin et sa série Foundations of Programming.
• CodeBetter.com
• Code pensé
• Los Techies
• Clean Coder
• Et aussi ce lien vers une question de débordement de pile.

Pour les livres, vous pouvez voir la liste Construire un noyau de programmation solide sur Amazon. Je recommanderais également ces derniers:

• Code propre
• Développement de logiciels agiles, principes, modèles et pratiques
• Presque tous les livres de The Pragmatic Bookshelf

En tant que gestionnaire, c'est votre travail pour obtenir le temps nécessaire pour terminer un projet correctement. Lorsque vous vous approchez du PDG, assurez -vous d'avoir tous les chiffres à l'appui et les raisons pour lesquelles les estimations sont aussi longues qu'elles le sont. Il est de votre responsabilité en tant que manager de faire comprendre au PDG pourquoi il faut n heures / jours / semaines pour accomplir une tâche donnée. Cela peut parfois être difficile, mais je n'ai pas encore rencontré de PDG qui souhaite que son entreprise échoue et je parie que si vous l'exprimez dans ce genre de conditions (si tout le reste échoue), il peut changer son air.

Si le PDG ne veut pas vous accorder le temps nécessaire pour terminer les tâches, alors à mon humble avis, soyez prêt à passer à un autre travail ou à vous préparer à des marches de la mort continuelles. En dernier recours, expliquez au PDG l'épuisement professionnel qui proviendra sans doute d'attentes irréalistes.

Cela dit, vous devez également vous assurer que vos développeurs vous fournissent des estimations précises (extrêmement difficile, presque impossible sans conceptions techniques appropriées , qui devraient également être là quelque part).

Agile n'est pas bon dans tous les domaines de développement. Fonctionne pour certains types de projets, échoue lamentablement dans d'autres. Vous devrez peut-être essayer quelques méthodologies différentes avant d'en trouver une qui fonctionne bien .

Obtenez le contrôle de version configuré . Vraiment, il faut 5 à 10 minutes pour configurer Git, quelques minutes de plus pour arrêter les opérations de base et un jour ou deux pour lire les concepts les plus avancés.

Hmm, je ne sais pas si je vous ai rencontré lors d'un événement Agile / XP à Toronto - cela semble familier

Il semble que vous ayez besoin d'une pause. Prenez un long week-end, buz si vous le souhaitez et oubliez le travail pendant quelques jours.

Détendez-vous. L'auto-apprentissage est bon, et ce n'est pas parce que la méthodologie ne fonctionne pas avec les personnalités impliquées que vous vous trompez et que ce n'est pas un échec personnel.

Il existe un site (beta) pm.stackexchange.com, destiné à la gestion de projet, vous pouvez très bien y obtenir des conseils / assistance utiles - mais par tous les moyens, gardez la question ici aussi.

Passons à la technologie:

il n'y a pas de système de contrôle de version en place

Mettez-en un comme votre priorité absolue. Je préfère les systèmes centralisés comme SVN (Subversion) à git / mercurial, car un ordinateur portable volé n'aura pas autant d'historique localement. Particulièrement important si quelque chose de super secret (comme les mots de passe et les clés ssh) a été enregistré par erreur. Mais c'est une question de goût. Rien ne perd plus de temps que les bogues du «contrôle de version manuel» - par exemple, remettre le code à ce que vous pensez qu'il était.

Bonne chance

Il semble que vous ayez plusieurs problèmes: 1. Communiquer avec la haute direction non technique afin qu'elle soutienne votre programme d'amélioration; et 2. Piloter le programme d'amélioration pour réussir.

La partie la plus difficile du numéro 1 est simplement de se rappeler que la haute direction ne sera souvent pas intéressée par les détails de ce sur quoi vous travaillez. (S'ils l'étaient, ils le feraient eux-mêmes plutôt que de vous le remettre!) Il semble que le grand obstacle soit «pourquoi» et vous voudrez peut-être consulter CMM 1.1 pour une description des avantages commerciaux d'une amélioration des processus programme. Que vous utilisiez CMM ou autre chose pour réellement améliorer votre processus n'aura pas d'importance pour cette discussion, seules les données de l'étude Carnegie-Mellon qui montre que des organisations plus matures livrent des projets plus rapidement avec moins de variation dans le délai de livraison.

Il y a beaucoup de chemins vers le succès dans l'amélioration des processus, tous ont tendance à être très longs. L'expérience avec CMM montre qu'il peut falloir de 8 à 10 ans pour passer du niveau 1 à 5. L'expérience avec 6 sigma montre que chaque itération apporte une certaine amélioration mais nécessite plusieurs itérations pour éliminer la plupart des problèmes potentiels et, au moment où vous y arrivez 6 sigmas de qualité, le travail se fait complètement différemment sans avoir à prendre le risque d'essayer de tout remplacer à la fois.

S'il existe une approche d'amélioration de la qualité couramment utilisée dans votre secteur, prenez le temps d'essayer de voir comment elle s'applique aux logiciels et de l'utiliser afin que le reste de l'entreprise entende parler de quelque chose qu'ils connaissent et soutiennent déjà. Nous pouvons parler pendant des heures d'outils et de pratiques logicielles spécifiques, mais les PDG non logiciels les élimineront rapidement. Parlez des pratiques standard de l'industrie et il se redressera parce que vous parlez sa langue. Parlez des logiciels dans les termes courants de l'industrie et il commencera à poser des questions pertinentes pour mieux comprendre vos défis et vos plans pour améliorer les résultats des entreprises.

Vous ne gagnerez pas chaque demande de soutien de cette façon, vous obtiendrez probablement beaucoup moins de regards vides et plus de victoires!

Bonne chance monsieur!

Toutes vos suggestions sont en effet sensées et sont la voie à suivre dans de nombreuses entreprises. Mais ils ne sont pas universels, surtout avec des équipes qui ne sont pas si expérimentées. La raison pour laquelle ils ne le sont pas est qu'ils nécessitent une certaine quantité de travail pour configurer et maintenir - même le contrôle de version - que beaucoup supposeraient être des enjeux de table pour tout projet logiciel. Parce qu'ils ont besoin d'un peu de travail, ils doivent aussi fournir des avantages. Et il se peut que dans votre situation particulière, ce ne soit pas le cas! Ou du moins les personnes chargées de prendre les décisions ne voient pas l'avantage!

Comme d'autres l'ont souligné, vous devez:

• Essayez d'adopter les pratiques tour à tour. Ne les essayez pas tous à la fois car cela submergera les gens.
• Vous devez trouver un bon ordre pour cela. Je commencerais par le contrôle de version. Allez-y avec des plus faciles aussi. Une fois que les gens commencent à croire que vous prenez de bonnes décisions et qu'ils voient les avantages, ils seront plus susceptibles d'adopter des changements plus risqués.
• Créez un dossier solide pour expliquer pourquoi quelque chose doit être mis en œuvre. Avec 2-3 développeurs qui font constamment des progrès visibles pour les utilisateurs finaux, il est difficile de justifier l'adoption d'une méthodologie de développement plus élaborée par exemple. Vous serez considéré comme axé sur le processus plutôt que sur le résultat.
• N'oubliez pas qui vous devez convaincre. Les développeurs? Le PDG?