Agile คืออะไร เริ่มใช้งานอย่างไร
Agile Methodology คือแนวคิดในการทำงาน(ไม่ใช่รูปแบบหรือขั้นตอนการทำงาน) และไม่จำกัดว่าใช้ได้สำหรับการพัฒนาผลิตภัณฑ์ในสายซอฟต์แวร์(Software) เท่านั้น โดยอไจล์ให้ความสำคัญในการสื่อสารกับผู้เกี่ยวข้องทุกฝ่าย และการปรับปรุงพัฒนาผลิตภัณฑ์อยู่ตลอด เพื่อตอบสนองผู้ใช้งาน
ทำสกรัม (Scrum) ไม่เท่ากับทำอไจล์ (Agile)
หลายคนอาจเคยได้ยินคำว่าสกรัม(Scrum) มาก่อน อาจคิดว่าทำตามสกรัมก็จะได้การทำงานแบบอไจล์ นั่นเป็นความคิดที่ไม่ถูกต้องเสียทีเดียว เพราะบางส่วนของสกรัมไม่เกี่ยวกับอไจล์ด้วยซ้ำไป เพียงแต่เป็นตัวช่วยให้การทำงานแบบอไจล์ที่ทำอยู่แล้วเป็นอไจล์ที่เป็นขั้นตอนที่ชัดเจนและสมบูรณ์มากขึ้น ซึ่งหากเราไม่ได้มีทำงานแบบอไจล์แต่เอาสกรัมมาใช้ก็ไม่ได้แปลว่าเราจะได้การทำงานแบบอไจล์
หลายๆที่อาจมี Standup Meeting, Sprint Planning, Sprint Review, ฯลฯ ทำครบทุกอย่างแต่ทำไมยังรู้สึกว่าทำงานได้ช้าและมีการติดขัดในแต่ละขั้นตอนไปหมด หรืออาจเสียเวลาทำงานไปกับการวางแผนและประชุมตามสกรัมมากกว่าก่อนมีการใช้สกรัมด้วยซ้ำ ในบทความนี้จะอธิบายหลักการที่แท้จริงของอไจล์เพื่อให้เข้าใจแนวคิดที่ถูกต้อง (แต่จะยังไม่พูดถึงการนำไปปฏิบัติ)
หลักการทำงานแบบอไจล์
- Individuals and interactions over processes and tools เน้นการสื่อสารและปฏิสัมพันธ์กันระหว่างคน มากกว่าเครื่องมือต่างๆที่นำมาช่วย
- Working software over comprehensive documentation เน้นทำผลิตภัณฑ์ มากกว่าการทำเอกสาร
- Customer collaboration over contract negotiation เน้นตอบสนองผู้ใช้งาน มากกว่าแค่ทำตามสัญญา
- Responding to change over following a plan เน้นการปรับปรุงพัฒนา มากกว่าการทำตามแผนที่วางเอาไว้
User Story ความต้องการของผู้ใช้
ผลิตภัณฑ์ถูกพัฒนาขึ้นเพื่อแก้ไขปัญหาหรือตอบสนองความต้องการของผู้ใช้ เราจึงนำมาระบุให้ชัดเจนในรูปแบบของ User Story ซึ่งประกอบไปด้วย 4 ส่วน
- As a เพื่อระบุบทบาทของผู้ใช้งาน
- I want เพื่อระบุว่าผู้ใช้งานต้องการอะไร
- So that เพื่อระบุว่าผู้ใช้งานจะได้รับอะไร
- Acceptance criteria เกณฑ์วัดผลว่าสามารถตอบสนองความต้องการได้แล้ว
เช่น
- As a buyer, I want to find lowest price, So that I see the lowest price product.
- Acceptance criteria คือผู้ใช้เห็นสินค้าราคาต่ำสุด
การพัฒนาผลิตภัณฑ์ก็อาจออกแบบเป็นฟีเจอร์เป็นปุ่มกดให้สินค้าราคาต่ำที่สุดเด้งขึ้นมา
แต่ต่อมาผู้ใช้งานไม่อยากเห็นสินค้าราคาต่ำสุดเพียงชิ้นเดียว อยากเห็นสินค้าราคาต่ำชิ้นอื่นๆด้วย
- As a buyer, I want to see lower price product before higher price product, So that I see products in increasing order.
- Acceptance criteria คือผู้ใช้เห็นสินค้าราคาต่ำก่อนราคาสูง
การพัฒนาผลิตภัณฑ์ก็อาจออกแบบเป็นฟีเจอร์สำหรับเรียงราคาสินค้าจากต่ำไปสูง
ในแต่ละ User story สามารถมีวิธีแก้ไขปัญหาได้หลายวิธี แล้วเราควรเลือกวิธีใด เพื่อนำมาตอบสนองความต้องการหรือแก้ไขปัญหานั้น สามารถเข้าไปอ่านเพิ่มเติมได้ที่
ตำแหน่งที่สำคัญในอไจล์
- Stakeholders ผู้มีส่วนเกี่ยวข้องกับผลิตภัณฑ์, ผู้ใช้งาน, เจ้าของบริษัท
- Product Owner (PO) ผู้ออกแบบผลิตภัณฑ์เพื่อตอบสนอง Stakeholders
- Developer (Dev) ผู้พัฒนาผลิตภัณฑ์ตามที่ออกแบบไว้ให้เกิดขึ้นจริง
วิธีการทำงานแบบอไจล์
- เริ่มจาก Stakeholders มี Requiremnet(ปัญหาหรือความต้องการ) บางอย่าง
- PO อยากทำการแก้ไขปัญหาและตอบสนองความต้องการนั้น
- PO แปลง Requirement เป็น User Story เพื่อให้ Dev นำไปพัฒนาผลิตภัณฑ์
- Dev ออกแบบและพัฒนาผลิตภัณฑ์ตาม User Story ที่ได้รับ โดยมีตัววัดว่าสำเร็จคือ Acceptance Criteria
- Dev จะส่งมอบผลิตภัณฑ์ให้กับ Stakeholders นำไปใช้งาน
- Stakeholders อาจมี Feedback หรือความต้องการเพิ่มเติม
- วัดผลสิ่งที่ทำ จาก Feedback ที่ได้รับมา
- PO แปลงผลที่ได้เป็น User Story ใหม่ เพื่อให้ Dev นำไปปรับปรุงหรือพัฒนาผลิตภัณฑ์เพิ่มเติม
การทำอไจล์คือการลด Feedback Loop ดังกล่าวให้สั้นที่สุดเพื่อจะได้นำมาปรับปรุงได้อย่างรวดเร็ว
นอกจากนี้ในความเป็นจริง Stakeholders มีความต้องการมากมายทำให้ User Story มีจำนวนมาก ในขณะที่ Dev มีความสามารถในการพัฒนาผลิตภัณฑ์จำกัด ทำให้ไม่สามารถตอบสนองความต้องการทั้งหมดนั้นได้ PO จึงต้องเป็นคนคอยกำหนดว่าจะทำอะไรก่อนทำอะไรหลัง หรือจะไม่ทำอะไรเพราะประโยชน์ที่จะได้รับไม่คุ้มค่ากับการลงมือทำ
ตำแหน่งหน้าที่ในทีมพัฒนาผลิตภัณฑ์แบบอไจล์
Stakeholders
- ผู้มีส่วนเกี่ยวข้องกับผลิตภัณฑ์ ผู้ใช้งาน(End user), ผู้บริหารของบริษัท, บริษัทคู่สัญญาที่มาจ้างงานบริษัทเรา
- หลายบริษัทที่รับงาน Outsource อาจมีปัญหาว่าผู้ใช้งานกับคนตรวจรับงานต้องการผลิตภัณฑ์ที่ต่างกัน ทางที่ถูกต้องเราควรยึดผู้ใช้งานจริงเป็นหลักแต่ต้องหาข้อมูลมาสนับสนุนให้ได้ ว่าถ้าทำแบบนี้แล้วผู้ใช้งานจะใช้งานได้เร็วขึ้นกว่าแบบที่คนตรวจงานอยากได้เท่าไร ผลงานรวมต่อวันได้มากขึ้นเท่าไร มีประโยชน์อะไรจะได้รับมากขึ้น เป็นต้น
Product Owner
- เป็นคนอยากทำบางอย่างเพื่อแก้ไขปัญหาหรือตอบสนองความต้องการของ Stakeholders (Requirement)
- เปลี่ยน Requirement เป็น User Story และ Acceptance Criteria
- ทำให้ทุกฝ่ายเห็นภาพของ User Story ตรงกัน
- จัดลำดับความสำคัญของงานโดยคำนึงถึง 1. User Impact 2. Business Impact 3. Development Cost สำหรับข้อ 1 และ ข้อ 2 สามารถรู้ได้จากการทำวิจัย ส่วนข้อ 3 นั้นต้องถามทีมพัฒนาว่าพัฒนายากหรือง่าย ใช้เวลาในการพัฒนาเท่าไร
- แปลง User Story ที่มีขนาดใหญ่ให้มีขนาดเล็กลง และชัดเจนมากขึ้น
- ต้อง ปฎิเสธ Requirement บางอย่าง ไม่ปล่อยให้มี Backlog ค้างมากเกินไป
- รักษาสมดุลระหว่างการพัฒนาฟีเจอร์ใหม่ การแก้ไขปัญหาเดิม(Bug) การอัพเกรดระบบเดิมให้ดียิ่งขึ้น(Optimize)
- ในกรณีที่มีผลิตภัณฑ์หลายตัวแต่ทีมพัฒนามีจำกัด ต้องรักษาสมดุลในการให้ความสำคัญระหว่างการดูแลผลิตภัณฑ์เก่าและผลิตภัณฑ์ใหม่
- ลดความเสี่ยงทางธุรกิจ เทคโนโลยี ต้นทุนในการพัฒนา และเวลา โดยคำนึงถึงโอกาสที่จะเกิดขึ้น และผลกระทบที่จะได้รับหากเกิดขึ้น
- วางแผนการพัฒนาทั้งระยะสั้นและระยะยาว
- แต่ไม่มีอำนาจในการกำหนดว่าทีมพัฒนาต้องพัฒนาอย่างไร
Developer
- ประกอบไปด้วยตำแหน่งย่อย ดังนี้ Business Analyst, UX Designer, UI Designer, Developer, Quality Assurance, Operation โดยหนึ่งคนอาจมีบทบาทได้มากกว่า 1 ตำแหน่ง
- พัฒนาผลิตภัณฑ์โดยยึดตาม User Story
- งานจะเสร็จเมื่อ User Story นั้น ผ่าน Acceptance Criteria
- พัฒนา Unit Test และ Automate Test สำหรับ Acceptance Criteria
- พัฒนาระบบ Continuous Integration และ Continuous Delivery เพื่อให้สามารถรวบรวมผลิตภัณฑ์จากทีมต่างๆและส่งมอบให้ผู้ใช้งานได้ง่ายและรวดเร็ว
- พัฒนา Internal Tools เพื่อช่วยในการทำงานให้ง่ายและเร็วมากขึ้น
- พัฒนาทักษะเทคนิคคอล โดยทำวิจัยหรือ Proof of Concept (POC) ก่อนลงมือพัฒนาจริง
- ออกแบบและพัฒนา Architecture ให้เหมาะสมและดีขึ้น
- รู้ขีดจำกัดของตัวเองและทีม เช่น Story Point Limited per Sprint
ผลงานของตำแหน่งในทีมพัฒนาผลิตภัณฑ์แบบอไจล์
- Stakeholders แสดงความต้องการ(Requirement)
- Product Owner (PO) นำ Requirement มาแปลงเป็น User Story
- Business Analyst (BA) นำ User Story มาขยายเป็น Behavior Driven Development (BDD) เพื่อให้เข้าใจพฤติกรรมของผู้ใช้งาน และหา Solution ให้กับ User Story นั้น โดยคำนึงถึงการใช้งานส่วนใหญ่ทั้งแบบปกติและไม่ปกติ (Happy and Unhappy Case)
- UX Designer (UX) นำ BDD มาออกแบบพฤติกรรมการใช้งาน ความรู้สึกในการใช้งาน User Journey และ Wireframe
- UI Designer (UI) นำ Wireframe มาออกแบบหน้าตาการใช้งานที่ผู้ใช้จะเห็น
- Developer (Dev) นำ Design ที่ออกแบบไว้มาพัฒนาเป็นผลิตภัณฑ์จริง
- Quality Assurance (QA) นำ BDD มาขยาย Happy และ Unhappy Case ให้ครอบคลุมพฤติกรรมการใช้งานทุกรูปแบบที่เป็นไปได้ให้ได้มากที่สุด นำผลิตภัณฑ์มาทดสอบให้เป็นไปตาม BDD / Test Case ที่ออกแบบไว้
- Operation (Ops) นำผลิตภัณฑ์ที่ผ่านการทดสอบแล้วไปส่งมอบให้ผู้ใช้สามารถเข้ามาใช้งานได้
อไจล์ที่ประกอบด้วยหลายทีม
ในแต่ละทีมพัฒนาจะต้องมี PO เป็นของทีมตัวเอง (PO 1 คน อาจดูแลหลายทีมได้) PO ของแต่ละทีมจะต้องมีการคุยเพื่อแลกเปลี่ยนข้อมูลกัน เพื่อลดการทำงานที่ซ้ำซ้อน หรือถ้ามีหลายทีมมาก อาจมีหัวหน้า PO ขึ้นมาอีกคนเพื่อประสานงานระหว่าง PO ทีมต่างๆ
การจัดลำดับความสำคัญของการพัฒนาแบบอไจล์
- งานสำคัญและด่วน งานที่ต้องทำทันที ถ้าไม่เสร็จอาจเกิดปัญหาใหญ่ เช่น แก้ไขข้อผิดพลาดที่ทำให้ผู้ใช้งานไม่สามารถใช้งานได้ แก้ไขระบบล่ม
- งานสำคัญและไม่ด่วน งานที่ต้องหาเวลาทำ เช่น วางแผนสปรินท์ พัฒนาฟีเจอร์ใหม่ ขยายหรืออัพเกรดระบบเดิม
- งานไม่สำคัญและด่วน งานที่ให้คนอื่นทำแทนได้ เช่น ตอบข้อสงสัยของผู้ใช้งาน
- งานไม่สำคัญและไม่ด่วน งานที่ไม่ควรมี หรือทำในเวลาว่าง เช่น การประชุมที่เราไม่จำเป็นต้องเข้า
เมื่อพัฒนาในส่วนที่ 2 มากๆ จะทำให้งานในส่วนที่ 1 และส่วนอื่นๆ ลดน้อยลงไปด้วย
สิ่งที่ควรจะได้จากการทำอไจล์
- ลดความเข้าใจผิดพลาด หากคนในทีมเข้าใจงานคนละอย่าง อาจทำให้ผลลัพธ์ของงานไม่ตอบสนองต่อเป้าหมายที่ต้องการ จึงควรสื่อสารกันเรื่อยๆ เพื่อให้ทุกคนเข้าใจตรงกันอยู่เสมอ
- ลดกระบวนการที่ล่าช้า การติดต่อสื่อสารผ่านคนกลางควรเปลี่ยนให้ Dev ได้คุยกับ PO หรือ User โดยตรง และอัพเดทสิ่งที่คุยมาให้ทุกคนในทีมทราบและเข้าใจตรงกัน
- ลดการทำงานที่ซ้ำซ้อนกัน งานบางอย่างอาจมีการทำซ้ำซ้อนกับทีมอื่น งานที่เคยมีคนทำไว้แล้ว ควรสามารถหยิบมาใช้หรือพัฒนาต่อยอดได้ โดยไม่ต้องเริ่มใหม่ทั้งหมด
ก่อนเริ่มทำ: PM จัดลำดับความสำคัญของชิ้นงานว่าชิ้นไหนสำคัญกว่า
ตอนเริ่มทำ: Dev ติดต่อกับ PO หรือ User โดยตรง เพื่อลดการสื่อสารที่ล่าช้าและการเข้าใจผิดพลาด
สมดุลของการพัฒนาผลิตภัณฑ์แบบอไจล์
ทรัพยากรในการพัฒนาผลิตภัณฑ์มีจำกัดจึงต้องคำนึงถึงปัจจัยต่างๆ ทั้งต้นทุน คุณภาพ และเวลา ให้ออกมาตอบสนองผู้ใช้และตลาดได้อย่างทันเวลา โดย
- Developer (Dev) — quality & scalable สร้างผลิตภัณฑ์มีคุณภาพที่สุด การบำรุงรักษาและพัฒนาต่อยอดผลิตภัณฑ์ทำได้ง่าย
- Product Owner (PO) — usable & low maintenance cost ควบคุมผลิตภัณฑ์ให้มีคุณภาพตามมาตราฐาน ตอบสนองผู้ใช้ใด้มากที่สุด และการบำรุงรักษาผลิตภัณฑ์ทำได้ง่าย
- Project Manager (PM) — on time & on budget ใช้ทรัพยากรที่มีเพื่อส่งมอบผลิตภัณฑ์ให้ทันในเวลาที่กำหนด หรือ Scrum Master (SM) จะพยายามควบคุมให้ทีมทำงานได้ตามขั้นตอนในเวลาที่วางแผนไว้
หากทำผลิตภัณฑ์ดีและเสร็จเร็วแต่ไม่มีคุณภาพ ก็จะเป็นได้เพียงต้นแบบ ไม่สามารถใช้งานจริงได้
หากทำผลิตภัณฑ์มีคุณภาพและเสร็จเร็วแต่ไม่มีคนอยากใช้ ก็จะเป็นเพียงสิ่งประดิษฐ์ที่ไม่มีใครต้องการ
หากทำผลิตภัณฑ์ดีและมีคุณภาพแต่ออกมาช้า ก็ไม่มีคนอยากใช้งานแล้ว กลายเป็นผลิตภัณฑ์ล้าสมัย
ทั้งสามฝ่ายจึงต้องร่วมมือกัน หาจุดที่เหมาะสมที่ส่งผลกระทบต่อผู้ใช้ ต่อธุรกิจ และต้นทุนในการพัฒนาได้ลงตัวที่สุด
จุดสิ้นสุดของการพัฒนาผลิตภัณฑ์แบบอไจล์
กราฟแสดงความสัมพันธ์ระหว่าง Value ในช่วงเวลาต่างๆของการพัฒนาผลิตภัณฑ์ด้วยอไจล์ โดย Value ในที่นี้ประกอบไปด้วย Team Knowledge และ Customer and Business Value
การพัฒนาผลิตภัณฑ์ด้วยอไจล์จะแบ่งเป็น 3 ช่วงหลักๆ
- ช่วงเริ่มต้นของการพัฒนา จะโฟกัสไปที่ความรู้(Knowledge) ของทีมเป็นหลัก เนื่องจากเป็นผลิตภัณฑ์ใหม่ ทีมอาจจะยังประเมินขนาดของงานและเวลาที่จะใช้พัฒนาได้ไม่แม่นยำ รวมถึงอาจต้องใช้เทคโนโลยีใหม่ที่ไม่คุ้นเคยในการพัฒนาผลิตภัณฑ์ด้วย จึงเน้นให้ทีมมีความสามารถมากขึ้นในช่วงนี้ อาจมีการทำ Prototype หรือ Proof of Concept เพื่อหาเทคโนโลยีที่เหมาะสมที่จะนำไปพัฒนาผลิตภัณฑ์ รวมถึงการหาความต้องการของผู้ใช้งานและตลาดที่แท้จริง
- ช่วงกลางของการพัฒนา จะโฟกัสไปที่ Customer and Business Value คือหลังจากที่ทีมมีความรู้ในการพัฒนาผลิตภัณฑ์ในระดับหนึ่งแล้ว และเข้าใจความต้องการของผู้ใช้และตลาดมากขึ้นแล้ว จะมุ่งพัฒนาผลิตภัณฑ์ให้ตอบสนองให้เกิดคุณค่ากับผู้ใช้ให้มากที่สุด
- ช่วงปลายของการพัฒนา จะเป็นการพัฒนาผลิตภัณฑ์เพิ่มเติมที่อาจไม่ได้เพิ่มคุณค่าต่อผู้ใช้มากนัก เปรียบเสมือนเป็นฟีเจอร์แถม จนถึงจุดหนึ่งที่ไม่คุ้มค่าที่จะพัฒนาเพิ่มเติมก็จะทำการตัดจบ เพื่อนำทรัพยาการไปพัฒนาผลิตภัณฑ์อื่นต่อไป แต่จะต้องยังคงดูแลระบบหรืออัพเกรดระบบเพิ่มเติมจนกว่าจะปิดการใช้งานผลิตภัณฑ์นี้
การใช้งานอไจล์ให้มีประสิทธิภาพ
- รับ Feedback ให้เร็วที่สุด เพื่อนำมาปรับปรุงผลิตภัณฑ์และการทำงาน
- ใช้ต้นทุนให้น้อยที่สุด เพื่อให้ได้คุณค่ามากที่สุด
- ยอมรับความจริงและข้อผิดพลาดที่เกิดขึ้น เพื่อให้สามารถนำไปปรับปรุงได้
- มีการพัฒนากระบวนการการทำงานและระบบเดิมด้วย ไม่ใช่ทำแต่ของใหม่
- คนในทีมต้องรู้ว่าทำส่วนนี้เพื่ออะไร ไม่ใช่ทำเพราะ Guildline บอกให้ทำ
สรุปการทำงานแบบอไจล์
อไจล์ คือ วัฒนธรรมการทำงานที่นำ Feedback
จากผู้ที่เกี่ยวข้องมาปรับปรุง
1.ผลิตภัณฑ์ 2.กระบวนการการทำงาน
Keyword ที่สำคัญคือ
- วัฒนธรรมการทำงาน คนในองค์กรจะต้องมีวัฒนธรรมการทำงานที่เน้นการปรับปรุงพัฒนาอยู่ตลอดเวลา
- Feedback การฟังเสียงตอบรับจากสิ่งที่เราลงมือทำ
- Stakeholders ผู้ที่วิจารณ์ผลงานหรือกระบวนการการทำงาน ซึ่งรวมทั้งผู้ใช้งาน เจ้าของบริษัท ทีมพัฒนา
- ปรับปรุง การนำผลตอบรับมาปรับปรุง ผลิตภัณฑ์ และ กระบวนการการทำงานให้ดีขึ้นเรื่อยๆ
หากองค์กรของคุณมีคนบอกว่า แบบนี้ไม่ดีน่าจะลองปรับเปลี่ยนเป็นอีกแบบ แต่หัวหน้าดันไม่พอใจและหาว่ามาวิจารณ์เขา ทำมาเป็นสิบปีไม่เห็นมีปัญหาอะไร องค์กรของคุณจะไม่มีทางเป็นอไจล์
สกรัม (Scrum)
การทำอไจล์ให้แต่ละขั้นตอนมีความชัดเจนมากยิ่งขึ้น สามารถการวัดผลการดำเนินงาน ตรวจสอบสิ่งที่ลงมือทำและนำมาปรับปรุงพัฒนา จะมีเครื่องมือที่นิยมนำมาใช้งาน เรียกว่า สกรัม(Scrum) สามารถเข้าไปอ่านเพิ่มเติมได้ที่
