Metrics and Measures

  • Comments posted to this topic are about the item Metrics and Measures

  • I wish I better understood dev-ops so I could participate in an intelligent discussion on this topic, but even though the company I work for likes to pretend it follows dev-ops methodology, in actuality from everything I read it is far from it.  We don't follow principles of continuous integration.  Our branching strategy is very complex and not managed well, some branches live much longer than they should.  There are a number of projects that drag on for years with little to no progress.  Our flow of delivery is long and complicated.

    I read this article and agree with the statement "increasingly seeing (...) metrics used as goals".  My company seems to be in a continuous downward spiral of adding more and more metrics to IT processes without actually improving the processes or focusing on the hardware/software we are delivering. Upper IT management is always pushing measuring things to ever more detail rather than looking at the trends and trying to improve.  Is there a way to convince those above us that metrics is not equal to quality?

     

  • DevOps is about always looking to experiment, learn, and change your process. That would be the moving of bits from dev to prod (the process), or improving the code quality. If you don't do that, then you're not likely getting better at building software.

    You can be using some things and not others and on the journey, which is what DevOps is. It's not a do x, y, and z to do DevOps. It's regular and consistent improvement. Doesn't require CI, but that should be because you've decided CI isn't improving your process for some reason. There are reasons not to do this. It doesn't require a specific branching strategy, or any tech. It's about growing and improving, not dictating what needs to be done.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply