ออกแบบในหนึ่งทีมเข้ารหัสในอีกอันหนึ่ง

ฉันจะมีส่วนร่วมในโครงการที่การออกแบบซอฟต์แวร์ทั้งหมดทำโดยทีมงานในพื้นที่และการออกแบบเหล่านี้จะถูกส่งไปยังทีมต่างประเทศเพื่อเข้ารหัส

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

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

ความคิดเห็นของฉัน:

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

คำแนะนำของฉัน

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

• กำหนดให้ใช้มาตรฐานการตั้งชื่อที่รู้จัก

• กำหนดให้ใช้การทดสอบหน่วย

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

มันเรียกว่า Big Design Up Front หรือที่รู้จักในนาม Waterfall มันไม่ได้รับการยอมรับอย่างกว้างขวางว่าเป็นวิธีการที่ประสบความสำเร็จอย่างสูง แต่ฉันเคยเห็นมันใช้งานได้และเมื่อมันทำงานมันก็ทำงานได้ดีมาก มันแพงมากที่จะทำถูก

นี่คือสิ่งที่นายจ้างของคุณขอให้คุณทำ

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

โครงการสุดท้ายที่ฉันเป็นนักออกแบบซอฟต์แวร์ การพัฒนาทั้งหมดอยู่นอกชายฝั่ง เราประสบความสำเร็จ ดังนั้นกระบวนการนี้สามารถทำงานได้

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

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

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

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

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

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

1. กำหนดรหัสโครงกระดูก, ส่วนต่อประสานสาธารณะ, ส่วนต่อประสานบริการ ฯลฯ และตรวจสอบพร้อมกัน
2. กำหนดการทดสอบการยอมรับกับอีกด้านหนึ่ง
3. แยกเอกสารขนาดใหญ่เป็นเรื่องราวขนาดเล็กโดยทำงานจากเรื่องราวเล็ก ๆ เอกสารขนาดใหญ่เป็นเพียงภาพรวมของทั้งระบบ
4. ตั้งค่าจุดตรวจสอบของเรื่องราวหนึ่งสัปดาห์หรือสองสัปดาห์

1 และ 2 นั้นเกี่ยวกับการพัฒนาจริง ๆ เพื่อให้แน่ใจว่าอีกฝ่ายเข้าใจความต้องการเป็นอย่างดีและทั้งสองฝ่ายใช้รูปแบบเดียวกัน 3 และ 4 เป็นส่วนหนึ่งของวิธีการพัฒนาแบบว่องไว แต่สำหรับการพัฒนาในต่างประเทศยากที่จะใช้กระบวนการแบบเปรียวเต็มรูปแบบ

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

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

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

หากคุณให้ข้อมูลจำเพาะของคุณฉันจะถาม ถ้าคุณให้การทดสอบกับฉันฉันจะใช้รหัสและทดสอบ