เป็นวิธีที่ดีที่สุดในการแบ่งงานระหว่างนักพัฒนาอะไร

ทีมของฉันและฉันกำลังสร้างไซต์ที่เราพัฒนาขึ้นเมื่อประมาณสิบปีที่แล้วและเราต้องการทำใน Agile

ดังนั้นหลังจากที่ฉันใช้เวลาอ่านมาก (อาจไม่เพียงพอ) ฉันมีปัญหากับคำถามว่าจะแบ่งงานระหว่างนักพัฒนาอย่างไร

ฉันจะเจาะจงมากขึ้นและบอกว่าไซต์นั้นถูกแบ่งออกเป็นโมดูลแยกต่างหากซึ่งไม่มีการรวมกันระหว่างกันมาก

อะไรคือวิธีที่ดีที่สุด / ได้รับการยอมรับมากที่สุดในการแบ่งงานระหว่างนักพัฒนา

• ให้แต่ละโมดูลที่แตกต่างกันในการทำงาน
• กำหนดผู้พัฒนาทั้งหมดให้กับโมดูลเดียวกันและแบ่งงานตามส่วนต่าง ๆ ของโมดูล (UnitTesting, DAL และ Mapping, Logics, UI)
• กำหนดนักพัฒนาทั้งหมดให้กับโมดูลเดียวกันและแยกงานด้วย logics ที่แตกต่างกัน (ตัวอย่างเช่นนักพัฒนาแต่ละคนรับผิดชอบตรรกะเฉพาะ (อาจเป็นวิธีการใน BL) และเป็น UnitTesting, DAL และ Mapping และ UI ...

หรืออาจจะเป็นสิ่งที่แตกต่างอย่างสิ้นเชิง?

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

• การแบ่งผู้พัฒนาต่อโมดูล:

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

• ทุกคนทำงานในโมดูลเดียวกันในเวลาเดียวกัน

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

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

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

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

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

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

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

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

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

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

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

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

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

วิธีที่ง่ายที่สุดมักจะดีที่สุด

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

เมื่อเผชิญกับภาวะที่กลืนไม่เข้าคายไม่ออกประเภทเดียวกันนี้ฉันได้ใช้วิธีการดังต่อไปนี้:

• ขอบเขตโครงการ ให้แนวคิดกับตัวเองเกี่ยวกับสิ่งที่คุณกำลังทำและพัฒนารายการคุณลักษณะโดยการแบ่งโครงการออกเป็นชุดของงาน

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

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

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

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

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

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

ไม่มีทีมนักพัฒนาขององค์กรการอภิปรายจะเสร็จสมบูรณ์ได้โดยไม่เอ่ยดร. เฟร็ดบรูกส์ทีมผ่าตัด

สูตรพื้นฐานคือ: ทีมการผ่าตัดหนึ่งทีมต่อหนึ่งหน่วยงาน

การกำหนดทีมผ่าตัด

แนวคิดของทีมผ่าตัดขึ้นอยู่กับแนวคิดพื้นฐานสองประการ:

1. นักพัฒนาน้อยกว่าดีกว่าต่อหน่วยของงานเนื่องจากcross-talkฆ่าผลผลิต
2. นักพัฒนาที่ให้ผลผลิตสูงจะทำให้นักพัฒนาที่มีประสิทธิภาพต่ำ (และตาม Brooks ไม่มีสิ่งนั้นในฐานะนักพัฒนาที่เอาท์พุทขนาดกลาง) ดังนั้นคุณควรให้งานที่สำคัญที่สุดแก่พวกเขาและ จำกัด การรบกวน

ทีมผ่าตัดประกอบด้วยนักพัฒนา 3-10 คน:

1. หัวหน้าโปรแกรมเมอร์ นักพัฒนาที่ให้ผลผลิตสูงซึ่งทำหน้าที่เป็นส่วนใหญ่ในการเขียนโปรแกรมจริง
2. นักบินร่วมนักพัฒนาที่ให้ผลตอบแทนสูงอีกคนหนึ่งที่ทำการเขียนโปรแกรมบ้าง แต่ก็มีงานด้านการบริหารเช่นการเข้าร่วมการประชุมและการรวบรวมความต้องการ
3. 1 - 8 ผู้ช่วย Brooks อธิบายสิ่งเหล่านี้ในฐานะนักพัฒนาที่รับผิดชอบสิ่งต่าง ๆ เช่นเอกสารการล้างข้อมูลการวิจัยเครื่องมือการเขียน / อัลกอริทึมการทดสอบ ฯลฯ ย้อนกลับไปในยุค 60 Brooks เสนอบทบาท 8 ประการอย่างแน่นอน แต่ด้วยเครื่องมือที่ทันสมัย ควรได้รับมอบหมายตามความต้องการของโครงการของคุณ

การกำหนดหน่วยงาน

ดังนั้นตอนนี้เราสามารถรวมทีมเราจะมอบหมายอะไรให้พวกเขาบ้าง

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

คุณจะเห็นรูปแบบพื้นฐานที่ยอมรับได้สามรูปแบบ:

1. ทีมย่อย 1 ทีมแน่นอนสำหรับแต่ละเลเยอร์ (UI, DAL และอื่น ๆ )
2. แน่นอน 1 ทีมย่อยสำหรับแต่ละโมดูล (โฮมเพจ, เว็บไซต์สนับสนุน, ร้านค้า)
3. การผสมผสานของทั้งสอง (ทีมเฟรมเวิร์กระดับต่ำและทีมที่เน้น UI สำหรับแต่ละโมดูล)

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

แน่นอนว่ามันไม่ได้ผลเสมอไป ...

นี่คือสิ่งที่ฉันจะทำ:

หากโมดูลทั้งหมดมีขนาดเล็กคุณสามารถให้แต่ละโมดูลทำงานได้ มิฉะนั้นให้ทำดังนี้

1. กำหนดแต่ละขนาดโมดูลความซับซ้อนทักษะที่ต้องใช้
2. กำหนดทักษะของสมาชิกแต่ละคนในทีม
3. กำหนดว่าผู้คนทำงานร่วมกันได้ดีและคนที่ไม่ทำงานร่วมกับผู้อื่นได้ดี
4. กำหนดโมดูลขนาดใหญ่ให้กับทีมงานที่ทำงานร่วมกันได้ดีขึ้นอยู่กับความต้องการทักษะโมดูลและทักษะทีม
5. กำหนดโมดูลที่เหลือให้กับผู้ที่ไม่สามารถทำงานได้ดีกับคนอื่นตามความต้องการทักษะโมดูลและทักษะทีม

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