[eagad]

Sorry that I am the worst at replying to things in a timely manner. The project I’m testing iceScrum with is quite large. It has 2495 Stories, and 12 Releases. Each Release has about 14 2-week Sprints. I appreciate all the improvements made in the past year. I am still looking forward to build instructions that can enable those of us with development skills to help improve the software.

[eagad]

That explains a lot. I’ve seen issues with performance using Angular on other projects as well. I’m not very familiar with Angular myself so I’m sorry I cannot offer any suggestions on that front at the moment.

I did some performance measurements and network monitoring and it looks like you are correct, there is a bottleneck is on the browser side right now. However, I do see network transfer times of 4-7 seconds for each of the REST API calls as well so there is time to be saved there too. I’m not sure how to count the elements you are interested in, so if you have a method for that, I can get that data for you too.

Thank you for your detailed reply on GitHub, I’ll respond there with my thoughts on that subject. 🙂

I’m looking forward to this new era for iceScrum with the massive improvements in v7!

[eagad]

I tried using -Xms8G -Xmx8G and according to OpenShift, the pod is using 3.8 GB now. I don’t see a huge improvement on performance. 🙁

The project I am testing with is quite large, and has been using iceScrum since 2013. In reviewing the network traffic in Firefox, I noticed that doing a browser refresh causes many calls to the REST API to pull all the project data. I think there are two changes here that could improve performance significantly.

(1) Update the REST calls so that the client can request only the data they need to display instead of everything. Initial loads appear to pull data for all the retrospectives in the current release instead of just the retrospective for the current sprint. This is a lot of additional data to load that isn’t needed.

(2) It looks like doing an initial load of the page causes the data for all the tabs to be loaded at once. This is fine except that when I visit a new tab, another call is made to refresh to data on that tab. The data should either be lazy-loaded on demand as each tab is visited or the data should not be reloaded in its entirety when switching tabs. Doing lazy-loading and eliminating full reloads on tab switching would likely improve the perception of performance significantly.

I’ve tried to contribute to iceScrum in the past, but I had trouble building the code from scratch. I was told at the time to wait for v7 because it was such a big change and that the new build process was easier. Do you have a more straightforward build process these days? I’d love to be able to contribute here and there.

I really like the new version over the old one and think you all have done a great job thinking through the UI. I just need to figure out the performance issues.

[eagad]

So far, I haven’t tried setting either one. I was planning to try setting -Xmx 8G and seeing what that does. Do you have a recommendation for those settings I can try?

[eagad]

I pulled down the master branch of https://github.com/icescrum/iceScrum and I’m still having trouble building it. I haven’t worked with grails before so that may be the main problem for me. It seems that the version of grails might be important. Do you have any basic instructions for building the R7 code?

I would like to participate in the beta for R7 too. Please add me to the list. Thanks!

[eagad]

It is good to hear that work is still happening on R7. It seems like it has been a long time since I read that email announcing that version was coming. Is R7 available on GitHub in a branch or are you keeping it under wraps for now?

I get a lot of little requests from developers within our organization, and I wanted to learn the process for building from source so that I could explore and evaluate the difficulty of contributing those enhancements. Most of these are small, but would benefit all users of iceScrum.

The biggest one is probably the ability to record burn-up on tasks in addition to burn-down over time. Users want to improve their estimations and one way to do that is to compare how long they thought it would take to complete a task with how long it actually took to complete the task.

When do you think that you will be releasing an R7 version? Maybe a beta?

[Auteur]

Messages