Real Democracy NOW

Απόσπασμα από τα πρακτικά της 1ης συνέλευσης των "Αγανακτισμένων" Ελλήνων

 Να υπάρξουν κατασκηνώσεις σε όλους τους ανοιχτούς χώρους της Ελλάδας, να δημιουργηθούν ομάδες εργασίας με σαφή κατανομή καθηκόντων και υποχρεώσεων.

 Έχουμε την ομορφιά μαζί μας, απέναντι στον μοχθηρό τραπεζίτη και τον κακό πολιτικό.

 Όποιος πολιτικός αδικεί, όποιος πολιτικός δεν σέβεται την λαϊκή εντολή, να πηγαίνει σπίτι του ή στην φυλακή.

 Είναι μια διαδήλωση ανοιχτή, μια συγκέντρωση όπου μιλώ και ανατριχιάζω με την εμπειρία

 Η Δημοκρατία τους, δεν εγγυάται ούτε την Ισότητα ούτε την Δικαιοσύνη.

 Να μείνουμε στο Σύνταγμα, έως ότου αποφασίσουμε πώς θα λύσουμε τα προβλήματά μας.

 Όταν ο κόσμος, όταν όλοι εμείς συζητάμε χωρίς φόβο, ο φόβος φωλιάζει σε αυτούς εκεί πάνω στο κτίριο της Βουλής.

 Αυτή την στιγμή, οι λέξεις στην Ελλάδα, έχουν χάσει το νόημά τους. Λέμε Ελλάς και εννοούν ΕΛ. ΑΣ, λέμε λαός και εννοούν ΛΑΟΣ, το κόμμα του Καρατζαφέρη. Να δώσουμε ώθηση, να βρούμε την δύναμη, οι λέξεις να ξαναβρούν το νόημά τους.

 Να μείνει το Σύνταγμα και οι δρόμοι, κλειστοί αυτό το βράδυ, και κάθε βράδυ από εδώ και πέρα έως ότου βρεθεί λύση.

 Δεν πρέπει να μας ευχαριστεί να είμαστε καταναλωτές ή πελάτες, πρέπει να μας ευχαριστεί όταν είμαστε σωστοί, υπεύθυνοι πολίτες.

 Οι Ποδηλάτες, στις κινητοποιήσεις και τις ποδηλατοπορείες της Παρασκευής, κέρδισαν το δικαίωμά τους, στην μετακίνηση, κέρδισαν τον χώρο τους. Ας ακολουθήσουμε το παράδειγμά τους.

 Να συνειδητοποιήσουμε την δύναμή μας και να κατανοήσουμε τα κοινά προβλήματά μας.

 Να καταρρεύσει το πλουτοκρατικό σύστημα της πολιτικής, να το ανατρέψουμε με επαναστατικές κινήσεις.

 Να δούμε παγκόσμια το θέμα, το πρόβλημα της καταληστευμένης ζωής μας. Να ενωθούμε με ό, τι στον υπόλοιπο κόσμο γίνεται ως ανάλογη κίνηση.

 Να καλέσουμε καθηγητές, νομικούς να μας διαφωτίσουν με ποιόν τρόπο θα απαλλαγούμε από το Μνημόνιο.

 Να οργανώσουμε πολιτιστικές εκδηλώσεις, κινηματογραφικές προβολές και συναυλίες στο Σύνταγμα και τις κατασκηνώσεις που θα κάνουμε.

 Δεν φταίνε μόνο οι πολιτικοί, φταίμε οι Ελληνες με την ατομικιστική μας νοοτροπία.

 Να ξεκινήσουμε με την προσωπική μας αλλαγή, με την ενδιάθετη αλλαγή του εαυτού μας. Να απευθυνθούμε στον φίλο φοιτητή, στον φίλο εργαζόμενο να του ζητήσουμε να αλλάξει λογική και νοοτροπία. Και όλοι πρέπει να προσφέρουμε.

 Να συνεχίσουμε με συνέπεια τις εξεγέρσεις του αραβικού κόσμου. Να αρθούμε πάνω από πατρίδες και έθνη.

 Το βασικό πρόβλημα στα θεμέλια της Δημοκρατίας, είναι η αδιαφορία. Δημοκράτης είναι εκείνος που σέβεται τον εαυτό του και τον συνάνθρωπό του.

 Να κοιτάξουμε στα μάτια τους διπλανούς μας. Η αδιαφορία ξεκίνησε από τον καταναλωτισμό. Να πάψουμε να είμαστε αδιάφοροι.

 Το σύστημα ευνοεί λίγους και καταπιέζει τους πολλούς. Να γίνουν κύκλοι και συνελεύσεις συζητήσεων σε κάθε γειτονιά.

 Στο Σύνταγμα, σήμερα το βράδυ, νιώθω ευτυχισμένη. Ας κάνουμε μια καλή αρχή, κλείνοντας τις τηλεοράσεις μας. Και ας ξεκινήσουμε να συντονιζόμαστε.

 Έχουμε συνειδητοποιήσει και ζητούμε πλέον καθαρά να γυρίσει η Δημοκρατία στην βάση, δηλαδή σε όλους εμάς. Να μην υπάρχει κανένα σύμβολο, ή σημαία. Και να εκθρονιστούμε όλοι μας από το όποιο βόλεμα μας και να οργανωθούμε.

 Να γίνει ένα μπλογκ ενημέρωσης και συντονισμού.

 Συμμετέχουμε όσο μπορούμε για να αλλάξουμε την ζωή μας. Να φέρουμε την Δημοκρατία στα σωστά μέτρα, τα μέτρα της ανθρώπινης ζωής και αξιοπρέπειας.

 Στην Πνύκα, τα αρχαία χρόνια, γίνονταν συνελεύσεις και θεμελιωνόταν η Δημοκρατία. Να αλλάξουμε τις ζωές μας ,να αλλάξουμε την Ιστορία μας. Στην εταιρία μας άλλαξαν, προσέλαβαν ανέργους, τους έδωσαν δουλειά.

 Να πέσουν όσοι υποθηκεύουν το μέλλον μας. Να κρατήσουμε δυνατή και ζωντανή την οργάνωση από τα κάτω.

 Σήμερα το βράδυ, τα πρόσωπά μας, φωτίστηκαν από ένα χαμόγελο. Έχουμε όλοι, μια ψυχική ανάταση. Ας το κρατήσουμε αυτό, και ας προχωρήσουμε.

 Πρέπει να τιμωρηθούν οι πολιτικοί και να αγωνιστούμε για αυτήν την τιμωρία.

 Να γίνεται κάθε απόγευμα στις 6.00μμ συγκέντρωση, και να ακολουθεί στις 9.00μμ, συνέλευση.

 Υπάρχει φόβος αυτή την στιγμή στα ΜΜΕ του κατεστημένου και τους πολιτικούς. Η διαδήλωση είναι πάρα πολύ μεγάλη, η συνέλευση είναι πάρα πολύ μεγάλη. Να μην τους επιτρέψουμε να μας ενσωματώσουν.

 Να ξεκινήσουμε να διαμορφώνουμε αιτήματα. Να αλλάξει η πολιτική, να πέσει η κυβέρνηση, να διαμορφώσουμε τις δικές μας προτάσεις.

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

 Η Υγεία καταρρέει, δεν υπάρχουν υλικά, ο κόσμος κινδυνεύει στα νοσοκομεία, μας ληστεύουν και μας εγκαταλείπουν στην τύχη μας.

 Πήρα το μικρόφωνο για να ζητήσω συγγνώμη από τα νέα παιδιά, τους πολλούς νέους ανθρώπους που βλέπω εδώ, να ζητήσω συγγνώμη για την Ελλάδα και την πολιτική σκηνή που τους παραδίδουμε.

 Να ξεκινήσουν διαδικασίες αυτοδιάθεσης και αυτοθέσμισης, αποκαθιστώντας την σχέση μας με την πολιτική, να εργαστούμε με πείσμα για αυτό, να χτίσουμε έναν καλύτερο κόσμο.

 Να δώσουμε την δύναμη σε όλους εμάς, τους πολίτες, τους καλλιτέχνες, τους απλούς ανθρώπους που σήμερα πήραν μια βαθιά ανάσα.

 Ας ασκήσουμε το δικαίωμα στην ανυπακοή, ας το διακηρύξουμε με πάθος και δύναμη. Να φτιάξουμε Ιστορία από την αρχή.

 Η Δημοκρατία ξεκίνησε από εδώ, από την Αθήνα. Η πολιτική δεν είναι κάτι κακό. Για την καλυτέρευσή μας, ας την ξαναπάρουμε στα χέρια μας.

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

 Να φέρουμε και ένα ταπεράκι φαγητό, να αντέξουμε τις ώρες της συνέλευσης, να είναι και η μικρή, σημαντική προσφορά όσων δεν προλαβαίνουμε να είμαστε πολλές ώρες εδώ.

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

 Παιδιά, να μην φοβάστε. Να παραμείνετε ήρεμοι, αυτό θα μεταφέρω και στους φοιτητές μου. Να ξέρετε ότι τα οικονομικά, είναι απλά, σύνθετα τα κατάντησαν οι επιτήδειοι και τα αρπακτικά.

 Νίκη θα’ ναι να έρθουν στο Σύνταγμα όλοι οι νέοι άνθρωποι.

 Η αυτοοργάνωση είναι η μόνη λύση. Όσο πιο νωρίς το αντιληφθούμε, τόσο το καλύτερο για όλους μας.

 Μας έχουν γονατίσει με τις συμβάσεις τους. Δεν έχουν οι  πλουτοκράτες, ο Λάτσης, ο Βαρδινογιάννης, οι εφοπλιστές, τα ίδια συμφέροντα και τα ίδια δικαιώματα με εμάς. Εμείς παράγουμε τον πλούτο τους, τον δικό μας πλούτο, ας τον ξαναπάρουμε στα χέρια μας.

 Το χρέος μας γονάτισε τις ζωές.

 Οι Ισπανοί μας έδωσαν την ιδέα και το έναυσμα. Να συντονιστούμε με τον υπόλοιπο, υπερχρεωμένο Νότο, ας κινητοποιηθούμε. Οι Ισπανοί μας έδειξαν τον δρόμο.

 Αυτό που ζούμε μας αφορά όλους, εμάς, τους Ισπανούς, τους Ιρλανδούς, όλους τους λαούς. Το ένα ταπεράκι ας γίνει 10 ταπεράκια, να συντονιστούμε νομικοί, οικονομολόγοι, φοιτητές, όλοι να συνεισφέρουμε όσα μπορούμε με τις γνώσεις μας, κυρίως όμως να μεταδώσουμε το μήνυμα, να μεταλαμπαδεύσουμε όσα έγιναν εδώ στην οικογένεια, τους φίλους, τους συναδέλφους μας.

 Η ζωή είναι πολύτιμη για όλους μας.

 Νέοι άνθρωποι, πάρτε τις τύχες σας, στα χέρια σας. Μας πάνε σε συνθήκες Μεσαίωνα και δουλείας. Ο σημερινός αγώνας είναι αγώνας ενάντια στην βαρβαρότητα.

 Η πολιτική είναι ταυτόχρονα, πολλά εργαλεία. Ένα από αυτά είναι και ο συντονισμός με τους άλλους εξεγερμένους. Αυτή την στιγμή, στην Ισπανία, σε γιγαντοοθόνες αναμεταδίδουν όσα συμβαίνουν εδώ.

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

 Θα ‘ταν πολύ όμορφο, όσο μιλώ να με μεταφράζουν σε άλλες γλώσσες ή να υπάρχει κάποιος διερμηνέας της νοηματικής, για τους κωφάλαλους.

 Θα ‘ναι μεγάλη στιγμή, να ξεφύγουμε από τον στενό κορσέ τον οποίο μας έχουν φορέσει. Από σήμερα αναδιαπραγματευόμαστε το ισοζύγιο δύναμης στην ελληνική κοινωνία και την ελληνική πολιτική σκηνή, ισοζύγιο δύναμης που τώρα ρέπει προς την πλευρά της κυβέρνησης.

 Μας κόβουν κοινωνικές και πολιτικές κατακτήσεις αιώνων. Μας κόβουν τις ελπίδες που πρέπει να τις αναγεννήσουμε.

 Να ανατραπούν οι συσχετισμοί πολιτικής και κοινωνικής δύναμης.

 Ένα καλό βήμα κοινωνικοποίησης και συζήτησης θα ήταν αν φέρναμε εδώ στον δημόσιο χώρο, όσες δραστηριότητες θα κάναμε στον ιδιωτικό μας χώρο.

 Συκοφαντούν τους δημόσιους υπαλλήλους, τους δασκάλους, τους καθηγητές, τους ιατρούς. Δικαιοσύνη δεν είναι η ισοπέδωση των 500 ευρώ. Μας στερούν την αξιοπρέπεια.

 Η πολιτική είναι υπόθεση όλων μας. Η κοινωνία χρεοκόπησε. Ας το αλλάξουμε αυτό.

 Η γενιά μου είναι γενιά εκεί στα 50, είναι μέσα στην Βουλή και ζητώ συγγνώμη για όσα σας έχει οδηγήσει να υπομένετε.

 Είμαι 24 χρονών, βαρέθηκα, κουράστηκα να μιλούν γύρω μου με –ισμούς και γλώσσα ξύλινη. Θέλω κάτι να αλλάξει, να αλλάξει υπολογίζοντας και αναγνωρίζοντας και τις δικές μας ευθύνες.

 Εδώ βρισκόμαστε για να βρούμε την πραγματική Δημοκρατία.

 Ας ξεκινήσουμε με το να απευθυνόμαστε ο ένας στον άλλο σαν να ήμασταν αδέλφια.

 Ζητούμενο είναι να ζήσουμε με αξιοπρέπεια και έχοντας το κεφάλι ψηλά. Να εξεγερθούμε εναντίον της κοροϊδίας. Δεν νομιμοποιούμε κανένα Μνημόνιο.

 Η Ελλάδα είναι στον γκρεμό και τα χρήματα της χώρας έξω από την χώρα. Μας έκλεψαν και συνεχίζουν να μας κλέβουν.

 Μας τάζουν ισότητα στην κοινωνική εξαθλίωση. Εμείς πρέπει να διεκδικήσουμε ισότητα στην κοινωνική ανάταση.

 Το πρώτο ζητούμενο είναι να ξέρουμε γιατί το κάνουμε αυτό το οποίο κάνουμε εδώ, έχω AIDS και καρκίνο, είμαι άστεγος δεν ντρέπομαι να τα πω αυτά. Όλοι χρειαζόμαστε δύναμη και να ξέρουμε γιατί το κάνουμε αυτό.

 Δεν υπάρχει πιο καίρια πράξη, με βαθύ, πολιτικό νόημα από το να πάρουμε την ζωή μας, στα χέρια μας.

 Ας γίνουμε όλοι υπάλληλοι και υπόλογοι του λαού.

 Να κινηθούμε να υπερασπιστούμε το Σύνταγμα και την Ελλάδα, όπως λέει και το άρθρο 120 του Συντάγματος της χώρας.

 Εδώ συγκροτούμε την νέα, πολιτική δύναμη και σπάμε τον φόβο και την μιζέρια.

 Να πάει παντού το μήνυμα της εξέγερσης. Να δουλέψουμε για το εμείς. Να κινητοποιηθούν και να οργανωθούν όλοι οι άνεργοι.

 Δεν δουλεύει τίποτα χωρίς εμάς, χωρίς τα δικά μας χέρια. Γενικές απεργίες παντού να γίνουμε μια γροθιά.

 Να γίνουμε ιός και να διασπαρούμε παντού.

 Υπάρχουν εκδότες όπως ο Κουρής που χρωστάνε παντού, και τρομοκρατούν και εκβιάζουν τους εργαζόμενους.

 Το σύστημα φορολόγησης δεν είναι το ίδιο για τους πλοιοκτήτες και τους έχοντες και κατέχοντες. Ίδια δικαιώματα και υποχρεώσεις για όλους.

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

 Ξεπουλούν την ενέργεια, και αποκτούν μεγάλες περιουσίες με τις μίζες τους.

 Ας ξεκινήσουμε με δομές αυτοοργάνωσης, μια συλλογική κουζίνα, κάποιες καλλιτεχνικές εκδηλώσεις, να βρούμε παραγωγούς να μας δώσουν τα προϊόντα τους. Η πλατεία Συντάγματος να γίνει κεντρικό παράδειγμα αγώνα για όλη την Ελλάδα.

 Να περιφρουρήσουμε αυτό που συντελείται. Είναι υπόθεση δική μας και έτσι πρέπει να παραμείνει.

 Η νεολαία βγαίνει με ψυχή, με πίστη, ειρηνικά, όχι όπως τον Δεκέμβρη του 2008, έχουμε ωριμάσει όλοι μας.

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

 Μετά το «Βέλος», και το Πολυτεχνείο, είναι η πρώτη ενέργεια άμεσης Δημοκρατίας και ηθικής ανάτασης στην Ελλάδα.

ΠΗΓΗ : http://real-democracy.gr

To Sonar or Not to Sonar ?

To Sonar or not to Sonar? 

This is the first question that a project/product manager, team leader, software department director, customer, developer, ui designer, architect, tester or whatever role/title exists in a development team should answer. This is not a simple question about using an additional quality tool to help you with software development by providing some statistics. I suppose we all have plenty of them installed. This is not a simple question to see how much you care about the total lines of code and their test coverage or to find which classes have the most violations. There is no competition and no prize about that! It is the only question that you ought to answer in order to show how much you care, how much you REALLY care about the overall quality of your software. If you already use Sonar, then you should probably already know the answer and feel free to read our experience. On the other hand if you have never used Sonar or even heard about it, then this is your chance to find out how this little (but great) piece of software have changed our lives (as developers) and enhance our products.

I am an employee of a relatively small software development company, located in Thessaloniki, Northern Greece. There are about 25 developers currently working in small teams. The last 1 ½ years I am in charge of a team composed by 8 members. We are responsible for the maintenance of 5-6 systems (products) and in the meanwhile we have completed a project for one of our customers. Currently we are working on two new products. Since last May (2010) we are using Sonar and here is my little fairy tale about it.

Can I describe our development life before Sonar with a simple word? Of course I can!! Darkness. We had no idea of the situation in our code. We run no unit tests. We did not know whether the design and architecture of our systems allowed significant additions of new features or important changes, which made us very apprehensive about any refactoring attempt. Violations; Security flaws; what the heck are these? Duplicate Code? God bless copy – paste. Analyzability, Testability, Stability, Changeability were terms we believed that we needed to look-up in a Chinese dictionary to find out their meaning. Bugs were discovered late in the development lifecycle causing some red-alert situations and releases seemed to be some kind of middle-age dragons that our support and test department had to fight before they come out to our customers. And then some kind of a miracle happened. I cannot remember how I reached Sonar website, but right now I am quite sure that, those 10 minutes needed to read some of Sonar features, changed my development life. 

Without any second thought I downloaded it and in a couple of minutes it was installed in my personal computer. Full of excitement I configured it to be integrated with Maven and Jenkins (Hudson at that time) and after a couple of minutes I was starring at my screen in front of my first ever Sonar analysis.  I admit that my initial feeling was an extreme disappointment regarding the quality of our existent product but as soon as I realized the possibilities of this unknown to me software tool, I was absolutely stimulated about our new life. Immediately I showed it to my team, shortly explaining them, the different metrics and what do they mean about our project, about the QUALITY of our software. A new era has begun. Today, almost one year later, Sonar tracks all our projects through nightly builds – analysis. Every morning the whole team checks the project dashboard, and the differential views, especially from last analysis, and from last stable version. We have configured thresholds for the metrics we count the most, so whenever a build is out of the accepted limits, it is broken. We handle these builds just like all broken builds. It is our first priority to fix a sonar-broken build and to restore the required quality. Before we begin a refactoring task we always study our Sonar analysis related metrics to find out signs of poor design or architecture. We continuously strive to be focused on every aspect of software quality from the first day of the project and without any doubt; Sonar is the best ally we could ever hard. My favorite views are Treemap and motion Chart? I love to see my bubbles changing colors and moving towards perfection. I love to see my tree getting green from red. With a single view I can figure out which components need our further attention. It’s easy! Just pick up the red big-ones and start cleaning up your code!! 

Our new product releases are much more stable. From dragons are transformed to butterflies. Trust and confidence in our team has significantly grown. We feel no fear when we have to add some new functionality or modify existing features. In other words, this is our Sonar life! The new version, 2.8, is already out there and I cannot wait to try some of its new features like quality profile comparison and manual reviews. I would be also very happy if we could purchase the SQALE plugin. Come on Sonar guys I am sure you can do a better pricing for this kind of plugins.

I can’t imagine my development life without Sonar. Ι sometimes wonder how we and our code could “breathe” some months ago. Sonar gave us the missing oxygen. I have answered my question to myself. I have chosen light instead of darkness. it’s your turn now!




TO SONAR OR NOT TO SONAR? 

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.

Agile for dummies - Continuous Feedback with Customer Demos ( Greek Version )

Εισαγωγή

Δεν είναι λίγες οι φορές που οι περισσότεροι από εμάς έχουν αγανακτήσει για τη δυσκολία που έχει ο πελάτης στο να αποφασίσει τι τελικά χρειάζεται από ένα σύστημα, αλλά και την άνεση με την οποία αλλάζει τις προδιαγραφές. Ενώ αυτό θα έπρεπε να μας χαροποιεί, μας δημιουργεί αναστάτωση και με το πρώτο μήνυμα αλλαγής προδιαγραφών,ειδικά σε προχωρημένες φάσεις ενός project, έρχεται η καταστροφή. Και φυσικά για όλα τα παραπάνω φταίει αυτό το ανικανοποίητο και αναποφάσιστο πλάσμα που το ονομάζουμε «πελάτης». Όσες φορές κι αν προσπαθήσαμε να «κλειδώσουμε» τις προδιαγραφές στα πρώτα στάδια του project είτε επειδή έτσι το προβλέπει η σύμβαση μαζί του, είτε επειδή «πρέπει να ξέρουμε εκ των προτέρων τι έχουμε να υλοποιήσουμε», το μόνο που καταφέραμε είναι να έρθουμε σε ρήξη από την αρχή του project και να «επιτύχουμε» τα αντίθετα αποτελέσματα. Είμαστε τελικά δέσμιοι των ορέξεων των πελατών; Φυσικά και όχι. Ο σκοπός μας είναι, ή τουλάχιστο πρέπει να είναι, η παράδοση ενός συστήματος που καλύπτει όσο το δυνατόν καλύτερα, και πάντα μέσα στο budget, τις επιχειρησιακές του ανάγκες. Υπάρχει τρόπος να τα καταφέρουμε, και δεν είναι δύσκολος.

Η εφαρμογή της πρακτικής

Οι συχνές παρουσιάσεις για άμεση ανατροφοδότηση είναι πολύτιμες και έρχονται να καλύψουν το κενό που υπάρχει μεταξύ της ομάδας ανάπτυξης (τι υλοποιείται) και των τελικών χρηστών (τι τελικά θέλουν). Το γεγονός ότι λαμβάνουν μέρος σε τακτά διαστήματα από την αρχή του project, διασφαλίζει ότι οι κρίσιμες αλλαγές εντοπίζονται όσο πιο άμεσα γίνεται. Έτσι το κόστος υλοποίησης είναι σαφώς μικρότερο από την περίπτωση που θα ανακαλύπτονταν η ίδια αλλαγή πολύ αργότερα και όταν το project θα είχε προχωρήσει σημαντικά. Όπως σε κάθε Agile πρακτική, ωστόσο, έτσι και στις συχνές παρουσιάσεις καλό είναι να ακολουθούνται ορισμένοι κανόνες ώστε να έχουμε το μέγιστο επιθυμητό αποτέλεσμα. Οι παρακάτω σύντομες οδηγίες αφορούν κυρίως projects στα οποία ο πελάτης είναι ένας και μπορεί να προσωποποιηθεί.

• Από την αρχή του project, λοιπόν, τον ενημερώνουμε για την τακτική που έχουμε σκοπό να εφαρμόσουμε και προσπαθούμε να εξηγήσουμε την ανταποδοτικότητά της, ότι γίνεται δηλαδή για να κατανοήσουμε καλύτερα τις ανάγκες του, αλλά και για να καταλάβει ο ίδιος τι ακριβώς χρειάζεται από το σύστημα.
• Σε περίπτωση που υπάρξει δυσαρέσκεια για την ύπαρξη τόσων πολλών «εκδόσεων», είναι καλό να αποσαφηνίσουμε ότι δεν είναι πραγματικές εκδόσεις, αλλά εσωτερικά demos, τα οποία δε θα διανεμηθούν σε όλους τους χρήστες.  Είναι πολύτιμα ωστόσο για την έγκαιρη διάγνωση λανθασμένων προδιαγραφών
• Σεβόμαστε τους διαθέσιμους χρόνους των πελατών. Προσπαθούμε να βρούμε μία προσέγγιση που να εξυπηρετεί όλους. Αν ο πελάτης δεν μπορεί να συμμετάσχει στην παρουσίαση στο τέλος κάθε iteration (για παράδειγμα κάθε δύο ή τρεις εβδομάδες) του αντιπροτείνουμε ένα demo κάθε μήνα (είναι το μέγιστο χρονικό διάστημα το οποίο πρέπει να επιδιώκουμε)
• Εξασφαλίζουμε ότι έχουμε πραγματικά να δείξουμε κάτι. Νέα χαρακτηριστικά, νέες λειτουργίες, είναι απαραίτητες να υπάρχουν και συνάμα να μην έχουν προβλήματα.  Αν ο πελάτης απογοητευτεί από ένα μη σταθερό demo, τότε το πιο πιθανό είναι να χάσει την εμπιστοσύνη του στην ομάδα ανάπτυξης και να δυσπιστεί σε κάθε προσπάθεια επόμενων παρουσιάσεων.
• Η παρουσίαση γίνεται αποκλειστικά από ένα μέλος της ομάδας ώστε να καθοδηγήσει τον πελάτη στα σημεία που χρήζουν προσοχής και σχολιασμού. Δεν αφήνουμε τον πελάτη να «παίξει» με την έκδοση. Του υπενθυμίζουμε ευγενικά το σκοπό της πρακτικής και ότι το demo δεν είναι κατάλληλο για beta testing.
• Ξεκαθαρίζουμε πριν από κάθε παρουσίαση ότι το προϊόν / σύστημα είναι ακόμα υπό ανάπτυξη και δεν είναι η τελική έκδοση που θα διανεμηθεί. Προσπαθούμε να εστιάσουμε σε ουσιαστικά σχόλια επιχειρησιακών αναγκών, χωρίς αυτό να σημαίνει ότι αγνοούμε προτάσεις για τη χρηστικότητα, το user interface κτλ.

Product vs Project
Ωραία όλα τα παραπάνω, αλλά τι γίνεται στις περιπτώσεις που δεν έχουμε ένα διακριτό πελάτη, αλλά το προϊόν μας απευθύνεται σε αρκετές χιλιάδες χρηστών. Προφανώς τα παραπάνω δεν είναι καθόλου ρεαλιστικά ή μπορούν να εφαρμοστούν σε πολύ περιορισμένο βαθμό. Για το λόγο αυτό υπάρχουν μερικές εναλλακτικές ενέργειες που προσπαθούν να καλύψουν την αδυναμία υιοθέτησης της πρακτικής σε τέτοιου είδους προϊόντα.

• Η δημιουργία video επίδειξης στα οποία θα παρουσιάζονται τα νέα χαρακτηριστικά των συστημάτων σε κάθε έκδοση – πριν από την επίσημη ανακοίνωσή της. Κάτι σαν pre-release announcement. Το βασικότερο πλεονέκτημα αυτής της προσέγγισης είναι ότι με ελάχιστο κόστος, μπορούμε να δείξουμε σε πολύ μικρό χρονικό διάστημα (η διάρκεια του video δεν πρέπει να ξεπερνάει τα 3 λεπτά), τα συγκεκριμένα χαρακτηριστικά που χρειαζόμαστε για να διαφημίσουμε την νέα έκδοση και να λάβουμε ανάλογο feedback από τους πελάτες μας.
• Η δημιουργία demo sites στα οποία οι πελάτες ( υφιστάμενοι και υποψήφιοι ) έχουν τη δυνατότητα να δοκιμάζουν τις νέες εκδόσεις (Beta versions , Release Candidate versions ) και να αποστέλλουν με μία καθορισμένη διαδικασία τα σχόλιά και τις παρατηρήσεις τους.

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

Συνοψίζοντας τα παραπάνω παρουσιάζω ενδεικτικά μερικά από τα οφέλη της πρακτικής:

• Έγκαιρη διάγνωση λανθασμένων προδιαγραφών.
• Διόρθωση της «πορείας» του project με χαμηλό κόστος.
• Συνεχής επικοινωνία με τον πελάτη. Αίσθημα συμμετοχής στη διαμόρφωση του project.
• Δημιουργικό κλίμα μεταξύ της ομάδας ανάπτυξης και των τελικών χρηστών.
• Ενδυνάμωση της εμπιστοσύνης.
• Οι πιο κρίσιμες λειτουργίες παραδίδονται ολοκληρωμένες χωρίς να χρειάζεται να φτάσουμε στις τελευταίες φάσεις του project.

My first opensource journey

A few weeks ago, without any particular reason, probably to satisfy my continuous research for new hobbies and interests, I decided to contribute to an open-source project, initially developing a small plugin (module). The truth is that I did not take under consideration what I might encounter during this effort. Now, having completed the first version of the plugin, I feel that I finished a short journey in a different world of software development from that than I knew, and with this post I would like to share my experiences. Before that, however, I believe that it is appropriate to shortly describe what the plugin is about.

For over a year I am using the (in my humble opinion) ultimate tool for software quality which is Sonar. What makes Sonar so perfect and amazing? The infinite possibilities that offers to a software team in order to monitor the quality of a project under development / maintenance in detail. it covers the 7 axes of code quality: Design and Architecture, Duplicate Code, Unit Tests , complexity, potential software defects, Comments, and finally code rules.Integration with other popular systems like Maven as build system, and Jenkins for Continuous Integration practices, definetely increase its capabilities. Of course, to be honest, to benefit from Sonar, it is not enough just to keep track of code quality, but rather to act continuously towards improvement. The plugin, therefore, I developed for the Sonar, provides integration with Google Calendar, which is part of the suite of applications offered free by Google. Whenever Sonar completes the analysis a quality project, the plugin takes action and creates an event in Google Calendar set by the end user.

What did I encounter during my first opensource try?

Firstly I found a very structured and well-organized environment/community that provides tools for rapid development of plugins, control them, test their usage by other developers (SNAPSHOT release) and final publish them to thousands of Sonar users. The developers, are always willing to contribute their knowledge, ideas and comments whether positive or negative. There are rules and procedures, strictly followed by everyone, that define how the code is developed, how the documentation is written, about automated build processes and quality ( eat your Own Food ), even how much spaces should have the pom.xml file that describe the plugin. At almost every step there were a sonar core developer who was correcting me (thank you Evgeny!) and was giving extrelemely valuable feedback. I confess that after fifteen years of experience (?) In software development I felt like a student who developed my first Hello World example! Even how and when a plugin is ready for release is determined by a voting process among active developers/contributors of the project. All so different from what I was used or learned so far and so exciting for someone who wants to work within a standardized environment.

What have I learned - How have I expanded my technical knowledge?

I extended my knowledge around Maven. I learned new features in practice and how they serve specific purposes during the development of a (sub) system.

I studied a working example of a modular system without the cumbersome use of other technologies like OSGI. Besides, I used it to develope, test and release the plugin!!

I discovered the new google-api-client and more specifically the part that needs to process data in google calendar. A completely different API, and an approach that only ... Google could ever follow!
Finally I participated in a community of developers with different skills and knowledge, but they all respect each other and exchange ideas and comments without hesitation and intolerance.


My feelings
Initially, enthusiasm, which was then replaced by deep speculation until I managed to understand both systems and their API (Sonar/Google Calendar). With the completion of a beta release I started receiving feedback. That was a grear disappointment but make me try even harder for the final result. New efforts for better quality , always attached to the prescribed rules and procedures.Finally the first version is ready. It is approved by developers community and to be honest I feel as proud as I felt when I was finishing some lab exercises back in the mid-90s ? 

For one thing I am absolutely sure ... The open source software community of Sonar won one more supporter and as my free time permits I will continue to contrinute to it!

P.S. More Info about the plugin can be found at http://docs.codehaus.org/x/KAB-D 

My first opensource journey - Greek Version

For english version please visit this blog

Πριν από λίγο καιρό, χωρίς να υπάρχει ιδιαίτερος λόγος, μάλλον για να ικανοποιήσω τις ασταμάτητες ανησυχίες μου για νέες ασχολίες και ενδιαφέροντα, αποφάσισα να συνεισφέρω σε ένα open-source project, αναπτύσσοντας αρχικά ένα μικρό plugin (υποσύστημα). Η αλήθεια είναι ότι δεν το πολυ-σκέφτηκα, ούτε ήξερα τι θα συναντούσα στην πορεία. Σήμερα, έχοντας ολοκληρώσει την πρώτη έκδοσή του, νιώθω ότι τελείωσα ένα μικρό ταξίδι, σε έναν διαφορετικό κόσμο ανάπτυξης λογισμικού από αυτόν που ήξερα, και με αυτό το post θέλω να μοιραστώ τις εμπειρίες μου. Πριν από αυτό, ωστόσο, κρίνω σκόπιμο να περιγράψω με λίγα λόγια το ίδιο το plugin.

Εδώ και πάνω από ένα χρόνο χρησιμοποιώ το ( κατά την ταπεινή μου άποψη ) απόλυτο εργαλείο ποιότητας λογισμικού που ακούει στο όνομα Sonar. Τι είναι αυτό που κάνει το Sonar τόσο τέλειο και καταπληκτικό; Μα, οι δυνατότητες που δίνει σε μία ομάδα λογισμικού να παρακολουθεί την ποιότητα ενός project υπό ανάπτυξη/συντήρηση με κάθε λεπτομέρεια. Οι άξονες στους οποιούς κινείται είναι οι εξής 7: Σχεδίαση και Αρχιτεκτονική, Διπλός Κώδικας, Unit Tests, Πολυπλοκότητα, Πιθανές ατέλειες λογισμικού, Σχόλια και τέλος Κανόνες Κωδικά. Η συνεργασία του με άλλα δημοφιλή συστήματα, όπως το Maven ως βuild σύστημα, και το Jenkins για συνεχή ολοκλήρωση, αυξάνουν κατακόρυφα τις δυνατότητές του. Βέβαια, για να είμαστε ειλικρινείς, για να επωφεληθεί μία ομάδα λογισμικού από το Sonar, δεν αρκεί να καταγράφει την ποιότητα του κώδικα, αλλά κυρίως να ενεργεί συνεχώς προς την κατεύθυνση της βελτίωσής της. Το plugin, λοιπόν, που ανέπτυξα για το Sonar, παρέχει ολοκλήρωση (Integration) με το Google Calendar, που αποτελεί μέρος της σουιτάς εφαρμογών που παρέχει δωρεαν η Google. Κάθε φορά που το Sonar ολοκληρώνει την ανάλυση ποιότητας ενός project, τότε το plugin αναλαμβάνει δράση και δημιουργεί ένα event στο Google Calendar που έχει ορίσει ο χειριστής.

Τι συνάντησα λοιπόν από την πρώτη ημέρα που ξεκίνησα την ανάπτυξη μέχρι σήμερα;

Καταρχάς βρήκα ένα πολύ οργανωμένο περιβάλλον/κοινότητα το οποίο παρέχει εργαλεία για τη γρήγορη ανάπτυξη υποσυστημάτων, τον έλεγχο αυτών, τη δοκιμαστική τους χρήση από άλλους developers (SNAPSHOT release) και την οριστική τους διάθεση στους χιλιάδες χρήστες του Sonar. Οι developers, είναι πάντα πρόθυμοι να συνεισφέρουν με τις γνώσεις, τις απόψεις και τα σχόλιά τους είτε αυτά είναι θετικά είτε αρνητικά. Υπάρχουν κανόνες και διαδικασίες που τηρούνται πιστά από όλους. Από το πως θα αναπτύσσεται ο κώδικας, το documentation, οι διαδικασίες αυτοματοποιημένου build και ποιότητας (eat your own food) μέχρι πόσα space πρέπει να έχουν τα XML αρχεία που περιγράφουν το υποσύστημα. Σε κάθε μου βήμα σχεδόν υπήρχε ένας developer που με διόρθωνε. Ομολογώ ότι μετά από δεκαπέντε χρόνια εμπειρίας(;;) στην ανάπτυξη λογισμικού ένιωθα σα φοιτητής που έγραφα το πρώτο μου Hello World παράδειγμα!!! Ακόμα και το πως/πότε ένα plugin θεωρείται έτοιμο για release καθορίζεται από μία διαδικασία ψηφοφορίας ανάμεσα στους ενεργούς developers/contributors του project. Όλα τόσο διαφορετικά από αυτά που είχα συνηθίσει ή μάθει μέχρι τώρα και τόσο συναρπαστικά για κάποιο που θέλει να δουλεύει με οργάνωση και τυποποίηση.

Τι έμαθα - Πως επέκτεινα τις γνώσεις μου τεχνικά;

Έμαθα πως αξιοποιείται το Maven στην ολότητά του. Έμαθα νέα χαρακτηριστικά στην πράξη και πως αυτά εξυπηρετούν συγκεκριμένους σκοπούς κατά τη διάρκεια ανάπτυξης ενός (υπο)συστήματος.

Μελέτησα ένα ζωντανό παράδειγμα modular συστήματος χωρίς τη χρήση άλλων δυσκίνητων τεχνολογιών όπως το OSGI. Άλλωστε το χρησιμοποίησα για να αναπτύξω το plugin!!

Γνώρισα το νέο google-api-client και πιο συγκεκριμένα το κομμάτι που χρειάζεται για την επεξεργασία δεδομένων στο google calendar. Ένα εντελώς διαφορετικό API και μία προσέγγιση που μονο ... η Google θα μπορούσε να έχει!!
Συμμετείχα σε μία κοινότητα από developers με διαφορετικές εξειδικεύσεις και γνώσεις, οι οποίοι όμως όλοι σέβονται ο ένας τον άλλον και ανταλλάσσουν απόψεις χωρίς ενδοιασμούς και μισαλλοδοξία.

Τα συναισθήματά μου
Αρχικά ενθουσιασμός, στη συνέχεια προβληματισμός μέχρι να καταλάβω τα δύο συστήματα και τα API τους (Sonar/Google Calendar). Με την ολοκλήρωση μιας πρώτης έκδοσης, άρχισαν οι παρατηρήσεις. Απογοήτευση αλλά συνάμα μεγαλύτερη επιμονή για το τελικό αποτέλεσμα. Νέες προσπάθειες για ποιοτικότερη εργασία, προσαρμοσμένη στους προβλεπόμενους κανόνες και διαδικασίες. Η πρώτη έκδοση είναι έτοιμη. Άγχος για τη ψηφοφορία. Θα εγκριθεί το plugin από την κοινότητα ή όχι. Θα μπορέσω να νιώσω τόσο υπερήφανος ξανά όσο όταν ολκλήρωνα τις ασκήσεις στα εργαστήρια της σχολής; Ακόμα δε ξέρω... σε λίγες ημέρες όμως θα το γνωρίζω ... 

Για ένα όμως είμαι σίγουρος... το open source λογισμικό κέρδισε ακόμα έναν υποστηρικτή και όσο μου το επιτρέπει ο ελεύθερος χρόνος μου θα συνεχίζω να ασχολούμαι ενεργά!!