La version 14.2 est publiée le 13 novembre 2009. La précédente version (14.1) datait du 4 août 2009.

Il n’est pas nécessaire d’initialiser la base de données avec cette nouvelle version.

Les numéros utilisés ci-dessous sont ceux du backlog de produit IceScrum (géré bien évidemment avec IceScrum). Vous trouverez les nouvelles stories réalisées depuis la 14.1, les défauts mineurs corrigés et les bugs connus résiduels dans la version 14.2

Nouvelles stories

• 114 : Guide d’installation en anglais. Le guide d’installation est désormais disponible en anglais et disponible en ligne sur le site (http://www.icescrum.org/index.php/frequently-asked-questions/about-installation/)
• 87 : Sortie PDF des tâches. Dans le PDF qui constitue l’export d’un projet, il y avait un décalage dans la partie concernant les tâches du sprint entre propriétaire/créateur/état. Cela est corrigé.
• 107 : remember me. Cette fonction, disponible au moment de la connexion, permet de se reconnecter automatiquement sur le dernier projet ouvert.
• 106 : autocompletion des rôles dans les user stories. Lorsque des rôles utilisateurs ont été définis, cette fonction complète automatiquement la saisie en cours dans la zone du template de user story en fonction des premiers caractères saisis. De plus, cela permet de connaitre, pour chaque rôle, le nombre de stories liées (visible dans la vue tableau des rôles utilisateurs).
• 105 : vision dans le release plan.  La vision peut être documentée dans une zone d’édition riche associée à une release. On y accède par l’icône en forme d’œil située à droite sur la barre. Une fois le texte saisi, la sauvegarde s’effectue avec le bouton Sauver la vision.
• 73 : suppression de l’info-bulle avec post-it agrandi. On peut agrandir un post-it dans les différentes vues en cliquant sur le coin en haut à droite. Désormais il n’y a plus d’info-bulle intempestive qui s’affiche au survol de la souris lorsque le post-it est agrandi.
• 173 : filtre sur la vue tableau dans le backlog de sprint. Dans le backlog de sprint, on peut filtrer l’affichage. Ces filtres sont désormais actifs également dans la vue tableau.
• 176 : Sonar installé et visible. Sonar est un outil qui permet d’analyser la qualité du code et produire des tableaux de bord (http://sonar.codehaus.org).  Les tableaux de bord IceScrum sont visibles : http://outils.icescrum.org/sonar.
• 86 : affichage du tableau des tâches amélioré. Dans le backlog de sprint, l’affichage a été sensiblement amélioré. Le tableau des tâches virtuel permet de voir les tâches à faire, en cours et finies sur 3 colonnes. Désormais la taille des colonnes est gérée dynamiquement, ce qui perme de mettre plusieurs post-it côte à côte par colonne. Cela est particulièrement visible lorsque la fenêtre du backlog de sprint est agrandie. Avec un sprint de taille usuelle dans Scrum (environ 8 stories et une quarantaine de tâches), il est possible, selon la taille de l’écran de tout voir en une page, sans scroller ni paginer. Cela permet également un meilleur résultat lors de l’impression du backlog de sprint par le navigateur.
• 76 : suppression d’un sprint. Si on supprimait un sprint alors que ce n’était pas le dernier sprint (ce qui n’est pas autorisé) d’une release, le message affiché était erroné : il disait vous devez être ScrumMaster pour supprimer un sprint alors qu’il aurait dû dire « vous pouvez uniquement supprimer le dernier sprint ». Cela est corrigé.
• 77 : Confirmation de la clôture du sprint. Lors de la clôture d’un sprint, il arrivait que l’équipe ait oublié de déclarer des stories vraiment finies comme finies dans IceScrum. La clôture étant définitive, cela provoquait un décalage entre la réalité du projet et son suivi dans IceScrum, notamment dans les indicateurs graphiques. Désormais, lors de la clôture d’un sprint, si des stories sont encore « en cours », une fenêtre pop-up de confirmation présente la liste des stories non finies. L’utilisateur peut alors revenir au sprint courant et déclarer finies ces stories si elles le sont. Dans le cas où ces stories ne sont pas finies, il confirme la clôture ce qui provoque le retour des stories non finies dans la partie « à prioriser » du backlog de produit (néanmoins les tâches associées à ces stories sont conservées).

Autres défauts corrigés

• Bug corrigé : La modification des dates d’un sprint provoque des affichages erronés.
• Bug corrigé : Il arrive que la liste des utilisateurs connectés affiche plusieurs fois le même compte lorsqu’un membre se connecte.
• Evolution : le Product Owner peut créer un build.
• Bug corrigé : quand il y a un nouveau message dans le chat, la notice prévenant le nouveau message s’affiche en dehors de l’en-tête.
• Bug corrigé : Une release à cheval sur deux années s’affiche mal dans la roadmap (les mois de la « timeline » se superposent).
• Evolution : dans les Post-it le texte est tronqué horizontalement sans couper des caractères.
• Evolution : le texte des zones remplies avec l’éditeur riche s’affiche sans les balises html.
• Evolution : l’affichage des vues tableau a été amélioré (en particulier dans la Vue build).
• Bug corrigé : les libellés des Rôles utilisateurs ne sont pas affichés dans le PDF (on a des chiffres au lieu de libellés).

Défauts connus dans la version 14.2

• 354 : mots de passe non codés. Les mots de passe ne sont pas codés avant le transfert http
• 80 : retour à l’état identifié pour une story. La modification (par le PO) d’une story dans l’état accepté la fait repasser dans l’état identifiée alors qu’elle devrait rester acceptée.
• 83 : perte de clic droit. Dans IceScrum, le clic droit est utile pour de nombreuses commandes dans différentes vues. Il arrive, après quelques minutes de connexion, qu’un utilisateur perde l’usage du clic droit. Solution de contournement : déconnexion suivie d’une reconnexion.
• 349 : déplacement d’une story dans le Plan de Release. Il est parfois nécessaire de scroller pour visualiser une story associée à un sprint. Si on souhaite déplacer une story visible après scrolling vers un sprint ne possédant pas encore de story associée, cela n’est pas possible. Solution de contournement : réduire l’affichage (CTRL – avec Firefox) pour retrouver la zone bleue sur laquelle déposer la story.
• 90 : manque de rafraichissement de l’affichage dans la vue tableau de Features. Quand une story est dissociée d’une feature, cela n’est pas mis à jour dans la vue tableau des features. Solution de contournement : déconnexion suivie d’une reconnexion.
• 91 : changement intempestif de langue. Après un changement de rôle, il arrive qu’on se retrouve avec des menus et messages en anglais au lieu du français.
• 355 : message d’erreur après modification administrateur.  Les modifications dans la zone admin (sa/sa) ne sont pas prises en compte. Solution de contournement : il faut redémarrer manuellement le serveur pour que les modifications soient prises en compte.
• 352 : réminiscence d’info-bulles. Il arrive que l’info-bulle obtenue au survol d’un post-it ne disparaisse pas à la fin du survol. Solution de contournement : actualiser la fenêtre dans le navigateur (F5).
• 299 : défauts avec d’autres navigateurs que Firefox. Les tests les plus poussés sont faits avec Firefox. Avec d’autres navigateurs, il peut y avoir des anomalies. Par exemple avec IE8, on ne peut pas passer une tache « en cours » ou « finie » dans le tableau des tâches. Solution de contournement : passer à Firefox.

Ajoutés récemment :

• En vue tests, la zone pour déplacer les post-it est réduite à une petite bande horizontale.

• 385 : date de début de release. La date de création d’une release est substituée par la date de fin de la release précédente.
• 399 : modification story mal répercutée. Quand on modifie une story planifiée, les modifications ne sont pas toujours répercutées dans les autres vues (plan de release et backlog de sprint) ; il faut se déconnecter puis se reconnecter pour les voir apparaître.
• 400 : date de début de sprint mal affichée. Quand on modifie la date de début d’un sprint, elle est mal affichée ; il faut se déconnecter et se reconnecter pour que cela soit pris en compte.
• 401 : plantage sur le tri selon le reste à faire dans le backlog de sprint. S’il y a au moins une tâche non estimée dans la liste, cela provoque une erreur.