วิธีรับมือกับสไตล์การพัฒนาที่แตกต่างกัน (จากบนลงล่างและจากล่างขึ้นบน) ในทีมหรือไม่

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

วิธีการ

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

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

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

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

ปัญหา

ปัญหาที่เกิดขึ้นคือผู้พัฒนาจากล่างขึ้นบนต้องเสียเวลาเพราะผู้พัฒนาจากบนลงล่างมักตัดสินใจแก้ปัญหาที่นักพัฒนาจากล่างขึ้นบนควรเขียนทิ้งเนื่องจากข้อบกพร่องในการออกแบบส่งผลให้ต้อง - เขียนรหัส

นักพัฒนาจากบนลงล่างต้องเสียเวลาเพราะแทนที่จะทำงานแบบขนานกันตอนนี้ผู้พัฒนาจากบนลงล่างมักจะนั่งลงเพื่อออกแบบการออกแบบที่ถูกต้องกับผู้พัฒนาจากล่างขึ้นบน สำหรับ 1 คนที่จะทำงานมากกว่า 2

นักพัฒนาทั้งสองต้องการทำงานร่วมกันอย่างต่อเนื่อง แต่ดูเหมือนว่าการรวมกันจะช่วยพวกเขาทั้งสองในทางปฏิบัติ

เป้าหมาย

เห็นได้ชัดว่าเป้าหมายร่วมกันคือการเพิ่มประสิทธิภาพการเข้ารหัส (เช่นลดการสูญเสียเวลา) และการเขียนซอฟต์แวร์ที่มีประโยชน์

คำถาม

พูดง่ายๆคือคุณจะแก้ไขปัญหานี้อย่างไรและรับมือกับสถานการณ์นี้ได้อย่างไร

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

มีวิธีที่ดีกว่า?

เห็นได้ชัดว่าพวกเขาผิดทั้งคู่

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

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

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

มันเรียกว่า Agile โดยวิธีการ (ไม่ใช่รุ่น BS ของความคล่องตัวที่บางคนฝึกฝนซึ่งขั้นตอนสำคัญกว่าซอฟต์แวร์ที่ทำงาน) แต่ความคล่องตัวที่แท้จริงที่ได้รับจากการทำงานไปสู่เป้าหมายสุดท้ายที่อธิบายและเข้าใจทั่วไป

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

สองนักพัฒนาต้องรักษาร่วมกันเคารพซึ่งกันและกัน

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

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

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

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

แจ้งให้ทุกคนทราบ!

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

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

ฉันคิดว่าคำพูดนี้เหมาะสมกับสถานการณ์ของคุณ

"ถ้าคนสองคนเห็นด้วยกับทุกสิ่งหนึ่งในนั้นก็ไม่จำเป็น" ~ บางคนเฒ่า

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

อาจเป็นแบบอย่างที่ดีสำหรับสมองหลาย ๆ

ในความคิดของฉันมันเป็นโปรไฟล์ที่สมบูรณ์และอาจจะทำได้ดีมาก ทั้งการเขียนโปรแกรมและการออกแบบเป็นขั้นตอนที่จำเป็นในการเขียนโปรแกรมและคุณไม่ต้องการที่จะจบลงในทีมที่ไม่มีใครต้องการทำ X สิ่งที่คุณต้องมีก็คือองค์กรเล็ก ๆ น้อยๆ (ดูฉันจะมีตัวหนาด้วย!)

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

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

One note: คุณพูด

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

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

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

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

1. ฉันต้องการให้พวกเขาสองคนนั่งลงและพูดคุยกันกระตุ้นให้พวกเขาเห็นมันจากมุมมองของอีกฝ่าย

2. หลังจากการสนทนาคุณสามารถเริ่มพูดคุยเกี่ยวกับการวางแผน: สิ่งนี้ควรทำกันเป็นทีมด้วยความเข้าใจว่าไม่จำเป็นต้อง 'ยอมรับ' ต่ออีกฝ่าย แต่การประนีประนอมจะต้องทำ มีหลายวิธีในการวางแผนสถาปัตยกรรมสำหรับโค้ดเบสที่อนุญาตให้ขยายได้อย่างง่ายดายในภายหลังโดยไม่ต้องมีโค้ดพิเศษมากมาย

3. เมื่อคุณได้รับพวกเขามาเพื่อพักรบปล่อยให้พวกเขาวิ่งป่า! ให้ไดรฟ์ 'จากบนลงล่าง' วางแผนสถาปัตยกรรมระดับสูง, อินเทอร์เฟซ, ลำดับชั้นเป็นต้นปล่อยให้ 'bottom up guy' กระโดดเข้าและเริ่มเขียนโค้ดเมื่อมีโมดูลที่วางแผนไว้สองโมดูล ให้พวกเขายอมรับอย่างเป็นทางการที่จะยอมรับวิธีการอื่น ๆ ที่ดีสำหรับโครงการโดยรวม: การวางแผนเพื่อให้การเปลี่ยนแปลงในอนาคตง่าย ๆ นั้นดี แต่มันไม่จำเป็นต้องถูกเข้ารหัสด้วยวิธีนั้นทันที สร้างอินเทอร์เฟซและวิธีการไม่สมบูรณ์เพื่อรับโครงสร้างของรหัสและยอมรับว่ารหัสที่ดีสำหรับอนาคตจะไม่ถูกเขียนจริงจนกว่าจะจำเป็น

4. ให้นักเรียนทบทวนการออกแบบและรหัสบ่อยครั้งพร้อมกัน วนซ้ำตามรอบที่คุณดำดิ่งลงในบางส่วนของสถาปัตยกรรมวางแผนในรายละเอียดเพิ่มเติมและเขียนส่วนเหล่านั้น

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

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

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

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

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

วิธีการก็ไม่เพียงพอ ดูเหมือนว่าพวกเขาแต่ละคนฉลาดหรือมีประสบการณ์มากพอที่จะตระหนักถึงวิธีการอื่นที่สั้น (บางทีพวกเขาอาจถูกเผา?) แต่ไม่เห็นวิธีสั้น ๆ ที่เลือกมาเอง ...

ความจริงก็คือจำเป็นต้องมีวิธีการที่หลากหลาย:

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

อย่างไรก็ตามการผสมทั้งสองอย่างคุณสามารถ:

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

เนื่องจากไม่มีระบบที่มีอยู่เพื่อตอบสนองวัตถุประสงค์นี้มีอยู่สิ่งสำคัญคือต้องตระหนักล่วงหน้าว่า:

• การทดลอง / การสร้างต้นแบบจะมีความจำเป็น
• ดังนั้นจึงจำเป็นต้องทำซ้ำ

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

เพื่อให้ข้อเสนอแนะมีคุณค่าแม้ว่าจะเป็นการดีที่สุดที่จะจัดการส่วนหลักก่อน

แล้วเพื่อนร่วมงานของคุณทำอะไร?

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

จากนั้นพวกเขาต้องยอมรับว่าใครทำอะไร โปรดทราบว่าในวิธีการที่อยู่ตรงกลางที่ขีดเส้นใต้ข้างต้นทั้งคู่จะต้องทำงานที่พวกเขาพอใจ

โปรดทราบว่าทั้งการสร้างโครงกระดูกและการสร้างอิฐนั้นเข้าใกล้แบบค่อยเป็นค่อยไป

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

ล้างและทำซ้ำจนกว่าคุณจะได้ชิ้นงาน สะสมข้อเสนอแนะพร้อมวิธีการปรับแต่งตามความจำเป็น

ระวัง: นี่คือต้นแบบทั้งคู่ต้องพร้อมที่จะทิ้งมันและเริ่มจากศูนย์ในการออกแบบที่แตกต่างอย่างสิ้นเชิง

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

ทางออกเดียวที่มีประสิทธิภาพที่ฉันสามารถนึกได้ว่าไม่ต้องเสียเวลาคือการให้นักพัฒนาแต่ละคนทำตามสไตล์การออกแบบของเขา / เธอ

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