Mon dernier article Les
secrets d'une conception réussie de la PI (système d'information) sur l'exemple de la construction de l'hôpital ont provoqué des discussions parfois animées dans les commentaires. Par conséquent, j'ai décidé d'énoncer un certain nombre de thèses sur la base de cette discussion.
Le design n'est pas pour les programmeurs
Très souvent, lorsque vous discutez des méthodes de conception et de mise en œuvre d'un projet de systèmes d'information, vous entendez des critiques de ces méthodes par les développeurs (programmeurs).
Parfois, les développeurs ne voient tout simplement pas qu’en plus d’écrire du code, un projet a une composante organisationnelle sérieuse, qui consiste à identifier, formuler et convenir des exigences - la tâche la plus difficile est d’éduquer les utilisateurs et de reconstruire tous les processus - pas seulement un jour.
Chers programmeurs, afin de savoir CE QUE doit faire un système, vous devez connaître pas du tout C # ou JAVA, mais posséder un domaine. Pour concevoir un système logistique, vous devez être un logisticien: avoir de l'expérience dans ce domaine ou dans plusieurs domaines connexes et similaires. Par conséquent, il existe des analystes commerciaux dont la tâche est de déterminer l'apparence fonctionnelle du système.
Au mieux, le client fournira 30 à 50% des informations nécessaires, le reste doit être pensé de manière indépendante. Et penser est extrêmement critique. Au début, le client ne sait pas ce qu'il veut! En règle générale, un développement conjoint d'un modèle commercial a lieu, et alors seulement une liste de fonctions est compilée.
Cela nécessite une connaissance du domaine. Nous devons comprendre le client en bref: il raconte toujours l'idée, et vous savez déjà pourquoi il en a besoin et surtout, comment elle est organisée, comment une telle entreprise devrait fonctionner, et pas seulement des logiciels.
Notes agiles
L'Agile est-elle une nouvelle religion?
Sujet de discussion Agile vs. La technologie du design (cascade, cascade, cascade) ressemble plus à un différend entre fanatiques religieux! L'article ne concernait pas du tout Agile, mais tous les commentaires portaient sur ceux «flexibles». Les gars! Eh bien, est-il vraiment impossible de regarder plus loin et de voir que pour les deux méthodes il y a une place sous le soleil?!
À mon avis, le rejet brutal d'Agile est une réaction à la poussée extrêmement agressive de cette technologie. À l'écoute des «prédicateurs» des technologies flexibles, il semble qu'avant Agile, le monde n'existait pas, il n'y avait pas beaucoup d'années d'expérience dans le développement de logiciels, et en général, tous ceux qui travaillaient avant nous étaient des imbéciles et des pécheurs terribles, car Agile n'était pas éclairé. Naïf! Une telle vision du monde est typique des adolescents, mais nous ...
Réduisons le degré et essayons d'évaluer sobrement les différentes approches pour chaque projet.
Agile n'est pas adapté partout, tout comme la technologie de conception
Comme l'a écrit un commentateur,
«Agile n'est pas pour l'informatique et pas pour l'informatique. Agile pour les entreprises et les professionnels .
» En effet, il faut parfois obtenir un résultat très rapide, entrer sur le marché avec au moins quelque chose pour miser sur une place et trouver des investisseurs. Ou bien il y a un développement de nouvelles technologies, dont les exigences sont difficiles à faire. C'est définitivement une niche Agile.
D'un autre côté, où trouvez-vous suffisamment de clients prêts à travailler sur des technologies flexibles? 70 à 80% des commandes sur le marché sont des agences gouvernementales qui utilisent une technologie de conception standard. De plus, selon GOST 34. Et ils paient bien pour cela.
De plus, ces méthodes peuvent être combinées en un seul développement: le cœur est créé à l'aide de la technologie de conception et certaines parties sont créées par essais et erreurs (Agile). Eh bien, tout n'est pas possible de penser à l'avance. De plus, la technologie de conception est flexible: il existe une opération d'essai, pendant laquelle beaucoup de choses peuvent changer.
Agile est la façon dont les développeurs pensent
Je ne peux pas garantir pour tout le monde, mais il semble que les programmeurs pensent "de manière flexible", Agile répond à la structure de leur pensée! Après tout, la programmation est une recherche constante des meilleures solutions. Vous vous asseyez sur la tâche, vous ne savez toujours pas comment la résoudre. Vous ne pouvez pas prévoir à l'avance ni le résultat, ni les délais (oui, vous multipliez les délais des développeurs par 6 à 10 fois et c'est la seule façon d'obtenir la vraie image, car ils ont oublié les tests et les améliorations). C'est la pensée de nombreux programmeurs, car ce sont des individus créatifs. Donc, vous n'avez pas besoin de forcer les individus créatifs à s'engager dans l'ennui du projet. Pour ce faire, il y a des analystes, des chefs de projets.
Nous avons réalisé qu'Agile est l'essence même des développeurs intelligents. Mais le client pense le contraire! Et le client veut comprendre ce qu'il paie, "toucher" le résultat futur, avant le début du développement. Et ensuite, le jeu a un seul objectif: il est pratique pour les développeurs, et le client ne dort pas la nuit, réfléchissez si cela fonctionnera ou non, et si cela fonctionne, que se passe-t-il quand cela fonctionne et combien cela coûtera. Mais pour le programmeur Laf, je travaille calmement, ce que je ferai, puis je le ferai quand j'aurai fini, puis je finirai autant que je demanderai, ils paieront tant. N'est-ce pas?
Mais parfois, le client doit le dire: nous faisons de nouvelles choses, donc nous ne sommes pas prêts à prédire le calendrier, le coût ou le résultat. Êtes-vous d'accord? Ensuite, nous le faisons. C'est du moins honnête.
Tournez toujours la tête
Le développement logiciel diffère des autres domaines en ce que vous apprenez quelque chose tout le temps. Chaque projet est comme un nouveau monde. Chaque projet a ses propres exigences. Par conséquent, la tête doit toujours rester allumée. Ne vous attardez pas sur une seule technique, une seule approche. Je dois improviser, presque toujours.
Pour critiquer quelque chose, vous devez l'étudier.
Lorsqu'ils critiquent la technologie de conception ou Agile, les critiques connaissent rarement le sujet de leur indignation. Il y en a très peu qui ont vraiment étudié (y compris les normes: GOST, ISO, IEEE) et essayé d'appliquer sérieusement la technologie de conception. Mais ses critiques suffisent. Très peu d'équipes qui réussissent vraiment (pour que le client soit satisfait!) Appliquez Agile, mais il y a suffisamment de «prédicateurs».
Et encore une fois, ne confondez pas Agile et le chaos. Si vous ne savez pas comment concevoir et choisissez donc des méthodes flexibles, vous aurez un gâchis.
Les applications Agile réussies peuvent nécessiter encore plus d'efforts que la technologie de conception. Plus grande cohérence de l'équipe, qualification de ses membres, capacité à trouver une langue commune avec le client.
Lisez d'autres articles de l'auteur: