Bon tout le temps de la journée. C'était au tour de parler de la conception des projets. D'après ma propre expérience, je sais qu'il est parfois plus difficile de créer un projet à partir de zéro que de ranger ce qui existe déjà. Cela est largement dû à l'héritage que vous ou vous laissez derrière vous. Dans cet article, je vais essayer de vous dire à quoi cela mérite une attention particulière et vous suggérer un plan court pour le suivre.
Compréhension du projet
Avant de planifier quelque chose, vous devez comprendre quel projet vous devez mettre en œuvre. Pour ma part, j'ai identifié plusieurs catégories de projets, tels que:
- Un artisanat unique est un projet visant à créer une sorte de concept graphique et à le vendre à des investisseurs. Les caractéristiques distinctives de ce type de projet sont:
- Documentation insensée. L'idée de base est claire, mais les analyses de rentabilité sont dans un chaos complet, et il n'y a pas de trous logiques à considérer.
- Délais. Jusqu'à 3 mois de la rédaction de la documentation au prototype.
- Il n'y a aucun plan de développement et aucun autre soutien n'est prévu.
- Petite équipe. Habituellement, jusqu'à 5 personnes, y compris les concepteurs.
- Manque de processus métier. Toute interaction est chaotique, basée sur la communication interpersonnelle, la clarification des points clés et / ou l’invention en déplacement.
- Les rôles sont flous. Il n'y a pas de répartition claire des pouvoirs et des domaines de responsabilité.
- Pas de données réelles. Toutes les données sont générées pour la «beauté» et adaptées pour un meilleur affichage.
- Pour accélérer le développement, les dépendances externes sont pleinement utilisées.
- Une startup est un projet qui est configuré pour implémenter une idée spécifique, avec un développement ultérieur. Habituellement, ces projets sont développés selon un modèle en spirale et, pour cette raison, ont presque les mêmes caractéristiques distinctives que le premier type (artisanat unique):
- Répartition claire en étapes. Minimum: termes et liste de fonctionnalités qui doivent être implémentées dans un laps de temps donné.
- Documentation relativement saine. Analyses effectuées, repères pour les étapes d'achèvement définies, des améliorations sont souvent apportées au cours du sprint. Ils utilisent le plus souvent la cascade, malgré le fait qu'Agile le prétend.
- Délais moyens pour la fonctionnalité principale. En moyenne, de 6 à 12 mois.
- Aux étapes initiales, des dépendances externes sont utilisées, qui finissent par changer pour leur propre implémentation.
- Petite équipe. Habituellement, jusqu'à 7 à 10 personnes.
- Il y a une séparation des rôles, mais la responsabilité est floue.
- Un projet peut muter. À un moment donné, le concept ou l'approche de mise en œuvre peut changer. Cela est généralement dû aux exigences des investisseurs, à une idée initialement défaillante ou à des erreurs d'architecture.
- Données en direct conditionnelles. Exécution dans des groupes de discussion ou analyse de données en direct à partir de ressources tierces. Certes, cela ne se produit pas toujours ...
- Un système d'information est un projet qui met en œuvre une idée avec des plans d'intégration dans des services tiers.
- Il y a un plan de développement.
- Documentation clairement écrite. Minimum: description de l'API documentée.
- Vous devrez peut-être intégrer des services tiers, installer des béquilles ou reconstruire des parties du système.
- Il existe des versions intermédiaires, des correctifs.
- Équipe moyenne. Habituellement de 10 à 20-30 personnes.
- Séparation claire des responsabilités.
- Exigences de sécurité: après l'analyse, des cas sont créés qui peuvent conduire à l'effondrement du système.
- Du temps est consacré aux tests.
- Utilisé par Agile.
- Il y a presque toujours un arriéré.
- Seules les dépendances externes coûteuses à implémenter seules sont utilisées. Il est pratiqué sur un pied d'égalité avec ceux exclusifs.
- Un système fermé est un projet volumineux conçu pour répondre aux besoins spécifiques du client, avec un raffinement supplémentaire.
- Client spécifique.
- Il y a un plan de développement.
- Documentation de conception pour le développement. Pour aider les utilisateurs, une documentation séparée a été rédigée à la demande du Client.
- Différenciation des droits des utilisateurs.
- Il y a presque toujours un arriéré.
- La taille de l'équipe est généralement supérieure à la moyenne. En règle générale, de 10 personnes à une perte de fréquence cardiaque.
- Utilisé par Agile. De temps en temps, des tâches supplémentaires arrivent qui doivent être mises en œuvre à tout prix.
- Manifestations inattendues. Les demandes ont lieu à la demande de la direction, de sorte qu'un circuit de test réalisable ne sera jamais redondant.
- La solution Saas est un projet volumineux avec une configuration flexible et une personnalisation supplémentaire pour un client spécifique.
- Système multimodulaire. Le système est divisé en plusieurs parties. Qui peut être utilisé individuellement, même en dehors de la portée d'un projet spécifique.
- Planification claire. Minimum: les coûts de main-d'œuvre sont estimés pour la mise en œuvre des fonctionnalités. Le temps est venu pour la modernisation et la refactorisation.
- Documentation volumétrique. Presque tout est décrit, en règle générale, y compris les cas de test.
- En règle générale, il n'y a pas de dépendances externes et leurs propres implémentations de parties du système sont écrites. Même s'il existe des implémentations tierces.
- Plusieurs équipes de développement. Chacun est responsable de sa part du développement, que ce soit le support ou le front.
- Testez la couverture de tout et de tout. Des tests automatiques, unitaires, de régression et d'intégration sont utilisés.
Toutes les gradations sont conditionnelles et les types fluides sont le plus souvent trouvés. Je veux noter que tous les types peuvent muter les uns dans les autres, la seule nuance réside dans le coût de la modernisation. Par exemple, le projet était à l'origine un «artisanat unique», puis a évolué vers un «système fermé». Habituellement, cela conduit à une réécriture complète ou presque complète du système ou de sa refactorisation. Comme vous le savez, ce n'est pas économiquement faisable. Pour la même raison, il est conseillé de comprendre quel type de projet vous devez créer à partir de zéro et d'essayer de déterminer son sort futur.
Pour déterminer le type de projet, ci-dessous j'ai posé des questions, ayant reçu une réponse à laquelle il vous sera clair ce qu'ils attendent de vous:
- Le but du projet?
- Une liste complète de ce qui doit être mis en œuvre?
- Y a-t-il de la documentation?
- Quels sont les délais? Des dates précises sont souhaitables.
- Une interaction externe est-elle prévue avec des systèmes tiers, ou le projet aura-t-il une API externe
- Y a-t-il des développements?
- Taille de l'équipe?
- Qui est responsable de quoi? Qui définit les tâches, qui accepte, qui a des droits de veto.
- Existe-t-il des plans de développement et quels sont-ils?
- Qui est le client?
- Y a-t-il un budget pour l'achat de solutions clé en main?
- Sur quelle méthodologie prévoyez-vous travailler
- Y a-t-il des analogues?
Comme vous pouvez le voir, la liste n'est pas si longue. Cependant, pour une raison inconnue, peu de gens posent de telles questions avant de commencer à faire quoi que ce soit. Vous demandez pourquoi devrais-je comprendre le type de projet?! Vous devez toujours faire vivre le projet pour toujours?! En gros, vous avez raison, mais il y a des nuances, comme dans une blague torride. Ces nuances sont des ressources et des délais. N'oubliez pas que nous travaillons pour le bien des affaires et réalisons les tâches. Lorsque vous connaissez le type de projet, vous pouvez sacrifier quelque chose sans un pincement de conscience pour atteindre vos objectifs.
Sélection de technologies
Dans le choix, il est préférable de respecter la règle: la technologie ne doit pas être une supernova, mais aussi obsolète. Si la technologie ou le cadre est nouveau, cela peut entraîner des problèmes tels que:
- Recherche de personnel qualifié
- Perspectives de développement: dans les premiers stades, le développement peut mourir, ou, inversement, si la technologie est ancienne, les bogues devront être traités par eux-mêmes.
- Manque de solutions clé en main pour les nouvelles et manque de mises à jour pour les anciennes.
Cette liste de problèmes concerne non seulement la technologie, mais également les dépendances de tiers. Tout ce qui précède peut enterrer le projet dans l'œuf.
Avant de choisir quelque chose de spécifique, réfléchissez plusieurs fois. Créez un tableau des avantages notoire avec des facteurs d'importance pour le projet.
Cet exemple concerne un projet fictif:
Le nom de la fonctionnalité du projet.
| Ratio d'importance du projet
|
|---|
Travailler avec des formulaires
| 3
|
Acheminement
| 1
|
Facilité d'écriture d'animation
| 0,3
|
Comme le montre le tableau, les critères de sélection importants sont le «travail avec les formulaires» et le «routage». La simplicité de création d'animation pour ce projet n'est pas significative. Ensuite, nous allons mettre à jour la table en ajoutant de nouvelles colonnes technologiques. Dans notre cas, il y en aura deux.
Le nom de la fonctionnalité du projet.
| Ratio d'importance du projet
| Technologie 1
| Technologie 2
|
|---|
Travailler avec des formulaires
| 3
| +
| ±
|
Acheminement
| 1
| +
| ±
|
Facilité d'écriture d'animation
| 0,3
| +
| -
|
Sur la base des données du tableau, nous comprenons que le travail «Technologie 2» avec les formulaires et le routage est boiteux, et créer une animation, c'est comme appeler Satan. En conséquence, le poids spécifique de cette technologie est de 2. Vous demandez pourquoi 2? Tout est simple! Si vous définissez ±, alors dans cette technologie, nous mettrons en œuvre une fonctionnalité spécifique, mais avec une sorte de «béquilles», ou plus de main-d'œuvre. Dans notre comparaison, la «Technologie 1» sera plus rentable, avec un total de 4,3. Je pense que l'explication sur la formation des montants n'est pas nécessaire. Ce tableau fonctionne non seulement avec la technologie, mais avec tout ce qui nécessite une comparaison et une sélection dans la liste. L'essentiel est de ne pas oublier que plus vous écrivez de critères, plus il vous sera facile de faire un choix.
L'architecture
Actuellement, il est possible de choisir parmi une variété de services différents qui fournissent des outils pour la conception architecturale. Certes, aucun d'entre eux n'a d'inconvénients, pour certains, ils sont critiques, mais pour quelqu'un non. Comme je suis «oldfag», je préfère un morceau de papier et un stylo ou un tableau et un marqueur.
Afin de comprendre ce qu'il faut saisir en premier lieu, vous devez décrire les principales parties du système, puis choisir la façon de construire l'architecture. En règle générale, dans la pratique, seuls trois sont utilisés:
Décroissant - les développeurs poussent à partir de gros nœuds du système et vont vers les plus petits. Le sens de l'architecture est que les composants prioritaires sont de grands nœuds qui en contiennent de plus petits.
Croissant - les développeurs poussent à partir de petites pièces et passent à de plus grandes. Le sens de l'architecture est qu'au début, beaucoup de petits composants sont créés, et que de plus grands sont déjà assemblés à partir d'eux.
Le monolithe est une architecture indivisible, souvent appelée «héritage». En fait, il s'agit d'une structure rigide, dont le changement nécessite des solutions sans «béquilles». C'est la pire option, mais, comme tout dans notre monde, elle a le droit d'exister. Le monolithe est utilisé pour implémenter des fonctionnalités spécifiques et ne prévoit pas de les maintenir à l'avenir. Par rapport à d'autres, la vitesse de cette approche est beaucoup plus rapide. Eh bien, juste parce que vous pouvez fermer beaucoup les yeux.
Le choix de l'architecture dépend des objectifs du projet et de la vitesse de développement. Habituellement, la première méthode est utilisée lorsque les délais ne sont pas épuisés et que le nombre de modules volumineux est faible. Sa caractéristique est qu'il est possible de représenter avec précision la relation entre des modules spécifiques. Parmi les inconvénients, je peux noter un long temps de développement associé à une séquence d'actions.
La deuxième méthode est préférée lorsqu'une vitesse de développement élevée est requise et qu'il n'y a aucune compréhension de l'architecture de niveau supérieur. Une caractéristique est les nombreux petits composants qui sont parfois utilisés dans différentes grandes unités. Il convient de noter que presque tout le développement peut être effectué en parallèle, sans tenir compte des autres tâches. Les inconvénients de cette approche seront les composants qui ne répondent pas aux exigences de l'architecture de niveau supérieur et, par conséquent, ils devront être réécrits ou créer la possibilité de personnalisation.
Comme le montre la pratique, toutes les techniques de développement sont réduites à une approche en spirale, caractérisée par une accumulation progressive de fonctionnalités. Je ne juge pas approprié de l'examiner dans le cadre de cet article.
Planification
La soi-disant «feuille de route» vous aidera à faire votre travail plus efficacement. En fait, il s'agit d'un calendrier, avec des délais conditionnels pour la livraison d'une fonction particulière. Les dates peuvent être reportées, mais, comme le montre la pratique, avec une mise en œuvre correcte des points ci-dessus, la modification atteindra 30%. En pratique, cela représente généralement 10 à 15%. La planification vous permettra de suivre l'avancement du projet, voir l'affaissement, faire des ajustements sous forme de ressources ou un décalage des délais, etc.
Dont plus tard ils vous remercieront
Tout projet commence par la documentation, et plus il est, mieux c'est! Alors ne soyez pas paresseux - nous documentons TOUT. Oui, cela prendra un certain temps, mais par la suite, cela peut vous sauver de la colère des dirigeants si quelque chose se passe mal, pas de votre faute. N'oubliez pas non plus qu'après votre apparition sur le projet, les gens devront comprendre ce que vous avez créé. Et sans documents, ce ne sera pas facile.
Conclusions
Cet article décrit comment agir et quoi rechercher lors du démarrage d'un projet. Ces étages sont universels pour l'avant, l'arrière, les tests ou tous ensemble. J'ai délibérément évité les spécificités de la technologie, afin de ne pas être trompeur.
Lorsque vous avez le choix de la pile technologique à utiliser, de l'architecture et que vous devez déterminer le calendrier du projet, le tableau ci-dessous peut vous aider:
Type / caractéristiques du projet
| Embarcation jetable
| Démarrage
| Systèmes d'information
| Systèmes fermés
| Solutions Saas
| Quelques autres projets
|
|---|
Nombre de personnes de moins de 5 ans
| | X
| X
| X
| X
| |
Nombre de personnes de 7 à 10
| | | | | | |
Nombre de personnes de 10 à 30
| X
| | | | | |
Quantité supérieure à 30
| X
| X
| | | | |
Date d'achèvement jusqu'à 3 mois
| | X
| X
| X
| X
| |
Délai de livraison de 6 à 12 mois
| | | | | | |
Période de plus de 12 mois
| X
| | | | | |
La documentation
| | | | | | |
Exigences d'intégration avec d'autres systèmes
| | | | | | |
Client spécifique connu
| | | | | | |
Soutien supplémentaire prévu
| | | | | | |
Planification
| | | | | | |
Les rôles sont clairement définis
| | | | | | |
Dépendances externes autorisées
| | | | | | |
Il existe des données en direct pour les tests et les analyses.
| | | | | | |
Exigences de sécurité
| | | | | | |
Test requis
| | | | | | |
Nécessite une documentation ou des instructions sur le produit
| | | | | | |
Implémentation modulaire requise
| | | | | | |
Plusieurs équipes de développement
| | | | | | |
Total
| | | | | | |
Comment utiliser le tableau, je pense que tout le monde a déjà deviné, mais juste au cas où - exactement comme avec le précédent, seulement avec un petit ajout sous la forme de cellules remplies. Cela signifie que la valeur ne peut pas être utilisée pour ce projet. Veuillez également noter que le tableau peut être incomplet, ajoutez les lignes que vous jugez nécessaires.