นักพัฒนาใช้วิธีใดในการประเมินงาน?

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

จะทำอย่างไรถ้าคุณไม่ได้รับคะแนนที่ถูกต้อง?

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

มีการประเมินเวลาอย่างไร?

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

คะแนนเรื่องราวคืออะไร

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

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

วิธีที่จะไม่ใช้คะแนนเรื่องราว

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

Scrum Poker คืออะไร

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

ไม่ทราบจำนวนจุดสิ้นสุด

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

ต้องการพัก

วิธีการประมาณค่าที่หายากมากขึ้น:

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

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

ตัวอย่างการประเมินงาน

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

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

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

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

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