สิ่งที่ทำให้ Agile มีเอกลักษณ์ เป็นของตัวเอง น่าจะมีหลายอย่าง แต่วันนี้ขอเริ่มกันแบบเบสิค ถ้าจะนำ Agile มาใช้ ต้องรู้จักกับสิ่ง เหล่านี้ เอาล่ะ มาเริ่มกันเลย…
ทำแต่สิ่งที่มีคุณค่าเท่านั้น (Completely Value Driven)
อันนี้ก็คงไม่ต้องอธิบายว่า ทำไมถึงดี แต่ที่ Agile ย้ำ คือ ให้ทำแต่สิ่งที่มีคุณค่าเท่านั้น และตลอดเวลาด้วย อันนี้ต้องไปอ่าน The Great Pyramid of Agile ประกอบ (reuse code ไม่ต้องเขียนเองด้วย ขุก ขุก ขุก) นั่นก็คือ เราต้องทำให้ software ของเราเป็นปิระมิดที่สมบูรณ์อยู่ตลอดเวลา จากปิระมิดเล็กๆ แล้วค่อยต่อเติมเป็นปิระมิดที่ใหญ่ขึ้น ใหญ่ขึ้น เพราะปิระมิดที่ไม่สมบูรณ์ ไม่ได้เป็นประโยชน์กับใคร
Iteration ที่มีระยะเวลาตายตัว (Time Boxed Iterations)
iteration ใน Agile จะต้องมีเวลาตายตัว ห้ามโดยเด็ดขาด ที่จะบอกว่า โอ๊ะ งานที่บอกว่าจะทำใน iteration นี้ไม่เสร็จ งั้นเราก็เลื่อนเวลาปิด iteration ออกไปละกัน เมื่อทำเช่นนั้น ข้อดีของการทำ iteration จะหายไปทันที
ตะกี๊ ไปนั่ง search หาคำแปลให้ Time Boxed Iterations ก็เจอว่า มีหลายคนเลย ที่เขียนว่าเทคนิค Time boxing เนี่ย เป็นวิธีที่มีประสิทธิภาพมากในการทำงานให้เสร็จ เพราะเราได้มีการกำหนดเป้าหมายระยะสั้น เพื่อให้ทุกคนวิ่งไปให้ถึง (iteration จึงถูกเรียกว่า sprint เหมือนการวิ่งเร็วในบางตำรา) และหลังจากถึงเป้าหมายแล้วยังได้มีการ หยุด เพื่อดูว่าทำอะไรเสร็จแล้วบ้าง มองย้อนกลับไปเพื่อแก้ไขในสิ่งที่ผิดพลาด เพื่อพัฒนาต่อไปใน iteration หน้า และถ้ามีการเปลี่ยนแปลงทิศทาง ก็สามารถตอบสนองได้ทันท่วงทีใน iteration ถัดไปเช่นเดียวกัน
นอกจากนี้ การตั้งเป้าหมายระยะสั้น ยังป้องกันไม่ให้เกิดการผัดวันประกันพรุ่ง ว่าไปทำทีหลังละกัน เรื่องนี้มันยากหรือไม่น่าสนใจ รวมทั้งป้องกัน ผู้ยึดติดกับความสมบูรณ์แบบ (perfectionist) ไม่ให้นั่ง design เพื่อสิ่งที่ดี่ที่สุด (ซึ่งไม่รู้มีอยู่จริงในโลกนี้รึเปล่า) เป็นระยะเวลานานนาน
การพัฒนาที่ใช้การ test เป็นผู้นำทาง (Test Driven Development)
การเป็น Agile คือ ความคล่องแคล่ว ว่องไว เคลื่อนไหวอย่างรวดเร็ว และนั่นก็นำมาซึ่งการเปลี่ยนแปลงที่เป็นไปอย่างรวดเร็ว ถ้าใครยังนั่งทำ manual test กัน ในขณะที่นำ Agile มาใช้ล่ะก็ มีหวังมือหงิกแน่นอน unit testing จึงเกิดมา เพื่อให้ developer ได้รับผิดชอบ (ย้ำ developer รับผิดชอบ) หน้าที่ของ unit tests ก็คือ ทำให้มั่นใจว่าสิ่งที่ตัวเองเขียนมาจะไม่ผิดพลาด และ ทำให้มั่นใจว่า ไม่ว่าคนอื่นมาแก้ code ยังไง สิ่งที่เคยเป็น ก็จะยังคงอยู่ และสิ่งที่เหมือนตาข่ายรองรับความผิดพลาดนี่เอง ก็จะช่วยให้ทุกคนสบายใจขึ้นกับการเปลี่ยนแปลงที่เกิดขึ้น นอกจาก unit tests แล้วใครอยาก power up ให้มีคนเขียน automated functional tests (ส่วนใหญ่ก็คงจะเป็น tester) ก็ยิ่งดีเข้าไปใหญ่ เหมือนมีตาข่ายสองชั้น
นอกจากนี้ ก็มีสิ่งที่เรียกว่า Continuous Integration แปลง่ายๆ ก็การประกอบร่างอย่างต่อเนื่อง ทั้ง unit tests และ automated functional tests ก็เป็นส่วนสำคัญของสิ่งนี้ เพื่อให้มั่นใจว่าการประกอบร่างจะประสบความสำเร็จ Continuous Integration จะต้อง run ทุกครั้งที่เกิดการเปลี่ยนแปลงใน source code (ที่เป็น trunk นะ เรื่อง version control คงจะขออนุญาตไม่อธิบาย เดี๋ยวยาว) ซึ่งจะประกอบไปด้วยการ update code มาลงใน environment ที่เราจะใช้ test แล้ว run unit tests และ functional tests และอื่นๆซึ่งขึ้นอยู่กับ technology ของแต่ละ project เมื่อจบ ทุกอย่างผ่านสวยงาม developer ก็นอนตีพุงได้ เย้ code ชั้นจะไม่มีปัญหา และไม่ทำให้คนอื่นมีปัญหา แต่ถ้าไม่ผ่านอย่างสวยงาม ก็จะได้แก้ไขได้อย่างรวดเร็ว ก่อนจะลืมไปแล้วว่า code นี่มันเอาไว้ทำไรนะ
วางแผนและประมาณงานด้วย Story Points (Planning & Estimating with Story Points)
สิ่งที่เราได้รับการสั่งสอนมาแต่โบราณคือ จะทำงานอะไรก็บอกเค้าไปสิว่าจะใช้กี่วัน แต่ยิ่งงานซับซ้อนขึ้นเท่าไร จะมีกี่ % กันที่การคาดเดานั้นมันจะถูก
เราหารู้ไม่ว่า คน น่ะไม่เก่งกับการคาดเดาอะไรแบบเป๊ะๆเอาซะเลย เอาตัวอย่างง่ายๆ ซึ่งเป็นการเล่นมุขยิงตัวเอง ถ้าเราได้เจอหน้ากัน แล้วแป๋มถามทุกคนว่า แป๋มสูงเท่าไรคะเป็นเซนติเมตร คุณคิดว่าคุณมี % ถูกอยู่เท่าไร และถ้าถามหลายคน จะมีคำตอบที่แตกต่างกันมากมายแค่ไหน ขอโทษเถอะ รู้จักกันมาหลายปี บางคนยังไม่สามารถเดาได้ถึงหลักหน่วยเลย แต่ถ้าแป๋มยืนเทียบอยู่กับโต๊ะทำงาน แล้วถามว่าแป๋มสูงกว่าโต๊ะทำงานกี่เท่า คนส่วนใหญ่ก็คงบอกว่า สอง (ยกเว้นคนที่มีอคติจริงๆ ชิ)
คนเราน่ะ เก่งในเรื่องการเปรียบเทียบขนาดมากกว่าการบอกแบบเป๊ะๆมากนัก และสิ่งของบางอย่างมันก็ไม่ได้ต้องการความเป๊ะมากนักหรอก เพราะมันไม่มีทางจะเป๊ะได้ เช่นเรื่องของอนาคต อย่างการ estimate การทำงานเป็นต้น นี่เองก็เป็นที่มาของ Story Points
Story Points ใช้ประมาณปริมาณแรงที่ต้องใช้ในการทำงาน ไม่มีหน่วย เพราะเป็นการเปรียบเทียบกันใน user stories ที่มีทั้งหมด ไม่ได้เกี่ยวข้องอะไรทั้งสิ้นกับจำนวนวันที่ใช้ทำ story นั้นๆ อ่าว ทีนี้ก็ต้องมีคนถามละ ว่า แล้วจะรู้ได้ยังไงล่ะ ว่าจะทำเสร็จเมื่อไร จะไปบอกลูกค้ายังไง สิ่งที่จะมาบอกเราได้ว่าเราจะทำงานเสร็จเมื่อไร คือ story points ทั้งหมดของ release นี้ และ velocity ซึ่งก็คือ average ของจำนวน story points ที่เราทำได้ในแต่ละ iteration พูดอย่างนี้อาจจะงง จึงขอนำเสนอด้วยรูปต่อไปนี้
น้องคนนี้คืออะไร ก็คือถัง Release ของเรานั่นเอง ทรายที่อยู่ในถังก็คือ user stories ที่เราต้องทำ ที่ตักที่เราเลือกมาคือระยะเวลาของ iteration แล้ว velocity ก็คือปริมาณทรายที่ตักออกไปได้ในแต่ละครั้งโดยเฉลี่ย แล้วเมื่อไรจะเสร็จล่ะ ก็เมื่อทรายถูกตักออกไปจนหมดไง ปริมาณทรายทั้งหมด หารด้วย ปริมาณทรายที่ตักออกไปได้โดยเฉลี่ย ก็คือ เวลาที่เราจะใช้นั่นเอง จริงๆถังทรายนี้ยังสามารถอธิบายสิ่งที่จะเกิดขึ้นใน project ได้อีกมากมาย แต่เอาไว้แค่นี้ก่อนละกัน
เกมโป๊กเกอร์ (Planning Poker)
อ๊ะ ไม่ได้ชวนเล่นการพนันแต่อย่างใด เกมโป๊กเกอร์คืออะไรนั้น ไปอ่านได้ที่ Planning Poker มาโหวตกัน !! นะคะ (reuse code อีกแล้ว อารามง่วง) แต่ข้อดีของมันคืออะไรล่ะ
- ทำให้ทุกคนในทีมทั้ง dev, test, infra ไม่ว่าจะตัวเล็กตัวจ้อยแค่ไหน ได้มีสิทธิในการออกเสียง ก็คนเหล่านี้นี่แหละที่จะเป็นคนทำงานจริงๆ ใช่คุณ manager หรือ team lead ผู้ยิ่งใหญ่ไม่
- เป็นวิธีที่จะทำให้เกิดการตกลงไปยังตัวเลขเดียวกันได้เร็วที่สุด (แต่บางทีจะมีคนที่ชอบลง details ถึงแม้ว่าเราจะได้ตัวเลขเดียวกันแล้ว อันนี้ถ้าไม่ได้ทำให้ estimate เปลี่ยนแปลง ก็เก็บไว้คุยกันในการประชุมอื่นนะคะ)
- พวก story จ้อยๆ ง่ายๆ เราจะสามารถ estimate กันได้อย่างรวดเร็วมาก แล้วจะได้มีเวลามา focus ในสิ่งที่ยากๆ
- ทำให้คุยกันมากขึ้น เข้าใจกันมากขึ้น (เอ๊ะ คุ้นๆ) ระหว่างทุก role ในทีม
นี่ล่ะค่ะ หมดละ สิ่งเบสิคๆใน Agile เขียนยาวอีกแล้วอ่าา… จริงๆอันนี้เป็นส่วนนึงของ course หลายชั่วโมง ที่เคยไป train เมื่อหลายเดือนที่แล้ว ตอนแรกนึกว่าจะสั้นๆ แต่อยากอธิบายให้เห็นภาพเหมือนเวลาทำ training เลยออกมายาวขนาดนี้ ขอบคุณที่อ่านนะคะ
ป.ล. สัญญาไว้วันพุธ แอบส่งการบ้านช้าด้วยล่า…
อยากเสริมเรื่อง time boxed iteration เนื่องจากที่บริษัทเป็น agile ออกแนว scrum ซึ่งมี time box iteration เป็นองค์ประกอบหนึ่งที่สำคัญที่ทำร่วมกันกับ practice อื่นๆ แต่ก็มี agile แขนงอื่นเหมือนกัน เช่น kanban ที่ไม่ได้ใช้ concept ของ time boxed iteration แต่จะทำเป็น increment boundaries แทน ซึ่งสิ่งที่เกิดขึ้นคือ ทำให้ kanban ไม่มี concept ของการทำพวก release/iteration planning ซึ่งแตกต่างกับ scrum ที่มีการ meeting ค่อนข้าง fix และรู้ได้ล่วงหน้า เป็นไปตาม time boxed iteration และแน่นอน kanban ก็จะอดได้ข้อดีบางข้อของ iteration ไป ตามที่พี่แป๋มบอกไว้ แต่อาจจะมีข้อดีอื่นๆ ต้องลองไปศึกษาเองนะคะ อันนี้เก๋เอามาเผยแพร่แบบทฤษฎีล้วนๆ ไม่เคยลอง kanban ด้วยตัวเองเหมือนกัน
ดังนั้น ก็ขึ้นกับผู้ใช้ จะเลือกใช้สิ่งที่เหมาะสมกับตัวเองแล้วค่ะ สิ่งที่เราชาวโปรเตอุสนำมาบอกเล่า เป็น agile ในแบบที่เราใช้แล้วได้ผลเห็นจริงกับตา จึงนำศาสนามาเผยแพร่ดังที่เห็น 555+ ดังนั้นหากใครไปอ่านอะไรมา แล้วเจอสิ่งที่แตกต่างกันกับที่เขียนไว้แถวนี้ แล้วเกิดอาการงงว่าจะฟังใครดี ให้พึงระลึกไว้เสมอว่า agile มีวิธีการทำเป็นล้านแปดวิธีค่ะ วิธีที่เรามาบอก เป็นเพียงแค่วิธีที่ได้ผลดี(มาก) ก็เท่านั้นเอง คุคุคุ
คำถาม: พี่แป๋มสูงเท่าไหร่
คำตอบ: เนื่องจากไม่ถนัดทายตัวเลข เพราะมัน estimate ได้ไม่แม่นยำ ดังนั้นจึงขอตอบว่า พี่แป๋มเตี้ยค่ะ ก๊ากๆๆ
ขอบคุณสำหรับโพสต์ที่ครอบคลุมไปถึงตับไตไส้พุง และกางเกงที่นุ่ง ค่ะ
อ่อ จริงด้วย เค้าก็ไม่เคยใช้ kanban เลยไม่ได้นึกถึงไปเลย ต้องไปศึกษาเพิ่มเติมซะแล้ว
RE: คำถาม/คำตอบ -”- แฟ่!
Kanban เป็น practice ใน Lean ข้าพเจ้าไม่ได้แก่กล้าแต่ประการใดแต่เท่าที่ศึกษามาคือ Kanban มองการทำงานเป็น flow ไหลจากทีมหนึ่งไปยังอีกทีมหนึ่ง ตัวอย่าง flow อย่างง่ายๆคือ DEV->QA->OPS หลักการคือทำยังไงจะให้ flow ไหลได้ลื่นที่สุด สมมุติว่าแต่ละทีมมี velocity ต่างกัน DEV(15 apples) -> QA(8 papayas) -> OPS (9 oranges) ถ้า QA มีงานอยู่เต็ม 9 มะละกอแล้ว ก็ไม่มีประโยชน์ที่ DEV จะส่งไปเพิ่ม มาช่วย QA ก่อนดีกว่า เรียกเก๋ๆว่าการ Limit Work In Progress ฟังดูคล้ายๆ waterfall แต่ไม่ใช่ ฟังดูเหมือนทำไปเรื่อยๆ ซึ่งก็จริงแต่ต้องออกบ่อยๆ ถ้าคุม flow ใ้ห้ steady ได้ลูกค้าก็จะมีของใช้ตลอด
ผู้เชี่ยวชาญเรื่องนี้น่าจะเป็น Korn4D เพราะทำทิ้งไว้ที่เก่าตั้งแต่ยังไม่มีใครรู้จัก Kanban ตอนนี้คงเชี่ยวแล้ว
ตอบด้วยคำถาม
- อยู่ดึกเข้ามาทำวันเสาร์ ยังถือว่า time boxed iteration ได้หรือไม่?
- ถ้า unit testing เป็นของ developer และดีพอแล้ว จะมี QA ทำไม?
- ถ้า developer ทำ test แล้วยังต้อง มี QA ทำไมไม่ให้ QA เป็นคนทำ test อย่างเดียว, developer จะได้มีเวลาโค้ดเพื่อสร้าง value ได้มากขึ้น
- ถ้า developer อู้ ทำน้อยแต่โหวตมากๆ จะทำอย่างไร?
- ทำทั้งหมดนี้แล้วจะ commit ได้หรือไม่ว่าทั้งหมดเสร็จเืมื่อไหร่?
แอบตอบก่อนเจ้าของ post
- อยู่ดึกเข้ามาทำวันเสาร์ ยังถือว่า time boxed iteration ได้หรือไม่?
– time boxed iteration นับเป็นช่วงเวลาตามที่ตกลงกัน เช่น 2 weeks แปลว่า ตั้งแต่วันที่ 1-14 คือ 1 iteration ในช่วงเวลานั้นไม่ว่าจะมาทำงานเกินตอน weekend หรือ มีวันหยุดเยอะแยะ มันก็ยังคงเป็น iteration วันที่ 1-14 อยู่ดี เพราะมันคือ time box ที่เหลือเราก็ต้องจัดการ story ในช่วงเวลานั้นเองตามสถานการณ์
- ถ้า unit testing เป็นของ developer และดีพอแล้ว จะมี QA ทำไม?
– unit testing ดี ไม่ได้หมายความว่าระบบจะทำงานได้ตาม flow เพราะ unit test คือการ test ว่าตัวฉันถูกต้อง (ไม่ได้หมายความว่ารวมกับคนอื่นแล้วจะถูกตาม requirement) ดังนั้น functional testing ก็ยังคงมีความสำคัญ และต้องทำอยู่ดี และ tester จะเป็นคนเห็นความถูกต้องในด้านภาพรวมอีกด้วย
- ถ้า developer ทำ test แล้วยังต้อง มี QA ทำไมไม่ให้ QA เป็นคนทำ test อย่างเดียว, developer จะได้มีเวลาโค้ดเพื่อสร้าง value ได้มากขึ้น
– การทำ test ของ QA และ developer เป็นของคนละอย่างกัน test ที่ developer ทำเป็นการเขียน code เพื่อป้องกัน functionality พัง เวลามีคนอื่นมาแก้โค้ดเรา แต่ tester มองในมุมมองของประโยชน์และสิ่งที่ลูกค้าต้องการด้วย
- ถ้า developer อู้ ทำน้อยแต่โหวตมากๆ จะทำอย่างไร?
– การโหวตไม่ได้มาจากคนแค่ 1 คน ดังนั้น point ที่ออกมาเป็นสิ่งที่ตกลงกันแล้ว เค้าจะอู้ไม่ได้หากคนอื่นไม่เห็นด้วยที่จะให้ใช้เวลาทำนาน
- ทำทั้งหมดนี้แล้วจะ commit ได้หรือไม่ว่าทั้งหมดเสร็จเืมื่อไหร่?
– สิ่งสุดท้ายที่จะเห็นจากการ iteration คือ velocity ที่เราทำออกไปได้ ที่เป็นตัวแสดงว่าเราทำงาน แต่แน่นอน ก่อนจะเริ่ม iteration/release เราก็ได้ commit ไว้ว่าจะทำได้ถึงแค่ไหน ก็มาจาก story point ที่ได้ร่วม estimate และสร้างมันขึ้นมาร่วมกับลูกค้า คราวนี้สิ่งที่เรา commit ว่าจะส่ง จะแม่นแค่ไหน ก็อยู่ที่เราตี requirement และเอาออกมา estimate ได้แม่นแค่ไหน และสมมติว่าเราทำจนจบ release/iteration เราทำไม่ได้ตามที่เคยคุยไว้ ก็ไม่ได้หมายความว่าเราขี้เกียจ หาก velocity ที่ออกมามัน make sense และเราก็เอา “งานงอก” ที่เกิด ไปแสดงให้ลูกค้าดูได้ เหตุการณ์นี้เกิดเมื่อเรา underestimate ในสิ่งที่เราทำ โอเคแม้ลูกค้าจะผิดหวังกับการที่เค้าไม่ได้ในสิ่งที่ต้องการ แต่ด้วยความที่ลูกค้ามาร่วมทุกข์ร่วมสุขกับเราโดยตลอด เค้าจะมองเห็นปัญหาที่เราเจอเช่นกัน และเค้าก็จะรับกับสิ่งนั้นได้ ดังนั้นปัญหาความไม่พอใจของลูกค้า หากจะเกิด คงเกิดเพราะเค้าไม่ได้เข้ามา involve กับเรามากเท่าที่ควรเป็น หากลูกค้ามองเห็นเหตุการณ์ตลอด เค้าจะยอมรับได้กับ progress นั้น ซึ่งกำลังจะบอกว่า commit ได้หรือไม่ มันอยู่ที่ว่า เราทำให้ลูกค้าพอใจได้หรือไม่ แม้เราทำงานไม่เสร็จตามที่ตกลง หรือ underestimate แต่ลูกค้า happy ก็ถือว่า เราประสบความสำเร็จค่ะ
ขอบใจมาก A2 (คล้ายๆกล้วยหอม B1&B2)
ก็ตามที่เก๋ได้ตอบไปแล้วส่วนหนึ่ง แล้วเขียนตอบไปเขียนตอบมา มันยาว เลยขอย้ายไปที่ 2 post นี้นะคะ
http://www.agile66.com/blogs/2010/08/12/t-nv/
http://www.agile66.com/blogs/2010/08/12/qa-never-jobless/
ขอบคุณครับ ทำให้มือใหม่(อย่างผม)เห็นภาพของ Agile ได้ชัดขึ้น