ทำตามกำหนดเวลาของคุณ: วิธีการที่นักพัฒนาใช้ในการประเมินความพยายาม

สวัสดีทุกคน! มีทฤษฎีจำนวนมากที่คุณจำเป็นต้องรู้เพื่อเริ่มต้นในการพัฒนาซอฟต์แวร์ ผู้เชี่ยวชาญบางคน (เช่น นักพัฒนาแบ็คเอนด์ที่ใช้ Java และภาษาอื่นๆ) รู้เรื่องนี้มากกว่า ในขณะที่คนอื่นๆ (เช่น นักพัฒนาส่วนหน้าที่ใช้ JavaScript และ React Native) อาจรู้น้อยกว่าเล็กน้อย ที่กล่าวว่าทั้งสองกลุ่มต้องมีเนื้อหาขนาดใหญ่ไม่เพียง แต่ความรู้ด้านเทคนิคเท่านั้น แต่ยังต้องมีความรู้ด้าน "องค์กร" ด้วย ความรู้ "องค์กร" นี้เป็นส่วนที่ทับซ้อนกันสำหรับนักพัฒนาส่วนหน้าและส่วนหลัง วันนี้ฉันต้องการพูดคุยเกี่ยวกับแง่มุมของความรู้ที่ไม่ใช่ด้านเทคนิคขององค์กร วันนี้เราจะพูดถึงการประมาณค่าความพยายาม เพราะฉันมีประสบการณ์การใช้ระเบียบวิธีแบบอไจล์ เท่านั้น(ซึ่งถือว่าเป็นที่นิยมมากที่สุด) โดยเฉพาะอย่างยิ่ง Scrum framework ฉันจะพิจารณาการประมาณค่าความพยายามในบริบทของScrum ในตอนแรกต้องบอกว่าการประมาณค่าความพยายามนั้นยาก สำหรับฉัน มันเป็นหนึ่งในแง่มุมที่ท้าทาย/ไม่น่าพอใจที่สุดในงานของฉันในฐานะนักพัฒนา มีหลายปัจจัยที่ต้องพิจารณาซึ่งอาจส่งผลต่อการประมาณการความพยายามที่จำเป็นสำหรับงานหนึ่งๆ นอกจากนี้ แผนการพัฒนาในอนาคตจะขึ้นอยู่กับการประมาณการของคุณ

จะเกิดอะไรขึ้นถ้าคุณให้ค่าประมาณที่ไม่ถูกต้อง

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

วิธีทำประมาณการเวลา

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

จุดเรื่องราวคืออะไร?

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

• คุณสามารถหลีกเลี่ยงการประมาณเวลาที่ไม่ถูกต้องได้
• Story point แตกต่างจากการประมาณการในหน่วยเวลาตรงที่ Story point ให้คุณคำนึงถึงต้นทุนค่าใช้จ่าย: การสื่อสารระหว่างสมาชิกในทีมและลูกค้า การอภิปรายของทีมและกิจกรรมการวางแผนต่างๆ ตลอดจนสถานการณ์ที่ไม่คาดฝัน
• แต่ละทีมจะประเมินงานของตนโดยใช้มาตราส่วนที่แตกต่างกัน ซึ่งหมายความว่าความสามารถของพวกเขา (วัดเป็นคะแนน) จะแตกต่างกัน
• การกำหนดสเกลสำหรับการกำหนดแต่ละจุดของเรื่องราวจะช่วยให้คุณจัดสรรจุดต่าง ๆ ได้อย่างรวดเร็วโดยไม่มีข้อโต้แย้งมากนัก

วิธีไม่ใช้จุดเรื่องราว

น่าเสียดายที่ประเด็นเรื่องราวมักถูกใช้ในทางที่ผิด ประเด็นเรื่องราวอาจทำให้เข้าใจผิดได้เมื่อนำไปใช้ในการประเมินบุคคล กำหนดเส้นตายและทรัพยากรโดยละเอียด และเมื่อเข้าใจผิดว่าเป็นการวัดผลการปฏิบัติงาน ทีมควรใช้เพื่อทำความเข้าใจขอบเขต/ความซับซ้อนของแต่ละงานและเพื่อกำหนดลำดับความสำคัญ บางทีส่วนที่ถือว่ายากกว่าควรจัดการก่อน จึงจะเสร็จก่อนจบสปรินต์อาจเปลี่ยนงานที่ง่ายกว่าไปทำทีหลัง ฉันขอเตือนคุณว่า Sprint คืออะไรในบริบทของ ระเบียบวิธี Scrum : ระยะเวลาของช่วงเวลานี้จะถูกกำหนดเมื่อการพัฒนาเริ่มต้นขึ้นและมีการตกลงระหว่างทีมและลูกค้า อาจเป็นช่วงเวลาสองสัปดาห์หรือหนึ่งเดือน หรือช่วงเวลาอื่นๆ ตามกฎแล้ว การประมาณการความพยายามจะทำขึ้นที่จุดเริ่มต้นของการวิ่งแต่ละครั้ง เพื่อวางแผนงานที่สามารถทำให้เสร็จได้เมื่อสิ้นสุดการวิ่ง เมื่องานที่เสร็จสมบูรณ์ถูกส่งไปยังลูกค้า การสาธิตช่วยให้คุณเห็นความคืบหน้าในการพัฒนาผลิตภัณฑ์ รับคำติชมจากลูกค้า และปรับแนวทางการดำเนินโครงการตามวิสัยทัศน์ของลูกค้า แต่เราพูดนอกเรื่องเล็กน้อย กลับไปที่ค่าประมาณกัน มันจะเป็นอัตนัยเกินไปที่จะให้นักพัฒนาเพียงรายเดียวให้ค่าประมาณสำหรับงานทั้งหมด ดังนั้นกระบวนการนี้มักจะเป็นความพยายามของทีม มีเทคนิคค่อนข้างน้อยที่ทีมสามารถใช้เพื่อสร้างค่าประมาณได้ วันนี้เราจะมาดูเทคนิคยอดนิยม: การ ต่อสู้โป๊กเกอร์ เทคนิคนี้ต้องการผู้จัดการที่จะทำหน้าที่เป็นผู้ดูแลการต่อสู้โป๊กเกอร์ นี่อาจเป็นคนที่เป็นปรมาจารย์ด้านการต่อสู้หรืออาจเป็นPMก็ได้

สครัมโป๊กเกอร์คืออะไร?

Scrum Pokerหรือการวางแผนโป๊กเกอร์เป็นเทคนิคการประมาณการที่ขึ้นอยู่กับการบรรลุข้อตกลง ส่วนใหญ่ใช้เพื่อประเมินความซับซ้อนของงานข้างหน้าหรือขนาดสัมพัทธ์ของงานพัฒนาซอฟต์แวร์ ฉันจะพูดทันทีว่าการต่อสู้โป๊กเกอร์เป็นแนวทางปฏิบัติในการพัฒนาซอฟต์แวร์ทั่วไป และคุณจำเป็นต้องรู้ว่ามันเกี่ยวกับอะไร โดยปกติจะเกี่ยวข้องกับแอปหรือเว็บไซต์เพื่ออำนวยความสะดวกในการทำงานร่วมกันของทีมในการสร้างค่าประมาณสำหรับงานเฉพาะ สิ่งนี้เกิดขึ้นได้อย่างไร? ทีมนำบางอย่างจากงานในมือ (งานใหม่ ฟังก์ชันการทำงานบางอย่าง) และหารือสั้น ๆ ถึงข้อผิดพลาดที่อาจเกิดขึ้นและความแตกต่างอื่น ๆ ที่เกี่ยวข้อง จากนั้นผู้เข้าร่วมแต่ละคนเลือกการ์ดที่มีตัวเลขที่สะท้อนถึงความซับซ้อนที่ประเมินไว้ อ้อ อีกอย่างหนึ่ง เมื่อทำการประมาณค่าเหล่านี้ เราใช้ตัวเลขในลำดับฟีโบนัชชีแทนที่จะเป็นตัวเลขธรรมดา ตัวเลข Fibonacciเป็นที่นิยมในการต่อสู้โป๊กเกอร์เนื่องจากมีช่องว่างที่ใหญ่ขึ้นเรื่อย ๆ ระหว่างพวกเขา (คล้ายกับระดับของพีระมิด) งานบางอย่างจะมีความซับซ้อนสูง และเราจะไม่สามารถหลีกหนีจากเรื่องราวเล็กๆ น้อยๆ ได้ มีการ์ดที่ผิดปกติบางอย่างที่มีความหมายดังต่อไปนี้:

ไม่ทราบจำนวนปลายทาง

งานยาวไม่สิ้นสุด

ต้องการพัก

วิธีการประมาณค่าที่ใช้กันน้อย:

• ขนาดเสื้อยืด — S, M, L, XL
• สายพันธุ์สุนัข — ชิวาวา ปั๊ก ดัชชุนด์ บูลด็อก และอื่นๆ (โดยส่วนตัวแล้วฉันคิดว่านี่เป็นหน่วยวัดความพยายามที่แปลกที่สุด =D)

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

ตัวอย่างการประมาณค่าความพยายาม

สมมติว่าทีมของคุณสร้างมาตราส่วนต่อไปนี้เพื่อกำหนดประเด็นเรื่องราวให้กับการประมาณการ: มีการเล่น Scrum Pokerสำหรับแต่ละงาน และคุณให้ค่าประมาณดังนี้:

• คุณไม่เคยใช้ฟังก์ชันที่คล้ายกันมาก่อน: +3
• ฟังก์ชันมีขนาดเฉลี่ย: +2
• การใช้งานจะซับซ้อนมาก: +3
• การทดสอบการเขียนสำหรับการทำงานจะมีความซับซ้อนสูง: +3

เมื่อรวมองค์ประกอบแต่ละส่วนเข้าด้วยกัน คุณจะได้แต้มเรื่องราวทั้งหมด 11 แต้ม แต่ไม่มีการ์ดดังกล่าว ดังนั้นคุณจึงแนะนำ 13 แต้ม เพื่อนร่วมงานคนหนึ่งเสนอค่าประมาณต่อไปนี้สำหรับงาน:

• เขาเคยทำงานที่คล้ายกันมาก่อน: +1
• ฟังก์ชันมีขนาดเฉลี่ย: +2
• การใช้งานจะมีความซับซ้อนโดยเฉลี่ย: +2
• การทดสอบการเขียนสำหรับฟังก์ชันการทำงานจะมีความซับซ้อนโดยเฉลี่ย: +2

ผลลัพธ์ขั้นกลางของเขาคือ 7 สตอรี่พอยต์ แต่ไม่มีตัวเลขนั้นในซีรีส์ฟีโบนัชชี ดังนั้นเขาจึงส่งการ์ดด้วยตัวเลขโดยประมาณมากที่สุด — 8 สมาชิกในทีมคนอื่นๆ ทำการประมาณการตามมุมมองส่วนตัว จากนั้นทุกคนก็แสดงการ์ดของตน และคุณจะพบว่าเพื่อนร่วมงานของคุณเกือบทั้งหมดให้ค่าประมาณ 13 ยกเว้นนักพัฒนาคนหนึ่งที่เสนอ 8 ในกรณีนี้ เขาได้รับอนุญาตให้พูดเพื่อให้เหตุผลสำหรับค่าประมาณที่ต่ำกว่าของเขา สมมติว่าเขาเสนอเหตุผลนี้: ก่อนหน้านี้เขาเคยทำงานเดียวกันและไม่ยากอย่างที่คิด ในท้ายที่สุด เขาโน้มน้าวให้ทุกคนในทีมเปลี่ยนใจจาก 13 เป็น 8 สตอรี่พอยต์ โดยบอกว่าเขาจะช่วยใครก็ตามที่จบงานนี้ หรือบางทีเขาจะทำมันเอง ไม่ว่าในกรณีใด ไม่สำคัญว่าคนอื่นจะยอมรับข้อโต้แย้งของเขาหรือไม่ เพราะไม่ทางใดก็ทางหนึ่งจะมีการประมาณการให้กับงาน และทีมจะพิจารณาข้อถัดไป ในขั้นต้น การประมาณการจะไม่ถูกต้อง เช่นเดียวกับการประมาณการปริมาณงานที่คุณวางแผนจะทำให้เสร็จในช่วงเวลาถัดไป (sprint) ท้ายที่สุดการประมาณเหล่านี้ทำขึ้นโดยใช้การประมาณการ เมื่อเวลาผ่านไปสักสามเดือน ทีมจะเริ่มประเมินเวลาที่ต้องใช้สำหรับงานต่างๆ ได้แม่นยำขึ้น และปริมาณงานโดยเฉลี่ยที่ทีมสามารถดำเนินการได้ในระยะเวลาสั้นๆ จะปรากฏชัดเจน แต่นี่เป็นกระบวนการในการจัดทำแผนทั่วไปสำหรับขอบเขตของงาน โดยมุ่งเน้นที่เวลาเป็นหลัก แต่ในกรณีนี้ อาจมีปัจจัยที่เกี่ยวข้องหลายประการ ตัวอย่างเช่น สมมติว่านักพัฒนาซอฟต์แวร์ไปพักร้อนเป็นเวลาสองสัปดาห์ คุณจะต้องตัดงานที่วางแผนไว้จำนวนหนึ่ง (ฟังก์ชันการทำงานที่วางแผนไว้) หรือสมมติว่ามีนักพัฒนารายใหม่เข้าร่วมทีม แต่ยังไม่พร้อมเต็มที่ ดังนั้นคุณต้องให้เวลาเธอทำความคุ้นเคยกับโครงการผ่านขั้นตอนการขึ้นเครื่อง อาจใช้เวลาสองสัปดาห์ ให้เวลาหรือใช้เวลาหนึ่งสัปดาห์ ขึ้นอยู่กับความซับซ้อนของโครงการ นั่นคือทั้งหมดสำหรับวันนี้! ฉันหวังว่าฉันจะปรับปรุงความรู้ของคุณเล็กน้อยเกี่ยวกับการประมาณค่าความพยายาม ซึ่งเป็นแง่มุมที่ไม่ใช่ด้านเทคนิคที่จำเป็นสำหรับการพัฒนาซอฟต์แวร์ หากคุณต้องการลงลึกในหัวข้อนี้และรายละเอียดของการต่อสู้ ฉันขอแนะนำให้คุณอ่านหนังสือ "SCRUM" โดย Jeff Sutherland ฉันไม่สามารถให้คำมั่นสัญญาใดๆ เกี่ยวกับผลที่ตามมาได้ เพราะหลังจากอ่านแล้ว คุณจะมีความปรารถนาที่น่ารำคาญที่จะเป็นปรมาจารย์การต่อสู้ =D