Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We've just set up a Rational Team Concert v3 system. The data was loaded on Friday, but there was an issue connecting to the report data warehouses that was not fixed until today (Monday). We've fixed it, and the data load operations seem to be finishing correctly now.
I'm desperately eager to see a burndown chart - even though I know that in 24 hours we won't really have enough data to make it useful. I'm also eager to see just about any report from the RTC server, as we want to be able to share as much information as possible with the customer, and this is a trial for RTC as a large team tool.
How long should one expect it to take before RTC is able to show reports relating to work items? We've already cached several data updates - but only within the last few hours.
Should we wait 24 hours? 48? should it show up immediately? Haven't found any good heuristics for this on the Rational site.
You need a few things to happen to get a decent burn down chart in RTC
Run the Data Warehouse job (this happens every 24 hours automatically, or you can trigger it manually from the Reports page in the Admin section.
Get some work done - complete tasks, set Stories to Completed, etc. The burn down is a graph over time of work done.
You should see progress on the chart after the two event above occur.
Another thing to check - is that specific burn down chart set to point to the right project and team?
If that does not work - you may want to raise the question with IBM support (sounds like something is wrong, or raise the question on the RTC forum on jazz.net
Closure - It turns out we had several problems. Problems included:
- incorrect account setup on the account syncing between RTC and the data warehouse - we had to both make a new account and setup more privileges for it.
- a truly messed up set of sprints. I don't know what went wrong with the Sprints that were first set up (by default!) with the project, but they did not ever sync properly. Moving tasks to a newly made sprint caused the tasks to show up properly in reports (after a sync), but the original sprints were simply broken. Eventual workaround - make new sprints, same dates, and move all assigned stories/tasks to them.
The final answer was - the data should show up instantly after a sync. If you think your sync shows new data and you don't see a change in your report, then you have a problem.
Other notes - the data in the selection fields in "edited" reports is based on the data in the warehouse. If you don't see a sprint or release in there, it means that the report search criteria is not showing that there is data in the column that you are looking for. Report business logic seems to vary by report - in some cases, not being able to select a sprint (or not having a sprint in the data that matches the "current iteration") - will cause empty reports.
Related
Let's say you have a small project. The team has estimated all the tasks as 300 days of effort.
I have 5 developers in the team, and I want MS Project to tell me when the project will complete considering vacations and working schedule of my team member.
In order to do that:
I'm creating a Task "Development" with fixed work "300d", and task type "Fixed Work".
Then I create 5 resources, and specify a 2 week vacation for one of the developers somewhere in the middle of the schedule.
Then I assign my 5 development resources to this task.
The problem is, the 300d distributed evenly to all 5 development resources. And If one of them have a two weeks vacation in between, due to that particular resource the work will be finished 2 weeks later, where other 4 resources are sitting and doing nothing for 2 weeks. Total duration is 70 days.
what I get
What I want to get is: work is distributed accordingly through all 5 resources unevenly in a way that the whole task finishes as earlier as possible taking most of the usable time from all developers.
That's how I would expect it to work. In that particular case I was distributing hours manually.
what i would expect
Is there a possibility in MS Project to do something like this? Or am I doing something wrong?
There are a couple issues with how you are approaching the problem.
1. Rather than just planning out the manpower hours estimated to be needed for the entire project on a single line item, You should plan out the tasks that will need to be done to accomplish "Small Project"
If you discretely plan out the tasks that need to be accomplished to satisfy the scope of "Small project", you can establish dependency (predecessor/successor) relationships between your tasks and figure out what tasks need to be done before you can move on to others. When you do this it will give you a good idea of how long the total duration of the project will take and likely be more accurate than just relying on an estimate based on the manpower hours estimate your developers give you. Find out what tasks they actually need to do, not just how many hours they think the whole project will take them. This will also allow you to plan out the utilization of your resources better because you'll be able to assign specific resources to specific tasks, and not all of your resources need to be on every task.
2. In general I would avoid using the Task Usage form.
I noticed you are altering resources in the task usage form, but unless you are really experienced with Microsoft Project I would avoid ever touching that, as it's really easy to set the period of performance of resources assigned to a task to be different than the actual period of performance of the task itself. This will cause MS Project to behave unusually, and it can be hard for an unexperienced user to understand why. This usually leads to pain and frustration. This leads me to my next bit of advice:
3. If you really want to specify a resource's vacation time, it's better to adjust the calendar associated the resource to exclude those dates as working dates.
In your situation with only 5 resources on your project, this can be fairly easy to do. You can accomplish this 2 different ways (I'll start with the easiest option):
1. You can add resource specific exclusion dates to the default calendar in your project
You can accomplish this by opening the Resource Sheet table and then clicking the Project tab then Change Working Times. If you have the Resource Sheet open instead of the Gantt chart, you can specify the resource that is going to be effected by the exceptions:
In this example you can see that I would be excluding (removing) 8/23/21 thru 9/3/21 as working days for the SW Engineer resource, without needing to change the calendar used by the resource completely.
2. You can completely change the calendar used by particular resources to be different than the default calendar set for the project.
You can accomplish this by going into the Resource Sheet and opening the Base Calendar column:
From here you can assign any calendar that exists in the project to the resource. Of course this means you would need to create the calendars and assign exclusion dates to them.
To create a calendar, click the Project tab then click Change Working Times. Click Create New Calendar on the form that opens up and give it a name:
From there you can add exclusion dates and all that.
Note: In a larger project with many resources, I would recommend not messing with the calendar for the resources at all. It just gets hard to deal with when there are a lot of resources.
The current interval of 1 second and max of 60 seconds is too small and issues may be missed.
When viewing the live metrics stream page of Application Insights the interval on all graphs are 1 second, and it only goes up to 60 seconds. I am trying to use this as a monitoring page to keep an eye on recently released or updated function apps. For this I need to be able to change the interval to view more data at once without having to keep watch on it. Right now if we don't keep watch on it every minute we may miss something important.
I have searched the Microsoft documentation, the git repository, stackoverflow, and various other sites trying to find my answer but the only thing I found was from over 4 years ago and I would hope that this has changed since then.
Live Metrics Stream allows to peek at what's going one right now with 1 second resolution. But it doesn't persist data anywhere. So, data is only stored in UX (browser) and right now only for 60 seconds.
For bigger intervals it might make sense to refer to other Application Insights experiences (including Analytics).
I'm currently making a online mobile game. It's like an online Idle Clicker.
In order to save the data I will use firebase. I'm still deciding if I should use the "Realtime Database" or " Cloud Firestore". (If any of you could help me too I would appreciate).
My main question is: When should I save my data ?
Saving the data every second is crazy because I will spend millions of euros. Even saving the data every minute seems not a viable solution to me.
I have searched and I can save the game everytime the user press the Home Button to leave the app. What if the user is playing and the phone dies?
Is there any other better solution that I am not thinking of ?
Thank you very much, Gonçalo
I would use OnApplicationQuit() for this. It's called whenever your game is closed. It won't be called if the device loses power though, so if you're worried about that you could start a timer when the game is opened and do autosaves every 10 minutes or on certain scene switches (if the player exits to the main menu for example).
This thread has more info on the topic that you may find useful.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
In Scrum, there is the process of backlog grooming, which, in-part, deals with the breakdown of epics/big user stories into smaller stories that are easier to estimate and consume within an individual sprint.
In JIRA Agile, I am looking for the proper way to mirror the grooming process and still have a manageable list of backlog items and an accurate tracking of estimation of the stories.
Here's an example of the problem I see:
An epic is created as an individual ticket. (Ticket total: 1)
That epic is broken-down into (let's say) 3 user stories: (Ticket total: 4)
We try to estimate the first user story and realized it's too big, so we break down this user story into 2 smaller user stories (Ticket total: 6)
I now have a backlog of 6 tickets that are to be prioritized and managed, when in reality I should only need to be prioritizing the smallest user stories against each other. Also, I may have put a large estimate on a large user story, and then refined the estimates through estimating the sub user stories. (i.e. Step 3 might have a large user story estimate of 20 points, but the sub stories might total to 13 + 5 = 18)
Am I splitting stories the correct way as it was intended in JIRA?
Should I remove the estimates of the larger user stories once I've sub-divided the story, and only focus on the estimates for the smallest stories to prevent double-counting?
How can I manage user-stories that have ultimately become epics in themselves (and still associate them to the higher-level epic)?
(I've been using the Structure plugin, but it doesn't help me with managing backlog prioritization in the agile board.)
The concept of an epic is that it is a very large user story that requires breaking down.
In Scrum the backlog is a process of just in time refinement. We start with coarse grained ideas and as we get closer to starting work on something we get it in to better and better shape.
It would be quite possible to do all of this with stories. However, many teams find that it is useful to have backlog items that are less defined than a story. Hence the use of epics.
As an example, a team I worked with a few years ago was asked to work on a medical evidence product. They realised that the required work fell into 4 broad areas (i.e. really big stories). There was a clear prioritisation which meant they needed to work on one of these areas straight away and the others could follow on later.
The team decided to break the first area of work down in to normal sized user stories immediately. They added these items to the backlog.
They also wanted to track the other 3 areas of work and so they added epics to represent them.
The team started work on the first area and was making good progress. It was clear that they would be able to start on the next epic in a few sprints time. The Product Owner started to refine the epic by breaking it down a little. They met with the team several times and some stories were further broken down into smaller stories. By the time the team was about 1-2 weeks away from starting on the epic it was in good shape and consisted of stories that could be brought in to planning meetings.
At this point the epic was not of any real interest to the team. They had the detailed stories they needed. The team used JIRA and they did find it helpful to see the epic name on issues as it helped them to see the backlog clearly.
My suggestion to you would be:
Add epics to JIRA as place holders for future work
As you get closer to working on them, break them down in to stories
Once an epic is broken down in to stories then you no longer need to be concerned about it
If a story is broken down in to smaller stories, remove the original
You may find that you break epics down in to stories, but still need to keep the epic as there is more work to be done on it. If this happens, it suggests that your epics are too big. I would recommend that an epic should be broken down in to no more than 10 stories (even that is pretty big).
Try to avoid epics that are really categories of work and hence can keep on producing new stories. You might want to use themes or labels in JIRA for this kind of thing.
Epic should not be listed as story rather epic should act as parent to all stories. Stories themselves have only one parent that is epic and not story.
I'm coming from a SCORM end and trying to figure out two related issues with how to do update and find the most recent data (ie, looking for best practices).
In SCORM I'd have a set of activities that would all store their answers and scores (easily understandable from the docs etc). The "how" I'm after is specifically related to resuming the set of activities multiple times, and hitting "reset" and submitting a different answer to a single activity after a statement has been sent in.
From what I read with xAPI it states that statements are immutable - so how would I go about this.
My first thought was that I'd make the statement id generated from the activity id and void the old answer when it changes - but that sounds wrong (not least because it reads like you can't re-use the id even with voiding).
So it looks like the Statement id needs to be unique, which would mean that multiple identical Objects would be found - so would I have to look through every attempt and check for the latest one?
I'm currently looking at using xAPIWrapper in the middle.
Moving from SCORM to xAPI requires a change of mindset. SCORM deals with statuses which get updated; xAPI logs events like a journal.
You can think of it like Facebook. You post a photo of your new cat; a month later you post a photo of your cat 1 month older. There's no need to go back and delete the old post. If you want the latest photo of your cat you just go and get the most recent photo tagged "Ryochet's cat". You can also look at older photos to see how your cat developed. xAPI is like that activity stream on Facebook.
So, if somebody scores 10 points on their first attempt, then 20 points on their second attempt, you'd simply send a second set of statements about the 2nd attempt. There's no need to get rid of the statements about the old attempt, that happened and is useful data to see how the learner developed.