[Nicolas Noullet]

Hi,

iceScrum provides an integration with version control tools:

Git & SVN

It enables linking commit with tasks thanks to a special mark-up tag that developers have to add to their commit message.

Such link provides traceability between code modifications and tasks, which is nice. Even further, it provides traceability between code modifications and the business items that required them (commits are indeed displayed on stories, aggregated from their tasks). Thus, it makes it possible for someone, e.g. a developer, to know what business need lead to modifying a specific piece of code.

Does this answer your question?

[Nicolas Noullet]

Hi,

Any story in the Sandbox or in the Backlog can be split by the Product Owner, regardless of its type (user / technical / defect or epic).

A difference is that the default action suggested in the menu of an Epic story (in its details) is « Split », while it’s not the case for the other types (user / technical / defect). Such Epic story cannot progress further than the story backlog, so they MUST be split in order to be eventually developed by the team, that is why we visually encourage splitting it.

[Nicolas Noullet]

Hi,

The point of Feature color is to help visual management when dealing with stories. This allows the human mind to take a shortcut and categorize stories automatically, which is really handy when dealing with dozens of stories which are displayed in the same backlog.

Tasks would not benefit that much from in turn inheriting this color. Indeed, unlike stories that don’t show their feature explicitly, tasks are grouped by story in the task board and the story name is displayed. The feature color is also already visible (left border of the row). Finally, unlike features and stories which are both business items, tasks are technical items so it can be useful to leverage visual management to classify them according to technical criterias rather than business ones. For example, for the development of a client/server application you can pick green for tasks dealing with frontend development and blue for the backend.

[Nicolas Noullet]

Hi, do you still face this error?

If so, could you try from another browser?

• Cette réponse a été modifiée le il y a 6 années et 3 mois par Vincent Barrier.
• Cette réponse a été modifiée le il y a 6 années et 2 mois par Nicolas Noullet.

[Nicolas Noullet]

Bonjour,

Nous avons effectivement détecté ce problème hier (02/07), l’avons corrigé dans la foulée et le correctif a été déployé dans la soirée. Désolé pour la gêne occasionnée.

[Nicolas Noullet]

Bonjour,

Merci pour ce commentaire très détaillé et bien étayé. A ma connaissance c’est la première fois que nous recevons un argumentaire qui tient la route pour motiver la possibilité d’ajouter des colonnes dans le Kanban des tâches !

D’après notre expérience, les pratiques de validation / review / merge / recette / déploiement varient énormément d’une équipe à une autre et à ma connaissance aucune méthode ne structure l’ensemble de ces points. Ils dépendent du produit développé, des technologies utilisées, de la maturité de l’équipe, des pratiques d’ingénierie, des outils…

Certaines pratiques suscitent des états intermédiaires. Un des dangers de créer des colonnes dédiées et que cela vient légitimer ces états intermédiaires, ces « stocks » qui coûtent à l’équipe car ils n’apportent pas encore de valeur. Dans Kanban, la reduction de nombre de colonne est d’ailleurs vue comme une amélioration. Bien sûr, des contraintes externes rendent parfois la tâche compliquée, par exemple un déploiement en continu sur une infra matérielle embarquée paraît impossible. Par contre sur l’exemple des blocages, si il est fréquent d’avoir des tâches « stucked » alors cela est un vrai frein à l’agilité de l’équipe. Il serait intéressant de remonter la chaîne des causes de ces blocages et de les prévenir plutôt que d’avoir à les subir.

Comme vous l’avez noté, iceScrum peut supporter un workflow plus riche via par exemple les couleurs des tâches (personnalisées et bientôt associées à un label), ou les tags. Le fait qu’une tâche est bloquée est également représenté dans iceScrum, mais cela vient effectivement remplir la colonne « In progress ».

Comme vous l’avez également noté notre positionnement est différent de nos concurrents, dont certains sont plutôt des gestionnaires de ticket avec une sur-couche agile, d’autre des outils agiles plus orientés sur Kanban que Scrum. Nous prenons bien sûr en compte vos retours dans les perspectives d’évolutions d’iceScrum. En attendant, compte tenu de vos pratiques, un outil plus orienté Kanban semble plus approprié.

Bonne continuation !

[Nicolas Noullet]

4 to 7 seconds is indeed too long. Here are the way server side performance can be improved, and we most of them are already in use but they sure can be further tweaked and refined:
– database cache: store in memory data from frequent database queries, thus avoiding db query
– controller cache: store in memory the response for a given request, thus avoiding all the underlying work: logic, db query, serialization
– custom marshalling: query only part of the data for some requests, thus avoiding db queries, serialization

By saying « how many elements », I meant for example how many stories do you have in your project (you can see that on the « All » backlog in the « backlogs » view), roughly how many releases and sprints…

[Nicolas Noullet]

We agree on your observation that in some cases too much data is loaded, often re-loaded, and this is sometimes part of why iceScrum can feel slow on big projects, but it is often not the bottleneck.

Indeed, part of the time is lost on the browser side itself when many elements are displayed, e.g. when showing a big backlog or task board. This is due to the underlying mechanisms of the framework we use (Angular) and it is not really straightforward to fix, but we are working on it.

However, we know too little about your issue to be sure about your case. Can you be more specific: what time it takes to iceScrum to display which view with how many elements?

I have answered on the contribution / building iceScrum topic on the GitHub issue you commented.

Anyway, thanks for the feedback regarding the UI and the new version, glad you like it!

[Nicolas Noullet]

Bonjour,

Les textareas peuvent maintenant être redimensionnés verticalement dans iceScrum 7.15 :

iceScrum v7.15

Nicolas

[Nicolas Noullet]

Content que ça fonctionne, merci à vous pour vos retours !

[Nicolas Noullet]

Bonjour Yoann,

Concernant le format et le contenu de l’export, vous pouvez exporter les stories en .xls ou .csv grâce à une App https://www.icescrum.com/fr/documentation/data-export/.

En effet, la v7 propose des fonctionnalités additionnelles sous forme d’Apps à activer sur un projet : https://www.icescrum.com/fr/documentation/apps/. Les Apps ne sont disponibles qu’avec une licence et sur la version Cloud d’iceScrum.

Les informations que vous souhaitez sont incluses dans ces exports : les tests d’acceptation, commentaires et sprint font chacun l’objet d’une colonne dédiée.

Comme vous l’avez noté, dans la vue « backlogs », il est possible d’exporter un backlog de stories. Avec l’App ci-dessus, les choix « xls » et « csv » seront eux aussi disponibles. L’App rajoute également des menus d’exports dans les vues détaillées des releases et des sprints, permettant d’exporter respectivement toutes les stories de la release (un zip avec un fichier par sprint) ou d’un sprint.

Une autre option consiste à créer des backlogs à l’aide de filtres personnalisés via l’App dédiée : https://www.icescrum.com/fr/documentation/custom-backlogs/. Vous pouvez alors exporter spécifiquement les stories qui remplissent certains critères.

[Nicolas Noullet]

Bonjour Christophe,

Merci pour vos retours positifs, ça fait plaisir ! Merci aussi pour cette bonne remarque concernant le champ description.

Techniquement ce n’est malheureusement pas si simple (ce champ a bien la propriété « resize: both » mais a un « max-height » qui empêche de l’agrandir verticalement. Retirer ce max-height ne suffit pas, l’affichage est alors incorrect du fait d’une interaction avec un autre élément).

En tous cas nous avons ajouté cette suggestion dans notre backlog.

N’hésitez pas si vous avez d’autres retours !

Nicolas

[Nicolas Noullet]

Bonjour,

En effet il n’y a plus de vue de recherche globale pour le moment.

Il est possible de rechercher une story par numéro dans un backlog. Par défaut, l’application propose les backlogs « Bac à sable », « Backlog », « Finies » et « Toutes ».

Le backlog All permet de rechercher sur l’ensemble des stories. La principale différence avec le Finder est que toutes les stories sont affichées avant la recherche, ce qui peut être long selon la taille de votre backlog.

La v7 permet de créer ses propres backlogs à partir de filtres personnalisés via une App (documentation).

Si vous connaissez le contexte de la story dont vous avez l’identifiant, vous pouvez le rechercher dans un backlog plus restreint que « Toutes », par exemple « Finies » ou un backlog personnalisé « Release 2 » par exemple.

[Nicolas Noullet]

Hello,

Pipeline Scripts are not supported yet, that’s why you can’t find it in the documentation.

We have many things in the pipe right now so it is not in our immediate priority.

I don’t think there is much to do on the iceScrum side and the code for the Jenkins plugin is open:
https://github.com/jenkinsci/icescrum-plugin

If you are willing to contribute, we would be glad to help!

Nicolas

[Nicolas Noullet]

Hi,

Your first sentence is correct: If story A depends on story B, then story B must be finished before A can be.

iceScrum avoids story nesting and offers two solutions instead, depending on your case:

– Case 1: A story is so big that it is actually an individual and valuable product feature that will take several sprints to complete. In iceScrum, this is called a feature. Features have their own backlog, a feature can have zero, one or many child stories and it gives its color to its child stories. A story can have zero or one parent feature. Read more about features in the dedicated documentation.

– Case 2: a story is a bit too big so it is divided into individual separate smaller stories and the original big one disappears altogether so there is no link parent / children. The next version of iceScrum will offer the ability to identify such big stories as « Epic stories » (see Epic story App). The ability to split a story into smaller ones is already available.

In both cases such stories (either stories belonging to the same feature, or stories split from a bigger one) must be « good » stories. That means that they should be made as independent as possible from each others so they can be ordered in the backlog, planned and completed independently.

However, this is not always possible, that is why the story « depends on » feature allows ruling that a story cannot be completed before another one. If a story depends on more than one other story, then you should try to break these dependencies because they would greatly hinder your agility. You can also wonder if the dependency is worth specifying in the tool (light/soft dependencies are fine and are probably not worth specifying).

[Auteur]

Messages