Agile for Software Development
ภาคแชร์ประสบการณ์
วันที่ 12 -14 พค. 2560 ผมมีโอกาสร่วมเป็น Co-Agile Coach
กับเพื่อนพ้องน้องพี่ สยามชำนาญกิจ (มากันทั้งบริษัทเลย)
เห็นได้ชัดว่ามีความตั้งใจและจริงใจ ที่จะร่วมให้ความรู้และส่งเสริม Agile development process ให้กับภาคการศึกษาในไทย
โดยกิจกรรมนี้ถูกจัดมาหลาย มหาฯลัย แล้ว
ตั้งแต่ มข. มอ. บางมด แม่ฟ้าหลวง พระนครเหนือ และรอบถัดไป ก็จะเป็น ม.ธรรมศาสตร์
รอบนี้มากันที่ พระจอมเกล้าฯ พระนครเหนือ
ผู้เรียนประกอบด้วย
อาจารย์ นักศึกษา ป.ตรี ป.โท(เยอะสุด) และ ป.เอก ประมาณ 40 ท่าน
นอกจากเรามาชวนทำ Agile แล้ว
ผมยังชอบประโยคย์นึง จากทีมที่บอกว่า
“เราไม่ได้แค่มาสอน Agile Process แต่เรามาร่วมส่งมอบประสบการณ์” (ตีความเอาเอง คือ เราทำวอดวาย กันมาเยอะ )
ดังนั้นมาดูกันว่าทำอะไรแล้ววอดวาย ส่วนอะไรที่ทำแล้วดี ก็ให้รู้กันจาก
Share ประสบการณ์ Workshop 3 วันนี้กันเลย
เริ่มแรกเลย เรา Coach ทีม
ให้นำ Scrum มาใช้ในรูปแบบของ Large Scale Scrum (LeSS)
แยกเป็น 2 บริษัท คือ บริษัท A และ บริษัท B
แบ่งเป็นทีม ทีมละ 4–6 คน
ดังนั้นแต่ละบริษัท จะประกอบไปด้วย
บริษัท A 3 ทีม
บริษัท B 3 ทีม
เริ่มแรก ให้ทีมลอง Brainstorm กัน ว่าปัจจุบัน ที่ทำงาน เราแบ่ง SDLC เป็นกี่ Process (กันแน่)
( ทีมนี้เป็น นศ ป.ตรี ล้วน อาจ งงๆ หน่อย เพราะยังไม่เคยประสบภัยในบริษัทมาก่อน แต่ความตั้งใจนี่ เต็มร้อยทุกคน )
หลังจากนั้นให้ทีมลองเอา Process มาจัดลงในกระดาษแผ่นเดียวกันดูซิ
ถ้าเรามองเป็น Team ร่วมกันทำ และส่งมอบในรูปแบบของ Software Product
ทีมจะมีหน้าตา เป็นยังไง
ถัดมา
แต่ละทีม เราแบ่งเป็น
PO และทีมพัฒนา
โดยสิ่งที่ทีม จะต้องเรียนรู้เพิ่มเติม คือ การ Estimation และ Prioritization
โดยใช้ Coin Game เป็นตัวอย่าง
ให้PO เป็นคนจัด Prioritize งาน และทีมพัฒนา ช่วยกัน Estimate แต่ละชิ้นงาน
ตัวอย่างการ Estimate ง่ายๆ
เรายกตัวอย่างการทำอาหาร ก็จะแบ่ง Size ของการทำอาหาร จากง่าย (เช่น ข้าวไข่เจียว) ไปยาก (เช่น ต้มยำกุ้ง) โดยเทียบความยากกับ size เสื้อเล็ก ไป ใหญ่
ทีมกำลังถกกัน อย่างเข้มข้น ว่าอันไหนยากมาก ยากน้อย
เป็นการฝึกให้ ทีมรู้จักการ Estimate
จบ Lecture ด้วยให้ทีม ลองช่วยกันสรุปความรู้ ออกมาในรูปของ Mindmap
มาเริ่ม Part Workshop กันบ้าง
Requirement วันนี้คือ E-Wallet
โดยให้แต่ละทีมในบริษัท ช่วยกันทำ ในรูปแบบของ LeSS (Large Scale Scrum)
ทีม ตกลงกันว่า
- Develop โดยใช้ภาษา PHP
-ใช้ GIT เป็น Repository
-ใช้ PHP Unit ในการทำ TDD , Unit Testing
ทีม Discuss กันว่า ระบบ E-wallet จะต้องประกอบไปด้วย Features อะไรบ้าง โดยใช้ Tool FISH-BONE Diagram
เพื่อให้ทีม Share idea ให้เห็นภาพรวมของปัญหาร่วมกัน
ส่วนหน้าที่ Coach จะชวนถามให้คิดในสิ่งที่ทีมลืมหรือตกหล่นไป
แต่การตัดสินใจ จะยังอยู่ที่ทีมเสมอ ไม่ใช่ Coach ตัดสินใจให้
ไม่เช่นนั้น ก็จะเข้า Loop การทำงานเดิม ที่ทีมไม่เก่งสักที
PO ให้ requirements โดยแต่ละทีมในแต่ละบริษัท
หยิบงาน (Product Backlog Items) เพื่อเข้า Sprint
โดยเริ่มแรก เรา Design ให้ Product นี้ต้องเสร็จภายใน 2 Sprint โดยให้เวลา Sprint ละ 3 ชั่วโมง (โหดป๊ะหล๊ะ)
เริ่มเข้า Sprint
1. Sprint Planning Part I (What , Why)
ชวนให้ทีมคิดว่า เราทำอะไร , ทำมันทำไม เพื่อให้ทีมสร้างความเข้าใจร่วมกัน
โดยช่วยกัน Draw ออกมาในรูปแบบของ A-DAPT Blueprint (ที่ทางสยามชำนาญกิจทีม นำมา Apply)
แยกเป็น 2 Parts ใหญ่ๆ คือ
1. Customer Visible (ส่วนที่ลูกค้ามองเห็น จับต้องได้)
เช่น Acceptance Test , UI
2. Customer in-Visible (ส่วนที่ลูกค้ามองไม่เห็น ซึ่งก็คือ Technical part นั่นเอง)
เช่น Business logic , Database , Support
ทีมจะพูดคุยกับทีม ในรูปแบบของ Customer visible โดย ใช้หลักการ A-TDD หรือ Acceptance Test Driven Development หลักการคือ
ใช้ คิด Test นำการ Development
ข้อดีคือ เราได้ Cross-check กับ PO ว่า นี่คือ Acceptance ที่เขาต้องการจริงๆ และเข้าใจใน Schenario ตรงกัน
2.Sprint Planning Part II : (How ทำอย่างไร)
ทีมจะลง Detail Design ทั้ง UI , Biz Logic , DB Design , Support เพื่อ นำ Detail เหล่านี้ เข้าใน Sprint (ซึ่งเราจะได้ Sprint Backlog Item ในขั้นตอนนี้เลย )
สอน Coding Dojo ด้วย TDD : Test Driven Development
ปกติ Programmer เมื่อได้ requirement แล้ว
เขาก็จะเริ่มคิดถึง Programming Solution ในหัวเลย ว่าจะมี IF ELSE กี่ตัว
แต่มันจะยาก ถ้ามีการเปลี่ยนแปลง Requirement ในภายหลัง
เพราะเราจะไม่รู้เลยว่า มันกระทบ logic เดิมอย่างไร
ดังนั้น หลักการ TDD จะมาช่วยทำ Automate Unit Test เพื่อ Regression อีกที
หลักการง่ายๆ (แต่ทำยาก) คือ Fail -> Pass -> Refecter
เป็นวงรอบ
เราฝึกฝนโดยใช้ game “FIZZ,BUZZ”
ให้ทีม Pair programming เขียนโปรแกรม Check input
ถ้า หาร 3 ลงตัว ให้ Print คำว่า “FIZZ”
ถ้า หาร 5 ลงตัว ให้ Print คำว่า “BUZZ”
ถ้า หาร 3 หรือ 5 ลงตัว ให้ Print คำว่า “FIZZBUZZ”
นอกนั้น ให้ Print ตาม input
โดยวิธีการ Pair programming แล้ว Test ตาม TDD Cycle คือ รัน Test
ถ้า Fail ->ก็แก้ให้ Pass ->แล้ว Refactor code ตามลำดับ
ต่อไปถ้ามีการเปลี่ยนแปลง ก็ automate run Unit test เหล่านี้ซะ
จะได้ไม่เสียเวลา manual test กันเอง (ยอมเหนื่อยตอนแรก )
หลังจาก ดำเนินพิธีกรรมใน Sprint ที่เหลือ
3. Daily Scrum
4. Product Backlog Refinement
5. Sprint Review
6. Sprint Retrospective
สรุปผลลัพธ์ คือ ส่งมอบ Backlog ได้ไม่ครบ ตาม Definition of Done (DoD) !!!!
พอทีมเริ่มเยอะ ความวุ่นวาย ก็จะมาพร้อมเสมอ
ทีมจะตั้งหน้าตั้งตาทำงานตามโจทย์ เพื่อเอาชนะกัน
ดังนั้น ทีมจะถูก Break จาก Coach เพื่อ Re-Cap ถึง วัตถุประสงค์ของการเรียนรู้ พร้อมทั้งให้เรียนรู้จากความล้มเหลว ไม่ใช่ให้เอาชนะกันนะจ๊ะ
จบ Sprint มาดู นักศึกษา Feedback กับทีม Coach กันสักหน่อย
อ่านแล้ว ก็ อดยิ้ม อดขำไม่ได้
สุดท้าย ท้ายสุด
ขอขอบคุณเพื่อนพ้องน้องพี่แก๊งเกรียน แห่งสยามชำนาญกิจ
ที่มาร่วม Share ประสบการณ์ จากการไปประสบภัยจากการทำ Agile ณ ที่ต่างๆ
และให้โอกาสเข้าร่วม Coach ในครั้งนี้
ผิดพลาดหรือตกหล่นส่วนไหน Comment กันได้เสมอนะครับ (มียาดม ติดตัว)
หวังว่าโอกาสถัดไป เราจะได้ร่วมแบ่งปันกันแบบนี้เสมอๆครับ
