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 และส่วนอื่นๆ ลดน้อยลงไปด้วย

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

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

• Developer (Dev) จะพยายามสร้างผลิตภัณฑ์ที่ดีที่สุด

• Product Owner (PO) จะพยายามทำผลิตภัณฑ์เพื่อตอบสนองผู้ใช้ให้มากที่สุด

• Project Manager (PM) จะพยายามส่งมอบผลิตภัณฑ์ให้ทันในเวลาที่กำหนด หรือ 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 ที่สำคัญคือ

1. วัฒนธรรมการทำงาน คนในองค์กรจะต้องมีวัฒนธรรมการทำงานที่เน้นการปรับปรุงพัฒนาอยู่ตลอดเวลา

2. Feedback การฟังเสียงตอบรับจากสิ่งที่เราลงมือทำ

3. Stakeholders ผู้ที่วิจารณ์ผลงานหรือกระบวนการการทำงาน ซึ่งรวมทั้งผู้ใช้งาน เจ้าของบริษัท ทีมพัฒนา

4. ปรับปรุง การนำผลตอบรับมาปรับปรุง ผลิตภัณฑ์ และ กระบวนการการทำงานให้ดีขึ้นเรื่อยๆ

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

สกรัม (Scrum)

การทำอไจล์ให้แต่ละขั้นตอนมีความชัดเจนมากยิ่งขึ้น สามารถการวัดผลการดำเนินงาน ตรวจสอบสิ่งที่ลงมือทำและนำมาปรับปรุงพัฒนา จะมีเครื่องมือที่นิยมนำมาใช้งาน เรียกว่า สกรัม(Scrum)