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
Does anybody have any advice on working in a Date Driven Development environment? Essentially, we are updating our RIA every 8 weeks. I work in a small team of less than 5 developers, so I'm concerned about how to manage long-term features that don't fit in small cycles. Additionally, I'm concerned about being in a state of perpetual crunch-time.
Rule 1. Defer features.
If it's not done, (1) defer it to the next release and then (2) figure out why.
"Pushing", "Overtime" and "working smarter not harder" don't actually do much. The point is to be realistic about your plans.
Plans are an attempt to predict the future.
You cannot predict the future.
Therefore, your plans will be wrong. Always.
Rather than rant and rave about "the plan", "the commitment" and "customer expectations", think about this.
Your goal is to deliver features at a pace that is faster than the users can make use of them.
Strive for 2-week increments. Tested, Integrated, ready-for production.
After the first four sprints, you're at 8-weeks, ready to release. You will have built things, deferred things, and wound up with a deferred list at the end.
Many cycles of new features will -- generally -- bother the users with the pace of change. You wouldn't release each 2-week sprint because the users don't like this. If you release too often, you get told to bundle the features together into a bigger release so that the pace of change seen by the users is slower.
You must still do many small cycles. Aim for 2-week sprints where you build some small subset of your bigger backlog.
You just don't release each small cycle.
8 weeks is a lot of time....compared to some shops that have 1 or 2 week releases...so you're fortunate. Some recommendations:
prioritize your maint/bug fixes with the help of your client/business owner after each release and work your way from top of list down...(sounds simple until you get a last minute must have in there)
the development for cycle 'D' should actually start in cycle 'C' in regards to planning and should end 1-2 weeks prior to delivery to ensure proper QA and fixing of found issues
there will always be 'something' to make you question pushing the delivery date - don't give into it - reduce scope/keep to the date
break the larger deliveries into smaller ones and promote in a manner that they are 'there' but no 'live' (beta) - this incremental work might add some extra effort, but should reduce end of delivery QA/bug related issues and risks
track important metrics - for planning and showing progress
Related
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 6 years ago.
Improve this question
In our team we are evaluating to use the kanban board as an organization tool for software development. The development phase will take about 6 months with a team of 5.
We have as input all the functional requirements agreed with the client, business rules and use cases - in other words, macroscopic requirements. We will convert these rules in stories to be "atomic" process units for the kanban board. The kanban itself will be used as a performance evaluation tool and progress roadmap.
The Kanban "prescribes" to have a fixed amount of stories for each stage, but as the software is new and complex, the "stories" will be probably some hundreds - so I guess that putting all the stories in the backlog at the beginning of the development wouldn't be a smart move.
What would it be the best practice for this case?
First, few teams set limits for backlog. Kanban advises work in progress (WIP) limits. Items in backlog are rarely considered "in progress."
Second, considering you, more or less, know the scope of the project it wouldn't make much sense of forcing yourself to artificially limit number of items in backlog.
At the same time you're right that putting a few hundreds items in backlog makes no sense. The board would be overcrowded and its usefulness would drop significantly.
Typical strategies to organize backlog is such cases include:
Keeping epic stories/features in backlog and splitting them into detailed stories/tasks only when you start working in them. This way you have far fewer items, while you're still able to deal with detailed tasks on development stages.
Stacking stories which are going to be a part of the same part of an app. If you already split your scope, there's no point in artificially hiding this information. You can, however, stack work items that are connected or will be done at the same time. It makes backlog cleaner and, once you start building the items, you can unstack them totally easy.
Staging backlog. If you have a rough plan how your development will be going you can have a couple of stages of your backlog. Early one which is a box where you store all the features you will build (it can be even a physical box attached to the board) and later one which shows only work for the very next time period. This way you see fewer items on the board, yet still, technically all the work is there.
Of course mixing all these ideas is possible, and even encouraged, whenever it seems reasonable.
BTW: You can see visualization of a couple of these techniques in this presentation (slide 21).
I must disagree: limits in backlog is a possibility. Probably not in the input column, but for instance if process has some prioritization columns, highest priority column can contain a limit thus saying that one may not push to many high priority tasks, because WIP cannot maintain such pace and they will be hanging dead there.
Kanban board looks like this
Henrik Kniberg in his free book about Kanban describes how setting WIP limit to backlog helps focus on most important functionality first.
I think this is good strategy especially for product owner. Backlog contains only stories to be developed in upcoming period while other stories might be in mind map or 'wishlist'.
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 6 years ago.
Improve this question
I have now a good process for estimating development work for projects, I think how much time it would take me to do it considering the worst case scenario, and then I double that number. For each of my team members I have another ratio (higher or even lower) but the idea is the same.
My problem is the fixes phase, it is very hard to tell up front how much time to reserve for issue resolving as it depends on many parameters (complexity of the project, staff skill level, management and design quality, QA quality etc)
I am still to decide on a percentage from the project pure development estimation that I should always add for the issue fixes (Just the fixes phase untill "go live" / "production" / "next release" etc)
Is there a methodology that defines an actual golden ratio number? does anyone have one?
20%? 50%?
Test Driven development reduces these pains. At the cost of the time you write a test, you instantly (if you actually run your tests) detect regressions.
As you say there are many variables. For me one commonality is that look at the lines added vs the lines deleted. When every commit adds and removes about the same number of lines, those are the bug fixes.
use your SCM to track how many commits / weeks / lines this was.
NOTE: your deleters might be doing more good than your adders in some cases. ( as long as they don't introduce bugs )
On a traditional waterfall style project, we found a good rule of thumb was 20/20/20/40 - 20 HLD, 20 DD, 20 CCUT, 40 integration and test. I've always found that to be useful in that it works both for initial estimates and for a checkpoint when you are part way into the cycle.
From an ongoing post-delivery maintenance, I don't have as good a ratio. Most projects I know, don't even try, they just budget some number of support hours, and figure some will be bugfix, and some will be user handholding.
Addition - realized I ought to clarify my acronyms:
HLD = High Level Design
DD = Detailed Design
CCUT = Code, Compile, Unit Test
I'm pulling from traditional waterfall concepts here as that's where I've had access to the most metrics. So these assume that you'll (more or less) have to do HLD before DD, DD before CCUT and so forth. Practical experience shows they can blend more than a little, but if you have HLD and CCUT happening at the same time, you have some real risks afoot.
As you say bug fixing depends a lot on the code complexity. automated tools like ProjectCodeMeter calculate this by analyzing your source code, it usually gives me between %30 to %60 percent for debugging+testing, depending on the code.
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
I realize there are various kinds of software projects:
commercial (for John Doe)
industrial (for Mr. Montgomery Burns)
successful open-source (with audience larger than, say, 10 people)
personal projects (with audience size in the vicinity of 1).
each of which releases a new version of their product on different conditions. I'm particularly interested in the case of personal projects and open-source projects. When, or under what conditions, do you make a new release of any kind? Do you subscribe to a fixed recurring deadline such as every two weeks? Do you commit to a release of at least 10 minor fixes, or one major fix? Do you combine the two conditions such as at least one condition must hold, or both must hold?
I reckon this is a subjective question. I ask this question in light of searching for tricks to keep my projects alive and kicking. Sometimes my projects are active — but look as if they aren't because I don't have the confidence to make a release or a tag of any sort for a long time.
For all my personal projects and prototype projects I do at work I release builds when the completion criteria for my current milestone is complete.
In essence...
I make a plan, including the things you definitely want and some things that would be nice to have in the next official build
I work on those things until they meet the desired level of functionality as defined in the plan
Then I label a release
On my personal projects I rarely have a timeline (since it's a hobby), so step 2 often has no strict deadlines, in the case where you have deadlines and they arrive but the plan isn't complete then you may have to cut some things from the plan and make a release anyway. In many cases it's better to release something that has only 50% of the planned features but they all work and are well tested than wait until 100% of all the features are fully complete.
We have a release schedule, major release every M months, minor release every N months, where M > N. We know we will need to make a major release every M months as we work with the government and they add required functionality every 6-12 months, and the minor releases are bugfixes or new features as suggested by customers.
Minor releases might get pushed back or coalesced into another release, depending on what fixes/features are going in and how busy we are with the major release.
Approximate turnaround time for a bug found to being fixed in a minor release is 6 to 8 weeks.
It really depends on the project and the urgency of the release. In most cases, I prefer to have a regular build schedule (usually weekly) and stick to it unless an emergency patch is required for a show-stopper bug. However, for production releases, there should be a phased build cycle -- perhaps monthly. As you stated though, it's very subjective.
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
I have friends who have asked me to make websites and most are very small, usually I don't bother with a technical plan but one friend in particular clearly had goals larger than my own and the project is dragging on forever. If I had made a spec before the project I feel like this wouldn't have happened and our relationship would be as solid as before.
So my question is, how can you tell how small is too small? How do you tell when the project you're embarking on is going to end up in a guilt-ridden scope creep nightmare?
If you are going to be charging money (or don't want to be stuck doing the project forever), a project plan is always a good idea. Even if it's just a one-pager outlining what the web site will have (how many pages, any special features) and who is responsible for what. You should factor in that you'll spend 20% of your time (or whatever percentage past experience has taught you) on documentation or non-coding type work, you can give a better estimate of the effort needed. If it's a friend, you might want to tell them that you'll do the first X hours for free, but after that your rate is $Y per hour. Also, keep an accurate log of the time you've spent so that you can show them the amount of effort that is involved. Also, keeping an accurate log helps you estimate future projects.
As you may have already figured out, no project is too small to have at least an informal, written plan. Even if it's just a features list.
A project that does not need a plan is a project that does not need to be even started. In my opinion everything needs a plan, what changes is the extent of that plan. A plan could be just a list of deliverables and some deadline attached to each one. A more robust plan should include time charts, cost, phases, communications howto, dependencies, etc. So I think everything needs a plan, the contents of the plan is what changes depending on the project complexity.
Dwight Eisenhower on planning:
In preparing for battle I have always
found that plans are useless, but
planning is indispensable.
It seems the same in many software projects: you'll find that your plans need to be continually updated and that your first plan was quite different from what you finally completed. But that's okay, it's much better to put some planning in up front than to try something by the seat of your pants.
Agilists try to accommodate such changes in plans by breaking longer term plans into small "sprints" of 2-4 weeks. They'll have more details on the near term sprints, and fewer details on the longer term goals.
You'll especially want to be more detailed and precise if the project is bigger, if you are doing this for an external customer, or if you're attempting something new for you. It's less important (though not unimportant) for smaller projects and types of work you've done before and are very familiar with.
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
For projects that should take between two and six weeks, is Scrum the right way? Having read up on Scrum a bit, I was left with the impression Scrum is an excellent choice for mid to large sized projects.
I've run short projects of around 5-6 weeks using 1 week sprints - I found it useful to have each sprint run from Wednesday->Tuesday - the team was fresher for the final two days of the sprint, and carried through the rest of the week by new stories!
One thing we struggled with in 1 week sprints was getting stories tested - we would sometimes start a new iteration with some stories not formally tested. Here we had to "tweak" the process a little to perform tests over 2 week cycles.
In short, it's doable, and you can still reap the benefits of iterative development. You just might find yourself making a few compromises in the process.
We do Scrum for short projects all the time, I find it it is much more productive for short term stuff than the waterfall approach or similar phasing.
Just one word of warning: start bugfixing from day 2, keep testing intensely. Our first Scrum tries led into truckloads of bugs to fix (for free) after the delivery of the product.
Nowadays we maintain a stringent "not done until free of bugs" policy, per story, which works wonders, without hurting productivity! If it's broken it's not in the release.
Have fun at Scrumming!
I think the point of scrum is that it delivers business value throughout rather than just at the end, I guess you have to decide whether your project can do that and whether it needs to do that.
Also read this, very simple explanation of how scrum works, you will be able to think about how it will affect your project while reading. http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
Depends on your velocity. Usually a sprint is around 2 weeks. Using a formal process for just 3 sprints seems a bit overkill to me. I would still recommend using it, but not be so rigid about sticking to the process too much.