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 สามารถมีวิธีแก้ไขปัญหาได้หลายวิธี แล้วเราควรเลือกวิธีใด เพื่อนำมาตอบสนองความต้องการหรือแก้ไขปัญหานั้น

สามารถเข้าไปอ่านเพิ่มเติมได้ที่

ตำแหน่งที่สำคัญในอไจล์

1. Stakeholders ผู้มีส่วนเกี่ยวข้องกับผลิตภัณฑ์, ผู้ใช้งาน, เจ้าของบริษัท
2. Product Owner (PO) ผู้ออกแบบผลิตภัณฑ์เพื่อตอบสนอง Stakeholders
3. 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 ทีมต่างๆ

การจัดลำดับความสำคัญของการพัฒนาแบบอไจล์

1. งานสำคัญและด่วน งานที่ต้องทำทันที ถ้าไม่เสร็จอาจเกิดปัญหาใหญ่ เช่น แก้ไขข้อผิดพลาดที่ทำให้ผู้ใช้งานไม่สามารถใช้งานได้ แก้ไขระบบล่ม
2. งานสำคัญและไม่ด่วน งานที่ต้องหาเวลาทำ เช่น วางแผนสปรินท์ พัฒนาฟีเจอร์ใหม่ ขยายหรืออัพเกรดระบบเดิม
3. งานไม่สำคัญและด่วน งานที่ให้คนอื่นทำแทนได้ เช่น ตอบข้อสงสัยของผู้ใช้งาน
4. งานไม่สำคัญและไม่ด่วน งานที่ไม่ควรมี หรือทำในเวลาว่าง เช่น การประชุมที่เราไม่จำเป็นต้องเข้า

เมื่อพัฒนาในส่วนที่ 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) จะพยายามควบคุมให้ทีมทำงานได้ตามขั้นตอนในเวลาที่วางแผนไว้

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

หากทำผลิตภัณฑ์มีคุณภาพและเสร็จเร็วแต่ไม่มีคนอยากใช้ ก็จะเป็นเพียงสิ่งประดิษฐ์ที่ไม่มีใครต้องการ

หากทำผลิตภัณฑ์ดีและมีคุณภาพแต่ออกมาช้า ก็ไม่มีคนอยากใช้งานแล้ว กลายเป็นผลิตภัณฑ์ล้าสมัย

ทั้งสามฝ่ายจึงต้องร่วมมือกัน หาจุดที่เหมาะสมที่ส่งผลกระทบต่อผู้ใช้ ต่อธุรกิจ และต้นทุนในการพัฒนาได้ลงตัวที่สุด

จุดสิ้นสุดของการพัฒนาผลิตภัณฑ์แบบอไจล์

สรุปการทำงานแบบอไจล์

อไจล์ คือ วัฒนธรรมการทำงานที่นำ Feedback

จากผู้ที่เกี่ยวข้องมาปรับปรุง

1.ผลิตภัณฑ์ 2.กระบวนการการทำงาน

Keyword ที่สำคัญคือ

1. วัฒนธรรมการทำงาน คนในองค์กรจะต้องมีวัฒนธรรมการทำงานที่เน้นการปรับปรุงพัฒนาอยู่ตลอดเวลา
2. Feedback การฟังเสียงตอบรับจากสิ่งที่เราลงมือทำ
3. Stakeholders ผู้ที่วิจารณ์ผลงานหรือกระบวนการการทำงาน ซึ่งรวมทั้งผู้ใช้งาน เจ้าของบริษัท ทีมพัฒนา
4. ปรับปรุง การนำผลตอบรับมาปรับปรุง ผลิตภัณฑ์ และ กระบวนการการทำงานให้ดีขึ้นเรื่อยๆ

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

ที่มา : https://medium.com/fastwork-engineering/agile-%E0%B8%84%E0%B8%B7%E0%B8%AD%E0%B8%AD%E0%B8%B0%E0%B9%84%E0%B8%A3-%E0%B9%80%E0%B8%A3%E0%B8%B4%E0%B9%88%E0%B8%A1%E0%B9%83%E0%B8%8A%E0%B9%89%E0%B8%87%E0%B8%B2%E0%B8%99%E0%B8%AD%E0%B8%A2%E0%B9%88%E0%B8%B2%E0%B8%87%E0%B9%84%E0%B8%A3-ab749306d96e