“ คำจำกัดความที่ดี” สำหรับทีมที่เป็นผู้ใหญ่แล้วมีลักษณะอย่างไร?

เมื่อดูตัวอย่างของคำจำกัดความที่ทำในแหล่งข้อมูลต่าง ๆ พวกเขามักจะรวมถึงจุดเช่น

• รหัสเสร็จสมบูรณ์
• เรียกใช้การทดสอบหน่วย
• รหัสตรวจสอบหรือจับคู่
• รหัสตรวจสอบใน
• อัปเดตเอกสารประกอบแล้ว
• ...

ในทีมของเราเรามีรายการที่คล้ายกัน แต่ไม่มีใครเคยดูเพราะคะแนนเหล่านั้นดูเหมือนชัดเจนจนเห็นได้ชัดว่ามันจะไม่เกิดขึ้นกับทุกคนที่จะข้ามขั้นตอนเหล่านี้ ดังนั้นเราจึงสงสัยว่าส่วนใหญ่นั้นเป็นเครื่องมือสำหรับทีมที่เปลี่ยนไปสู่กระบวนการที่คล่องตัวหรือไม่และเราไม่ควรกำจัดมันออกไป

ในขณะที่วรรณกรรมจำนวนมากอ้างว่าทีมที่มีประสิทธิภาพสูงนั้นมีคำจำกัดความที่ชัดเจน คำแนะนำแบบนี้ที่เราอาจพลาดโอกาสในการปรับปรุงที่นี่

ดังนั้นสิ่งที่เป็นตัวอย่างของคำจำกัดความที่แข็งแกร่งของการทำทีมที่ครบกำหนด? โดยทั่วไปแล้วจะมีคะแนนประเภทใดบ้าง

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

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

เป็นกระบวนการวนซ้ำทุกครั้งที่คุณเห็นบางสิ่งที่คุณสามารถปรับปรุงเพิ่มในนิยามของการกระทำ การทำงานล่วงเวลาคุณจะพัฒนารายการที่เกี่ยวข้องกับ บริษัท ของคุณ อานันท์ได้พูดถึงบางอย่างที่คุ้มค่าแล้ว

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

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

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

ฉันสงสัยว่ารายการตรวจสอบที่ดีที่จะใช้เป็นพื้นฐานสำหรับคำจำกัดความของการทำคือ:

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

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

ฟังดูเหมือนคุณเป็นคนโชคดีจริงๆ:

ในทีมของเราเรามีรายการที่คล้ายกัน แต่ไม่มีใครเคยดูเพราะคะแนนเหล่านั้นดูเหมือนชัดเจนโจ๋งครึ่ม

ทีมของคุณ "เป็นผู้ใหญ่แล้ว" ;-) แต่มีห้องสำหรับการปรับปรุงอยู่เสมอ!

สำหรับคำถามของคุณ:

ดังนั้นสิ่งที่เป็นตัวอย่างของคำจำกัดความที่แข็งแกร่งของการทำทีมที่ครบกำหนด? โดยทั่วไปแล้วจะมีคะแนนประเภทใดบ้าง

ด้านบนของรายการคุณสามารถเพิ่ม:

มาตรวัดคุณภาพของรหัสต่างๆ: - ความไม่เสถียร, Abstraction - LOC กับ DLOC (ทำเป็นเอกสาร) - ฯลฯ ...

กฎของหัวแม่มืออาจเป็นไปได้ว่าตัวชี้วัดไม่ควรแย่ไปกว่าการกระทำของคุณ ด้านบนคุณสามารถกำหนด "เสร็จสิ้น: withExcellence" ถ้ามีคนทำให้การวัดดีขึ้นจริง ๆ แม้ว่าสิ่งนี้ (การวัดที่เริ่มดีขึ้น) มักจะไม่ได้เป็นส่วนหนึ่งของขั้นตอนการพัฒนา (คุณลักษณะใหม่) แต่เป็นการสร้างเฟสใหม่

ในหนึ่งใน บริษัท ที่ผ่านมาของฉันเรามีคำจำกัดความของ "เสร็จสิ้น" ซึ่งกล่าวว่าการวัดของคุณต้องอยู่ต่ำกว่าเกณฑ์ที่กำหนดหากคุณไปด้านบนคุณยังไม่ได้ทำ (Cyclomatic Complexity ไม่ควรสูงกว่า 15 ยกเว้นว่าคุณมีข้อแก้ตัวที่ดีมาก ๆ เช่น calcs ที่ซับซ้อน)

เช่นเดียวกันกับประเภทของการละเมิด Checkstyle โดยเฉพาะถ้าคุณมีชุดกฎที่กำหนดเองเพื่อตรวจสอบสไตล์ทีมของคุณ หากคุณละเมิดมาตรฐานการเข้ารหัสคุณยังไม่ได้ดำเนินการ

จากนั้นคุณไม่สามารถดำเนินการ UnitTest ได้เท่านั้นคุณสามารถวัดความครอบคลุมโค้ดได้ หากไม่ได้รับความคุ้มครองอย่างน้อย 50% คุณจะไม่ดำเนินการต่อ แม้ว่าสิ่งนี้จะเป็นข้อผิดพลาดที่เกิดขึ้นเนื่องจากคุณควรมีการทดสอบสำหรับวิธีการ core / main / critical และไม่จำเป็นต้องเป็น 100% ของฐานรหัสของคุณ

โอ้ใช่แล้ว ... และถ้าคุณมี (คุณควร) เซิร์ฟเวอร์ CI ที่มีการรวมสาขาอัตโนมัติ ... คุณจะทำก็ต่อเมื่อคอมมิชชันของคุณใน DEV Branch ผสานกับ LIVE-Branch ปัจจุบันและทำให้ไม่มีข้อผิดพลาด (การทดสอบหน่วย ฯลฯ )

อืม ... นั่นคือทั้งหมดที่ฉันจำได้ถูกต้องรู้จาก บริษัท หรือโครงการที่ผ่านมาซึ่งไม่ได้กล่าวถึงในรายการของคุณ

ฉันหวังว่าจะให้ความคิดกับคุณ ;-)

ไชโย

anann

ในสภาพแวดล้อม TDD / BDD คำจำกัดความของ "เสร็จสิ้น" (ในทางเทคนิค "รหัสสมบูรณ์" เนื่องจากคำจำกัดความของ "เสร็จแล้ว" "ของ Matt S นั้นถูกต้องแล้ว) ค่อนข้างง่าย:

• การทดสอบอัตโนมัติทั้งหมดผ่าน (การทดสอบอัตโนมัติเหล่านั้นควรรวมการทดสอบใหม่ที่เขียนขึ้นสำหรับเรื่องราวที่เป็นปัญหาเพื่อตรวจสอบการทำงานหรือพฤติกรรมที่ต้องการที่มีอยู่และทำงาน)
• การตรวจสอบโค้ดที่ส่งผ่าน (อย่างน้อยหนึ่ง dev อาวุโสในทีมคือเนื้อหาเพื่อให้งานของคุณกลายเป็นส่วนหนึ่งของ codebase และคุณไม่ได้ "โกง" หรือ "แฮ็ค" ทางผ่านเรื่องราว)
• ยอมรับสำเร็จ (รวมถึงการสร้างบอทผ่านการทดสอบอัตโนมัติทั้งหมดการครอบคลุมโค้ดการตรวจสอบสไตล์ตำรวจ ฯลฯ )

ณ จุดนี้คุณสามารถไปต่อ จุดสามจุดเหล่านี้มีความสำคัญ แต่ทุกอย่างเป็นสิ่งที่ coder ของทีมโดยเฉลี่ยต้องเกี่ยวข้อง เขียนหรือไม่ได้เขียนซึ่งขัดขืนไม่ได้ในสภาพแวดล้อม TDD Documentation เมื่อ coders เป็นคนที่ทำ documenting เป็นจุดเพิ่มเติม ในทีม Agile ล่าสุดของฉันเอกสารได้รับการจัดการโดย BAs / QAs พวกเขารู้ว่าสิ่งที่ลูกค้าต้องการเรียกใช้ UATs และดังนั้นจึงดีที่สุดสามารถจัดทำเอกสารคุณลักษณะใหม่ในลักษณะที่มีความหมายต่อลูกค้าดังนั้นเอกสารไม่ได้เป็นส่วนหนึ่งของคำจำกัดความของ "เสร็จสิ้น" แม้ว่ามันจะเป็นส่วนหนึ่ง ของคำจำกัดความของทีม