วิธีการแบ่งโครงการการเขียนโปรแกรมเป็นงานสำหรับนักพัฒนาอื่น ๆ [ปิด]


164

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

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

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


27
คุณเคยออกแบบซอฟต์แวร์ด้านสถาปัตยกรรมบ้างไหม? เจ้านายของคุณเชื่อว่าคุณสามารถทำได้หรือตั้งค่าให้คุณล้มเหลว
Robert Harvey

15
คุณรู้เกี่ยวกับระบบควบคุมเวอร์ชันเช่นgitหรือไม่? มันสามารถช่วยแก้ไขไฟล์เดียวกันในสถานที่ต่าง ๆให้ผู้ใช้ได้อย่างถูกต้อง!
Basile Starynkevitch

2
ฉันชอบเขียนข้อกำหนดทางเทคนิคก่อนเสมอ จากนั้นมันง่ายที่จะรู้ว่าสิ่งใดที่จำเป็น หลังจากนั้นงานสามารถแบ่งออกเป็นงาน "ฐานข้อมูล, ธุรกิจ, UI, กรณีทดสอบ" สามารถทำได้ในแบบคู่ขนาน หากโครงการมีขนาดใหญ่คุณสามารถแบ่งออกเป็นโมดูล (ตัวอย่าง) "โมดูลผู้ใช้โมดูลใบแจ้งหนี้โมดูลสัญญา" ยิ่งไปกว่านั้นด้วยการมีข้อกำหนดทางเทคนิคมันง่ายกว่าที่จะรู้ว่าต้องใช้เวลาเท่าไรสำหรับแต่ละงาน (เช่นเราจะมี 3 ตาราง 10 ร้านค้า proc ใช้เวลา 4 วันนิติบุคคลมี 15 กฎธุรกิจควรใช้ 3 วัน)
the_lotus

6
ขอบเขตของคุณมีขนาดเท่าใดในแง่ของเวลาจำนวนคนเวลาโดยประมาณจำนวนงาน ฯลฯ
rmayer06

1
ดูเหมือนว่าผู้คนจำนวนมากกำลังมองหาเคล็ดลับเกี่ยวกับวิธีการจัดการโครงการ (การหาโครงสร้างการแบ่งงานเป็นหนึ่งในสิ่งแรกที่คุณทำในการจัดการโครงการ) นี่เป็นรูปแบบที่ดีสำหรับการสอน PM หรือไม่?
rmayer06

คำตอบ:


214

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

  1. ข้อมูลพื้นฐานเกี่ยวกับ

    • อย่าไปคนเดียว พยายามเกี่ยวข้องกับเพื่อนร่วมทีมของคุณให้มากที่สุด
    • เดินทางเบา
    • ประชาธิปไตย แต่ไม่มากเกินไป บางครั้งมันไม่เกี่ยวกับสิ่งที่ทำให้คนจำนวนมากที่สุดพอใจ แต่สิ่งที่ทำให้คนจำนวนน้อยที่สุดเจ็บ
    • เก็บสิ่งที่ (ต้องทำ) และวิธีการ (มันจะทำ) แยกต่างหาก
    • เรียนรู้เกี่ยวกับScrum ("อะไร"), XP (Extreme Programming, "how"), Kanban ("เท่าไหร่"), Lean ("อะไรไม่ได้") และ DevOps ("กับใคร")
    • ลีนเป็นเรื่องเกี่ยวกับการไหล : สำหรับประสิทธิภาพโดยรวมแล้วประสิทธิภาพการไหลมักจะสำคัญกว่าประสิทธิภาพของแต่ละคน
    • เรียนรู้เกี่ยวกับซอฟท์แวฝีมือ , รหัสสะอาดและการเขียนโปรแกรมในทางปฏิบัติ
    • สถาปัตยกรรมที่ดีคือการเพิ่มจำนวนการตัดสินใจที่ไม่ได้รับประโยชน์สูงสุด
    • การต่อสู้ / XP / ลีน / เปรียวเป็นเรื่องเกี่ยวกับการเพิ่มปริมาณของงานที่ไม่ได้ทำ : YAGNI
    • ราคาหลักของซอฟแวร์คือการที่คุณสามารถเปลี่ยนได้อย่างง่ายดายมัน มันทำในสิ่งที่ควรทำมีความสำคัญ แต่นั่นเป็นเพียงมูลค่ารอง
    • ชอบแนวทางแบบวนซ้ำ และแบบ เพิ่มหน่วยใช้กล่องเวลาสำหรับเกือบทุกอย่างโดยเฉพาะการประชุมทำให้กฎของพาร์กินสันเป็นเพื่อนของคุณเพราะกฎของฮอฟสแตดเตอร์ใช้
    • สร้างความสมดุลให้กับโครงสร้างทีมด้วยความเข้าใจในกฎของคอนเวย์และขั้นตอนการพัฒนาทีมของทัคแมน
    • การเขียนโปรแกรมเป็น quaternity มันเป็นวิทยาศาสตร์ , วิศวกรรม , ศิลปะและงานฝีมือทั้งหมดในเวลาเดียวกันและผู้ที่จะต้องอยู่ในความสมดุล
    • เพียงเพราะScrum / XP / XYZ นั้นดีสำหรับใครบางคน (รวมถึงฉันด้วย) ไม่ได้แปลว่ามันดีสำหรับคุณ / เหมาะสมกับสภาพแวดล้อมของคุณ อย่าติดตาม hype อย่างไม่เข้าใจจงเข้าใจเสียก่อน
    • ตรวจสอบและปรับตัว! (การต่อสู้มันตรา)
    • หลีกเลี่ยงการทำซ้ำ - ครั้งเดียวและครั้งเดียว! (XP Mantra) aka DRY - อย่าทำซ้ำตัวเอง aka SPOT - จุดเดียวของความจริง
  2. กระบวนการแยกย่อยงาน "โลกอะไร"

    • รวบรวมความต้องการเป็นเรื่องที่ผู้ใช้ / เรื่องงานเป็นสินค้าค้าง
    • ผู้ใช้ (จากเรื่อง User) คล้ายกับนักแสดง (ใน UML) คล้ายกับPersonaคล้ายกับบทบาท
    • ปรับแต่งเรื่องราวของผู้ใช้จนกว่าพวกเขาจะได้พบกับคำจำกัดความพร้อมของทีมของคุณตามINVEST (อิสระต่อรองได้มีค่าประเมินโดยประมาณขนาดเล็กทดสอบได้) (การประชุม Scrum: การปรับค่าคงค้าง )
    • จัดเรียงสินค้าค้างโดยมูลค่าทางธุรกิจ
    • อย่าเริ่มทำงานในเรื่องก่อนที่จะพร้อม (พร้อมตามคำจำกัดความของพร้อม)
    • ใช้การวางแผนโป๊กเกอร์เพื่อประเมินความพยายามของเรื่องในเรื่องคะแนน ใช้การเปรียบเทียบรูปสามเหลี่ยมเพื่อให้มั่นใจถึงความสอดคล้องของการประมาณการ
    • สภาพอากาศของเมื่อวานนี้เป็นการคาดคะเนที่ดีที่สุด
    • แยกเรื่องถ้ามันใหญ่เกินไป
    • ปรับปรุงวัฒนธรรมการส่งมอบที่มีความหมายของการเสร็จสิ้น
    • อย่ายอมรับการนำเรื่องราวของผู้ใช้ไปใช้ก่อนที่จะเสร็จสิ้น (ทำตามคำจำกัดความของเสร็จสิ้น)
    • หลายทีมในฐานรหัสเดียวกันควรตกลงและแบ่งปันคำจำกัดความของการกระทำที่เหมือนกัน(โดยเฉพาะมาตรฐานการเข้ารหัส )
    • ตรวจสอบความคืบหน้าของคุณด้วยแผนภูมิ burndown
    • ตรวจสอบกับผู้มีส่วนได้เสียอย่างสม่ำเสมอว่าสิ่งที่ทีมส่งมอบคือสิ่งที่จำเป็นจริงๆ (การประชุมการต่อสู้: รีวิว Sprint )
  3. การแยกย่อยเรื่อง

    • รายการและอธิบายผู้ใช้ / บุคลากร / นักแสดง / บทบาท (เจ้าของผลิตภัณฑ์)
    • Epic -> เรื่อง (เรื่องราวของผู้ใช้หรือเรื่องงาน) (เจ้าของผลิตภัณฑ์)
    • เรื่องราว -> เกณฑ์การยอมรับ (เจ้าของผลิตภัณฑ์)
    • เรื่องราว -> ภารกิจย่อย (ทีมงานพัฒนา)
    • เกณฑ์การยอมรับ -> การทดสอบการยอมรับ (ข้อมูลจำเพาะ: เจ้าของผลิตภัณฑ์, Impl: ทีมงาน Dev)
    • เริ่มต้นด้วยโครงกระดูกเดินซึ่งเป็น minimalistic End-to-(Half-End)
    • สร้างMVP - สินค้าทำงานได้ขั้นต่ำ
    • ขยาย MVP ใช้สเมิร์ฟ - เฉพาะของตลาดที่มีประโยชน์, ชุดคุณลักษณะ
  4. "โลกเป็นอย่างไร" สำนึก

    • ใช้OOA / D , UMLและการ์ด CRCแต่หลีกเลี่ยงการออกแบบขนาดใหญ่ล่วงหน้า
    • ดำเนินการเชิงวัตถุ , โครงสร้างและการทำงานในเวลาเดียวกันมากที่สุดเท่าที่เป็นไปได้โดยไม่คำนึงถึงการเขียนโปรแกรมภาษา
    • ใช้การควบคุมเวอร์ชัน ( กระจายอย่างดีกว่า)
    • เริ่มต้นด้วยการทดสอบการยอมรับ
    • สมัครTDDปล่อยให้กฎสามข้อของ TDDไดรฟ์คุณผ่านสีแดงสีเขียว-Refactor รอบด้วยเดี่ยวยืนยัน-กฎ , 4 ของ , GWT ( ป.ร. ให้ไว้เมื่อนั้น)จากBDD
    • " การทดสอบหน่วยเป็นการทดสอบที่ทำงานเร็ว " - Michael Feathers
    • สมัครSOLIDและหลักการแพคเกจในการจัดการการเชื่อมต่อและการทำงานร่วมกัน ตัวอย่าง: S ใน SOLID คือ SRP = หลักการความรับผิดชอบเดี่ยวลดจำนวนการแก้ไขอย่างมีนัยสำคัญ ผสานความขัดแย้งในทีม
    • รู้กฎหมายของ Demeter / บอกไม่ถาม
    • ใช้การบูรณาการอย่างต่อเนื่องหากใช้ได้แม้การจัดส่งต่อเนื่อง (DevOps)
    • ใช้การเป็นเจ้าของรหัสแบบรวมตามมาตรฐานการเข้ารหัสทั่วไปที่ตกลงกันไว้(ซึ่งควรเป็นส่วนหนึ่งของคำนิยามของเสร็จสิ้น )
    • ใช้การปรับปรุงการออกแบบอย่างต่อเนื่อง (การปรับโครงสร้างอย่างต่อเนื่อง fka)
    • รหัสที่มาคือการออกแบบ การคิดอย่างตรงไปตรงมาเป็นสิ่งที่ขาดไม่ได้และจะไม่มีใครโต้แย้งไดอะแกรม UML ที่ชัดเจนได้
    • XP ไม่ได้หมายความว่าไม่มีวันเป็นวันสถาปัตยกรรม แต่หมายความว่าทุกวันเป็นวันสถาปัตยกรรม มันเป็นจุดสนใจของสถาปัตยกรรมไม่ใช่การเบลอและโฟกัสอยู่ในโค้ด
    • เก็บของหนี้ทางเทคนิคต่ำหลีกเลี่ยงการออกแบบสี่กลิ่นเปราะบาง , ความแข็งแกร่ง , สามารถเคลื่อนและความหนืด
    • สถาปัตยกรรมเป็นเรื่องเกี่ยวกับตรรกะทางธุรกิจไม่ใช่เกี่ยวกับการคงอยู่และกลไกการส่งมอบ
    • สถาปัตยกรรมเป็นกีฬาของทีม ( ไม่มี 'I' ในสถาปัตยกรรม )
    • รูปแบบการออกแบบ , Refactoringและสถานที่การเปลี่ยนแปลงลำดับความสำคัญ
    • รหัสโครงการเป็นเอทีพีทรินิตี้ที่มีลำดับความสำคัญดังนี้ 1. การทำงานอัตโนมัติรหัส 2. รหัสทดสอบ 3. รหัสการผลิต
    • ตรวจสอบกับทีมของคุณเป็นประจำว่าเพื่อนร่วมทีมของคุณปรับปรุงอย่างไร (การประชุมการแย่งชิงกัน: Sprint ย้อนหลัง )
    • การทดสอบควรเป็นครั้งแรก - รวดเร็วเป็นอิสระทำซ้ำตรวจสอบตัวเองและทันเวลา

รายการข้างต้นไม่สมบูรณ์แน่นอนและบางส่วนอาจเป็นที่ถกเถียงกัน!

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

ดูสิ่งนี้ด้วย

อ่านเพิ่มเติม (ออนไลน์)

อ่านเพิ่มเติม (หนังสือ)

  • ทำความสะอาดรหัสโดย Robert C. Martin
  • การพัฒนาซอฟต์แวร์แบบว่องไว: หลักการรูปแบบและการปฏิบัติโดย Robert C. Martin
  • The Pragmatic Programmer - จาก Journeyman to Master โดย Andrew Hunt และ David Thomas
  • ทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกโดย Michael Feathers
  • Refactoring - ปรับปรุงการออกแบบของรหัสที่มีอยู่โดย Martin Fowler
  • Refactoring to Patterns โดย Joshua Kerievsky
  • The Ten Day MBA โดย Steven Silbiger (sic!)
  • การออกแบบที่ขับเคลื่อนด้วยโดเมนโดย Eric Evans
  • เรื่องราวของผู้ใช้ที่นำมาใช้โดย Mike Cohn
  • การวิเคราะห์และออกแบบเชิงวัตถุด้วยแอปพลิเคชันโดย Gray Booch และคณะ
  • รูปแบบการออกแบบโดย Gang of Four
  • การทดสอบพัฒนาขับเคลื่อนโดย Kent Beck
  • การเขียนโปรแกรมสุดขีดโดย Kent Beck
  • [if Java] Java ที่มีประสิทธิภาพโดย Joshua Bloch

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

3
หนังสือที่อาจช่วยให้ (บางคนมีอยู่เป็น e-books): Addison Wesley - The Pragmatic Programmer, From Journeyman To Master by Andrew Hunt, David Thomas & Addison Wesley - 1999, O'reilly - The Productive Programmer by Neal Ford, Prentice Hall - Clean Code, a Handbook of Agile Software Craftsmanship ny Robert C. Martin, ..., O'Reilly - Head First Object-Oriented Analysis & Design by Brett D. McLaughlin, Gary Pollice & David Westและอื่น ๆ อีกมากมาย ...
BlueCacti

4
ขอโทษนะครับฉันจะตอบคำถามนี้ทำ PDF พิมพ์และวางบนผนังสำนักงานของฉัน ...
Agustin Meriles

1
@ AgustinMeriles ไปข้างหน้าเพียงแค่คำขอเล็กน้อยสามข้อเท่านั้น - ถ้าเป็นไปได้และหากคุณต้องการ 1. พูดถึง programmers.stackexchange.com เป็นแหล่ง 2. พูดถึงฉันในฐานะผู้เขียน 3. หากเพื่อนร่วมงานของคุณมีข้อเสนอแนะหรือเพิ่มเติมโปรดโพสต์ไว้ที่นี่เพื่อให้ฉันและคนอื่น ๆ ในชุมชนสามารถปรับปรุงคำตอบได้
Christian Hujer

อ๋อไม่มีปัญหากับ :) ว่า
Agustin Meriles

34

รับเปรียว

ฉันอยากจะแนะนำต่อไปนี้:

การแก้ไขไฟล์เดียวกัน

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

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

ดังที่ได้กล่าวไว้ในความคิดเห็น Git ไม่ใช่ยาครอบจักรวาล แต่เมื่อรวมกับการทดสอบอัตโนมัติมันช่วยได้อย่างมาก

รายการคุณสมบัติทั้งหมด

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

เหล่านี้ควรเป็นคุณสมบัติที่ผู้ใช้มองเห็นคุณสามารถพูดคุยเกี่ยวกับกลยุทธ์การใช้งานในภายหลัง

เขียนคำแนะนำทั้งหมดบนบัตรดัชนีแม้เป็นคนโง่ หาเหตุผลเข้าข้างตนเองอย่างรวดเร็วรายการเพื่อลบรายการที่ซ้ำกันและวางไพ่ทั้งหมดบนโต๊ะขนาดใหญ่หรือแม้แต่พื้น

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

ตอนนี้จัดเรียงบัตรของคุณเป็นกลุ่มสับพวกเขาเกี่ยวกับได้รับความรู้สึกสำหรับพวกเขา นี่คือขอบเขตโครงการของคุณ

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

วางแผนการเล่นโป๊กเกอร์ ยังคงอยู่กับทุกคนร่วมกันมอบการ์ดนักพัฒนาทั้งหมดที่พูดว่า "1 คะแนน", "2 คะแนน" ฯลฯ จนถึงสูงสุด "4 คะแนน" นอกจากนี้ยังมีการ์ด "เพิ่มเติม" จุดนั้นมีค่าประมาณหนึ่งชั่วโมง

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

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

เมื่อคุณมีข้อตกลงให้เขียนตัวเลขลงบนการ์ดด้วยปากกาสีอื่น

คะแนนดีกว่าชั่วโมง

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

ตอนนี้เขียนวิ่ง

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

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

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

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

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

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

ตอนนี้ไปที่มัน

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

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

รักษาทัศนวิสัย

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

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

มีทางเลือกทางเทคโนโลยีในการทำดัชนีบัตร แต่ไม่มีอะไรจะดีไปกว่าการแสดงกระดาษขนาดใหญ่เกี่ยวกับสถานะโครงการบนผนัง

ถ้าเป็นไปได้ให้ทุกคนอยู่ในห้องเดียวกันตลอดระยะเวลาของโครงการ มีผู้มีส่วนได้ส่วนเสียมากที่สุดทุกวัน

มอดไหม้

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

หากคุณกำลังจะล้มเหลวล้มเหลวก่อน

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

การทดสอบอัตโนมัติ

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

การทดสอบหน่วยเป็นกระบวนการของการเขียนการทดสอบสำหรับแต่ละส่วนของ codebase ของคุณ (แต่ละวิธีนึกคิด) การทดสอบหน่วยของคุณควรทำงานบ่อยครั้งด้วยการบันทึกทุกครั้งหากเป็นไปได้ มีเครื่องมือมากมายที่สามารถช่วยได้เช่น Karma หรือ Rspec

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

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

หลีกเลี่ยงหนี้สินทางเทคนิคและทำให้เสร็จ

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

อย่าตรวจสอบคุณสมบัติของคุณจนกว่าจะเสร็จสิ้น อย่านวดกราฟ สิ่งนี้ทำร้ายทุกคนในระยะยาวรวมถึงคุณด้วย

นี่คือเหตุผลหนึ่งว่าทำไมในตอนแรกเราเสนอราคา 6 คะแนนต่อผู้พัฒนาต่อวันเท่านั้น เสร็จแล้วใช้เวลาทำงานพิเศษ แต่รู้สึกดีและทำให้ทีมเพิ่มขึ้น


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

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

@LightnessRacesinOrbit - ใช่ฉันกำลังทำให้สิ่งต่าง ๆ ง่ายขึ้นเล็กน้อย Git ไม่ใช่ยาครอบจักรวาล แต่อย่างน้อยการรวมกันก็เป็นไปได้ ฉันอาจจะพูดถึงการทดสอบหน่วยและการยอมรับ
superluminary

3
Agile ไม่ใช่วิธีแก้ปัญหาสำหรับทุกปัญหาและจะไม่ช่วยถ้าคุณไม่ทราบว่าการวางแผนโครงการพื้นฐานและแนวคิดการจัดการ
rmayer06

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

10

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

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

ถัดไปคุณต้องการแบ่งคุณลักษณะเหล่านั้นออกเป็นภารกิจ (เรื่องราว) สิ่งเหล่านั้นควรเป็นเรื่องง่ายเช่น "เมื่อผู้ใช้คลิกปุ่มโปรแกรมจะโหลดไฟล์", "เมื่อโปรแกรมเริ่มทำงานมันจะโหลดไฟล์กำหนดค่า" เป็นต้น

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

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

ฉันขอแนะนำให้อ่าน "Extreme Programming" โดย Kent Beck หนังสือยอดเยี่ยมที่ช่วยฉันเมื่อฉันกำลังจะเป็นผู้จัดการโครงการ


1
หากสมาชิกในทีมพูดคุยกันความขัดแย้งเป็นครั้งคราว (ในความหมายการควบคุมเวอร์ชัน) สามารถแก้ไขได้อย่างง่ายดาย การประชุมประจำวันช่วยได้สิ่งนี้
Jan Hudec

10

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

ตรวจสอบให้แน่ใจว่าคุณบังคับใช้ TDD กับนักพัฒนาเพื่อรับประกันว่าโมดูลทั้งหมดจะทำงานแยกกัน

เพื่อให้ตัวอย่างของสิ่งที่ฉันหมายถึง:

สมมติว่าคุณต้องการให้หนึ่งในนักพัฒนาสร้างตัวบันทึก SQL

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

interface ILogger
{
    void Log(string message, int level);
}

สิ่งที่ฉันคาดหวังกลับมาจากนักพัฒนาคือ:

  1. การใช้งานเฉพาะ SQL สำหรับคนตัดไม้

    class SqlLogger : ILogger
    {
        private readonly SqlLogRepository _logRepository;
    
        public SqlLogger(SqlLogRepository _logRepository)
        {
            this._logRepository = _logRepository;
        }
    
        public void Log(string message, int level)
        {
            _logRepository.CreateLog(message,level);
        }
    }
    
  2. รหัสอ้างอิงใด ๆ เช่นการติดตั้งใช้งาน SqlLogRepository

  3. การทดสอบหน่วยหรือการเยาะเย้ยขึ้นอยู่กับสิ่งที่ถูกถาม การทดสอบการเยาะเย้ยในกรณีข้างต้น (ที่เรามีการอ้างอิงภายนอกอื่น ๆ ) หรือถ้ามันเป็นฟังก์ชั่นยูทิลิตี้อย่างง่ายเช่นString.ReverseCharacters(string input)จากนั้นฉันก็อยากจะเห็นการทดสอบหน่วยที่ทดสอบสถานการณ์ที่แตกต่างกันไม่กี่

ซึ่งหมายความว่า:

คุณและทีมของคุณสามารถพัฒนาต่อไปได้โดยใช้ส่วนต่อประสานนี้ เช่น

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

และหากคุณจำเป็นต้องเรียกใช้รหัสของคุณก่อนที่SqlLoggerจะเข้าแทนที่คุณสามารถสร้างNullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

และนี่คือวิธีที่คุณสามารถทดสอบในระหว่างนี้ (ฉันขอแนะนำให้ดูที่ ICO สำหรับการฉีดพึ่งพา)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

สรุป

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

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


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

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

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

ฉันคิดว่าจำเป็นต้องมี TDD การไม่ทำ TDD นั้นเหมือนกับการไม่ล้างมือในฐานะแพทย์หรือไม่ทำสมุดบัญชีสองครั้งเพื่อรักษาบัญชี ฉันรู้ว่า ppl ไม่เห็นด้วย แต่แพทย์ก็ไม่เห็นด้วยกับดร. เซมเมลไวส์ อย่างไรก็ตามฉันคิดว่า TDD ไม่สามารถ "บังคับใช้" ได้ TDD สามารถสอนและใช้ชีวิตเป็นตัวอย่างได้ แต่ถ้ามันเป็น "การบังคับใช้" ฉันกลัวว่ามันจะไม่ทำงานเนื่องจากแรงมักทำให้เกิดแรงต้าน / แรงต่อต้าน
Christian Hujer

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

2

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

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

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

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


1

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.