จะทำอย่างไรกับทีมพัฒนาที่อดอยาก? [ปิด]


10

มันแย่มากที่ได้อยู่ในเส้นทางวิกฤติในฐานะนักพัฒนาซอฟต์แวร์โดยเฉพาะถ้าคุณมาสาย เมื่อคุณเป็นนักพัฒนาอาวุโสที่ทีมกำลังมองหาความเป็นผู้นำมันยิ่งเลวร้ายลง

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


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

27
@ StudentT ที่สายตาสั้นอย่างไม่น่าเชื่อเนื่องจากความยากลำบากในการกระหน่ำยิงทีมสำรองเมื่อตัวบล็อคได้รับการแก้ไขแล้ว
jonrsharpe

8
@StudentT แทนที่จะเป็นผู้นำควรถูกไล่ออกเพราะไม่ได้วางแผนสำหรับอนาคตไม่คาดการณ์สิ่งนี้จะเกิดขึ้นได้
jwenting

13
devs ที่หิวโหย? คำเดียว: พิซซ่า
Mason Wheeler

3
ถ้า OP ไม่มีหนี้สินทางเทคนิคที่ต้องชำระและไม่มีการทดสอบหน่วย / การทำงานหรือสคริปต์การปรับใช้เพื่อเขียน / ปรับปรุงเขาจะบ่นจาก Deaven (Dev Heaven) อย่างแน่นอนและฉันก็เสียใจอย่างมาก: <
xDaizu

คำตอบ:


29

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


2
นี้. dev โดยเฉลี่ย (ฉันรวมอยู่ด้วย) ส่งเสียงครวญครางเกี่ยวกับการไม่มีเวลากลั่นกรองสิ่งต่าง ๆ ถือไว้เพื่อมัน
Traubenfuchs

4
ฉันชอบนายพลคนนี้ "ทำสิ่งที่คุณยังไม่ได้ทำ" ฉันจะเพิ่มความคิดเห็นรหัสและ refactoring ที่ ทำให้เป็นซอฟต์แวร์ที่เรียบร้อยมาก ๆ ที่ใช้งานได้ดีเหมือนเครื่องจักรที่มีความเชี่ยวชาญและมีความสุขที่ได้เห็น นั่นน่าพอใจสำหรับนักพัฒนา
ปีเตอร์ - Reinstate Monica

สิ่งที่ไม่สำคัญพอที่จะทำก่อนอาจยังไม่คุ้มที่จะทำตอนนี้ เพียง 'ทำให้งาน'
Ewan

16

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

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

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


2
ฉันชอบทางเลือกของ "มีสิ่งที่ต้องปรับปรุงอยู่เสมอ" หากพวกเขาดีพอจะดีกว่าที่จะมุ่งเน้นไปที่ปัญหาปัจจุบันและหาวิธีแก้ไขที่เหมาะสม
Walfrat

15

คุณต้องมีแผนสำรองสำหรับการส่งมอบล่าช้า

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

สร้างแบบจำลอง

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

มันมีอินเตอร์เฟซที่กำหนดไว้หรือไม่? ใช้มัน

มันมีเอกสารรายละเอียด? เลียนแบบให้ดีที่สุดเท่าที่จะทำได้

มันเป็นแค่ความคิดของใครบางคน? ดูว่าคุณจะได้รับต้นแบบ

จากนั้นเมื่อพวกเขาส่งตารางอีกครั้ง ....

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

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


เครื่องมือจำลองไม่จำเป็นต้องสมบูรณ์หรือน่าอัศจรรย์เพียงพอที่จะทำให้คุณสามารถก้าวหน้าได้
Thorbjørn Ravn Andersen

1
ฉันคิดว่ามันฟังดูดีและไม่แนะนำทันที โดยเฉพาะอย่างยิ่งมุมมองที่นอกเหนือจากการเข้ารหัสคือการทดสอบ การจำลองเป็นค่าสองเท่า
Peter - Reinstate Monica

4

หากองค์ประกอบที่สำคัญมีอินเทอร์เฟซที่รู้จักและหากไม่มีความหวังในการทำให้เสร็จในเวลาอันสั้นทำไมไม่สร้างการทดสอบสองครั้ง (เช่นจำลอง )?

สิ่งนี้จะช่วยให้ทีมสามารถเขียนโค้ดได้แม้ว่าผลการทดสอบจะมีความหมายน้อยกว่าเล็กน้อย


2

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

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


0

คุณไม่ได้พูดถึงวิธีการที่คุณใช้ซึ่งทำให้ยุ่งยากในการแนะนำอย่างแน่นอน

ที่ฉันทำงานถ้ามีตัวบล็อกมันเป็นทุกมือที่ปั๊มทำสิ่งที่พวกเขาสามารถเร่งการพัฒนา

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.