สรุปการอบรม Agile 1 วันเพื่อนำมาใช้ในองค์กร

ผมได้ยิน Agile มาก็นานมากแล้ว และได้อ่านจากบทความต่างๆ มาก็มาก แต่ก็ไม่เคยที่จะนำมาใช้งานจริงจังเลย นำเพียงบ้างส่วนของแนวคิด และวิธี scrum มาใช้งานเพียงนิดเดียว และไม่เคยรู้ว่าเลย Agile จริงๆ แล้วมันคืออะไร บริษัทอื่นๆ เขานำมาใช้ยังไงกัน

ซึ่งในปีนี้พวกผมเลยตั้งเป้าหมายกันว่าจะยกระดับการพัฒนาซอฟแวร์ขึ้นมาอีกขั้น ก็เลยเลือก Agile มาเป็นส่วนหนึ่งของเป้าหมายนี้ ฮาๆ จะได้ไปคุยกับคนอื่นได้ว่าบริษัทผมก็ใช้ Agile นะเว้ยยยย

ในวันที่ 21 กุมภาพันธ์ 2563 พวกเราจึงได้เชิญอาจารย์ทีปกร ศิริวรรณผู้มากประสบการณ์ในการทำบริษัทซอฟแวร์ และทำ Start up ต่างๆ และเป็น Scrum Master Certification มาช่วยสอนพวกเราตั้งแต่ระดับ MD, CTO, PM และโปรแกรมเมอร์ให้รู้จัก Agile กันมากขึ้น เพื่อให้ทั้งองค์กรสามารถขับเคลื่อนไปในแนวทางเดียวกันได้อย่างมีประสิทธิภาพ เหมือนกับการวิ่งสามขา

คุณค่าใน Agile

Agile นั้นไม่ได้เหมาะสมกับทุกธุรกิจ และทุกโปรเจ็ค ดังนั้นเราต้องรู้จักในตัว Agile ก่อนว่ามันมีคุณค่าอะไรที่เหมาะสมให้เราสามารถนำมาใช้งานได้อย่างเต็มประสิทธิภาพ คุณค่าของ Agile ได้แก่

• สนใจ และให้ความสำคัญในการคุยกันมากกว่ากระบวนและการใช้เครื่องมือ
• ให้คุณค่าของซอฟแวร์มากกว่าการทำงานตามเอกสาร (TOR)
• ให้คุณค่าการทำงานร่วมมือกับลูกค้า มากกว่าการต่อรองกัน
• ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

1. สนใจและให้ความสำคัญในการคุยกันมากกว่ากระบวนการ และการใช้เครื่องมือ

เราควรให้ความสำคัญกับการคุยกัน (Communication) ระหว่างทีมพัฒนาด้วยกันเอง หรือแม้แต่ระหว่างลูกค้ากับทีมพัฒนา เพื่อให้มีการอัพเดทสถานะการทำงานอยู่บ่อยๆ หรือมีการแชร์ปัญหา หรือข้อติดขัดในการทำงานๆ นั้นกับลูกค้าได้เร็วที่สุด ฉะนั้นคุยกันเถอะ คุยกันเยอะๆ

2. ให้คุณค่าของซอฟแวร์มากกว่าการทำงานตามเอกสาร (TOR)

ในการพัฒนาซอฟแวร์ส่วนใหญ่เราจะมีการรับ requirement ต่างๆ มาจากลูกค้าเบื้องต้นแล้วก็มาเขียนเอกสาร TOR (Term of Reference) เพื่อกำหนดทิศทางของซอฟแวร์นั้นๆ ก่อนลงมือปฎิบัติกันจริง

แต่เนื่องจากเราต้องเข้าใจก่อนว่าการพัฒนาซอฟแวร์นั้นเป็นงาน Craft หรืองานที่ต้องใช้ฝีมือทำขึ้นมาก็จะมีโอกาสที่การพัฒนานั้นๆ อาจไม่ตรงตามเอกสารเสมอไป เราควรให้ความสำคัญกับตัวซอฟแวร์ที่สามารถนำไปช่วยผู้ใช้งาน (End users) ได้จริงๆ

3. ให้คุณค่าการทำงานร่วมมือกับลูกค้า มากกว่าการต่อรองกัน

จงจำไว้ว่า “คนซื้อไม่ได้ใช้ คนใช้ไม่ได้ซื้อ” นั้นหมายความว่าอะไร โดยส่วนใหญ่ลูกค้าที่จ้างเราพัฒนาซอฟแวร์ขึ้นมาไม่ได้เป็นผู้ใช้ซอฟแวร์นั้นโดยตรงจริงๆ หรือที่เราเรียกกันว่า End user

ดังนั้นทีมพัฒนากับผู้จ้างพัฒนาควรทำงานร่วมกัน พูดคุยกัน และแก้ไขปัญหาร่วมกัน มากกว่าที่จะมาทะเลาะกันเอง และก็เกิดการต่อรองกันไปๆ มาๆ ซึ่งผลสุดท้ายแล้วซอฟแวร์นั้นๆ End user อาจจะใช้งานไม่ได้จริงก็ได้

4. ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

แผนการทำงานเราสามารถกำหนดไว้ได้เพื่อเป็นแนวทางในการดำเนินงาน แต่เราต้องเข้าใจด้วยว่า ทุกอย่างในโลกนั้นอนิจัง คือมีการเปลี่ยงแปลงได้ตลอดอาจไม่เป็นไปตามแผนเสมอไป เพื่อให้ตอบสนองความต้องการของ End user ให้มากได้ที่สุด

พื้นฐานการเข้าใจในเรื่อง Agile และ Scrum

Scrum เป็นเพียงเครื่องมือหนึ่งที่ถูกนำมาใช้มากกว่า 80% ในระบบ Agile ของงานพัฒนาซอฟแวร์ ดังนั้นเรามาทำความเข้าใจพื้นฐานกันก่อนสำหรับ Agile และ Scrum

พื้นฐาน Agile

โดยทั่วไปเราจะนิยมส่งมอบซอฟแวร์ทั้งหมดในคราวเดียวให้ลูกค้าเลย เหมือนกับการทำเค้กแล้วเราส่งให้ทั้งก้อนเลย ซึ่งการทำลักษณะนี้จะเรียกกันว่า Waterfall

แต่ในการส่งมอบงานซอฟแวร์ของ Agile จะเป็นการส่งมอบเค้กแบบถูกแบ่งชิ้นออกมา ให้เรานึกถึง เค้ก 1 ชิ้นซึ่งจะมีส่วนประกอบสามส่วนหลักๆ คือ หน้าเค้ก, เนื้อเค้ก และขนมปัง แล้วให้ลูกค้านั้นกินได้เลย เพื่อให้รู้ว่ารสชาติอร่อยแค่ไหน

ซึ่งการส่งเค้กเป็นชิ้นลักษณะนี้เปรียบเสมือนกับการที่เราส่ง Feature บ้างอย่างออกไปให้ลูกค้าได้ทดลองใช้งานจริงก่อน เช่น ส่งมอบแค่ระบบ Login ไปก่อนโดยระบบจะต้องสามารถใช้งานล็อกอินได้จริง มีหน้าตา และสีที่เหมือน Design ที่ออกแบบกันมาครบ โดยอาจจะไปสุดท้ายที่หน้าโล่งๆ แล้วเขียนแค่ Welcome ก็ได้

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

พื้นฐาน Scrum

จากที่ได้บอกไปข้างต้นแล้วว่าเราต้องส่งมอบเค้กแบบเป็นชิ้นให้ลูกค้าไปชิมก่อน ซึ่งนั้นก็หมายความว่า เราและลูกค้าจะมีการพบกันบ่อยขึ้น คุยกันมากขึ้นทำการประชุมเกิดบ่อยขึ้น แต่จะทำยังไงให้การคุยกันแต่ละครั้ง มีประโยชน์สูงสุด Scrum จึงมาช่วยเราในสิ่งนี้

ในการ Scrum แต่ละครั้งจะประกอบไปด้วยกลุ่มคนอยู่สามตำแหน่ง คือ

• Product Owner คือคนที่อยากได้ของ หรือลูกค้า และคนๆ นี้ต้องเป็นคนตัดสินใจได้ว่าต้องการส่วนไหนก่อนหลัง หรือเอาและไม่เอาอะไร
• Scrum Master คือคนที่เข้าใจในระบบ scrum คนที่ค่อยช่วยเหลือทีม และเข้าใจสิ่งที่นักพัฒนากำลังทำอะไรออกมา และต้องค่อยสื่อสารระหว่างลูกค้า (Product owner) กับนักพัฒนา (Team) ด้วย
• Development Team คนที่พัฒนาซอฟแวร์ ซึ่งถ้าเป็นไปได้คนในทีมควรทำงานแบบ Cross function ได้เพื่อถ้าตอนไหนขาดไปคนหนึ่ง อีกคนก็ยังสามารถช่วยทำได้

จำนวนทีมของการ Scrum ไม่ควรเกิน 8-10 คน

The Agile – Scrum Framework

หลังจากที่รู้พื้นฐานกันมาแล้ว ตอนนี้ก็มาดูกันในเรื่องของการนำ Scrum มาใช้งานจริงว่าประกอบไปด้วยอะไรบ้าง ถึงจะสามารถส่งชิ้นเค้กให้ลูกค้าได้กินบ่อยๆ เราจะเรียกกระบวนการนี้ว่า Scrum Framework

Product backlog

Product backlog คือจำนวนงานที่ต้องทำเพื่อให้เกิดผลิตภัณฑ์ออกมาซึ่งในช่วงนี้ Product Owner จะต้องอยู่ด้วยเพื่อเป็นคนบอกว่ามี Requirment อะไรบ้าง โดยจะเขียนในรูปแบบของ User story card ซึ่งจะเป็นการเขียนให้อยู่ในรูปแบบประโยคสั้นๆ อ่านแล้วเข้าใจง่าย จะเป็นลักษณะดังนี้

• As a <user role> ตำแหน่งอะไร?
• I want <goal> ต้องการอะไร?
• so that <benefit> เพื่อประโยชน์อะไร?

โดยส่วนใหญ่เราจะเห็นการเขียนในกระดาษ Post it แล้วนำมาแปะไว้ที่บอร์ดส่วนกลางเพื่อให้ทุกคนได้เห็น

จากนั้นก็ให้ Product owner เป็นคนกำหนดว่า User story card อันไหนควรทำก่อนหรือหลัง เพื่อให้ทุกคนเห็นว่าอันนี้มันสำคัญสำหรับ Product owner นะ

การทำ Product backlog นั้นส่วนใหญ่จะใช้เวลาประมาณครึ่งวัน หรือ 1 วันเลย เพราะเราต้องเอา Requirement แสดงออกมาให้ทุกคนในทีม และ Product owner เห็นทั้งหมดก่อนทีจะเริ่มทำงานกัน

Sprint Planning Meeting

เป็นการนำ User story card มาจัดสรรลงในการทำงานแต่ละ Sprint ซึ่งคำว่า “Sprint” จะหมายถึงระยะเวลาการทำงานตั้งแต่ 1-4 สัปดาห์ แต่โดยส่วนใหญ่แล้วจะกำหนดกันไว้ที่ 2 สัปดาห์

นั้นหมายความว่าถ้าพูดว่างานที่ทำจะจบใน 1 sprint ให้รู้ได้เลยทันทีว่าคือ 2 สัปดาห์

คราวนี้เราก็จะได้รู้ว่าแล้วงานทั้งหมดจะใช้ระยะเวลาประมาณกี่ sprint หรือกี่สัปดาห์

หลังจากที่เราเขียน User story card แล้วก็ให้คนในทีมแตกการทำงานออกมาเป็น issue ของในแต่ละ User story card จากนั้นก็มาถึงการให้คะแนนความยากง่ายของใบนั้นๆ โดยจะใช้หลักการที่เรียกว่า Scrum poker เข้ามาเป็นตัวเลขการให้คะแนน

ดังรูปบนคะแนนจะเป็นเลขฟิโบนาชชี่ (Fibonacci numbers) คือ 0,1,2,3,5,8,13,20,40 และ 100 (ไม่ตายตัวนะ) เลขน้อยคือง่ายสุด วิธีการให้คะแนนก็เป็นดังนี้

1. Scrum master อ่าน User story card นั้นๆ ออกมาแล้วอธิบายเพิ่มเพื่อให้ทุกคนเข้าใจตรงกัน
2. หาก Product owner ฟังแล้วไม่ตรงใจสามารถอธิบายเพิ่ม หรือแก้ไขเพื่อให้ได้ของที่ถูกต้อง
3. Development ทุกคนใส่เลขคะแนนที่ตัวเองคิดว่าทำได้ง่าย หรือยากลงไปในกระดาษของตัวเอง แล้วปิดไว้ก่อน
4. Scrum master ให้ Development เปิดคะแนนนั้นๆ ออกมาให้เห็นกันหมด แล้วดูว่าความแตกต่างของคะแนน ถ้าไม่เหมือนกัน ให้คนที่คะแนนน้อยสุด กับมากสุดพูดอธิบายว่าทำถึงให้คะแนนแบบนี้ออกมา ด้วยเหตุผลอะไร ซึ่งความยากง่ายของแต่ละคนไม่เหมือนกัน
5. หลังจากอธิบายกันจบแล้ว Scrum master จะให้ทุกคนใส่คะแนนกันใหม่ แล้วพอเปิดออกถ้าคะแนนทุกคนยังไม่เท่ากันอีก ก็จะวนกลับไปข้อ 4 อีกครั้งเพื่อให้ทีมได้อธิบายถึงคะแนนนั้นออกมา
6. ทำข้อ 4-5 วนไปเรื่อยๆ จนกว่าทุกคนในทีมจะใส่คะแนนได้เท่ากันสำหรับ User story card นั้นๆ ก็เป็นอันจบ

เพียงแค่นี้เราก็จะได้ Issue ที่มีคะแนนทุกอัน

Sprint backlog

ในส่วนนี้จะเป็นการทำงานในแต่ละ sprint ซึ่งจะต้องมีการประชุมทีมกันทุกวัน เวลาไหนก็ได้ตามที่ทีมตกลงกันเอง เราจะเรียกว่า “Daily Scrum” โดยระยะเวลาในการประชุมจะไม่เกิน 15 นาที เนื้อหาสาระจะมีเพียงแค่

• เมื่อวานใครทำอะไร
• วันนี้ใครทำอะไร
• ใครติดปัญหาอะไร

และก็จะมีการแยกชิ้นงานออกมาจาก User story card เพื่อนำไปใส่ใน Kanban board แยกส่วนให้เห็นว่า Task ไหนอยู่ไหนแล้ว ซึ่งโดยส่วนมาก Kanban board เราจะแยกเป็น 3 ส่วนคือ To-do, In-progress และ Done

เมื่อประชุมกันเสร็จ ก็แยกย้ายไปทำงานของแต่ละคนได้เลย ในระหว่างนี้ใครทำอะไรส่วนไหนก็นำ Task ตัวเองเลือนไปยังช่องที่กำหนดไว้

Sprint backlog ควรอยู่ในจุดที่ทุกคนในทีมเห็นได้ เพื่อให้เห็นความคืบหน้าของการทำงานทั้งหมดว่าอะไรไปถึงไหนแล้ว

Sprint Review

เป็นขั้นตอนหลังจากจบในแต่ละ sprint เพื่อเป็นการส่งชิ้นเค้กให้กับลูกค้าได้ลองชิม หรือได้ลองทดสอบ features ต่างๆ ที่ได้ทำมากันใน sprint ก่อนนำขึ้นไป Production จริง และรับ feedback จาก Product Owner หรือผู้ใช้งาน และ Product Owner ก็จะแจ้งให้ทราบถึงสิ่งที่ต้องทำต่อไป ซึ่งโดยส่วนใหญ่จะใช้เวลาประมาณครึ่งชั่วโมง ถึงหนึ่งชั่วโมง

Sprint Retrospective

มาถึงขั้นตอนสุดท้ายของ Sprint แล้วก็คือ Sprint retrospective คือการประชุมภายในทีมกันเองเพื่อหาข้อดี ข้อเสียต่างๆ และจุดที่ทีมสามารถจะปรับปรุงให้ดีขึ้นได้ในรอบการทำงานต่อไป

สุดท้าย

ทั้งหมดที่เขียนมาคือสิ่งที่ได้ความรู้มาภายใน 1 วันซึ่งรายละเอียดและวิธีการของ Agile มันยังมีอีกมากที่น่าสนใจ แต่อาจารย์ทีปกรก็ได้สอนพวกเราผ่านการเล่นเกมส์ต่างๆ เช่น Ball point game, Pass the pennies และ Snow flake ซึ่งเกมส์พวกนี้ทำให้พวกเราเข้าใจ และเห็นความสำคัญในระบบ Agile มากขึ้น

• 

• 

• 

• 

• 

• 

• 

• 

ข้อทิ้งท้ายด้วย quote ที่ได้รับจากการอบรมครั้งนี้

ความสำเร็จของ Scrum คือลูกค้า Confirm

Agile ควรเริ่มจากระดับผู้บริหารให้เข้าใจก่อน ไม่ควรเริ่มจากระดับล่างขึ้นมาบน

การเป็น Agile คือ เมื่อทีมขาดคนใดคนหนึ่งไปแล้วงานยังสามารถ Deliver ต่อไปได้ไม่สะดุด

เดียวได้ลองทำจริงอาจจะได้แชร์ประสบการณ์การทำ Agile ของพวกเรา Twin Synergy กันบ้าง 🙂