👩🏻‍✈️ 🕡 🖱️ Évaluation et planification de projets logiciels

Mes amis, bon après-midi!

Nous continuons une série de publications "sans coupure" sur des projets liés au développement, souvent avec le préfixe "web". Aujourd'hui, nous parlerons de la manière la plus appropriée et la plus rapide d'évaluer le travail et de planifier les versions du système logiciel. Très probablement, les gestionnaires novices et les développeurs énergiques et égoïstes seront choqués par les recommandations, mais, croyez-moi, l'objectif est un et un seul: vous aider et faire de vous un véritable Jedi, ce qui apporte des avantages à l'entreprise, déplace des projets et développe des personnes en même temps. Un tel Jedi qui ne mérite sincèrement pas d'être découvert comme une momie dans la salle des serveurs sombre entre les racks avec des serveurs web et les bases de données d'un projet web volant vers le futur sans code profondément documenté, TK utilise uniquement de l'énergie pure "HZ". Alors allons-y!

Performance et analogues proches

Il est important, extrêmement important, en particulier pour le pouvoir clé du projet - les développeurs, excellents spécialistes, qui font évoluer quotidiennement leurs compétences dans les IDE modernes, pour comprendre que le manque de bon sens dans l'évaluation du travail commence avant même le désir de «concevoir une idée». Cela se produit particulièrement souvent dans le développement Web, où pendant l'appel d'offres, il est nécessaire de prendre et de prétendre que le problème politisé du poulet et des œufs a une «solution stricte»:

Le client ne sait pas encore ce qu'il veut, ou il le sait très vaguement et contradictoire (c'est-à-dire qu'il ne sait pas, mais il le veut vraiment et, surtout, à l'heure!)
Le client souhaite que les ingénieurs calculent le coût "je ne sais pas encore quoi" et il est offensé s’il ne tombe pas vraiment dans cette évaluation
Le client souhaite que les ingénieurs s’inscrivent dans les délais et lancent «Je ne sais pas quoi», disons le 1er septembre, et que, bien sûr, «je ne sais pas encore quoi»
Le client délègue souvent la clarification des détails "Je ne sais pas quoi" en dessous de la hiérarchie aux employés qui, étonnamment, commencent à jouer à "cache-cache", rigolent, remuent une jambe, claquent la porte et tirent le caoutchouc!

Cela deviendra un peu plus facile si vous trouvez des analogies proches des performances étranges décrites ci-dessus dans l'environnement:

beau mâle cour d'une femelle avant ... épreuve de force domestique dans la cuisine
acheter des pommes de terre sur le marché
voyance, astrologie, numérologie
Sacrifices à Cthulhu, etc.

Il est clair que ce n'est pas encore devenu plus facile, surtout si vous vous souvenez que la représentation est souvent assistée par des «psychologues certifiés» des deux côtés, qui savent paraître convaincants, décisifs, en disant «oui, bien sûr que nous le ferons!» et ne comprennent pas les principes de base du développement logiciel. Et si vous vous souvenez que parfois «avoir l'air confiant» aux deux extrémités du projet franchit la ligne de front, fraternise, s'unit et commence directement sincèrement indigné à exiger quelque chose de concret de la part des ingénieurs, sans fournir de réponses formelles claires à des questions clairement posées ... - Je veux vraiment aller à vacances académiques en Antarctique et oubliez, étreignant des pingouins et de l'eau froide, mais pas moins beau, sirènes :-)

Poussée d'amour

Il est assez pénible pour les ingénieurs de percevoir sobrement et analytiquement strictement les performances décrites ci-dessus, jusqu'à ce qu'ils saignent des yeux, ils prennent donc plusieurs mesures psychologiques bien connues qui rapprochent le travail concret et réel:

Besoin de se sourire
Je dois dire oui, même s'il n'y a PAS de confiance
Besoin de promettre de s'entraider
Vous devez taper sur votre poitrine (comme KinKong) et faire preuve de confiance!
~~Je dois jurer l'amour sur la tombe~~

Mais sérieusement, à ce stade, tous les membres de l'équipe de projet doivent être très clairs sur:

que nous devons encore comprendre les détails et un tas de pops intéressants et inattendus, mais comme ils se sont déjà souris, cela fonctionnera ensemble
si une date limite est assignée, alors vous devez démêler le désordre émotionnel dès que possible, comprendre et commencer à faire les choses les plus importantes de manière descendante et quelque chose ne sera toujours pas fait et c'est vrai
plus le désordre émotionnel et politique au début est important, plus il faut consacrer de temps à la phase d'analyse et de conception

Au total, à la fin de la représentation, il devrait y avoir une poussée sûre vers un avenir inconnu, dans une bonne humeur vigoureuse et un désir mutuel de s'écouter et de s'entendre.

Projets mort-nés

Malheureusement, parfois littéralement immédiatement, on comprend que le projet en cours de lancement ... personne n'en a besoin, se tord, se fige et sera jeté dans les archives:

Le projet n'a pas d'objectif charismatique clair. Vous avez juste besoin de faire quelque chose, car on ne sait pas quoi faire de plus important. Par conséquent, vous devez faire au moins QUELQUE CHOSE, puis payer un salaire - il doit y avoir une raison :-)
Des tentatives sont faites pour trouver non pas les «moteurs» de l'équipe de projet, des gens énergiques qui s'inspirent eux-mêmes et les autres et croient en l'atteinte de l'objectif, mais recherchent les responsables (à qui tout peut être reproché, en cas de problème). Ressentez la différence.

Types de performances efficaces

C'est gratifiant, mais souvent, les bons départs de projets se rencontrent, ce qui se distingue par les signes suivants. Tenez-vous à cette liste et essayez d'entrer dans de telles équipes par crochet ou par escroc:

Il y a une ou plusieurs personnes qui brûlent des idées et croient sincèrement à la réalisation de l'objectif. Le charisme et la chaleur qui en émanent permettront à l'équipe du projet d'être flexible et de dissiper les malentendus émergents et les évaluations rares.
Le client a une conscience adéquate de l'incertitude de ses propres désirs, risques et du désir de rencontrer les ingénieurs. Il y a une prise de conscience que vous devez vous tendre la tête plusieurs fois et penser, même si vous, en tant que client, avez déjà tout payé.
Du côté du client, il y a soit ou… IL y a une compréhension de la nécessité d'attirer une masse critique de «matière grise» sous la forme d'analystes adéquats et d'experts en la matière qui sont capables, sans «euh ... w ... wow ...» d'expliquer aux ingénieurs les subtilités de la logique commerciale de la prochaine projet.
Du côté du client, on souhaite atteindre les objectifs commerciaux le plus rapidement et le plus rapidement possible. Je me souviens d'un projet où un client voulait et a passé beaucoup de temps sur un «beau panneau d'administration de projet Web sophistiqué» pour les employés et a sérieusement manqué les tâches commerciales qui se trouvent à la surface.

Mais gardez à l'esprit - une rencontre avec un client aussi qualifié signifiera pour l'équipe d'ingénierie la descente du paradis informatique promis, de la sueur, du travail et du sang. Vous serez choqué par toute la connaissance des modèles de conception, appris à écrire du code simple immédiatement sans erreurs, et au lieu d'utiliser un script en PHP de 20 lignes, vous rejetterez l'usine de classe comme une tentation démoniaque. Le matin, après avoir versé du café, vous serez surpris de constater que le client, après (après!) Votre service de test, a trouvé et enregistré 30 à 40 autres bugs dans le bugtracker et vous recommande (vous!) D'écrire soigneusement les tests unitaires et de changer le cerveau des testeurs ... Mais d'un autre côté, c'est bon de pomper :-)

Alors, comment évaluez-vous un projet logiciel?

Je vais parler directement. Des gens raisonnables, y compris les ingénieurs comprennent qu'il est impossible d'évaluer ce qui n'a pas encore été inventé ... On ne peut que mentir en toute confiance. Mais, comme vous le savez, la logique mathématique formelle ne fonctionne pas pour tout le monde, donc parfois, vous rencontrerez des interlocuteurs qui prétendent que 1 + 1 = 11, et c'est tellement convaincant que même des larmes peuvent apparaître dans vos yeux.

Mais il y a une issue: une analogie. Ce n'est pas pour rien que dans l'approche Agile moderne, c'est l'analogie qui est utilisée comme brique fondamentale de l'évaluation. Exemples pratiques d'analogies dans le développement Web:

Vous devez créer une boutique en ligne typique. Et nous en avons déjà fait deux. Nous donnons une évaluation ajustée pour l'adéquation du client / l'expérience de l'équipe sous la forme d'un numéro de Fibonacci.
Nous évaluons la fonctionnalité en récits et non en heures-homme. Et nous prenons 1 point de stockage pour la complexité de créer, disons, un bloc d'informations avec une liste de nouvelles .
Parfois, vous pouvez déterminer approximativement le type de projet Web en fonction du nombre de modules standard et du pourcentage de personnalisation. S'il y avait des types de projets similaires avec des ensembles de modules similaires ou proches et une personnalisation - vous pouvez utiliser l'analogie en toute sécurité.
Parfois, ils donnent une estimation approximative en mesurant l'épaisseur du TS en millimètres. Je suis complètement sérieux - j'ai vu et, étonnamment, je travaille.

Il est important d'utiliser une approche par analogie avec les qualifications de l'équipe:

Les quatre d'entre eux ont foiré le formulaire de recherche pendant une semaine, puis ont corrigé les bogues pendant 2 semaines. Multipliez le score par 10.
Ce développeur peut intégrer le site avec mise en page en une semaine. Ajoutez 3 jours supplémentaires pour un bon comportement.

Quelque chose comme ça. Oui, vous pouvez discuter, mais qu'en est-il de PMBoK, du diagramme de Gantt, de Velicity , des cartes Kanban , des livres épais d'estimation Agile, de l'accélération d'équipe, des métriques, des petrikas? ~~Franchement, cela ne fonctionne pas et je~~ vais faire une analogie avec le «machine learning».

Apprentissage automatique et évaluation

On vous enseignera 50 types de mathématiques à l'université pendant 5 ans, puis encore six mois dans des cours coûteux sur DataScience et MachineLearning, puis dans la pratique, vous découvrez soudain que ... il n'y a pas d'approche scientifique dans ce domaine, vous devez passer par toutes les options d'hyperparamètres, seulement vous avez besoin de temps personne ne donnera (jours et mois) et il reste une recherche divine aléatoire et, surtout, INTUITION. Et il ne reste plus qu'à ... revenir et commencer à lire la théorie dans les cours. Ainsi, avec l'évaluation du travail dans les projets logiciels - il existe de nombreuses théories, mais seulement des éléments de connaissances qui sont impliqués dans l'intuition profonde et, ce qui est une seule et même expérience, le travail dans la pratique.

Pour vraiment apprendre à évaluer la complexité de la programmation, vous devez quitter les villes, vivre avec les autochtones, manger de la viande crue, boire un sang chaud et pulsant - pour être plus proche de la nature = code, bugs, production se vautrer, admins barbus, dormir quelques nuits dans la salle des serveurs et ... apprendre à faire du plantain au lieu de papier toilette. Le minimalisme et le désir de le faire simplement et clairement - permettront à l'équipe de passer beaucoup plus souvent aux notes et au client - de voler plus vite. En fait, vous devez évoquer et implémenter cette culture de sauvegarde dans le projet dès que possible.

Abus connus

C'est drôle, mais parfois de tels abus de notes se produisent qui font que les ingénieurs expérimentés ne font que sourire:

Un énorme savoir-faire de 1000 pages est en cours d'écriture, qui commence à devenir obsolète et à ne pas sentir le lendemain. Personne ne l'a lu jusqu'au bout, mais on y fait souvent référence. C'est contradictoire, aqueux, politique et non érotique. Mais ils l'ont apprécié, ont coupé l'itération, les ont évalués aussi, et maintenant tout le monde essaie de s'intégrer dans cet enfer logique
Un énorme diagramme de Gantt est créé. Parce que les exigences sont constamment discutées et changeantes, le département pour le mouvement des rayures dans le diagramme de Gantt se distingue - ils s'assoient et se déplacent toute la journée
Les fonctionnalités sont évaluées et stockées dans la boîte aux lettres. Personne sauf le manager n'a vu toutes les fonctionnalités et les notes. Le manager prend soudain des notes avec la vie et le projet ... se termine.
Des tableaux et des marqueurs sont disponibles, mais les stylos-feutres sont soit à séchage long soit permanents et écrivent quelque chose d'obscène sur le tableau pendant la communication et l'évaluation ostentatoires, il s'avère impossible de l'effacer :-)

Pratiques d'évaluation utiles et fonctionnelles dans les projets logiciels

Si vous lisez le message jusqu'à ce point, alors, évidemment, vous n'appartenez plus à la catégorie «plus il y a de papier, plus le nettoyeur», «vous posez la mauvaise question», «vous avez posé le problème non mathématiquement», mais vous voulez vraiment faire projet de logiciel en temps voulu et à un prix raisonnable. Nous corrigeons les pratiques de travail vraiment suivantes:

"Simple, moyen, difficile." Oui, nous consultons un développeur ou une équipe d'experts et mettons une note de 3 possible sur chaque fonctionnalité dans ProductBacklog. Il est conseillé de passer en revue toutes les caractéristiques connues du projet et de donner au moins une telle évaluation. Il est possible et nécessaire, n'ayant que cela en main - de planifier déjà les versions.
"Planifier le poker." Il y a beaucoup d'informations sur ce sujet, mais si vous assurez une atmosphère saine et positive de communication et de confiance entre vous, les membres de l'équipe et le client pendant l'évaluation, cela fonctionne bien.
"Appelle un ami." Si vous avez une entreprise / équipe ou à côté, un développeur expert familier, parlez-lui. Malheureusement, parfois, les équipes conspirent et essaient d'étirer le temps - un expert peut donner une évaluation adéquate de la mise en œuvre.
Les fonctionnalités et les communications sont visualisées au maximum. Des planches de liège distinctes se détachent, des dépliants avec des caractéristiques y sont accrochés, les gens se lèvent, discutent, dessinent sur d'autres planches, pour lesquelles, attention, ce ne sont pas des flasters secs et une rondelle de travail. Voici une excellente ressource sur ce sujet.

Les outils et les bonnes pratiques sont souvent plus importants que les plans et les délais.

J'espère qu'il est devenu clair et évident que même si les exigences d'un projet logiciel sont très claires et formalisées (cela arrive, bien que rarement), il peut y avoir, en tant qu'ingénieur ou analyste inexpérimenté, autant de surprises inattendues que ... seules l'intuition et la méthode d'analogie fonctionnent bien. Examinons des exemples de surprises - vous devez connaître l'ennemi en personne:

Même si les lois créées par les organes législatifs du monde entier peuvent souvent contenir de l'eau et des contradictions logiques qui provoquent des douleurs physiques dans le cerveau, alors qu'en est-il des savoirs traditionnels. Naturellement, lorsqu'une contradiction est détectée, il est urgent d'apporter des modifications au code. Le changement est fait rapidement, et le système tombe en panne après cela afin que les N-jours soient restaurés et il est impossible de prédire N scientifiquement!
Un conflit de bibliothèque de logiciels est détecté et vous devez désactiver l'un d'eux ou un glaïeul. Vous ne pouvez pas en prédire un simple.
Lors même d'une petite charge, l'insuffisance des algorithmes sélectionnés est détectée (le coût algorithmique des scénarios d'utilisation a été sous-estimé), c'est pourquoi le système commence à ralentir. Vous pouvez trouver et résoudre le problème en heures et en mois. C'est impossible à prévoir. Expérience, expérience unique ou solutions en boîte .
Le développeur principal en a fait trop avant la sortie et a commencé, sous l'influence d'émotions montantes, à uriner dans la salle des serveurs sur un rack avec des balanceurs web. Fer court-circuité. Temps d'arrêt soudain - 2 jours.

Compte tenu des risques inévitables ci-dessus, il est habituel d'agir différemment - par la méthode de la guerre systémique des bunkers (rappelez StarCraft) et des tactiques: utilisez des pratiques et des outils d'ingénierie éprouvés et estimez qu'en adhérant à cette tactique, nous atteindrons des objectifs stratégiques. Je dirai simplement la même chose: si vous faites des pompes, courez, appuyez sur l'expandeur et faites la barre le soir, alors la probabilité d'atteindre votre maison le soir est beaucoup plus élevée. Si vous prévoyez de vous protéger contre les hooligans dans le diagramme de Gantt, en calculant la probabilité de frapper 2 ou 3 personnes selon le chemin du retour et la période de l'année, alors ce sera plus difficile et beaucoup plus long et tout changement de probabilités devra être pris en compte chaque jour :-) Nous nous sommes mutuellement , en général, compris.

Tableaux, marqueurs, wikis - pour les communications les plus ouvertes entre eux et avec les clients
Arrondir le projet. Au lieu de tuer la communication et d'introduire des flux d'informations déformées et des téléphones de la hiérarchie lentement corrompus, le projet est arrondi de sorte que tous les membres de l'équipe et les représentants des clients soient accessibles à distance.
Les savoirs traditionnels ne sont pas quelque part mais accrochés aux planches, aux murs et autant de personnes que possible peuvent le "lire" et discuter
Outils d'évaluation disponibles par analogie, archives des évaluations précédentes disponibles pour tous les arrivants
Les développeurs écrivent des tests unitaires, unitaires et d'intégration automatisés pour le code. Les tests devraient être autant que du code
Habituellement, dans tout projet logiciel, il y a plusieurs endroits couverts de brouillard et des démons se trouvent dans leurs tourbillons. Il est nécessaire de lever des prototypes reflétant ces lieux le plus rapidement possible et d'effectuer des tests de charge et autres et d'obtenir un devis. Cette évaluation est très utile dans les étapes ultérieures du projet.

Après avoir entouré le projet des bons outils de communication d'équipe et adopté un système de valeurs tactiques simple mais correct et en les transmettant, dans la mesure du possible, à leur client, les chances de s'intégrer dans les notations et les communiqués sont considérablement augmentées. Et personne ne nous donnera plus de garanties - c'est la vérité de la vie.

Total

Pour résumer. En bref, nous avons vu sous différents angles que les méthodes politisées intelligemment depuis longtemps pour évaluer des projets logiciels dans une horloge lapin-perroquet ne fonctionnent que sur des données de test dans des conditions idéales, mais pas dans la pratique. La situation répète les approches et les résultats de l'apprentissage automatique - vous pouvez étudier beaucoup et pendant longtemps pour comprendre que seule l'intuition / l'expérience / l'analogie fonctionne. Il est extrêmement coûteux de tout démonter à l'avance en cubes formels - et, en règle générale, il n'y a pas de temps pour cela. En conditions réelles, pour l'évaluation, il est préférable de s'appuyer sur la méthode de l'analogie, de simples listes hiérarchisées de fonctionnalités, sans hiérarchies ni interdépendances. Développeurs - rendre le code auto-documenté, ne pas compter sur les savoirs traditionnels en décomposition immédiate et écrire des auto-tests pour le code. Mettre en œuvre et suivre les valeurs de communications ouvertes au maximum, visualiser les exigences d'un projet logiciel, une atmosphère chaleureuse et inspirée, de simples évaluations catégoriques feront beaucoup plus pour atteindre la date de sortie que des changements sans fin de bâtons abstraits dans les diagrammes de Gantt et autres. Dans ce cas et seulement dans ce cas, il y a toutes les chances de voir l'équipe du projet avec du champagne dans les mains, avec des sourires, marquant la sortie terminée, coïncidant avec la nouvelle année. Et à propos de la maman du manager dans la salle des serveurs - il vous a juste semblé :-)

Bonnes vacances à tous et bonne humeur!

Évaluation et planification de projets logiciels - sans espèces