กระบวนการซอฟต์แวร์แบบ Agile และรูปแบบ Waterfall

กระบวนการซอฟต์แวร์แบบ Agile

• นำเสนอโดย Wiwat V.

แบบจำลองลำดับเชิงเส้น (Linear Sequential Model)

• วงจรชีวิตแบบคลาสสิกหรือแบบจำลอง Waterfall ประกอบด้วยกิจกรรมต่างๆ ได้แก่ การสร้างแบบจำลองระบบ/ข้อมูลและวิศวกรรม, การวิเคราะห์ความต้องการของซอฟต์แวร์, การออกแบบ, การสร้าง Code, การทดสอบ และการสนับสนุน

ภาพรวมทั่วไปของกระบวนการซอฟต์แวร์

• คำจำกัดความ (Definition) มุ่งเน้นไปที่ "อะไร" (WHAT)
• การพัฒนา (Development) มุ่งเน้นไปที่ "อย่างไร" (HOW)
• การบำรุงรักษา (Maintenance) มุ่งเน้นไปที่ "การเปลี่ยนแปลง" (Change)

รูปแบบ Waterfall

• ถูกกล่าวถึงโดย Royce ตั้งแต่ปี 1970
• ขั้นตอนต่างๆ แสดงให้เห็นว่ามีการไหลต่อเนื่อง (cascading) จากขั้นตอนหนึ่งไปยังอีกขั้นตอนหนึ่ง
• แต่ละขั้นตอนควรจะเสร็จสมบูรณ์ก่อนที่จะเริ่มขั้นตอนถัดไป
• ถูกใช้เป็นพื้นฐานสำหรับสิ่งที่ต้องส่งมอบ (deliverables) ในสัญญาของกระทรวงกลาโหมสหรัฐฯ ซึ่งกำหนดไว้ใน DOD2167-A
• สิ่งที่ต้องส่งมอบ (Deliverables) จะถูกสร้างขึ้นในแต่ละกระบวนการ
• รูปแบบ Waterfall มีประโยชน์ในการช่วยเหลือผู้พัฒนาในการวางแผนสิ่งที่พวกเขาต้องทำ

ข้อเสียของรูปแบบ Waterfall

• แสดงให้เห็นว่าแต่ละเฟสสิ้นสุดลงเมื่อมีการสร้างบางสิ่ง (artifact) แต่ไม่ได้ให้ข้อมูลเชิงลึกว่าแต่ละกิจกรรม (activity) เปลี่ยน artifact หนึ่งไปสู่อีก artifact หนึ่งได้อย่างไร
• ไม่มีคำแนะนำว่าจะจัดการกับการเปลี่ยนแปลงผลิตภัณฑ์และกิจกรรมอย่างไร
• การแสดงผลิตภัณฑ์ให้ลูกค้าเห็นนั้นสายเกินไป

ปัจจัยที่ขัดขวางข้อกำหนดเบื้องต้นที่น่าเชื่อถือ

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

รูปแบบ Prototyping

• เริ่มต้นด้วยการรับฟังลูกค้า
• สร้างและแก้ไข Mock-up
• Customer test drives mock-up
• แนะนำ Mock-up ของแต่ละฟังก์ชันที่จะพัฒนา

รูปแบบ Spiral

• รูปแบบนี้จะเน้นที่การประเมินความเสี่ยง (Risk Assessment) ในแต่ละขั้นตอนของการพัฒนา

แนวทางปฏิบัติขั้นพื้นฐานบางประการสำหรับกระบวนการซอฟต์แวร์

• Timeboxing: กำหนดช่วงเวลาในการพัฒนา (1-6 สัปดาห์ต่อ timebox)
• Adaptive: ปรับตัวตามข้อเสนอแนะจากงานก่อนหน้า จากผู้ใช้, การทดสอบ, ผู้พัฒนา ฯลฯ
• Iterative: อธิบายและควบคุมทุกการเคลื่อนไหวที่เราทำในเกือบทุกด้านของการเปลี่ยนความคิดให้เป็นผลิตภัณฑ์
• Incremental: “คุณลักษณะนั้นจะพร้อมใช้งานในส่วนที่เพิ่มขึ้นถัดไปของผลิตภัณฑ์”

Agile คืออะไร?

• Agile = ว่องไว แข็งขัน กระฉับกระเฉง
• Agile = การตอบสนองที่รวดเร็วและยืดหยุ่นต่อการเปลี่ยนแปลง

Manifesto for Agile Software Development

• เน้นที่บุคคลและการมีปฏิสัมพันธ์กัน มากกว่ากระบวนการและเครื่องมือ
• เน้นที่ซอฟต์แวร์ที่ใช้งานได้ มากกว่าเอกสารที่ครอบคลุม
• เน้นที่การทำงานร่วมกันกับลูกค้า มากกว่าการเจรจาสัญญา
• เน้นที่การตอบสนองต่อการเปลี่ยนแปลง มากกว่าการทำตามแผน

12 หลักการของ Agile Software

• ความสำคัญสูงสุดคือการสร้างความพึงพอใจให้กับลูกค้าผ่านการส่งมอบซอฟต์แวร์ที่มีคุณค่าอย่างรวดเร็วและต่อเนื่อง
• ยอมรับการเปลี่ยนแปลงข้อกำหนด แม้ในช่วงท้ายของการพัฒนา กระบวนการ Agile จะควบคุมการเปลี่ยนแปลงเพื่อสร้างความได้เปรียบในการแข่งขันให้ลูกค้า
• ส่งมอบซอฟต์แวร์ที่ใช้งานได้บ่อยๆ จากช่วงสองสัปดาห์ถึงสองเดือน โดยมีความต้องการในช่วงเวลาที่สั้นกว่า
• ผู้คนทางธุรกิจและผู้พัฒนาต้องทำงานร่วมกันทุกวันตลอดโครงการ
• สร้างโครงการโดยมีพื้นฐานจากบุคคลที่มีแรงจูงใจ ให้สภาพแวดล้อมและการสนับสนุนที่พวกเขาต้องการ และเชื่อใจพวกเขาให้ทำงานให้เสร็จ
• วิธีการที่มีประสิทธิภาพและประสิทธิผลมากที่สุดในการถ่ายทอดข้อมูลไปและภายในทีมพัฒนาคือการสนทนาแบบเห็นหน้ากัน
• ซอฟต์แวร์ที่ใช้งานได้คือตัวชี้วัดหลักของความคืบหน้า
• กระบวนการ Agile ส่งเสริมการพัฒนาที่ยั่งยืน ผู้สนับสนุน ผู้พัฒนา และผู้ใช้ควรรักษาระดับการทำงานที่คงที่ไปเรื่อยๆ ได้อย่างไม่สิ้นสุด
• การใส่ใจอย่างต่อเนื่องในความเป็นเลิศทางเทคนิคและการออกแบบที่ดี ช่วยเพิ่มความคล่องตัว
• ความเรียบง่าย (Simplicity) คือศิลปะของการเพิ่มปริมาณงานที่ไม่ต้องทำให้มากที่สุด ถือเป็นสิ่งจำเป็น
• สถาปัตยกรรม ข้อกำหนด และการออกแบบที่ดีที่สุดเกิดขึ้นจากทีมที่จัดการตนเอง
• ในช่วงเวลาปกติ ทีมจะพิจารณาถึงวิธีการที่จะมีประสิทธิภาพมากขึ้น แล้วปรับและปรับพฤติกรรมของตนเองตามนั้น

Agile Documentation

• เน้นที่การเดินทางแบบเบาๆ, เอกสาร Agile ควรกระชับ, เติมเต็มวัตถุประสงค์, อธิบายข้อมูลที่ไม่น่าจะเปลี่ยนแปลง, อธิบาย "สิ่งที่ดีที่ควรรู้", มีลูกค้าเฉพาะและอำนวยความสะดวกในการทำงานของลูกค้านั้น, มีความถูกต้อง สอดคล้อง และละเอียดเพียงพอ และจัดทำดัชนีอย่างเพียงพอ
• เหตุผลที่ถูกต้องในการทำเอกสาร ได้แก่ ผู้มีส่วนได้ส่วนเสียในโครงการของคุณต้องการ, เพื่อกำหนดรูปแบบสัญญา, เพื่อสนับสนุนการสื่อสารกับกลุ่มภายนอก และเพื่อคิดให้รอบคอบ

ค่าใช้จ่ายของ BRUF แบบดั้งเดิม (Big Requirements Up Front)

• โครงการที่ "ประสบความสำเร็จ" ก็ยังมีของเสียจำนวนมาก โดย 45% ของฟังก์ชันที่ส่งมอบไม่เคยถูกใช้งานจริง

Big Requirements Up Front (BRUF) Approach

• BRUF เป็นแนวทางที่สร้างข้อกำหนดโดยละเอียดในช่วงต้นของวงจรชีวิตการพัฒนาซอฟต์แวร์
• ต้องมีกระบวนการจัดการการเปลี่ยนแปลงเพื่อหลีกเลี่ยง "การเพิ่มขอบเขต" ตลอดทั้งโครงการ
• Big design up front (BDUF) คือแนวทางที่คุณพยายามระบุสถาปัตยกรรมของคุณโดยละเอียดก่อนที่จะเริ่มเขียนโค้ด

Agile Software Requirements Management

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

Active Stakeholder Participation

• ผู้มีส่วนได้ส่วนเสียในโครงการควรให้ข้อมูลอย่างทันท่วงที, ตัดสินใจอย่างทันท่วงที, และมีส่วนร่วมในการสร้างแบบจำลองที่มุ่งเน้นธุรกิจ

Model With Others

• การสร้างแบบจำลองเทียบเท่ากับการเขียนโปรแกรมแบบคู่
• คุณมีความเสี่ยงอย่างแท้จริงเมื่อใดก็ตามที่ใครบางคนทำงานด้วยตัวเอง
• หลายหัวดีกว่าหัวเดียว

ประสิทธิภาพของเทคนิคการรวบรวมข้อกำหนด

• การมีส่วนร่วมของผู้มีส่วนได้ส่วนเสียอย่างแข็งขัน: ผู้มีส่วนได้ส่วนเสียอยู่ที่ไซต์งาน
• การออกแบบแอปพลิเคชันร่วมกัน (JAD)
• กลุ่มเป้าหมาย
• การสังเกตการณ์
• การสัมภาษณ์แบบเห็นหน้ากัน
• การสัมภาษณ์ทางอิเล็กทรอนิกส์
• การวิเคราะห์ Code เดิม
• การอ่าน

Agile Approach

• แบบดั้งเดิมกิจกรรมจะเป็นแบบครั้งเดียว แต่แบบ Agile จะเป็นกิจกรรมต่อเนื่อง

Agile Modeling Methodology

• Scrum โดย Ken Schwaber และ Jeff Sutherland, 1990
• eXtreme Programming (XP) โดย Kent Beck, 1996
• Feature Driven Development (FDD) โดย Jeff De Luca, 1999
• Crystal Clear: A Human-Powered Methodology for Small Teams โดย Alistair Cockburn, 2004

Scrum

• Scrum เป็นกระบวนการแบบ Agile ที่ช่วยให้มุ่งเน้นไปที่การส่งมอบมูลค่าทางธุรกิจสูงสุดในเวลาที่สั้นที่สุด
• ช่วยให้สามารถตรวจสอบซอฟต์แวร์ที่ใช้งานได้จริงอย่างรวดเร็วและซ้ำๆ (ทุกสองสัปดาห์ถึงหนึ่งเดือน)
• ธุรกิจกำหนดลำดับความสำคัญ ทีมจัดการตนเองเพื่อกำหนดวิธีที่ดีที่สุดในการส่งมอบคุณสมบัติที่มีลำดับความสำคัญสูงสุด
• ทุกๆ สองสัปดาห์ถึงหนึ่งเดือน ใครๆ ก็สามารถเห็นซอฟต์แวร์ที่ใช้งานได้จริงและตัดสินใจว่าจะเผยแพร่แบบที่เป็นอยู่หรือดำเนินการปรับปรุงต่อไปในการ Sprint อื่น

ที่มาของ Scrum

• Jeff Sutherland ได้เริ่มต้น Scrum ครั้งแรกที่ Easel Corp ในปี 1993
• IDX และผู้คนกว่า 500 คนกำลังทำ Scrum
• Ken Schwaber ได้นำเสนอ Scrum ในงาน OOPSLA 95 ร่วมกับ Sutherland
• Ken Schwaber เป็นผู้แต่งหนังสือสามเล่มเกี่ยวกับ Scrum
• Mike Beedle มี Scrum patterns ใน PLOPD4
• Ken Schwaber และ Mike Cohn ร่วมกันก่อตั้ง Scrum Alliance ในปี 2002 ซึ่งเดิมอยู่ใน Agile Alliance

องค์กรที่ใช้ Scrum

• Microsoft
• Yahoo
• Google
• Electronic Arts
• High Moon Studios
• Lockheed Martin
• Philips
• Siemens
• Nokia
• Capital One
• BBC
• Intuit
• Intuit
• Nielsen Media
• First American Real Estate
• BMC Software
• Ipswitch
• John Deere
• Lexis Nexis
• Sabre
• Salesforce.com
• Time Warner
• Turner Broadcasting
• Oce

Scrum ถูกนำไปใช้สำหรับ

• ซอฟต์แวร์เชิงพาณิชย์
• การพัฒนาภายในองค์กร
• การพัฒนาตามสัญญา
• โครงการราคาคงที่
• แอปพลิเคชันทางการเงิน
• แอปพลิเคชันที่ได้รับการรับรอง ISO 9001
• ระบบฝังตัว
• ระบบ 24x7 ที่มีเวลาทำงาน 99.999%
• the Joint Strike Fighter
• การพัฒนาวิดีโอเกม
• ระบบที่ได้รับการอนุมัติจาก FDA ซึ่งมีความสำคัญต่อชีวิต
• ซอฟต์แวร์ควบคุมดาวเทียม
• เว็บไซต์
• ซอฟต์แวร์พกพา
• โทรศัพท์มือถือ
• แอปพลิเคชันสวิตชิ่งเครือข่าย
• แอปพลิเคชัน ISV
• แอปพลิเคชันที่ใหญ่ที่สุดบางส่วนที่ใช้งานอยู่

ลักษณะ

• ทีมที่จัดการตนเอง
• ผลิตภัณฑ์มีความคืบหน้าในชุดของ "sprints" เป็นเวลาหนึ่งเดือน
• ข้อกำหนดจะถูกบันทึกเป็นรายการในรายการ "product backlog"
• ไม่ได้กำหนดแนวทางปฏิบัติทางวิศวกรรมที่เฉพาะเจาะจง
• ใช้กฎ generative เพื่อสร้างสภาพแวดล้อมแบบ Agile สำหรับการส่งมอบโครงการ
• Scrum เป็นหนึ่งใน "กระบวนการแบบ Agile"

Agile Manifesto

• ให้ความสำคัญกับบุคคลและการมีปฏิสัมพันธ์ มากกว่ากระบวน และเครื่องมือ
• ให้ความสำคัญกับซอฟต์แวร์ที่สามารถใช้งานได้ มากกว่าเอกสารครอบคลุมรายละเอียดทั้งหมด
• ให้ความสำคัญกับการร่วมมือกับลูกค้า มากกว่าการต่อรองสัญญา
• ให้ความสำคัญกับการตอบสนองต่อการเปลี่ยนแปลง มากกว่าการทำตามแผนที่วางไว้

ระดับเสียงของโครงการ

• มีความซับซ้อนสูงหากเทคโนโลยีและความต้องการอยู่ในความไม่แน่นอน

Scrum สรุป

• ในแต่ละ Sprint:
  • มีเป้าหมายของ Sprint
  • Sprint Backlog
  • จะมีการผลิต Product Increment ที่สามารถส่งมอบได้ (Potentially Shippable Product Increment)

Sprints

• โครงการ Scrum มีความคืบหน้าในชุดของ "sprints"
  • คล้ายคลึงกับการทำซ้ำ Extreme Programming
• ระยะเวลาโดยทั่วไปคือ 2-4 สัปดาห์หรือหนึ่งเดือนตามปฏิทิน
• ระยะเวลาคงที่นำไปสู่จังหวะที่ดีขึ้น
• ผลิตภัณฑ์ได้รับการออกแบบ เขียนโค้ด และทดสอบระหว่าง Sprint

ลำดับเทียบกับการพัฒนาที่ทับซ้อนกัน

• Scrum เน้นที่การทำทุกอย่างทีละเล็กละน้อยตลอดเวลา (Overlapping Development) มากกว่าการทำสิ่งหนึ่งให้เสร็จก่อนแล้วค่อยทำอย่างอื่น (Sequential)

การเปลี่ยนแปลงระหว่าง Sprint

• ไม่มีการเปลี่ยนแปลงเกิดขึ้นในระหว่าง Sprint
• ควรวางแผนระยะเวลาของ Sprint ให้สอดคล้องกับระยะเวลาที่คุณสามารถรักษาสภาพแวดล้อมที่ไม่เปลี่ยนแปลงได้

โครงสร้าง Scrum

• บทบาท (Roles):
  • Product owner
  • ScrumMaster
  • Team
• พิธีการ (Ceremonies)
  • Sprint planning
  • Sprint review
  • Sprint retrospective
  • Daily scrum meeting
• สิ่งประดิษฐ์ (Artifacts)
  • Product backlog
  • Sprint backlog
  • Burndown charts

Product Owner

• กำหนดฟีเจอร์ของผลิตภัณฑ์
• ตัดสินใจเกี่ยวกับวันที่เผยแพร่และเนื้อหา
• รับผิดชอบต่อผลกำไรของผลิตภัณฑ์ (ROI)
• จัดลำดับความสำคัญของคุณสมบัติตามมูลค่าตลาด
• ปรับคุณสมบัติและลำดับความสำคัญใหม่ทุกครั้งที่ทำซ้ำตามต้องการ
• ยอมรับหรือปฏิเสธผลการทำงาน

ScrumMaster

• เป็นตัวแทนของการจัดการต่อโครงการ
• รับผิดชอบในการประกาศใช้ Scrum values และแนวทางการปฏิบัติ
• กำจัดอุปสรรค
• ตรวจสอบให้แน่ใจว่าทีมทำงานได้อย่างสมบูรณ์และมีประสิทธิภาพ
• ช่วยให้เกิดความร่วมมืออย่างใกล้ชิดในทุกบทบาทและหน้าที่
• ปกป้องทีมจากการรบกวนภายนอก

Team

• โดยทั่วไปมี 5-9 คน

Amazon Jeff Bezos’ Two Pizza Team

ถ้า Basic two pizza team size = 6 แล้ว communication links = 15 ถ้า team size = 12 then links = 66

Sprint Planning Meeting

• Team capacity

Sprint Prioritization

• วิเคราะห์และประเมิน Product Backlog
• เลือก Sprint Goal

Sprint Planning

• ตัดสินใจวิธีการเพื่อให้บรรลุ Sprint Goal (Design)
• สร้าง Sprint Backlog (Task) จาก Product Backlog Items (User stories / Features)
• ประมาณการ Sprint Backlog เป็นชั่วโมง

Sprint Planning

• ทีมคัดเลือกงานต่าง ๆ จาก Product Backlog ที่พวกเขาสามารถ Commit ได้ว่าจะทำให้งานเสร็จสมบูรณ์
• Sprint Backlog ถูกสร้างขึ้น
  • งาน (Tasks) ถูกระบุ และแต่ละงานถูกประมาณค่า (Estimated 1-16 ชั่วโมง)
  • ทำงานร่วมกัน ไม่ได้ทำคนเดียวโดย Scrum Master การออกแบบระดับสูงจะถูกพิจารณา

Daily Scrum

• พารามิเตอร์
  • รายวัน 15-นาที ยืนขึ้น
    • สถานที่เดียวกัน (แนะนำ)
• ไม่ใช่สำหรับการแก้ปัญหา
  • ทั้งโลกได้รับเชิญชวน
    • เฉพาะสมาชิกในทีม, Scrum Master, Product Owner ที่สามารถพูดคุย
• ช่วยหลีกเลี่ยงการประชุมที่ไม่จำเป็นอื่น ๆ

สิ่งที่ทุกคนต้องตอบคำถาม 3 ข้อ

• เราได้ทำอะไรไปแล้วเมื่อวานนี้?
• เราจะทำอะไรวันนี้?
• มีอะไรเป็นอุปสรรคต่อคุณหรือไม่?
  • เหล่านี้ไม่ใช่ Status สำหรับ Scrum Master
    • พวกเขาคือคำมั่นสัญญาต่อหน้าเพื่อนร่วมงาน

Sprint Review

• Team นำเสนอสิ่งที่พวกเขาสำเร็จในระหว่าง Sprint
• โดยปกติจะอยู่ในรูปแบบของการ Demo ฟีเจอร์ใหม่, รูปแบบทางสถาปัตยกรรม
• ไม่เป็นทางการ - กฎเวลาเตรียมการ 2-ชั่วโมง - ไม่มีสไลด์
• ทั้งทีมมีส่วนร่วม
  • เชิญโลกทั้งใบ
• ปัญหา "Pig และ Chicken"

Sprint Retrospective

• พิจารณาเป็นระยะว่าอะไรคืออะไรและอะไรที่ไม่ใช่
• โดยปกติ 15-30 นาที ทำเสร็จหลังจากทุก Sprint ทีมทั้งหมดมีส่วนร่วม - ScrumMaster - Product Owner - ทีม - ลูกค้าและคนอื่น ๆ สามารถมีส่วนร่วม

เริ่ม / หยุด / ทำต่อ

• ทีมงานทั้งหมดจะรวมตัวกันและหารือว่าพวกเขาต้องการอะไร
• Start Doing
  • Stop Doing
• ดำเนินการต่อ
  • นี่เป็นเพียงหนึ่งในหลายวิธีในการทำ Sprint Retrospective

Product Backlog

• Product Backlog - เป็นข้อกำหนด (The Requirements)
  • A List of all desired work on the project
    • ตามหลักการ, แต่ละรายการได้แสดงออกถึงคุณค่าของผู้ใช้งานหรือลูกค้า
      • ถูกจัดความสำคัญโดย Product Owner.
    • ทำใหม่ในช่วงเริ่มต้นของแต่ละ Sprint

Agile Estimates

-ชอบการวัดขนาด มากกว่าการวัดเวลา
-ชอบ Relative score มากกว่า Absolute score
-การใช้ "STory Point" ที่สัมพันธ์กัน (บ่งชี้ขนาด) ของผู้ใช้