Agile

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 ความต้องการของผู้ใช้

  • 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. Product Owner (PO) ผู้ออกแบบผลิตภัณฑ์เพื่อตอบสนอง Stakeholders
  2. Developer (Dev) ผู้พัฒนาผลิตภัณฑ์ตามที่ออกแบบไว้ให้เกิดขึ้นจริง

วิธีการทำงานแบบอไจล์

  • 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

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

Product Owner

  • เปลี่ยน 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

  • พัฒนาผลิตภัณฑ์โดยยึดตาม 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

ผลงานของตำแหน่งในทีมพัฒนาผลิตภัณฑ์แบบอไจล์

  • 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) นำผลิตภัณฑ์ที่ผ่านการทดสอบแล้วไปส่งมอบให้ผู้ใช้สามารถเข้ามาใช้งานได้

อไจล์ที่ประกอบด้วยหลายทีม

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

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

เมื่อพัฒนาในส่วนที่ 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

Visitors: 606,451