25-02-2012, 01:21 AM
désolé de répondre si tard, mais des conneries au boulot, par fois ça vide l'énergie ^^
Je suis pas forcément le mieux placé pour expliquer les différences mais globalement dans le sprint tu dois avoir des interactions aller retour etc pendant toute la durée, des tests en // du dev, des modifications/adaptations/précisions de besoin pendant les dev, ... , dans un cycle en V quelque soit sa taille, on a des jalons qui permettent des passages de témoin, de l'expression du besoin jusqu'à la fin de la période post go live (passage en mode maintenance)
j'ai utilisé ce terme (pas forcément consacré) pour désigner toute doc technique permettant à une équipe de développement de prendre en main une application, d'identifier rapidement où et comment intervenir
ce qui veut dire, par exemple les docs qui expliquent :
les interfaces avec d'autres systèmes (appels aux web services, bdd, etl, etc...)
les couches applicatives
les modèles de données, de classes, ...
des explications sur les différents modules, sur la factorisation de code, etc...
spec techniques diverses etc...
grosso modo une doc qui permet de savoir où aller et quoi faire avant même d'ouvrir un code source
(24-02-2012, 05:38 PM)Sephi-Chan a écrit : Bien sûr que tu te retrouves avec de petits cycles en V, c'est le principe même des sprints : il faut bien écrire le code. Je ne comprends pas ton raisonnement : comment en arrives-tu invariablement à l'épuisement ?je vois pas le lien entre la notion de cycle en V et "il faut bien écrire le code" (dans le sens ou cycle en V ne se résume pas au code, bien au contraire)
Je suis pas forcément le mieux placé pour expliquer les différences mais globalement dans le sprint tu dois avoir des interactions aller retour etc pendant toute la durée, des tests en // du dev, des modifications/adaptations/précisions de besoin pendant les dev, ... , dans un cycle en V quelque soit sa taille, on a des jalons qui permettent des passages de témoin, de l'expression du besoin jusqu'à la fin de la période post go live (passage en mode maintenance)
(24-02-2012, 05:38 PM)Sephi-Chan a écrit : Qu'est-ce que tu désignes par documentation d'architecture ? C'est abstrait pour moi.
j'ai utilisé ce terme (pas forcément consacré) pour désigner toute doc technique permettant à une équipe de développement de prendre en main une application, d'identifier rapidement où et comment intervenir
ce qui veut dire, par exemple les docs qui expliquent :
les interfaces avec d'autres systèmes (appels aux web services, bdd, etl, etc...)
les couches applicatives
les modèles de données, de classes, ...
des explications sur les différents modules, sur la factorisation de code, etc...
spec techniques diverses etc...
grosso modo une doc qui permet de savoir où aller et quoi faire avant même d'ouvrir un code source