|
|
-
 20-10-2011, 19:07
|
|
|
Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Μόλις διάβασα το Empirical Software Engineering στο American Scientist και εντυπωσιάστικα από τα συμπεράσματα που καταρρίπτουν κάποιες από τις πιο βασικές "αλήθεις" του HR και του project management. Σημειωτέον, δεν μιλάμε για έρευνα σε λίγα projects αλλά για την ανάλυση των δεδομένων που έχουν συλλεχθεί σε data repositories από τη NASA και το αμερικάνικο National Science Foundation για χρήση από όλους τους ερευνητές. Τα σχόλια δικά μου - Βάση των στοιχείων, τα διάφορα metrics δεν προσφέρουν περισσότερη πληροφορία για την ποιότητα του κώδικα από το απλό Lines Of Code. (Αυτά για τη μανία να μετράμε πράγματα που δεν μετριώνται, μόνο και μόνο για να νοιώσουμε πιο άνετα)
- Το pair programming οδηγεί αρχικά σε μείωση της απόδοσης καθώς οι προγραμματιστές προσαρμόζονται στο νέο τρόπο δουλειάς, αλλά μετά ξεπερνάει την αρχική απόδοση ενώ ο παραγόμενος κώδικας είναι πιο κατανοητός και καλύτερης ποιότητας. Το ακριβώς αντίθετο απ' ότι πιστεύουν οι managers, ότι "χαλάνε" δύο άτομα για τη δουλειά "του ενός". (Πολύ ακριβή δεισιδαιμονία αυτή. Όπως λέει και το άρθρο, ο φόβος της αλλαγής είναι μεγάλος).
- Η προσωπικότητα ενός προγραμματιστή δεν έχει καμμία συσχέτιση (θετική ή αρνητική) με το πόσο καλός είναι. Εξάλλου μεταξύ των προγραμματιστών υπάρχει μεγαλύτερη ομοιογένεια στο χαρακτήρα απ' ότι σε άλλες πληθυσμιακές ομάδες. (Κάτι που αχρηστεύει τις τεχνικές αλλά και τις πεποιθήσεις του HR)
- Η μετατροπή πρόχειρων διαγραμμάτων σε ακριβή διαγράμματα UML κοστίζει περισσότερο απ' ότι αξίζουν αυτά τα διαγράμματα στους προγραμματιστές που τα χρησιμοποιούν (Κακό αυτό για το Rational Rose και το Visio, καλό για εμάς που αναγκαζόμαστε να βασανίζουμε τα σχεδιάκια μας για να ικανοποιήσουμε τα εργαλεία)
- Η δομή του κώδικα σε modules αντικατοπτρίζει την οργανωτική δομή μίας εταιρείας. Λειτουργίες οι οποίες απαιτούν τη χρήση πολλαπλών modules της εφαρμογής εμφανίζουν περισσότερα σφάλματα απ' όσες ολοκληρώνονται σε ένα module. Το οποίο σημαίνει ότι:
- Η οργανωτική διασπορά των ομάδων προκαλεί αύξηση των σφαλμάτων. Η γεωγραφική διασπορά όχι. (Γι αυτό εταιρείς διάσπαρτες στην οικουμένη μπορούν να κάνουν καλή δουλειά, ενώ άλλες δεν μπορούν να βγάλουν άκρη κι ας είναι όλοι στο ίδιο γραφείο).
Υπάρχουν φυσικά και κάποια λιγότερο εντυπωσιακά συμπεράσματα: - Ο αριθμός και η σοβαρότητα των θεμάτων ασφαλείας δεν έχει ισχυρή συσχέτιση με το αν τα project είναι open source ή όχι.
- Το είδος της εφαρμογής έχει ισχυρή συσχέτιση με τα θέματα ασφαλείας που εμφανίζονται
Το άρθρο είναι μεγάλο, οπότε είναι ευκολότερ να το διαβάσετε στην printer friendly μορφή του. Αν θα το δείξετε και στον προϊστάμενο σας είναι δικό σας θέμα. Έχω παρατηρήσει όμως ότι τίποτε δεν ενοχλεί περισσότερο από την απόδειξη ότι κάποιες "αλήθειες" είναι μύθοι ...
Υ.Γ. Το άρθρο παραπέμπει και στο Making Software: What Works and Why we Believe It των Andy Oram, Greg Wilson από τον O'Reilly, όπου ο Διομήδης Σπινέλλης αναλύει τον κώδικα ανοικτών και κλειστών λειτουργικών (FreeBSD, OpenSolaris, Linux, Windows) και καταλήγει σε παρόμοια συμπεράσματα με το άρθρο. Το βιβλίο αξίζει πραγματικά καθώς εμβαθύνει σε πολύ περισσότερους τομείς απ' ότι το άρθρο και καταρρίπτει μερικούς ακόμα από τους μύθους του project management (π.χ. Ακριβείς εκτιμήσεις? καθαρή φαντασία. Μέτρηση ατομικής παραγωγικότητας? Ανακριβής και περιττή, ξεχάστε τα performance reviews).
Έτσι για την πλάκα, θα ήθελα να δω και κάποια ανάλυση για το αν οι αυστηρές και λεπτομερείς διαδικασίες παράγουν καλύτερο κώδικα αποδοτικότερα σε σχέση με agile ομάδες με καλούς προγραμματιστές. Όχι ότι έχω καμμία αμφιβολία, αλλά ίσως να πεισθούν επιτέλους κάποιοι PM ότι απλά βασανίζουν τους προγραμματιστές τους ....
Παναγιώτης Καναβός, Freelancer Twitter: http://www.twitter.com/pkanavos
|
|
-
|
20-10-2011, 21:00
|
-
Markos
-
-
-
Μέλος από τις 26-10-2008
-
Αθήνα
-
Δημοσιεύσεις 874
-
-
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Προσωπική μου άποψη είναι πως κάποια πράγματα μπορούν να μετρηθούν και να αποτελέσουν, ως ένα βαθμό, αξιόπιστους δείκτες για την αποτελεσματικότητα και την ικανότητα ενός developer. Για παράδειγμα, το πλήθος των bugs που εμφανίζει ο κώδικας, η σοβαρότητά τους, το πόσο σύντομα διορθώνονται, καθώς και το πόσο συχνά γίνεται refactoring σε υπάρχοντα κώδικα, είναι κάποια από αυτά. Δεν γνωρίζω, βέβαια, κατά πόσο με τα υφιστάμενα εργαλεία ανάπτυξης μπορεί να γίνει "προσωποποίηση" των σφαλμάτων μιας εφαρμογής, έτσι ώστε να μπορεί να αποδοθεί το "ποιος ευθύνεται για τι". Αυτά τα μεγέθη δεν τα "πιάνουν" τα συνήθη "εργαλεία", γιατί απλά δεν εκτιμώνται με σκανάρισμα - "διάβασμα" του κώδικα. Απαιτούν μιας άλλης μορφής παρακολούθηση της εργασίας των developers και την τήρηση κάποιου αρχείου ιστορικού. Πιστεύω ότι αν κάποιος σκεφτεί λίγο περισσότερο θα μπορέσει ν' ανακαλύψει κι άλλες παραμέτρους, λιγότερο ή περισσότερο μετρήσιμες. Χωρίς, βέβαια, ν' αρνούμαι ότι κάποιες απ' αυτές θα είναι καθαρά ποιοτικού και καθόλου ποσοτικού χαρακτήρα, άρα εντελώς υποκειμενικές. Κλείνοντας, αυτό που θα ήθελα να γράψω σαν συμπέρασμα είναι πως η παραγωγικότητα ενός developer μπορεί να αξιολογηθεί με ασφάλεια ύστερα από το deployment!
Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!
|
|
-
|
20-10-2011, 21:03
|
-
dimos.homatas
-
-
-
Μέλος από τις 13-12-2010
-
Θεσσαλονίκη
-
Δημοσιεύσεις 319
-
-
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Ωραίο άρθρο, με πολύ καλά 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;
"When the darkness rises up from inside - that is normal. It's when you reach down to pull it up - that the noxious warnings sound." Tuzak, Farscape
|
|
-
|
20-10-2011, 21:07
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Το σημαντικό με το άρθρο και το βιβλίο είναι ότι δεν βασίζονται σε απόψεις αλλά σε μετρήσεις. Και οι μετρήσεις λένε ότι τα code metrics δεν είναι καλύτερα από τα απλά LOCs στην εκτίμηση της ποιότητας και κατ' επέκταση στην πιθανότητα εμφάνισης σφαλμάτων. Ο αριθμός και η συχνότητα των σφαλμάτων ΔΕΝ είναι code metrics. Είναι το αποτέλεσμα της κακής ποιότητας που θέλουμε να εκτιμήσουμε και να προλάβουμε (WARNING εκτίμηση != μέτρηση). Σκοπός των code metrics είναι να εκτιμήσουν την ποιότητα και κατά συνέπεια την πιθανότητα εμφάνισης των σφαλμάτων - και φαίνεται ότι δεν επαρκούν.
Παναγιώτης Καναβός, Freelancer Twitter: http://www.twitter.com/pkanavos
|
|
-
|
20-10-2011, 21:12
|
-
Markos
-
-
-
Μέλος από τις 26-10-2008
-
Αθήνα
-
Δημοσιεύσεις 874
-
-
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
 Παναγιώτης Καναβός:Ο αριθμός και η συχνότητα των σφαλμάτων ΔΕΝ είναι code metrics. Είναι το αποτέλεσμα της κακής ποιότητας που θέλουμε να εκτιμήσουμε και να προλάβουμε (WARNING εκτίμηση != μέτρηση).
Ίσως αυτό να είναι το λάθος της προσέγγισης με τα code metrics. Προσπαθούμε μετρήσουμε το "καλό", ενώ στην ουσία το μόνο αξιόπιστα μετρήσιμο είναι το "κακό". Μήπως τελικά πρέπει ν' αρχίσουμε να βλέπουμε τα πράγματα μέσα από τον καθρέφτη;
Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!
|
|
-
|
20-10-2011, 21:16
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
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), όπως και η άδεια του μηχανικού, δεν λέει ότι είσαι καλός μηχανικός αλλά ότι έχεις τις ελάχιστες απαιτούμενες γνώσεις για να μην πάρεις τους άλλους στο λαιμό σου. Άσε που οι άδειες των μηχανικών έχουν επίπεδα τα οποία αποκτάς ανάλογα με την εμπειρία και τα έργα που έχεις κάνει. Απαγορεύεται να κτήσεις πολυκατοικία όταν μόλις έχεις βγει από τη σχολή. Η πιστοποίηση θα "κόψει" τους άσχετους, δεν θα αναδείξει τους καλούς. Οι πιστοποιήσεις είναι απαραίτητες γιατί ο χώρος της πληροφορικής έχει γεμίσει με κάθε καρυδιάς καρύδι. Υπάρχουν καλοί προγραμματιστές χωρίς πτυχίο και διδακτορικοί που είναι επικίνδυνοι για τη δημόσια ασφάλεια. Μία σωστή πιστοποίηση (και τί σημαίνει αυτό?) μπορεί να κόψει κάποιο ποσοστό άσχετων αλλά μέχρι εκεί.
Παναγιώτης Καναβός, Freelancer Twitter: http://www.twitter.com/pkanavos
|
|
-
|
20-10-2011, 21:25
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Markos: Προσπαθούμε μετρήσουμε το "καλό", ενώ στην ουσία το μόνο αξιόπιστα μετρήσιμο είναι το "κακό".
Τα bug είναι το αποτέλεσμα. Τα metrics προσπαθούνε να εκτιμήσουν την αιτία. Δεν είναι το ίδιο πράγμα. Δεν μετράμε ούτε το καλό ούτε το κακό. Η λέξη εκτίμηση είναι σημαντική γιατί αυτό κάνουμε στην ουσία. Μετράμε ένα μέγεθος προσπαθώντας να εκτιμήσουμε ένα άλλο, γνωρίζοντας ή ελπίζοντας ότι τα δύο μεγέθη σχετίζονται. Να το πω αλλιώς. Τα bug σημαίνουν ότι το αυτοκίνητο κλάταρε. Τί να μετρήσω ότι κλάταρε, το ξέρω ότι κλάταρε, το βλέπω μπροστά μου. Μπορώ όμως με κάποιο τρόπο να εκτιμήσω ποιό αυτοκίνητο θα κλατάρει ή πότε? Αποδεικνύεται ότι τα περίπλοκα code metrics ΔΕΝ μπορούν να εκτιμήσουν πού θα εμφανιστούν bugs καλύτερα από τα απλά LOCs.
Παναγιώτης Καναβός, Freelancer Twitter: http://www.twitter.com/pkanavos
|
|
-
|
20-10-2011, 21:35
|
-
Markos
-
-
-
Μέλος από τις 26-10-2008
-
Αθήνα
-
Δημοσιεύσεις 874
-
-
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Παναγιώτης Καναβός:
...Τα metrics προσπαθούνε να εκτιμήσουν την αιτία. Δεν είναι το ίδιο πράγμα....
Η όλη συζήτηση ανέδειξε την αναποτελεσματικότητά τους. Δε λέω ότι έχω δίκιο. Απλά, προσπαθώ να δώσω μια άλλη προοπτική. Πιστεύω ότι τα αποτελέσματα μιας αντίστοιχης έρευνας, για την παραγωγικότητα και την ικανότητα των προγραμματιστών, θα ήταν εξίσου ενδιαφέροντα αν η τελευταία γινόταν βασισμένη στις "αντίθετες παραδοχές". Δε ψάχνω, δηλαδή, να βρω τον καλό πιανίστα με βάση το πόσα πλήκτρα πάτησε σωστά, αλλά με βάση το πόσα πάτησε λάθος και πόσες φορές αναγκάστηκε να "παίξει" το ίδιο κομμάτι για να το κάνει σωστά (μην ξεχνάμε το refactoring).
Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!
|
|
-
|
20-10-2011, 23:18
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Refactoring?? Αν ήξερες πόσο συχνά πατάω Ctrl+M (extract method), Ctrl+F (extract field), Ctrl+P (introduce parameter) κάθε ώρα ... Όσο πιο έμπειρος είναι κανείς τόσο περισσότερο χρησιμοποιεί refactoring αντί να προσπαθεί να κάνει τον ίδιο κώδικα να δουλέψει. Τόσο περισσότερο θα πειραματιστεί μέχρι να πετύχει αυτό που θέλει, τόσα περισσότερα tests θα γράψει. Άλλο το πως καταλαβαίνεις ότι ένα κομμάτι κώδικα έχει πρόβλημα και άλλο πως εντοπίζεις τον καλό προγραμματιστή. Είναι άλλες παράγραφοι και στο άρθρο. Αν πάρουμε το παράδειγμα του πιάνου, θα λέγαμε ότι ψάχνουμε να βρούμε ποιά είναι καλή σύνθεση, όχι ποιός είναι καλός πιανίστας. Μπορείς να κρίνεις ποιά σύνθεση είναι καλή με αυτόματο τρόπο που δεν απαιτεί ανθρώπινη αξιολόγηση ? Μάλλον όχι.
Παναγιώτης Καναβός, Freelancer Twitter: http://www.twitter.com/pkanavos
|
|
-
|
16-11-2011, 11:32
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Tο empirical 'everything' έχει να κάνει με εμειρία και παρακολούθηση
http://en.wikipedia.org/wiki/Empirical. Στο Project Management το
ονομάζουμε "Best Practices and Historical Information".
Αδυνατώ όμως να κατανοήσω πως μπορεί το: "Εγώ έχω μάθει να
πετάω το A380 από μόνος μου" μπορεί να υποκαταστήσει τις σχολές πιλότων... Η σωστή προσέγγιση είναι γνωστή. Την έχουν ανακαλύψει άλλοι: -Education -Traning -Experience Πέραν τούτου μάλλον ουδέν...
Θεοφάνης Γιώτης (Theofanis Giotis) | BA, MSc, Ph.D. c., CSAP PMI-PMP, PMI-PBA, DASSM, PMI-ACP, CSM, CSP, PSM I, ITIL, CTT+ PMI ATP Trainer, PMI DA ATP Trainer, PRINCE2 Trainer, PRINCE2 Agile Trainer [email protected]Tel: +30 693-22.13.502 CEO at 12PM Consulting, 1988-now President at PMI-GREECE, 2004-2014 Vice President at PMI-GREECE, 2017-2020 President at PMI-GREECE, 2020-2021 Leader at AgileGreece, 2014-now
|
|
-
|
16-11-2011, 12:09
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Η αγγλική γλώσσα, όπως και η ελληνική, δίνει διαφορετικές σημασίες στην ίδια λέξη. Όταν μιλάμε σε επιστημονικό επίπεδο, Empirical σημαίνει Εμπειρική παρατήρηση, ή με άλλα λόγια, παρατηρώ και καταγράφω τί σημαίνει. Δεν διαφέρει και τόσο από τις δύο έννοιες που έχει η ίδια λέξη και στα Ελληνικά. Όταν διαβάζουμε μία δημοσίευση στο IEEE Transactions on Software ή στο ACM, Empirical σημαίνει παρατήρηση, σε αντίθεση με το Theoretical. Οπότε μάλλον θα έπρεπε να λέμε "Παρατηρώ, ελέγχω και μετράω κάθε αισθητήρα του Α380 για να δω αν είναι μέσα στις φυσιολογικές παραμέτρους" αντί να λέμε "Δεν τραντάζει άρα καλά πάει". Εξάλλου, το άρθρο δεν έχει να κάνει με γλωσσολογία. Τα περιεχόμενα και το συμπέρασμα του άρθρου έχουν σημασία: Τα στοιχεία αποδεικνύουν ότι πολλές από τις παραδοχές που κάναμε ως τώρα για το software development και το Project management δεν ανταποκρίνονται στην πραγματικότητα. Όταν συζητάμε για το πως θα βελτιωθούν οι πρακτικές του επαγγέλματος μας δεν μπορούμε να αγνοήσουμε τα στοιχεία. Μπορεί να μας ενοχλούν, ή να είναι αντίθετα με τις πεποιθήσεις μας αλλά δεν μπορούμε να τα κρύψουμε κάτω από το χαλί. Προσωπικά με απογοητεύει ότι δεν μπορεί να υπάρξει κάποιο αξιόπιστο accreditation πέρα από το "πιστοποιούμε ότι αυτός ο προγραμματιστής δεν είναι επικίνδυνος για την κοινωνία". Πραγματικά θα ήθελα να υπήρχε ένας τρόπος να ξεχωρίσουν οι αξιόπιστοι προγραμματιστές από τις "βουβουζέλες". Αν όχι τίποτε άλλο, θα έκανε τις προσλήψεις πολύ ευκολότερες.
Με ενοχλεί επίσης ότι δεν υπάρχει κάποιο code metric για να βρω εύκολα τα προβλήματα στον κώδικα μου. Θα ήταν ανόητο όμως να επιμείνω στις παλιές προσπάθεις όταν τα στοιχεία μου λένε το αντίθετο.
Παναγιώτης Καναβός, Freelancer Twitter: http://www.twitter.com/pkanavos
|
|
-
|
16-11-2011, 12:23
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Μερικά σχόλια: - "φυσιολογικές
παραμέτρους" σημαίνει Best Practices ή χρήση της κανονικής κατανομής για να βρείς τι γίνεται (πχ. η Ιατρική το κάνει αυτό) - "προγραμματιστής δεν είναι επικίνδυνος για την κοινωνία" Μόνο η εταιρεία στην οποία εργάζεται ή οι πελάτες του μπορούν να το κρίνουν. Επίσης το μοντέλλο DIKW (Data, Information, Knowledge, Wisdom) βοηθά πάρα πολύ στην επεξεργασία των πληροφοριών.
Θεοφάνης Γιώτης (Theofanis Giotis) | BA, MSc, Ph.D. c., CSAP PMI-PMP, PMI-PBA, DASSM, PMI-ACP, CSM, CSP, PSM I, ITIL, CTT+ PMI ATP Trainer, PMI DA ATP Trainer, PRINCE2 Trainer, PRINCE2 Agile Trainer [email protected]Tel: +30 693-22.13.502 CEO at 12PM Consulting, 1988-now President at PMI-GREECE, 2004-2014 Vice President at PMI-GREECE, 2017-2020 President at PMI-GREECE, 2020-2021 Leader at AgileGreece, 2014-now
|
|
-
|
16-11-2011, 12:56
|
-
dimos.homatas
-
-
-
Μέλος από τις 13-12-2010
-
Θεσσαλονίκη
-
Δημοσιεύσεις 319
-
-
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Παναγιώτης Καναβός: Πραγματικά θα ήθελα να υπήρχε ένας τρόπος να ξεχωρίσουν οι αξιόπιστοι προγραμματιστές από τις "βουβουζέλες".
Προσωπικά έχοντας κυριολεκτικά άμεση εμπειρία με βουβουζέλα code (νοτιοαφρικάνικη εταιρία βλέπετε!) μπορώ να πω με ασφάλεια ότι βλέπω προσπάθεις project management με διάφορες μεθοδολογίες να μην μπορούν να στεριώσουν, αλλά ενώ όλοι κοιτάνε το process, κανείς δεν κοιτάει τον υπάρχοντα κώδικα που θέλουν πχ να επεκτείνουν!
Όταν έχεις όλα τα είδη του Pasta Code δεν σε σώζει κανένα PM... εάν δεν υπάρχουν coding standards, conventions & principles, όλα τα άλλα είναι μπαλώματα.
"When the darkness rises up from inside - that is normal. It's when you reach down to pull it up - that the noxious warnings sound." Tuzak, Farscape
|
|
-
|
16-11-2011, 13:17
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Εγω ο εγκάθετος θα τράβηξω την κουρτίνα ή το πέπλο που δεν σαν αφήνει να δείτε αλλιώς τα πράγματα.
Αγαπητοί μου συνάδελφοι μια ερώτηση έχω μόνο και θα ήθελα να απαντήσετε στον εαυτό σας πρώτα, και μετα σε μένα.
Ο κώδικας βουβουζελα ή πάστα ή όπως θέλετε να το λέτε γίνεται γιατι φταίει ο PM ή ο developer που τον έγραψε;
Και πραγματικά δεν θέλω να διαβάσω απαντήσεις ότι δεν μας δίνουν το χρόνο που χρειάζεται για να γραφτεί σωστός κώδικας γιατί όσος και να δωθει πάλι ο ίδιος κώδικας θα γραφτεί.
Με εκτίμηση Ένας προγραμματιστής τα τελευταία 25 χρόνια
Antonios Chatzipavlis
|
|
-
|
16-11-2011, 13:23
|
|
|
Απ: Empirical Software Engineering Ή Πως οι "αλήθειες" του Project Management αποδεικνύονται μύθοι
Παναγιώτη μου αυτά τα έχουν λύσει άλλοι για εμάς. Όταν κοιτάς τον προβληματικό κώδικα, ΕΙΝΑΙ ΠΟΛΥ ΑΡΓΑ... Είναι σαν να κοιτάς καμμένη μηχανή αυτοκινήτου επειδή δεν είχε λάδια και να θες να την βελτιώσεις. Αυτή η προσέγγιση λέγεται Reactive και είναι postmortem. Η σωστή προσέγγιση είναι η reactive και πες την να όπως θες. Εγώ την Project Management, Quality planning, quality metrics, quality assurance κλπ.
Θεοφάνης Γιώτης (Theofanis Giotis) | BA, MSc, Ph.D. c., CSAP PMI-PMP, PMI-PBA, DASSM, PMI-ACP, CSM, CSP, PSM I, ITIL, CTT+ PMI ATP Trainer, PMI DA ATP Trainer, PRINCE2 Trainer, PRINCE2 Agile Trainer [email protected]Tel: +30 693-22.13.502 CEO at 12PM Consulting, 1988-now President at PMI-GREECE, 2004-2014 Vice President at PMI-GREECE, 2017-2020 President at PMI-GREECE, 2020-2021 Leader at AgileGreece, 2014-now
|
|
Σελίδα 1 από 2 (18 εγγραφές)
1
|
|
|