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) και με αυτόν τον τρόπο θυμούνται πιο εύκολα τι έχουν να κάνουν.

Ένα ... click ... πριν την ολοκλήρωση

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

Ένα έργο, λοιπόν (για να είμαι ακριβής, μία σειρά από έργα), που δεν είναι υπερβολή να το χαρακτηρίσω ισάξιο του TAXIS, είναι η πλήρης, και τονίζω τον όρο πλήρης, μηχανογράφηση του υποθηκοφυλακείου Θεσσαλονίκης και η παροχή υψηλού επιπέδου ηλεκτρονικών υπηρεσιών σε ένα ευρύ φάσμα αποδεκτών. Από το 2004 μέχρι τα τέλη του 2010 έλαβαν χώρα στον παραπάνω φορέα μία σειρά από καινοτόμες προσπάθειες και οι οποίες οδήγησαν στη σημερινή κατάσταση που μπορεί να φαντάζει ξένη στην ελληνική πραγματικότητα. Από τους αμέτρητους φακέλους στις υπερβολικά γεμάτες ντουλάπες, τις ατελείωτες ώρες αναμονής στα γκισέ και τους χώρους αναζήτησης πράξεων, και τους απαράδεκτους χρόνης απόκρισης στις εκδόσεις πιστοποιητικών και εγγραφών φτάσαμε στην ολοκληρωμένη μηχανογράφηση όπου ο καθε ενδιαφερόμενος εξυπηρετείται σε ελάχιστα λεπτά, στην πλήρη ψηφιοποίηση του ιστορικού αρχείου του υποθηκοφυλακείου από τη δεκαετία του '30 μέχρι σήμερα και στην online αναζήτηση πράξεων (μεταγραφές, υποθήκες, κατασχέσεις και αγωγές) από εξουσιοδοτημένους χρήστες (δικηγόροι, δικαστικοί επιμελητές, εφορίες κτλ. )

Κι όμως ένα τέτοιο έργο δεν είναι ακόμα ανακοινώσιμο και ευρέως διαθέσιμο. Η αιτία; Δεν βρίσκονται τα κονδύλια για να καλύψουν την ετήσια δαπάνη για μία αξιοπρεπή τηλεπικοινωνιακή γραμμή που θα είναι ικανή να εξυπηρετήσει τους χιλιάδες δυνητικούς επισκέπτες της μηχανής αναζήτησης του υποθηκοφυλακείου Θεσσαλονίκης. Έτσι ένα τόσο σημαντικό έργο περιορίζεται και βρίσκεται μεταξύ φθοράς και αφθαρσίας επιτρέποντας, δυστυχώς, την πρόσβαση σε περιορισμένο αριθμό χρηστών (μερικές δεκάδες) μέχρι να δοθεί λύσει στο πρόβλημα του τηλεπικοινωνιακού εξοπλισμού. Για το ΣΥΖΕΥΞΙΣ; Ούτε λόγος να γίνεται; Η αίτηση του φορέα σίγουρα βρίσκεται σε κάποιο συρτάρι εδώ και 1 1/2 χρόνο. 

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

Τι περιμένουμε;

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, αλλά μας «απελευθερώνει» ώστε να αφοσιωθούμε στον λεπτομερή έλεγχο κρίσιμων και περίπλοκων λειτουργιών του λογισμικού.