ตัวอย่างรายการเพื่อใช้ตรวจสอบสําหรับ ScrumMasterไมเคิล เจมส์ ( mj4scrum@gmail.com )วันที่ 14 กันยายน 2007(ปรับปรุงเมื่อ 2 กุมภาพันธ์ 2016)พงษ์ศักดิ์ ฤทธิพ์ ิทักษ์พงศ์ ( jane@odd-e.com )วันที่ 21 ธันวาคม 2018ผู้มีหน้าที่อํานวยความสะดวก เต็มเวลาหรือไม่?
สกรัมมาสเตอร์(ScrumMaster) ที่ดีจะสามารถดูแลทีมได้ครัง้ ละสองหรือสามทีม และหากคุณพอใจที่จะจํากัดบทบาทของคุณไว้เพียงแค่จัดระเบียบการประชุม บังคับให้ใช้เวลาตามที่กําหนดไว้ และตอบสนองต่อปั ญหาต่าง ๆทั นที แล้วล่ะก็ คุณสามารถทําบทบาทนี ้ได้โดยไม่จําเป็ นต้องเป็ นงานเต็มเวลา ที มอาจจะยังคงสามารถทํางานร่ว
มกันได้ตามความคาดหวังพื้นฐานขององค์กร และอาจจะไม่มีหายนะใด ๆ เกิดขึ้น
แต่ถ้าคุณกําลังจินตนาการถึงที มที่ทํางานสําเร็จลุล่วงตามเป้ าหมายร่วมกันได้อย่างมีความสุ ขในแบบที่ไม่เคยมีใคร
คิดฝั นมาก่อน มันก็อาจจะถึงเวลาที่องค์กรควรพิจารณาถึงการมีสกรัมมาสเตอร์(ScrumMaster) ทํางานแบบเต็มเวลาได้แล้ว
“สกรัมมาสเตอร์(ScrumMaster) ที่ยอดเยีย
่ ม” จะดูแลทีมทีละหนึ่งทีม เท่านั้น
คําแนะนําของพวกเราคือ สกรัมมาสเตอร์หนึ่งคนควรทํางานร่วมกับทีมที่มีสมาชิกประมาณ 7 คน ณ ช่วงก่อร่าง
สร้างทีมเอกสารนีไ้ ม่ใช่เอกสารที่สมบูรณ์แบบสําหรับทุกคนในทุกบริบท โดยเอกสารประกอบด้วยส่วนต่าง ๆ สี่ส่วนโดยเน้นที่
เรื่องที่คุณต้องคํานึงถึงสี่ด้านคือโปรดักส์โอนเนอร์(Product Owner) ของคุณ ทีมของคุณ ความชํานาญทาง
วิศวกรรมของทีมของคุณ และหน่วยงานอื่น ๆ รอบ ๆ ทีมของคุณ คุณจะพบว่าเอกสารนีไ้ ม่ได้รวบรวมหน้าที่ทั้งหมด
ที่สกรัมมาสเตอร์(ScrumMaster) ควรทําไว้ ผมเพียงแค่รวบรวมสิ่งที่ผมมักเห็ นสกรัมมาสเตอร์(ScrumMaster)มองข้ามเอาไว้ในเอกสารนีเ้ ท่านั้นโปรดทําเครื่องหมายแต่ละช่อง ด้วยสัญลักษณ์ √, ∆,? หรือ N/A ตามคําอธิบายในหน้าสุดท้าย2ส่วนที่ 1 - โปรดักส์โอนเนอร์(Product Owner) ของฉันเป็ นอย่างไรบ้าง?
สกรัมมาสเตอร์(ScrumMaster) สามารถช่วยปรับปรุงประสิทธิภาพของโปรดักส์โอนเนอร์(Product Owner)ได้โดยการช่ วยให้ เค้าหาวิ ธีการที่ เหมาะสมมาบํารุ งรักษาโปรดักส์ แบ็ คล็อก(Product Backlog) รวมถึงการวางแผนของการส่งมอบได้ (อย่าลืมว่าโปรดักส์โอนเนอร์(Product Owner) เป็ นผู้รบั ผิดชอบและมีสิทธิข์ าดในการเรียงลําดับความสําคัญของงาน)โปรดักส์แบ็คล็อก(Product Backlog) ได้ถูกปรับปรุงการเรียงลําดับความสําคัญตามความเห็นของ
โปรดักส์โอนเนอร์(Product Owner) อยู่ตลอดเวลาหรือไม่?
ความต้องการหรือความปราถนาของผู้เกีย่ วข้องได้ถูกบันทึกไว้ในโปรดักส์แบ็คล็อก(ProductBacklog) หรือไม่? (อย่าลืมว่าโปรดักส์แบ็คล็อก(Product Backlog) สามารถปรับเปลีย่ นได้ทุกวินาที)โปรดักส์แบ็คล็อก(Product Backlog) อยู่ในขนาดที่สามารถจัดการได้หรือไม่? จํานวนของชิ้นงานใน
โปรดักส์แบ็คล็อก(Product Backlog) อยู่ในจํานวนที่สามารถจัดการได้กล่าวคือ ให้งานที่มีมีรายละเอียดชัดเจนอยู่ด้านบน และให้งานที่ยังไม่มีความชัดเจนหรือยังไม่มีรายละเอียดอยู่ด้านล่าง เพื่อป้ องกันให้เราไม่ใช้เวลากับการวิเคราะห์รายละเอียดเชิงลึกเร็วเกินไป เพราะอย่างไรก็ตามรายละเอียดของชิ้นงานที่ทําอาจจะมีการเปลีย่ นแปลงแก้ไขได้ตลอดในระหว่างที่เราพัฒนาผลิตภัณฑ์หรือพูดคุยกับลูกค้าและผู้ที่เกีย่ วข้องหรือแม้แต่ผลตอบรับจากการใช้งานจริงเป็ นไปได้แค่ไหนที่ชิ้นงานแต่ละชิ้น โดยเฉพาะงานชิ้นบน ๆ ของโปรดักส์แบ็คล็อก(Product Backlog)สามารถจัดให้อยู่ในลัษณะของงานที่เป็ นอิสระต่อกัน ต่อรองได้ มีคุณค่าทางธุรกิจ ประเมินความซับซ้อนได้ และทดสอบได้
คุณเคยให้ความรูโ้ ปรดักส์โอนเนอร์(Product Owner) เกีย่ วกับ “หนีท้ างเทคนิค” และวิธกี ารหลีกเลีย่ งหรือป้ องกันหรือไม่? หนึ่งในวิธกี ารดังกล่าว เช่น การใช้เทคนิคการทดสอบแบบอัตโนมัติ(AutomateTest) หรือการปรับเปลีย่ นรูปแบบของชุดคําสั่ง(Refactor) เพื่อให้ง่ายต่อการบํารุงรักษา โดยกําหนดให้เป็ นหนึ่งในนิยามของคําว่าเสร็จ (DOD) ของงานทุกชิ้น
โปรดักส์แบ็คล็อก(Product Backlog) เป็ นจุ ดศูนย์กลางของข้อมูลทั้งหมดและเป็ นที่ประจักษ์ต่อสายตาขอทุกคนที่เกีย่ วข้องหรือไม่?
หากคุณใช้เครื่องมืออัตโนมัติสําหรับการจัดการงานในโปรดักส์แบ็คล็อก(Product Backlog) ทุกคนสามารถใช้มันได้อย่างง่ายดายหรือไม่? (เครื่องมืออัตโนมัติมักมาพร้อมกับอันตรายที่ทําให้ข้อมูลของแต่ละชิ้นงานไม่ได้รบั การปรับปรุงอยู่เสมอ)คุณสามารถช่วยทําให้ข้อมูลในโปรดักส์แบ็คล็อก(Product Backlog) ถูกเผยแพร่ให้ทุกคนได้โดยง่ายหรือไม่?
คุณสามารถใช้เครื่องมือต่าง ๆ เพื่อช่วยทุกคนมองเห็นภาพรวมได้อย่างชัดเจนหรือไม่?
คุณได้ช่วยโปรดักส์โอนเนอร์(Product Owner) ในการจัดเรียงชิ้นงานให้อยู่ในรอบของการส่งมอบให้ลูกค้า หรือกลุ่มของลําดับความสําคัญที่เหมาะสมหรือไม่?
Copyright © 2007-2016 Michael James. All Rights Reserved. และพงษ์ศักดิ์ ฤทธิ์พิทักษ์พงศ์3ทุกคนรูห้ รือไม่ว่าแผนของการส่งมอบ ยังคงสะท้อนกับความเป็ นจริง? เช่น มีการปรับปรุงแผนภูมิรีรสี เบิรน์ ดาวน์(Release Burndown Chart) หลังจากงานแต่ละชิ้นได้รบั การยอมรับว่า “เสร็จ” ในการประชุมสปรินส์รวี ิว(Sprint Review) แผนภูมิดังกล่าวจะแสดงทั้งชิ้นงานที่เสร็จจริง ๆ และชิ้นงานที่
เพิ่มเข้ามาใหม่ซ่ึงนั่นหมายถึงการอนุญาตมีการปรับแผนของการส่งมอบไปจากเดิม
โปรดักส์โอนเนอร์(Product Owner) ได้ปรับปรุงแผนของการส่งมอบหลังจากจบการประชุมสปรินท์
รีวิว(Sprint Review) หรือไม่? โปรดักส์โอนเนอร์(Product Owner) ที่ดีจะปรับปรุงแผนของการส่งมอบทุกรอบการทํางาน และนั่นอาจจะหมายถึงอาจจะมีงานบางชิ้นต้องเลื่อนออกไปหากค้นพบว่ามีงานชิ้นที่สําคัญกว่าต้องทําก่อน
ส่วนที่ 2 - ทีมของฉันเป็ นอย่างไรบ้าง?
ในขณะที่ คุณได้รบั การสนั บสนุ นให้ เป็ นผู้ นําด้วยวิ ธีการทําให้ ดูเป็ นตัวอย่างโดยร่วมมื อกับสมาชิ กในที มฝึกฝนผ่ านการทํางานของพวกเขา จึงมีความเสี่ยงที่คุณจะจมลงไปในงานและรายละเอียดทางเทคนิคได้ง่าย สิ่งเหล่านีค้ ือสิ่งที่ต้องพิจารณาและเป็ นความรับผิดชอบหลักของคุณต่อทีม
ทีมของคุณอยู่ในสถานะที่เรียกว่า “ไหลลื่น”(Flow) หรือไม่? โดยทั่วไปจะหมายถึงทีมมีคุณลักษณะดังต่อไปนี ้- เข้าใจเป้ าหมายชัดเจน (ความคาดหวังที่จะบรรลุเป้ าหมาย สอดคล้องกับทักษะและความสามารถ)- มีสมาธิจดจ่ออยู่กับงานที่ทํา- สมาชิกทุกคนมั่นใจและ รูต้ ัวดี ว่ากําลังทําอะไรอยู่- ได้ฟดี แบ็กค์(Feedback) จากกิจกรรมที่ทําอย่างชัดเจน และทันที (ทั้งในส่วนของ ความสําเร็จและความผิดพลาด ทําให้สามารถปรับปรุงพฤติกรรมได้ทันทีตามความจําเป็ น)- มีความสมดุลระหว่างระดับความสามารถ และความท้าทาย (งานที่ทําไม่ยากหรือว่าง่ายเกินไป)- มีความรูส้ ึกมั่นใจ ว่าสามารถควบคุมสถานะการหรือกิจกรรมที่ทําได้- งานที่ทํา ทําให้เขารูส้ ึกมีคุณค่าไม่รูส้ ึกเสียแรงเปล่าสมาชิกในทีมมีเรื่องที่มีปัญหากันเข้าใจผิดกันหรือโอกาสในการปรับปรุงที่ทีม ไม่ได้พูดคุยกันเพราะความเกรงใจหรืออึดอัดหรือไม่?
คุณมีความหลากหลายของวิธกี ารหรือสถานที่ในการทําสปรินท์เรโทรสเปคทีฟ(Sprint Retrospective)หรือไม่?
ทีมจะทํางานอย่างมุ่งมั่นเพื่อให้ทําตามเป้ าหมายของรอบการทํางานนั้น ๆ หรือไม่ คุณอาจจะลองหากิจกรรมเพื่อตรวจสอบ กลางรอบการทํางานเพื่อตรวจสอบว่าทีมยังคงการทํางานเพื่อให้บรรลุเป้ าหมายตามรายละเอียดของแต่ละชิ้นงานที่รบั เข้ามาในรอบการทํางานนีห้ รือไม่?
สปรินท์แบ็คล็อก(Sprint Backlog) สะท้อนงานจริงที่ทีมกําลังทําอยุ่หรือไม่? ระวังงานที่ซ่อนอยู่(ทีมทําอยู่แต่ไม่อยู่บนสปรินท์แบ็คล็อก(Sprint Backlog) และงานที่ต้องใช้เวลามากกว่าหนึ่งวัน รวมถึง
งานที่ไม่เกีย่ วข้องกับข้อตกลงของงานในรอบการทํางานนั้น ๆ
Copyright © 2007-2016 Michael James. All Rights Reserved. และพงษ์ศักดิ์ ฤทธิ์พิทักษ์พงศ์

4สมาชิกในทีมแต่ละคนชื่นชอบพอซึ่งกันและกัน ออกไปสนุกด้วยกัน ฉลองให้กับความสําเร็จของกันและ
กันหรือไม่?
สมาชิกในทีมมีความรับผิดชอบต่อกันและกันสูง และท้าทายกันและกันเพื่อเติบโตอยู่เสมอหรือไม่?
ทีมงานมีจํานวนสมาชิกระหว่าง 3-9 คนโดยผสมผสานทักษะต่าง ๆ ที่จําเป็ นต้องใช้ในการพัฒนาผลิต
ภัณท์หรือไม่?
สปรินท์แบ็คล็อก(Sprint Backlog) ได้รบั การปรับปรุงอยู่ตลอดหรือไม่?
สิ่งของหรืออุปกรณ์ต่าง ๆ ที่ทีมต้องใช้งานเพื่อให้ทีมสามารถบริหารจัดการตัวเองได้ ถูกจัดไว้ให้เห็นได้
อย่างชัดเจน และทีมสามารถใช้งานได้อย่างสะดวกหรือไม่?
สปรินท์แบ็คล็อก(Sprint Backlog) ถือเป็ นทรัพย์สินของทีม ทั้งนีเ้ พื่อช่วยให้ทีมใช้ในการบริหารจัดการ
ตัวเอง คุณได้ทําให้ม่ันใจว่าสปรินท์แบ็คล็อก(Sprint Backlog) ของทีมไม่ถูกคนที่ไม่ใช่ทีม เช่นโปรดักส์โอนเนอร์(Product Owner) ผู้จัดการ หรือคนที่ไม่ได้อยูในทีม นําไปใช้เป็ นข้อมูลในการตัดสินให้คุณหรือโทษใด ๆ ทั้งสิ้น หรือไม่?
สมาชิกในทีมอาสาที่จะหยิบชิ้นงานไปทําเองหรือไม่?
มีความต้องการที่จะลดหรือกําจัดหนีท้ างเทคนิค และได้ถูกทําเป็ นข้อตกลงในคําจัดกัดความของคําว่า
เสร็จ(Definition of Done) อย่างชัดเจน เพื่อค่อย ๆ ทําให้ชุดรหัส(Source Code) เป็ นของที่น่าทํางานขึ้นเรื่อย ๆ อยู่เสมอหรือไม่?
สมาชิกในทีมไม่ได้ให้ความสําคัญกับชื่อตําแหน่ง และร่วมด้วยช่วยกันทํางานทุกอย่างเป็ นทีมเพื่อให้งาน
สําเร็จ (การทดสอบ, จัดทําเอกสาร, …) หรือไม่?
ส่วนที่ 3 -- ความชํานาญทางวิศวกรรมของทีมของฉันเป็ นอย่างไรบ้าง?
ในระบบที่ใช้ในการพัฒนาของคุณมีปุ่มที่ช่ือว่า “Push to Test” และอนุญาตให้สมาชิกทุกคน (ไม่ว่าจะในทีมเดียวกัน หรือต่างทีม) สามารถกดเพื่อตรวจสอบว่าสิ่งที่แก้ไขทําให้ฟังก์ช่ันงานเดิมที่เคยทํางานได้บกพร่องหรือไม่ ปกติแล้วสามารถใช้ xUnit Framework ต่าง ๆ เช่น JUnit, NUnit เป็ นต้นคุณให้สมดุลระหว่างการทดสอบการทดสอบระบบอัตโนมัติ(End-To-End Test) และการทดสอบหน่วยย่อยอัตโนมัติ(Unit Test) อย่างเหมาะสมหรือไม่?
ทีมใช้ภาษาในการเขียนการทดสอบระบบและ การทดสอบหน่วยย่อย(Unit Test) เป็ นภาษาเดียวกันกับ
ระบบที่พวกเขากําลังพัฒนาหรือไม่? เราจะไม่สามารถพัฒนาการทํางานร่วมกันได้หากใช้ภาษาพิเศษหรือระบบในการทดสอบที่ มีแค่ส่วนหนึ่งของทีมเท่านั้นที่รูว้ ิธกี ารดูแลรักษา
ทีมทราบถึงความคล้ายคลึงระหว่าง การทดสอบระบบ(System test) และการทดสอบหน่วยย่อย(Unittest) หรือไม่?

Copyright © 2007-2016 Michael James. All Rights Reserved. และพงษ์ศักดิ์ ฤทธิ์พิทักษ์พงศ์

5การควบรวมต่อเนื่อง(Continuous Integration) มีการส่งเสียงหรือแจ้งเตือนอัตโนมัติเมื่อมีสมาชิกทําให้ระบบที่เคยทํางานได้บกพร่องหรือไม่? และพยายามลดเวลาของการได้รบัฟีดแบ็กค์(Feedback) นีล้ งได้เรื่อยๆ ตัง้ แต่ระดับชั่วโมง จนถึงไม่กีน่ าทีผลการทดสอบทั้งหมดได้ถูกรวบรวมเข้ากับ ระบบการควบรวมต่อเนื่อง(Continuous Integration)หรือไม่?
ทีมของคุณพบความสนุกของการออกแบบอย่างต่อเนื่องและ การปรับปรุงอย่างสมํ่าเสมอ(Refactor)ในเวลาที่เหมาะสมหรือไม่? การออกแบบและการปรับปรุงอย่างต่อเนื่องถือเป็ นทางเลือกแทนการทําการออกแบบเผื่อเพื่อความสมบูรณ์แบบ(Up Front Design) การปรับปรุงอย่าง
สมํ่าเสมอ(Refactoring) มีข้อกําหนดที่เคร่งครัด หมายถึง การทําการเปลีย่ นแปลงโครงสร้างภายในโดยไม่เปลีย่ นแปลงพฤติกรรมภายนอก โดยทั่วไปการปรับปรุงสมํ่าเสมอ(Refactor) ควรเกิดขึ้นอย่างน้อย7-9 ครัง้ ต่อชั่วโมง หรือเมื่อไหร่ก็ตามที่เกิดความซํ้าซ้อน ตรรกที่ซับซ้อน (เห็นได้ชัดจาก Method ที่ยาวๆ) การตัง้ ชื่อที่ไม่ส่ือความหมาย หรือการที่ Object ผูกติดกันแน่น เป็ นต้น อย่างไรก็ตามการปรับปรุง
สมํ่าเสมอ(Refactor) จะเกิดขึ้นได้เมื่อมีการทดสอบอัตโนมัติที่ครอบคลุม การละเลยการปรับปรุงสมํ่าเสมอ ทําให้ระบบยากต่อการเปลีย่ นแปลงในอนาคตโดยเฉพาะการหา นักพัฒนาเก่ง ๆ ที่ยินดีมาทํางานต่อบนระบบที่แย่คําจํากัดความของคําว่าเสร็จ(Definition of Done) สําหรับแต่ละชิ้นงานได้รวมถึงความครอบคลุมของการทําการทดสอบอัตโนมัติ และการปรับปรุงสมํ่าเสมอ(Refactor) แล้วหรือไม่? คุณสามารถเพิ่มความเป็ นไปได้ด้วยการเรียนรูเ้ ทคนิค การขับเคลื่อนการพัฒนาด้วยการทดสอบ(Test DrivenDevelopment)ทีมใช้เวลาส่วนใหญ่ในการใช้เทคนิคการทํางานเป็ นคู่หู(Pair Programming) หรือไม่? การทํางานเป็ นคู่หู(Pair Programming) สามารถเพิ่มความสามารถของ การบํารุงรักษาระบบ รวมถึงการลดจํานวนข้อผิดพลาด ได้อย่างมาก มันอาจจะดูเชื่อได้ยากมาก โดยเฉพาะเมื่อเราวัดผลลัพธ์ จากจํานวนบรรทัดของชุดรหัส(Source Code) ที่เขียนได้ มากกว่าการวัดที่ ฟั งชั่นงานที่สามารถส่งมอบได้จริง คุณสามารถใช้วิธกี ารทําให้ดูเป็ นตัวอย่าง ได้โดยการเริ่มเป็ นคู่หูของสมาชิกในทีมและทํางานด้วยกันสักวันนึง หรือบางคนอาจชอบกับการทํางานเป็ นคู่หู(Pair Programming) ตัง้ แต่ต้นอยู่แล้วส่วนที่ 4 -- องค์กรของคุณเป็ นอย่างไรบ้างมีการประสานงานระหว่างทีมอย่างเหมาะสมหรือไม่? “Scrum of Scrums” อาจจะไม่ใช่วิธที ี่ดีที่สุดยังคงมีวิธอี ่ืนที่น่าจะส่งเสริมให้เกิดการประสานงานกัน
ทีมแต่ละทีมสามารถสร้างส่งมอบชิ้นงาน(Feature) ที่สามารถทํางานได้อย่างอิสระต่อกันหรือไม่?
ถึงแม้ว่าการแก้ไขต้องข้ามเส้นแบ่งของสถาปั ตยกรรมของระบบก็ตามสกรัมมาสเตอร์(ScrumMaster) ได้มีการนัดพบกันเองในกลุ่มสกรัมมาสเตอร์(ScrumMaster) เพื่อช่วยกันแก้ไขอุปสรรคขององค์กรหรือไม่?
Copyright © 2007-2016 Michael James. All Rights Reserved. และพงษ์ศักดิ์ ฤทธิ์พิทักษ์พงศ์

6อุปสรรคต่าง ๆ ขององค์กรได้ถูกทําให้ผู้มีอํานาจแก้ไขเปลีย่ นแปลงรับทราบในทุกเวลาที่เป็ นไปได้ หรือไม่? อุปสรรคดังกล่าวอาจจะส่งผลให้ต้นทุนสูงขึ้น ส่งมอบของสู่ตลาดได้ช้าลง คุณภาพลดลง หรือทําให้ลูกค้าเสียโอกาส อย่างไรก็ตาม สิ่งที่ได้เรียนรูจ้ ากความผิดพลาดของ เคน ชเวบเบอร์(Ken Schwaber)คือ “สกรัมมาสเตอร์(ScrumMaster) ที่ตายแล้วคือสกรัมมาสเตอร์(ScrumMaster) ที่ไม่มีประโยชน์”คุณได้ทําการช่วยเหลือและทําความเข้าใจถึง นโยบายของฝ่ ายทรัพยากรบุคคลเพื่อลดความเข้าใจผิดเรื่องของความก้าวหน้าในสายอาชีพ เช่น การเป็ นนักพัฒนา และนักทดสอบระบบ ได้รบั ค่าตอบแทนที่ต่างกันมากหรือ เขียนโปรแกรมให้เก่งเพื่อให้เป็ นผู้จัดการที่ไม่ต้องเขียนโปรแกรมอีกองค์กรของคุณได้รบั การยอมรับจากสื่อต่าง ๆ ว่าเป็ นที่ที่น่าทํางานมากที่สุดหรือ เป็ นผู้นําในธุรกิจหรือไม่?
คุณได้พยายามสร้างองค์กรแห่งการเรียนรูห้ รือไม่?
บทสรุปถ้าคุณทําเครื่องหมายถูกในหัวข้อส่วนใหญ่ที่กล่าวมาและยังพอมีเวลาเหลือ ผมยินดีรบั ฟั งความเห็นของคุณมันไม่มีสูตรสําเร็จที่สามารถทําให้มนุษย์ฉลาดขึ้นในทุก ๆ บริบท เอกสารฉบับนีไ้ ด้แสดงถึงรายการที่อาจจะช่วยหรือไม่ช่วยก็ได้ในบริบทที่คุณกําลังเจอ
เมื่อคุณตระหนักได้ว่าคุณจะสร้างความแตกต่างให้เกิดขึ้นได้อย่างไร หรือคุณอาจจะพบว่าคุณกลัวที่จะทํามัน นี่ถือเป็ นสัญญานว่าคุณมาถูกทางแล้วของการเป็ นสกรัมมาสเตอร์(ScrumMaster) ที่ยอดเยีย่ ม

Copyright © 2007-2016 Michael James. All Rights Reserved. และพงษ์ศักดิ์ ฤทธิ์พิทักษ์พงศ์

7แบบฟอร์มอุปสรรคขององค์กรปั ญหาที่พบ :ต้นเหตุของปั ญหา (ใช้เทคนิคการถามทําไม ห้าครัง้ ) :ผลกระทบต่อธุรกิจ :ผมกระทบต่อความรูส้ ึก :ความเข้าใจ หรือ รายการที่จะดําเนินการ :แบบฟอร์มอุปสรรคขององค์กรปั ญหาที่พบ :ต้นเหตุของปั ญหา (ใช้เทคนิคการถามทําไม ห้าครัง้ ) :ผลกระทบต่อธุรกิจ :ผมกระทบต่อความรูส้ ึก :ความเข้าใจ หรือ รายการที่จะดําเนินการ :Copyright © 2007-2016 Michael James. All Rights Reserved. และพงษ์ศักดิ์ ฤทธิ์พิทักษ์พงศ์

8คําแนะนําหากคุณได้รบั เอกสารฉบับนีเ้ พื่อเป็ นแบบสอบถามในการอบรมและสถานการณ์ที่คุณกําลังเผชิญอยู่คือการพยายาม
ทําบางอย่างที่ดูคล้าย Scrum ขอให้คุณนึกถึงภาพที่คุณเคยเห็นมา และทําเครื่องหมายในข้อต่าง ๆ ดังนี ้√ สําหรับ “ทําได้ดี”∆ สําหรับ “สามารถทําให้ดีกว่านีไ้ ด้ และคุณรูว้ ่าจะเริ่มทําอย่างไร”? สําหรับ “สามารถทําให้ดีกว่านีไ้ ด้ แต่คุณไม่รูว้ ่าจะทําอย่างไร”N/A สําหรับ “ไม่เหมาะสม หรือ อาจจะไม่มีประโยชน์”หรือ สถานการณ์ที่คุณเผชิญอยู่คือการพยายามใช้ Scrum กรุณานึกถึงภาพที่คุณเคยเห็นมา และทําเครื่องหมาย
ในข้อต่าง ๆ ดังนี ้√ สําหรับ “ทําได้ดี” หรือ “น่าจะทําให้ดีได้ไม่ยาก”∆ สําหรับ “เป็ นเรื่องที่ท้าทาย และคุณรูว้ ่าจะเริ่มทําอย่างไร”? สําหรับ “เป็ นเรื่องที่ท้าทาย แต่คุณไม่รูว้ ่าจะทําอย่างไร”N/A สําหรับ “ไม่เหมาะสม หรือ อาจจะไม่มีประโยชน์”เมื่อคุณทําเครื่องหมายครบทุกข้อแล้ว ให้ลองนึกถึงอุปสรรคที่องค์กรของคุณกําลังเจอ 2-6 ข้อโดยใช้แบบฟอร์ม
อุปสรรคขององค์กรตามที่แนบมา ไม่ว่ามันจะเพิ่งค้นพบจากการทํารายการนีห้ รือไม่ก็ตาม จากนั้นเลือกอุปสรรคที่
คุณรูส้ ึกมีความหวังอย่างน้อย 1% ที่คุณสามารถที่จะเปลีย่ นแปลงมันได้ แล้วทํามัน

Copyright © 2007-2016 Michael James. All Rights Reserved. และพงษ์ศักดิ์ ฤทธิ์พิทักษ์พงศ์