คำถามติดแท็ก teamwork

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

16 teamwork  code-reviews 

บริษัท ของฉันเพิ่งเริ่มทำการตรวจสอบโค้ดอย่างเป็นทางการ กระบวนการดังกล่าวเป็นเช่นนี้: คุณส่งไปยัง GitHub, ร้องขอการดึง, โค้ดจะได้รับการตรวจสอบโดยคนประมาณสามคนจากนั้นถ้าผ่านไปทั้งหมด, รหัสของคุณจะเข้า กระบวนการดูเหมือนยุติธรรม แต่คนสามคนที่ทำรีวิวโค้ดดูเหมือนจะไม่ยุติธรรม ฉันสังเกตเห็นว่าเมื่อฉันใส่รหัสของฉันในการตรวจสอบฉันได้ทุกที่ระหว่าง 100-200 ความคิดเห็น หมายเลขสูงสุดสำหรับฉันคือ 300 ความคิดเห็นครั้งเดียว แน่นอนว่าคุณคิดว่ามันเป็นการเปลี่ยนแปลงครั้งใหญ่ แต่นี่อาจเป็นการเปลี่ยนแปลงเล็กน้อยมากพร้อมกับรหัสน้อยกว่า 50 บรรทัด (ซึ่งรวมถึงการทดสอบหน่วย) ความคิดเห็นทั้งหมดได้รับการพิจารณาว่า "ต้องทำ" และไม่มีข้อโต้แย้ง โดยที่ในใจปัญหาหลักของฉันที่นี่คือดูเหมือนว่ามากเกินไป ฉันได้พูดคุยกับกลุ่มและพวกเขาบอกฉันโดยทั่วไปว่าเพียงเพราะฉันมีเวลาหลายปีในการพัฒนา php ไม่ได้หมายความว่าฉันเป็น "นักพัฒนา" ของหลักสูตรนี้ดูเหมือนจะเป็นอันตรายมากกว่าไม่ นอกจากนี้ฉันสังเกตเห็นว่าภายในกลุ่มพวกเขาไม่ได้แสดงความคิดเห็นมากนักและส่วนใหญ่พวกเขาเพิกเฉยหรือไม่สนใจข้อคิดเห็นหรือคำแนะนำอื่น ๆ ที่ไม่ค่อยยอมรับว่าเป็นจุดที่ถูกต้องแม้ว่าจะมีบางอย่างขาดหายไป ดังนั้นคำถามของฉันคือถ้านี้ยุติธรรม หรือเป็นเรื่องธรรมดา?

16 teamwork  code-reviews 

ปัจจัยพื้นฐาน ทีมใช้ DVCS IDE รองรับการแยกวิเคราะห์ความคิดเห็น (เช่นสิ่งที่ต้องทำและอื่น ๆ ) เครื่องมือเช่น CodeCollaborator มีราคาแพงสำหรับงบประมาณ เครื่องมือเช่น gerrit นั้นซับซ้อนเกินไปสำหรับการติดตั้งหรือไม่สามารถใช้งานได้ ขั้นตอนการทำงาน ผู้เขียนเผยแพร่บางแห่งในสาขาฟีเจอร์ repo กลาง ผู้ตรวจทานดึงข้อมูลและเริ่มตรวจสอบ ในกรณีที่ผู้ตรวจสอบคำถาม / ปัญหาสร้างความคิดเห็นด้วยป้ายกำกับพิเศษเช่น "REV" ป้ายกำกับดังกล่าวต้องไม่อยู่ในรหัสการผลิต - เฉพาะในขั้นตอนการตรวจสอบ: $somevar = 123; // REV Why do echo this here? echo $somevar; เมื่อผู้ตรวจทานโพสต์ความคิดเห็นเสร็จ - เพียงแค่คอมเม้นต์ด้วยข้อความ "ความคิดเห็น" ที่งี่เง่าและดันกลับมา ผู้เขียนดึงฟีเจอร์แบรนช์กลับมาและตอบความคิดเห็นในลักษณะเดียวกันหรือปรับปรุงโค้ดแล้วดันกลับ เมื่อความคิดเห็น "REV" หายไปเราสามารถคิดได้ว่าการตรวจทานเสร็จสิ้นแล้ว ผู้เขียนจะทำการย่อกิ่งก้านสาขาที่มีลักษณะโต้ตอบ, กำจัดมันเพื่อลบ "ความคิดเห็น" …

16 teamwork  code-reviews  workflows  dvcs 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน7 ปีที่ผ่านมา มหาวิทยาลัยของฉันมีโมดูลสำหรับการพัฒนาซอฟต์แวร์กับลูกค้าจริง สมาชิกในทีมของฉันบางคนทำงานในห้องปฏิบัติการคอมพิวเตอร์ตลอดเวลาซึ่งเป็นสภาพแวดล้อมที่มีเสียงดังมากที่มีการขัดจังหวะและการรบกวนมากมาย มีคนพูดประมาณ 30 คน ผู้คนมักจะไปที่ Facebook, YouTube หรือเล่าเรื่องตลกด้วยกันนอกเหนือจากการ "ทำงาน" สมาชิกในทีมของฉันบางคนทำงาน 3 ชั่วโมงทุกวันในสภาพแวดล้อมนี้ ฉันเข้าร่วมการประชุมทีมรายสัปดาห์และใช้ระบบการจัดการโครงการออนไลน์ของเราอย่างกว้างขวาง ฉันระบุที่อยู่อีเมลทั้งหมดและมีโปรแกรมแชทไม่ว่าง แต่ฉันได้รับข้อความ ฉันใช้แหล่งข้อมูลออนไลน์เป็นจำนวนมากเมื่อแก้ปัญหาของฉัน อย่างไรก็ตามนอกการประชุมทีมและเซสชันการเขียนโปรแกรมคู่ฉันทำงานส่วนใหญ่ในสภาพแวดล้อมที่เงียบสงบที่ฉันสามารถมุ่งเน้นและมีสมาธิและฉันปิดกั้นการขัดจังหวะภายนอกทั้งหมดและภายใน ฉันมุ่งเน้นงานของฉัน 100% ฉันพบว่าฉันทำสิ่งนี้ได้มากกว่าในห้องปฏิบัติการประมาณ 10 เท่าและฉันสามารถทำงานให้เสร็จได้มาก ปัญหาคืออาจารย์หรือผู้บริหารของเราไม่เห็นฉันทำงานอยู่ในห้องแล็บ ดังนั้นฉันดูเหมือนจะไม่ทำงานกับพวกเขา พวกเขาคิดว่าฉันไม่ได้ทำงานเป็นทีม ฉันจะทำให้พวกเขาเชื่อมั่นได้อย่างไรว่าฉันทำงานเป็นทีมเพราะฉันมีการสื่อสารกับทีมของฉันมากมาย แต่ในขณะเดียวกันฉันก็อยากทำงานด้วยตัวเอง ฉันต้องการพิสูจน์ว่าเพียงเพราะฉันทำงานคนเดียวมากและไม่จำเป็นต้องทำงานทั้งหมดในห้องทดลองฉันยังเป็นสมาชิกที่มีประสิทธิผลของทีม ผู้บริหารอัปเดตบอกฉันว่าปัญหาคือฉันใช้เวลาทำงานเป็นทีม 60% ของเวลาและฉันทำงานคนเดียว 40% ของเวลา พวกเขาบอกฉันว่าฉันควรใช้เวลา 99% ในการทำงานกับทีมตัวต่อตัวในห้องแล็บหรือที่ทำงาน ความคิดเห็นที่เกี่ยวข้องบางคำตอบซึ่งบางคนอาจพลาด: "ปัญหาคือฉันไม่จำเป็นต้องถามทีมของฉันเลยเพราะฉันชอบทำมันเองมากกว่าฉันและเชื่อใจ …

16 productivity  teamwork 

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

16 productivity  teamwork  communication  etiquette 

ฉันทำงานเป็นผู้พัฒนา iOS ใน บริษัท เอาท์ซอร์สขนาดเล็กในทีมขนาด 4 คน เราทำงานในโครงการที่เริ่มเมื่อสองสามปีก่อนที่ฉันและนักพัฒนาอีกสองคนจะเข้าร่วม บริษัท ก่อนหน้านี้โครงการส่วนใหญ่ดำเนินการโดยบุคคลเดียว เมื่อฉันเริ่มทำงานในโครงการมันเป็นความยุ่งเหยิงอย่างสมบูรณ์ มีการทำซ้ำรหัสจำนวนมาก ฉันเห็นโค้ด 500 ตัวเดียวกันกับไฟล์ที่แตกต่างกัน 20 ไฟล์โดยมีการเปลี่ยนแปลงเล็กน้อย นอกจากนี้มันไม่ได้ถูกจัดระเบียบอย่างถูกต้อง: รหัสการสร้าง UI ทั้งหมดถูกผสมในตัวควบคุมมุมมองพร้อมกับตรรกะ ฉันพยายามอย่างที่สุดในการทำสิ่งต่าง ๆ ที่นี่และที่นั่นกำจัดรหัสซ้ำซ้อนปรับปรุงโครงสร้างไฟล์ของโครงการและอื่น ๆ รู้สึกเหมือนผู้พัฒนาก่อนหน้าไม่สนใจสิ่งเหล่านี้ทั้งหมดหรือไม่มีประสบการณ์ มีเวลาที่ฉันทำงานคนเดียวกับคุณสมบัติที่ยิ่งใหญ่สักสองสามเดือน เนื่องจากลักษณะของคุณสมบัตินี้ฉันต้องสัมผัสโค้ดจำนวนมากในแอพทั้งหมดดังนั้นฉันจึงพยายามปรับปรุงบางอย่าง เมื่อนักพัฒนารายอื่นเข้าร่วมโครงการฉันสังเกตเห็นว่าพวกเขาใช้รูปแบบการเข้ารหัสที่แตกต่างกัน (บางครั้งก็เป็นสไตล์ที่แตกต่างอย่างสิ้นเชิง) และมักจะไม่ใช้คุณสมบัติภาษาสมัยใหม่เช่นตัวเข้าถึงคุณสมบัติ บางครั้งพวกเขาจะประดิษฐ์จักรยานของตัวเองแทนที่จะใช้คุณสมบัติที่คล้ายกันของกรอบงานหรือถ่ายโอนแนวคิดจากภาษาโปรแกรมหรือ patters อื่น ๆ ที่พวกเขาเรียนรู้ลงในฐานรหัสของเรา บ่อยครั้งที่พวกเขาไม่สามารถตั้งชื่อวิธีการหรือตัวแปรได้อย่างเหมาะสมเนื่องจากภาษาอังกฤษไม่ดี (Objective-C เป็นภาษาที่คุณใช้ชื่อยาว) บางครั้งฉันคิดว่าถ้าไม่ใช่สำหรับ IDE ฉันคิดว่าพวกเขาจะเขียนโค้ดทั้งหมดโดยไม่มีการเยื้องหรือการจัดรูปแบบเลย โดยทั่วไปฉันเกลียดโค้ดที่เขียน มันมีการจัดรูปแบบ / จัดระเบียบไม่ดีและบางครั้งก็แตกต่างอย่างสิ้นเชิงจากส่วนที่เหลือของโครงการ ฉันรู้สึกหงุดหงิดมากเมื่อพวกเขาเพิ่มสปาเก็ตตี้ในงานศิลปะของฉันและมันส่งผลต่ออารมณ์ในที่ทำงานและประสิทธิภาพการทำงานของฉัน มันให้ความรู้สึกมากขึ้นเรื่อย ๆ เช่นพวกเขาไม่สามารถใส่ใจเรียนรู้หรือไม่สนใจพวกเขาทำสิ่งที่พวกเขาต้องการและกลับบ้าน …

16 coding-style  teamwork 

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

15 object-oriented  teamwork 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน4 ปีที่แล้ว ในทีมของฉันเรามักจะต้องการโปรแกรมเมอร์อาวุโสที่สุดในการฝึกอบรม / ให้คำปรึกษาแก่โปรแกรมเมอร์รุ่นใหม่ อย่างไรก็ตามโปรแกรมเมอร์อาวุโสคนเดียวกันนี้เป็นคนที่ทำงานจริงและสำคัญจำนวนมาก ฉันพยายามที่จะโต้แย้งกับผู้จัดการของฉันว่ามันมีเหตุผลที่จะมีโปรแกรมเมอร์รุ่นเยาว์ที่แสดงความสามารถสูงใช้โปรแกรมเมอร์ใหม่ภายใต้ปีกของพวกเขา ก่อนอื่นมันจะเพิ่มนักพัฒนาอาวุโสให้ทำงานในโครงการที่สำคัญกว่าเดิม (ไม่ใช่การให้คำปรึกษานั้นไม่สำคัญ) ต่อไปก็จะทำให้โปรแกรมเมอร์ผู้น้อยรู้สึกภาคภูมิใจในงานที่พวกเขาจะถูกมองว่าเป็นความรับผิดชอบและพวกเขาอาจเรียนรู้บางอย่างในการสอน ในที่สุดมันจะประหยัดเงินของ บริษัท เนื่องจากผู้พัฒนาระดับสูงต้องเสียค่าใช้จ่ายมากกว่ารุ่นน้อง เจ้านายของฉันล้มเหลวในการชักชวนเนื่องจากนี่เป็นวิธีการทำงานกับทีมนี้ตั้งแต่เริ่มต้นเวลา สมมติว่ามีการตัดสินใจว่าการฝึกอบรม / การให้คำปรึกษาบางอย่างนั้นเป็นสิ่งจำเป็นทุกคนสามารถให้ข้อโต้แย้งที่ดีกว่าหรือบอกฉันได้ว่าทำไมฉันถึงทำผิด ทีมของคุณทำอะไร ** เราทุกคนเห็นพ้องต้องกันว่ารุ่นพี่ไม่จำเป็นต้องหมายถึงความสามารถดังนั้นเพียงแค่สมมติโดย "โปรแกรมเมอร์อาวุโส" ฉันหมายถึง "โปรแกรมเมอร์ยอดนิยม"

15 teamwork  knowledge-transfer 

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

15 management  teamwork 

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

15 team  teamwork 

ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังคำตอบที่จะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการถกเถียงอภิปรายโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน8 ปีที่ผ่านมา อะไรที่คุณคิดมากเกี่ยวกับนักพัฒนารุ่นน้องที่เข้าร่วมทีมของคุณหรือคนที่คุณต้องทำงานด้วย? เห็นได้ชัดว่าพวกเขาไม่มีประสบการณ์ดังนั้นคุณไม่สามารถคาดหวังให้พวกเขารู้ทุกอย่าง แต่ทักษะใดที่ขาดหายไปอย่างลึกลับ - และเราสามารถช่วยให้พวกเขาสร้างทักษะที่ขาดหายไปได้อย่างไร ฉันไม่ได้หมายถึงทักษะระหว่างบุคคลเช่น 'การฟังคำแนะนำ' ฉันหมายถึงเรื่องทางเทคนิคเช่น (ถ้ามี): 'คุณไม่เคยทำ SQL ใช่ไหม' 'คุณไม่เคยเขียนการทดสอบหน่วยหรือไม่' 'คุณไม่รู้ว่าจะใช้คำสั่ง Unix ได้อย่างไร' สิ่งที่คุณไม่คาดหวัง - ฉันต้องการที่จะได้ยินข้อสังเกตและเทคนิคของการเรียนการสอนเขียนโปรแกรมใหม่เพื่อให้ได้มาข้อบกพร่องเหล่านี้เฉพาะ

15 teamwork  knowledge-transfer 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันเล่นด้วยความคิดว่าฉันจะสร้าง บริษัท ในฝันของฉันได้อย่างไรและคน ๆ หนึ่งสามารถทำให้โปรแกรมเมอร์ที่ยอดเยี่ยมมีเสน่ห์ได้อย่างไร ถ้าใครสามารถจ้างโปรแกรมเมอร์ "ซูเปอร์สตาร์" สองสามคนแทนที่จะเป็นคน "ดี" หลายคน สิ่งหนึ่งที่ฉันชอบเป็นการส่วนตัวคืออิสระในการทำงานจากเมื่อใดก็ตามที่ฉันต้องการ ดังนั้นฉันจึงสามารถเดินทางไปทั่วเมืองต่าง ๆ ได้ถ้าฉันรู้สึกชอบและทำงานจากระยะไกลหรือฉันก็สามารถนั่งที่บ้านได้เมื่อมีโหมดกรุบกรอบ จากประสบการณ์ของฉัน แต่คุณต้องการสำนักงานที่มีเพื่อนที่คุณสามารถพูดคุยและมี "วัฒนธรรม" ของ บริษัท สมมติว่าคุณต้องการจ้างโปรแกรมเมอร์ที่มีความสามารถระดับสูงซึ่งอาจมาจากประเทศและเมืองต่าง ๆ เราจะตั้งขึ้นเพื่อแข่งขันกับมหาวิทยาลัยได้อย่างไร การมี บริษัท ที่ไม่ใช้สำนักงานอย่างสมบูรณ์ดูเหมือนจะเหมาะสมที่สุดคุณอาจต้องการพื้นที่สำนักงานที่ซึ่งผู้คนสามารถพบปะและเลือกทำงานได้ ฉันเดาว่าสิ่งหนึ่งที่ทำได้คือมีสำนักงานขนาดเล็กในประเทศต่าง ๆ และให้คนทำงานจากที่พวกเขาเลือก Programmer's สามารถถอดออกได้สำหรับ "crunch-modes" เมื่อได้รับการรับประกัน แต่ยังสามารถทำงานได้จากตำแหน่งที่ต้องการการทำงานเป็นทีมและตัวต่อตัว รูปแบบอื่นคือแทนที่จะมีสำนักงานของที่นั่งจ้างของคุณเองในสำนักงานที่โปรแกรมเมอร์คนอื่นทำงาน ด้วยวิธีนี้แม้ว่าจะมีพนักงานเพียงหนึ่งหรือสองคนในเมืองของคุณคุณก็ยังสามารถหา บริษัท ได้ถ้าคุณรู้สึกว่า "เหงา" จากการทำงานจากระยะไกล อีกแนวคิดหนึ่งคือเหมือนหนึ่งสัปดาห์ทุก ๆ เดือนคุณจะพาทั้งทีมไปยังสถานที่เดียวกัน ซึ่งอาจไม่ใช่สำนักงาน …

15 productivity  teamwork  communication 

ฉันเพิ่งเปลี่ยนการตั้งค่าสาขาในที่เก็บ GitHub ของฉันดังนั้นสาขา [ถัดไป] ของฉันต้องผ่านการสร้าง CI ผ่านคำขอดึง การสนทนาตามด้วยสมาชิกในทีมจำนวนหนึ่งเกี่ยวกับการทดสอบที่ล้มเหลว เพื่อบริบทของ ... ที่เก็บมีสาขา [master] ที่มีการประชาสัมพันธ์เพียงอย่างเดียวเมื่อมีการเปิดตัวดังนั้น [master] มีรหัสณวันที่ออกล่าสุดโดยไม่คำนึงว่าสาขาใหญ่ผู้เยาว์โปรแกรมแก้ไขด่วนเบต้าหรือ alpha / รุ่นก่อนวางจำหน่าย สาขา [ถัดไป] เป็นสาขา "ค่าเริ่มต้น" โดยที่เราต้องการเก็บรหัส "พร้อมใช้" ในทางเทคนิคสาขานั้นสามารถประชาสัมพันธ์ให้เป็น [master] ได้ตลอดเวลาและได้รับการปล่อยตัว ส้อมแต่ละคนมีกิ่ง dev ของตัวเองและผู้สนับสนุน PR ถึง [ถัดไป] เมื่อฉันตรวจทาน PR ที่ไม่สำคัญฉันจะรวมสาขา dev ของผู้มีส่วนร่วมในสาขา "review" ของฉันและถ้าฉันเห็นสิ่งที่ฉันสามารถแก้ไขได้อย่างรวดเร็วฉันจะยอมรับ / ผลักดันการเปลี่ยนแปลงและการทดสอบใหม่ (บางครั้งล้มเหลว) และ PR กลับไปที่สาขานักพัฒนาของผู้มีส่วนร่วม; เมื่อพวกเขารวมการเปลี่ยนแปลงของฉันทำการทดสอบความล้มเหลวใหม่ผ่านแล้วผลัก PR ของพวกเขาประสานและจากนั้นฉันจะรวมการประชาสัมพันธ์เป็น [ถัดไป] …

14 unit-testing  git  teamwork  continuous-integration 

ในกระบวนการ Agile ของเราเรามี Sprints 2 สัปดาห์ งานจะถูกส่งเป็นรายวัน (งานสร้างรายวัน) และทีมทดสอบจะทำการทดสอบเสร็จในวันถัดไปหรือในวันเดียวกัน นอกจากนี้เรายังมีบทวิจารณ์รหัส Dev ซึ่งต้องใช้เวลา (1-2 ชั่วโมง) ดังนั้นจึงมีกำหนด 3 ครั้งต่อสัปดาห์: จันทร์ - ศุกร์ นักพัฒนามารวมกันและแนะนำวิธีปรับปรุง / สร้างรหัสใหม่ ปัญหาของเราคือเมื่อรายการการดำเนินการเกิดขึ้นหลังจากการตรวจสอบโค้ดงานส่วนใหญ่ได้รับการทดสอบแล้ว ผู้ทดสอบไม่ต้องการทดสอบสิ่งที่ผ่านการทดสอบแล้ว พวกเขาไม่สนใจเกี่ยวกับการเปลี่ยนแปลง dev ภายใน เราเข้าใจผิดเกี่ยวกับกระบวนการเปรียวหรือไม่? การตรวจสอบโค้ดไม่เข้ากันกับรอบการเปิดตัว / ทดสอบรายวันหรือไม่ เราไม่สามารถตรวจสอบโค้ดได้ทุกวันเนื่องจากใช้เวลาของทุกคน

14 project-management  agile  teamwork  code-reviews  sdlc 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว คุณเคยมีประสบการณ์เกี่ยวกับบุคคลที่ไม่ได้ทำงานกับโปรแกรมเมอร์ในระหว่างกระบวนการเข้ารหัสหรือไม่? มันเหมือนกับการเขียนโปรแกรมคู่ แต่บุคคลหนึ่งเป็นบุคคลที่ไม่ใช่ด้านไอทีที่รู้เรื่องธุรกิจเป็นอย่างมากอาจเป็นวิศวกรกระบวนการที่มีพื้นฐานทางคณิตศาสตร์ที่รู้วิธีคำนวณสิ่งต่าง ๆ และสามารถเข้าใจโค้ดที่ไม่ใช้สำนวนได้ ฉันพบว่าบางภาษาเฉพาะโดเมนเช่น PL / SQL นั้นค่อนข้างเข้าใจได้ง่ายโดยวิศวกรที่ไม่ใช่ไอที บุคคลเหล่านี้เป็นผู้เขียนรหัสและรับประกันความถูกต้องของสูตรปัจจัย ฯลฯ ฉันพบว่าการเขียนโปรแกรมคู่ชนิดนี้มีประสิทธิภาพมากผู้ใช้ประเภทวิศวกรรมรู้สึกว่าพวกเขายังเป็น "เจ้าของ" และ "ผู้เขียน" ของรหัสและช่วยลดความเข้าใจผิดในกระบวนการสื่อสาร พวกเขายังช่วยออกแบบกรณีทดสอบ การปฏิบัตินี้เป็นเรื่องปกติหรือไม่ มันมีชื่อหรือไม่? คุณเคยมีประสบการณ์คล้าย ๆ กันบ้างไหม?

14 teamwork  requirements  client-relations  business-logic  pair-programming