Continuous Inspection - How to define, measure and continuously improve code quality?
When it comes to software quality, everybody wants good quality software only. However when it comes to define, measure and achieve it objectively, confusion prevails. Different people and different perceptions.
So how to define software code quality, how to measure it and build a culture towards great code quality software, take proactive steps instead of reporting based reactive steps? These are some important aspects this session will touch-base.
On top of that, we all have heard about Continuous Integration, Continuous Delivery and Continuous Deployment, but what's this Continuous Inspection all about? What all is involved to achieve that and how to achieve that with Jenkins and with other Continuous Integration servers? Along with answers of all these questions, a hand-on demo will be given as part of the session.
Outline/structure of the Session
- Definition of code quality
- Broken window theory and technical debt
- What should I measure for code quality
- Which metrics (7 sins of code quality)
- Proactive static code analysis demo with:
- Eclipse (IDE)
- Maven (build tool)
- Jenkins (CI server)
- Continuous inspection introduction
- Continuous Inspection and Definition of Done
- Continuous inspection rules
- Continuous Inspection in Jenkins
- Continuous Inspection Demo
- How to define, measure and improve code quality
- How to reduce technical debt
- Explain Continuous Inspection and how to achieve that
- Hands-on demos with Eclipse, Maven and Jenkins
Developers, Scrum masters and Managers
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Movers n shakers of Enterprise AgilityPrasad
schedule 2 years agoSold Out!
With business agility the new watchword in senior management circles, more and more enterprises are looking for ways to adopt ‘agile’ into their technology practices. However, such an initiative needs to go beyond the mere adoption of agile in a few projects. To successfully implement enterprise IT agility, organizations need to understand the impact of agile across functions and groups, develop frameworks to sustain agile, empower teams across the board to work in an agile fashion, and invest in the right infrastructure. A strategic roadmap based on these considerations can help organizations infuse agile into their practices, processes and systems, thereby achieving true benefits of agile – faster returns, better quality and quicker time-to-market.
This session discusses the critical factors for an effective roadmap to implementing enterprise IT agility. It also outlines how these factors contribute to a successful enterprise IT agility strategy.
Distributed Agile Patterns and Practices
Way back in 2008, when I started working in Agile, there was enough material available on Scrum and. However when it came to distributed aspect of it, people were still struggling with it. Based on working for years in this fashion, I realised that communication, trust, transparency and innovation are the core fundamental values towards successful distributed Agile implementation.
In other words, as most of the problems were caused by softer aspects of skills (misunderstanding, miscommunication, non-availability of people, mistrust etc), humanizing the distributed team experience looked like the key for successful distributed Agile implementation.
Based on working with distributed teams over the years, we discovered some distributed Agile patterns. Some of them got blogged from time to time. Those already available in form of blogs are as follows:
- Distributed Pair Programming
- Local Retrospective
- Agile way of documentation
- One Team Multiple Projects
- The nut/bolt pattern for distributed Scrum development
- Chain-Link Pattern
- Virtual One Room
The session is to share the these patterns and more (when to go for distributed Agile and when not etc)
Specification by Example Explained
What if you could write functional tests without writing a single line of application code? What if those tests are written in plain English (so that anybody could understand) but still it's executable spec or source-code? What if you could generate the documentation from live production source code? Now you don't need to update the requirement doc all the time.
What's Specification by Example? Is it different compared to BDD? Who all participate in defining these specifications? Are functional tests and functional specifications same? These are the questions this session tries to answer.
Completely Distributed Agile - A Case Study
What about a case where the whole team is completely distributed, i.e. every team member works from a different distributed location, possibly from a different country or from a different time-zones. What about the challenges faced while working with a team where time-zone changes can be 7-8.
In the new era of Lean Startup, some startups are working and developing software in this fashion. This session is a case-study of one such startup which is completely distributed. How they are working, are they using Agile or have evolved some new practices which work for them. What kind of different challenges these teams face on regular basis and how do they solve them, these are some of the question this session tries to answer.