Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We are thinking of moving from Scrum to a more Kanban style of development, however one thing that is not clear to me is how to monitor progress under Kanban.
I have read that progress can be measured by monitoring the cycle time of each story and then presumeably applying this time to the number of outstanding stories. But this seems to me to be dependent on the size and complexity of the stories which could all be different.
I have also seen burndown charts being used, so would there be a chart for the entire release? As the backlog is not fixed (unlike during a sprint) would you just allow it to burn up/down as the pending backlog is amended by the PO? I guess as you get closer to release the backlog should be less volatile allowing you to burndown to completion.
After further thought I think my problem is that our managers like the 'illusion' of control that a burndown chart brings. They tend to see it (wrongly in my opinion) as a schedule and so are able to make judgements like the project is 'on schedule' or 'behind schedule' or whatever. I cant quite see how this is replicated in Kanban. Maybe thats a good thing.
For a whole project the best way to track progress is Cumulative Flow Diagram. Learn more about CFD from this presentation. You can also learn from CFD about things like bottlenecks etc.
For a specific tasks it really depends on your approach. If you have small features (like 1-2 days of development) on Kanban board you can see the status directly on the board since features are moving fast through the workflow.
If you use bigger features, you may want to split them into smaller tasks. This is basically how we work with our features: for bigger features (like 5-10-day long) we split them to development tasks (we don't put development task on the board though). Then I can say that task A has 3 out of 4 development tasks completed so we're doing well. Additionally we estimate the length of development tasks so I can distinguish between 1-hour long and 8-hour long tasks. For small features we have just a single development tasks which is developing the feature.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have been trying to learn the basics of software engineering principles, but I have come across a question that I cant find enough detail on to answer, any help would be appreciated:
For each of the process models (i.e. waterfall, incremental, prototyping
and spiral), how does the model handle a significant change in requirements late in the
development?
Thanks in advance.
I think this question can be simplified - broadly speaking there are two types of software development life cycle:
Iterative (or agile) methodologies like Scrum and Extreme Programming.
Sequential (or "big design upfront") methodologies like waterfall.
The iterative methodologies rely on the experiential feedback from within the project. In Scrum, the sprint review provides guidance concerning what can be achieved in the next sprint and the review of the product backlog can promote the latest requirements to the top of the priority list. In iterative methodology, the evaluation phase of the increment can feed into the planning for the next iteration.
These two examples show a clear point at which the methodologies can adapt and react to new requirements.
There are of course some specific details beyond this broad stroke explanation. For example, a Scrum team wouldn't actually change scope until the end of the sprint - unless the sprint was completely abandoned. As a result there could be a small delay before new requirements could begin implementation.
With the more traditional methodologies such as Waterfall, accommodating adaptation is more difficult because you are constrained by the current phase of the series of phases. To adapt requirements it's likely going to involve non-optimal design and implementation because of the nature of the change being bolted on. If the changes in the requirements were significant enough the entire development may be abandoned and restarted. At least with the agile methodologies you will have already developed, or in fact shipped, some increment of business value.
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
While doing planning sessions using Rapid Board what are some reasonable ways to make sure each person on the team has a decent enough amount of work for the length of the sprint?
e.g. if you have 10 people on the team, how can you quickly see if 1 person only has 2 hours worth of work? Are you supposed to wait for them to speak up or can this be done through Greenhopper somehow?
The best way to make sure that everybody has work to do throughout the sprint, is to let them sign up for work every time they complete the previous task. This means that the members will be "pulling" work, rather than having their work "pushed" onto them.
If you conduct a daily scrum - daily - you will find out pretty quickly that someone is not signing up for new work - that he's either stuck on what he has, or not picking new work. Essentially, if you break up your work into small enough tasks, you will know what is going on within a day.
All this will work for you regardless of which software tool you use to track your sprint.
If you are using Jira, (and your project can afford it) I would suggest looking into the add-on "Green Hopper." It is also made by Atlassian and does a lot of what you are asking for. You can view individuals and see how much work they have as well as how much free time is remaining.
You can also drag the stories (Jira issues represented as virtual index cards) into different iterations (sprints) and onto different people. As well, it will help you to run your daily standup (using it as the scrum board), however YMMV.
m
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I work for a web development company, and quite often, some of our projects come back from the client after being released, with small bugs.
This frustrates my boss as it means we must carry out development work to fix the issue, for which we are not getting paid for.
How can we prevent errors from ever occuring, or is this just something that should be taken into the initial cost?
Our philosophy, time versus money applies to your circumstance as well. The more time that is spent on unit testing, the less likely it is that code will contain bugs after it is released. At the same time, the more time your spend unit testing the less profitable the code is.
We take a more cavalier approach. Our programmers test their own code, pass it off to a fellow programmer for testing, and then a final review and unit test is performed by a supervisor. If all three tests pass, the code is stamped complete and is passed on the end users.
Bugs are an inherent part of programming and must be anticipated as inevitable. No amount of testing can truly guarantee that code is 100% bug free.
Some good methods of avoiding writing bugs are found at this site.
http://sites.google.com/site/yacoset/Home/how-to-avoid-writing-bugs
Released software will always contain some bugs, even the big companies like MS, Google and apple can't release without bugs. Ofc you can do lots of thing to prevent it, like unit testing, smoke testingen, stress testuing ect. ect., but there will always be bugs. thats as certain as rain when you'r on holiday in England.
Make sure you discuss stuff like this in the sell proces. For example 3 weeks aftercare(bugs fixed for free), after that the can buy maintaince hours
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
How do you start planning a fairly large project? Do you immediately start writing up the major classes and break it down further and further? Do you sit down and draw out some UML?
I'm designing my first large project (well, large compared to the other ones) and I'm looking for ideas.
I suggest reading about agile methodology and scrum.
Large Projects would be beneficial when used Agile scrum methodology.
Agile methods divides your projects into smaller sprints giving one the time to prioritize the main features to be concentrated & completed.
Continuous interaction with client means less ambiguity, more real value. The client would see live ideas before final. So more improvising at very early stage with ample of time to make it better.
Bug fixing process gets speedy. Less the bugs, more efficient the Project!
By using time-boxed, fixed schedule Sprints of 1-4 weeks, new features are delivered quickly and frequently, with a high level of predictability. This also provides the opportunity to release or beta test the software earlier than planned if there is sufficient business value.
Improves Quality. By breaking down the project into manageable units, the project team can focus on high-quality development, testing, and collaboration. Also, by producing frequent builds and conducting testing and reviews during each iteration, quality is improved by finding and fixing defects quickly and identifying expectation mismatches early.
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
When working on a project - I always estimate my tasks and calculate how long it will take me to finish. So in the end I get a time-span in which the project should be finished (it rarely is).
My question is - do you record your data and assumptions use in your estimates during a project and use them for later projects or refined estimates on the same project?
If so - how do you record such data and how do you store them?
I used an excel-sheet - but somehow (cannot imagine how that happened ;)) I tend to forget to fill in new assumptions or gained information. On the other hand it is not really readable or useful for evaluating my predictions after finishing the project - to learn from it for the next project.
Sounds like what Joel wrote FogBugz for.
I had a discussion with a friend recently about a pragmatic variation of this, more specifically, the feasiblity of using the coarse level evidence of when code is checked in.
Provided you work in a reasonably cohesive manner, your checkins can be related, at least through the files involved, to some work units and the elapsed time used to determine an average productivity.
This fits well with the Evidence-based Scheduling approach included in FogBugz. If you happen to have been spending time on other things to an unusual degree, then in future you will be more productive than the checkin rate suggests. Any error is on the safe side of over-allocating time.
The main flaw, for me, in an approach like this is that I typically interweave at least two projects, often more, in different repositories and languages. I would need to pull the details together and make a rough allocation of relative time between them to achieve the same thing. In a more focused team, I think repository date stamps may be good enough.
Isn't that what project managers are for? ;)