Agile Sixty-Six Rotating Header Image

Agile Pitfalls

Pitfalls in using Agile

Use Case VS User Story

วันนึง ณ skype land ในเมือง No Boss Allowed

ถ้าเริ่มอ่านแล้ว อ่านให้จบนะคะ เพราะสรุปอยู่ที่ตอนท้าย
(Warning: มันยาวมว้าาาาก และมีความไร้สาระปนกับสาระเป็นระยะๆ)

[8/24/2011 13:12:26] N: อ่านอะไรกัน
[8/24/2011 13:19:30] J: วิธีหา usecase แบบ Agile
[8/24/2011 13:23:35] N: เมื่อคืนไปอ่านมาแล้วว่า usecase กับ user story ต่างกันยังงัย 8-)
(more…)

Measurable(?) Goal

อันนี้ก็เป็นอีกหนึ่งบทสนทนาที่แตกออกมาจาก Playing the Devil’s Advocate และ Devil’s Advocate Child Process ซึ่งเนื้อหาหลักๆที่ถกเถียงกัน ก็น่าจะเป็นเรื่อง เป้าหมายที่วัดได้? หรือ วัดไม่ได้?

จากผู้เขียน: ต้องขออภัยผู้อ่านไว้ล่วงหน้าสำหรับภาษาที่ใช้นะคะ อาจจะดูเหมือนทะเลาะอะไรกันรึเปล่า จริงๆเป็นเพียงบทสนทนาของเพื่อนที่คบกันมายาวนานเกินสิบปี เลยออกมาแนวตรงไปตรงมาอย่างนี้ :) จริงๆต้องขอบคุณเพื่อน ที่ช่วยให้ได้ใช้สมองในการขุดค้นหาคำตอบ

และต้องขออภัยในความยาวของบทความนี้ด้วยนะคะ หมักหมมไว้นานเกิน (> /|\ <  ) ถ้าผู้อ่านมีความเห็นอะไรเพิ่มเติมหรือคำถามที่มากกว่าที่มีอยู่ในนี้ ก็เชิญที่ comment ได้เลยค่าา

djshiow: ถาม/เถียงต่อ

เรื่องไล่คนออก ที่โดนพลิกสถานการณ์ให้ไล่หัวหน้าออก (ไม่ได้! ) จริงๆแล้วมีสองประเด็นปนๆกันอยู่
หนึ่งคือ ที่บอกว่าวัดทุกอย่างเป็นทีม แล้วถึงตอนต้องไล่คนออกทำไงอะ
สองคือ โคด สวยมันสำคัญขนาดไหน ถ้าต้องเทียบกับความเร็วในการโค๊ด ซึ่งจริงๆแล้วก็เข้า
ใจว่าต้องดูกันไปตามสถานการณ์

ประเด็น process improvement
@athiwat : Retro ก็ดีนะ แต่คนในทีมคุยกันมันจะช่วยชี้จุดที่เป็นปัญหาได้เสมอเหรอ
คือเปรียบเทียบเหมือนเขียนโปรแกรมขึ้นมาอันนึงแล้วมันช้าๆเงี้ย ขั้นตอนแรกที่ควรจะทำก็คือ การวัดเวลา
การทำงานของแต่ละขั้นตอนปะ แล้วมาดูว่ามันช้าตรงไหนจะได้ไปแก้ตรงนั้นให้เร็วๆ สรุปประเด็นคือ
ถ้าใช้ความรู้สึกคนในทีมอย่างเดียวอาจจะไม่ได้แก้ปัญหาให้ตรงสาเหตุใหญ่/ อาจจะแก้อะไรที่คนไม่พอใจกันเยอะๆ
แต่ไม่ใช่ปัญหาใหญ่ๆปะ

@sinapam: เพราะฉะนั้นก็ต้อง measure อะไรที่มันเกิดประโยชน์ดิ ไม่ใช่ไม่ measure อะไรเลยปะ

สรุปว่าจริงๆความเห็นส่วนตัวคือเห็นด้วยกับประเด็นแรกนะ ว่าไม่ควรจะวัดจาก number of story อย่างเดียว
แต่การไม่วัดอะไรเลย หรือวัดจาก reaction ลูกค้า ซึ่ง a) subjective b) indirect มันจะดีกว่าจริงๆอะเหรอ

ถ้าไม่รู้ว่าตอนนี้ตัวเองอยู่ที่ไหน แล้วจะไปถึงเป้าหมายได้ยังไง , ถ้า GPS ไม่สามารถหา current location ก็ทำงานไม่ได้ หรือ ทำงานได้ยาก ฉันใดฉันนั้น ฮ่า

(more…)

Devil’s Advocate Child Process

[น้องไม่ได้ขี้เกียจนะคะ น้องเห็นว่ามันน่าจะมีประโยชน์ :D ]

djshiow: อืม ตกลงคือ ไม่วัดอะไรออกมาเป็นตัวเลขเลยอะเหรอ ,
- บอกว่าดูกันที่ “คุณภาพของ code” มันไม่ subjective ไปหน่อยเหรอ
- แล้วถ้าเราใช้เวลาชาติเศษ ผลิต code ที่โคตรสวยเลยอะ มีค่าเท่ากับ คนที่ใช้เวลา แปปเดียว โคตรทำงานได้ ไม่สวยมากปะ

djshiow: ‎(สงสัยจิง ไม่ใช่สาวกปีศาจ)
(more…)

Playing the Devil’s Advocate

ต่อไปนี้คือ บทสนทนาใน 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 กันไปเพื่ออะไร
(more…)

กับดัก Agile ที่ level 3

ใช่ครับ ผมข้าม level 2 มา แหะๆ ^ ^” สารภาพว่ากับดักที่ level 2 เขียนยากมาก และยากขึ้นเรื่อยๆตามเวลาที่ผ่านไปด้วย วิธีการเขียน blog ของกับดักแต่ละ level ผมอ้างอิงจากการทดลองกับตัวเอง ณ level แรกๆ ผมเขียน code ก่อน test (ไม่ได้ทำตามกฎเหล็ก 3 ข้อของ TDD) แต่ยังคงเขียน test ควบคู่ไปด้วยตรงจุดสัญชาติญาณบอกให้เขียน ซึ่งการทดลองนี้ก็ทำให้ผมเห็นอะไรแปลกๆใหม่ๆขึ้นมาเรื่อยๆ จุดไหนที่น่าสนใจผมก็เอามาแบ่งปันให้เพื่อนๆพี่ๆน้องๆฟัง ปัญหาคือ สิ่งที่ผมรู้สึกตอน level 2 มันผ่านมานานแล้ว และผมก็เริ่มลืมความรู้สึกนั้นไปแล้ว Y-Y”

ที่ level 3 เหมาะสำหรับคนที่ทำ TDD แบบตามกฎเป๊ะๆ กฎของ TDD มี 3 ข้อดังนี้ครับ

  1. You are not allowed to write a line of production code until you have written a failing unit test.
  2. You are not allowed to write more of a unit test than it is sufficient to fail.
  3. You are not allowed to write more production code than it sufficient to pass the failing test.

อ้างอิง: RailsConf 09: Robert Martin, “What Killed Smalltalk Could Kill Ruby, Too” แถวๆนาทีที่ 28:30 – 30:30 (more…)

Plugin from the creators of Brindes :: More at Plulz Wordpress Plugins