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

คำเตือน: ฉันเป็นผู้มาใหม่ (นี่เป็นวันที่สามของการทำงาน) และเพื่อนร่วมทีมส่วนใหญ่ของฉันมีประสบการณ์มากกว่าฉัน เมื่อฉันดูรหัสของฉันฉันเห็นกลิ่นของรหัสและวิธีปฏิบัติทางวิศวกรรมที่ไม่ดีเช่นดังต่อไปนี้: หลักเกณฑ์การตั้งชื่อค่อนข้างไม่สอดคล้องกัน คุณสมบัติไม่ถูกทำเครื่องหมายว่าอ่านได้อย่างเดียวเมื่อเป็นไปได้ คลาสขนาดใหญ่ - ฉันสังเกตเห็นคลาสยูทิลิตี้ที่ประกอบด้วยวิธีการขยายหลายร้อยรายการ (สำหรับหลายประเภท) มันยาวกว่า 2,500 บรรทัด! วิธีการขนาดใหญ่ - ฉันกำลังพยายามปรับวิธีการที่มีความยาว 150 บรรทัด สองหลังดูเหมือนจะเป็นปัญหาจริง ฉันต้องการโน้มน้าวให้เพื่อนร่วมทีมใช้คลาสและวิธีการที่เล็กลง แต่ฉันควรทำอย่างนั้น? ถ้าใช่แล้วได้อย่างไร ทีมของฉันได้รับที่ปรึกษาจากทีมหลัก (เราเป็นทีมดาวเทียม) ฉันควรไปหาเขาก่อนไหม UPDATE : เนื่องจากคำตอบบางอย่างถามเกี่ยวกับโครงการโปรดทราบว่าเป็นโครงการที่ทำงานได้ และ IMHO คลาส / วิธีการขนาดใหญ่นั้นไม่ดีเสมอไป ยังไงก็ตามฉันไม่ต้องการที่จะฉี่ทีมของฉันออก นั่นเป็นเหตุผลที่ฉันถาม - ฉันควรทำอย่างนั้นหรือไม่และถ้าใช่แล้วฉันจะทำอย่างนั้นเบา ๆ ? UPDATE : ฉันตัดสินใจที่จะทำบางสิ่งตามคำตอบที่ยอมรับ: เพราะฉันเป็นผู้มาใหม่ดังนั้นฉันจึงเห็นทุกอย่างใน "ตาสด" ฉันจะจดบันทึกทุกรหัสกลิ่นที่ฉันพบ (ตำแหน่งทำไมมันแย่เราจะทำอย่างไร ดีกว่า ... ) …

27 .net  code-quality  team  refactoring 

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

26 team  problem-solving 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการ4 ปีที่แล้ว เป็นเวลา 4 ปีแล้วที่ฉันเป็นนักพัฒนาเดี่ยวสำหรับ บริษัท ขนาดเล็ก เรามีการสร้างผลิตภัณฑ์ที่ดีในอุตสาหกรรมเฉพาะกลุ่ม เราจะจ้างนักพัฒนา 1-2 เร็ว ๆ นี้และอาจมีการเปลี่ยนแปลงวิธีการทำงานของสิ่งที่นี่ แม้ว่าฉันจะไม่มีชื่อ "ของจริง" แต่ฉันจะเป็น "ผู้ดูแล" ของทีมนี้ สิ่งที่ฉันต้องการทำคือจัดตั้งแผนกการเขียนโปรแกรมที่เป็นระเบียบและมีประสิทธิผลสำหรับ บริษัท ของฉัน ฉันได้งานเดี่ยวนี้ออกจากวิทยาลัยดังนั้นในขณะที่ฉันมีความเชี่ยวชาญในฐานะโปรแกรมเมอร์ในอุตสาหกรรมนี้ฉันไม่มีประสบการณ์การเขียนโปรแกรมทีมจำนวนมาก ฉันรู้สึกว่าการเริ่มต้นด้วยเท้าขวาจะเป็นกุญแจสำคัญ ตอนนี้มันเป็นแค่ฉันคอมพิวเตอร์สองสามเครื่องและเซิร์ฟเวอร์ SVN ฉันกำลังมองหาคำแนะนำทั่วไปในการสร้างทีมจากพื้นดินขึ้นมา

25 teamwork  team  solo-development  knowledge-transfer 

ในการจัดการคำถามผู้ร่วมงานที่ล้าสมัยของฉันหลายคนพูดถึงกลยุทธ์ในการจัดการกับเพื่อนร่วมงานที่ไม่ต้องการรวมเวิร์กโฟลว์ของพวกเขาเข้ากับทีม ฉันต้องการถ้าเป็นไปได้เพื่อเรียนรู้กลยุทธ์บางอย่างสำหรับ "การสอน" ผู้ร่วมงานที่ไม่รู้เทคนิคและเครื่องมือที่ทันสมัยเพียงอย่างเดียว ฉันเริ่มทำงานกับโปรแกรมเมอร์ที่จนกระทั่งเมื่อไม่นานมานี้ได้ทำงานในความโดดเดี่ยวในส่วนอื่นของ บริษัท เขามีความรู้เกี่ยวกับโดเมนอย่างกว้างขวางและที่สำคัญที่สุดเขาได้แสดงให้เห็นถึงทักษะการแก้ปัญหาที่ดีสิ่งที่ผู้สมัครหลายคนดูเหมือนจะขาด อย่างไรก็ตามรหัส (C #) จริงที่ฉันเคยเห็นคือการย้อนกลับไปสู่ ​​VB6 วัน โครงสร้างขั้นตอน, สัญกรณ์ฮังการี, ตัวแปรทั่วโลก (การละเมิดstatic), ไม่มีส่วนต่อประสาน, ไม่มีการทดสอบ, การไม่ใช้ Generics, การขว้างSystem.Exception... คุณจะได้รับแนวคิด โปรแกรมเมอร์คนนี้ค่อนข้างแก่กว่าฉันและด้วยความประทับใจแรกอย่างน้อยก็ไม่ได้แสวงหาการเปลี่ยนแปลงในเชิงบวก ฉันจะไม่พูดต่อต้านการเปลี่ยนแปลงเพราะฉันคิดว่าส่วนใหญ่เป็นปัญหาของหัวข้อที่ได้รับการเจาะและฉันต้องการที่จะเตรียม โปรแกรมเมอร์มักจะเป็นคนที่ดื้อรั้นและเข้าร่วมกับการจู่โจมปืนและทำการตรวจสอบโค้ดที่ฉีกขาดเป็นชิ้นเล็กชิ้นน้อยและนโยบายที่บังคับใช้อย่างเคร่งครัดมีแนวโน้มว่าจะไม่สร้างผลลัพธ์ที่ฉันต้องการ หากนี่คือการจ้างงานใหม่โปรแกรมเมอร์รุ่นเยาว์ฉันไม่คิดเลยว่าจะมีท่าทาง "ผู้ให้คำปรึกษา" สองครั้ง แต่ฉันก็ระมัดระวังในการปฏิบัติต่อพนักงานที่มีประสบการณ์ในฐานะมือใหม่ที่ไร้เดียงสา (ซึ่งเขาไม่ใช่ - เขาแค่ไม่ ทันกับความก้าวหน้าบางอย่างในสนาม) ฉันจะไปเกี่ยวกับการยกระดับมาตรฐานคุณภาพรหัสของผู้พัฒนานี้ตามวิธี Dale Carnegie ผ่านการโน้มน้าวใจที่อ่อนโยนและสิ่งจูงใจที่ไม่ใช่วัสดุได้อย่างไร อะไรจะเป็นกลยุทธ์ที่ดีที่สุดในการทำให้เกิดการเปลี่ยนแปลงที่ละเอียดและค่อยเป็นค่อยไปโดยไม่ต้องสร้างสถานการณ์ที่เป็นปฏิปักษ์? มีคนอื่น ๆ โดยเฉพาะผู้พัฒนานำ - เคยอยู่ในสถานการณ์แบบนี้มาก่อนหรือไม่? กลยุทธ์ใดที่ประสบความสำเร็จในการกระตุ้นความสนใจและสร้างกลุ่มพลังเชิงบวก กลยุทธ์ใดที่ไม่ประสบความสำเร็จและควรหลีกเลี่ยงได้ดีกว่า ชี้แจง: ฉันรู้สึกว่าหลายคนกำลังตอบตามความรู้สึกส่วนตัวโดยไม่อ่านรายละเอียดทั้งหมดของคำถาม โปรดทราบสิ่งต่อไปนี้ซึ่งควรบอกเป็นนัย แต่ตอนนี้ฉันกำลังชี้แจงอย่างชัดเจน: …

24 programming-practices  project-management  team  team-building 

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

23 project-management  open-source  team  contribution  planning 

เมื่อเร็ว ๆ นี้ใน บริษัท ของฉันมีคนแนะนำว่าหนึ่งนักพัฒนาควรมุ่งเน้น นั่นจะหมายถึงบางสิ่งบางอย่างเช่นการตั้งค่าผู้พัฒนานอกเหนือจากรูทีนทีมปกติปล่อยความรับผิดชอบอื่น ๆ (การประชุมและอื่น ๆ ) และบุคคลนี้จะเป็น "คนเดียว" ที่รับผิดชอบในคุณสมบัติเทคโนโลยีที่ชาญฉลาด สำหรับบันทึกเราใช้ SCRUM ภายใน SAFe และเรามีนักพัฒนาเต็มเวลาต่อทีมแบ่งปัน QA และเจ้าของผลิตภัณฑ์ระหว่างสองทีมของเรา (Android และ iOS) ในขณะที่ฉันยอมรับว่าสิ่งนี้จะเพิ่มผลผลิตในระยะสั้นฉันมีความรู้สึก (และฉันคิดว่าฉันได้เรียนรู้ในมหาวิทยาลัย) ว่านี่เป็นการฝึกฝนที่ไม่ดีด้วยเหตุผลหลายประการ: การตรวจสอบรหัสจะเสียค่า แบ่งปันความรู้น้อยที่สุด การเพิ่มความเสี่ยง การสูญเสียความยืดหยุ่นของทีม ฉันถูกหรือว่าไม่ใช่การปฏิบัติที่ไม่ดีเลย?

22 agile  team  code-ownership 

ฉันเป็นผู้จัดการทีมนักพัฒนาซอฟต์แวร์ 11 คนที่ดูแลเว็บไซต์ บริษัท / เว็บแอปพลิเคชันของฉันทำงานได้ถึง 4 โครงการพร้อมกันพร้อมการสนับสนุนแบบวันต่อวันได้ตลอดเวลา ภายในนักพัฒนา 11 คนนั้นมีการผสมผสานระหว่างทักษะทางเทคนิคตำแหน่งงานและประสบการณ์ถึงแม้ว่าโครงสร้างของทีมจะแบนราบกับนักพัฒนา 11 คนที่รายงานตรงถึงฉัน ทีมงานทั้งหมดที่มีผู้จัดการเดียวกำลังเริ่มพิสูจน์ให้เห็นว่าไม่ดีมาก ฉันเริ่มแพร่กระจายบางเบาเกินไปดังนั้นต้องการลดจำนวนรายงานโดยตรงของฉัน ทุกวิธีที่ฉันคิดว่าสามารถทำได้มีข้อเสียที่สำคัญ: มีผู้พัฒนารุ่นเยาว์รายงานถึงรุ่นพี่ สิ่งนี้จะช่วยลดเวลาที่ใช้ในการพัฒนาโดยช่างที่ดีที่สุด แบ่งทีมตามผลิตภัณฑ์ซอฟต์แวร์เช่นนักพัฒนา 1-6 ทำงานบนอินทราเน็ตและทำงาน 7-11 ในไซต์ภายนอกโดยแต่ละส่วนจะมีผู้นำทีมใหม่ (อาจเป็นคำอธิบายงานใหม่ที่มีความรับผิดชอบด้านการจัดการ / ให้คำปรึกษา / ฝึกสอนมากกว่าผู้พัฒนาอาวุโสในปัจจุบัน ) นี่เป็นการเพิ่มไซโลประดิษฐ์และอาจทำให้ "นักพัฒนาอินทราเน็ต" ทำงานบนเว็บไซต์ภายนอกได้ยากหากฉันต้องการให้พวกเขาทำ รักษาโครงสร้างให้เรียบและเพิ่มการสนับสนุนด้านการจัดการในรูปของ Project Managers / Team Administrators เพียงเพื่อลดแรงกดดัน สิ่งนี้ไม่ได้แก้ปัญหาเนื่องจากทีมไม่สามารถเติบโตอย่างนี้ตลอดไป มีวิธีมาตรฐานในการแก้ปัญหานี้ซึ่งฉันพลาดหรือไม่? ถ้าไม่คุณมีคนอื่นในการแก้ไขปัญหานี้อย่างไร?

22 management  team 

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

21 unit-testing  team  refactoring  bad-code  integration-tests 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 8 ปีที่ผ่านมา หัวหน้าทีมของฉันมีนิสัยที่น่ากลัวในการล้อเลียนกับสคีมาฐานข้อมูลและการเปลี่ยนแปลงที่อาจทำให้เกิดการแตกอย่างรุนแรงบนฐานรหัส โดยปกติฉันจะอยู่กับมัน แต่เรามีกำหนดส่งภายใน 2 สัปดาห์และสิ่งนี้เกิดขึ้นนับตั้งแต่ฉันเริ่ม 1 และครึ่งเดือนที่แล้ว ฉันถูกนำไปใช้เพื่อเร่งการพัฒนาของโครงการ เนื่องจากกำหนดเวลาฉันใช้งานไปแล้ว 60 ชั่วโมงต่อสัปดาห์และฉันไม่มีพลังงานเหลือพอที่จะจัดการกับสิ่งนี้ได้ (ฉันได้ลองมาแล้วหลายวิธี) เราเป็นเพียงทีมชาย 2 คนและนอกเหนือจากการเปลี่ยนฐานข้อมูลทุกวันเขายังไม่ได้มีส่วนช่วยในการพัฒนาที่แท้จริง (การเขียนโค้ด) ขณะนี้ฉันรู้สึกเหมือนกำลังทำงานทั้งหมดรวมทั้งต้อง 'แก้ไข' สิ่งที่เขาหยุดพักเมื่อมีการเปลี่ยนแปลง มีวิธีจัดการกับเรื่องนี้อย่างไร? ฉันได้พูดกับผู้จัดการของเราเกี่ยวกับการขาดความพยายามของเขาในแผนกพัฒนา เขาอยู่ที่นั่นนานกว่าฉัน 6 เดือน แต่ฉันได้เขียนโค้ด 95% เมื่อคุณไม่รวมความผิดปกติของฐานข้อมูลฟอร์มที่ 5 ที่เขา 'สนับสนุน' ข้อเสนอแนะใด ๆ ชันสูตรศพ: เมื่อวันศุกร์ที่เราได้คุยกับผู้จัดการและฉันทำให้ฉันกังวล สิ่งนี้นำไปสู่การเผชิญหน้าเล็กน้อย แต่โดยรวมแล้วฉันรู้สึกว่าผู้จัดการเข้าข้างฉัน อย่างน้อยเราก็มีข้อมูลของเราหยุดอยู่ในขณะนี้ลองมาดูกันว่ามันเป็นอย่างไรจากที่นี่

21 communication  team 

เราเป็นกลุ่มคนที่เล่นฟลอร์บอลด้วยกันเป็นประจำ ทุกเซสชั่นเริ่มต้นด้วยภารกิจที่น่ากลัวของการแบ่งทีม ... ดังนั้นจะมีอะไรดีไปกว่าแอปพลิเคชันในการเลือกทีมโดยอัตโนมัติ ดังนั้นด้วยประวัติของการรวมทีมและผลลัพธ์และรายชื่อของผู้คนที่ปรากฏตัวในเซสชั่นนี้สิ่งที่จะเป็นกลยุทธ์ที่ดีในการหาทีมที่ดีที่สุด? ตามความเหมาะสมฉันหมายถึงทีมงานเท่าที่จะทำได้ ความคิดใด ๆ แก้ไข: เพื่อให้ชัดเจนข้อมูลที่ฉันต้องใช้ในการเลือกจะเป็นดังนี้: [{ team1: ["playerA", "playerB", "playerC"], team2: ["playerD", "playerE", "playerF"], goals_team1: 10, goals_team2: 8 }, { team1: ["playerD", "playerB", "playerC"], team2: ["playerA", "playerE", "playerG"], goals_team1: 2, goals_team2: 5 }, { team1: ["playerD", "playerB", "playerF"], team2: ["playerA", "playerE", "playerC"], goals_team1: 4, goals_team2: …

20 algorithms  strategy  team 

แม้ว่าฉันจะใช้และชอบ DVCS สำหรับโครงการส่วนบุคคลของฉันและสามารถเห็นได้อย่างชัดเจนว่ามันช่วยให้คุณจัดการการสนับสนุนโครงการของคุณจากผู้อื่นได้ง่ายขึ้น (เช่นสถานการณ์ Github ทั่วไปของคุณ) แต่ดูเหมือนว่าสำหรับทีม "ดั้งเดิม" อาจมีปัญหามากกว่า วิธีการรวมศูนย์ที่ใช้งานโดยโซลูชันเช่น TFS, Perforce เป็นต้น (โดย "ดั้งเดิม" ฉันหมายถึงทีมนักพัฒนาในสำนักงานที่ทำงานในโครงการหนึ่งที่ไม่มีใคร "เป็นเจ้าของ" โดยทุกคนอาจสัมผัสรหัสเดียวกัน) ปัญหาเหล่านี้สองสามอย่างที่ฉันเห็นล่วงหน้าด้วยตัวเอง แต่โปรดพูดสอดแทรกกับข้อควรพิจารณาอื่น ๆ ในระบบดั้งเดิมเมื่อคุณพยายามตรวจสอบการเปลี่ยนแปลงของคุณในเซิร์ฟเวอร์หากมีคนอื่นตรวจสอบก่อนหน้านี้ในการเปลี่ยนแปลงที่ขัดแย้งกันแล้วคุณจะถูกบังคับให้รวมก่อนที่คุณจะสามารถตรวจสอบของคุณในรุ่น DVCS นักพัฒนาแต่ละคนตรวจสอบ การเปลี่ยนแปลงในท้องถิ่นและในบางจุดผลักไปที่ repo อื่น ๆ repo นั้นมีสาขาของไฟล์นั้นที่ 2 คนเปลี่ยน ดูเหมือนว่าตอนนี้บางคนต้องรับผิดชอบในการจัดการกับสถานการณ์นั้น บุคคลที่ได้รับมอบหมายในทีมอาจไม่มีความรู้เพียงพอเกี่ยวกับ codebase ทั้งหมดเพื่อให้สามารถจัดการกับการรวมความขัดแย้งทั้งหมด ดังนั้นตอนนี้จึงมีการเพิ่มขั้นตอนพิเศษที่บางคนต้องเข้าหาหนึ่งในผู้พัฒนาบอกให้เขาดึงและทำการรวมแล้วกดอีกครั้ง (หรือคุณต้องสร้างโครงสร้างพื้นฐานที่ทำงานโดยอัตโนมัติ) นอกจากนี้เนื่องจาก DVCS มีแนวโน้มที่จะทำงานในพื้นที่ให้สะดวกจึงมีความเป็นไปได้ที่นักพัฒนาจะสามารถสะสมการเปลี่ยนแปลงบางอย่างใน repos ท้องถิ่นของพวกเขาก่อนที่จะผลักดันทำให้ความขัดแย้งดังกล่าวเป็นเรื่องธรรมดาและซับซ้อนมากขึ้น เห็นได้ชัดว่าถ้าทุกคนในทีมทำงานได้เฉพาะในส่วนต่าง ๆ ของรหัสนี่ไม่ใช่ปัญหา แต่ฉันอยากรู้เกี่ยวกับกรณีที่ทุกคนทำงานกับรหัสเดียวกัน ดูเหมือนว่ารูปแบบการรวมศูนย์บังคับให้เกิดความขัดแย้งที่จะได้รับการจัดการอย่างรวดเร็วและบ่อยครั้งลดความจำเป็นในการรวมตัวที่ใหญ่โตเจ็บปวดหรือมีใคร "ตำรวจ" เป็นตัวแทนหลัก …

20 version-control  dvcs  team 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันได้รับการเขียนโปรแกรม (อย่างย่ำแย่) ตั้งแต่ฉันอายุ 12 ปีฉันมีความรู้พอสมควรในภาษาต่าง ๆ ตั้งแต่การประกอบการจนถึง C ++ จาวาสคริปต์จนถึง Haskell Lisp และ Qi แต่ทุกโครงการของฉันเป็นของตัวเอง ฉันสำเร็จการศึกษาด้านวิศวกรรมเคมีไม่ใช่ CS หรือวิศวกรรมคอมพิวเตอร์ แต่เป็นครั้งแรกที่ฤดูใบไม้ร่วงนี้ฉันจะทำงานในโครงการเขียนโปรแกรมขนาดใหญ่กับคนอื่น ๆ และฉันก็ไม่รู้วิธีเตรียม ฉันใช้ Windows มาตลอดชีวิต แต่โครงการนี้จะเป็นยูนิกซ์มากฉันจึงซื้อ Mac เมื่อไม่นานมานี้โดยหวังว่าจะได้ทำความคุ้นเคยกับสภาพแวดล้อม ฉันโชคดีที่ได้มีส่วนร่วมในการแฮ็กฮ็อตกับเพื่อนบางคนเมื่อปีที่แล้ว - ทั้งวิชาเอก CS - และน่าตื่นเต้นมากที่เราชนะ แต่ฉันรู้ว่าฉันทำงานกับพวกเขาว่ากระบวนการทำงานของพวกเขาแตกต่างจากของฉันมาก พวกเขาใช้ Git สำหรับการควบคุมเวอร์ชัน ฉันไม่เคยใช้มันในเวลานั้น แต่ฉันได้เรียนรู้ทุกอย่างที่ฉันสามารถทำได้แล้ว พวกเขายังใช้เฟรมเวิร์กและไลบรารีจำนวนมาก ฉันต้องเรียนรู้ว่า Rails นั้นค่อนข้างค้างคืนสำหรับ …

19 programming-practices  development-process  team  solo-development 

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

19 project-management  scrum  team  roles 

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

19 management  communication  meetings  team-building  team 

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

19 team  organization