Having worked as a lowly software developer for large companies for years and now a startup, I have reluctantly learned quite a bit about software project management. All software devs really want to do is code and build things, but then we get annoyed having to deal with all sorts of other problems and end up diversifying our skill sets.
As a junior dev at a very large company, I was shocked at how quickly I could toss my change into a customer-facing system after uttering the words "oh yeah, I'm done". Then the inevitable panic as I would have to work late in an unfamiliar production environment trying to perform triage. *I guess I wasn't really that "done" after all *. Lesson learned! From now on, "done" means testing thoroughly and on non-local environments. The app is really popular, so Bob is joining the project! Yeah, Bob rules, this is going to be twice as productive! After 3 months of adding tons of features we are ready to show everyone, I deploy and… oh no, not again. Bob sucks, his features broke mine. "I don't think so", says Bob, "you broke my features." Lesson learned! We need Sally from QA to do integration testing before we are "done". Sally is kind of busy and we need time after the QA phase for bug fixes but the app will be more stable. It will just take a little longer but being done now includes QA.
The QA environment emulates production closely so quality is high, but even trivial changes are bundled with large changes to be packaged as release candidates for QA. The resulting development cycles can easily take 3 months in a large organization. But then we're done… right? Once the feature hits production and customers use it, we start getting valuable feedback. No problem, some small tweaks are made, but quite often the feature itself does not work as intended. The customers hate it! Great, all that time and they don't even use it right or at all. So "done" evolves for us over time to encompass more and more. *How can we be done if the customer hates the highly tested and bug-free feature? *
With the lessons learned above, the adoption of Continuous Delivery has become more popular. The hard part is being disciplined and releasing regularly. Once a month, once a week? It depends on what can be automated. But in general, massive automation in deployment and testing are worth it. Especially when you consider the difficulty in predicting the features that will be a hit with customers. Getting the metrics from actual production use is invaluable. The definition of Done that's popular in Agile methodologies like SCRUM should therefore consider including customer metrics and feedback. A minimum viable feature that helps guide subsequent development deployed quickly and safely is usually the best answer. Scared? Don't be, there are many tools to assist: CI servers, CD pipelines, Configuration Management, VM/Container images, Integration and load testing, cross-browser test VMs and services.
*Okay, I think we can call this post DONE * :)