J'ai l'impression qu'ici il y a une ignorance crasse de ce qu'est la méthode SCRUM.
Le principe du sprint c'est de découper le temps de travail en périodes courtes pour ne pas se perdre dans 20000 deadlines différentes et de faire un état des lieux et avoir l'opportunité de réétablir les priorités entre chaque période, trouver des pistes d'améliorations. On les adopte coe.on veut mais c'est à ça que servent toutes les cérémonies (planification, daily, revue et retrospective)/de la méthode SCRUM. C'est justement fait pour avoir l'opportunité de pouvoir prendre du recul.
Ça n'a rien à voir avec le fait de sprinter et tout faire vite en ne se concentrant que sur du code et en oubliant le reste.
La documentation tu la prends en compte dans l'effort nécessaire à effectuer une tâche. Il y a même des tâches dédiées à la recherche, les spikes, où le travail délivré est obtenir une information.
Et quoiqu'il en soit toute la partie veille techno que tu fais n'es pas forcément inclue dans le sprint. Si la politique de ta boite dit que tu peux dédier 10% ou 20% de ton temps de travail dans de la veille et de la formation, tu le prends en compte dans la planification de tes sprints pour ne pas êtee surchargé de tâches et d'avoir ce temps que tu peux consacrer.
Moi perso je préfère avoir un chef de projet qui sait qu'il va avoir les tâches A B C réalisée dans les 15 jours que de travailler en waterfall ou kanban et d'avoir tout le temps quelqu'un sur le dos et des priorités et deadlines qui changent tout le temps, ou de se rendre compte 6mois/1 an après que les specs et le cahier des charges était foireux et qu'on est bon pour tout refaire différemment.
[^] # Re: Ça s’appelle la prolétarisation des cadres
Posté par Psychofox (Mastodon) . En réponse au journal Et l’intelligence humaine, alors ?. Évalué à 10. Dernière modification le 25 septembre 2025 à 07:48.
J'ai l'impression qu'ici il y a une ignorance crasse de ce qu'est la méthode SCRUM.
Le principe du sprint c'est de découper le temps de travail en périodes courtes pour ne pas se perdre dans 20000 deadlines différentes et de faire un état des lieux et avoir l'opportunité de réétablir les priorités entre chaque période, trouver des pistes d'améliorations. On les adopte coe.on veut mais c'est à ça que servent toutes les cérémonies (planification, daily, revue et retrospective)/de la méthode SCRUM. C'est justement fait pour avoir l'opportunité de pouvoir prendre du recul.
Ça n'a rien à voir avec le fait de sprinter et tout faire vite en ne se concentrant que sur du code et en oubliant le reste.
La documentation tu la prends en compte dans l'effort nécessaire à effectuer une tâche. Il y a même des tâches dédiées à la recherche, les spikes, où le travail délivré est obtenir une information.
Et quoiqu'il en soit toute la partie veille techno que tu fais n'es pas forcément inclue dans le sprint. Si la politique de ta boite dit que tu peux dédier 10% ou 20% de ton temps de travail dans de la veille et de la formation, tu le prends en compte dans la planification de tes sprints pour ne pas êtee surchargé de tâches et d'avoir ce temps que tu peux consacrer.
Moi perso je préfère avoir un chef de projet qui sait qu'il va avoir les tâches A B C réalisée dans les 15 jours que de travailler en waterfall ou kanban et d'avoir tout le temps quelqu'un sur le dos et des priorités et deadlines qui changent tout le temps, ou de se rendre compte 6mois/1 an après que les specs et le cahier des charges était foireux et qu'on est bon pour tout refaire différemment.