ทำอย่างไรให้การจัดการไม่อยู่ในกระบวนการพัฒนาของเรา

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

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

ตามที่ระบุไว้ข้างต้น บริษัท ของเรามีทีมวิศวกร 3 ทีมและทีมงานที่ฉันส่งมอบซอฟต์แวร์ตรงเวลา (ให้หรือรับส่วนต่าง 10%) ในขณะที่ทีมอื่นมักจะส่งมอบล่าช้า แต่ส่วนใหญ่เกิดจากการวางแผนในการประเมินต่ำเกินไป พวกเขาวางแผนการเข้ารหัสเท่านั้นไม่ใช่การจัดการทดสอบและจัดการกับมัน

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

ผมได้มีการจัดการกับสถานการณ์ที่คล้ายกันตัวเองและฉันตอบคำถามนี้ในหัวข้อที่คล้ายกัน ฉันยัง blogged เกี่ยวกับวิธีจัดการกับมันที่นี่:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

ในกรณีที่คุณไม่รู้สึกว่าลิงค์ไล่ฉันจะทำซ้ำสรุปของฉันจากคำถามที่เกี่ยวข้อง:

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

ข้อสรุปของฉันจากประสบการณ์นี้คือ:

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

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

กฎข้อหนึ่งที่ต้องปฏิบัติตามโดยไม่คำนึงถึงวิธีการที่คุณใช้คือ

1. นักพัฒนาควรมีสิทธิ์ประเมินงานของตนเอง
2. ผู้มีส่วนได้เสียควรมีสิทธิ์จัดลำดับความสำคัญของงานนั้น

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

คุณอาจชี้ให้เห็นว่าการทดสอบหน่วยประหยัดเวลาดังนั้นหากคุณปล่อยการประมาณการไปที่ 500 ชั่วโมง

บอกพวกเขาเกี่ยวกับหนี้ทางเทคนิคและมูลค่าของการทดสอบหน่วย

ดูโพสต์นี้จากความคิดที่ดีเกี่ยวกับหนี้ทางเทคนิค การติดตามจากโพสต์นั้นคุณสามารถไปที่pdfต่อไปนี้

ฉันชอบโพสต์นี้เกี่ยวกับคุณค่าของการทดสอบหน่วย (อาจมีมากขึ้นที่จะหา)

ความหวังไม่ใช่เพื่อนำพวกเขาออกจากกระบวนการพัฒนาของคุณ แต่ให้พวกเขามีส่วนร่วมและมุ่งมั่นอย่างถูกวิธี

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

• ชั่วโมงน้อยกว่า (ไม่ใช่ทั้ง 150 ซึ่งฟังดูไร้สาระ) โดยที่การเปลี่ยนแปลงทุกอย่าง (ระหว่างขั้นตอนการพัฒนาและระหว่างการบำรุงรักษา) โดยเฉลี่ยจะใช้เวลา:
  • ขนาดเล็ก 4 ชั่วโมง
  • ปานกลาง 16 ชั่วโมง
  • ขนาดใหญ่ 40 ชั่วโมง
• ชั่วโมงโดยประมาณของคุณซึ่งการเปลี่ยนแปลงทุกอย่าง (ขั้นตอนการพัฒนาและระหว่างการบำรุงรักษา) โดยเฉลี่ยจะใช้เวลา:
  • เล็ก 2 ชั่วโมง
  • ปานกลาง 8 ชั่วโมง
  • ขนาดใหญ่ 20 ชั่วโมง

(เวลาเป็นเพียงตัวบ่งชี้คุณมีความพร้อมในการประมาณการที่เหมาะสมมากขึ้น)

อย่าลืมที่จะรวมบันทึกการติดตามของคุณสำหรับการส่งมอบตรงเวลาในงบประมาณ

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

หวังว่าสิ่งนี้จะช่วยและโชคดี

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

นี่เป็นวิธีที่ดีวิธีหนึ่งที่จะทำให้การพัฒนาไม่ใช่กระบวนการ "พัฒนากระบวนการของคุณ" อย่ารวมกระบวนการพัฒนาของคุณในรายการงานหรือกำหนดการโครงการที่คุณให้ไว้!

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

ฉันเคยอยู่ในสถานการณ์ที่ฉันทำงานกับรหัสฐานในสถานะที่ดีมาก ต้องการคุณลักษณะใหม่ที่ท้าทายในระยะเวลาอันสั้นและฉันจัดการเพื่อส่งมอบคุณสมบัติในเวลาอันสั้น ณ จุดนั้นรหัสฐานอยู่ในสภาพที่แย่กว่ามาก คุณสมบัติถูกส่งมอบ แต่งานของฉันไม่ได้ทำ: ฉันต้องใส่ทุกอย่างกลับคืนสู่สภาพที่ดีเท่าเทียมกัน

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

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

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

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

สมมติว่าไม่มีเหตุผล "ตกตาย" สำหรับกำหนดเวลาแล้วฉันจะแนะนำ 2 สิ่ง

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

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

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

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

ฉันคาดว่าจะใช้เวลา 300 ชั่วโมงและหากพวกเขามีงบประมาณ 150 ให้พวกเขามีตัวเลือกมันจะเป็นงานเร่งด่วนแบบบั๊กกี้หรือส่งช้ากว่ากำหนด เมื่อโครงการเสร็จสมบูรณ์และเป็นไปตามที่คุณคาดการณ์คุณสามารถบอกได้ว่าเป็นสิ่งที่คุณต้องการ

วอลลี่จะทำอะไร?

มีหลายวิธีในการตีความสิ่งที่ฝ่ายบริหารขอจากคุณหนึ่งคือพวกเขาไม่ต้องการให้คุณส่งมอบตรงเวลา

ดูเหมือนไร้สาระ? ใช่ แต่พวกเขารู้ได้อย่างไรว่าคุณไม่ได้ประเมินค่าสูงไป ไม่ตรงตามกำหนดเวลาของคุณ (หย่อนหากจำเป็น) หากคุณพลาดและตั้งใจส่งของตรงเวลาให้แน่ใจว่าดูเหนื่อยจริง ๆเพื่อไม่ให้ความรู้สึกว่าเป็นการเดินเล่นในสวนสาธารณะ

คุณกำลังดอง หากคุณยึดปืนของคุณและต้องการที่จะยึดติดกับการทดสอบหน่วยและต้องการเรียกร้อง 300 ชั่วโมงคุณจะสร้างศัตรู

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

ไม่ว่าคุณจะแพ้

หรือดังนั้นดูเหมือนว่า

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

คุณเห็นสิ่งที่คุณต้องการคือการวิเคราะห์ ROI และคุณไม่มีข้อมูลทั้งหมดที่จะทำการวิเคราะห์ คุณมีค่าใช้จ่ายบางส่วนเท่านั้น (คุณไม่ทราบหมายเลขเงินเดือนของทุกคน) และแน่นอนคุณไม่มีส่วนรายได้โดยเฉพาะอย่างยิ่งไม่ใช่การคาดการณ์รายได้

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

ดังนั้นหากคุณต้องการร่วมทุนให้เริ่มต้น บริษัท ของคุณเอง คุณจะเห็นว่าไม่ใช่เรื่องง่าย

พูดอีกอย่างคือทำสิ่งที่คุณบอก หากฝ่ายบริหารรู้ว่ากำลังทำอะไรอยู่คุณจะออกมาข้างหน้า ถ้าไม่คุณออกจากงานทดสอบหน่วยหรือไม่

ROI ของคุณถามอะไร ผลตอบแทนการลงทุน. มันเป็นชื่อที่ไม่ดี จะต้องมีผลตอบแทนจากการลงทุนอย่างทันเวลา (ROTI) เพราะเวลาเป็นทุกสิ่งในการลงทุน