ต่อไปนี้คือ บทสนทนาใน Facebook Status (สีน้ำเงิน คือ คำแปล)
DO NOT measure your team or individual’s performance with the number of story points they finish. The only thing you’ll get is a bunch of bad quality code and defects waiting to happen. Ask yourself again what’s the goal of software development.
อย่าวัดความสามารถในการทำงานของทีมหรือคนในทีมด้วยปริมาณ story points ที่เค้าทำเสร็จ สิ่งเดียวที่คุณจะได้ก็คือ code คุณภาพแย่จำนวนมาก และ bug ที่พร้อมจะเกิดขึ้นได้ทุกเมื่อ ขอให้ถามตัวเองอีกครั้ง ว่าเราพัฒนา software กันไปเพื่ออะไร
Korn4D: Money, of course!
Korn4D: อัดอั้นเหรอ? นิมนต์ไประบายที่ agile66 หน่อยสิ
sinapam: พูดอยู่คนเดียว เหงาอ่ะดิ๊…
Korn4D: ก็ไม่รู้หนีหายไปไหนกันหมด
NT: 55555
NT: ขอแจมด้วยอัดอั้น
athiwat: Yes, we develop software for free coffee !!!
kluak110: ช่วยไปขอคืนพื้นที่ Agile66 จาก Korn4D ด้วย ไม่งั้นจะเปลี่ยนชื่อเป็น Korn66
tikkychai: Why not? It’s the only number available for performance evaluation.
The goal of software development is … “to deliver YOUR commitment at the quality that meets MY expectation”
ทำไมจะไม่ทำอย่างนั้นล่ะ? มันเป็นเลขตัวเดียวที่เรามี ที่เอามาทำการประเมินผลการทำงานได้นะ
เป้าหมายของการพัฒนา software คือ … “ส่งมอบผลงานตามที่ คุณ ได้ทำข้อตกลงไว้ ด้วยคุณภาพที่ ผม คาดหวังไว้”
sinapam: and why would you want to measure people with number la ja? how does that tell you he/she is a good software developer?
แล้วทำไมน้องถึงอยากจะวัดคนด้วยตัวเลขล่ะจ๊ะ มันจะบอกให้เรารู้ได้ว่าเค้าเป็น developer ที่ดีอย่างนั้นเหรอ
tikkychai: well, if he is a good software developer, he should complete more number of tasks, burn up more points, finish more difficult tasks, and, again, meet MY expectation.
without those numbers, how am I supposed to evaluate performance of each developer?
ก็ถ้าเค้าเป็น developer ที่ดี เค้าควรจะทำ tasks ได้เสร็จมากกว่า ทำ points ได้เยอะกว่า ทำ tasks ที่ยากๆได้มากกว่า และ ก็อีกนั่นแหละ ทำให้ได้ตามที่ ผม คาดหวังไว้
kluak110: You all, direct or sarcasm, should write a blog in agile66 
พวกคุณทั้งหลาย ไม่ว่าจะพูดตรงๆ หรือ ประชดประชัน ควรไปเขียนใน agile66 นะ
sinapam: how about i burn up more points by hacking in code.. i can finish it faster than other people but i hide so many defects that can be found later as well and i create code that is so difficult to maintain by that too.
you can play games with number that’s the point.
i only measure my developers by the quality of code, readability, maintainability. you look at it and you can tell. i manage my projects by knowing what my team produces, actually looking at the code and be a developer. you can just tell. no numbers needed.
velocity is only used for planning purposes and showing how much you’ve done in a release, not for measuring if people are good or bad developers.
ถ้างั้น ถ้าพี่ทำ points ได้เยอะกว่าด้วยการ hack code เข้าไปล่ะ (ไม่ได้สนใจว่าจะ design ดีรึเปล่า) พี่ก็สามารถทำเสร็จได้เร็วกว่าคนอื่น แต่ก็ซ่อน bug ไว้มากมาย ที่จะมาเจอได้ที่หลังเหมือนกัน และก็ทำ code ที่ยากมากที่จะ maintain ด้วย
point ก็คือ เราสามารถจะโกงกับตัวเลขได้ทุกเมื่อ
พี่วัด developer ในทีมพี่ด้วยคุณภาพของ code ความอ่านง่าย ความง่ายในการ maintain ของ code เท่านั้นแหละ แค่เห็นก็รู้แล้ว เพียงแค่คุณ manage projects โดยรู้ว่าทีมของคุณผลิตผลงานแบบไหนออกมา แค่มองดูที่ code จริงๆ และเป็น developer ไปกับเค้าด้วย ก็บอกถึงผลงานได้ โดยไม่ต้องใช้ตัวเลข
kluak110: Look at the code? Are you nuts? I don’t have that kind of time. I like graph and numbersssss! Wah haa haa …
ดู code งั้นเรอะ! บ้าไปแล้วรึเปล่า? ผมไม่มีเวลาขนาดนั้นหรอกนะ ผมชอบ graph และตัวเลขขขขขข วะ ฮ่ะ ฮ่ะ ฮ่ะ ฮ่า
sinapam: are you guys playing devil’s advocate….. ฮืออออ ใจร้ายยย
[playing devil's advocate = การทำการโต้แย้งเพื่อการโต้แย้ง ไม่ใช่เพราะเป็นฝ่ายตรงข้ามอย่างแท้จริง]
tikkychai: แหม๊… รู้อีก 
sinapam: พี่ก็ว่าน้องเปลี่ยนไป๋ ฮืออ
TS: อุ้ยว่าถูกทั้งคู่แหล่ะคับ เราต้องดูทั้งข้อมูลเชิงคุณภาพและข้อมูลเชิงปริมาณ (y) (ลอกวิเคราะห์หุ้นมา :p) ต่างก็ตรงที่ข้อมูลเชิงปริมาณวัดผลระยะสั้น แต่เชิงคุณภาพวัดผลระยะยาว
sinapam: แต่สิ่งที่สำคัญ เราต้องรู้ว่าเรากำลังวัดอะไรอยู่น่ะค่ะ ถ้า focus ผิดที่ มัวแต่จมอยู่ในวังวนของตัวเลข ผลที่ได้คงจะมีแต่ผลเสีย มากกว่าผลดีนะ
งานเดิน คนไม่พัฒนา จะมีประโยชน์อันใดกับองค์กร
Korn4D: ผมว่าที่ @Tikkychai พูดน่ะมีเหตุผลมากนะ ก็มันเป็นตัวเลขถ้าไม่เอามาใช้แล้วจะใช้อะไร ใช้ความรู้สึกเหรอ นั่นน่ะมัน bias สุดๆ เลย ถ้ายังไงลองไประบายกันใน blog จะดีกว่านะจะได้กว้างๆ กัน แถมคุยกันในนี้มันหายไปเร็ว อยู่ใน blog นี่คงทนถาวรตลอดกาล
sinapam:
เล่นง่ายนะ คุณน้อง
แฮ่ เขิน
มีคนหลงมาโพสก็ดีแล้วน่า
Totally agree. I didn’t sign up for spending 70% of my time tracking how many points each of my developers burn and how many bugs/rework they generate. (I would have signed up for TPM if I loved tracking that much) Actually, I don’t really know what I signed up for for maybe i’m in a wrong role!
Anyway, apparently, this approach of “counting numbers” is supposed to encourage people to work harder, or more “efficiently” in their preferred term. It also serves as a tangible evidence for an ambitious software developer to show the lead/manager that they can perform on par with the senior engineer, thus, deserve a promotion. Without these tangible, measurable criteria, how else they’re gonna prove that they are as good as others? Depend on Lead’s judgement? Lead is so bias!
Personally, with my gut feeling, I don’t like this approach but I have no idea either on how else we can define a SMART criteria so that we can tell who’s “better” or “more efficient” than others.
if your lead doesn’t have the maturity to make an un-bias judgement, your organization obviously has something wrong for putting the person to be a lead.
having said that, i know how difficult it is for you guys
even if your organization is that way, i hope you think differently. if upper management wants to play games, play with them, don’t play with your team members.
Totally agree! if the lead is not matured enough to make unbiased judgement, then we might as well replace the lead (just fix the root cause rather than finding the workaround). Then again, who is it to judge whether lead is make a biased judgement or not? mm….