Please enable JavaScript.
Coggle requires JavaScript to display documents.
Agile Software Development, ทำเป็นคู่ค่ะ - Coggle Diagram
Agile Software Development
Agile manifesto
Individuals and interactions
ให้ความใส่ใจกับการมีปฏิสัมพันธ์กับผู้คน
มากกว่าการทำตามคู่มือ และเครื่องมือ
Working software over comprehensive documentation
:
ซอฟแวร์ที่ใช้งานได้จริง มากกว่าเอกสารที่ครบถ้วนสมบูรณ
Customer collaboration over contract negotiation:
ร่วมมือกันทำงานไปกับลูกค้า หรือ stakeholder มากกว่าการต่อรองให้เป็นไปตามสัญญา
Responding to change over following a plan:
พร้อมที่จะเปลี่ยน มากกว่าการทำตามแผนเดิมที่วางเอาไว้
หลัก 12 ประการ
Customer satisfactio
n มุ่งเน้นทำให้ได้ตามที่ลูกค้าพึงพอใจ
Welcome changes
ตอบสนองต่อการเปลี่ยนแปลง ถึงแม้จะมาช้า หากมันจะเพิ่มขีด
ความสามารถในการแข่งขัน หรือเพิ่ม Value ให้ลูกค้าได
Speed and frequently delivery
ส่งมอบบ่อยขึ้น เร็วขึ้น ในช่วงเวลาที่สั้น
Collaboration among business people and developers
ดึงเอาทีมงานส่วนธุรกิจเข้ามาทำงานกับ นักพัฒนาฯ ให้ได้ตลอดช่วงของโครงการ
Effective communication
ใช้วิธีการสื่อสารที่ได้ผลและคุ้มค่า เน้นที่การส่งต่อข้อมูลที่ถูกต้องให้
เข้าใจตรงกัน
Empowerment, trust the team
ให้อำนาจการตัดสินใจและดำเนินงานแก่ทีม และเชื่อใจ
Good metrics
ใช้ผลของการทำงานได้ของซอฟต์แวร์เป็นตัววัดความก้าวหน้าของโครงการ
Steadiness
เรียนรู้ผ่านกระบวนการ การทำงานแบบ Agile
สร้างความยั่งยืนในการทำงานร่วมกันในองค์กร
Technical and operational excellent
ใส่ใจต่อความเป็นเลิศทางเทคนิคสร้างแบบ(design)ที่ดี
เพื่อเพิ่ม Agile ในอนาคต
Simplicity
ความง่าย คือ โฟกัสที่การพัฒนาเพิ่มส่วนฟังก์ชั่นที่ทำให้ซอฟต์แวร์ใช้งานได้
Self organized
ทีม ต้องจัดการตนเองได้
Continuous improvement
ในช่วงเวลาที่เหมาะสม ทีมสะท้อนออกมาให้เห็นว่า จะเพิ่มศักยภาพและปรับตัวเข้าหากัน เพื่อให้งานบรรลุเป้าหมายได้ดีขึ้นได้อย่างไร
Scrum framework
3.Scrum Master
สนับสนุน Product Owne
ช่วยจัดลำดับความสำคัญProduct Backlogให้ผลิตภัณฑ์มีคุณค่ามากที่สุด
หาเทคนิคในการบริหารจัดการ Product Backlog
คือ
ทำให้ทีมเข้าในสกรัมและนำไปใช้ได้อย่างถูกต้อง
ช่วยเหลือการดำเนินงานในขั้นตอนต่างๆ
รู้ว่าการดำเนินงานแบบไหนดีหรือไม่ดีต่อทีม
ทำให้ทีมเข้าใจขอบเขตของผลิตภัณฑ์
สนับสนุน Developer
ช่วยให้สามารถผลิตงานที่มีคุณภาพ
กำจัดอุปสรรคที่มีผลต่อการพัฒนาผลิตภัณฑ์
พัฒนาให้Developer สามารถบริหารตัวเอง และมีความสามารถหลากหลาย
สนับสนุนองค์กร
สอนให้องค์กรเข้าใจสกรัม ประโยชน์และนำไปใช้ได้อย่างมีประสิทธิภาพ
2. Developer
สมาชิกมีจำนวน 5–9 คน เพื่อให้สามารถรับปริมาณงานได้ไม่น้อยเกินไป และไม่เสียเวลาในการประสานงานมากเกินไป
พัฒนางานตามที่วางแผนเอาไว้
ไม่มีการแบ่งทีมย่อยภายใต้ทีมพัฒนาอีก เช่น ทีมออกแบบ ทีมทดสอบ
1. Product Owner
บริหารจัดการ Product Backlog ให้ชัดเจน
จัดลำดับความส าคัญของงานใน Product Backlog และสามารถอธิบายเหตุผลได้
ทำให้ทีมเข้าใจรายละเอียดของ Product Backlog ตรงกัน
หาทางเพิ่มผลการดำเนินงานให้มีประสิทธิภาพมากขึ้น
User Stor
y
ระบุความต้องการของผู้ใช้ให้ชัดเจน
ระบุเกณฑ์การทดสอบว่าผลิตภัณฑ์ที่พัฒนาขึ้นมาตอบสนองความ
ต้องการได้จริงหรือไม
User Story ที่ดีต้องท าให้Developer เข้าใจสโคป (Scope) ของงานได้
อย่างชัดเจนว่าอะไรที่เกี่ยวข้องแล้วต้องพัฒนาขึ้น
So that เพื่อระบุว่าผู้ใช้งานจะได้รับอะไร
I want เพื่อระบุว่าผู้ใช้งานต้องการอะไร
As a เพื่อระบุบทบาทของผู้ใช้งาน
Acceptance criteria เกณฑ์วัดผลว่าสามารถ
ตอบสนองความต้องการได้แล้ว
Sprint Backlog
เลือกจาก Product Backlog
Sprint Backlog ควรมีงานอย่างน้อย 1 ชิ้น ที่มาจากการท า Sprint Retrospective เพื่อปรับปรุงประสิทธิภาพการท างานของทีม
Product Owner และ Developer
Product Backlog
งานทั้งหมดที่ต้องทำเพื่อพัฒนาผลิตภัณฑ์
มีรายละเอียดของงาน เกณฑ์การทดสอบงาน การประเมินความซับซ้อนและเวลาที่ต้องใช้ในการพัฒนา
เมื่อพัฒนาเสร็จและส่งมอบแล้ว อาจน าผลตอบรับจากผู้ใช้มาทบทวนและปรับปรุงผลิตภัณฑ์เพิ่มเติม โดยเขียนเป็ น User Story ใหม
นิยมเขียนในรูปแบบของ User Story
เมื่อ Product Backlog มีการเปลี่ยนแปลง Product Owner จะต้องจัดเรียงความสำคัญใหม่และแก้ไขรายละเอียดของ User Story ที่มีความสำคัญสูงให้พร้อมสำหรับนำไปพัฒนาได้ทันที
Product Backlog มีการเปลี่ยนแปลงอยู่เรื่อยๆ ตามความต้องการของผู้ใช้และตลาดเพื่อให้ผลิตภัณฑ์ตอบสนองความต้องการได้มากที่สุด
กิจกรรมของสกรัม (Scrum Events)
1.วางแผนสปรินท์ (Sprint Planning)
เลือกว่าจะทำงานอะไร
Product Owner เลือก User Story จาก Product Backlog มาแจ้งให้ทีมทราบว่าต้องท างานชิ้นไหน
บ้างเพื่อที่จะบรรลุเป้าหมายของสปรินท์
Developer จะเลือกงานที่ Product Owner เลือกไว้ใน Product Backlog เข้าสู่ Sprint Backlog เองเพราะรู้ขีดจ ากัดว่างานใดที่สามารถนำไปพัฒนาได้หรือต้องรองานส่วนอื่นเสร็จก่อน และปริมาณ
งานที่ทีมสามารถพัฒนาได้เสร็จในสปรินท์
Product Owner ก าหนดเป้าหมายของสปรินท์ว่าจะส่งมอบอะไร เพราะอะไร และเพื่ออะไรทำให้ทีม
เข้าใจว่าต้องทำงานชิ้นไหนบ้างเพื่อให้เกิดอะไร
ออกแบบวิธีว่าจะทำงานอย่างไร
ระบุส่วนที่ต้องรีบท าก่อนส่วนอื่น(ถ้ามี)
แบ่งชิ้นงานขนาดใหญ่ให้เป็ นชิ้นงานเล็กๆ
Developer ออกแบบแนวทางที่จะใช้ในการพัฒนางานแต่ละชิ้น
อาจท าการประเมินความซับซ้อนและเวลาที่ใช้ในการพัฒนางานใหม
อาจน าผลการประเมินมาจัดเรียงความส าคัญของงานใหม่
อาจมีการต่อรองปริมาณใน Sprint Backlog กับ Product Owner ใหม่ หากพบว่าการพัฒนามี
ความยากกว่าที่ประเมินไว้ในตอนแรก
2. สกรัมประจำวัน (Daily Scrum)
อาจเรียกว่า Standup Meeting ใช้เวลาไม่เกิน 15 นาทีเน้นให้ Developer แจ้ง
ความคืบหน้าในการพัฒนางาน
วางแผนทำงานในแต่ละวัน
แต่ละคนแจ้งให้ทีมทราบว่า 1.ทำอะไรไปในเมื่อวาน 2.วันนี้จะทำอะไรเพิ่มเติม 3.ปัญหาที่เกิดขึ้นในการพัฒนา
ตรวจสอบและแจ้งความคืบหน้าของงานในสปรินท์
หากพบปัญหาหรือการเปลี่ยนแปลงที่ส่งผลต่อการบรรลุเป้าหมายของสปรินท์
อาจจัดประชุมหลังทำสกรัมประจำวันเพื่อวางแผนงานที่เหลือในสปรินท์ใหมโดยอาจ
เปลี่ยนแปลงสโคปงาน หรือโยกย้ายงานที่จำเป็นน้อยกว่าออกจากสปรินท์
แจ้งให้ทีมทราบหากมีงานอื่นแทรกเข้ามา
Scrum Master ช่วยควบคุมเวลาไม่ให้เกิน 15 นาที และป้องกันไม่ให้คนภายนอกรบกวนการทำสกรัมประจำวัน
3. ตรวจสอบผลลัพธ์ของสปรินท์ (Sprint Review)
ใช้เวลาไม่เกิน 2 ชั่วโมง ส าหรับสปรินท์ 2 สัปดาห์ ตรวจสอบงานที่พัฒนาและแสดงผลลัพธ์ของงานในสปรินท์
ให้แก่ผู้เกี่ยวข้อง(Stakeholders) เพื่อรับฟังข้อเสนอแนะ และทบทวน Product Backlog ที่จะท าต่อไป
Product Owner อธิบายงานที่เหลือใน Product Backlog จะทำอะไร
เป็นลำดับต่อไปและจะเสร็จเมื่อไรโดยดูได้จาก BurndownChart เป็นต้น
ทบทวนทิศทางตลาดและสถานการณ์ที่เปลี่ยนไป
ทบทวนทรัพยากรที่มี ทีมงาน, เวลา, เครื่องมือ, ตลาด
พิจารณาคุณค่าของงานที่ได้พัฒนาขึ้นมาและเลือกงานที่จะส่งมอบให้แก่ผู้ใช้
Demo งานที่พัฒนาขึ้นในสปรินท์
Developer อธิบายการดำเนินงาน และปัญหาที่เกิดขึ้นรวมถึงวิธีที่แก้ไข
Product Owner อธิบายว่ามีงานอะไรเสร็จหรือไม่เสร็จ
ตรวจสอบการดำเนินงานของสปรินท์ (Sprint Retrospective)
ใช้เวลาไม่เกิน 1.5 ชั่วโมงสำหรับสปรินท์ 2 สัปดาห์ตรวจสอบการดำเนินงานในสปรินท์ที่จบลงทั้งในเรื่องของทีมงาน ความสัมพันธ์ภายในทีม ความรู้ เครื่องมือ สภาพแวดล้อมในการทำงาน
▪ แต่ละคนแจ้งให้ทีมทราบว่าสปรินท์ที่จบลงมีอะไรที่ดีและไม่ดีบ้าง
▪ จัดล าดับความส าคัญของผลกระทบของสิ่งที่ไม่ดีและต้องการปรับปรุง
▪ ทีมเสนอแนวทางในการแก้ไขสิ่งที่ไม่ดี เพื่อเพิ่มประสิทธิภาพในการด าเนินงานและคุณภาพของผลิตภัณฑ์
▪ สรุปวิธีการด าเนินการที่จะใช้ในสปรินท์ถัดไป(ถ้ามี) โดยจะต้องสามารถวัดผลวิธีการด าเนินงานแบบใหม่ เพื่อน ามา
เปรียบเทียบกับวิธีด าเนินงานแบบเก่าว่าแบบไหนมีประสิทธิภาพมากกว่ากัน
▪ Scrum Master เข้าร่วมในสถานะสมาชิกทีม และช่วยควบคุมเวลา
ชี้แจงรายละเอียด Product Backlog (Product Backlog Refining)
ใช้เวลาไม่เกิน 10% ของสปรินท์ จัดเมื่อไหร่ก็ได้ในสปรินท์โดยให้ทีมตกลงกันเอง ระหว่างProduct Owner และ Developer เพื่อชี้แจงรายละเอียดงาน ประเมินเวลาที่ใช้ในการพัฒนาชิ้นงาน และจัดลำดับความสาคัญของงาน
▪ Product Owner อธิบาย User Story ต่างๆ ใน Product Backlog
▪ งานที่มีล าดับความส าคัญสูงต้องมีรายละเอียดงานให้ครบ เพื่อให้ Developer สามารถประเมินความซับซ้อนและเวลาที่ต้องใช้ในการพัฒนางานได้อย่างแม่นยำ
▪ Developer ประเมินความซับซ้อนและเวลาที่ใช้ในการพัฒนางาน
▪ Product Owner นำผลการประเมินมาช่วยจัดล าดับความส าคัญใหม่
▪ Product Owner สรุปงานที่เหลือใน Product Backlog เทียบกับงานที่ทำในสปรินท์ปัจจุบัน เพื่อดูว่างานทั้งหมดจะ
พัฒนาเสร็จเมื่อไร (สามารถใช้ Burndown Chart ช่วยประเมินเวลาที่จะพัฒนาได้)
การทำสกรัมให้มีประสิทธิภาพ
ให้ความส าคัญกับงานในสปรินท์ก่อน
พัฒนาผลิตภัณฑ์ในทางที่ถูกต้อง ไม่ซ่อนปัญหา
ทุกคนช่วยกันทางานเพื่อบรรลุเป้าหมายของทีม
ไม่ใช่เฉพาะของเรา
เคารพการทำงานของคนอื่น เพื่อให้แต่ละฝ่ายสามารถทำงานได้อิสระ
เปิดใจกว้างต่องานทั้งหมดที่มีและความท้าทายในการทำงาน
ทำเป็นคู่ค่ะ
65030035 ฉัตรลดา ว่องการยนต์
65030007 กนกศิริ บุญคำ