คุกกี้พื้นฐานที่จำเป็น เพื่อช่วยให้การทำงานหลักของเว็บไซต์ใช้งานได้ รวมถึงการเข้าถึงพื้นที่ที่ปลอดภัยต่าง ๆ ของเว็บไซต์ หากไม่มีคุกกี้นี้เว็บไซต์จะไม่สามารถทำงานได้อย่างเหมาะสม และจะใช้งานได้โดยการตั้งค่าเริ่มต้น โดยไม่สามารถปิดการใช้งานได้
คุกกี้ในส่วนวิเคราะห์ จะช่วยให้เว็บไซต์เข้าใจรูปแบบการใช้งานของผู้เข้าชมและจะช่วยปรับปรุงประสบการณ์การใช้งาน โดยการเก็บรวบรวมข้อมูลและรายงานผลการใช้งานของผู้ใช้งาน
คุกกี้ในส่วนการตลาด ใช้เพื่อติดตามพฤติกรรมผู้เข้าชมเว็บไซต์เพื่อแสดงโฆษณาที่เหมาะสมสำหรับผู้ใช้งานแต่ละรายและเพื่อเพิ่มประสิทธิผลการโฆษณาสำหรับผู้เผยแพร่และผู้โฆษณาสำหรับบุคคลที่สาม
Scrum (สกรัม) คือการนำแนวคิดในการทำงานแบบ Agile (อไจล์) มาปฏิบัติตามขั้นตอนของสกรัม เพื่อระบุปัญหาที่มีความซับซ้อน เปลี่ยนแปลงบ่อย เพื่อให้สามารถส่งมอบผลิตภัณฑ์ที่ตอบสนองต่อการเปลี่ยนแปลงที่เกิดขึ้นได้อย่างรวดเร็ว
//www.mimeo.com/blog/three-reasons-scrum-master-certified/สกรัม
การพัฒนาผลิตภัณฑ์แบบอไจล์(Agile) ด้วยรูปแบบของสกรัม(Scrum)
ช่วยให้การพัฒนาผลิตภัณฑ์แบบอไจล์มีขั้นตอนการการดำเนินงานและผลลัพธ์ที่ชัดเจน โปร่งใส สามารถตรวจสอบประสิทธิภาพของแต่ละขั้นตอนการดำเนินงาน สามารถปรับปรุงและวัดผลการปรับปรุงที่เกิดขึ้นได้ โดยบทความนี้จะยึดเนื้อหาตามคู่มือสกรัมฉบับล่าสุด ณ วันที่เขียนบทความ คือคู่มือสกรัมฉบับปี 2017 (Scrum Guide 2017) เป็นหลัก
ก่อนที่จะเข้าสู่เนื้อหาของสกรัม หากยังไม่เข้าใจว่าการพัฒนาผลิตภัณฑ์แบบอไจล์คืออะไร สามารถเข้าไปอ่านเพิ่มเติมได้ที่
Agile คืออะไร เริ่มใช้งานอย่างไร
Agile Methodology คือแนวคิดในการทำงาน(ไม่ใช่รูปแบบหรือขั้นตอนการทำงาน)…
medium.com
ทำสกรัมเพื่ออะไร (Scrum Achievement)- กำหนดทิศทางและความสามารถของผลิตภัณฑ์ อะไรควรมี อะไรไม่ควรมี
- เพิ่มคุณค่าให้ผลิตภัณฑ์
- ส่งมอบผลิตภัณฑ์ได้รวดเร็วและบ่อยมากขึ้น
- วงจรอายุการใช้งาน(Life cycle) ของผลิตภัณฑ์ที่ยั่งยืน
สกรัม เน้นการนำความรู้จากประสบการณ์เฉพาะที่เคยลงมือทำจริง(Empiricism) มาพัฒนาการดำเนินงานในปัจจุบันให้ดียิ่งขึ้น ประกอบด้วย 3 ส่วน
- ความโปร่งใส (Transparency) คือทีมจะต้องเห็นภาพชัดเจนและเข้าใจตรงกัน มาตรฐานเดียวกัน ไม่ตีความหมายต่างกัน เช่น นิยามของคำว่างานเสร็จ หมายถึง การผลิตเสร็จ หรือ ผลิตและทดสอบเสร็จ หรือ ได้รับการเซ็นรับรอง หรือ ส่งมอบให้ผู้ใช้แล้ว ต้องนิยามและตกลงให้เข้าใจตรงกัน
- การตรวจสอบ (Inspection) คือการนำผลลัพธ์การดำเนินกิจกรรมต่างๆของสกรัม(Scrum Artifact) มาตรวจสอบและวัดผลว่าบรรลุตามที่กำหนดไว้หรือไม่
- การปรับเปลี่ยน (Adoption) คือหากผลลัพธ์ไม่เป็นไปตามที่กำหนด จะต้องปรับเปลี่ยนการดำเนินงาน หรือจำนวนทรัพยากรที่ใช้ เพื่อให้บรรลุผลตามที่กำหนดหรือใกล้เคียงได้มากที่สุด
User Story ใช้สำหรับระบุความต้องการของผู้ใช้ให้ชัดเจน และระบุเกณฑ์การทดสอบว่าผลิตภัณฑ์ที่พัฒนาขึ้นมาตอบสนองความต้องการได้จริงหรือไม่ โดย User Story ที่ดีต้องทำให้ Developer เข้าใจสโคป(Scrope) ของงานได้อย่างชัดเจนว่าอะไรที่เกี่ยวข้องแล้วต้องพัฒนาขึ้น และอะไรที่ไม่เกี่ยวข้องจะได้ไม่ต้องเสียเวลาพัฒนา ส่วนรายละเอียดเพิ่มเติมเกี่ยวกับการเขียน User Story ที่ดี สามารถอ่านเพิ่มเติมได้ที่
ใช้ User story อย่างไรให้มีความหมาย
เคยคิดกันบ้างมั้ยว่าทำไมเราถึงต้องเขียน User Story ด้วยนะ?
medium.com
Product Backlogงานทั้งหมดที่ต้องทำเพื่อพัฒนาผลิตภัณฑ์ ส่วนใหญ่นิยมเขียนในรูปแบบของ User Story โดยมีรายละเอียดของงาน เกณฑ์การทดสอบงาน การประเมินความซับซ้อนและเวลาที่ต้องใช้ในการพัฒนาด้วย เมื่อพัฒนาเสร็จและส่งมอบแล้ว อาจนำผลตอบรับจากผู้ใช้มาทบทวนและปรับปรุงผลิตภัณฑ์เพิ่มเติม โดยเขียนเป็น User Story ใหม่
เมื่อ Product Backlog มีการเปลี่ยนแปลง Product Owner จะต้องจัดเรียงความสำคัญใหม่ และแก้ไขรายละเอียดของ User Story ที่มีความสำคัญสูงให้พร้อมสำหรับนำไปพัฒนาได้ทันที การทำ Product Backlog จะมีการเปลี่ยนแปลงอยู่เรื่อยๆ ตามความต้องการของผู้ใช้และตลาดเพื่อให้ผลิตภัณฑ์ของเราตอบสนองความต้องการได้มากที่สุด
การประเมินเวลาที่ใช้ในการพัฒนางานการประเมินจะมี 2 ส่วน คือขนาดของงาน ความซับซ้อน และความเสี่ยงในการพัฒนางานจะเรียกว่า Story Point ส่วนเวลาที่ต้องใช้ในการพัฒนางาน เรียกว่า Estimate Time
สาเหตุที่ต้องมี 2 ส่วนเนื่องจากการพัฒนางานประเภทซอฟต์แวร์นั้นมีความเป็นศิลป์ ทำให้แต่ละคนมีการออกแบบโค้ดไม่เหมือนกัน วางความซับซ้อนในโครงสร้างเพื่อรองรับการเปลี่ยนแปลงหรือการทดสอบต่างกัน จึงมีความซับซ้อนทำการพัฒนาและใช้เวลาไม่เท่ากัน อีกทั้งประสบการณ์และความสามารถที่ต่างกันด้วย จึงควรใช้ทั้งสองค่าร่วมกัน ในช่วงแรกของการพัฒนาผลิตภัณฑ์ค่าประเมินอาจจะไม่แม่นยำ แต่เมื่อทีมดำเนินงานไปเรื่อยๆ ค่าประเมินจะแม่นยำมากขึ้น
ค่าประเมินทั้งสองจะมีผลต่อการจัดเรียงความสำคัญของงานใน Product Backlog เพราะ Product Owner จะทราบว่างานแต่ละชิ้นต้องใช้ทรัพยากรในการพัฒนาเท่าไร คุ้มกับมูลค่าที่จะได้เมื่องานเสร็จหรือไม่
นิยามของงานเสร็จ (Done)- ต้องมีการนิยามให้ชัดเจนและเข้าใจตรงกันทั้งทีมและทุกทีม เช่น งานเสร็จคือพัฒนาเสร็จ หรือ งานที่มีระบบตรวจสอบการทำงาน หรือ งานที่มีคู่มือใช้งาน หรือ งานที่ทดสอบผ่านแล้ว หรือ ทดสอบใช้งานร่วมกับของเดิมผ่านแล้ว หรือ งานที่ส่งมอบให้ผู้ใช้แล้ว
- ทำให้ทีมเข้าใจตรงกัน และรู้ขีดจำกัดว่ารองรับปริมาณงานได้มากเท่าไร
- งานใหม่จะต้องผ่านการทดสอบว่าสามารถใช้งานร่วมกับของเดิมได้
- Developer ต้องพัฒนาให้เสร็จตามนิยามที่ตกลงไว้ร่วมกัน
- Product Owner จะเป็นคนเลือกว่างานที่เสร็จนั้นจะส่งมอบแก่ผู้ใช้หรือไม่
- เมื่อทีมเก่งขึ้นจะนิยามคำว่า “งานเสร็จ” ใหม่ เพื่อเพิ่มคุณภาพของชิ้นงาน
งานที่ทำเสร็จพร้อมสำหรับส่งมอบให้แก่ผู้ใช้งาน(แม้จะยังไม่ส่งมอบให้ผู้ใช้งาน) โดยหมายถึงงานที่เสร็จในสปรินท์ปัจจุบันและงานจากสปรินท์เก่าที่ผ่านมาทั้งหมด
สปรินท์(Sprint) รอบเวลาการดำเนินงานแบบสกรัมเนื่องจากธุรกิจในปัจจุบันมีการแข่งขันที่สูง และความต้องการของผู้ใช้งานเปลี่ยนแปลงบ่อย เมื่อสถาณการณ์และเวลาเปลี่ยนไปผู้ใช้งานอาจต้องการของอย่างอื่นที่ไม่ใช่สิ่งที่เราคิดไว้ในตอนแรก และต้องพัฒนาผลิตภัณฑ์ของเราให้สามารถต่อกรความสามารถของผลิตภัณฑ์ของคู่แข่งได้ทันเวลา
สกรัมจึงแบ่งรอบการดำเนินงานเป็นช่วงเวลาสั้นๆ เรียกว่าสปรินท์(Sprint) คือช่วงเวลาในการดำเนินงานที่จะสามารถส่งมอบผลิตภัณฑ์ เมื่อจบสปรินท์จะต้องได้รับชิ้นงานตามที่วางแผนไว้และสามารถนำไปส่งมอบให้แก่ผู้ใช้ ทำให้ผู้ใช้ไม่จำเป็นต้องรอจนงานเสร็จทั้งหมดก่อนจึงจะได้รับ แต่สามารถนำบางส่วนไปใช้งานก่อนได้เลยและส่วนอื่นๆ ทยอยตามมาเพิ่มเติมในภายหลัง
- ความยาวของสปรินท์จะมีช่วงเวลาระหว่าง 1–4 สัปดาห์
- ไม่ควรมีการเปลี่ยนแปลงที่ส่งผลกระทบต่อเป้าหมายของสปรินท์
- ไม่มีการลดคุณภาพของชิ้นงาน
- สโคปงานอาจเปลี่ยนแปลงได้ โดยต้องตกลงกันระหว่าง Product Owner และ Developer
คือวัตถุประสงค์ของสปรินท์นั้นว่าต้องการทำอะไร เช่น ต้องการทำให้มีผู้ใช้ใหม่เพิ่มขึ้น X % หรือ ต้องการแนะนำสินค้าที่เกี่ยวข้องให้แก่ผู้ใช้ เป็นต้น ทำให้ทีมเห็นเป้าหมายตรงกัน รู้ว่าต้องทำงานอะไรบ้าง และรู้ว่าต้องทำงานชิ้นนี้ไปเพื่ออะไร
การยกเลิกสปรินท์Product Owner เป็นคนเดียวที่สามารถยกเลิกสปรินท์ได้ โดยจะยกเลิกถ้าหากเป้าหมายของสปรินท์มีการยกเลิก เช่น ยกเลิกการพัฒนาฟีเจอร์นี้เนื่องจากตลาดไม่ต้องการแล้ว เมื่อทำการยกเลิกสปรินท์งานที่ทำเสร็จไปแล้วอาจนำไปใช้ต่อ ส่วนงานที่ยังทำไม่เสร็จจะนำกลับเข้าสู่ Product Backlog เมื่อจะนำเข้าสปรินท์จะทำการประเมินงานใหม่อีกครั้ง
Sprint Backlogงานที่ Product Owner และ Developer ตกลงกัน โดยเลือกจาก Product Backlog เข้าสู่ Sprint Backlog เพื่อให้ Developer รู้ว่าต้องทำงานชิ้นไหนบ้างในสปรินท์เพื่อที่จะบรรลุเป้าหมายของสปรินท์ และ Developer ต้องพัฒนาให้เสร็จจนพร้อมสำหรับส่งมอบแก่ผู้ใช้เมื่อจบสปรินท์ และใน Sprint Backlog ควรมีงานอย่างน้อย 1 ชิ้น ที่มาจากการทำ Sprint Retrospective เพื่อปรับปรุงประสิทธิภาพการทำงานของทีม
ตำแหน่งในทีมสกรัมสกรัมเหมาะสำหรับทีมขนาดเล็กที่พร้อมปรับตัว พัฒนา และเปลี่ยนแปลง สมาชิกในทีมสกรัมต้องมีความสามารถที่หลากหลาย สามารถบริหารและดำเนินงานกันเองได้ด้วยสมาชิกภายในทีม สามารถหาแก้ไขปัญหาได้เอง โดยไม่ต้องรอความช่วยเหลือจากนอกทีม โดยประกอบด้วย
1. Product Owner
- บริหารจัดการ Product Backlog ให้ชัดเจน
- จัดลำดับความสำคัญของงานใน Product Backlog และสามารถอธิบายเหตุผลได้
- ทำให้ทีมเข้าใจรายละเอียดของ Product Backlog ตรงกัน
- หาทางเพิ่มผลการดำเนินงานให้มีประสิทธิภาพมากขึ้น
2. Developer
- สมาชิกมีจำนวน 3–9 คน เพื่อให้สามารถรับปริมาณงานได้ไม่น้อยเกินไป และไม่เสียเวลาในการประสานงานมากเกินไป
- พัฒนางานตามที่วางแผนเอาไว้
- ไม่มีการแบ่งทีมย่อยภายใต้ทีมพัฒนาอีก เช่น ทีมออกแบบ ทีมทดสอบ
- สมากชิกทีมแต่ละคนจะมีความสามารถเฉพาะทางของตนเอง เช่น ความสามารถในการออกแบบ แต่ความรับผิดชอบงานจะเป็นของทั้งทีม หากงานออกแบบไม่เสร็จทั้งทีมต้องมาช่วยกันรับผิดชอบ
3. Scrum Master
- ทำให้ทีมเข้าในสกรัมและนำไปใช้ได้อย่างถูกต้อง
- ช่วยเหลือการดำเนินงานในขั้นตอนต่างๆ
- รู้ว่าการดำเนินงานแบบไหนดีหรือไม่ดีต่อทีม
- ทำให้ทีมเข้าใจขอบเขตของผลิตภัณฑ์
สนับสนุน Product Owner
- หาเทคนิคในการบริหารจัดการ Product Backlog
- ช่วยจัดลำดับความสำคัญ Product Backlog ให้ผลิตภัณฑ์มีคุณค่ามากที่สุด
สนับสนุน Developer
- พัฒนาให้ Developer สามารถบริหารตัวเอง และมีความสามารถหลากหลาย
- ช่วยให้สามารถผลิตงานที่มีคุณภาพ
- กำจัดอุปสรรคที่มีผลต่อการพัฒนาผลิตภัณฑ์
สนับสนุนองค์กร
- สอนให้องค์กรเข้าใจสกรัม ประโยชน์ และนำไปใช้ได้อย่างมีประสิทธิภาพ
การทำกิจกรรมของสกรัมเพื่อให้การดำเนินงานเป็นขั้นตอนชัดเจน ตรวจสอบ วัดผลได้ และลดการประชุมที่ไม่จำเป็น การทำสกรัมจะประกอบไปด้วยกิจกรรมต่างๆ ดังนี้
1. วางแผนสปรินท์ (Sprint Planing)
ใช้เวลาไม่เกิน 4 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ โดยจะแบ่งการวางแผนสปรินท์ออกเป็นสองส่วน
ส่วนที่หนึ่ง: เลือกว่าจะทำงานอะไร
- Product Owner จะกำหนดเป้าหมายของสปรินท์ว่าจะส่งมอบอะไร เพราะอะไร และเพื่ออะไร ทำให้ทีมเข้าใจว่าต้องทำงานชิ้นไหนบ้างเพื่อให้เกิดอะไร
- Product Owner เลือก User Story จาก Product Backlog มาแจ้งให้ทีมทราบว่าต้องทำงานชิ้นไหนบ้างเพื่อที่จะบรรลุเป้าหมายของสปรินท์
- Developer จะเลือกงานที่ Product Owner เลือกไว้ใน Product Backlog เข้าสู่ Sprint Backlog เอง เพราะรู้ขีดจำกัดว่างานใดที่สามารถนำไปพัฒนาได้หรือต้องรองานส่วนอื่นเสร็จก่อน และปริมาณงานที่ทีมสามารถพัฒนาได้เสร็จในสปรินท์
ส่วนที่สอง: ออกแบบวิธีว่าจะทำงานอย่างไร
- Developer ออกแบบแนวทางที่จะใช้ในการพัฒนางานแต่ละชิ้น
- ระบุส่วนที่ต้องรีบทำก่อนส่วนอื่น(ถ้ามี)
- แบ่งชิ้นงานขนาดใหญ่ให้เป็นชิ้นงานเล็กๆ
- อาจทำการประเมินความซับซ้อนและเวลาที่ใช้ในการพัฒนางานใหม่
- อาจนำผลการประเมินมาจัดเรียงความสำคัญของงานใหม่
- อาจมีการต่อรองปริมาณใน Sprint Backlog กับ Product Owner ใหม่ หากพบว่าการพัฒนามีความยากกว่าที่ประเมินไว้ในตอนแรก
2. สกรัมประจำวัน (Daily Scrum)
//standuply.com/blog/daily-standup-meeting-excel-template/
การประชุมประจำวัน (Daily Meeting) หรืออาจะเรียกว่า Standup Meeting เพราะเป็นการล้วมวงยืนประชุมในเวลาสั้นๆ ใช้เวลาไม่เกิน 15 นาที เน้นให้ Developer แจ้งความคืบหน้าในการพัฒนางานแก่กัน
- เพื่อตรวจสอบและแจ้งความคืบหน้าของงานในสปรินท์
- เพื่อเป็นการวางแผนทำงานในแต่ละวัน
- โดยแต่ละคนแจ้งให้ทีมทราบว่า 1.ทำอะไรไปในเมื่อวาน 2.วันนี้จะทำอะไรเพิ่มเติม 3.ปัญหาที่เกิดขึ้นในการพัฒนา
- แจ้งให้ทีมทราบหากมีงานอื่นแทรกเข้ามา
- หากพบปัญหาหรือการเปลี่ยนแปลงที่ส่งผลต่อการบรรลุเป้าหมายของสปรินท์ อาจจัดประชุมหลังทำสกรัมประจำวันเพื่อวางแผนงานที่เหลือในสปรินท์ใหม่ โดยอาจเปลี่ยนแปลงสโคปงาน หรือโยกย้ายงานที่จำเป็นน้อยกว่าออกจากสปรินท์
- Scrum Master ช่วยควบคุมเวลาไม่ให้เกิน 15 นาที และป้องกันไม่ให้คนภายนอกรบกวนการทำสกรัมประจำวัน
3. ตรวจสอบผลลัพธ์ของสปรินท์ (Sprint Review)
ใช้เวลาไม่เกิน 2 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ ตรวจสอบงานที่พัฒนาและแสดงผลลัพธ์ของงานในสปรินท์ให้แก่ผู้เกี่ยวข้อง(Stakeholders) เพื่อรับฟังข้อเสนอแนะ และทบทวน Product Backlog ที่จะทำต่อไปให้สอดคล้องกับโอกาสและสถานการณ์ของตลาดในปัจจุบัน
- Product Owner อธิบายว่ามีงานอะไรเสร็จหรือไม่เสร็จ
- Developer อธิบายการดำเนินงาน และปัญหาที่เกิดขึ้นรวมถึงวิธีที่แก้ไข
- Demo งานที่พัฒนาขึ้นในสปรินท์
- พิจารณาคุณค่าของงานที่ได้พัฒนาขึ้นมาและเลือกงานที่จะส่งมอบให้แก่ผู้ใช้
- ทบทวนทรัพยากรที่มี ทีมงาน, เวลา, เครื่องมือ, ตลาด
- ทบทวนทิศทางตลาดและสถานการณ์ที่เปลี่ยนไป
- Product Owner อธิบายงานที่เหลือใน Product Backlog เกริ่นคร่าวๆว่าจะทำอะไรเป็นลำดับต่อไปและจะเสร็จเมื่อไร โดยดูได้จาก Burndown Chart เป็นต้น
4. ตรวจสอบการดำเนินงานของสปรินท์ (Sprint Retrospective)
//sunitarajain.wordpress.com/2014/09/27/what-is-an-agile-sprint-retrospective/
ใช้เวลาไม่เกิน 1.5 ชั่วโมง สำหรับสปรินท์ 2 สัปดาห์ ตรวจสอบการดำเนินงานในสปรินท์ที่จบลง ทั้งในเรื่องของทีมงาน ความสัมพันธ์ภายในทีม ความรู้ เครื่องมือ สภาพแวดล้อมในการทำงาน เป็นต้น
- โดยแต่ละคนแจ้งให้ทีมทราบว่าสปรินท์ที่จบลงมีอะไรที่ดีและไม่ดีบ้าง
- จัดลำดับความสำคัญของผลกระทบของสิ่งที่ไม่ดีและต้องการปรับปรุง
- ทีมเสนอแนวทางในการแก้ไขสิ่งที่ไม่ดี เพื่อเพิ่มประสิทธิภาพในการดำเนินงานและคุณภาพของผลิตภัณฑ์
- สรุปวิธีการดำเนินการที่จะใช้ในสปรินท์ถัดไป(ถ้ามี) โดยจะต้องสามารถวัดผลวิธีการดำเนินงานแบบใหม่ เพื่อนำมาเปรียบเทียบกับวิธีดำเนินงานแบบเก่าว่าแบบไหนมีประสิทธิภาพมากกว่ากัน
- Scrum Master เข้าร่วมในสถานะสมาชิกทีม และช่วยควบคุมเวลา
5. ชี้แจงรายละเอียด 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 ช่วยประเมินเวลาที่จะพัฒนาได้)
สรุปการดำเนินสปรินท์ฉบับย่อ
Sprint Cheatsheet คู่มือทำสกรัม (Scrum) ฉบับรวบรัด
สรุปขั้นตอนต่างๆ ในสปรินท์ ว่าต้องทำอะไรเมื่อไร
medium.com
ผลลัพธ์จากกิจกรรมของสกรัม (Scrum Artifacts)คือผลลัพธ์ที่ได้จากการทำกิจกรรมสกรัมต่างๆ เพื่อนำมาใช้ในการตรวจสอบและวัดผลการปรับเปลี่ยนวิธีการดำเนินงานแต่ละสปรินท์ ช่วยให้สามารถเปรียบเทียบว่าวิธีการดำเนินงานแบบใหม่กับแบบเก่า แบบใดที่ดีกว่ากันได้อย่างชัดเจนและโปร่งใส
เช่น ตรวจสอบจาก Product Backlog ที่ครบถ้วนชัดเจนมากขึ้น ทีมผลิตงานได้ปริมาณมากขึ้น หรือมีอุปสรรคในการดำเนินการน้อยลงจากการทำ Sprint Retrospective เป็นต้น
การทำสกรัมให้มีประสิทธิภาพ- ทุกคนช่วยกันทำงานเพื่อบรรลุเป้าหมายของทีม ไม่ใช่เฉพาะของเรา
- ให้ความสำคัญกับงานในสปรินท์ก่อน
- พัฒนาผลิตภัณฑ์ในทางที่ถูกต้อง ไม่ซ่อนปัญหา
- เปิดใจกว้างต่องานทั้งหมดที่มี และความท้าทายในการทำงาน
- เคารพการทำงานของคนอื่น เพื่อให้แต่ละฝ่ายสามารถทำงานได้อิสระ
ก่อนมีสปรินท์แรก
- จัดตั้งทีมสกรัมโดยขนาดของทีมต้องมีขนาดเล็ก ประกอบด้วย Scrum Master 1 คน, Product Owner 1 คน, Developer 3–9 คน
- กำหนดระยะเวลาของสปรินท์ระหว่าง 1–4 สัปดาห์
- นิยามคำว่างานเสร็จให้เข้าใจตรงกัน
- ออกแบบผลิตภัณฑ์ให้ตอบโจทย์ผู้ใช้ โดยเขียนในรูปแบบ User Story และใส่ไว้ที่ Product Backlog
วงจรสปรินท์ (Sprint Loop)
- Sprint planing 1 เลือกว่าจะทำ User Story ไหนบ้าง
- Sprint planing 2 ออกแบบว่าจะพัฒนา User Story นั้นอย่างไร
- Daily Scrum เพื่อรายงานความคืบหน้าและปัญหาที่เกิดขึ้น
- Sprint Review เพื่อตรวจสอบงานที่พัฒนา และฟังข้อเสนอแนะ
- Sprint Retrospective เพื่อตรวจสอบประสิทธิภาพในการดำเนินงาน และหาแนวทางปรับปรุง
- Product Backlog Refining เพื่ออธิบายรายละเอียดงานที่เหลือ
หากยังเห็นภาพไม่ชัดเจนให้ย้อนกลับไปดูภาพบนสุดของบทความ จะแสดงขั้นตอนต่างๆทั้งหมดของการทำสกรัม
จะเห็นได้ว่าการทำงานแบบอไจล์ด้วยสกรัมนั้นมีการวัดผล และปรับปรุงพัฒนาอยู่ในทุกขั้นตอน นอกจากนี้คู่มือสกรัมได้ระบุไว้ว่า การทำสกรัมต้องนำไปใช้ตามคู่มือทั้งหมดโดยไม่มีการปรับเปลี่ยน ไม่เช่นนั้นจะไม่ถือว่าเป็นผลลัพธ์จากการทำสกรัม อย่างไรก็ตามในความเห็นของผม มันก็ขึ้นอยู่กับสถานการณ์ของแต่ละองค์กร
อย่าทำสกรัมเป็นพิธีกรรม แต่จงทำสกรัมให้เป็นอไจล์
การทำสกรัมให้เป็นอไจล์ต้องมีการวัดผลการดำเนินงานและนำไปปรับปรุงพัฒนาจึงจะเรียกว่าอไจล์ ถ้าแค่ใช้แบ่งงานเป็นชิ้นเล็กๆเพื่อทยอยส่งมอบ โดยไม่สนใจผลตอบรับและนำมาปรับปรุงจะไม่ใช่อไจล์ แต่เป็นแค่การทยอยส่งงานโดยเอากิจกรรมของสกรัมมาทำเป็นพีธีกรรม
Follow Scrum events with Scrum theory getting empiricism to improve product and process for Scrum achievement.
วัตถุประสงค์ของการประสานงานประกอบด้วยอะไรบ้าง
วัตถุประสงค์ของการประสานงาน 1. เพื่อแจ้งให้ผู้มีส่วนเกี่ยวข้องทราบ 2. เพื่อรักษาไว้ซึ่งความสัมพันธ์อันดี 3. เพื่อขอคายินยอมหรือความเห็นชอบ 4. เพื่อขอความช่วยเหลือ 5. เพื่อขจัดข้อขัดแย้งที่อาจมีขึ้น 6. เพื่อให้งานสาเร็จตามเป้าหมาย 7. เพื่อให้งานมีคุณภาพตามมาตรฐานที่กาหนดไว้การประสานงานที่สำคัญมีอะไรบ้าง
การประสานงาน อาจกระทำได้เป็น 2 ลักษณะ คือ 1. การประสานงานอย่างเป็นทางการ หมายถึง การ ประสานงานแบบมีพิธีรีตรองที่ต้องปฏิบัติ เช่น มีหนังสือติดต่อหรือ แจ้งเป็นลายลักษณ์อักษร หรือเสนอรายงานเป็นลำดับชั้น เป็นต้น 2. การประสานงานอย่างไม่เป็นทางการ หมายถึง การ ประสานงานแบบไม่มีพิธีรีตรองเพียงแต่ทำความตกลงให้ทราบถึง การที่จะ ...ข้อใดคือประโยชน์ในการประสานงานในองค์กร
ช่วยในการประสานงานที่ดี ช่วยในการขับเคลื่อนการดำเนินเพื่อสร้างความโปร่งใสในองค์การ ช่วยในการตรวจสอบความก้าวหน้าในการดำเนินงาน จะทำให้ทราบถึงประสิทธิภาพการทำงานของบุคคลในองค์การข้อตกลงที่สำคัญของการประสานงานในองค์การคืออะไร
2. การประสานงานเป็นเรื่องเกี่ยวกับคน งาน และจิตใจ เพราะการประสานงาน ต้องน าเอาคน คือ ผู้ปฏิบัติงานเข้ามาร่วมท างานกันอย่างสมานฉันท์เป็นทีมเวิร์ค จึงเห็นว่า ข้อตกลงที่ส าคัญยิ่งของการประสานงาน คือ ความร่วมมือซึ่งเป็นเรื่องของจิตใจ ในการท างานร่วมกัน