[Nicolas Noullet]

Bonjour,

Ce bug est résolu dans la nouvelle version d’iceScrum : 7.9.1

[Nicolas Noullet]

Bonjour Nicolas,

Les histoires utilisateurs n’ont pas vocation de servir de documentation fonctionnelle exhaustive du produit ; autrement dit ce ne sont pas des listes d’exigences détaillées et à jour vis-à-vis du produit comme on peut en retrouver dans un cahier des charges.

Une illustration simple de cela : imaginons qu’une fonctionnalité de notification par email fasse l’objet d’une histoire (h1). Elle est développée dans le sprint 3, tout se passe bien et l’histoire et validée par le PO. Un retour d’une partie prenante suggère la modification des règles métier qui déclenchent l’envoi d’email. Une nouvelle histoire (h2) est créée dans le backlog, décrivant seulement le résultat du changement de la règle métier, et est développée au sprint 5. Pour savoir ce qu’est censé faire l’outil sur l’ensemble de la fonctionnaltié de notification, h2 ne suffit pas, h1 non plus, il faut connaître les deux et savoir comment certaines règles d’h1 ont été rendues obsolètes par h2. Avec deux histoires c’est encore gérable, mais avec de nombreuses histoires réparties sur plusieurs sprints, on voit que ça deviendrait vite ingérable.

Les histoires sont avant tout un support de discussion entre le PO et l’équipe de développement afin que l’équipe développe la fonctionnalité attendue par le PO. Comme vous le soulignez, certaines précisions seront données par le PO à l’oral et de manière informelle plutôt qu’à l’écrit, c’est exactement le but des histoires utilisateurs et c’est même pour cela qu’on les appelle “histoires”. Cela fonctionne car la connaissance métier est diffusée et partagée par le Product Owner, notamment lors des réunions d’estimation, de planification et les revues de sprint.

Rien n’empêche d’écrire des cahiers de test fonctionnels, notamment utiles pour de la non-régression et pour avoir cette vision “à jour” de ce qu’est censé faire le produit que ne peut pas donner les histoires. Evidemment pour éviter le travail inutile, ces tests peuvent se baser sur les stories et leurs tests d’acceptation, auxquels viendraient s’ajouter les précisions que vous évoquez.

Je ne connais pas précisément votre contexte mais il semble que si il y a des testeurs et recetteurs, ils devraient être intégrés à l’équipe et ainsi bénficier de ces échanges avec le PO. Une story finie à la fin d’un sprint doit être définitivement finie. La validation des stories doit être effectuée pendant le sprint dans lequel elles sont développées, indépendemment du fait qu’il y ait ou non des cahiers de test en complément des histoires.

[Nicolas Noullet]

Bonjour,

Merci, meilleurs voeux à vous aussi !

Nous attendons donc de vos nouvelles quand la configuration aura été mise à jour,

Nicolas

[Nicolas Noullet]

Bonjour,

Merci pour vos retours.

A première vue il manque un point essentiel à votre configuration. En effet notre système de push de données utilise les Web Sockets or ici ils ne sont apparemment pas gérés. Je vous invite à consulter la documentation correspondante pour plus d’informations : https://www.icescrum.com/documentation/application-server/#proxy-ssl.

Si vous regardez la console javascript de votre navigateur en naviguant sur iceScrum, vous devriez voir des erreurs indiquant un échec de connexion du système de push.

Le problème des “1|X” est lié au système de push mais je ne peux pas garantir que corriger le problème que j’ai identifié suffira…

Je comprends votre problématique concernant une commande éventuelle, si nous pouvons faire quoi que ce soit pour faciliter le processus, n’hésitez pas à nous en faire part.

Excellentes fêtes de fin d’année à vous aussi !

[Nicolas Noullet]

Hi Alessandro,

The configuration can be done through manual modification of config.groovy, see https://www.icescrum.com/documentation/config-groovy/#settings_4.

Be sure to add:
icescrum.debug.enable = true
an restart your server to get detailed logs.

As an alternative, post installation config is available in the UI from the administration account but only with a paying license: https://www.icescrum.com/documentation/server-administration/

You can ask for a free 14 days free trial license from your account
https://www.icescrum.com/documentation/license-activation/
It will give you the time to configure your email settings properly (with a test button that should fill the logs in case of errors) and also give you the ability to try other paying features. At the end of the license, iceScrum will keep working normally.

[Nicolas Noullet]

Hi Alessandro,

What was not working is the email notification settings in the user profile. They are indeed fixed since iceScrum 7.6 (https://www.icescrum.com/blog/icescrum-v7-6/) on all platforms, including Docker.

[Nicolas Noullet]

Bonjour Jean Christophe,

Est ce qu’il y a un un front / proxy devant iceScrum ? Ce type de configuration extérieure à iceScrum pourrait être la cause du problème.

Il me semble que vous ne possédez pas de licence professionnelle. Dans le cadre du support inclus dans les license, nous pourrions être à même de prendre le temps nécessaire pour vous aider et corriger le problème.

Concernant la seconde erreur :

[http-nio-8080-exec-7] ERROR StackTrace – Full Stack Trace:
java.lang.IllegalArgumentException: Secure object invocation FilterInvocation: URL: /p/ui/window/backlog/settings

Il est normalement corrigé dans les version supérieurs à la 7.6.

[Nicolas Noullet]

Hi Alessandro,

What bug do you refer to?

[Nicolas Noullet]

Bonjour,

Merci pour votre retour, c’est un défaut connu. Nous n’avons pas encore d’échéance pour sa correction mais c’est dans notre backlog.

Nicolas

[Nicolas Noullet]

Bonjour,

La copy inter-projet est bien implémentée dans la v7, comme indiqué dans la doc. Elle est proposée par une App qui nécessite une license (payante ou d’essai) et qui est activée par défaut en présence de cette license.

Suite à votre message (merci pour les logs), nous avons détecté un bug qui apparaît sous trois conditions :
– vous êtes explicitement PO de plusieurs projets
– vous n’avez pas de license active
– vous essayez de copier une story depuis un des projets dont vous êtes PO
Le comportement attendu dans de telles conditions est que la story soit copiée à l’intérieur dans le même projet que la story d’origine.

Ce bug est corrigé et le correctif sera disponible dans la prochaine version à paraître très bientôt.

Etant donné que vous êtes affecté par le bug, il semblerait que votre license d’essai ne soit pas active.

[Nicolas Noullet]

Hi,

Thanks for the additional report.

The first bug is fixed and the fix will be available in the next major version which should hopefully be available on all platforms (incl. Docker) next friday.

[Nicolas Noullet]

Hello Jean-Christophe,

This is an intended behavior. Indeed, iceScrum needs to run on UTC in order to work properly.

The only downside is that you have to do the conversion by yourself when you want to correlate the logs with dates in your Timezone.

Nicolas

[Nicolas Noullet]

Hello,

Thanks for your feedback. This seems to be a bug, we are investigating. Sorry for the inconvenience.

[Nicolas Noullet]

Bonjour,

En fait la version 7.2 n’a été disponible que pendant une journée car une migration (m1) qu’elle apportait empêchait le démarrage sur certaines versions de Postgres. Visiblement vous n’avez pas été affecté par ce problème.

La 7.2.1 est sortie juste après avec deux modifications :
– la migration apportée par la 7.2 (m1) ne s’execute plus sur Postgres
– une nouvelle migration spécifique s’execute sur Postgres (m2).

En mettant à jour vers la 7.4, iceScrum a tenté d’exécuter m2 alors que vous aviez déjà exécuté m1, d’où l’erreur. Vous avez annulé l’effet de m1 manuellement, ce qui a permis l’execution de m2.

Vous êtes probablement un des seuls à avoir rencontré ce problème : il faut en effet avoir téléchargé la 7.2 pendant les quelques heures où elle été disponible et l’avoir installé sur un environnement Postgres sur lequel m1 n’échouait pas.

[Nicolas Noullet]

Merci pour vos retours.

Un aspect pratique d’abord, si on autorisait la valeur 100 en plus de 0 à 99, l’impact n’est pas anodin:
– on passe à 101 valeurs,
– on passage à trois caractères à afficher (avec un impact potentiel sur le layout) alors qu’une seule valeur les utilisera,
– on rajoute un ordre de grandeur, celui des centaines, alors qu’une seul valeur l’utilisera.

Si on autorisait 100, dans un soucis de cohérence il faudrait donc aussi permettre jusqu’à 999, mais nous pensons que ce n’est probablement pas une bonne idée.

Il n’est pas nécessaire d’éviter que deux stories aient la même valeur. Je ne vois pas pourquoi deux stories ne pourraient pas apporter une valeur métier équivalente. En revanche elles doivent avoir une priorité différente et c’est au PO de trancher, à l’aide de la valeur mais aussi d’après d’autres critères parfois inquantifiables. La valeur numérique synthétisant tous ces critères est la priorité, et non la valeur.

Si les stories sont de bonnes stories, elles ont une granularité fine et n’apportent souvent que peu de valeur prises isolément. Il est donc difficile de faire le lien entre la valeur d’une story et une vraie mesure de valeur produit (bénéfices, satisfaction client etc.), contrairement aux features, de granularité plus grosses.

Avec des valeurs qui vont jusqu’à 100, la différence entre une story qui vaut 98 et une qui vaudrait 99 n’est que d’1%, or la marge d’erreur sur une telle estimation est probablement bien supérieure à cela. Pour la une story qui vaudrait 998 et une 999, la différence est encore plus négligeable. Donner un tel niveau de détail est probablement de l’énergie perdue et de la sur-spécification.

L’outil est certes là pour aider les équipes à implémenter leurs propres pratiques, mais il ne peut pas s’adapter à toutes les particularités sinon il deviendrait une usine à gaz de configuration. Beaucoup de nos concurrents sont d’ailleurs critiqués pour cela.

Notre outil a également une vocation supplémentaire : encourager les équipes à adopter des bonnes pratiques et décourager les mauvaises.

Vous voyez donc que le choix de limiter de 0 à 99 est loin d’être arbitraire, il tient à la fois d’une volonté de cohérence et de bonnes pratiques.

Ceci dit nous ne sommes pas fermés : si les intervalles choisis par vos équipes (0 à 100 ou 0 à 1000) ne sont pas arbitraires mais motivé par un besoin précis, nous sommes intéressés de le connaître.

[Author]

Posts