สวัสดีทุกคน! ทฤษฎีที่จำเป็นในการเริ่มต้นการพัฒนานั้นกว้างขวางมาก ผู้เชี่ยวชาญบางคน (นักพัฒนาแบ็กเอนด์ใน Java และภาษาอื่นๆ) มีมากกว่านั้น ในขณะที่คนอื่นๆ (เช่น นักพัฒนาส่วนหน้าใน JavaScript - React Native) มีน้อยกว่าเล็กน้อย อย่างไรก็ตาม ทั้งสองคนต้องมีสต็อกจำนวนมากไม่เพียงแต่ความรู้ด้านเทคนิคเท่านั้น แต่ยังรวมถึงความรู้ "เชิงองค์กร" ด้วย ความรู้เกี่ยวกับ "องค์กร" นี้เป็นหนึ่งในจุดตัดสำหรับนักพัฒนาส่วนหน้าและส่วนหลัง
![“ ตรงตามกำหนดเวลา”: นักพัฒนาใช้วิธีการใดในการประเมินงาน - 1]()
วันนี้ฉันต้องการพูดคุยเกี่ยวกับแง่มุมหนึ่งของความรู้ที่ไม่ใช่เชิงเทคนิคและเชิงองค์กร - เกี่ยวกับ
การประเมินงาน (การประมาณค่า) และเนื่องจากฉันทำงานเฉพาะใน วิธี
Agile เท่านั้น (ซึ่งอันที่จริงแล้วถือว่าได้รับความนิยมมากที่สุด) ในส่วนย่อยScrum
ฉันจะพิจารณาการประเมินงานในบริบทของ
Scrum ฉันจะบอกทันทีว่าการประเมินหรือที่เรียกว่าการประมาณค่านั้นเป็นเรื่องยาก สำหรับฉันเป็นการส่วนตัวในฐานะนักพัฒนา นี่เป็นหนึ่งในแง่มุมที่ยาก/ไม่พึงประสงค์ที่สุดของงานนี้ มีหลายปัจจัยที่ต้องพิจารณาซึ่งสามารถมีอิทธิพลต่อการประเมินงานได้ ในขณะเดียวกัน แผนการพัฒนาเพิ่มเติมจะขึ้นอยู่กับการคาดการณ์ของคุณ
จะทำอย่างไรถ้าคุณไม่ได้รับคะแนนที่ถูกต้อง?
หากนักพัฒนาใช้เวลาหลายชั่วโมงกับงานมากกว่าที่จะใช้ในท้ายที่สุด อาจดูเหมือนว่าเขาไม่ใช่ผู้เชี่ยวชาญที่ดีที่สุด เนื่องจากการประมาณการนั้นไม่ถูกต้องมาก ถ้าจะพูดก็คือชูนิ้วบนท้องฟ้า ในเวลาเดียวกัน หากนักพัฒนาไม่ลงทุนในเวลาที่คาดการณ์ไว้ เขาจะเป็นอันตรายต่อแผนการของลูกค้าที่จะเปิดตัวผลิตภัณฑ์/ฟีเจอร์ใหม่ นี่คือธุรกิจและธุรกิจหมายถึงเงินและมีลูกค้าเพียงไม่กี่รายที่จะชอบการเจาะแบบนี้
![“ ตรงตามกำหนดเวลา”: นักพัฒนาใช้วิธีใดในการประเมินงาน - 2]()
นี่คือสาเหตุที่ฉันไม่ชอบการประมาณค่า เพราะบางครั้งการกำหนดเวลาที่แน่นอนในการทำงานให้สำเร็จก็ยากมาก
มีการประเมินเวลาอย่างไร?
ตามกฎแล้ว การประมาณค่าจะดำเนินการเป็นชั่วโมงหรือประเด็นของเรื่องราว โดยส่วนตัวแล้ว ฉันใกล้ชิดกับกระบวนการประเมินในประเด็น
เรื่องราว มากกว่ามาก หากนาฬิกาเป็นสิ่งที่จับต้องได้ ก็เป็นสิ่งที่สามารถเข้าใจผิดได้ ประเด็นของเรื่องราวเป็นเพียงสิ่งอื่นเล็กน้อยและเป็นนามธรรมมากกว่า โดยทั่วไปแล้ว ทีมพัฒนาซอฟต์แวร์จะให้การประมาณการในรูปแบบเวลา: ชั่วโมง วัน สัปดาห์ เดือน การประมาณเวลาดังกล่าวขึ้นอยู่กับประสบการณ์ส่วนตัว การคาดเดา หรือสัญชาตญาณเป็นหลัก ในกรณีนี้ นักพัฒนาเพียงแค่ดูงานและประเมินว่าจะใช้เวลานานแค่ไหน เป็นผลให้มีความแม่นยำน้อยมากเนื่องจากมีปัจจัยมากเกินไปที่อาจส่งผลต่อกำหนดเวลาในการทำงานให้เสร็จสิ้น ดังนั้นหลายทีมที่ทำงานตาม ระเบียบวิธี
แบบ Agileจึงใช้ประเด็นเรื่องราว ลองคิดดูสิ
คะแนนเรื่องราวคืออะไร
ประเด็นเรื่องคือหน่วยวัดที่แสดงออกถึงการประเมินความพยายามทั้งหมดที่จำเป็นในการทำให้งานเฉพาะด้าน (ฟังก์ชันการทำงาน) ทำงานได้อย่างเต็มที่ นั่นคือนี่เป็น ความ ซับซ้อน
สัมพัทธ์ ทีมกำหนดประเด็นเรื่องราวตามความซับซ้อนของงาน ขอบเขตของงาน และความเสี่ยงหรือความไม่แน่นอน โดยปกติแล้วค่าเหล่านี้จะถูกกำหนดให้แบ่งงานออกเป็นส่วนเล็กๆ ได้อย่างมีประสิทธิภาพมากขึ้น จึงช่วยลดความไม่แน่นอนได้ เมื่อเวลาผ่านไป สิ่งนี้จะช่วยให้ทีมเข้าใจสิ่งที่พวกเขาสามารถบรรลุผลสำเร็จในช่วงเวลาที่กำหนด และช่วยให้พวกเขาวางแผนงานด้านต่อไปได้แม่นยำยิ่งขึ้น สิ่งนี้อาจดูเหมือนขัดกับสัญชาตญาณโดยสิ้นเชิงสำหรับคุณ แต่สิ่งที่เป็นนามธรรมนี้มีประโยชน์มากจริงๆ: มันผลักดันให้ทีมทำการตัดสินใจที่เข้มงวดมากขึ้นเกี่ยวกับความซับซ้อนของงาน มาดูเหตุผลบางประการในการใช้ประเด็นเรื่องราวในการวางแผน:
- สามารถหลีกเลี่ยงความไม่ถูกต้องในการประมาณค่าในช่วงเวลาได้
- ต่างจากการประมาณค่าเมื่อเวลาผ่านไป ต้นทุนค่าโสหุ้ยสามารถนำมาพิจารณาได้ดีกว่า: การสื่อสารระหว่างสมาชิกในทีมและลูกค้า การอภิปรายและการวางแผนในทีมต่างๆ รวมถึงสถานการณ์ที่ไม่คาดฝัน
- แต่ละทีมจะให้คะแนนงานในระดับที่แตกต่างกัน ซึ่งหมายความว่าความเร็ว (วัดเป็นคะแนน) จะแตกต่างกัน
- ด้วยการกำหนดระดับสำหรับการกำหนดประเด็นเรื่องราวแต่ละจุด คุณสามารถกระจายประเด็นได้อย่างรวดเร็วโดยไม่มีข้อโต้แย้งมากนัก
วิธีที่จะไม่ใช้คะแนนเรื่องราว
น่าเสียดายที่ประเด็นเรื่องมักใช้เพื่อจุดประสงค์อื่น ประเด็นเรื่องอาจมีข้อบกพร่องได้เมื่อนำไปใช้ในการประเมินบุคคล กำหนดกำหนดเวลาและทรัพยากรโดยละเอียด และเมื่อใดที่ประเด็นเหล่านั้นถือเป็นการวัดประสิทธิภาพโดยไม่ได้ตั้งใจ แต่ทีมจำเป็นต้องใช้สิ่งเหล่านี้เพื่อทำความเข้าใจปริมาณ/ความซับซ้อนของงานในแต่ละงานและเพื่อจัดลำดับความสำคัญ เป็นไปได้ว่าชิ้นส่วนที่ได้รับการจัดอันดับว่ายากกว่าควรทำก่อนจึงจะเสร็จก่อนสิ้นสุดการ
วิ่งแต่ชิ้นส่วนที่ง่ายกว่าสามารถดันกลับเข้าไปใหม่ได้ในภายหลัง ฉันขอเตือนคุณว่า Sprint คืออะไรในบริบทของ วิธี
Scrum :
Sprintคือช่วงเวลาคงที่ที่สามารถทำซ้ำได้ในระหว่างที่มีการสร้างฟังก์ชันการทำงานบางส่วนที่วางแผนไว้ |
ระยะเวลานี้ถูกกำหนดไว้นานแค่ไหนในช่วงเริ่มต้นของการพัฒนาตามข้อตกลงระหว่างทีมงานและลูกค้า นี่อาจเป็นช่วงเวลาสองสัปดาห์ หนึ่งเดือน หรือช่วงเวลาอื่นๆ ตามกฎแล้ว การประมาณค่างานจะดำเนินการที่จุดเริ่มต้นของการวิ่งเพื่อวางแผนปริมาณงานที่เป็นไปได้ที่จะเสร็จสมบูรณ์ก่อนสิ้นสุดการวิ่ง เมื่อมีการส่งมอบงานที่เสร็จสมบูรณ์ให้กับลูกค้า
การนำเสนองานที่เสร็จสมบูรณ์ระหว่างการวิ่งให้กับลูกค้าเรียกว่าการสาธิต |
ช่วยให้คุณเห็นความก้าวหน้าในการพัฒนาผลิตภัณฑ์ รับคำติชมจากลูกค้า และปรับการพัฒนาโครงการตามวิสัยทัศน์ของลูกค้า แต่ถึงกระนั้น เราก็พูดนอกเรื่องเล็กน้อย: กลับมาที่การประมาณกันก่อน การประเมินงานโดยนักพัฒนาเพียงคนเดียวอาจเป็นเรื่องส่วนตัวเกินไป ดังนั้น ตามกฎแล้ว นี่คือการทำงานเป็นทีม มีเทคนิคบางประการในการประเมินทีม วันนี้เราจะมาดูสิ่งที่ใช้กันมากที่สุด - Scrum
Poker เทคนิค นี้ต้องใช้ผู้จัดการที่จะเป็นคนแบบผู้นำของ
Scrum Poker นี่ อาจเป็นบุคคลที่เชี่ยวชาญใน
Scrum Masterหรือ
PM
Scrum Poker คืออะไร
Scrum Poker - หรือการวางแผนโป๊กเกอร์ - เป็นเทคนิคการประเมินที่ขึ้นอยู่กับการบรรลุข้อตกลง ส่วนใหญ่จะใช้เพื่อประเมินความซับซ้อนของงานข้างหน้าหรือปริมาณงานสัมพัทธ์ที่จะแก้ไขในระหว่างการพัฒนาซอฟต์แวร์ ฉันจะทราบทันทีว่า
Scrum Pokerเป็นวิธีปฏิบัติทั่วไปในการพัฒนา และคุณจำเป็นต้องรู้อย่างแน่นอนว่ามันเป็นสัตว์ร้ายชนิดใด สำหรับกระบวนการนี้ เรามักจะใช้แอปพลิเคชันหรือเว็บไซต์บางประเภทที่ช่วยให้เราสามารถจัดการประเมินทีมสำหรับงานเฉพาะได้ สิ่งนี้เกิดขึ้นได้อย่างไร? ทีมงานรับงานที่ค้างอยู่ (งานใหม่ ฟังก์ชันการทำงาน) อภิปรายสั้นๆ ถึงข้อผิดพลาดที่อาจเกิดขึ้นและความแตกต่างอื่นๆ ที่เกี่ยวข้อง จากนั้นผู้เข้าร่วมแต่ละคนจะเลือกการ์ดที่มีตัวเลขที่แสดงถึงระดับความยากของตน อ้อ และในการ ประมาณ ค่านั้นไม่ใช่อนุกรมปกติที่ใช้ แต่เป็น
ตัวเลขฟีโบนัชชี หมายเลข Fibonacciได้รับความนิยมอย่างมากใน
Scrum Pokerเนื่องจากช่องว่างระหว่างตัวเลขเหล่านี้จะเพิ่มขึ้นเมื่อเวลาผ่านไป (ชวนให้นึกถึงระดับพีระมิด) มีงานที่จะมีความซับซ้อนอย่างมากและไม่สามารถบรรลุจุดเรื่องราวจำนวนเล็กน้อยได้
![“ ตรงตามกำหนดเวลา”: นักพัฒนาใช้วิธีการใดในการประเมินงาน - 4]()
คำอธิบายการ์ดที่ผิดปกติ:
ไม่ทราบจำนวนจุดสิ้นสุด
งานที่ยาวไม่สิ้นสุด
ต้องการพัก
วิธีการประมาณค่าที่หายากมากขึ้น:
- ในขนาดเสื้อยืด - S, M, L, XL
- หรือในสุนัข - ชิวาวา ปั๊ก ดัชชุนด์ บูลด็อก และอื่นๆ (ในความคิดของฉัน นี่เป็นหน่วยที่แปลกที่สุดในการประเมินงาน =D)
![“ ตรงตามกำหนดเวลา”: นักพัฒนาใช้วิธีใดในการประเมินงาน - 8]()
จากนั้นทีมงานจะเปรียบเทียบการประมาณการที่มอบให้กับปัญหาเดียวกันโดยนักพัฒนาแต่ละราย และหากพวกเขาเห็นด้วยก็เยี่ยมมาก! ถ้าไม่เช่นนั้น จำเป็นต้องหารือถึงสาเหตุของความแตกต่างในการประเมิน (ข้อโต้แย้ง) หลังจากนี้เราสามารถร่วมกันประมาณการได้ ซึ่งทุกคนจะบวกหรือลบจะเห็นด้วย เหตุใดโป๊กเกอร์จึงถูกนำมาใช้ในการวางแผนโครงการซอฟต์แวร์ที่จริงจัง? ท้ายที่สุดแล้วนี่เป็นเรื่องแปลก ในความเป็นจริง การเล่นเกมดังกล่าวส่งเสริมให้สมาชิกในทีมคิดอย่างอิสระ โดยขอให้พวกเขาแสดงผลพร้อมกับเพื่อนร่วมทีม ซึ่งจะช่วยหลีกเลี่ยงการพึ่งพาความคิดเห็นของสมาชิกในทีมคนอื่นๆ มิฉะนั้น นักพัฒนาที่มีประสบการณ์น้อยจะพิจารณาและพึ่งพาการประเมินของสมาชิกในทีมที่มีประสบการณ์มากกว่า ซึ่งจะลบล้างประโยชน์ของการประเมินของตนเอง แต่ด้วยการเปิดผลลัพธ์พร้อมกันจึงเป็นไปไม่ได้เลย ตัวอย่างของแอปกำหนดเวลา Scrum Poker มาจาก
Atlassian
ตัวอย่างการประเมินงาน
ลองจินตนาการว่าทีมของคุณได้ระบุระดับการประเมินในประเด็นเรื่องราวแล้ว:
1. คุณมีประสบการณ์กับงานประเภทนี้หรือไม่? |
+1 – ฉันเคยทำงานนี้มาก่อน |
+2 - ฉันยังไม่ได้ทำสิ่งนี้ แต่ฉันได้ทำงานกับสิ่งที่คล้ายกัน |
+3 - ฉันไม่ได้ทำสิ่งเดียวกันและไม่มีประสบการณ์อะไรที่คล้ายกัน |
2. ขอบเขตการทำงานของงาน |
+1 – ปริมาณต่ำ |
+2 - ปริมาณเฉลี่ย |
+3 – ปริมาณมาก |
3. ความซับซ้อนของการดำเนินงานนี้ |
+1 - ง่าย |
+2 - เฉลี่ย |
+3 - ยาก |
4. ความยากในการทดสอบฟังก์ชันการทำงานนี้ |
+1 - ง่าย |
+2 - เฉลี่ย |
+3 - ยาก |
Scrum Pokerเริ่มต้นงาน และคุณประเมินดังนี้:
- คุณไม่เคยทำงานกับการใช้งานฟังก์ชันที่คล้ายกันมาก่อน - +3
- ฟังก์ชันการทำงานของงานขนาดกลาง - +2
- การดำเนินงานมีความซับซ้อนสูง - +3
- การทดสอบการเขียนที่ซับซ้อนสูงสำหรับฟังก์ชันนี้ - +3
เป็นผลให้คุณได้รับ 11 คะแนนเรื่องราว แต่เนื่องจากไม่มีการ์ดดังกล่าว คุณจึงเสนอ 13 คะแนน เพื่อนร่วมงานอีกคนของคุณประเมินงาน:
- ทำงานกับปัญหาที่คล้ายกันก่อน - +1
- ฟังก์ชันการทำงานของงานขนาดกลาง - +2
- การดำเนินงานมีความซับซ้อนโดยเฉลี่ย - +2
- ความซับซ้อนโดยเฉลี่ยของการทดสอบการเขียนสำหรับฟังก์ชันนี้ - +2
เป็นผลให้เขาได้รับ 7 คะแนนเรื่องราว แต่ไม่มีสิ่งนั้นในตัวเลขฟีโบนัชชี และเขาวางการ์ดที่มีหมายเลขที่ใกล้เคียงที่สุดที่เป็นไปได้ - 8 สมาชิกในทีมคนอื่นๆ จึงให้ค่าประมาณตามมุมมองส่วนตัวของพวกเขา ถัดไป คุณจะแสดงผลของคุณและพบว่าเพื่อนร่วมงานของคุณเกือบทั้งหมดให้ค่าประมาณ 13 ยกเว้นนักพัฒนารายหนึ่งที่ให้ 8 ในกรณีนี้ เขาได้รับพื้นและเขาก็ให้เหตุผล ตัวอย่างเช่น พวกเขาเป็นเช่นนี้: เขาเคยทำงานด้วยปัญหาเดียวกันมาก่อน และไม่ยากอย่างที่คิด และสุดท้ายเขาก็โน้มน้าวสมาชิกในทีมที่เหลือให้เปลี่ยนวิธีแก้ปัญหาจาก 13 เรื่องเป็น 8 เรื่อง คะแนนบอกว่าเขาจะช่วยใครก็ตามที่ทำภารกิจนี้จะคิดออก หรือสุดท้ายเขาจะทำเอง และโดยทั่วไปแล้ว ไม่สำคัญว่าคนอื่นจะฟังข้อโต้แย้งของเขาหรือไม่ เพราะไม่ทางใดก็ทางหนึ่ง จะมีการให้คะแนนสำหรับงานนี้ และทีมจะเดินหน้าทำความคุ้นเคยกับงานถัดไป
![“ ตรงตามกำหนดเวลา”: นักพัฒนาใช้วิธีใดในการประเมินงาน - 9]()
ในครั้งแรก การประมาณการจะไม่ถูกต้อง เช่นเดียวกับการประมาณปริมาณงานที่คุณวางแผนจะทำในช่วงเวลาถัดไป (การวิ่ง) ท้ายที่สุดแล้ว การประมาณการเหล่านี้จัดทำขึ้นตามการประมาณการอย่างแม่นยำ หลังจากนั้นประมาณสามเดือน ทีมจะเริ่มประเมินงานได้แม่นยำยิ่งขึ้น และจำนวนงานโดยเฉลี่ยที่ทีมสามารถทำได้ต่อการวิ่งหนึ่งครั้งจะปรากฏให้เห็น แต่นี่เป็นการวางแผนขอบเขตงานโดยทั่วไป มันเกี่ยวกับเวลามากกว่า และในกรณีนี้ อาจมีปัจจัยหลายอย่างที่มีผลกระทบ ตัวอย่างเช่น นักพัฒนาคนหนึ่งไปพักร้อนเป็นเวลาสองสัปดาห์ นั่นคือคุณต้องขีดฆ่างานที่วางแผนไว้จำนวนหนึ่ง (ฟังก์ชันที่วางแผนไว้) หรือมีนักพัฒนาใหม่เข้ามาร่วมทีมแต่คุณไม่จำเป็นต้องพึ่งเขาอย่างเต็มที่เพราะ... คุณต้องคำนึงถึงเวลาที่ต้องใช้ในการปรับตัวให้เข้ากับโปรเจ็กต์ที่เรียกว่าการ
เริ่มใช้งาน ซึ่งอาจใช้เวลาสองสัปดาห์ บวกหรือลบต่อสัปดาห์ ขึ้นอยู่กับความซับซ้อนของโครงการ
![“ ตรงตามกำหนดเวลา”: นักพัฒนาใช้วิธีใดในการประเมินงาน - 10]()
นั่นคือทั้งหมดสำหรับวันนี้ ฉันหวังว่าฉันจะปรับปรุงความรู้ของคุณเล็กน้อยในส่วนความรู้ที่ไม่ใช่ด้านเทคนิค เช่น การประมาณปัญหา หากคุณต้องการเจาะลึกในหัวข้อนี้ รวมถึงรายละเอียดของ Scrum ฉันขอแนะนำให้คุณอ่านหนังสือ “SCRUM” โดย Jeff Sutherland ฉันไม่สามารถรับรองผลที่ตามมาได้ เพราะบางทีหลังจากนั้นคุณอาจจะมีความปรารถนาอันน่ารำคาญที่จะเป็น Scrum Master =D
GO TO FULL VERSION