Comment acquérir une pratique personnelle dans les méthodologies de développement des poids lourds?

Je suis dans un nouveau travail où le projet doit répondre à des normes de qualité strictes, être fortement documenté, géré dans les moindres détails, les diagrammes UML et toutes ces choses qui sont opposées au "codage cowboy" où la plupart de mes expériences de travail passées ont été . Pensez à la façon dont les logiciels à grande échelle pour l'aérospatiale ou les dispositifs médicaux sont développés.

Je suis heureux de quitter le chaos du codage cowboy et je suis curieux de voir à quel point les méthodes d'ingénierie lourdes fonctionnent. Mais comment acquérir rapidement de l'expérience avec les méthodes lourdes?

En plus d'être simplement au travail pendant un certain nombre de mois / années, c'est-à-dire.

Avec un simple langage ou une nouvelle API, on peut pirater un programme de test de jouets, lire, faire délibérément des erreurs pour voir ce qui se passe, etc. Comme devenir bon en vélo ou jouer d'un instrument de musique, la pratique est essentielle. Il est facile de prendre une flûte et de passer une demi-heure chaque jour; pas besoin de rejoindre un orchestre ou d'être consultant en flûte à plein temps. Mais comment pratiquer des activités de génie logiciel qui sont grandes, complexes, impliquent des équipes, et dont une grande partie concerne la communication et la planification, et éviter les mauvaises communications et dépasser les limites de calendrier et de budget?

Cela ne semble pas possible de faire en solo. Existe-t-il un moyen pour un petit nombre de personnes de simuler l'ingénierie d'un grand projet à petite échelle en peu de temps (un jour)?

Existe-t-il un moyen pour un petit nombre de personnes de simuler l'ingénierie d'un grand projet à petite échelle en peu de temps (un jour)?

Oui, cela est possible dans une certaine mesure. Il y a environ 10 ans, j'ai participé à un atelier à la conférence OOP de Munich où 16 personnes ont été chargées de faire une analyse et une conception approximatives pour un logiciel de petite entreprise. La première moitié de la journée a principalement consisté à trouver une structure d'équipe pour résoudre la tâche avec 16 personnes, et la deuxième moitié de la journée a été consacrée à la résolution de la tâche avec cette équipe.

Au cours de la première partie, nous avons été guidés pour diviser les 16 personnes en groupes de quatre. Chaque équipe de quatre personnes a dû élaborer des suggestions pour la structure de l'équipe (sous la pression du temps), après quoi un processus de fusillade a été appliqué pour décider quelle structure d'équipe pourrait être la meilleure et devrait être utilisée pour la deuxième partie de l'atelier. .

Malheureusement, pendant la première partie, nous avons fait l'erreur d'essayer de donner à chacune des 16 personnes un emploi dans la structure d'équipe prévue. Cette erreur a conduit au chaos dans la seconde moitié - parce que 16 personnes sont beaucoup trop pour résoudre une telle tâche. Une solution de travail aurait pu être de diviser à nouveau les 16 personnes en équipes plus petites, ou de choisir 3 ou 4 personnes pour effectuer le travail principal, mais dans le feu de l'action, nous avons manqué de voir cela.

J'ai toujours l'impression d'avoir beaucoup appris sur les problèmes typiques que l'on peut rencontrer ce jour-là dans les grandes organisations de projet. Je ne sais pas où vous pouvez visiter ce genre d'atelier quelque part près de chez vous, ou qui offre une telle chose de nos jours, mais si vous en avez l'occasion, je vous recommande fortement d'y assister.

Commencez par une liste de contrôle . (Vous saviez que c'était la première étape, non?)
Assurez-vous que la liste de contrôle répertorie toute la documentation standard de votre projet actuel. c'est à dire. Diagramme UML, spécifications fonctionnelles, conceptions de haut niveau et bas niveau, etc ... L'ingénieur système en moi proposera d'utiliser une RTVM (matrice de vérification de la traçabilité des exigences)

Choisissez un exemple de programme sur lequel travailler. Si vous ne pouvez pas en trouver un, google "code katas" ou consultez l'archive de codejam de Google des défis. Ou construisez simplement une calculatrice. :-)

Générez les spécifications fonctionnelles de votre exemple de programme. Passez ensuite à la conception de haut niveau, au diagramme UML, etc ... Construisez-le selon les spécifications. Essaye-le. Chaque fois que vous trouvez une faille importante dans votre spécification (telle que définie par vos pratiques de travail actuelles), vous devez alors revenir à cette étape du SDLC et réviser avant d'avancer à nouveau.

Pour votre premier tour, allez-y et gardez-le petit. Faire défiler le processus est plus important que la surpuissance dans une étape particulière. Pour les tours suivants, ajoutez les fonctionnalités que vous avez laissées. Suivi, journalisation, analyse des performances, échafaudage de test, etc. Ce que vous voudrez ajouter dépendra de ce que votre employeur attend de votre travail réel.

Après avoir répété plusieurs fois le cycle de conception / construction / test / répétition, vous aurez acquis des compétences et de l'expérience dans les composants "lourds" qui vous inquiètent maintenant. Les itérations vous montreront également l'interconnexion entre les différentes étapes et la documentation générée. La leçon précieuse montre comment un changement de code de 5 minutes peut avoir un effet d'entraînement de plusieurs heures ailleurs en raison des mises à jour de la documentation et des exigences de test.

L'expérience des pratiques "lourdes" ne vient que de la réalité. Il n'y a aucun moyen de le pratiquer efficacement de manière isolée. Vous pouvez cependant l'étudier. Il existe de nombreuses études de cas et sources que vous pouvez étudier et méditer.

Cependant, toutes les pratiques que vous voyez ou étudiez ne sont pas nécessairement positives. Le développement de logiciels est une chose fluide, et ce qui semble hardcore et strict aujourd'hui peut sembler stupide et redondant demain. Cela se produit à la fois grâce à de nouveaux outils et à une expérience expérimentale remontant des startups aux organisations les plus conservatrices.

Fondamentalement, le changement et la gestion des risques semblent avoir une forme unique pour chaque organisation. Votre meilleur pari est de garder l'esprit ouvert, mais ne portez pas trop d'hypothèses d'une équipe à l'autre.