On avait pas ce découpage artificiel en période de n semaines.
Il ne faut pas oublier aussi que la méthode SCRUM est juste un exemple de résultat d'une méthode agile. C'est fait par des gens qui ont expérimenté les méthodes agiles et sont arrivés à une organisation stable et qui leur convient.
L'idée des méthodes agiles, c'est surtout d'adapter les choses en fonction des besoins. Tu vois qu'il y a un truc qui ne sert à rien, tu l'enlèves. Tu vois que c'est la merde tous les mois parce qu'il manque un truc (genre tu fais pas de tests avant de livrer), tu l'ajoutes.
Si tu ne sais pas par où commencer pour mettre ton projet en place, SCRUM te donne un exemple de façon d'organiser les choses, qui peut servir de point de départ à faire évoluer ensuite.
Si tu n'aimes pas les sprints et que ce n'est pas pertinent dans ton cas, tu peux prendre une méthode qui ressemble plus à Kanban: il y a une liste de trucs à faire, tu pioches dedans quand tu es disponible pour démarrer une nouvelle tâche, il y a un suivi individuel de chaque tâche.
Dans mon cas on pratique un mélange des deux: il y a une planification par sprints parce que ça permet d'estimer la capacité de l'équipe (prévoir à peu près combien de tâches on va pouvoir compléter chaque mois et chaque trimestre), mais si il y a une tâche qui dure 2 mois de suite, ce n'est pas bloquant, il faut juste tenir compte du fait que une personne ne va faire que ça pendant 2 mois.
Et pour les sprints qui ne seraient pas tenables: dans SCRUM c'est l'équipe qui choisit combien de "points" (et donc de tâches à compléter) sont prévues dans chaque sprint. Si vos sprints ne sont pas tenables, il suffit de moins les remplir. Bien évidemment, ce n'est pas facile à expliquer au management, mais ça, ce n'est pas le problème de la méthode SCRUM (qui n'a peut-être pas été conçue pour fonctionner avec un management hostile à ce genre de choses).
[^] # Re: Ça s’appelle la prolétarisation des cadres
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et l’intelligence humaine, alors ?. Évalué à 8.
Il ne faut pas oublier aussi que la méthode SCRUM est juste un exemple de résultat d'une méthode agile. C'est fait par des gens qui ont expérimenté les méthodes agiles et sont arrivés à une organisation stable et qui leur convient.
L'idée des méthodes agiles, c'est surtout d'adapter les choses en fonction des besoins. Tu vois qu'il y a un truc qui ne sert à rien, tu l'enlèves. Tu vois que c'est la merde tous les mois parce qu'il manque un truc (genre tu fais pas de tests avant de livrer), tu l'ajoutes.
Si tu ne sais pas par où commencer pour mettre ton projet en place, SCRUM te donne un exemple de façon d'organiser les choses, qui peut servir de point de départ à faire évoluer ensuite.
Si tu n'aimes pas les sprints et que ce n'est pas pertinent dans ton cas, tu peux prendre une méthode qui ressemble plus à Kanban: il y a une liste de trucs à faire, tu pioches dedans quand tu es disponible pour démarrer une nouvelle tâche, il y a un suivi individuel de chaque tâche.
Dans mon cas on pratique un mélange des deux: il y a une planification par sprints parce que ça permet d'estimer la capacité de l'équipe (prévoir à peu près combien de tâches on va pouvoir compléter chaque mois et chaque trimestre), mais si il y a une tâche qui dure 2 mois de suite, ce n'est pas bloquant, il faut juste tenir compte du fait que une personne ne va faire que ça pendant 2 mois.
Et pour les sprints qui ne seraient pas tenables: dans SCRUM c'est l'équipe qui choisit combien de "points" (et donc de tâches à compléter) sont prévues dans chaque sprint. Si vos sprints ne sont pas tenables, il suffit de moins les remplir. Bien évidemment, ce n'est pas facile à expliquer au management, mais ça, ce n'est pas le problème de la méthode SCRUM (qui n'a peut-être pas été conçue pour fonctionner avec un management hostile à ce genre de choses).