Comment puis-je prouver à la direction que nos programmeurs pourraient travailler plus de manière productive?
Backstory
J'ai obtenu son diplôme il y a moins d'un an avec un diplôme en informatique (avec des cours supplémentaires en génie logiciel) et un autre diplôme en génie logiciel. J'aimerais penser que je connais bien les méthodologies modernes de développement de logiciels (CI, Scrum, XP, etc.).
le problème
J'ai eu mon premier emploi (et actuel) lors d'une entreprise de développement de jeux de taille moyenne. La Société existe depuis plusieurs années, a plusieurs titres retenus sous sa courroie et regorge de personnes talentueuses et dévouées. Cependant, le développement logiciel se produit d'une manière entièrement ad hoc. Nous utilisons SVN et un bugtracker, mais au-delà de cela, il y a très peu de planification, aucun test automatisé, et vous seriez difficile de trouver un diagramme UML n'importe où dans le bureau.
Je peux penser à deux raisons possibles pour cela:
- Les programmeurs ne sont tout simplement pas donnés suffisamment de temps pour faire les choses correctement. Malheureusement, la gestion supérieure a tendance à définir les délais sans consulter les programmeurs, ce qui a conduit à beaucoup de tout nommé.
- Les programmeurs eux-mêmes manquent d'éducation/de motivation pour employer des techniques appropriées.
la question
J'ai récemment parlé à la direction à ce sujet et j'ai été encouragé à suggérer des alternatives. Je pense que la première chose à faire serait d'exclure la deuxième possibilité énumérée ci-dessus: c'est-à-dire que la direction donne une certaine preuve que si les programmeurs avaient donné plus d'espace respiratoire, ils pourraient devenir beaucoup plus productifs. Cependant, je ne suis pas tout à fait sûr de savoir comment y aller. Ma meilleure idée jusqu'à présent est de mener une enquête entre les programmeurs sur les méthodologies de développement logicielles qu'ils connaissent, ainsi que leurs attitudes à l'égard de la qualité du code et de telles.
TL; DR
Comment puis-je déterminer si nos programmeurs sont capables/disposés à employer des méthodes de développement de logiciels modernes et prouvent à la direction que cela conduirait à une productivité accrue?
ÉDITER
J'ai évidemment échoué à apporter mon point correctement, alors laissez-moi élaborer un peu sur la situation.
First, je suis pleinement conscient que cela ressemble à un grad frais aux yeux brillants essayant de sauver le monde avec son éducation L33T et de changer les méchants façons de ces vieux fossiles grincheux qui ne savent tout simplement plus mieux . Je comprends aussi qu'il y a toujours une différence entre la théorie et la pratique et ce qu'ils vous enseignent à l'école n'est jamais ce qui se passe dans la vie réelle. C'est exactement pourquoi je suis incroyablement prudent ici, essayant d'avoir une idée de la situation actuelle au lieu de faire la charge d'aller "Hai Guise, allons tous tes tests unitaires à partir de maintenant!"
deuxième, @psr soulève un très bon point. Permettez-moi de nommer certaines des raisons pour lesquelles je pense qu'il y a de la marge d'amélioration:
- Notre développeur senior, qui est un peu mal-envère, mais finalement un gars qualifié et raisonnable, convient qu'à ce stade de l'histoire de la société, nous devrions avoir des processus de développement plus sophistiqués et plus répandus.
- L'un des programmeurs beaucoup plus expérimentés que moi et a utilisé des méthodes modernes convient avec moi que nous pourrions être plus productifs si nous en utilisions certains d'entre eux.
- Dans certains cas, jetant des caractéristiques ensemble pendant un tout noir et ensuite chasser tous les bugs prend une quantité de temps ridicule; Je ne peux pas imaginer que cela fait des choses d'autre manière pourraient être pires.
- L'absence de planification, de conception, de refactoring et de documentation conduit à une mauvaise qualité de code. Peut-être plus important encore, cela conduit à des programmeurs à oublier comment leur propre code fonctionne en quelques mois (alors qu'ils travaillent toujours sur le même projet!), Et aucun moyen de le décharger des essais et des erreurs ou de la pataugeage à travers les spaghettis.
- Même la gestion souffre, comme la seule mesure quantifiable des progrès dans un projet est le nombre de bugs non résolus. Mais comme tout est susceptible de casser à tout moment (en raison des raisons ci-dessus), il s'agit d'une figure très peu fiable.
troisième, je ne crois pas vraiment que mes collègues ne connaissent pas la connaissance des méthodes modernes ou de la volonté de les utiliser, c'est juste que, à ce stade, je ne peux pas l'exclure comme une possibilité. Ce qui est en quelque sorte la raison pour laquelle je suis venu ici demandant quelle est la meilleure façon de savoir ce qu'ils savent (en plus des entretiens personnels longs, évidemment).
quatrième, ne prenez pas ces commentaires sur UML et des tests automatisés trop au sérieux, ils n'étaient que des exemples. Le fait est que le code est produit sur les caprices immédiats des concepteurs/la haute direction sans aucune sorte de conception de logiciels et n'a jamais été testé par quelques gars en appuyant sur des boutons pour voir si quelque chose se casse. Peut-être que je porte toujours mes lunettes teintées roses émises par l'université, mais cela me frappe comme un développement de garage à sa fin.
TL; DR
J'essaie vraiment de ne pas être arrogant à ce sujet, mais mes camarades programmeurs et mes collègues semblent exprimer un désir de manière plus prévisible et productive de développer des logiciels. Comment puis-je trouver une solution qui pourrait faire une transition facile?
Avez-vous parlé à vos collègues de développement à ce sujet? Comment savez-vous qu'ils manquent d'éducation? C'est une déclaration assez radicale et vous trouverez probablement que vous avez tort.
Je ne pense pas que cela va trop bien si un nouveau grad a commencé à se mêler aux processus sans comprendre pourquoi ils sont comme ça en premier lieu. Les gestionnaires aiment les processus et l'amour du suivi et de l'amour ont été faites paraître bien, de sorte que le sceptique de bataille-durci en moi estime que votre responsable est intéressé par votre point de vue, car c'est quelque chose qu'ils peuvent prendre un crédit.
Sachez également que les méthodes de développement de logiciels dans des livres textuelles ne font pas toujours de la même manière que dans le monde réel. Ils ne sont certainement pas une taille unique - tous et peuvent regarder le monde à travers des spectacles teintés roses. UML est une charge de merde, ne pas avoir que ce n'est pas ce problème d'une affaire.
Premièrement, soyez clair sur les étapes spécifiques que la direction devrait prendre. "Donnez à vos programmeurs plus de salles respiratoires" est trop vague, non actionnable et pas mesurable.
Deuxièmement, identifier le problème réel. Pourquoi vos programmeurs tirent-ils tous les quartiers? Il y a toujours une cause fondamentale ou des causes, et cette cause fondamentale s'étend au-delà de "nous n'avons pas assez de temps à faire."
Troisièmement, trouvez des sources faisant autorité et études de cas qui sauvegardent vos revendications. Il existe de nombreuses ressources disponibles qui discutent des solutions aux problèmes de développement de logiciels; utilisez-les pour faire votre cas.
Quatrièmement, appel à la direction sur leurs propres termes. Que cherchent-ils? Les chances sont bonnes qu'ils recherchent des moyens d'être plus productifs en termes qu'ils peuvent mesurer. En d'autres termes, "montrez-leur l'argent."
Cinquièmement, Considérez la possibilité que le problème que vous décrivez n'existait pas vraiment. Si la société est rentable, et ils compensent de manière adéquate les développeurs, tous les peuples bouchent à des problèmes de planification simples et inadéquats gestion des attentes. En d'autres termes, ce n'est peut-être pas un problème avec vos méthodes de développement de logiciels, mais plus un problème de gestion des modifications de la portée et de la fonctionnalité.
Enfin, prendre en compte votre manque d'expérience pratique. L'éducation est excellente; J'en ai un aussi, mais que l'éducation ne m'a pas automatiquement fait un expert. Ce qu'il a fait était mis sur moi dans les principes fondamentaux. Entrer dans le "monde réel" et savoir comment les choses fonctionnent réellement sont une toute une éducation de noeud.
Mon expérience a été que, avant que mes suggestions de changements de processus soient même entendues, j'ai dû développer une réputation avec le groupe concerné. Le système Les groupes ont travaillé - peut-être pas bien, mais suffisamment bon pour les produits pour être expédiés pendant de nombreuses années. Demander aux gens de passer à l'inconnu basé sur la parole de quelqu'un avec un bilan inconnu a été une grande demande.
"Le statu quo fonctionne. Pourquoi le changer? Pourquoi devrions-nous vous écouter?"
Je suis au-delà de cette route avant. Alors qu'est-ce que j'ai fait? Beaucoup de choses (20 ans en développement SW sont longtemps), mais cela semble avoir fonctionné le mieux: j'ai commencé par construire ma réputation. Je me suis montré accompli pour faire les tâches assignées. J'ai aussi appris leurs systèmes et les raisons derrière eux. (Steven Covey présente l'idée d'un compte bancaire. Demander une modification est équivalente à demander un retrait du compte. Avant de pouvoir faire un grand retrait, vous devez investir suffisamment pour le couvrir.)
Une fois que j'avais établi ma réputation, j'attendrais que les occasions de suggérer de petites améliorations:
"Que se passerait-il si nous pouvions faire automatiquement une construction du code fixé chaque fois qu'il a changé et que les résultats soient envoyés aux développeurs?"
"Maintenant que nous avons automatiquement le bâtiment de code, que si nous avions des tests unitaires exécutés avec chaque construction?"
"Vous savez, au lieu de passer un mois de tout le monde à faire des critiques de code à la fin du cycle de développement, pourquoi n'examinons-nous pas tous les commentaires, avant de devoir reconquérir des sections majeures?"
Cela a-t-il fonctionné? Oui. Une équipe qui a résisté à l'idée de vérifier en code plusieurs fois par semaine commet plusieurs fois par jour. Si le système CI est en panne aussi peu qu'une heure, je reçois des appels. Tout le code source est maintenant sous tests d'unité (95 +% de couverture!) Pour chaque construction. L'équipe fait maintenant des "critiques continus" alors que des modifications sont engagées.
Et moi, eh bien, je commence à construire ma réputation à nouveau. Ils aiment déjà que l'idée d'avoir une intégration s'appuie avec chaque commit ... Si seulement il y avait un moyen de faire cela se produire ... :-)
Cela devrait être assez simple. Utilisez des méthodes de développement de logiciels modernes pour être sensiblement plus productives que les autres et créditer votre productivité à ces méthodes.
Alors ... Faites une liste des endroits où votre productivité va exceller, puis au fil du temps, pour chaque élément de la liste, gardez un enregistrement des méthodes que vous avez utilisées pour atteindre l'excellence.
Le mode de gestion des produits de la gestion des produits et des entreprises ne peut pas aller pour tous. J'ai travaillé avec des projets d'imagerie médicale. Tout le monde voulait travailler à une manière agile, mais le problème est que nous ne pouvons pas être complètement agiles, car nous avons réglementé à contrôler notre entreprise et qu'il est nécessaire d'avoir beaucoup de documentation pour prouver que ce produit répond à leurs conditions générales de vente.
Les personnes qui sont nocturnes au travail ne se déroulent pas très malgré le processus. Ils considèrent comme un travail de merde et ralentir leurs activités (ouais la plupart des programmeurs font).
Je suppose qu'ils travaillent avec des gens font leurs plans et expédient le produit. C'est comme ça que ça a fonctionné jusqu'à présent et ils ne sont pas prêts à le changer.
Pour E.g Les sociétés comme la valve n'ont aucun gestionnaire à leur bureau. C'est un cas extrême, mais la plupart des sociétés de produits ont une vision, un piratage sur certaines choses et des navires. En introduisant un processus, posez ces questions de base
- Quel est le problème exactement que vous allez résoudre?
- Trouvez-vous sans processus approprié que nous expédions des produits de faible qualité? Ou d'introduire un nouveau processus, vous êtes convaincu de l'amélioration de la manière de travailler au sein de l'équipe?
- Si c'est un problème de gestion, alors qui doit être corrigé en premier? Manquent-ils du moral des employés?
- Comment pouvez-vous améliorer la qualité du produit? Certaines choses simples telles que les tests d'unités, la couverture, les normes de codage et les directives convient à votre projet peuvent améliorer la qualité du code
- Comment il est possible de rationaliser le processus sans les avoir beaucoup mal?
Une manière agile de travail doit bien adapter les besoins de votre entreprise. Pour le développement Web, cela pourrait bien fonctionner. Ils expédient tôt et souvent.
Les diagrammes UML sont un peu des choses méchantes et la plupart des gens n'ont pas vraiment besoin d'un niveau de diagramme trop détaillé, il est bon d'avoir, mais il faut beaucoup de temps. modélisation agile est tout à fait différent et assez simple. Peut-être que vous pouvez demander aux gens de suivre cette approche et ils seront prêts à le faire comme la plupart d'entre nous discutons de choses en termes de schémas simples dessinés à la main.
Les gens détestent les changements et je suis à peu près sûr que l'enquête ne va pas vraiment vous aider beaucoup, si elles sont frustrées par la manière de travailler, ils l'auraient réparé tôt en tant qu'organisation d'auto-apprentissage. Mais ici, vous demandez à leur aide de résoudre votre problème que le leur aussi, vous ne pouvez pas clairement dire ce qui fonctionne vraiment pour eux. Je vous suggère de vous asseoir et de réfléchir et de faire le processus rationalisé dans le processus de développement sans beaucoup de frais généraux.
Dans le niveau de résumé, vous devrez identifier clairement les problèmes à tous les niveaux et l'aborder une par une (départ du sommet, c'est facile) et prospère l'équipe vers le succès.
Comment déterminer si nos programmeurs sont capables/disposés à employer des méthodes de développement de logiciels modernes?
On dirait que la première chose à faire est de parler à vos collègues. De votre question, j'ai l'impression que vous ne comprenez pas pourquoi les processus actuels ou manquent de là sont en place. Alors demandez à quelqu'un! Il se peut que vos collègues soient conscients des alternatives et choisissent de ne pas les utiliser pour des raisons que vous pouvez alors discuter, sinon ils ne sont pas conscients, et vous pouvez ensuite les présenter et avoir une discussion sur la manière dont ils pourraient profiter à votre équipe.
Essayer de changer de culture, de procédure ou de structure d'équipe sans comprendre pourquoi il est actuellement la façon dont elle fait une recette pour la catastrophe. Travaillez pour comprendre les préoccupations qui ont conduit à cet endroit, puis discutez de certaines solutions que vous pourriez voir. Une nouvelle paire d'yeux est géniale, mais seulement si vous vous engagez dans un dialogue avec des personnes qui connaissent bien le territoire.
La plupart des méthodologies et des pratiques optimales pour la conception de logiciels ne prétendent jamais pouvoir obtenir une demande construite dans les plus brefs délais. Votre entreprise est la preuve que vous pouvez "COWBY CODE" votre chemin à travers quelques agresseurs et obtenir quelque chose de publié. La direction est heureuse parce qu'elles ont eu "cela" fait à temps et généralement cela signifie sur le budget.
Bugs Show-up et vous passerez de temps de temps disproportionné sur eux, mais la direction s'en fiche. D'une manière ou d'une autre, elles sont renforcées pour avoir frappé cette date de sortie. Quelqu'un aura une bonne idée d'améliorer vos jeux, mais votre code est trop fragile pour faire un changement aussi radical. Oh bien, qu'aurait pu être.
Suggérez d'appliquer une de vos idées à une zone particulière de l'un de vos jeux. De cette façon, vous pouvez suivre et mesurer les avantages comparés à vos autres applications et présentez ces résultats à la gestion. Exemple: suggérer des tests automatisés. Vos autres programmeurs s'afficheront très rapidement, qu'ils puissent ou non la mettre en œuvre. Très peu de devs qui ont pris le temps de devenir couramment le test de l'unité protester leur utilisation.
IMHO - La gestion arbitraire du délai détermine le développement est votre plus gros problème. Vous devez vous rapprocher des Devs des utilisateurs et/ou des décideurs qui proposent ces idées. Découvrez les conditions réelles. Ce n'est pas parce qu'il est nécessaire de faire des jeux disponibles sur différentes plates-formes, cela ne signifie pas qu'ils doivent courir dans un navigateur. Il y a toujours plus d'une façon de cuire un chat.
"Prévisible ... des moyens de développer des logiciels".
Les processus purs ont des résultats prévisibles. Mais la création logicielle est littéralement la création d'un processus, pas seulement la suivante d'un processus. Une analogie à la fabrication: le développement de logiciels est comme concevoir une usine pour créer des widgets; pas la course quotidienne de l'usine de widget.
Tous les processus de création de logiciels sont impur. (en dehors des solutions générées automatiquement)
Les processus impures n'ont pas la prévisibilité du processus pur. L'action créative plus sur la mouche sur la mouche qui se produit dans le processus, moins elle est pure.
La pureté n'implique pas bon ou mauvais.
Je pense qu'il y a des aspects importants concernant la productivité (je ne suis pas un expert en gestion, ce n'est donc que mes 2 cents).
Voici un scénario simplifié pour illustrer mes points.
Supposons que vous ayez 2 paquets de fonctionnalités (x et y) pour mettre en œuvre et qu'il faut 6 mois pour compléter le premier package X (première version). Supposons également que l'emballage X est utilisé par des modules ultérieurs (par exemple, y).
Je pense que souvent les programmeurs disent "Je n'ai pas le temps de le faire correctement" car quand ils écrivent x, ils savent que x va être réutilisé dans Y et vouloir nettoyer le code et la conception afin de le rendre plus robuste et réutilisable . Même si le code ne va pas être réutilisé, ils savent qu'un code de nettoyage les sauvera beaucoup de temps s'il doit corriger des bugs plus tard. C'est aussi ce que vous apprenez à l'école et je pense que ce sont de bons principes.
Mais d'un point de vue de la direction (c'est-à-dire dans l'industrie, le soi-disant monde réel), la libération 1 est la seule chose qui est sûre à 100%, et tout le temps supplémentaire dépensé sur X après X est suffisamment bon pour la libération 1 est considéré une perte de temps. Le client achète des logiciels de travail, pas de nettoyer le code.
Six mois plus tard, lorsque vous travaillez sur le forfait, vous utilisez une utilisation intensive de X, vous souhaiteriez avoir produit des diagrammes et des conceptions appropriés, vous souhaitez que vous aviez fait votre conception plus extensible et que vous le souhaitez que vous aviez fait cela six mois plus tôt, quand vous aviez tout le problème encore dans votre esprit.
Quoi qu'il en soit, il doit maintenant être fait et il doit donc être prolongé (travail supplémentaire). Tout en ajoutant rapidement des extensions à X, x commence à obtenir des bugs en désordre et de nouveaux bugs. Donc, au lieu de
- 7 mois pour la libération 1 (faire x correctement), et
- 7 mois pour la libération 2 (faites-vous correctement, avec peu de travail sur x),
vous avez
- 6 mois pour la libération 1 (Minimal X Mise en œuvre qui fait le travail), et
- 9 mois pour la libération 2 (mise en œuvre de Y, mise en œuvre de la solution de contournement et la fixation des bugs sur X).
Dans le deuxième scénario, vous avez une productivité inférieure en moyenne mais à partir d'un point de vue de la gestion, vous ne pouvez planifier que le terme court/moyen terme. Fondamentalement, vous n'étudiez pas ce dont vous n'avez peut-être pas besoin: vous ne pouvez pas planifier travailler sur la version 1 et 2, si vous n'êtes pas sûr à 100% s'il y a une libération 2.
Je pense que c'est un peu un paradoxe: les gestionnaires préfèrent sauver un mois sur la version 1 et passer deux mois supplémentaires sur la version 2 car le coût supplémentaire sur la libération 2 est moins sûr que l'économie de libération 1.
Donc, je pense qu'une grande partie de la frustration de nombreux programmeurs que "il n'y a pas de temps à faire les choses correctement la première fois, mais il est toujours temps de les réparer plus tard" (et la perte de productivité résultante) est inhérente à la manière dont les projets sont PLANIFIÉ: Puisque nous ne savons pas comment le marché sera dans 2 ans à partir de maintenant, nous ne pouvons pas faire des plans optimaux et nous devons accepter une perte de productivité.
Je trouve votre question assez audacieuse! Je comprends complètement ce que vous voulez dire, je partage également certaines parties de ce que vous vivez, c'est pourquoi je réponds.
À propos des méthodes, je suppose que vous devriez vous adapter à la façon dont ils font parce que cela va vous revenir à vous. Si vous vous mettez dans leurs chaussures, ils pourraient penser "Un gars juste gradué va me dire (> 5 ans de développement) Comment travailler, si j'ai eu des promotions et monte en faisant ce que je fais comme je le faisais jusqu'à présent "Comme vous pouvez comprendre, une déclaration assez dangereuse pouvant devenir peu de belles situations avec vos collègues, ce que j'ai toujours évité, car vous devez d'abord apprendre les moyens qu'ils utilisent et essaient ultérieurement d'améliorer sans confrontation.
La réponse de votre gestion Je comprends comme "montrez-moi l'argent ou gardez-la assez", ce n'est pas non pas bon, qui vous met à la lumière sans connaître 100% de quoi faites-vous affaire (signifiant à quel point les méthodologies précédentes sont rentables pour eux).
Dans mon cas, la façon dont je traite est d'appliquer les méthodes que je connais seulement à moi-même, j'utilise UML avec le code que je dois maintenir (actuellement je le fais de temps de travail) et j'ai tendance à expliquer pourquoi je l'ai fait sans impliquer la bonne façon. (Comme vous le savez, UML est pour un code comme une carte pour un explorateur. Vous pouvez explorer sans carte, mais ne vous plaintenez pas si vous faites 2 km supplémentaires dans le retour à la maison :))
Actuellement, je reçois plus de questions sur le code que le créateur d'origine, principalement parce que je suis frais avec le code, mais aussi parce que j'ajoute également une belle carte (UML) avec quelques notes sur la façon de changer quelque chose, dans un court laps de temps (Le propriétaire du code continue également de faire des changements).
Mes conseils utilisent ce que vous savez par vous-même, et si vous devenez plus efficace, ils déplaceront les projecteurs vers vous, puis vous pouvez commencer à parler de l'efficacité, avant de pouvoir mettre votre crédibilité en péril.