[ATH2016] CMMI – Waterfall – Agile – Scrum

Blog นี้ ผมแตกประเด็นมาจาก สรุปงาน Agile Thailand 2016 โดยในตอนนี้ ผมขอรวม Slot 2 อัน ในช่วงเช้า เข้าด้วยกันเลยครับ โดยมีของ

• SPI - CMMI vs Agile ของคุณ นิ้ง
• Agile & Scrum. How to get start ของคุณ ปลา ครับ

This slideshow requires JavaScript.

ก่อนที่เราเข้าประเด็นกัน สิ่งที่เราต้องรู้กันก่อนคำศัพท์ แต่ละคำ คือ อะไร ครับ

• CMMI (Capability  Maturity  Model  Integration) - คือ มาตรฐานที่เอาไว้บอกถึงความเชื่่อมั่น และคุุณภาพของกระบวนกาพัฒนา Software ทำให้เป็นระบบ และยืดหยุ่นต่อการปรับเปลี่ยนได้
  • ตัว CMMI มี 5 Level (เอาคร่าวๆ ก่อนนะครับ จริง CMMI มันมีแผนผัง อารมณ์เดียวกับ Skill Tree ใน Game ครับ)
    • Level 1 - มี Product ก็ผ่านแล้วครับ
    • Level 2 - Repeatable การกำหนด Basic Project Management งานหลักๆ ที่ใช้ในการพัฒนา Software
    • Level 3 - Defined การกำหนดรูปแบบของการทำงานเข้ามา และนำไปใช้กับทั้งองค์กร
    • Level 4 - Managed มีการเก็บสถิติการทำงาน และ วัดผลการทำงาน
    • Level 5 - Optimizing / Continuous Process Improvement นำข้อมูลที่ได้มีวิเคราะห์หาสาเหตุ และปรับปรุงกระบวนการทำงานให้ดียิ่งขึ้น

    

  • Process Area สำหรับ CMMI ในแต่ละ Level

    

  • สำหรับองค์กรที่เอา CMMI มาใช้ จะมีหน่วยงานโผล่เข้ามา อีก 2 หน่วยครับ
    • SPI - Software Process Improvement ทำให้ Flow การทำงาน ในการสร้าง Software มันไหลลื่น และยั่งยืน
    • PPQA - Process and Product Quality Assurance เป็น Audit ตรวจสอบการทำงานในองค์กรว่ามีความเข้าใจใน CMMI ขนาดไหน
• Waterfall
  • รูปแบบการพัฒนาระบบ โดยทำที่ละขั้นตอนให้เสร็จก่อน ถึงไปงานชิ้นถัดไปได้

  

• Agile - มันเป็น Abstract Class มีรูปแบบหลักการทำงานมาให้และ ตาม manifesto  มี 4 ข้อ ได้แก่
  • Individuals and Interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

  This slideshow requires JavaScript.
• Scrum - มันเป็น Implementation ของ Agile เป็น Framework รูปแบบการทำงานที่ตอบรับกับ Consept ของ Agile ครับ

พอรู้ความหลายของแต่ละคำแล้ว ผมมาจับประเด็น แต่ละอันครับ

• CMMI กับ Agile มันเข้ากันได้ หรือไปกันไม่ได้
  • ผมยกคำนิยามที่ผมอธิบายไว้ด้านบน "มาตรฐานที่เอาไว้บอกถึงความเชื่่อมั่น และคุุณภาพของกระบวนกาพัฒนา Software ทำให้เป็นระบบ และยืดหยุ่นต่อการปรับเปลี่ยนได้"
  • ถ้าเอา Agile มาใช้แล้วมันติดขัด เราต้องปรับ Process มันขวาง Flow ใน CMMI ให้ดีขึ้นครับ ทีมที่ดูและเรื่องนี้ คือ SPI ครับ
• Waterfall & Agile
  • Waterfall - Product ที่เรารู้ฉากจบจริงๆ ไม่มีการซ่อนเร้น (Requirement ต้องเน้นมากๆ) เช่น การ Redesign Product จาก Platform win App ไปเป็น Web Base เป็นต้นครับ
  • ใน Waterfall มี Agile ไหม
    • มีครับ ถ้างานมาแยกกันชัดเจนมาก เราสามารถทำ Agile ได้ครับ ส่วนตัวผมใช้แนวคิด Kanban Board ในการจัดการผ่านเว็บ Trello ครับ แต่ไม่ได้ทำ TDD มี Unit Test ปกติ
    • ถ้า Agile มี Waterfall อันนี้ Scrum Master ต้องหาสาเหตุแล้วนะครับ
  • แล้วถ้ายากเปลี่ยนจาก Waterfall ไปเป็น Agile หละ
    • เริ่มต้นจากทีมเล็กก่อนที่ Thomson Reuters จากจุดนั้น เมื่อมันสำเร็จ ต่อไปหาคน Support ไม่ใช้ใครที่ไหน กลุ่ม Management ในองค์กรแหละครับ - Get buy in, Get sponsor - พอมีฝ่ายสนับสนุนแล้ว เราสามารถหา Coach มาช่วยนำ (อ่าน Blog Agile Transformation ดูครับ ) ลองทำ Project สร้าง Product มาทดลองก่อนให้เห็นผล และปรับไปใช้ทั้งองค์กรครับ
• Organization Structure กับ Agile
  • หลายองค์กร มีการแยกหน่วยงานอย่างชัดเจน PM, ฺBA, DEV และ QA เป็นต้น เวลาการทำ Agile ทุก Role ต้องมามีส่วนร่วมหมด สำหรับองค์กรใช้ลักษณะนี้ อาจะต้องมีการทำ Proxy (คุยกับ Head แต่ละหน่วย) เพื่อลองสร้าง Team ครับ
• Agile & Scrum อันนี้ผมขอพูดเยอะหน่อยนะครับ

  

  • Role ที่เกี่ยวข้อง
    • Product Owner - คนที่รู้ความต้องการ (Requirement) ของงานทั้งหมดที่กำลังทำอยูู่ คนทีทำงานนี้ถ้าดีที่สุด ควรเป็น User ที่ใช้งานครับ ถัดมาเป็น PM หรือถ้า Product มันเฉพาะทางมาก เช่น พวกฝั่งการเงิน ก็จะมี BA มาเป็น PO แทนครับ สรุปสิ่งที่ต้องทำออกมาเป็น Product Back Log ครับ
    • Scrum Master - คนที่ทำหน้าที่จัดทีม เป็น Coach ค่อยดูภาพรวมครับของ Team ครับ ฝึกทักษะของสมาชิกในทีม โดยท้ายที่สุด สิ่งที่เราได้มาเป็น Cross-Functional-Team ทุกคนในทีมความสามารถใกล้เคียงกันครับ และ Scrum Master ปกป้องทีม และไกล่เกลี่ยปัญหาอย่างสร้างสรรค์ครับ ไม่ใช้ชี้ว่านนำว่าใคร ผิดถูกครับ
    • Team - กลุ่มคนที่ทำงาน เพื่อให้เราสามารถออก Product ออกมาได้ครับ ประกอบไปด้วย Developer (มองเป็นภาพรวมครับ มี SA , DEV และ QA เป็นต้นครับ เดี๋ยวท้ายที่สุด ถ้าทำได้มันเป็น  Cross-Functional-Team) จากการศึกษาทีมที่เหมาะสมควรมีขนาดประมาณ 7-9 คน แต่ไม่เกิน 14 คนครับ
  • Scrum Flow

    

    • Product Backlog - งานที่ต้องทำมัน คือ Requirement จากผู้ใช้ แต่มันยังไม่ต้องลง Detail แบบละเอียดตัว Product Backlog มี 4 แบบ
      • Features  - เขียนในรูป User Story
      • Bug - เหมือน Features  มองในมุมของคุณภาพ
      • Technical work  - งานด้านเทคนิค ไม่เกี่ยวกับความต้องการของผู้ใช้ เช่น การ Set VM, Firewall หรือ Web Server เป็นต้น
      • Research / Knowledge acquisition  - งานที่ต้องศึกษา หาข้อมูลเพิ่มเติม เพิ่มตัดสินใจ เช่น การใช้ใน ORM เลือกระหว่าง Entity Framework, nhibernate หรือ Dapper ต้องใช้ออะไร มีข้อดี-ด้อย อย่างไร
    • ** Product Backlog Grooming ** - เป็นการคุยระหว่าง Product Owner กับ Team เพื่อทำความเข้าใจในเรื่องของงานให้ตรงกัน และมี Acceptance Criteria อะไร และประเมินงานคร่าวๆ ก่อนไปทำ Sprint Plan Meeting ถ้าใหญ่ (Epic) ไปจะได้แตกงานใน Product Back Log ให้เป็นชิ้นที่เล็กลง
    • Sprint Plan Meeting วางแผนการทำงานดึง Product Back Log ออกมาทำเป็น User Story โดยต้องประมาณงานที่ทำให้จบในหนึ่ง Sprint (1 รอบการทำงาน ปกติประมาน 2 Week) เพื่อให้สร้าง Feature Product ออกมาได้ทันครับ
      • Priority
      • MVP (Minimum viable product)
      • Story point แบ่ง Task ที่ทำ เป็นระดับคะแนนของงาน ไม่ใช่ Manday นะครับ มักกำหนดเป็นเลขแบบ Fibonacci (0, 1, 1, 2, 3, 5, 8, 13) แต่ไม่ควรเกิน 13 เพราะมันงานมันต้องใหญ่มาก และอาจจจะทำให้ Sprint Fail (งานไม่เสร็จได้)
    • Sprint Back Log - ส่งที่ได้มาจาก Sprint Plan Meeting
    • ลอง Sprint วนรอบการทำงาน โดยสัก 1-2 รอบแรก เป็นการประเมิน ว่ามีศักยภาพแค่ไหนครับ ซึ่งในแต่ละวันมีการจัด Daily Scrum Meeting เพื่อให้สมาชิกในทีมมา Update ให้ Feedback ช่วยกันแก้ปัญหาครับ
    • ครบรอบ Sprint นำ Product ที่ได้ไปให้ Product Owner ทดสอบ และให้ Feedback กลับมาครับ
    • พอ Demo เสร็จคราวนี้ มีการทำ Sprint Retrospective คล้ายเป็นการ meeting แต่บอกสิ่งที่ควรปรับปรุง แก้ไขให้ดียิ่งขึ้นไปครับ ในงาน Agile ที่จัดมีช่องให้บอก Good, Bad และ Try ครับ
      • Sprint Retrospective - มองว่าเป็นการสร้าง Mindset ที่ดีให้กับ Agile ครับ
    • พอจบตรงนี้ ถ้างานใน Product Back Log ยังไม่หมด ก็วนไปทำ Sprint ถัดไปจนครบครับ

บทความนี้ดองยาวเหมือนกันร่าง ตั้งแต่วันที่ 9 แต่มาเสร็จจริงๆวันที่ 12 ในบทความผมมีการ Research หาข้อมูลเพิ่มเติม และใส่ข้อคิดเห็นส่วนตัวลงไปด้วย หากมีอะไรผิดพลาดขออภัยมา ณ ที่นี้ครับ ถ้าแจ้งมาได้ยิ่งดี ผมจะได้ปรับให้ถูกต้อง