<commit_before>= Projets : Instructions générales

== Démarrage d’une itération

=== Rôles
* Une équipe de _n_ personnes est constituée de _n/2_ (arrondi au-dessus) sous-équipes : des binômes d’architectes développeurs et une sous-équipe de un ou deux Scrum Master / Product Owner (nommée ci-après « le SM/PO » pour désigner la sous-équipe, même quand ils sont deux)
* Sous-équipes doivent changer à chaque itération ; le rôle de SM/PO doit être réparti égalitairement

=== Responsabilités
* SM/PO : vérifie le respect des _tâches_ à délivrer ; réoriente les tâches en cas de problème de prérequis ; vérifie la qualité des rendus, entre autres, en relisant les propositions avant soumission ; vérifie que le projet fonctionne toujours après fusion ; est responsable de la cohérence du tout
* Un binôme d’architectes développeurs travaille sur une ou plusieurs tâches dans une itération. Une tâche peut consister à compléter une tâche précédente (ajout de tests unitaires, correction bugs, …).

=== Plan
* Le SM/PO commence l’itération en indiquant dans le README du projet un plan indiquant sur quoi portera cette itération, en accord avec l’équipe et le client. 
* Le plan de l’itération contient une découpe en tâches et pour chacune une affectation à un binôme et ses pré-requis éventuels (d’autres tâches).
* Conseil : une découpe en tâches très élémentaires simplifiera grandement votre travail, surtout au début.
* Ceci se fait par une PR, que je dois approuver avant le démarrage du travail.
* Une mission importante de l’équipe est de s’assurer que le projet converge vers un ensemble cohérent de fonctionnalités exploitables dans la branche `main`. Tentez de terminer en priorité les tâches presque finies qui ne sont pas encore dans `main`, par exemple, avant de commencer de nouvelles choses.

En interne, réfléchissez à un calendrier pour éviter de coincer les sous-équipes qui dépendent des autres et à un plan de repli. C’est la responsabilité principale, mais pas exclusive, du SM/PO.

== Instructions de livraison
Chaque itération se conclut par une livraison.

Dates de livraison précisées dans le programme du cours. https://www.wolframalpha.com/input/?i=Plot%5BPiecewise%5B%7B%7B-1%2F2*x,x%3C+2%7D,%7B-2%2F22*(x-2)-1,+2%3C%3D+x+%3C+24%7D,%7B-1%2F24*x-2,+24%3C%3D+x%7D%7D%5D,+%7Bx,+0,+72%7D%5D[Non respect] des dates : −0.5/20 pour 2h de retard, −3 (en tout) pour 24h de retard puis −1 par jour supplémentaire.
<commit_msg>Rephrased teams<commit_after>= Projets : Instructions générales

== Démarrage d’une itération

=== Rôles
* Une équipe de _n_ personnes est constituée de _n/2_ (arrondi au-dessus) sous-équipes
** une sous-équipe est constituée de un (si _n_ est impair) ou deux (si _n_ est pair) Scrum Master / Product Owner, nommée ci-après « le SM/PO » pour désigner la sous-équipe, même quand ils sont deux
** les autres sous-équipes sont constituées de binômes d’architectes développeurs
* Les sous-équipes doivent changer à chaque itération ; le rôle de SM/PO doit être réparti égalitairement

=== Responsabilités
* SM/PO : vérifie le respect des _tâches_ à délivrer ; réoriente les tâches en cas de problème de prérequis ; vérifie la qualité des rendus, entre autres, en relisant les propositions avant soumission ; vérifie que le projet fonctionne toujours après fusion ; est responsable de la cohérence du tout
* Un binôme d’architectes développeurs travaille sur une ou plusieurs tâches dans une itération. Une tâche peut consister à compléter une tâche précédente (ajout de tests unitaires, correction bugs, …).

=== Plan
* Le SM/PO commence l’itération en indiquant dans le README du projet un plan indiquant sur quoi portera cette itération, en accord avec l’équipe et le client. 
* Le plan de l’itération contient une découpe en tâches et pour chacune une affectation à un binôme et ses pré-requis éventuels (d’autres tâches).
* Conseil : une découpe en tâches très élémentaires simplifiera grandement votre travail, surtout au début.
* Ceci se fait par une PR, que je dois approuver avant le démarrage du travail.
* Une mission importante de l’équipe est de s’assurer que le projet converge vers un ensemble cohérent de fonctionnalités exploitables dans la branche `main`. Tentez de terminer en priorité les tâches presque finies qui ne sont pas encore dans `main`, par exemple, avant de commencer de nouvelles choses.

En interne, réfléchissez à un calendrier pour éviter de coincer les sous-équipes qui dépendent des autres et à un plan de repli. C’est la responsabilité principale, mais pas exclusive, du SM/PO.

== Instructions de livraison
Chaque itération se conclut par une livraison.

Dates de livraison précisées dans le programme du cours. https://www.wolframalpha.com/input/?i=Plot%5BPiecewise%5B%7B%7B-1%2F2*x,x%3C+2%7D,%7B-2%2F22*(x-2)-1,+2%3C%3D+x+%3C+24%7D,%7B-1%2F24*x-2,+24%3C%3D+x%7D%7D%5D,+%7Bx,+0,+72%7D%5D[Non respect] des dates : −0.5/20 pour 2h de retard, −3 (en tout) pour 24h de retard puis −1 par jour supplémentaire.

{'fraction_non_alphanumeric': 0.07086930335274041, 'fraction_numerical': 0.02128086729572375, 'mean_word_length': 4.923900118906064, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3657974', 'n_tokens_mistral': 1736, 'n_tokens_neox': 1689, 'n_words': 688}