5+1 Sonar Plugins you must NOT miss

Sonar, to my humble opinion, is the leading system to help developer teams track,manage and eventually enhance the overall quality of their code and obviously their software products/projects. To be honest, this is not a post to describe either Sonar features or the necessity of a tool for every developer that respect his time and efforts. If you want to read such analysis you can see my related post To Sonar or Not to Sonar. In this article I briefly present 5+1 plugins that every Sonar Installation should have them. I would like to clarify though some exceptions I have made prior to my final choice. I have excluded all plugins that have to do with additional languages and IDE to keep this post as much as objective I can. I have also excluded all commercial plugins for obvious reasons. After that assumptions I have limited my selections to the following categories : 

• Additional Metrics
• Governance
• Integration
• Visualization / Reporting

Sonar itself comes with a variety of features that cover most of the needs of a software development team. However I consider that the following plugins are essential, especially for those that have adapted or trying to adapt agile practices. To be honest it was very difficult to select only 6 plugins!!

1.Hudson / Jenkins plugin

Although Sonar analysis can be easily triggered from several build tools (maven, ant etc.) I strongly believe that its native integration with the most famous open source CI server makes itself an important part of the continuous integration / deployment practice. The configuration is extremely easy and as proposed the best practice is to trigger Sonar at night builds. Team members can track day by day software quality, automatically, without bothering when a new analysis should run.

2.Jacoco Plugin

Unit Test results, with drill down analysis, line and branch coverage, running and failed tests are features implemented in Sonar core and cover in depth all aspects of unit testing practice. But, as there is always a 'but', what about Integration tests? What if we want to have separated measures about unit and integration tests? Here comes JaCoCo plugin to save our time and money. Although JaCoCo is an alternative to Cobertura (default Sonar coverage tool ), it may be properly configured to display metrics only for Integration Tests. There is a great article that explains in details how we can use it and get the same analysis ( as for Unit Tests ) for Integration Tests.

3.Useless Code Plugin

It may looks similar to the Sonar Core feature named Duplicate Code, but it adds some more metrics, which I think are very useful especially for large or legacy systems. In general it measures how many lines can be removed from your code. It reports what is the number of unused private methods that can be safely removed and the number of unused protected methods exist in the code that can be removed after some more careful code examination. Finally it provides some more details about code duplication informing how duplicate lines are formed (i.e. x blocks of y lines )

4.SIG Maintainability Model Plugin

This plugin, as its name implies is an implementation of the Software Improvement Group(SIG) Maintainability Model. It reports ranking - from -- :(very bad) to ++ (very good) on the following base indicators:Analysability, Changeability, Stability and Testability. The core idea for this ranking is to measure a series of base metrics such as Lines of Code(LOC), Duplications,Unit Tests,Complexity and Unit Size. Each of these metrics is then accounted into some of the mentioned indicators and the final result is representing the overall maintainability of the project. We can see the results of this analysis in a graphical (spider) presentation with all four axes of the model. With a glance a this graph you have a global and detailed at the same time view of how easy is to change and maintain your codebase. For me it is the first index I check every morning and if something is not + or ++ then we definitely have done something wrong ;-)

5.Quality Index Plugin
Have you ever wanted to check a single number (indicator) and understand how healthy is your project? I am sure you have!! Well, the quality Index plugin is exactly what you are looking for. The plugin combines four weighted axes (complexity, coding violations, style violations, test coverage) of quality and produces a ranking between 0 (lowest) and 10(highest). Moreover it calculates a method complexity factor based on the complexity factor mentioned above. Have you ever tried to get a ranking of 10 with this plugin? I think it worths the effort! :-)

6.Technical Debt Plugin
Last, but not least, the plugin that reports about the interest you have to pay as a developer, as a team, as a company. Technical debt is a term invented by Ward Cunningham to remind us that if we don't pay our interest from time to time, then it is for sure that eventually this will make our software unmaintainable and hard to add new features or even find the root cause of defect. The plugin, which has a very powerful configuration, represents technical debt in four dimensions.

• Debt Ratio : The percentage of current technical debt to the maximum possible technical debt.
• Cost to reimburse : Cost in your currency to pay all interest and clean up your code
• Work to reimburse : Same as above measured in man days.
• Breakdown : Distribution to the following axes: Duplication, Violations, Complexity, Coverage, Documentation and Design

Be sure that you check its measures to avoid find yourself in bad situation like spaghetti code :-)

I am pretty sure that there are plenty of interesting Sonar plugins so please feel free to post your comments with your list of them.

Agile for dummies - Continuous Feedback with Customer Demos

Introduction

Most of us,during the development of a software system, have probably received some major changes requests from customers near the end of the project. Even worse, during a demo session, the end users as soon as see (for the first time) the final(?) product jump out of the window screaming and cursing you and your team:"This is not what I wanted. I don't like it. Get it back and bring me something else". What exactly is this "something else"? No one is able to explain it and at this point of the project being under budget/time pressures it is something extremely difficult to clarify. With a simple (greek) word: A CATASTROPHE. If you find your self smiling at this moment then at some time in the past you have been in such a position and of course, for that we usually blame this unsatisfied and indecisive creature that we call "the customer". No matter how many times you have tried to "freeze" the requirements in the early stages of the project either because you had a fixed-price contract, or because "we need to know in advance what we are going to develop", the only thing you achieve is to "lose" the customer from the beginning of the project and obviously, this is not what you would expect. So, are we really unprotected against to our customers? Of course not. Our purpose is, or at least should be, the delivery of a system that covers as many as possible, and always within budget, customer business needs. One of the agile practices I like and I believe that help towards this aim is the one i simply present (for agile dummies) in this blog.

Some simple rules and guidelines

Frequent demos for immediate feedback are extremely imporant and come to fill the gap between the development team (what is implemented) and end users (what they really want from the system).The fact that from the early stages of the project, the customer  participate at regular intervals in such meetings, ensure that critical requirement changes and misunderstandings are identified as soon as possible. Thus the implementation cost is far lower than the scenario where the same change is "discovered" much later when the project would be in advance.As for each agile practice, however, frequent demos should follow some rules and guidelines in order to get the maximum of the. The following brief instructions are  mainly focusing to projects where there is a single customer.

• Since the beginning of the project, therefore, describe in details the practice you intend to follow and try to explain its return of investment. Make clear that these demos have a single purpose. To understand early in the project what are the actual needs of end users and get as soon as possible feedback on the track you follow, so if something is extremely wrong you have adequate time to fix it.
• If there is some kind of dissatisfaction about the large number of releases, it is good to clarify that these are not real releases, but internal demos, which will be not available to all users. There are nevertheless valuable for the early diagnosis of requirements misunderstandings.
• Respect customers' free time. Try to find an approach that will make everyone happy. If the customer can not attend a demo at the end of each iteration (for example every two or three weeks) try to make it at the end of each month. This, IMHO, is the maximum allowed period between two demos.
• Try to ensure that you really have to show something. New features, modified or redesigned screens are essential in a demo and should work with no problems. If the customer is frustrated by a non-working demo, then it is most likely that he loses confidence in the development team and distrusts any attempt for future meetings.
• The demo should be done only by development-team members so that he/she will show the customer features that need his/her attention and feedback. Do not let the customer "play" with the release. Politely remind him the purpose of this meeting and that the demo version of the system is not suitable yet for beta testing.
• Remember to make clear before each demo that the product/system is still under development and that this is NOT what the end users will get. Try to focus on core and critical business requirements so you can get important feedback, but this does not mean that you ignore proposals for the usability, the user interface, etc.

Product vs Project

What happens though, when we do not have a single customer, but our product is targeting thousands of customers? Obviously, the frequent demo aproach seems to be unrealistic or it may be applied to a limited extent. For that reason, I propose below a couple of alternative actions that will replace this practice aiming at the same results (get early feedback).

• Try to create videos that demonstrate the new feature of the upcoming release- several days before its official announcement. Something like a pre-release announcement.The main advantage of this approach is that with minimum cost, we can briefly show (the duration of the video should not exceed 2-3 minutes), the core features for that we would like to get feedback and comments from our customers, before the new version is actually released
• Try to provide a try-it-live demo site where customers (existing and potential) are allowed to test the new upcoming version (Beta versions, Release Candidate versions) and send with a predefined way comments and feedback.
• Try to gather some of the customers (if they are located in some or nearby places) or a webinar for long distance-customers and perform a demo session instead. Although this will not have the same results as if you would showing the product in a single customer, but you may get some important feedback.

Benefits

Some of the practice's benefits are summarized right below:

• Early detection of misunderstood requirements.
• Correction of the project "path" at a very low cost.
• Continuous communication with the customer.    
• Increase confidence between the development team and end users.
• Creative collaboration to achieve the same purpose (meaningful and working product)
• Most critical and core features are delivered first and complete without having to reach at the latest phases of the project.

Probably the above list is not completed, so if you have some more ideas (remember this post is for agile beginners and not experienced users) feel free to post your comments.

Daily Stand Up Meetings

Εισαγωγή

Τα Daily Stand-Up Meetings (DSUM) --επιτρέψτε μου να χρησιμοποιώ τους αγγλικούς όρους- αποτελούν ίσως την πιο εύκολη, φαινομενικά, agile πρακτική. Αν και μπορεί να χαρακτηριστεί παράξενη ή ακόμα και εκκεντρική αποτελεί σημαντικό κομμάτι του συνολικότερου agile planning. Ποιος δε θα απορούσε, σε μία εταιρία που όλες οι συναντήσεις παραδοσιακά γίνονται γύρω από ένα τραπέζι, αν έβλεπε μία ομάδα ανθρώπων να στέκονται όρθιοι καθημερινά – όχι στο διάλειμμά τους - και να συζητάνε για την πρόοδο των εργασιών τους; Ακόμα και οι ίδιοι οι συμμετέχοντες σίγουρα τις πρώτες φορές θα νιώσουν εντελώς αμήχανα. Άλλωστε ποιος είναι ο λόγος να είμαστε όρθιοι; Τι κερδίζουμε; Μια χαρά δεν είναι οι συναντήσεις στο τραπέζι; Συνήθως μιλάνε ένα – δύο άτομα και οι υπόλοιποι περιμένουν να περάσει η ώρα χαζεύοντας το ρολόι στον τοίχο ή εξασκώντας το ταλέντο τους στην αφηρημένη ζωγραφική σε όποια επιφάνεια βρεθεί διαθέσιμη.

Χαρακτηριστικά - Κανόνες

Τα DSUMs, βρίσκονται στο κατώτερο επίπεδο agile planning, όπως φαίνεται και στο παρακάτω σχήμα και αποτελoύν τον ημερήσιο προγραμματισμό της ομάδας. Για να είναι επιτυχημένα και ουσιώδη αρκεί να έχουν συγκεκριμένα χαρακτηριστικά.

• Γίνονται πέντε φορές την εβδομάδα (κάθε εργάσιμη ημέρα) στον ίδιο χώρο και την ίδια ώρα. (Η ώρα επιβάλλεται να εξυπηρετεί όλους τους συμμετέχοντες)
• Όλοι όσοι εργάζονται στο project / product απαντούν τουλάχιστο στις παρακάτω τρείς(3) ερωτήσεις

• • Τι έκανα την ημέρα που τελείωσε;
  • Τι θα κάνω την ημέρα που έρχεται;
  • Τι εμπόδια έχω στο δρόμου μου
• Η διάρκειά τους δεν ξεπερνάει τα δεκαπέντε (15’) λεπτά. ( Τεχνικές λεπτομέρειες και αναλύσεις γίνονται μετά τη συνάντηση με τα μέλη που απαιτούνται )
• Ο χώρος στον οποίο γίνονται συνίσταται να είναι ο χώρος εργασίας και πιο συγκεκριμένα γύρω από τον πίνακα εργασιών της ομάδας (Team Board)
•  Και φυσικά, όλοι οι συμμετέχοντες στέκονται όρθιοι, σχηματίζοντας ένα ημικύκλιο ώστε να μπορούν να κοιτάζονται χωρίς εμπόδια.

Το τελευταίο χαρακτηριστικό, είναι αυτό που προσδίδει και τη μεγαλύτερη αξία στην πρακτική. Μία συνάντηση που απαιτεί να είναι όρθιοι οι συμμετέχοντες, συνήθως, διαρκεί πολύ λιγότερο από ότι ή ίδια συνάντηση σε ένα τραπέζι και «αναγκάζει» τον καθένα να συμμετέχει ενεργά.

Από την Ομάδα – Για την Ομάδα

          

Ένα κλασσικό «λάθος» που γίνεται σε τέτοιες συναντήσεις (DSUMs) είναι να θεωρηθούν ότι αποτελούν ένα εναλλακτικό είδος αναφοράς προόδου στον Project / Product Manager ή στον Team Leader.

Αυτό που χρειάζεται να γίνει σαφές σε όλα τα μέλη της ομάδας, είναι ότι τα DSUMs γίνονται για να συγχρονίζονται μεταξύ τους σε σχέση με το πλάνο της επανάληψης (iteration plan) και με τις εργασίες που έχουν αναλάβει να ολοκληρώσουν μέχρι το τέλος της. Οι απαντήσεις και οι πιθανές ερωτήσεις πρέπει να έχουν ως αποδέκτες όλα τα μέλη της ομάδας και όχι τον εκάστοτε υπεύθυνο. Άλλωστε, οι συναντήσεις γίνονται αποκλειστικά με σκοπό το όφελος των ανθρώπων που εργάζονται στην ομάδα. Μια καλή πρακτική για τον έλεγχο της ροής της συνάντησης είναι να υπάρχει ένα αντικείμενο, το οποίο ο κάτοχός του θα έχει και το λόγο. Μόλις το αντικείμενο δοθεί σε άλλον τότε αλλάζει και ο ομιλητής.

Ποιοι συμμετέχουν

                Η πρακτική εφόσον επιθυμούμε να εφαρμοστεί σωστά, απαιτεί τη συμμετοχή όλων των μελών της ομάδας στα DSUMs (developers, testers, designers, πελάτες ή business analysts, agile coaches κτλ. ). Υπάρχουν δύο διαφορετικές απόψεις για το ποιοι έχουν «δικαίωμα» να μιλάνε σε αυτές τις συναντήσεις.

Η πρώτη στηρίζεται στην ιστορία της κότας και του γουρουνιού και επιτρέπει να μιλάνε μόνο αυτοί που συνεισφέρουν στο project. Δεν έχουν δικαίωμα, δηλαδή, να μιλήσουν οι πελάτες ή οι business analysts.

Η δεύτερη προσέγγιση κατακρίνει τη διάκριση των συμμετεχόντων σε κοτούλες και γουρουνάκια, εκτιμώντας ότι αφενός αυτό αποτελεί ένδειξη μη σεβασμού και αφετέρου χάνεται το ενδιαφέρον από τους ανθρώπους χωρίς «δικαίωμα» παρέμβασης.

Τα οφέλη της πρακτικής

Θεωρώντας ότι τα DSUM αντικαθιστούν οποιαδήποτε άλλη μορφή συναντήσεων που έχουν σκοπό αναφορές προόδου παρουσιάζω ενδεικτικά μερικά από τα οφέλη της πρακτικής:

• Λιγότερος «χαμένος» χρόνος σε παρακολούθηση προόδου εργασιών
• Εργασίες που καθυστερούν εντοπίζονται από όλη την ομάδα άμεσα και καθημερινά
• Τα περισσότερα προβλήματα αναφέρονται καθημερινά και επιλύονται άμεσα.
• Τα μέλη της ομάδας σταδιακά γίνονται ολοένα και πιο ενεργά
• Το status του project καθημερινά κοινοποιείται σε όλα τα μέλη της ομάδας.
• Το κάθε μέλος έχει το δικαίωμα να προγραμματίζει την εργασία του (όχι ο PM) και με αυτόν τον τρόπο θυμούνται πιο εύκολα τι έχουν να κάνουν.

Unit Testing με απλά λόγια

Εισαγωγή

Η πρακτική του Unit Testing, δεν αποτελεί Agile «εφεύρεση» ούτε αποκλειστικότητα των Agile ομάδων. Αντιθέτως προϋπήρχε όπως πολλές άλλες. Η διαφορά, ωστόσο μιας agile ομάδα ανάπτυξης λογισμικού είναι ο τρόπος που την υλοποιεί και πως αυτή συνδυάζεται με άλλες πρακτικές και τεχνικές. Για το λόγο αυτό, αλλά και χάρις την εύκολη εφαρμογή της, η πρακτική του Unit Testing, βρίσκεται στις πρώτες θέσεις της λίστας των πρακτικών που υιοθετούνται άμεσα από τις περισσότερες ομάδες που προσπαθούν να ακολουθήσουν μία Agile προσέγγιση στην ανάπτυξη λογισμικού.

Τι σημαίνει λοιπόν Unit Testing. Είναι η μέθοδος με την οποία διαπιστώνεται αν οι αυτόνομες μονάδες λογισμικού πληρούν τις τεχνικές και επιχειρησιακές προδιαγραφές που καλούνται να υλοποιήσουν. Με λίγο πιο τεχνικούς όρους είναι τα «σενάρια ελέγχου» που πιστοποιούν ότι όλες οι μέθοδοι μίας κλάσης (άρα και η κλάση) είναι έτοιμες προς ολοκλήρωση με το υπόλοιπο σύστημα.  Πριν αναλυθεί γιατί, πως και πότε πρέπει να αναπτύσσονται τα unit tests, είναι χρήσιμο να αποσαφηνιστούν μερικές έννοιες και να απομυθοποιηθούν καταστάσεις σχετικά με το testing.

Μύθοι και έννοιες

Μία ατέλεια λογισμικού ή αλλιώς ένα σφάλμα, ή αλλιώς ένα bug (δεν έχει σημασία ο όρος) συμβαίνει όταν

• Το λογισμικό δεν κάνει κάτι, το οποίο οι προδιαγραφές αναφέρουν ότι θα έπρεπε να κάνει
• Το λογισμικό κάνει κάτι, το οποίο  οι προδιαγραφές αναφέρουν ότι δε θα έπρεπε να κάνει
• Το λογισμικό κάνει κάτι, το οποίο  οι προδιαγραφές δεν αναφέρουν
• Το λογισμικό δεν κάνει κάτι, το οποίο οι προδιαγραφές δεν αναφέρουν αλλά θα έπρεπε να το αναφέρουν
• Το λογισμικό είναι δυσνόητο, δύσκολο στη χρήση του, αργό ή στα μάτια του tester ή του τελικού χειριστή δε φαίνεται σωστό

Είναι αδύνατον να ελεγχθεί πλήρως (100%) ένα σύστημα:

• Ο αριθμός των πιθανών δεδομένων εισόδου και εξόδου είναι απεριόριστος
• Ο αριθμός των διαφορετικών τρόπων χρήσεων ενός λογισμικού ( software paths) είναι επίσης πολύ μεγάλος
• Οι λειτουργικές προδιαγραφές είναι υποκειμενικές και αλλάζουν διαρκώς.

To Testing, ειδικότερα το Unit Testing, δεν αποδεικνύει ότι έχουν εξαλειφθεί όλες οι ατέλειες του λογισμικού.

Όταν εμφανίζεται μία ατέλεια σε ένα τμήμα κώδικα, τότε είναι σίγουρο ότι υπάρχουν εκεί κοντά ακόμα περισσότερες ατέλειες. Γιατί όμως?

• Οι developers έχουν κι αυτοί άσχημες ημέρες, όπως όλοι οι άνθρωποι.
• Οι developers, όπως όλοι οι άνθρωποι, συνηθίζουν να κάνουν το ίδιο λάθος.
• Συνήθως μία ατέλεια που ανακαλύπτεται είναι μόνο η «κορυφή του παγόβουνου»

Η θέση του Unit Testing στα επίπεδα ελέγχου ενός συστήματος.

Όπως φαίνεται στο παρακάτω σχήμα το Unit Testing αποτελεί το πρώτο «ανάχωμα» στη συνεχή μάχη με τις ατέλειες του λογισμικού. Τα Unit Tests γράφονται κατά κανόνα από τους developers που αναπτύσσουν τον αντίστοιχο κώδικα και σε σπάνιες περιπτώσεις από white-box testers.

Η χρονική στιγμή που πρέπει να γράφονται τα unit tests έχει άμεση εξάρτηση με το αν εφαρμόζεται η πρακτική του test-driven development, για την οποία θα αναφερθώ σε μελλοντικό blog. Αν λοιπόν μία ομάδα ανάπτυξης ακολουθεί test-driven development τότε τα tests γράφονται πριν από τον κώδικα, διαφορετικά αναπτύσσονται συνήθως παράλληλα με τον κώδικα ή στο τέλος. Η σύγκριση, ωστόσο, των παραπάνω τεχνικών δεν αποτελεί αντικείμενο του παρόντος Blog. Όποτε λοιπόν έχουμε αμφιβολία για το πώς ο κώδικάς μας συμπεριφέρεται ή όποτε θέλουμε να πιστοποιήσουμε ότι κάνει αυτό που περιμένουμε, γράφουμε ένα unit test. Η αξία των Unit Tests είναι ανεκτίμητη επειδή άπαξ και αυτοματοποιηθούν μπορούμε να τα εκτελούμε κάθε φορά που κάνουμε μία αλλαγή στον κώδικα ώστε να ξέρουμε άμεσα και αξιόπιστα αν έχουμε χαλάσει κάτι που ήδη «έπαιζε σωστά». Ένα Agile project, θα έχει εκατοντάδες, αν όχι χιλιάδες unit tests, τα οποία διατρέχουν όλο το λογισμικό ελέγχοντας ότι αφορά την επιχειρησιακή λογική του (business logic).

Χαρακτηριστικά ενός καλού Unit Test

• Θα πρέπει να είναι αυτοματοποιημένο και να μπορεί να επαναληφθεί όποτε απαιτείται.
• Θα πρέπει να είναι εύκολο στην υλοποίηση και στη συντήρησή του
• Άπαξ και αναπτύχθηκε μια φορά θα πρέπει να είναι διαθέσιμο για μελλοντική χρήση
• Οποιοσδήποτε θα πρέπει να μπορεί να τρέξει και να δει τα αποτελέσματά του
• Θα πρέπει να ακολουθεί τους ίδιους κανόνες σχεδίασης με το λογισμικό που ελέγχει ώστε να αποφεύγονται σφάλματα μέσα στα ίδια τα tests.
• Θα πρέπει να είναι γρήγορο και αξιόπιστο.

Τα οφέλη της εφαρμογής της πρακτικής του Unit Testing

• Άμεση ανατροφοδότηση (feedback)
  • Μόλις γίνονται αλλαγές στον κώδικα κι ένα unit test «χαλάει» (σταματάει δηλαδή να είναι επιτυχές), ο developer το μαθαίνει αμέσως και όχι μετά από μερικές εβδομάδες, όταν έχει φτάσει η έκδοση στην ομάδα ελέγχου, ομάδα υποστήριξης ή ακόμα χειρότερα στον πελάτη.
• Δραματική μείωση του κόστους ελέγχου μίας έκδοσης
  • Αντί να χρειάζεται να γίνει χειροκίνητος έλεγχος όλων των λειτουργιών κάθε φορά που είναι έτοιμη μία έκδοση, σώζουμε δεκάδες ώρες, αυτοματοποιώντας τουλάχιστον τους ελέγχους για τις «εύκολες» λειτουργίες και αφιερώνουμε τον υπόλοιπο χρόνο στις πιο περίπλοκες.
• Δραματική μείωση του χρόνου αποσφαλμάτωσης
  • Όταν αποτυγχάνει ένα Unit Test ο developer ξέρει ΑΚΡΙΒΩΣ σε ποιο σημείο του κώδικα υπάρχει η ατέλεια, χωρίς να χρειάζεται να διατρέψει εκατοντάδες γραμμές κώδικα αναζητώντας αυτή που το έχει προκαλέσει.
• Αύξηση αξιοπιστίας και άνεση στη διανομή σε ομάδες ελέγχου και υποστήριξης
  • Η ύπαρξη μίας πλειάδας αυτοματοποιημένων ελέγχων παρέχει ένα επίπεδο ασφάλειας σε όλους τους εμπλεκόμενους σε ένα project. Αυτό δε σημαίνει, φυσικά, ότι κάθε έκδοση γίνεται αποδεκτή, μόνο και μόνο επειδή υπάρχουν τα unit tests, αλλά μας «απελευθερώνει» ώστε να αφοσιωθούμε στον λεπτομερή έλεγχο κρίσιμων και περίπλοκων λειτουργιών του λογισμικού.