แม้ว่าทักษะเชิงปฏิบัติและความรู้เกี่ยวกับภาษาโปรแกรม เครื่องมือ และเทคโนโลยีเฉพาะจะเป็นกุญแจสำคัญในการได้งานเต็มเวลาในฐานะนักพัฒนาซอฟต์แวร์ แต่ก็มีตัวบ่งชี้ที่มีค่าอีกประการหนึ่งที่สามารถมองได้หลายวิธีว่าเป็นข้อสันนิษฐานสำหรับความสำเร็จในอาชีพนี้: ผลผลิต การวัดประสิทธิภาพเป็นสิ่งที่นักพัฒนาซอฟต์แวร์มืออาชีพทุกคนต้องเข้าใจและคำนึงถึง เนื่องจากเมตริกประสิทธิภาพมีความสำคัญโดยเนื้อแท้สำหรับทีมพัฒนาซอฟต์แวร์ในสภาพแวดล้อมทางธุรกิจในปัจจุบัน
เหตุใดผลงานของคุณในฐานะนักพัฒนาจึงมีความสำคัญ
ในยุคของการพัฒนาแบบ Agile, DevOps และการลดรอบการปล่อยซอฟต์แวร์ เมื่อนักพัฒนาจำเป็นต้องจัดส่งผลิตภัณฑ์เวอร์ชันใหม่ให้เร็วที่สุด บริษัทต่างๆ จะใช้เมตริกประสิทธิภาพการทำงานที่แตกต่างกันหลายรายการเพื่อประเมินประสิทธิภาพของโปรแกรมเมอร์แต่ละคนและทีมโดยรวม เมื่อมองสิ่งนี้จากมุมมองของนักพัฒนา การวัดผลการปฏิบัติงานสามารถตอบสนองวัตถุประสงค์อันมีค่าหลายประการ ช่วยให้คุณติดตามความก้าวหน้าของทักษะการเขียนโปรแกรมของคุณ ซึ่งจะช่วยให้คุณสามารถเติบโตอย่างมืออาชีพได้อย่างสม่ำเสมอ นักเขียนโค้ดที่มีประสิทธิผลสูงคือคนที่ได้รับข้อเสนอเงินเดือนที่ต้องตะลึงและได้ทำงานในโครงการที่น่าตื่นเต้นที่สุด แต่แม้ว่าคุณจะไม่ได้ประสบความสำเร็จสูงนักและต้องการงานด้านการพัฒนาซอฟต์แวร์และประสบความสำเร็จพอสมควร คุณยังต้องมีความเข้าใจพื้นฐานเกี่ยวกับตัวบ่งชี้ประสิทธิภาพเป็นอย่างน้อย และวิธีการใช้ตัวบ่งชี้เหล่านั้นเพื่อวัดประสิทธิภาพของข้อมูลที่คุณป้อนในที่ทำงาน ซึ่งสิ่งที่เราจะพูดถึงในวันนี้
เมตริกวัดประสิทธิภาพการพัฒนาซอฟต์แวร์
เมตริกประสิทธิภาพการพัฒนาซอฟต์แวร์คืออะไร
เมตริกการพัฒนาซอฟต์แวร์เป็นพื้นที่ของงานเขียนโปรแกรมที่สามารถใช้การวัดเชิงปริมาณเพื่อติดตามประสิทธิภาพ คุณภาพของงาน และผลผลิตของนักพัฒนา ตัวชี้วัดประสิทธิภาพการทำงานทั้งหมดขึ้นอยู่กับการนำข้อมูลจากกระบวนการพัฒนาและใช้เพื่อวัดประสิทธิภาพการทำงาน เนื่องจากแทบจะไม่มีอะไรเกี่ยวข้องกับการพัฒนาซอฟต์แวร์ที่ง่ายและตรงไปตรงมา คุณอาจกล่าวได้ว่าการวัดประสิทธิภาพการเขียนโปรแกรมนั้นค่อนข้างไม่สอดคล้องกันและแยกส่วนทั่วทั้งอุตสาหกรรม หรือพูดง่ายๆ ก็คือ ทีมและบริษัทต่างๆ สามารถใช้ตัวบ่งชี้ประสิทธิภาพที่แตกต่างกันโดยสิ้นเชิง และจัดการกับปัญหานี้จากหลายมุม คุณจึงไม่ต้องกังวลกับการเรียนรู้แต่ละเมตริกที่อาจใช้โดยทีมพัฒนาซอฟต์แวร์
มีตัวชี้วัดประสิทธิภาพการพัฒนาซอฟต์แวร์ประเภทใดบ้าง?
โดยปกติแล้ว มีเมตริกประสิทธิภาพการทำงานที่แตกต่างกันหลายตัวที่เข้าใกล้การวัดประสิทธิภาพในระดับและมุมต่างๆ ต่อไปนี้คือประเภทเมตริกประสิทธิภาพที่พบได้บ่อยที่สุด:
- เมตริกที่เน้นขนาดอย่างเป็นทางการ
เมตริกเหล่านี้มุ่งเน้นไปที่การวัดขนาดของผลลัพธ์การทำงานของโปรแกรมเมอร์ เช่น บรรทัดของโค้ด (LOC) ความยาวของคำสั่งโค้ด ความซับซ้อนของโค้ด เป็นต้น เมตริกเหล่านี้ถือว่าล้าสมัยมากขึ้นในอุตสาหกรรมการพัฒนาซอฟต์แวร์ในปัจจุบัน
- เมตริกประสิทธิภาพที่เน้นเวลาและฟังก์ชัน
มีเมตริกการผลิตแบบดั้งเดิมให้เลือกมากมายที่ใช้ในการพัฒนาซอฟต์แวร์ Waterfall เช่น จำนวนวันที่ใช้งาน ขอบเขตของฟังก์ชันการทำงานที่จัดส่งในช่วงเวลาที่กำหนด อัตราการเลิกใช้โค้ด จำนวนงานที่มอบหมาย เป็นต้น
- เมตริกกระบวนการพัฒนาแบบ Agile
เมตริกกระบวนการพัฒนาแบบ Agile เช่น รายงานเบิร์นดาวน์ ความเร็ว เวลานำ รอบเวลา และอื่นๆ น่าจะเป็นเมตริกที่ใช้บ่อยที่สุดในบรรดาทีมพัฒนาซอฟต์แวร์ในปัจจุบัน เราจะพูดถึงเมตริก Agile ในรายละเอียดเพิ่มเติมในบทความต่อไป
- เมตริกการวิเคราะห์การดำเนินงาน
เมตริกชุดนี้มุ่งเน้นไปที่การวัดประสิทธิภาพของซอฟต์แวร์ในสภาพแวดล้อมการผลิตปัจจุบัน เวลาเฉลี่ยระหว่างความล้มเหลว (MTBF) เวลาเฉลี่ยในการกู้คืน (MTTR) และอัตราการหยุดทำงานของแอปพลิเคชันเป็นเมตริกที่ใช้มากที่สุดที่นี่
การทดสอบซอฟต์แวร์มีชุดเมตริกของตนเองเพื่อวัดคุณภาพของการทดสอบระบบ เช่น เปอร์เซ็นต์ของการทดสอบอัตโนมัติ ความครอบคลุมของโค้ด เป็นต้น
- เมตริกความพึงพอใจของลูกค้า
สุดท้าย ตัวชี้วัดขั้นสูงสุดสำหรับซอฟต์แวร์ชิ้นใดก็ตามคือประสบการณ์ของลูกค้าปลายทาง และมีตัวชี้วัดทั้งชุดสำหรับสิ่งนั้นเช่นกัน เช่น คะแนนความพยายามของลูกค้า (CES) คะแนนความพึงพอใจของลูกค้า (CSAT) คะแนนโปรโมเตอร์สุทธิ (NPS) และคนอื่น ๆ.
เมตริกการพัฒนาซอฟต์แวร์แบบ Agile
อย่างที่คุณเห็น มันค่อนข้างง่ายที่จะหลงทางในความซับซ้อนทั้งหมดของเมตริกประสิทธิภาพการทำงานของซอฟต์แวร์ อย่างไรก็ตาม สิ่งเดียวที่นักพัฒนาซอฟต์แวร์ทั่วไปควรคุ้นเคยเป็นอย่างดีคือเมตริก Agile ซึ่งใช้กันทั่วไปโดยทีมพัฒนาซอฟต์แวร์ในปัจจุบันเป็นมาตรฐานการวัดประสิทธิภาพการทำงานของทีมในส่วนต่าง ๆ ของวงจรชีวิตการพัฒนาซอฟต์แวร์ มาดูเมตริก Agile หลักและใช้กันมากที่สุด
1. วิ่งเบิร์นดาวน์
รายงาน Sprint Burndown เป็นหนึ่งในเมตริกหลักสำหรับทีมพัฒนา Agile scrum เช่นเดียวกับที่ Agile กระบวนการพัฒนาได้รับการจัดระเบียบผ่าน Sprint ที่มีขอบเขตเวลา Sprint Burndown จึงถูกใช้เป็นวิธีติดตามความสำเร็จของงานระหว่าง Sprint ชั่วโมงหรือจุดเรื่องราวใช้เป็นหน่วยวัด เป้าหมายคือการบรรลุความก้าวหน้าที่สม่ำเสมอและส่งมอบงานให้สอดคล้องกับประมาณการเบื้องต้น Sprint Burndown ช่วยให้ทีมวัดจังหวะการทำงานและปรับเปลี่ยนได้ตามต้องการ
2. ความเร็วของทีม
ความเร็วเป็นตัวบ่งชี้สำคัญอีกตัว ซึ่งขึ้นอยู่กับชั่วโมงหรือจุดของเรื่องราวเป็นหน่วยวัด วัดปริมาณงานโดยเฉลี่ยที่ทีมทำเสร็จระหว่างการวิ่ง และใช้สำหรับการประเมินและวางแผนตลอดทั้งโครงการ ความเร็วในการติดตามเป็นสิ่งสำคัญเพื่อให้แน่ใจว่าทีมให้ประสิทธิภาพที่สม่ำเสมอ
3. แต้มเนื้อเรื่อง
ในระดับสมาชิกทีมพัฒนาแต่ละคน ประเด็นเรื่องราวเป็นเมตริกที่มีค่า เนื่องจากขนาดของเรื่องราวที่โปรแกรมเมอร์นำเสนอในแต่ละรุ่นเป็นตัวบ่งชี้ประสิทธิภาพการทำงานของโค้ดเดอร์นี้
4. แผนภูมิควบคุมวงจร
วัดเวลาทั้งหมดจากช่วงเวลาที่งานหรือรายการงานค้างอื่นเริ่มทำงานจนเสร็จสิ้น อนุญาตให้ติดตามและควบคุมรอบเวลาโดยให้ผลลัพธ์ที่คาดเดาได้มากขึ้น
5. ปริมาณงานและการส่งมอบคุณค่า
ผู้จัดการโครงการวิเคราะห์งานที่มอบหมายให้กับนักพัฒนาและกำหนดคุณค่าให้กับพวกเขา เมตริกนี้ใช้เพื่อวัดปริมาณงานของทีม หรืออีกนัยหนึ่งคือปริมาณงานที่เพิ่มมูลค่าที่ทำได้
6. การเปลี่ยนรหัส
Code churn เป็นอีกหนึ่งเมตริกที่ควรค่าแก่การกล่าวถึง เนื่องจากใช้สำหรับวัดทั้งประสิทธิภาพการทำงานของทีมโดยรวม และเพื่อติดตามประสิทธิภาพของโปรแกรมเมอร์แต่ละคน การเลิกใช้โค้ดจะวัดความถี่ที่นักพัฒนาลบหรือทำการเปลี่ยนแปลงในบรรทัดของโค้ดที่เพิ่มไว้ก่อนหน้านี้ และเปอร์เซ็นต์ของโค้ดที่เขียนก่อนหน้านี้จะจบลงด้วยการเปลี่ยนแปลงหรือโยนทิ้งไป
ความคิดเห็นของผู้เชี่ยวชาญ
สุดท้าย เพื่อเพิ่มมุมมอง คำพูดเล็กน้อยเกี่ยวกับเรื่องนี้โดยผู้เชี่ยวชาญด้านอุตสาหกรรมการพัฒนาซอฟต์แวร์ที่มีประสบการณ์ “ฉันหวังว่าคุณจะไม่ต้องการ "เปรียบเทียบ" เมตริกของคุณกับมาตรฐานบางประเภท หรือแม้แต่ประสิทธิภาพของทีมอื่นในบริษัทอื่น ทุกที่ที่ฉันทำงานมีความแตกต่างที่ไม่เหมือนใครในคำจำกัดความของประเด็นเรื่องราว ความเร็ว การประมาณการรายชั่วโมง งาน ฯลฯ ซึ่งแทบจะเป็นไปไม่ได้เลยที่จะเปรียบเทียบประสิทธิภาพของทีมหนึ่งจากบริษัทหนึ่งโดยตรงกับอีกทีมหนึ่ง บริษัท” Cliff Gilley อดีตผู้จัดการผลิตภัณฑ์ด้านเทคนิคและ Agile Coach
กล่าว. “ฉันไม่ค่อยมั่นใจในการวัดผลเมื่อต้องชี้นำประสิทธิภาพของทีม เมื่อคุณให้ความสนใจกับตัวแปรเพียงหนึ่งหรือสองตัวแปร มันจะกลายเป็นเรื่องง่ายมากที่จะหลงกล (ตั้งใจหรือไม่ก็ตาม) หลอกตัวเองว่าคุณกำลังปรับปรุง เมื่อสิ่งที่คุณทำคือการปรับปรุงเมตริก ตัวอย่างเช่น เมตริกตามความเร็วสามารถ "ปรับปรุง" โดยทีมที่ย้ายไปยังเรื่องราวที่เล็กลง (งานต่อเรื่องน้อยลง - เรื่องราวที่เสร็จสมบูรณ์มากขึ้น - ความเร็วจึงเพิ่มขึ้น) นั่นอาจเป็นสิ่งที่ดีหากเรื่องราวเป็นเรื่องราวของผู้ใช้ที่มีประโยชน์ซึ่งให้มูลค่าทางธุรกิจเพิ่มขึ้นเล็กน้อย นั่นอาจเป็นสิ่งที่ไม่ดีหากเรื่องราวมีขนาดเล็กลงและงาน "ด้านเทคนิค" มากขึ้นซึ่งไม่ได้ให้คุณค่าที่แท้จริงด้วยตัวมันเอง” เอเดรียน โฮเวิร์ด ผู้เชี่ยวชาญในอุตสาหกรรมอีกคน
กล่าว. “เมื่อทำงานในระบบแบบดึง ฉันให้ความสำคัญกับปริมาณงานและรอบเวลา ข้อแรกให้ข้อมูลทั่วไปเกี่ยวกับความสามารถของทีม และเมื่อเวลาผ่านไปอาจกลายเป็นตัวชี้วัดที่มีประสิทธิภาพมาก ประการที่สองมีประโยชน์ในฐานะมาตรวัดทั่วไปของประสิทธิภาพของท่อส่งของเรา หากรอบเวลาสูง ก็ถึงเวลาที่จะเริ่มมองหาไปป์ไลน์ เนื่องจากมีข้อจำกัดที่เราอาจจะพยายามผ่อนคลาย/ใช้ประโยชน์ได้ แต่เมตริกเป็นเพียงเครื่องมือ อย่าหลงไปกับสิ่งเหล่านี้ และแน่นอนว่าอย่าเริ่มวางแผนไปยังเมตริกใดเมตริกหนึ่งๆ ลองนึกถึงสิ่งที่คุณกำลังทำเป็นทีมและวิธีที่คุณทำงานตามธรรมชาติ จากนั้นสร้างระบบที่อยู่รอบๆ ผู้คน เมตริกควรช่วยให้คุณเห็นว่าระบบของคุณสนับสนุนงานของทุกคนอย่างไร หรือไม่” Dave Cerra โปรดิวเซอร์ผู้พัฒนาวิดีโอเกมกล่าว
ทิ้งท้าย
GO TO FULL VERSION