แชร์ประสบการณ์และความรู้จากจากงาน Agile for Software Development for Academy
จากบทความที่แล้ว ผมได้มีโอกาสศึกษา The Scrum Guide ก็ได้ทำความเข้าใจมาระดับหนึ่ง แต่ยังมองภาพในเชิงปฏิบัติไม่ออก เมื่อไปปฏิบัติจริงๆก็ไม่รู้ว่าแบบไหนคือวิธีที่ถูกกันแน่ ก็เลยลองหา Workshop เพื่อหาประสบการณ์ดู ก็ได้มาพบกับงาน “Agile for Software Development for Academy” จัดวันที่ 12–14 พฤษภาคม 2560 ณ มหาวิทยาลัยเทคโนโลยีพระจอมเกล้าพระนครเหนือ โดย Keynote Speaker ก็คือคุณประธาน ด่านสกุลเจริญกิจ และทีมงานอีกมากมายหลายชีวิต
วันแรก
ช่วงเช้าจะเป็นการทำความเข้าใจในเรื่องของ Software Development Life Cycle เพื่อปูทางไปสู่ Agile ว่าแตกต่างจาก Flow ที่เราทำกันแบบปกติอย่างไร โดยการดำเนินกิจกรรมทุกกิจกรรม จะทำเป็นทีม และจะมี Post-it กับปากกาเพื่อใช้ในการเขียนหรือวาดสิ่งที่อยู่ในหัวออกมา
เทคนิคอย่างนึงที่ผมเพิ่งค้นพบจากกิจกรรมนี้ คือการทำ Silent Brainstorming หรือการระดมความคิดแบบไม่ใช้เสียง โดยเมื่อเกิดความคิดที่ไม่ตรงกัน แต่ละคนก็ต้องเขียนความคิดของตัวเองลงกระดาษโดยไม่ต้องปรึกษาใคร จากนั้นก็ให้แต่ละคนพรีเซนท์ไอเดียของตัวเอง ซึ่งประโยชน์ก็คือ คนที่มักจะไม่ค่อยกล้าพูดก็จะมีสิทธิออกไอเดียหรือความคิดของตนเองด้วย
กิจกรรมนี้จะทำให้เราได้เห็นในเรื่องของ Iterative and Incremental คือเราจะแบ่งการทำงานเป็นรอบเพื่อทยอยส่งมอบงานให้ลูกค้าแทนการส่งมอบตอนจบ SDLC เพื่อให้ลุกค้าเห็นของได้เร็วขึ้น เกิด Changes เร็วขึ้น และเราสามารถแก้ Changes นั้นได้เร็วขึ้น (ลองคิดดูว่า ถ้าเราส่งมอบให้ลูกค้าทั้งหมดในครั้งเดียวตอนจบ หากลูกค้ามีสิ่งที่อยากได้เพิ่ม หรืออยากปรับเปลี่ยนล่ะ แล้วคิดว่าจะเกิดอะไรขึ้นหากเกิดสิ่งเหล่านั้น ?)
กิจกรรมถัดมา คือ Coin Game หรือเกมส์โยนเหรียญ โดยจุดประสงค์ของกิจกรรมนี้ คือการให้เราเข้าใจในเรื่องของการทำงานเป็นรอบ การประเมินความยากง่ายของงาน และบทบาทหน้าที่ในการทำงาน
ลักษณะของเกมส์คือ มีการ์ดมาให้ทั้งหมด 25 ใบ เป็นเรื่องของการโยนเหรียญ โดยใบ 1 ใบเปรียบเสมือน Task งาน 1 งาน โดยงาน ก็จะมีมูลค่ากำกับอยู่ ซึ่งในที่นี้ก็จะแบ่งเป็น 1000 100 50 20 10 อย่างละ 5 ใบ รวมเป็นมูลค่า 5,900 (หน่วยคือล้านบาท) สิ่งที่ต้องทำคือ ทำงาน 25 งานนี้ให้เสร็จภายใน 45 ครั้ง แบ่งเป็น 3 รอบ รอบละ 15 ครั้ง เพื่อให้เกิดมูลค่าสูงสุด
การดำเนินกิจกรรมคือ จะมีตัวละครสองกลุ่ม คือ
- Product Owner กับผู้ช่วย คือผู้ที่จะตัดสินใจว่าเราจะทำงานไหนตามลำดับความสำคัญ
- Development Team คือผู้ที่จะต้องประเมินและปฏิบัติงานที่ได้รับ
ขั้นตอนการดำเนินเกมส์
- PO และผู้ช่วย ทำการเลือกและแบ่งงานเป็น 3 รอบ พร้อมทั้งให้ลำดับความสำคัญก่อนหลังของแต่ละงาน โดยงานทั้งหมดจะอยู่ในที่จัดเก็บของ PO เรียกว่า Product Backlog
- DevTeam นำ Task ในรอบที่ 1 ของ Product Backlog มาประเมินความยากง่าย (Estimation) เพื่อดูว่างานแต่ละใบมีความยากง่ายขนาดไหน
- DevTeam ประเมินว่างานในรอบที่ 1 ที่ได้รับนั้นทำได้หมดหรือไม่ แล้วกลับไปให้คำตอบกับ PO เพื่อให้ PO ประเมินงานในรอบที่ 1 ใหม่
- เมื่อ PO ประเมินงานในรอบที่ 1 ใหม่แล้ว นำงานจาก Task ทั้งหมดย้ายเข้ามาไว้ใน Sprint Backlog ซึ่งประกอบไปด้วย 3 ช่องคือ To Do | Doing | Done โดยเริ่มต้นเราจะย้ายงานทั้งหมดมาไว้ในช่อง To Do
- จากนั้น ทาง DevTeam เริ่มหยิบการ์ดใบที่ 1 เพื่อมาทำงานโดยย้ายมาไว้ฝั่ง Doing เพื่อบอกว่าเรากำลังทำงานใบไหน พร้อมทั้งบันทึกผลการทำงานแต่ละครั้งไว้ในแผ่นบันทึก หากทำงานสำเร็จ ให้ย้ายการ์ดไปไว้ที่ Done แล้วหยิบการ์ดลำดับถัดไปเข้ามาทำงาน
- เมื่อทำงานถึงครั้งที่ 7 หรือกลาง Sprint ให้ทำการพิจารณางานทั้งหมดที่มีอยู่ว่าต้องการปรับเปลี่ยนอะไรหรือไม่ โดยทาง DevTeam ต้องไปคุยกับ PO เพื่อขอปรับเปลี่ยน และ PO จะปรับเปลี่ยนจะถอดออก หรือจะสลับงาน หรือจะแลกงานใหม่เข้าไปแทนก็ได้
- จากนั้น DevTeam ดำเนินงานต่อจนครบ 15 ครั้ง หรือจบ 1 Sprint งานที่สามารถทำได้สำเร็จ ก็จะส่งมอบให้ PO ตรวจรับ ส่วนงานที่ยังไม่เสร็จ ก็คืนให้ PO เพื่อให้ PO ทำการประเมินงานที่จะส่งมาให้ในรอบถัดไปใหม่
- ดำเนินเกมส์ตามข้อ 2–7 ใหม่จนครบ 3 Sprint จากนั้นดูผลว่าเราสามารถสร้างสินค้าได้มูลค่าเท่าไหร่ นับจากจำนวนงานที่ทำได้สำเร็จ
สิ่งที่ได้จากกิจกรรมนี้ คือทำให้เห็นภาพรวมการทำงานแบบแบ่งรอบมากขึ้น ทำให้รู้ว่าเราจะจัดการบริหารความเสี่ยงได้ดีกว่า เพราะมีการประเมินและต่อรองกันตั้งแต่เริ่มต้น และมีการประเมินและต่อรองกันอยู่เรื่อยๆ เพื่อลดความเสี่ยงในการส่งงานไม่ได้
Estimation
ผมได้รับงานในรอบ Sprint ที่ 1 มา 6 งาน ผมเขียนผลลัพธ์ที่เป็นไปได้ทั้งหมดที่ PO ยอมรับ (เพื่อเป็นข้อตกลงว่า ถ้าหากทำงานได้ถูกต้องตามผลลัพธ์ ถือว่างานใบนี้เสร็จ) จากนั้นประเมินความยากของงานแต่ละใบ สรุปออกมาได้ M XL L S M S ตามลำดับ ดูจากกรอบระยะเวลาที่มีให้ ในที่นี้คือ 15 ครั้ง เพื่อให้งาน 6 ใบเสร็จ ซึ่งผมก็ประเมินว่ามีงานที่ยากถูกโยนเข้ามา 2 งาน แถมลำดับความสำคัญดันมาต้นๆ ทั้งสอบใบ (อันดับ2–3) ผมเลยไปบอก PO ว่าผมอาจจะส่งมอบงานได้แค่ 2 ใบแรก เพราะใบที่ 2 อาจใช้เวลานาน อาจจะทำงานที่ 3 ไม่เสร็จ เลยจะขอถอดงานลำดับที่ 3 แต่ทาง PO ขอใช้วิธีปรับลำดับความสำคัญของงานใหม่ โดยย้ายงานลำดับที่ 3 ไปไว้เป็นลำดับที่ 6 ผมเลยได้ลำดับการทำงานใหม่เป็น M XL S M S L
การประเมินงาน เป็นเรื่องของการประเมินความสามารถในการทำงานภายใต้ระยะเวลาที่กำหนด เพื่อป้องกันความเสี่ยงที่เกิดขึ้น หรือทำเพื่อให้เกิดความเสียหายในกรณีที่ผิดพลาดขึ้นมาให้เสียหายน้อยที่สุด เพราะฉะนั้น ถ้าคิดว่าไม่ทันหรือไม่เข้าใจ ให้คุยกับ PO ตรงๆ ดีกว่าให้ PO มาเจอแจ๊คพ๊อตว่าจะ Deliver งานให้ลูกค้าไม่ได้
การประเมินงานนั้นมีหลายเทคนิคที่สามารถนำไปใช้ได้ เช่น การเปรียบเทียบด้วย Size ว่าอันไหนยากกว่าหรืออันไหนง่ายกว่า (Analogy) การแตกรายละเอียดเป็น Task ย่อยๆก่อนเพื่อให้ประเมินง่ายขึ้น (Disaggregation) การถามผู้เชี่ยวชาญ (Expert Opinion) หรือการใช้ Planning Poker ที่มีลักษณะเป็นการให้คะแนนความยากโดยทุกคนในทีม
หลังจากทำความเข้าใจเรื่อง Estimation กันไปแล้ว ช่วงบ่ายเป็นเรื่องของการแตก Requirements เพราะเวลาที่ PO ให้ Requirements มาจะอยู่ในรูปแบบของ Stated Requirements เช่น ต้องการสั่งสินค้าลงไปในตะกร้าสินค้า ซึ่ง Requirement แบบนี้เราไม่สามารถเอาไปทำ Software ได้ จึงต้องมีการกลั่น Stated Requirements ให้เป็น Real Requirements ที่สามารถเอาไปใช้ในการพัฒนาได้จริง จึงเกิดกิจกรรม การทำ Fishbone Diagram
การทำ Fishbone Diagram คือการใช้รูปก้างปลา ที่ปลายก้างคือ Feature ต่างๆของ Product และในแต่ละเส้นก้าง คือ Story ต่างๆ ที่อยู่ภายใต้ Feature นั้นๆ ซึ่งคำแนะนำของ Coach คือ ให้แต่ละคนเขียนไอเดียของตัวเองใส่ Post-it ของใครของมัน เป็นก้างปลาของตัวเอง (หรือทีมตัวเองกรณีมีกลายทีม) จากนั้นจะเข้าสู่กระบวนการถัดไป คือการทำ User Story Mapping
ในการทำ User Story Mapping คือการเอา Feature ของทุกคนมารวมกัน ถ้าอันไหนซ้ำกันก็ให้แปะทับกัน แล้วก็เอา Story แต่ละ Feature แปะไว้ภายใต้หัวข้อของ Feature นั้นๆ ซึ่งเราจะได้รวบรวมหลายความคิดหลายไอเดีย เมื่อรวบรวมเสร็จ ก็ถึงคราว PO มาดูว่าตรงกับสิ่งที่เค้าต้องการรึเปล่า
และสุดท้าย เราก็จะได้รู้ว่าใน Sprint นี้เราจะได้ทำอะไรบ้าง
วันที่สอง
เรื่องแรกที่เจอในเช้าวันที่สอง คือการทำความเข้าใจเรื่องการทำ Testing ซึ่งในระดับของลูกค้า จะสนใจแค่เรื่องของ Business Requirements และจะตรวจรับด้วย Acceptance Testing ว่าทำงานได้ตรงตาม Business Requirements รึเปล่า ซึ่งจาก Business Requirements ก็จะไหลลงไปสู่ชั้น Technical ที่ต้องแปลง Business Requirements ให้เป็น Software Requirements Specification (ทดสอบด้วย System Test) ตามด้วย Hi-Level Design (ทดสอบด้วย Integration Test) และสุดท้ายคือ Detail Design (ทดสอบด้วย Unit Test) ซึ่งเป็นตัวที่สามารถเปลี่ยน Requirements ให้กลายเป็น Source Code ได้ หลังจากเข้าใจแล้ว ก็มาเขียน Test Case กันเล่นๆ ว่า Business Requirements ในการ Login จะมี Test Case อะไรบ้าง (ไม่ได้ถ่ายรูปมานะครับ)
เทคนิคที่ทางทีม Coach ใช้เพื่อวางแผนในการทำงานจาก Requirement คือ A-DAPT Blueprint เป็นการหยิบ Test Case ใน Requirement (ในที่นี้คือ Login) มาออกแบบ (Design) วิเคราะห์ (Analyze) วางแผน (Plan) และ การทดสอบ (Test)
จากนั้นก็ทำ Break Down Task ในแต่ละใบว่าเราสามารถแตกออกมาเป็นงานอะไรได้บ้าง พร้อมทั้งประเมินงานแต่ละใบว่าใช้เวลาเท่าไหร่ และทั้งหมดจะใช้เวลาเท่าไหร่ในการพัฒนาเพื่อให้สามารถทำงานได้จริง
เมื่อเราได้ตัวเลขและ Task ที่ประมาณการออกมาแล้ว ก็ให้สรุปกับ PO ว่า ด้วยเวลาที่กำหนดใน Sprint นี้ เราจะทำให้ PO ได้เสร็จทุกอย่างหรือไม่ ถ้าไม่ PO จะได้อะไรแค่ไหน ถือเป็นการทำข้อตกลงว่า เมื่อจบ Sprint นั้น PO จะต้องได้สิ่งที่เราพูดไว้จากตอนนี้
ในช่วงบ่าย ก็เป็นการทบทวนการทำการ Planning โดย PO จะให้โจทย์มาเพื่อให้เราวางแผน โดยมีระยะเวลาให้เพียงแค่ 2 ชั่วโมงรวมวางแผนและพัฒนา ดังนั้น การบริหารจัดการเวลาเป็นเรื่องสำคัญ ซึ่งในการทำงานจริง จะมีคนที่เป็น Scrum Master คือผู้ที่จะคอยตบตีคนในทีมให้เข้าที่เข้าทาง ไม่หลุดประเด็น หรือไม่ให้เกิดสิ่งที่ทำให้เสียเวลา เพราะทุกกิจกรรมใน Scrum จะถูกควบคุมด้วย Time Box ทุกกิจกรรม เมื่อหมดเวลา กิจกรรมก็ต้องจบ การรักษาเวลาเลยถือเป็นเรื่องสำคัญ เพราะฉะนั้น เราต้องรู้ว่าในแต่ละกิจกรรมต้องการอะไร แล้วเราจะทำอะไรเพื่อให้ได้สิ่งนั้นออกมา
การวางแผนในช่วงบ่ายเกิดขึ้นด้วยความวุ่นวาย เพราะมีทั้งความเข้าใจไม่ตรงกัน ความต้องการไม่ชัดเจน และที่สำคัญ ทุกอย่างถูกบีบด้วยเวลา ภาพที่เกิดขึ้นคือ ความโกลาหลเพราะเมื่อทำงานเองจริงๆครั้งแรกยอมรับว่ามันยาก Scrum Master ก็แนะนำว่าถ้าไม่เข้าใจหรือสงสัยตรงไหนเกี่ยวกับความต้องการให้เดินไปถาม PO เพราะ PO คือคนเดียวที่จะให้คำตอบเราได้ และนี่ก็คืองานที่เราใช้เวลาช่วงบ่ายในการวางแผน 1 Feature (ระบบเติมเงิน)
กิจกรรมสุดท้ายของวันที่สอง คือการทำ Retrospective โดยการให้ทุกคนเขียนปัญหาที่กังวลว่าจะเกิดขึ้นในการทำงานใน Sprint หน้า แล้วก็ไปแปะๆรวมกัน อันไหนเหมือนกันก็แปะทับๆกัน และสุดท้ายก็ทำการแยกหมวดหมู่ ว่าปัญหาไหนที่เราคิดว่าขจัดได้ ปัญหาไหนควบคุมไม่ให้รุนแรงได้ และปัญหาไหนที่แก้ไม่ได้
หลังจากที่เราได้ What มาแล้ว ถัดมาคือ How ว่าเราจะแก้ปัญหานั้นอย่างไร แล้วเราจะชี้วัดยังไงว่าปัญหานั้นถูกแก้ไปแล้วจริงๆ ความสำคัญของการชี้วัดคือ ถ้าเราไม่มีการชี้วัดการแก้ปัญหา สุดท้ายเราก็ไม่รู้ว่าปัญหามันลดลงรึเปล่า
วันสุดท้าย
วันสุดท้าย เปิดเรื่องด้วยการทำความเข้าใจเรื่อง Test Driven Development เพื่อให้เห็นประโยชน์ของแนวคิดในการเขียน Test ก่อนการ Develop
ในวันนี้ เป็นวันที่เราจะต้องทำ Sprint เพื่อส่งมอบ Feature ที่ตกลงเมื่อวาน โดยให้เวลา 5 ชั่วโมงในการทำงานตั้งแต่ Planning จนเสร็จสิ้น Retro ซึ่งเป็นการนำสิ่งที่เรียน 2 วันแรกมาใช้ปฏิบัติกันจริงๆ โดยกระบวนการทั้งหมดจะเป็นดังนี้
- Planning 1 (What & Why) คือ PO บอกว่า Goal ของ Sprint นี้จะทำเรื่องอะไร มี Feature ไหนบ้าง ทีมสามารถถามข้อสงสัยต่างๆได้ เพื่อนำไปทำต่อใน Planning 2
- Planning 2 (How & How Much) คือ Team ทำการวางแผน ออกแบบ วิเคราห์ ประมาณการแล้วให้คำตอบกับ PO ว่า PO จะได้ทุกอย่างตามที่ต้องการใน Goal นี้หรือไม่ ถ้าไม่ได้ จะทำได้แค่ไหน
- Daily Scrum + Develop ในช่วงเวลาการ Develop ในแต่ละวัน ( ณ ที่นี้คือในแต่ละชั่วโมง) ทีมจะต้องทำการ Daily Scrum เพื่อทำการ Sync ข้อมูลว่าตัวเองทำอะไรเสร็จ และกำลังทำอะไรต่อ หรือมีปัญหาที่ติดตรงไหน (เพื่อให้คนอื่นรู้และเข้าไปช่วยได้) โดยเราจะไม่ลงรายละเอียดลึกๆ (ถ้าจะลงรายละเอียดให้ไปทำหลัง Daily Scrum)
- Product Backlog Refinement ตรงนี้มีการพูดถึงคร่าวๆ คือการนำ Product Backlog มาวางแผนคร่าวๆในการทำ Sprint ถัดไป
- Review การนำเสนอ Product ให้ PO ว่า PO จะตรวจรับหรือไม่
- Retrospective การสะท้อนสิ่งที่เกิดขึ้นออกมา ไม่ว่าจะเป็นตัวเอง ทีม การทำงาน กระบวนการต่างๆ เพื่อให้เห็นข้อดี ข้อเสีย ปัญหาและแนวทางในการแก้ไขเพื่อเป็นการทำให้ Sprint ถัดๆไปนั้นดีขึ้น
สรุป
สิ่งที่รับรู้อย่างได้อย่างแรกจากการทำ Workshop 3 วันนี้คือ Scrum ให้ความสำคัญกับ “การวางแผน” มาก เราใช้เวลาส่วนใหญ่ไปกับการคิดและวางแผน ซึ่งพอถึงขั้นตอนพัฒนาจริงๆ คนแปลกหน้าหลายคนเข้ามาทำงานด้วยกันอย่างราบรื่น เพราะมีการวางแผนทุกอย่างชัดเจน มีการกำหนดมาตรฐานตั้งแต่เริ่มทำงาน มีการระดมความคิดที่ทุกคนมองเห็นภาพเดียวกัน เมื่อลงมือทำ ทุกคนก็ไหลไปในทิศทางเดียวกัน อาจจะมีหลุดกรอบไปบ้างแต่ก็ไม่เยอะ
“เวลา” เป็นสิ่งที่สำคัญไม่แพ้กันกับการวางแผน เพราะถ้าเราบริหารจัดการเวลาไม่เป็น หลายๆอย่างก็อาจจะไม่เป็นไปตามแผน
“ความคิด”ของทุกคน คือสิ่งที่สำคัญในการทำงาน การออกไอเดีย การระดมความคิดด้วยกัน แม้แต่การประเมินความยากของงาน ก็ต้องประเมินด้วยกันทั้งทีม เพราะฉะนั้น การแสดงความคิดเป็นเรื่องที่จำเป็นอย่างยิ่งในการวางแผนทำงาน
“Testing” เป็นกระบวนการที่ผมมองว่าหลายๆที่มักจะมองข้ามและให้ความสำคัญเป็นเรื่องหลังๆ แต่หลังจากจบ Workshop ที่นี่ทำให้ผมเห็นความสำคัญของกระบวนการ Test ต่างๆ โดยเฉพาะแนวคิดการทำ UAT ก่อนที่จะพัฒนา มันทำให้เราสามารถวางแผนต่อได้ว่าเราจะพัฒนาในทิศทางใด
สุดท้ายแล้วขอขอบคุณทางผู้จัด วิทยากร และทีมงานทุกคนที่จัดกิจกรรมดีๆแบบนี้ ที่ทำให้เห็นภาพของ Agile ในการพัฒนา Software ได้ชัดขึ้น
ปล. ไม่แน่ใจว่าผมเข้าใจประเด็นไหนผิดบ้างรึเปล่า ถ้าทีมงานแวะผ่านมาอ่านแล้วคิดว่าตรงไหนผมยังเข้าใจผิดก็บอกได้ครับ :)
