Dans le développement logiciel, on dit qu'il y a 3 variables d'ajustement pour planifier la sortie d'un logiciel : la qualité, la date de sortie et le nombre de fonctionnalité.
Or, si on fait bien notre boulot, on ne veut pas que la qualité soit mauvaise et donc il ne nous reste que 2 variables (même si en entreprise, la hiérarchie nous pousse souvent à jouer sur cette variable les dates et fonctionnalités ayant été fixées à l'avance).
De longues dates, on jouait plutot sur la variable date de sortie car on avait fixé les fonctionnalités et les dates étaient alors repoussées continuellement.
Hors, depuis on c'est aperçu que la cadence (ce dont parle mark S.) est importante et influe sur la qualité finale (meilleur planification des développeurs du fait de l'habitude --lecture entre les lignes : on est moins enclin à réduire la phase de test --,...)
Et, c'est l'une des raisons pour laquelle cette notion est incluse dans les nouvelles méthodes (agiles) de gestion de projets : xp, scrum,...
Je pense justement que pour un projet comme une distribution, si tous les projets qui la constitue avait la même cadence, les problèmes d'intégrations seraient moindre. Tu sais d'avance que tu auras une nouvelle version à intégrer même si tu ne connais pas (exactement) 6 mois avant la liste (complète) des fonctionnalités.
Tu n'as plus besoin de te poser constamment la question : Est-ce que la qualité de la version beta en cours de développement est-elle suffisante pour l'intégrer dans ma distribution?
La gestion de projet à date fixe est, il me semble, une bonne chose et c'est pourquoi de nombreux projets l'on adopté (noyau Linux, kde, gnome,....).
Mark S. plaide juste pour avoir la même cadence et l'avoir de façon synchronisée.
[^] # Re: Et je continue de penser que c'est une mauvaise idée
Posté par cosmocat . En réponse à la dépêche Vidéo : Mark Shuttleworth et Linux : Ergonomie et cadence. Évalué à 10.
Dans le développement logiciel, on dit qu'il y a 3 variables d'ajustement pour planifier la sortie d'un logiciel : la qualité, la date de sortie et le nombre de fonctionnalité.
Or, si on fait bien notre boulot, on ne veut pas que la qualité soit mauvaise et donc il ne nous reste que 2 variables (même si en entreprise, la hiérarchie nous pousse souvent à jouer sur cette variable les dates et fonctionnalités ayant été fixées à l'avance).
De longues dates, on jouait plutot sur la variable date de sortie car on avait fixé les fonctionnalités et les dates étaient alors repoussées continuellement.
Hors, depuis on c'est aperçu que la cadence (ce dont parle mark S.) est importante et influe sur la qualité finale (meilleur planification des développeurs du fait de l'habitude --lecture entre les lignes : on est moins enclin à réduire la phase de test --,...)
Et, c'est l'une des raisons pour laquelle cette notion est incluse dans les nouvelles méthodes (agiles) de gestion de projets : xp, scrum,...
Je pense justement que pour un projet comme une distribution, si tous les projets qui la constitue avait la même cadence, les problèmes d'intégrations seraient moindre. Tu sais d'avance que tu auras une nouvelle version à intégrer même si tu ne connais pas (exactement) 6 mois avant la liste (complète) des fonctionnalités.
Tu n'as plus besoin de te poser constamment la question : Est-ce que la qualité de la version beta en cours de développement est-elle suffisante pour l'intégrer dans ma distribution?
La gestion de projet à date fixe est, il me semble, une bonne chose et c'est pourquoi de nombreux projets l'on adopté (noyau Linux, kde, gnome,....).
Mark S. plaide juste pour avoir la même cadence et l'avoir de façon synchronisée.