We are a medium sized company (about 500 people) with a small team of web developers, one web designer, and QA staff. We develop requirements and go through a somewhat formal web project routine. The issue is that our senior management changes the requirements and even worse, during the last release made changes past the "code freeze." While some of this will need to be a culture shift in how web projects are seen in the company, we'd like to implement a more formal sign off to avoid this in the future. At what point are tweaks still acceptable? Does any one have any tools they use?
An interesting question. I've moved to a (hopefully) more appropriate forum, to increase the chance of getting a useful reply.
This one. (General Web Development & Application Design Issues)
Yes, this one. It was in General Discussion before, but it didn't get any replies.
No. I'd hit things from a different angle -- given modern development and configuration management tools why do you have code freeze in the 1st place?
I'd love things to be more agile but that's not our reality. Our developers want to maintain our code base ;(
So do ours so I'm not sure why that is a hang-up. Agile is getting to be a dirty word anyhow, what we practice is continuious deployment.
That said, we do try and hit "feature freeze" at some point near production. The great psychological release value is "file that feature for vNext"; now the implication is that there is vNext and vNext is coming soon which gets you back to modern development & deployment practices.
So it sounds like our issue here is less a matter of process and more of balancing act between the two sides (as I sort of thought). Stakeholders who want the speed and flexibility of "modern development and deployment" and our development team who needs more formal requirements and feature freezes.
Been there, done that.
What you're looking for is "Agile Development" that typically runs in 3 week sprint. There's ton of project management tool but the one I've used is called "VersionOne". It's really nothing fancy. You create User Story aka requirements then you give points based on risks (time/new technology/dependencies), then you break user story into tasks and assigned to team members. Each team member will come up w/ best estimated time to complete the task. If you keep iterating this w/ each user story then you'll know how much you can take per 3 weeks sprint. If your team is new to this then expect that their estimation to be way off. On each sprint iteration, you'll get better at estimating.
I still haven't answered your question "When do you code freeze?" What we did is that we dedicate 1 Sprint (3 week) to refactor/test/improve performance. We also made refactor/test/improve as a User Story with points. Customer should not be able to request new feature unless it's extremely important or something that's relatively easy. If your customer does ask you to do something then you create user story and give it a point. Say your team is commited to 450pt for Sprint 10 then your customer must make sacrifice on other task that won't be done.
Thanks, sg707. We've been doing longer release cycles (with multiple features) and perhaps this might solve some of our issue . Not sure I understand how the points works, but I'll look into it.
This topic is now closed. New replies are no longer allowed.