วิธีการโน้มน้าวให้เพื่อนร่วมทีมปฏิบัติตามกฎพื้นฐานบางประการ

ฉันมีปัญหากับเพื่อนร่วมทีม เรื่องสั้นสั้น: เราเป็นนักเรียนสามคนที่ทำงานในโครงการเพื่อการแข่งขัน โครงการประกอบด้วยแอพพลิเคชั่นแยกกัน 2 แอพ: หนึ่งอันสำหรับ Windows (ที่ฉันพัฒนา) และอีกอันสำหรับ Android (เพื่อนร่วมงานของฉันมีหน้าที่รับผิดชอบในการพัฒนา) ฐานรหัสของเราจะไม่ตัดกันแอพจะสื่อสารผ่านเครื่องมือของบุคคลที่สาม

ปัญหามีดังนี้ฉันมีประสบการณ์การทำงานเป็นทีมในขณะที่ฉันฝึกงานที่ บริษัท ใหญ่เมื่อปีที่แล้วและฉันพยายามบังคับใช้มาตรฐานการเข้ารหัสสำหรับรหัสของเรา ฉันยังตั้งค่าซอฟต์แวร์ที่เก็บ git / wiki / การทำงานร่วมกันที่เราสามารถใช้เพื่อผลักดันรหัส / เขียนความคิดโปรโตคอลเอกสารและอื่น ๆ แต่ดูเหมือนว่าฉันเป็นคนเดียวที่ใช้เครื่องมือเหล่านี้

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

รหัสส่วนใหญ่ของคนรอบข้างอยู่ในคอมพิวเตอร์พวกเขาไม่แชร์ฐานรหัสทั่วไปและเมื่อฉันค้นพบพวกเขารวมชิ้นส่วนของตนโดยการประชุมและแบ่งปันรหัสผ่าน usb stick

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

มีวิธีใดบ้างที่ฉันสามารถแสดงให้พวกเขาเห็นถึงประโยชน์ของการจัดทำรหัสการใช้ git และอื่น ๆ ?

คำถามของฉันคือ: ฉันรุนแรงเกินไปในเรื่องนี้หรือไม่?

คุณสามารถพาม้าไปที่น้ำ แต่คุณไม่สามารถทำให้เขาดื่ม

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

ลดความคาดหวังของคุณและมองหาวิธีในการบรรลุเป้าหมายบางอย่างโดยไม่ต้องการให้พวกเขาเริ่มใช้เครื่องมือที่พวกเขาไม่รู้ หากพวกเขาไม่ทราบวิธีการใช้คอมไพล์พวกเขาอาจจะไม่ได้รับประโยชน์มากมายจากมันในทุกกรณี อย่างไรก็ตามคุณยังต้องการตรวจสอบให้แน่ใจว่ามีการสำรองรหัสทั้งหมดในกรณีที่ฮาร์ดไดรฟ์ล้มเหลวหรือภัยพิบัติอื่น ๆ ดังนั้นขอให้พวกเขาคัดลอกโฟลเดอร์โครงการเป็นระยะ ๆ ไปยัง Google Drive, Dropbox หรือบริการแบ่งปันไฟล์ออนไลน์ที่คล้ายกัน ตรวจสอบให้แน่ใจว่าคุณทำเช่นเดียวกัน

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

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

หากคุณต้องการวัสดุที่มากขึ้นสำหรับพวกเขาเชื่อผมจะดูที่Programmer ศาสตร์หรือสมบูรณ์รหัส

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

ฉันเกรงว่ากฎที่คุณอธิบายไม่ได้เป็นพื้นฐานเลย

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

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

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

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

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

ที่จริงผมชอบความคิดของตัวเองโจ Spolsky ของมันในขณะที่เขาออกมาวางในสิ่งที่รับทำเมื่อคุณเท่านั้นฮึดฮัด เพื่อสรุป:

1. เพิ่งทำ - เขียน makefiles สร้างเซิร์ฟเวอร์สร้างรายวันเป็นต้น
2. ไม่มีใครใช้การควบคุมแหล่งข้อมูลหรือฐานข้อมูลบั๊ก? เริ่มใช้ด้วยตนเอง หากมีคนรายงานข้อผิดพลาดเกี่ยวกับงานของคุณขอให้พวกเขาใช้ฐานข้อมูลบั๊กอย่างสุภาพเพื่อรายงานข้อบกพร่องให้คุณเพื่อให้คุณสามารถติดตามพวกเขาได้ ไม่เช่นนั้นคุณจะไม่สามารถเก็บมันไว้ในหัวของคุณและแก้ไขได้ ในโครงการที่ไม่สำคัญจะมีสถานการณ์ที่แก้ไขได้ด้วยการควบคุมซอร์สเท่านั้น: ใช้การควบคุมซอร์สสำหรับโค้ดด้วยตัวเองและโฉบลงอย่างกล้าหาญเพื่อบันทึกวันเมื่อสถานการณ์ดังกล่าวเกิดขึ้น เมื่อสิ่งนี้เกิดขึ้นสองสามครั้งพวกเขาจะมั่นใจ
3. สร้าง Pocket of Excellence - ทำสิ่งที่ถูกต้องด้วยตัวคุณเอง: การเก็งกำไรการกำหนดเวลา ฯลฯ เนื่องจากนี่ดูเหมือนจะไม่เป็นโปรเจคต์การทำงานมันจึงดูไม่เหมือนที่คุณสามารถใช้คำแนะนำนี้ได้ตลอดทางเนื่องจากคุณไม่สามารถจ้างงานได้ สมาชิกในทีมใหม่ที่เชื่อในข้อความของคุณ
4. กลายเป็นสิ่งที่ประเมินค่าไม่ได้ - แสดงให้เห็นว่าคุณเป็นผู้มีส่วนร่วมที่ยอดเยี่ยมในการสร้างอิทธิพลให้กับทีม มิฉะนั้นคุณจะเสี่ยงต่อการเป็นที่รู้จักในฐานะบุคคลที่ให้ความสำคัญกับกระบวนการและเครื่องมือมากกว่าผลลัพธ์

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

แต่ลองตอบคำถามของคุณ:

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

ฉันเห็นด้วยกับความคิดเห็นจาก arnaud

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

วิธีการมีปัญหา:

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

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

3. ทุกคนเรียนรู้สิ่งต่าง ๆ เป็นธรรมดาที่โปรแกรมเมอร์ที่มาจากภูมิหลังที่แตกต่างกันได้เรียนรู้สิ่งต่าง ๆ จุดแข็งของพวกเขาแตกต่างกันและรูปแบบการเขียนรหัสแตกต่างกัน เครื่องมือที่ใช้แตกต่างกัน การบังคับใช้หนึ่งชุดของกฎ / เครื่องมือ / รูปแบบจะเป็นฝันร้ายเพราะข้อ จำกัด กำลังสูญเสียความแข็งแกร่งที่นักพัฒนาใช้เวลาเรียนรู้หลายปี
4. การเปลี่ยนแปลงต้องใช้เวลา ในขณะที่คนที่คิดค้นกฎที่คุณบังคับใช้นั้นมีเวลาค่อนข้างง่ายในการทำตามกฎ แต่ทุกคนก็ทุกข์และใช้เวลาเรียนรู้กฎใหม่ นี่คือเหตุผลหนึ่งว่าทำไมทุกคนในทีมควรสามารถเปลี่ยนกฎได้
5. เลือกเครื่องมือ / การเข้ารหัสการประชุมหรือรูปแบบสำหรับทีมงานทั้งหมดเป็นกิจกรรมที่ยากลำบาก สามารถทำได้ช้าเมื่อเวลาผ่านไปทดสอบสิ่งที่ทำงานและสิ่งที่ไม่ทำงาน การให้ทีม 2 สัปดาห์เพื่อเริ่มปฏิบัติตามกฎ 50 ข้อจะไม่ทำงาน

ฉันพบปัญหาอย่างนี้ที่มหาวิทยาลัย หลายคนก็ไม่เต็มใจที่จะเรียนรู้วิธีการทำงานที่แตกต่างกัน

ฉันมีระบบอยู่แล้วและอธิบายวิธีการใช้ระบบแล้วหลายคนยินดีที่จะลองใช้ ฉันยังคิดว่าที่เก็บข้อมูลเป็นเครื่องมือที่ใช้กันมากและผู้คนมักจะใช้สิ่งที่ต้องการเช่นดรอปบ็อกซ์