Quel processus de développement logiciel utilisez-vous? [fermé]
https://stackoverflow.com/questions/121839
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'ai toujours utilisé le processus de développement piloté par les fonctionnalités pour développer des logiciels. Qu'est-ce que tout le monde utilise et pourquoi le préférez-vous? Je préfère FDD parce que c'est ce que j'ai commencé avec des études fraîchement sorties du collège. Au collège, tout était très libre et mon " client " C’était généralement mon professeur, qui n’avait peut-être pas beaucoup d’expérience dans le secteur en dehors de la recherche pour l’université.
Maintenant, mes clients ne pardonnent pas tellement et je travaille beaucoup dans le domaine médical. Être agile et avoir un haut niveau de qualité est un must!
La solution
Au travail, nous utilisons le processus ICONIX. C'est un sous-ensemble des techniques AGILE et il est basé sur des exigences comportementales. Le processus ICONIX a pour objectif d'être le moins célébré possible, avec le moins de documentation possible - afin de vous permettre de le maintenir facilement à jour (il s'agit d'une grande différence par rapport aux autres processus AGILE, comme le font souvent les praticiens de Windows XP. semble pas maintenir la documentation à jour après le 1er brouillon en prétendant que leur code est la documentation).
Voici un aperçu pratique du processus:
- Brouillon de fonctionnel Conditions requises
- Définition rapide de un modèle de domaine
- Cas d'utilisation de modèles sur la base des étapes précédentes
- Facultatif - Dessinez un diagramme de robustesse à jeter pour chaque utilisation. cas, juste pour comprendre les relations entre tes cours
- Dessinez un Diagramme de séquence pour chaque cas d'utilisation
- Modélisez vos cas de test sur les cas d'utilisation
- Implémenter
- Test
À chaque étape, vous passez en revue votre travail dans son ensemble en mettant à jour votre modèle de domaine (il est impossible de le faire correctement du premier coup) et en ajoutant des commentaires sur vos cas d'utilisation. À la fin de l'étape 5), vous obtenez des classes et une logique prêtes à être implémentées, avec très peu de documentation à conserver si vous re-factorisez ou modifiez quoi que ce soit:
- Diagramme de cas d'utilisation
- Diagramme de séquence pour chaque cas d'utilisation
- Diagramme de cas de test (ou plan de test)
Si vous devez ajouter une fonctionnalité, vous ajoutez un nouveau cas d'utilisation et suivez l'ensemble du processus.
Ressources:
site Web Iconix Software Engineering
Références bibliographiques:
Autres conseils
Méthodologies de développement agiles combinant des pratiques d'ingénierie XP:
- TDD associé à la refactorisation
- YAGNI (vous n'en aurez pas besoin)
- KISS (restez simple, stupide)
- Refactor to Design Patterns
- Programmation par paires avec paires de commutation
- Base de code partagée
- Déployez tôt et souvent
Tout ce dont le projet actuel a besoin.
Je fais beaucoup de consultations pendant mon temps libre pour divers développeurs Web (principalement basés sur PHP). Je n'ai pas encore consacré le temps nécessaire à TDD pour ces projets et nombre d'entre eux utilisent des frameworks existants qui ne facilitent pas vraiment TDD.
Au travail, nous ne sommes pas encore équipés pour TDD. Nous utilisons donc un hybride de processus agiles et basés sur des spécifications de style ancien. Nous essayons d’avancer vers le TDD, mais nous sommes un petit magasin avec des projets existants bien enracinés (beaucoup de travail de maintenance) et un travail d’intégration avec des systèmes ERP. Je pense que je pourrais lancer TDD sur mon propre travail d’intégration (et que je fais des pas en avant dans cette direction), mais le reste est en grande partie une cause perdue.
Il semble y avoir une certaine confusion ici:
TDD porte plus sur la façon dont vous implémentez le code et non sur la gestion du développement global d'un projet logiciel. TDD ne vous aidera pas à choisir les fonctionnalités à planifier, le moment de la livraison ou la définition des priorités.
En revanche, des problèmes tels que Lean / Agile ou même Waterfall concernent ces problèmes de niveau supérieur. (Mon vote est pour Scrum qui tombe fermement dans la zone Lean / Agile.)
XP (Extreme Programming) est intéressant car il mélange les idées de ces deux domaines.
Je pars avec Agile Scrum , cela me donne le sentiment d'être connecté à l'équipe. Et contrôlez bien les jalons et les résultats individuels. Les mêlées du matin sont très utiles. Nous utilisons le modèle de projet Agile Scrum dans Team System http://www.scrumforteamsystem.com/fr/default.aspx
Je suppose que je suis vieille école. Je développe à la spécification du client. Une phase de conception vigoureuse suivie d'un cycle de développement, de test et de correction de bugs sans avertissement. Ensuite, implémentez.
Une fois que la spécification est définie et acceptée, aucun autre changement ne peut avoir lieu. Toutes les modifications doivent attendre que le développement et les corrections de bugs soient terminés. Cela empêche le fluage de la portée et permet au logiciel d'être écrit, testé, mis au point et mis en œuvre. À ce stade, les modifications deviennent des améliorations, de nouvelles fonctionnalités, etc.
J’ai constaté que pour presque tous mes clients au cours des 10 dernières années, environ 90% de ce qu’ils auraient "jeté" pendant le développement, la création d'un champ d'application est considérée comme n'étant pas nécessaire. Je ne peux pas vous dire combien de clients m'ont remercié de les avoir tenus à distance. Donc, je ne sais pas quel processus vous appelez cela, mais cela fonctionne pour moi et pour beaucoup d'autres développeurs que je connais.
Je suis un fan de développement de logiciels Lean , promu par les Poppendieck, largement basé sur les principes de fabrication sans gaspillage, avec Toyota comme enfant d'affiche. Il a beaucoup en commun avec les autres méthodologies Agiles, l’accent est mis sur l’élimination du gaspillage, sur l’utilisation de la théorie de la file d’attente, et sur une approche "juste à temps". état d’esprit (par exemple, spécifier une histoire au dernier moment responsable).
Lean est souvent associé à Kanban , méthode permettant de suivre des tâches via un pipeline. .
Conception par contrat avec un complément de tests unitaires
Nous utilisons la cascade où je travaille mais après quelques efforts de ma part, nous nous dirigeons davantage vers un modèle hybride agile / TDD / CI pour certains de nos nouveaux projets. Si Dieu le veut, nous pourrons abandonner la méthode de la cascade. Chaque version de maintenance que nous effectuons, notre principal client ignore simplement les échéances et nous transmet les modifications d’exigences à la dernière seconde, puis nous regarde sans rien nous expliquer pourquoi nous ne pouvons pas continuer à le faire.
Je plaisante, TDD est vraiment une excellente façon de faire.
TDD Design Driven
La confiance que vous obtenez en sachant qu'un changement de code n'a pas permis de casser quelque chose de subtil est géniale
Je seconde le vote pour Agile. J'explore Lean ces temps-ci, mais comme dans tout processus de développement, vous ne pouvez pas simplement vous arrêter sur votre groupe actuel. Toutefois, certaines fonctionnalités de Lean et Agile peuvent être intégrées à vos processus actuels et obtenir une valeur immédiate.
Mon projet précédent utilisait la méthode de la chute d’eau et en était fier. Ils se sont depuis sevrés de Waterfall et de Prototype, ce qui est une bonne étape.
Je travaille pour une entreprise spécialisée dans le développement Web et le développement de systèmes. Notre modèle de développement est le développement rapide. Nous utilisons la définition la plus moderne, ce qui le rapproche du développement agile. Sans les concepts XP.
Nous utilisons aussi Scrum ... Je pense que les stand-up peuvent être bons à certains égards, mais parfois les 15 minutes rapides deviennent au moins 30.
Mes idées personnelles au cours des dernières années ont été orientées vers le développement Lean, avec une forte influence de tout ce que j'ai appris de XP. Je pense qu'il est important de noter ici que Scrum est un processus de développement insuffisant car il n'influence pas le travail de développement de logiciels, mais le travail d'essayer de gérer le flux de tâches de développement de logiciels. ICONIX a également éclairé ma pensée. Je pense que c'est un excellent moyen d'aborder un environnement basé sur des cas d'utilisation et des diagrammes sans s'enliser dans une bureaucratie contre-productive.
