Μεγάλη υπόθεση το θέμα που άνοιξες.
Ο σοφός συνάδελφος σου, είχε απόλυτο δίκιο! Οι περισσότεροι πέφτουμε τουλάχιστον 100% έξω σε οποιοδήποτε estimation ενός task οποιουδήποτε project, πόσο μάλλον για estimation του τελικού χρόνου παράδοσης ολόκληρου του έργου.
Και ακόμα πιο δύσκολο είναι όταν εμπλέκεται ομάδα. Το σημαντικό για αρχή είναι φυσικά το οποιοδήποτε project να κοπεί σε αρκετά features/tasks. Προσωπικά έχω διαπιστώσει ότι οι ώρες που λέει ο κάθε developer είναι σχεδόν αυθαίρετες μιας και έχουν διακύμανση ανάλογα με το πόσο θεωρεί ο καθένας μας εύκολο κάτι ή όχι (το οποίο σε μια ομάδα developers δεν μπορείς να φανταστείς τελικά πόσο σχετικό είναι).
Ο
γνωστός Joel έχει δημιουργήσει το λεγόμενο
Evidence Based Scheduling, το οποίο παραδόξως είναι αρκετά αποτελεσματικό, μιας και λαμβάνει υπόψη του αυτή την αβεβαιότητα του κάθε developer και μετά από αρκετό καιρό μπορεί να υπολογίσει με αρκετή σαφήνεια το πραγματικό delivery date. Οπότε π.χ. ένα υποθετικό παράδειγμα αν σε μία ομάδα ο Κώστας θέτει 1h και πάντα τελειώνει σε x4 ώρες, ο Γιάννης θέτει 1h και τελειώνει πάντα στα 50m, τότε ο Γιάννης είναι πολύ πιο ακριβής άρα και αξιόπιστος στις εκτιμήσεις του κ.τ.λ. Αλλά δυστυχώς το FogBugz είναι πανάκριβο!
Προσωπικά έχω καταλήξει ότι ο υπολογισμός με βάση τις ώρες είναι καταδικασμένος εξ' αρχής. Το ανθρώπινο μυαλό απλά δεν είναι φτιαγμένο στο να υπολογίζει σωστά το χρόνο!
Πολύ καλή τεχνική είναι το λεγόμενο
Planning Poker. Προϋποθέτει την ύπαρξη μιας ομάδας τουλάχιστον 4 ατόμων, και το βασικό είναι ότι αφαιρεί εντελώς την έννοια των ωρών. Ουσιαστικά το κάθε μέλος της ομάδας έχει τη δική του τράπουλα η οποία έχει τη κλίμακα Fibonacci (ή σχεδόν αυτή γιατί διαφέρουν κάποια νούμερα) και ψηφίζει κρυφά από τους άλλους το βαθμό δυσκολίας κάθε task. Μετά ανοίγουν όλοι μαζί τα χαρτιά τους και βλέπουν τις αποκλίσεις. Αυτός που έχει το μεγαλύτερο αριθμό συζητάει με αυτόν που έχει το μικρότερο αριθμό για τους λόγους που το διάλεξαν. Έτσι ξανά επαναλαμβάνεται η ψηφοφορία μέχρι όλη η ομάδα να καταλήξει σε ένα κοινό αποτέλεσμα. Το τελικό αποτέλεσμα δείχνει πάντα τη πολυπλοκότητα ενός task.
Με βάση αυτό το νούμερο, και μετά από ένα βάθος χρόνου, όπου μπορεί να βγει ένα ασφαλές συμπέρασμα για το μέσο όρο των "μονάδων" που η ομάδα αποδίδει σε ένα συγκεκριμένο χρονικό διάστημα είναι πολύ πιο εύκολο να καθοριστεί η τελική ημερομηνία (επίσης σε αυτό βοηθάνε και μέθοδοι όπως το
Scrum, αλλά είναι άλλη συζήτηση).
έχω κολλήσει πολύ άσχημα ρε παιδιά, είναι το άμεσως μεγαλύτερο μετά τα hash tables της C, εκεί ευτυχώς το βρήκα..αι να δούμε εδω 