... you will never turn back
There are many definitions for DevOps, the most simple one can be a unique team able to develop and to operate in a continuous way, supported by a tool chain enabling automatically code integration, test and deployment in a single pipeline, where the code, after several approval steps, is released into production. In this post, I will try to share my definition and will share some personal considerations about the implications of decide for organize your team and development process
When comparing the frequency and granularity of test planning and execution in products developed under Waterfall and Agile methods, we observed that in Agile: we have more tests, in the story level and we have a progressive increment of test coverage all over the product and higher frequency running those tests.
Life is done of routines. A routine has a taste of contradiction: sometimes is boring sometimes means comfort, security, trust. Respect a routine implies discipline and recognition about the value we can get from that. In this post I would like to share my thoughts about the Continuous Improvement cycle. I think this is a basic concept you must understand once we enter in Agile and specially if we start planning to adopt a DevOps model to guide our development. Let’s pay attention
Why should we estimate? What are we considering when we do it? Yes, estimation accuracy is a matter of practice maintaining the same team constant. What and how can we estimate? We can do it all over hierarchy of requirements, since strategic levels until implementation ones. But essentially a good product planning should be done to slicing features maintaining product value and introducing complexity across the product development phases.