วิธีที่ดีที่สุดในการวางแผนการเขียนโปรแกรมสำหรับทีมเล็ก ๆ ? [ปิด]

ฉันเป็นผู้อำนวยการขององค์กรเริ่มต้นเล็ก ๆ ขณะนี้เรามีโปรแกรมเมอร์สองคน (มีประสบการณ์หนึ่งคนมีประสบการณ์น้อยลง) ที่กำลังสร้างแพลตฟอร์มเว็บแอปพลิเคชัน

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

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

คุณมีความคิดใด ๆ :

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

เทคนิคทั่วไปค่อนข้างสามัญสำนึกสิ่งสำคัญที่ควรทราบคือพวกเขาไม่ต้องการความเชี่ยวชาญด้านเทคนิคมากนัก

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

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

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

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

ในร้านค้าเล็ก ๆ นักพัฒนามักจะเพิ่มขึ้นเป็นสองเท่าในฐานะผู้ดูแลทีมสนับสนุนและแม้กระทั่งผู้ทดสอบ (แม้ว่าทุกสิ่งที่พวกเขาสามารถทำได้การทดสอบคือสิ่งที่คุณควรพยายามหลีกเลี่ยงค่าใช้จ่ายทั้งหมด) ดังนั้นคุณต้องพิจารณา ลองคิดดูว่านักพัฒนาของคุณใช้เวลาไปกับการทำงานกับคุณลักษณะและปัจจัยใหม่ ๆ หากงานประมาณ 2 วัน แต่ devs ของคุณสามารถทำงานกับการพัฒนาใหม่ได้ 60% ของเวลาคุณจะต้องใช้เวลา 4 วันในการทำให้เสร็จ คุณอาจสามารถช่วยเหลือเรื่องนี้ได้ด้วยการควบคุมขั้นตอนการทำงานอื่น ๆ ที่พวกเขาต้องจัดการเพื่อให้ผู้ดูแลระบบที่ไม่เร่งด่วนหรืองานสนับสนุนสามารถรวมกันได้ค่อนข้างดีแทนที่จะถูกจัดการแบบ Ad-hoc โปรแกรมเมอร์จำนวนมาก (รวมถึงตัวฉันเองในเรื่องนี้) ไม่ใช่ผู้จัดการเวลาที่ยอดเยี่ยม ดังนั้นทุกสิ่งที่คุณสามารถทำได้เพื่อให้ความช่วยเหลือในแง่นั้นจะช่วยได้ การทำภารกิจเดี่ยวนั้นง่ายกว่าสำหรับโปรแกรมเมอร์มากกว่ามัลติทาสกิ้ง การบล็อกเวลาระหว่างวันยังสามารถช่วยในเรื่องนี้ได้

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

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

อะไรคือสาเหตุของ [การประมาณ 2 วันใช้เวลา 8 วัน] มันเป็นเรื่องปกติสำหรับโปรแกรมเมอร์หรือไม่

มันคือถ้า:

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

เพื่อตั้งชื่อบางสิ่ง

อาจเป็นการดีที่สุดที่จะถามนักพัฒนาซอฟต์แวร์ของคุณว่าเหตุใดพวกเขาจึงคิดว่าการประเมินของพวกเขาใกล้จะหมดลง :-)

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

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

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

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

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

ฉันหวังว่าจะช่วย!

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

ตอนนี้คุณมีความเป็นไปได้มากมายที่ฉันจะพูดถึงสองข้อ:

• วางแผนโป๊กเกอร์
• PERT (การประเมินผลโครงการและเทคนิคการทบทวน)

วางแผนโป๊กเกอร์

วิธีนี้ใช้งานได้ดีในทีมขนาดเล็กที่มีความคล่องตัว

ตัดตอนมาจากวิกิพีเดีย:

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

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

ฮึกเหิม

บ่อยครั้งที่ยากที่จะประมาณค่าที่แน่นอนหนึ่งครั้ง สิ่งที่ง่ายกว่าคือการให้โอกาส PERT ใช้ 3 ค่าสำหรับการประเมิน:

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

โดยการให้น้ำหนักประมาณสามอย่างนี้คุณจะได้รับประมาณการที่น่าเชื่อถือมากขึ้น

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

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

ที่จริง PERT ประกอบด้วยมากกว่าด้านต่าง ๆ เหล่านี้ที่กล่าวถึงที่นี่ที่ฉันละเว้นเพื่อประโยชน์ของความกะทัดรัด

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

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

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

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

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

-Pivotal Tracker - โปรแกรมที่ยอดเยี่ยมสำหรับการติดตามเรื่องราวและกระตุ้นให้เกิดการทำลาย - งานมันลดน้ำหนักอย่างรวดเร็วในการเข้าสู่เรื่องราวและลดความเร็วโดยอัตโนมัติ https://www.pivotaltracker.com/

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

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

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

หวังว่านี่จะช่วยได้