[สรุป] คอร์ส Google Project Management: Professional Certificate ตอนที่ 5: Agile Project Management
สวัสดีครับ ตอนนี้เราก็จะมาพูดถึงเรื่อง Agile และ Scrum ที่เป็นวิธีการขององค์กรที่พัฒนา Software ยุคใหม่แทบทุกองค์กรที่ได้เปลี่ยนไปใช้วิธี Agile นี้กันหมดแล้ว บอกได้เลยว่าในบรรดา 6 ตอน ตอนนี้เป็นตอนที่ผู้เขียนชอบมากที่สุดละครับ และด้วยในฐานะที่เราจะเป็น Project Manager เราก็ควรรู้จักการบริหารโครงการด้วยการใช้แนวคิด Agile นี้ด้วย ถึงแม้ใน Agile มันจะไม่มี Role PM จริงๆก็ตาม เพราะ ใน Agile เขาจะเรียกชื่อ Role แทนกันว่า Scrum Master ไม่ก็ Product Owner เนอะ แต่สุดท้ายยังไงก็ตาม Role พวกนี้ก็คงยังคงต้องพึ่งสกิลของ PM ประกอบด้วย เป็นอย่างไรบ้างครับ น่าสนใจไหมครับ ใครพร้อมแล้วก็ไปลุยกันได้เลยครับผม 🔥🔥
ส่วนตอนที่แล้วนะครับ เผื่อใครอยากย้อน
“Agile ไม่ใช้วิธีการ แต่ Agile คือ Culture ของผู้คน”
Week 1
มาถึงขอเริ่มต้นย้อนไปตั้งแต่ตอน 1 นะครับ ที่กล่าวไว้ถึงวิธีทำ Project จะใช้ 2 แนวทางใหญ่ๆครับ ได้แก่
- Waterfall : เป็นแนวทางการจัดการ Project แบบเส้นตรง เป็นขั้นเป็นขั้นตอนค่อยๆไป แล้วส่งมอบงานทีเดียว ปกติจะใช้กับ Project ที่ Requirement ค่อนข้างชัดเจน และไม่ค่อยมีการเปลี่ยนแปลงใด เป็นวิธีที่นิยมมากในการทำ Project
- Agile : เป็นแนวทางการจัดการ Project แบบแบ่งงานเป็นชิ้นงานเล็กๆ เน้นส่งมอบไวไปก่อน เหมาะกับ Project ที่มี Requirement ไม่ค่อยแน่ชัด และมีการเปลี่ยนแปลงสูง ซึ่งหลายบริษัทในปัจจุบัน ยิ่งเป็นบริษัทที่มีการพัฒนา Software ก็จะเป็นการใช้วิธีนี้แทนแล้ว
ก็ในตอนนี้เราจะลงลึกไปที่ Agile ครับ ซึ่งหลายคนคิดว่า Agile เป็นสิ่งใหม่ แต่เอาจริง ไม่ใหม่เลยนะครับ มันเริ่มใช้มาตั้งปี 1990 แล้ว และไม่ใช่ว่าสามารถทำใน Project ที่ทำเรื่อง Software ได้เท่านั้น เรื่องอื่นก็ทำได้ครับ แค่เรื่อง Software หรือเทคโนโลยีมันเปลี่ยนแปลงกันเร็ว และ Requirement ไม่ค่อยนิ่ง เขาเลยนิยมใช้ Agile กัน
ซึ่งเขาบอกเลยว่า
การเปลี่ยนมาใช้ Agile มันไม่ใช่แค่การเปลี่ยนวิธีการทำงาน เป็นคำ Buzz Word ที่สวยหรู แต่ต้องเปลี่ยนถึงระดับ Culture ของทั้งทีม จนไปถึงระดับองค์กร เลยครับ
โดยเขากล่าวกันว่าลักษณะของ Agile Manifesto ต้องมีดังนี้ครับ
- คำนึงถึงคน และการสื่อสารระหว่างกัน > เรื่อง Process และ Tool
- ใช้ Working Software > เอกสารหนาปึ้ก
- ใช้การทำงานร่วมกับลูกค้า > การทำสัญญาให้เซ็นสัญญามัดตัว
- พร้อมเปลี่ยนแปลงเมื่อเจอสิ่งที่ดีกว่า > ทำตามแผน
จะเห็นได้ว่าแนวคิดวิธีการทำจะแตกต่าง Waterfall ชัดเจนมากเลยนะครับ ที่มีเอกสารหนาปึ้ก คุยกับลูกค้า รับ Requirement ทีเดียวจบ แล้วก็ให้เซ็น และสุดท้ายก็เดินตามแผนจนจบกระบวนการ คือถ้าสิ่งที่เราคุยกับตั้งแต่แรก เราสามารถออกแบบมาได้อย่างสมบูรณ์แบบ วิธี Waterfall นี้ก็จะเป็นวิธีที่ Perfect มากครับ!!
แต่ในความเป็นจริงมันไม่ได้เป็นอย่างนั้น คือ ตัวลูกค้าบางครั้งเขาเองยังไม่รู้เลยว่าจะต้องทำไร รู้แค่กว้างๆ เช่น บอกว่าอยากได้รถที่บินได้ แต่หารู้ไม่มันคือ เครื่องบิน ซึ่งพอ Requirement ผ่านมือหลายคน จากสิ่งที่ต้องการเป็นเครื่องบิน อาจกลายเป็น เรือ ที่มันเป็นคนละเรื่องเลยก็ได้ คล้ายๆตัวอย่างใน VDO นี้ครับ
เราก็ไม่ได้อยากปล่อยให้ Dev ทำอุนจิออกมา แล้วไปเจอตอนจบใช่ไหมครับ ถ้าเรารู้ว่ามันมาผิดทางตั้งแต่แรกละ เราก็ควรแก้ก่อน นั่นเป็นที่มาที่เขาใช้วิธีที่เป็น Agile กันครับ ที่เน้นเรื่องการสื่อสารกันใกล้ชิด และนึกถึงผลประโยชน์ลูกค้าสูงสุดเป็นหลัก มากกว่าการยึดตามแผนเป๊ะๆ และแยกกันทำงานตัวใครตัวมัน และค่อยมาเซอไพร์สตอนจบ
เพื่อให้เข้าใจ Agile ขึ้นไปอีก ให้ท่องกฎเหล็กของ Agile 12 ข้อนี้และให้มันซึมซับอยู่ในสายเลือดครับ
- Priority ของเราสูงสุดคือการทำให้ลูกค้าพอใจ ด้วยการส่งมอบสิ่งที่ดีที่สุด
- ส่งมอบงานให้ถี่ที่สุด
- ใช้ Working Software เป็นตัวจัดการและวัดผล
- ทำทุกอย่างให้เรียบง่ายที่สุด อะไรไม่จำเป็นตัดออก
- ให้ Design สิ่งที่ดี และส่งมอบงานได้ไว
- ต้อนรับการเปลี่ยนแปลง Requirement ได้ตลอดเวลา แม้จะเป็นช่วงท้ายโปรเจค เพื่อสิ่งที่ดีที่สุดแก่ลูกค้า
- คนรู้ Business กับ Dev ต้องทำงานใกล้ชิดกันตลอดทั้ง Project
- สร้างทีมที่เป็นคนที่มี Motivation ซัพพอร์ตสิ่งที่ทีมต้องการ และไว้ใจทีมให้ทำงานไปจนจบ
- วิธีสื่อสารที่ดีที่สุด คือ คุยกันแบบ Face to Face
- นึกถึงการทำ Project แบบระยะยาวยั่งยืน ทุกๆคนต้องมีแรงทำงานและมีความมุ่งมั่นตลอดทั้ง Project ไม่ใช่ให้งานเยอะเกินไป จนท้อแท้ไปในที่สุด
- โครงสร้างพื้นฐาน, Requirement, ดีไซน์ ที่เยี่ยมที่สุด คือ เริ่มจากการที่เป็นทีมที่สมาชิกทุกคนสามารถจัดการตัวเองได้
- ตลอดช่วงระยะเวลา ทีมจะต้องมีการ Reflect ว่าจะต้องทำอย่างไรต่อไปเพื่อจะทำให้งานดีขึ้น และเอาวิธีนั้นไปใช้
ก็ถ้าทำได้ทั้ง 12 ข้อจริง งานที่ทำก็ควรจะออกมาดีกว่าแบบของ Waterfall แน่นอน เพราะ ทำทุกอย่างเน้น Quality จริงๆ แต่ก็นะครับ ชีวิตจริงทุกคนก็ไม่ได้ปฏิบัติตามได้ง่ายขนาดนั้น เพราะ ถ้ามีคนในทีมหรือคนนำใดไม่ได้ให้ความร่วมมือ และไม่ได้มีความเข้าใจวิธีการปฏิบัติแบบ Agile แบบฝังลงลึกถึง Culture ก็ยากที่จะใช้งานในทีมสำเร็จครับ หนำซ้ำอาจทำให้ชีวิตยุ่งยากขึ้นไปอีก เช่น องค์กรที่มี Culture ที่เป็นไซโล หรืองานเอกสารที่ต้องทำทุกขั้นตอนเต็มไปหมด หรือลูกค้าไม่ค่อยมีเวลามาคุยด้วยให้ความร่วมมือ อันนี้ก็ยากที่จะใช้ Agile ได้ครับ ต้องปรับตั้งแต่ต้นทางเสียก่อน ถ้ายังปรับไม่ได้เราอาจต้องใช้วิธีผสมกับ Waterfall ไปก่อนครับ จนองค์กรค่อยๆสามารถปรับตัว ก็ลองดูต่อกันไปครับ
ต่อไปหลังจากที่เราพูดเรื่อง Agile ไปแล้ว สิ่งที่จะลืมพูดต่อไม่ได้เลยนั่นคือ Scrum Framework ของ Agile ที่มีคนนิยมเอาไปใช้มากที่สุดในปัจุบัน
Scrum
Scrum หรือการลุมสกัม ให้นึกถึงกีฬารักบี้ ที่ทุกคนจะซุมหัวแย่งลูกรักบี้กัน โดยเพื่อให้ทีมชนะเราต้องทำงานกันเป็น Teamwork ช่วยกัน จนสามารถชนะไปถึงเป้าหมายที่ต้องการได้ครับ
คำศัพท์พื้นฐานที่ต้องรู้ใน Scrum นะครับ
- Product Backlog >> Feature หรืออะไรก็ตามของ Product ที่ List ออกมาเป็น Task งานเพื่อไปพัฒนาต่อ
- Sprint >> รอบการทำงาน และส่งมอบงานในแต่ละรอบ
- Daily Scrum >> ประชุม Daily Meeting สรุปงานที่ทำใน Sprint สั้นๆรายวันไม่เกิน 15 นาที
ส่วน Framework อื่นๆของ Agile ที่นิยมอีก เช่น
- Kanban >> ใช้ Post it แปะ แบ่งงานเป็น Stage ให้เห็นภาพง่าย
- XP (Extreme Programming) >> พัฒนา Product ที่มีคุณภาพที่สุด พร้อมสามารถปรับเปลี่ยนได้ความต้องการที่เปลี่ยนไปของลูกค้าได้ง่าย
- Lean >> การทำงานที่ทำเฉพาะสิ่งที่จำเป็น อะไรที่ไม่จำเป็น เปลืองเวลาตัดออก
Week 2
อาทิตย์นี้ผู้สอนก็มาลงลึกใน Scrum เพิ่มขึ้นอีกครับ โดยเริ่มจากแนวคิด 3 ทหารเสือของ Scrum ครับ
- Transparency >> โปร่งใส่ที่สุด มีปัญหาอะไรก็ต้องบอกทีมตรงๆ เพื่อมาแก้ปัญหา
- Inspection >> ต้องมีการตรวจสอบงานตลอดเวลา ว่าไปถึง Goal ของ Sprint ไหม ถ้าเจอปัญหาอะไรที่ต้องรีบแก้
- Adaptation >> เปลี่ยนแปลง เพื่อสิ่งที่ดีกว่าได้เสมอ
Scrum ปกติจะใช้คนประมาน 3–9 คน ต่อหนึ่งกลุ่ม ถ้ามากกว่านั้นอาจจะไม่ค่อยเหมาะแล้วครับ เพราะ คุมยาก ต่อไปเป็นเรื่อง 5 คุณสมบัติที่ต้องมีในการทำ Scrum
- Commitment >> ทุกคนต้องมี Commitment ของในงานของตัวเองแต่ละคน เพื่อให้สำเร็จตามเป้าของ Sprint
- Courage >> ต้องกล้าที่จะทำสิ่งที่ยาก กล้าที่จะพูด กล้าที่จะแก้ปัญหา
- Focus >> โฟกัสไปแต่งานที่ตัวเองทำ เพื่อให้สำเร็จตามเป้าของ Sprint
- Openness >> ต้องเปิดใจ แชร์ให้ทีมถ้ามีปัญหา หรือเรื่องการให้คำแนะนำต่างๆแก่ทีมเพื่อช่วยเหลือกัน
- Respect >> ให้ความเคารพความคิดเห็น การตัดสินใจ และสกิลคนในทีม ไม่ตำหนิซึ่งกันและกัน แต่เป็นการพูดเชิงให้ทุกคนมี Leaning Curve พัฒนากัน
ตำแหน่งที่ทำใน Scrum
- Scrum Master >> คนคุมทีมให้เป็นตามหลักการทำงานแบบ Agile และประสานงานทีมภายนอกต่างๆ ถ้าทีมมีปัญหาอะไร จะเป็นคนแก้ปัญหาเพื่อให้ไปถึงเป้าหมายเร็วที่สุด เปรียบเสมือนเป็นโค้ชในทีม
- Product Owner >> คนกำหนดทิศทาง Product, จัด ฺBacklog และจัด Priority งานที่จะทำก่อนส่งให้พัฒนา เพื่อ Ensure ว่าที่สิ่งที่เราพัฒนาสามารถตอบโจทย์ลูกค้าได้จริง ใครยังไม่เห็นภาพ ลองไปดูการทำงานของ Product Owner ในคลิปนี้ได้ครับ
- Dev Team>> คนพัฒนา Product ที่จะทำให้สิ่งที่อยู่ Backlog ที่เป็นสิ่งวาดฝันออกมาเป็นจริง
โดยพวก Characteristics ต่างๆที่เหมาะกับทำงาน 3 ตำแหน่งนี้ Google ได้ฝากบทความในลิงก์ให้ไปอ่านเพิ่มเติมครับ เผื่อใครอยากลองมาเบนสาย จะได้รู้ว่าคุณสมบัติเราเหมาะกับตำแหน่งที่เราสนใจหรือเปล่า
Week 3
อาทิตย์นี้ก็จะถึงคิวอธิบายการนำ Scrum ไปใช้ โดยมีสอนให้ใช้ Asana ด้วยครับ ซึ่งศัพท์ที่ควรรู้ครับ
Product Backlog
Task งานเก็บไว้ในคิวเพื่อเอาไปให้ Dev พัฒนาต่อ โดยหลักๆเขาจะมีวิธีจัด Priority ประมาณนี้ฮะ ก็คือให้ใส่สิ่งที่อยากทำเข้าไปในช่อง Description ครับ แล้วก็ใส่ค่าช่อง Value ว่าฟีเจอร์นี้สำคัญขนาดไหน และ Estimate เป็นการใส่ไว้ว่าเราต้องใช้ Effort ลงแรงมากขนาดไหนในงานนั้น โดยเบื้องต้นให้เราเลือกทำงานที่สำคัญที่สุดก่อนครับ ส่วนเรื่องเวลาให้เอามาเกลี่ยตามศักยภาพของทีม ถ้าสมมติทีมเรามีศักยภาพทำงานได้แค่ 30 แต้มต่อ Sprint ก็เลือกทำเป็นข้อ 1, 3 ก่อนใน Sprint แรกนี้ครับ (21+8<29 เราจะไม่ใส่เกินครับ เพราะ มันจะเกินศักยภาพของทีม และทำให้ Quality งานที่ส่งมอบด้อยลงครับ ใครงงทำว่าไม ให้ไปอ่านในกฏเหล็ก Agile 12 ข้ออีกทีครับ)
ส่วนใครอยากหาความรู้เรื่องเรื่องนีเชิงลึกขึ้น สามารถไปอ่านต่อได้ที่ลิงก์ข้างล่างนี้
User Story
เรื่องราวของ User ที่เล่าว่าเขาต้องการอะไรสั้นๆ โดยให้ประกอบด้วยโครงสร้าง 3 ส่วน ได้แก่
- ใครเป็นคนทำ?
- ทำอะไร?
- มีประโยชน์อะไร?
เช่น [ลูกค้า] [ต้องการซื้อขายผ่านช่องทางออนไลน์] [เพื่อที่เขาจะสามารถซื้อสินค้าได้ทุกที ทุกเวลา]
Epic
การรวมหลาย User Story มามัดรวมกัน กลายเป็น Epic
Acceptance Criteria
สิ่งที่เราจะออกมา เพื่อให้ตอบโจทย์ User Story หรือฟีเจอร์ที่เราจะทำนั่นเอง เช่น
1) สามารถดูข้อมูลสินค้าได้
2) สามารถเลือกสินค้าเข้าตะกร้า
3) สามารถสั่งซื้อสินค้าได้
ถ้าเอาทุกข้อมารวมก็ตามภาพด้านบน โดยสรุปข้อนี้ Resource ที่ทำงานใช้ได้แค่ 30 แต้มสูงสุด เป้า Sprint แรกของเราก็คือทำข้อ 1, 3 ก่อนนะครับ (21+8 < 30) เรียงลำดับ Value ตามความสำคัญ แล้วก็ทำข้อ 2, 4 ใน Sprint ถัดไป (13+17=30) โดยถ้าของใน Sprint แรกไม่เสร็จก็ต้องเอามาทบต่อที่ Sprint 2 แล้วอาจต้องตัดงานออกที่เคยคิดจะทำไปไปบางส่วนไม่ให้แต้มเกิน เพื่อให้เหมาะสมกับ Resource ของทีม ด้วยคุณภาพคงเดิมครับ
เผื่อใครอยากลองเล่น Asana ที่ในคอร์สสอน สามารถกดลิงก์ได้ข้างล่างนี้ครับ ซึ่ง Tool ตัวที่คล้ายกับ Asana ก็จะมี Jira ครับ
ส่วนวิธีนับ Effort Estimate ว่างานต้องใช้แรงทำประมานเท่าไร เอาจริงมีหลายวิธีครับ เช่น
- Planning Poker >> ใช้เลข Fibonacci 0, 1, 2, 3, 5, 8, 13,….
- Dot Voting
- The Bucket System
- Large/Uncertain/Small
- Ordering Method
- Affinity Mapping
ในคอร์สนี้จะใช้ Planning Poker นะครับ ส่วนข้ออื่นสามารถลองไปค้นหาข้อมูลเพิ่มเติมใน Google ได้ครับ
ต่อไปก็จะเป็นเรื่อง Tool ที่ใช้บ่อยๆใน Scrum นะครับ
- ฺBurn Down Chart >> ใช้พวกวัดงานที่ทำออกมาได้แต่ละ Sprint นะครับ ว่าตอนนี้ทำได้มากกว่าเป้า หรือต่ำกว่าเป้า
- Kanban Board >> เบื้องต้นถ้าไม่ใช่ Post it ก็ใช้บน Software Management Tool ที่มีฟีเจอร์นี้ก็ได้ครับ เช่น Treallo
- Software Management Tool เช่น Jira, Asana, Treallo
- Collaboration Tool อื่นๆ เช่น Google doc, Spreadsheet, Slide
Week 4
อาทิตย์นี้กลับมาเรื่องภาพรวมของ Agile อีกทีครับ อันนี้ก็เป็นศัพท์ที่ต้องรู้ในการวาง Plan ใช้วิธี Agile โดยเขามองเป็น Top Down ครับ เริ่มจาก
- Value Road Map >> ภาพใหญ่ว่าต้องการทำ Product อะไรบ้าง ให้ทีมเห็น Vision ภาพรวม
- Product Vision >> Product ที่ทำคืออะไร เป้าหมายคืออะไร และทำให้ใคร
- Product Road Map >> ภาพรวม High Level ในการพัฒนา Product
- Release Plan >> แผนที่จะออกฟีเจอร์เป็นรอบๆ
ตอนทำ Release Plan ตัว Scrum Master, Product Owner และ Dev Team ต้องมีการวางแผนร่วมกันเสมอนะครับ และต้องอิงกับ Product Road Map รวมถึงปริมาณงานต้องแบ่งให้ทีมแต่ละช่วงให้เหมาะสม ไม่หนักหรือน้อยจนเกินไปครับ และต้องพร้อมที่จะเปลี่ยนแปลงเมื่อพบแนวทางที่ดีกว่า ตามที่เคยเขียนในกฏเหล็กของ Agile 12 ข้อเลย ซึ่งเรื่องการ Change Requirement อันนี้ก็ใช้ Concept คลาสสิคเดิมครับสามเหลี่ยม Triple Constraint ใช้ได้ทุกที่ ทุกเวลา
นอกจากนี้ในอาทิตย์นี้ผู้สอนก็มีสอนพื้นฐานให้รู้จักกับ DevOps ด้วยครับ โดย DevOps เป็นอีกหนึ่ง Framework ของ Agile โดยการผสานระหว่าง IT Development กับ IT Operation ครับ หรือกล่าวง่ายๆ มันคือ หลักการที่จะทำให้เราสามารถพัฒนาและส่งมอบ Product ให้ไวและมีคุณภาพ รวมถึงต้นทุนต่ำที่สุด โดยปกติก็คือจะใช้เป็นพวกระบบ Automation เข้ามาช่วยแก้ปัญหาการ Build, Test, Release, Deploy ที่เป็นแบบอัตโนมัติแทนคนทั้งหมด ใครอยากศึกษาเพิ่มเติม Google เขาก็บอกให้ไปอ่านลิงก์นี้ครับ
- How to Combine DevOps and Agile
- Agile vs DevOps: What’s the Difference?
- The Convergence of Scrum and DevOps
นอกจากนั้นในคอร์สก็มีพูดคร่าวๆเกี่ยวกับ Framework ของ Agile อีกหลายตัวครับก็ลองไปศึกษาต่อกันได้
- Scaled Agile Framework (SAFe)
- Scrum of Scrums
- Large-Scale Scrum (LeSS)
- Disciplined Agile Delivery (DAD)
สุดท้ายในคอร์สก็มีสอนสัมภาษณ์งานด้าน Agile ด้วยครับ ก็ลองไปเรียนกันดูได้ฮะ
สรุปส่งท้าย
จบไปแล้วครับเรื่อง Agile เอาจริงเรื่อง Agile ยังมีรายละเอียดอีกเยอะมากเลยนะครับ ถ้าใครสนใจสามารถไปศึกษาเพิ่มเติมได้ในคอร์สอื่นๆทั่วไปฮะ หรือไปลองใช้ตอนทำงานจริงเลยก็ดี โดยก็อย่างที่เห็นจากเนื้อหาเลยครับว่า Agile มันมีกฏเหล็กที่ต้องปฏิบัติต่างๆมากมาย ซึ่งผมว่ามันไม่ใช่ธรรมชาติ Culture ของคนไทยสักเท่าไร จึงไม่น่าแปลกใจเลยที่มีหลายองค์กรที่พยายามใช้ Agile แต่สุดท้ายไม่สำเร็จ ซึ่งการที่เราจะ Implement Agile ให้สำเร็จนั้น ผมย้ำเสมอว่า “การเปลี่ยนมาใช้ Agile มันไม่ใช่แค่การเปลี่ยนวิธีการทำงาน เป็นคำ Buzz Word ที่สวยหรู แต่ต้องเปลี่ยนถึงระดับ Culture ของทั้งทีม จนไปถึงระดับองค์กร เลย”
ก็ตอนต่อไปนะครับ จะไปตอนสุดท้ายของคอร์ส Google PM นี้ ซึ่งจะเป็นการ Wrap Up เนื้อหาตั้งแต่ตอนที่ 2–4 รวบเอามาทำเคสตั้งแต่เริ่มทำ Project จนปิด Project เลย ถ้าเราทำได้ จะเป็นสิ่งที่พิสูจน์ว่าเราสามารถเอาเนื้อหาที่เรียนมาใช้ได้จริง ก็สามารถไปอ่านต่อได้ที่ลิงก์ข้างล่างครับ ตอนนี้ก็ขอจบเพียงเท่านี้ ขอบคุณครับ :)
