Since now collagues filled working hours to issues in GitLab. Each issue belong to a Sprint label, like "Sprint 25", and I calculated total times by looping manually though issues.
Sometimes issue blongs to two Sprint labels, because it had to be reopened. I need only a quick total working hour, but it is quite time consuming to to the sum up.
Is it any better approach to do it? I thought to use milestones instead of Labels. Would you recommend it?
Shall I use GitLab API and write a script to do the calculation?
Related
As of late, I have encountered a problem with my view index being rebuilt all the time and users are having massive issues with this particular view.
I figured it was due to #Date in my selection formula aswell as one of my column formulas. This way the selection formula would be different every second that passes.
So I figured, since I dont need hours/minutes/seconds in my formulas, I would use #Today. This worked out well for 2-3 days and after that the same problem occured again.
So since the problem is back again, I'm not quite sure if that even causes the problem. When this particular view is open, I have issues in every tab that's open in notes, not only this specific database.
Is this a common/known issue? What can I do to avoid this problem?
Yes, it's a common issue that has been well known since the very early days of Notes more than 20 years ago.
#Date is not a problem on its own. #Now and #Today are both problems.
Using #TextToTime("Today") was a popular workaround that was discovered early on. This hid the problem from the indexer so the server failed to realize that the view was out of date. It doesn't solve the underlying problem, though, which is that the view is trying to do something that views simply aren't designed to do. Views are intended to be static, requiring update only when documents change. Introducing time into a selection or column formula makes them dynamic, which kills that presumption and is a major source of performance problems. Using this workaround requires that the view be fully rebuilt every night. You can do that by setting the view index options to "Manual", and setting up a program document to run an updall command with the -T option for the specific database and view once per night. Note that if your users are spread out across timezones, you'll have to pick one specific time as your standard, and if you have servers spread out across timezones you're going to have a lot of fun figuring out how to make them all show the same documents in the view at all times - but that's common to pretty much all approaches to the problem.
See this IBM Technote for a description of several other options that people have used over the years, with their pros and cons. Also see this article by Andre Guirard, which covers date/time issues in great detail.
I would add that the agent-and-folder solution that they describe in the Technote was generally my preferred approach, but it does have an additional disadvantage that they don't mention: it can eventually lead to an obscure situation where the server throws an error "Folder is larger than supported". This error actually has nothing to do with the size of the folder in documents; it refers to fragmentation of internal structures that occurs as large numbers of documents are moved in and out of the folder over time. It could only be fixed by deleting and re-creating the folder, which you can do in your agent code. I believe this problem may be fixed in more recent versions of Domino, but it caused me a lot of grief back in the Notes 6 and 7 timeframes.
A client is asking how long does it take to audit the security of his Drupal module that is 29k lines long. Does anyone know at least what ballpark I should give him? His main concerns are file encryption and user permission.
Nope, not a damn clue :-)
However, whatever value you choose, may I suggest one thing?
Monitor your progress! Tell your client that your initial estimate is (for example) twenty-nine working days but that it depends on a great many factors outside your control.
Tell them you plan to mitigate risks of budget overrun by providing a daily snapshot of progress:
current number of lines audited in total [a].
days spent [b].
current "run rate" (number of lines per day, average) [c = a/b].
number of lines yet to be audited [d = 29,000 - a].
estimated days to completion [e = d / c].
Allow them to pull the plug at any time if the run rate is well below what you estimated.
This basic project management/reporting should give them the confidence that you know what you're doing, and will minimise their exposure considerably, to the point where they'll feel a lot more comfortable about taking you on.
Just on that last bullet point above, you may want to consider giving them a range (say +/-5% of the estimate), but don't get too clever about working out best and worst case based on your best and worst days to date. The power of averaging is that it gives you a "best" guess without having to fiddle too much with figures.
Typical estimates I've seen are that you can expect a developer to review 100-150 lines of code per hour. This is a very rough estimate, and it will vary greatly depending upon the nature of the code and the thoroughness of the review. Also, if you can review code for 8 hours a day, 5 days a week, straight, you're inhuman and amazing; for the rest of us, we need a change of activity to clear the brain.
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 been recently implementing Scrum and one of the things we often wonder is the granularity of tasks within stories.
A few people inside our company state that ideally those tasks should be very finely grained, that is, every little part that contributes to delivering a story should represent a task. They argument that this enables tracking on how we are performing in the current sprint.
That leads to a high number of tasks detailing many technical aspects and small actions that need to be done such as create a DAO for component X to persist in database.
I've also been reading Ken Schwaber and Mike Beedle's book, Agile Software Development with Scrum, and I've taken the understanding that tasks should really have this kind of granularity; in one of the chapters, they state that tasks should take between 4 to 16 hours to complete.
What I've noticed though, is that with such small tasks we often tend do overspecify things and when our solution differs from what we've previously established in our planning meetings we need to create many new tasks or replace the old ones. Team members also refrain from having to track each and every
thing they are doing inside the sprint and creating new tasks since that means we'll have to increment our total tasks in our burndown chart but not necessarily adding a task that aggregates value.
So, ideally, how granular should tasks be inside each story?
Schwaber and Beedle say "roughly four to sixteen hours."
The upper bound is useful. It forces the team to plan, and helps provide daily visibility of progress.
The lower bound is a useful target for most tasks, to avoid the fragility and costs of overspecification. However, occasionally the team may find shorter tasks useful in planning, and is free to include those. There should be no mandated lower bound.
For example, one of our current stories includes a task to send something to another team -- a task that will take 0 hours, but one we want to remember to finish.
The number of tasks in your burndown chart is irrelevant. It's the remaining time that matters. The team should feel free to change the tasks during the sprint, as Schwaber and Beedle note.
On my last assignment we had between 4 and 32 hours per task. We discovered that when we estimated tasks to more than ~32 hours it was because we did not understand what and how to do the task during estimation.
The effect was that the actual implementation time of those tasks varied much more than smaller task. We often also got "stuck" on those tasks or picked the wrong path or had misunderstood the requirements.
Later we learned that when estimated tasks to be that long it was a signal to try to break it down more. If that was not possible we rejected the task and sent it back for further investigation.
Edit
It also gives a nice feeling to complete tasks at least a couple of times a week.
It also gives rather fast feedback when something does not go as planned. If someone did not complete an 8h task in two days we discussed if the person was stuck on some part, if somebody else had some ideas how to progress or if the estimate was simply wrong from the beginning.
Tasks should probably take one-half day to a day, maybe as much as two days sometimes.
Think about it this way: on a more macro level, short iterations promote agility by creating small amounts of value quickly and allowing plans to change as business needs change. On a more micro level, the same is true for tasks. Just like you don't want to spend 3 months on a single iteration, you don't want to spend a week on a single task.
Daily standup meetings can give you a clue that your task size is too big. If team members frequently answer "What did you do yesterday?" and "What will you do today?" with the same answer that they gave the day before, your tasks are probably not small enough.
An example of that would be if a team member regularly answers: "I worked on BigComplexFeatureObject today and will work on it tomorrow" for more than one day in a row, that's a clue that your tasks may be too big. Hopefully, the majority of days a team member will report having completed one task and be about to start another.
Short tasks, 4-16 hours as others have said, also give the PO and team good feedback about project progress. And they prevent team members from going down "rabbit trails" and spending a lot of effort on work that might not be needed if business desires change.
A nice thing about having many smaller tasks is that it potentially gives the PO room to prioritize tasks better and optimize delivered value. You'd be surprised how many "important" parts of big tasks can be postponed or eliminated if they are their own small task.
Generally a good yardstick is that a task is something you do on a given day. This is ideal, which means it's rare. But it does fit nicely into that 4-16 hour estimate (some take half a day, some take two days, etc.) that you gave. Granted, I don't think I've ever spent an entire uninterrupted day on a single task. At the very least, you have to break for the scrum meeting. (At a previous job a day of coding was considered 6 hours to account for overhead.)
I can understand the temptation of management to want to plan every single granular detail. That way they can micro-manage every aspect of it. But in practice that just doesn't work. They may also think that they can then use the task descriptions to somehow generate detailed documentation about the software, essentially skipping that as an actual task itself. Again, doesn't work in reality.
Agile development does call for small work items, but taking it too far defeats the purpose entirely. It ends up becoming a problem of too much up-front planning and having to put in a ton of extra re-planning any time anything changes. At that point it's no longer agile, it's just a series of smaller waterfalls.
I don't think that there is a universal answer to this question that fits every situation. I think that you should try what your collegues are proposing, and after the first sprint or two you evaluate and see if the process needs tweaking to accomodate everyones needs and wishes.
That 4 hour figure sounds like a good minimum to me. I like to think in terms of visible results. We don't have a task per line of code, or a label on a screen, or per refactored utility method surely? But when we get to something that someone else can use, like a public class used by someone else, or a set of fields on a screen that allow some useful action then this sounds like a trackable task to me.
For me the key question is "Do we know we've finished it?" with individual helper functions there's a pretty good chance of refactoring and change, but when I say to my colleage "Here, use this" it either works or it doesn't. The task's completeness can be evaluated.
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
Agile/Scrum development is a very collaborative development process. e.g. it requires developers to continuously communicate & work closely together day-in day-out.
How do you handle your "off" days? Those days that you just don't have energy, can't think straight, don't really have anything to say at the standup meetings, etc.
Just like how athletes have their off days.
I don't think there should really be a day where you don't have anything to say at the standup meeting. Every standup meeting should be used to let the rest of the team know whether or not you met the prior day's commitments.
One problem that I have seen on a lot of agile teams is that the developers don't make concrete commitments on a daily basis, so the daily stand-ups aren't all that effective. If that is an issue, make sure everyone in attendance is setting out concrete goals on a daily basis that can objectively be communicated the next day as either done or not done.
To the rest of your question, I think it is perfectly acceptable to go into a daily stand-up and say that you didn't meet the prior day's objective because you had an off day and use the meeting as an opportunity to make new commitments. If there was a reason why you had an off day that could be clearly identified as an impediment (e.g. too many interruption, unclear requirements/objectives, dev environment frustrations), those reasons should be reported to the whomever is leading the stand-ups (scrum master) because it is their responsibility to make sure those impediments are addressed.
If you don't get anything done, say you couldn't focus and didn't get anything done at the standup meeting. The Scrum Master should try to find out of there is some factor that's distracting you, and try to remove it for you.
Also, if these "off days" are semi-frequent occurrences, try to figure out how often they occur, and include them in your estimates. Scrum is about what's really going on. It's about real timelines. If you know you have 4 off days in 4 weeks, then you should only be claiming 4 days a week worth of work, not 5. (That being said, it's possible that what you can do in 4 days is the same as what someone else can do in 5 days).
Pair programming makes it easier to handle. At least with pair programming, somebody else is there to catch your mistakes early.
Pick a different task/story to work on - so that you get a change on scene. Maybe you've been on the same user story too long.
Gold Cards - (or "fedex days") - where you can work on anything you want: http://www.planningcards.com/iterex/papers/InnovationAndSustainabilityWithGoldCards.pdf What's noticeable about "gold cards" is that the team that introduced them found that they didn't cause a drop in productivity. This would suggest that it's better to take somebody out of the process on an off day and let them do something constructive of their own choosing than let them work unproductively.
Depends if you're running the meetings, many people opt for the "Daily Scrum" whilst working on projects, but often they are time wasters and unnecessary. Structure your meetings around when things are completed, if you're completing and re-assigning tasks everyday, then yes, a daily meeting is a good thing, but realistically you can schedule and discuss a number of tasks in one meeting and then re-visit later in the week. Ideally the most efficient meetings usually consist of one weekly meeting (Monday) and quick progress catch up (Wednesday - Thursday). If you're the project manager, insist that team members respond to you directly when they complete work before the next meeting takes place. If you're holding official daily meetings, you're likely burn out with in a month! (and so are your staff). If you have to do daily meetings, make them quick catch ups, set at the same time everyday and only offer the most relevant information and only have one proper meeting during the week. If you'd like to know what to do on your "off days", I can only suggest that you cancel the meeting, take a Berocca, walk around the block, complete your filing and actually do some work instead of holding relentless meetings for a change.
G'day,
As mkedobbs mentioned, you should mention it in the stand-up meeting.
Maybe you need to look at what's making you have an "off" day and communicate that with your team members.
Is it due to you banging your head against a problem and you're losing motivation? Mentioning it in the stand-up may reveal another team member who has previously come up against the problem. They have maybe even solved it, or their experiences and observations may be slightly different to yours but the combination of two heads may solve the issue for both of you.
Is it due to your user story turning out to be much bigger than expected and you're feeling overwhelmed? Raising the issue in the stand-up will help resolve the problem. Maybe this particular user story should be considered a user theme or even a user epic and needs to be broken down into several user stories.
Is it because the user story you finished up with is not what you normally do? Discussing this in the stand-up may uncover team members that do have experience in the particular area covered by the user story. And those team members may be able to provide pointers to help you, maybe directly with the work itself, or with some other resources to help you come up to speed.
These are just a few reasons as to why your "off" day may be directly due to your current work. But definitely don't just stay silent though! Mention it at the stand-up so that any potential problems may be addressed sooner rather than later.
HTH
cheers,
I have off days. My team has off days.
If it is happening a lot or if it is the same people, then root cause and action is needed. This might be a good topic for a retrospective if the whole team is affected or one-on-one if it is an individual.
As for the answer, you are part of a team. The team picks up the effort, just like any other issue. If you team has issues with this, you probably don't have a well formed team and just have a bunch of individuals fending for themselves.
Generally at the start of an "off" day, it isn't clear that the day will go badly. It is only after a few stumbles that it becomes clear that it isn't going to be a good day. I'd still try to get something done but sometimes the progress is minuscule. The following day's stand-up is when to say, "Yesterday, I didn't get much done. I had an off day," or something similar to note that I do recognize that things didn't go well and I'd try to do better today.
Sometimes I'd change what I'm doing that day, as that can sometimes help. I have had times where I get a few off days in a row, which generally is indicative of needing to take a personal or vacation day and try to recharge myself to get back in the saddle again.
I am going to be implementing a burn down chart for our project management system. It's going to be using Open Flash Chart 2
The system knows when the project starts and when it's estimated to be completed. It also knows the story points and how many hours they each take.
Users write each day how many hours were worked on each story point they are assigned.
From the charts I've looked at, they usually show what the status is each day. And the projected completion date.
Should I expect each day to be 8 hours or 8 hours * users working. Or should i just show hours remaining and let the chart normalize itself (since many users can be working on it in the beginning and few at the end (or the opposite)
Has anyone created a burn down chart in open flash chart 2 and do you have any other tips for creating something like this.
The decision about how many hours constitute the sprint and what duration it will take is something that should be done at the sprint planning stage. Obviously the number of resources you have and the available hours they have each day will determine the total duration. Once you get to creating and updating your burndown chart you’ll be showing the total hours remaining on each day as opposed to breaking out the number of hours per day or number of resources; this has no bearing on the effort remaining (although obviously relates to the ability to complete that effort within the sprint period).
The issue you’ve raised is one of velocity; you’ll need to decide whether you’re working at a constant pace (same available resources over sprint duration) or variable pace (more resources up front, for example). Most burndown charts show a “steady pace” line so you might just need to think about what this looks like in a variable velocity sprint. I’m afraid I can’t comment directly on Open Flash Charts but hopefully the other info above is of use.