Tout en étant apprenant à l'Apple Developer Academy @ BINUS, j'ai eu l'opportunité de devenir Project and Product Manager ces 4 derniers mois, en construisant KOBAR, une application éducative de gamification.

En support de mon équipe en tant que Chef de Projet et Chef de Produit, Project Management dispose de nombreux outils utilisables, tant dans la méthodologie de travail que dans son propre logiciel. Pendant 4 mois, mon équipe a utilisé la méthodologie SCRUM où il est devenu une routine pour l'équipe d'organiser des réunions de sprint, des mêlées quotidiennes, des revues de sprint et des rétrospectives de sprint.

• Sprint contrôle le mécanisme de glissement qui limite la surcharge d'afflux,
• La planification de sprint permet une auto-évaluation de chaque tâche qui initie la lucidité et la croissance vis-à-vis du DoD (Definition of Done).
• Le développement de Daily Scrum améliore la coordination entre les équipes pour montrer et exprimer leurs idées.
• La revue de sprint inclut l'équipe scrum ainsi que les autres actionnaires. Ce qui prend les commentaires de l'équipe Scrum et une inspection a également été effectuée ici.
• La rétrospective de sprint offre une chance d'examiner les obstacles pour le moment et de recevoir des suppléments pour le sprint à venir.

Nous utilisons l'assistance de JIRA pour la gestion de projet car dans ce logiciel, nous sommes aidés pour pouvoir déléguer facilement des tâches à chacun, assistés s'il y aura un problème enfant dans le backlog.

"Ceux qui planifient font mieux que ceux qui ne planifient pas, même s'ils s'en tiennent rarement à leur plan." - Winston Churchill

Au début de la période du projet, tous les backlogs peuvent encore être complétés selon le temps prédéterminé. La répartition des tâches, était claire et structurée selon le calendrier souhaité. Cependant, lorsqu'il entre dans la période de développement, il y a beaucoup de choses à ajuster, de sorte qu'il est un peu écrasant pour l'équipe de terminer les tâches confiées.

C'est à ce moment que les problèmes surviennent, souvent lorsqu'une tâche aurait dû être terminée et démarrer le sprint suivant, l'équipe n'a pas été en mesure de la terminer. Au début, nous étions confus pourquoi? le temps imparti n'est-il pas suffisant ?

Mais on sait que le principal problème est,

il y a trop de retard dans un sprint, où nous ne pouvons pas aligner les attentes sur la réalité.

Alors pourquoi ce problème se produit?

• Nous avons surestimé ce que nous pouvions accomplir en une seule itération.
• L'un des éléments de travail était beaucoup plus important que prévu.
• Les injections de service/travail non planifié sont entrés dans l'itération.

Comprendre la cause profonde et trouver comment l'éviter. Mon équipe utilise la rétrospective de sprint pour évaluer la cause et en tirer des leçons. Chaque membre de l'équipe partage son point de vue et comment le surmonter.

Discuter de l'avenir de chaque backlog

• Si le backlog a une priorité élevée, déplacer le même backlog vers le sprint suivant devrait être utile . Peut-être que le temps imparti n'est pas suffisant avec la taille des éléments de travail donc ça va quand même
• Si le backlog a une faible priorité, déterminez si le backlog peut être décomposé et déplacez le travail en attente dans le backlog du produit.

Tout cela basé sur mon expérience et soutenu par les ressources de :

Tous les commentaires sont très appréciés ! s'il vous plaît, contactez-moi ici !

© 2022 Nathania Joyce Irène. Tous les droits sont réservés.