Please enable JavaScript.

Coggle requires JavaScript to display documents.

การพัฒนาซอฟต์แวร์แบบ Agile - Coggle Diagram

- - - - ทีมนักพัฒนาซอฟต์แวร์เข้าถึงผู้เชี่ยวชาญได้ง่าย
      - ทีมงานมีความเชื่อใจกัน และอิสระในการพูด
      - มีการทำงานแบบสะท้อนกลับ
      - มุ่งเพัฒนาซอฟต์แวร์อย่างมีประสิทธิภาพ
      - ทีมนักพัฒนาซอฟต์แวร์สามารถสื่อสารกับลูกค้าหรือผู้ใช้อย่างใกล้ชิด
      - ส่งมอซอฟต์แวร์ให้ลูกค้าบ่อยและรวดเร็ว
    - - การสื่อสารเป็นไปได้ยาก เนื่องจากเวลาว่างไม่ตรงกัน
      - มีกฏระข้อบังคับมาก ทำให้นักพัฒนาซอฟต์แวร์มีความเข้าใจไม่ตรงกัน
      - ใช้ทีมงานจำนวนมาก มีค่าใช้จ่ายสูง
  - - - การคาดคะเน (Speculation)
      - การเรียนรู้ (Learning)
        
        การทบทวนเชิงเทคนิคอย่างเป็นทางการ (Formal Technical Review)
        
        การตรวจสอยภายหลัง (Postmortem)
        
        กลุ่มเฉพาะทาง (Focus Group)
      - การร่วมมือ (Collaboration)
      - ข้อดี
        
        เหมาะสำหรับโครงการซอฟต์แวร์ที่มีความซับซ้อน
        
        องค์กรควบคุมความเสี่ยงในการปฏิบัติงานของนักพัฒนาซอฟต์แวร์ได้
        
        องค์กรควบคุมคุณภาพซอฟต์แวร์ได้ทุกขั้นตอนการผลิต และประเมินผลงานของนักพัฒนาซอฟต์แวร์เสมอ
      - ข้อเสีย
        
        นักพัฒนาซอฟต์แวร์ที่มีความเห็นไม่ตรงกัน ทำให้การทำงานเป็นทีมยาก
        
        นักพัฒนาซอฟต์แวร์มีทักษะและความชำนาญต่างกัน ทำให้ใช้เวลาในการเรียนรู้นานและมีค่าใช้จ่ายสูง
        
        ใช้ทีมงานจำนวนมาก ค่าใช้จ่ายสูง
  - - - เป็นแบบจำลองที่มีลักษณะการทำงานเหมือนกับแบบจำลองเวียนก้นหอย แบ่งเป็น 5 ขั้นตอน
        
        การใช้งาน (Deploying)
        
        การพัฒนา (Developing)
        
        การวางแผน (Planning)
        
        การนึกคิด (Envisioning)
        
        การสนับสนุน (Stabilizing)
    - - คือ การจัดทำแผนล่วงหน้าในกรณีที่มีความเสี่ยงที่เกิดขึ้น เช่น กำหนดการล่าช้า ขอบเขตเพิ่มมากขึ้น อัตราการลาออกของพนักงานสูง ข้อกำหนดซอฟต์แวร์ไม่ชัดเจน ความสามารถการผลิตงานน้อย เป็นต้น
    - - คือแบบจำลองที่สนับสนุนการพัฒนาซอฟต์แวร์และใช้ทีมงานขนาดเล็กจากหลากหลายสาขามาทำงานร่วมกันประกอบด้วย 6 บทบาท ดังนี้
        
        การพัฒนา
        
        การทดสอบ
        
        การจัดการโปรแกรม
        
        การจัดการการปล่อยซอฟต์แวร์
        
        การจัดการผลิตภัณฑ์
        
        ประสบการณ์ผู้ใช้
    - - ลูกค้าหรือผู้ใช้เปลี่ยนแปลงความต้องการและสื่อสารกับทีมงานได้อย่างรวดเร็ว
      - มอบอำนาจการตัดสินใจให้กับทีมงานพัฒนาซอฟต์แวร์
      - มีคำแนะนำและเทคนิคการบริหารโครงการ
      - เหมาะสำหรับโครงการซอฟต์แวร์ขนาดเล็ก ใช้ทีมงานขนาดเล็ก
      - ทีมงเรียนรู้จากประสบการณ์โดยตรง
    - - ไม่เหมาะกับโครงการขนาดใหญ่
      - ลูกค้าเปลี่ยนแปลงความต้องการบ่อย
  - - - การออกแบบ
      - การเขียนโปรแกรม
      - การวางแผน
      - การทดสอบระบบ
    - - เหมาะกับโครงการขนาดเล็ก,กลาง
      - ออกแบบระบบอย่างเรียบง่าย
      - เปลี่ยนแปลงโปรแกรมตามความต้องการของลูกค้าได้ตลอดเวลา
      - นักเขียนโปรแกรมไม่เสียเวลาในการปรับโปรแกรมตั้งแต่ต้น
      - นักเขียนโปรแกรมและผู้ใช้มีความสัมพันธ์ที่ดีต่อกัน
      - สามารถออกแบบ SW ใหม่ได้บ่อยครั้ง
    - - ขาดการวางแผนและการจัดการคุณภาพ
      - ความขัดแย้งเรื่องเงินทุน เมื่อความต้องการเปลี่ยนแปลงบ่อย
      - มุ่งเน้นการเขียนโปรแกรมไม่เน้นที่การออกแบบ
      - นักพัฒนาซอฟต์แวร์ต้องทำงานเป็นคู่
      - การสร้างกรณีทดสอบต้องอาศัยผู้เชี่ยวชาญและทำได้ยาก
  - - - ทีมงาน
        
        เจ้าของงาน (Product Owner)
        
        ทีมสครัม (Scrum Team)
        
        หัวหน้าสครัม (Scrum Master)
      - กระบวนการทำงาน
        
        ขั้นตอนการวนซ้ำ (Sprint Phase)
        
        สครัมประจำวัน (Daily Scrum)
        
        ความต้องการ (Backlog)
      - การสาธิตและการประเมินผลงาน
    - - สามารถปรับกระบวนการ ให้เข้ากับการเปลี่ยนแปลงได้
      - มีการแบ่งงานเป็นกลุ่มหรือส่วนงานให้ขึ้นต่อกันน้อยที่สุด เพื่อลดความผิดพลาด
      - ซอฟต์แมีหลายเวอร์ชั่น ทำให้ตรวจสอบ ทดสอบ บันทึกและพัฒนาต่อได้
      - จัดทเฉพาะเอกสารที่สำคัญ
      - ทีมงานเล็ก ใช้เทคนิคพัฒนาแบบไม่เป็นทางการ ประหยัดค่าใช้จ่าย
      - สามารถทำงานเสร็จเร็วขณะที่มีความไม่แน่นอนเกิดขึ้น
      - ส่งมอซอฟต์แวร์ให้ลูกค้าในเวลาที่รวดเร็ว
    - - มีการทำงานแบบ ทีมงานข้ามสาย(Cross-Function Team) อาจเกิดปัญหาได้
      - มีบทบาทที่แน่นอน ไม่ยืดหยุ่นในการทำงานบางองค์กรที่มีผู้จัดการโครงการ
      - ความต้องการขนาดใหญ่ถูกแบ่งเป็นงานย่อยมากๆทำให้เห็นภาพรวมไม่ชัดเจน
      - การเปลี่ยนแปลงขอบเขตทำให้เกิดค่าใช้จ่ายที่สูงขึ้น
  - - - กานำไปใช้
      - การจัดการโครงแบบ
      - การทดสอบ
      - การบริหารโครงการ
      - การเขียนโปรแกรม
      - สภาพแวดล้อม
      - การสร้างแบบจำลอง
    - - มุมมองในแนวตั้ง
        
        จะแสดงให้เห็นถึงกลุ่มกิจกรรมที่เกิดขึ้น ซึ่งจะถูกแบ่งกลุ่มออกตามวิธีการหรือลักษณะของการทำงานของกิจกรรมนั้นๆ
      - มุมมองในแนวนอน
        
        จะแสดงให้เห็นถึงเวลาและวงจรการพัฒนาในแต่ละช่วงของโครงการ
- - - - ไม่สามารถเปลี่ยนแปลงความต้องการได้
      - ต้องเข้าใจความต้องการของลูกค้าตั้งแต่เริ่มต้น ซึ่งอาจจะไม่ชัดเจน
      - ใช้นักพัฒนาซอฟต์แวร์จำนวนมากและทำงานหนัก
      - มีระเบียบวิธีชัดเจน
      - ใช้เวลาในการพัฒนาซอฟต์แวร์นาน
      - ต้องทำเอกสารจำนวนมากและใช้เวลานาน
    - - การพัฒนาซอฟต์แวร์เพื่อนำไปใช้งานจริงมากกว่าการทำเอกสาร
      - การทำงานร่วมกับลูกค้าหรือผู้ใช้มากกว่า การเจรจาต่อรองตามสัญญา (Contract)
      - การให้ความสำคัญกับผู้ปฏิบัติงาน เน้นความถนัดแต่ละบุคคล เน้นปฏิสัมพันธ์
      - การแก้ไขซอฟต์แวร์ตามการเปลี่ยนแปลงความต้องการของผู้ใช้ มากกว่าการปฏิบัติตามแผน
- - - - ระดับ 4 จัดการ
        
        การจัดการกระบวนการเชิงปริมาณ
        
        การจัดการคุณภาพของซอฟต์แวร์
      - ระดับ 3 นิยาม
        
        การทบทวนชิ้นงานโดยเพื่อนร่วมงาน
        
        การนิยามกระบวนการขององค์กร
        
        การจัดซอฟต์แวร์รวมกัน
        
        การประสานงานระหว่างกลุ่ม
        
        จุดรวมกระบวนการเชิงองค์กร
        
        โปรแกรมการฝึกอบรม
        
        วิศวกรรมผลิตภัณฑ์ซอฟต์แวร์
      - ระดับ 5 เหมาะที่สุด
        
        การจัดการการเปลี่ยนแปลงด้านเทคโนโลยี
        
        การจัดการการเปลี่ยนแปลงกระบวนการ
        
        การป้องกันข้อบกพร่อง
      - ระดับ 2 ทำซ้ำ
        
        การจัดการความต้องการ
        
        การวางแผนโครงการซอฟต์แวร์
        
        การจัดการผู้รับช่วงหรือว่าจ้าง
        
        การรับประกันคุณภาพซอฟต์แวร์
        
        การจัดการโครงการแบบซอฟต์แวร์
        
        การติดตามโครงการซอฟต์แวร์และความผิดพลาด
      - ระดับ 1 เริ่มต้น
        
        อาศัยความสามารถของทีมงานเป็นหลัก
        
        ไม่มีกวางแผน
        
        ไม่สามารถประเมินคุณภาพซอฟต์แวร์ได้
        
        กระบวนการพัฒนาซอฟต์แวร์ไม่เป็นระบบ
        
        ทำงานขึ้นกับหัวหน้า
        
        ไม่มีการจัดทำเอกสาร
        
        ผู้บริหารไม่สนใจการเปลี่ยนกระบวนการ
  - - - การประเมิน
        
        การปรับปรุงกลยุทธ์
        
        กำหนดความสามารถ
  - - - กำหนดมาตรฐานในการดำเนินงาน
      - ปรับปรุงประสิทธิภาพด้านต้นทุน กำหนดการ คุณภาพและความเสี่ยง
    - - สั่งสมประสบการณ์
      - วิเคราะห์และทำนายผล
    - - กำหนดนโยบายชัดเจน
      - กระบวนการเป็นระบบ มีแบบแผนและทำซ้ำได้
      - จัดทำเอกสารอย่างเป็นขั้นตอน
    - - ปรับปรุงกระบวนการอย่างต่อเนื่อง
      - มีองค์ความรู้ และปรับปรุงการเรียนรู้
      - มีประสิทธิภาพทุกด้าน
      - มีคุณภาพสูง และความเสี่ยงต่ำ
    - - ไม่มีระเบียบวิธีที่แน่นอน ไม่เป็นระเบียบ
      - มีความเสี่ยงสูง