Project Management

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

THEOFANIS GIOTIS | PMP, PMI-ACP, MCT, MSc, PhD C. — Wed, 16 Nov 2011 23:55:35 GMT

The correct answer is:
"Do not look who is right. Look for what is Right!!!"

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

dimos.homatas — Wed, 16 Nov 2011 23:43:43 GMT

Antonios Chatzipavlis:
Εγω ο εγκάθετος θα τράβηξω την κουρτίνα ή το πέπλο που δεν σαν αφήνει να δείτε αλλιώς τα πράγματα.

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

Ο κώδικας βουβουζελα ή πάστα ή όπως θέλετε να το λέτε γίνεται γιατι φταίει ο PM ή ο developer που τον έγραψε;

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

Με εκτίμηση
Ένας προγραμματιστής τα τελευταία 25 χρόνια

Απαντώ πρώτος:

Για την ποιότητα του κώδικα ευθύνονται κατά σειρά προτεραιότητας:

Πρώτα και κυριότερα ο προγραμματιστής που δεν το έγραψε σωστά. Ο έμπειρος μάλιστα πρέπει να προβλέπει τις ελλείψεις πχ των analysts, pms κλπ.

Κατόπιν ευθύνεται ο εκάστοτε team leader / technical leader κλπ που δεν έκανε σωστά (ή καθόλου) το code review για να ελέγξει τον (πιθανώς νέο και άπειρο, ποιος ξέρει) προγραμματιστή

Και τέλος ευθύνονται οι pms που δεν επιβάλλουν κάποια coding standards / guidelines στα project αυτά.

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

Όλα αυτά from a programmer's perspective πάντα.

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

THEOFANIS GIOTIS | PMP, PMI-ACP, MCT, MSc, PhD C. — Wed, 16 Nov 2011 21:28:47 GMT

http://www.dotnetzone.gr/cs/forums/68154/ShowThread.aspx#68154

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

THEOFANIS GIOTIS | PMP, PMI-ACP, MCT, MSc, PhD C. — Wed, 16 Nov 2011 21:23:10 GMT

Παναγιώτη μου αυτά τα έχουν λύσει άλλοι για εμάς.

Όταν κοιτάς τον προβληματικό κώδικα, ΕΙΝΑΙ ΠΟΛΥ ΑΡΓΑ... Είναι σαν να κοιτάς καμμένη μηχανή αυτοκινήτου επειδή δεν είχε λάδια και να θες να την βελτιώσεις.

Αυτή η προσέγγιση λέγεται Reactive και είναι postmortem. Η σωστή προσέγγιση είναι η reactive και πες την να όπως θες. Εγώ την Project Management, Quality planning, quality metrics, quality assurance κλπ.

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Antonios Chatzipavlis — Wed, 16 Nov 2011 21:17:43 GMT

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

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

Ο κώδικας βουβουζελα ή πάστα ή όπως θέλετε να το λέτε γίνεται γιατι φταίει ο PM ή ο developer που τον έγραψε;

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

Με εκτίμηση

Ένας προγραμματιστής τα τελευταία 25 χρόνια

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

dimos.homatas — Wed, 16 Nov 2011 20:56:41 GMT

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

Προσωπικά έχοντας κυριολεκτικά άμεση εμπειρία με βουβουζέλα code (νοτιοαφρικάνικη εταιρία βλέπετε!) μπορώ να πω με ασφάλεια ότι βλέπω προσπάθεις project management με διάφορες μεθοδολογίες να μην μπορούν να στεριώσουν, αλλά ενώ όλοι κοιτάνε το process, κανείς δεν κοιτάει τον υπάρχοντα κώδικα που θέλουν πχ να επεκτείνουν!

Όταν έχεις όλα τα είδη του Pasta Code δεν σε σώζει κανένα PM... εάν δεν υπάρχουν coding standards, conventions & principles, όλα τα άλλα είναι μπαλώματα.

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

THEOFANIS GIOTIS | PMP, PMI-ACP, MCT, MSc, PhD C. — Wed, 16 Nov 2011 20:23:27 GMT

Μερικά σχόλια:
- "φυσιολογικές παραμέτρους" σημαίνει Best Practices ή χρήση της κανονικής κατανομής για να βρείς τι γίνεται (πχ. η Ιατρική το κάνει αυτό)
- "προγραμματιστής δεν είναι επικίνδυνος για την κοινωνία" Μόνο η εταιρεία στην οποία εργάζεται ή οι πελάτες του μπορούν να το κρίνουν.

Επίσης το μοντέλλο DIKW (Data, Information, Knowledge, Wisdom) βοηθά πάρα πολύ στην επεξεργασία των πληροφοριών.

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Παναγιώτης Καναβός — Wed, 16 Nov 2011 20:09:58 GMT

Η αγγλική γλώσσα, όπως και η ελληνική, δίνει διαφορετικές σημασίες στην ίδια λέξη. Όταν μιλάμε σε επιστημονικό επίπεδο, Empirical σημαίνει Εμπειρική παρατήρηση, ή με άλλα λόγια, παρατηρώ και καταγράφω τί σημαίνει. Δεν διαφέρει και τόσο από τις δύο έννοιες που έχει η ίδια λέξη και στα Ελληνικά. Όταν διαβάζουμε μία δημοσίευση στο IEEE Transactions on Software ή στο ACM, Empirical σημαίνει παρατήρηση, σε αντίθεση με το Theoretical.

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

Εξάλλου, το άρθρο δεν έχει να κάνει με γλωσσολογία. Τα περιεχόμενα και το συμπέρασμα του άρθρου έχουν σημασία: Τα στοιχεία αποδεικνύουν ότι πολλές από τις παραδοχές που κάναμε ως τώρα για το software development και το Project management δεν ανταποκρίνονται στην πραγματικότητα.

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

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

Θα ήταν ανόητο όμως να επιμείνω στις παλιές προσπάθεις όταν τα στοιχεία μου λένε το αντίθετο.

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

THEOFANIS GIOTIS | PMP, PMI-ACP, MCT, MSc, PhD C. — Wed, 16 Nov 2011 19:32:15 GMT

Tο empirical 'everything' έχει να κάνει με εμειρία και παρακολούθηση http://en.wikipedia.org/wiki/Empirical. Στο Project Management το ονομάζουμε "Best Practices and Historical Information".

Αδυνατώ όμως να κατανοήσω πως μπορεί το: "Εγώ έχω μάθει να πετάω το A380 από μόνος μου" μπορεί να υποκαταστήσει τις σχολές πιλότων...

Η σωστή προσέγγιση είναι γνωστή. Την έχουν ανακαλύψει άλλοι:
-Education
-Traning
-Experience

Πέραν τούτου μάλλον ουδέν...

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Παναγιώτης Καναβός — Fri, 21 Oct 2011 06:18:59 GMT

Refactoring?? Αν ήξερες πόσο συχνά πατάω Ctrl+M (extract method), Ctrl+F (extract field), Ctrl+P (introduce parameter) κάθε ώρα ... Όσο πιο έμπειρος είναι κανείς τόσο περισσότερο χρησιμοποιεί refactoring αντί να προσπαθεί να κάνει τον ίδιο κώδικα να δουλέψει. Τόσο περισσότερο θα πειραματιστεί μέχρι να πετύχει αυτό που θέλει, τόσα περισσότερα tests θα γράψει.

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

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

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Markos — Fri, 21 Oct 2011 04:35:03 GMT

Παναγιώτης Καναβός:

...Τα metrics προσπαθούνε να εκτιμήσουν την αιτία. Δεν είναι το ίδιο πράγμα....

Η όλη συζήτηση ανέδειξε την αναποτελεσματικότητά τους. Δε λέω ότι έχω δίκιο. Απλά, προσπαθώ να δώσω μια άλλη προοπτική. Πιστεύω ότι τα αποτελέσματα μιας αντίστοιχης έρευνας, για την παραγωγικότητα και την ικανότητα των προγραμματιστών, θα ήταν εξίσου ενδιαφέροντα αν η τελευταία γινόταν βασισμένη στις "αντίθετες παραδοχές". Δε ψάχνω, δηλαδή, να βρω τον καλό πιανίστα με βάση το πόσα πλήκτρα πάτησε σωστά, αλλά με βάση το πόσα πάτησε λάθος και πόσες φορές αναγκάστηκε να "παίξει" το ίδιο κομμάτι για να το κάνει σωστά (μην ξεχνάμε το refactoring).

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Παναγιώτης Καναβός — Fri, 21 Oct 2011 04:25:01 GMT

Markos:
Προσπαθούμε μετρήσουμε το "καλό", ενώ στην ουσία το μόνο αξιόπιστα μετρήσιμο είναι το "κακό".

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

Να το πω αλλιώς. Τα bug σημαίνουν ότι το αυτοκίνητο κλάταρε. Τί να μετρήσω ότι κλάταρε, το ξέρω ότι κλάταρε, το βλέπω μπροστά μου. Μπορώ όμως με κάποιο τρόπο να εκτιμήσω ποιό αυτοκίνητο θα κλατάρει ή πότε?

Αποδεικνύεται ότι τα περίπλοκα code metrics ΔΕΝ μπορούν να εκτιμήσουν πού θα εμφανιστούν bugs καλύτερα από τα απλά LOCs.

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Παναγιώτης Καναβός — Fri, 21 Oct 2011 04:16:59 GMT

dimos.homatas:
Ωραίο άρθρο, με πολύ καλά points, μία ερώτηση μόνο:

We are skeptical of this work, for the very reasons that we are committed to empirical software engineering research. We believe that it puts the cart before the horse, that we simply don’t yet know enough about what actually works and what doesn’t to define such standards.

Δηλαδή το... πετάμε το SWEBOK;

Πετάει ο ζαχαροπλάστης τις συνταγές του? Ακόμα και την καλύτερη σχολή να έχεις βγάλει όμως, Παρλιάρος ή Pierre Herme δεν γίνεσαι επειδή πήρες το χαρτί.

Η επαγγελματική πιστοποίηση (ΟΧΙ τα certifications), όπως και η άδεια του μηχανικού, δεν λέει ότι είσαι καλός μηχανικός αλλά ότι έχεις τις ελάχιστες απαιτούμενες γνώσεις για να μην πάρεις τους άλλους στο λαιμό σου. Άσε που οι άδειες των μηχανικών έχουν επίπεδα τα οποία αποκτάς ανάλογα με την εμπειρία και τα έργα που έχεις κάνει. Απαγορεύεται να κτήσεις πολυκατοικία όταν μόλις έχεις βγει από τη σχολή.

Η πιστοποίηση θα "κόψει" τους άσχετους, δεν θα αναδείξει τους καλούς. Οι πιστοποιήσεις είναι απαραίτητες γιατί ο χώρος της πληροφορικής έχει γεμίσει με κάθε καρυδιάς καρύδι. Υπάρχουν καλοί προγραμματιστές χωρίς πτυχίο και διδακτορικοί που είναι επικίνδυνοι για τη δημόσια ασφάλεια. Μία σωστή πιστοποίηση (και τί σημαίνει αυτό?) μπορεί να κόψει κάποιο ποσοστό άσχετων αλλά μέχρι εκεί.

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Markos — Fri, 21 Oct 2011 04:12:59 GMT

Παναγιώτης Καναβός:
Ο αριθμός και η συχνότητα των σφαλμάτων ΔΕΝ είναι code metrics. Είναι το αποτέλεσμα της κακής ποιότητας που θέλουμε να εκτιμήσουμε και να προλάβουμε (WARNING εκτίμηση != μέτρηση).

Ίσως αυτό να είναι το λάθος της προσέγγισης με τα code metrics. Προσπαθούμε μετρήσουμε το "καλό", ενώ στην ουσία το μόνο αξιόπιστα μετρήσιμο είναι το "κακό". Μήπως τελικά πρέπει ν' αρχίσουμε να βλέπουμε τα πράγματα μέσα από τον καθρέφτη;

Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι

Παναγιώτης Καναβός — Fri, 21 Oct 2011 04:07:03 GMT

Το σημαντικό με το άρθρο και το βιβλίο είναι ότι δεν βασίζονται σε απόψεις αλλά σε μετρήσεις. Και οι μετρήσεις λένε ότι τα code metrics δεν είναι καλύτερα από τα απλά LOCs στην εκτίμηση της ποιότητας και κατ' επέκταση στην πιθανότητα εμφάνισης σφαλμάτων.

Ο αριθμός και η συχνότητα των σφαλμάτων ΔΕΝ είναι code metrics. Είναι το αποτέλεσμα της κακής ποιότητας που θέλουμε να εκτιμήσουμε και να προλάβουμε (WARNING εκτίμηση != μέτρηση). Σκοπός των code metrics είναι να εκτιμήσουν την ποιότητα και κατά συνέπεια την πιθανότητα εμφάνισης των σφαλμάτων - και φαίνεται ότι δεν επαρκούν.