พิจารณาแนวทางที่คล่องตัว ฉันหมายความว่าถ้าคุณมีเวลาและมีทักษะการเขียนที่ยอดเยี่ยมในการเขียนการตัดสินใจการออกแบบทุกครั้งที่พวกคุณทำพร้อมกับเหตุผลของพวกเขาเพียงบันทึกทุกอย่าง ฉันพูดอย่างแนบเนียนว่าคุณไม่ได้อยู่ในตำแหน่งแบบนั้น วิธีการแบบว่องไวสามารถช่วยในการท้าทายที่สำคัญสำหรับเอกสารของเหตุผล: คุณมักจะไม่ทราบเหตุผลที่เป็นสิ่งที่สำคัญจนกระทั่งในภายหลัง
ลองเข้าหาปัญหาจากมุมมองแบบองค์รวม พวกคุณมีเหตุผลในการตัดสินใจของคุณ พวกเขากำลังถูกขังอยู่ใน squishyware ในตอนนี้สมองของทีม แม้จะมีเอกสารเครดิตจำนวนมาก แต่การเก็บเหตุผลใน sqishyware นั้นไม่ได้เลวร้ายอะไรนัก จริงๆแล้วเราดีมากในฐานะเผ่าพันธุ์ที่จำสิ่งสำคัญได้ เหตุใด บริษัท ยักษ์ใหญ่ทุกแห่งจึงมี "ความรู้เกี่ยวกับชนเผ่า" แม้ว่า บริษัท เหล่านั้นพยายามที่จะจัดทำเอกสารความรู้เกี่ยวกับเผ่าทั้งหมด
ตอนนี้คุณมีปัญหา คุณกำลังพบว่า sqiushyware ไม่ได้ถือเหตุผลที่ดีพอ ดีสำหรับคุณที่ตระหนักว่ามีปัญหาและระบุว่าต้องแก้ไข! นั่นไม่ใช่ขั้นตอนที่ง่ายเสมอไป! ดังนั้นเราค่อนข้างมั่นใจว่าทางออกคือการลดเหตุผลบางอย่างลงในเอกสาร อย่างไรก็ตามนั่นยังไม่เพียงพอ เราไม่สามารถลืมช่วงครึ่งหลังของปริศนาซึ่งมีการบรรจุเหตุผลเข้าไปใน squishyware อีกครั้งเมื่อคุณต้องการตัดสินใจ ฉันได้เห็นทีมมากมายที่ทำเอกสารทุกอย่างอย่างบ้าคลั่ง แต่เนื้อหาไม่ได้ถูกจัดระเบียบเพื่อช่วยในการตัดสินใจที่ดีดังนั้นพวกเขาจึงลืมเหตุผลแม้ว่าพวกเขาจะถูกเขียนลงไปก็ตาม
ดังนั้นคุณมีกระบวนการสองขั้นตอน คุณจำเป็นต้องนำเหตุผลออกจาก squishyware และลงในเอกสาร จากนั้นคุณต้องตรวจสอบให้แน่ใจว่าเอกสารมีการจัดระเบียบที่ดีพอที่จะนำเหตุผลกลับมาสู่ squishyware เมื่อคุณต้องการ! ตอนนี้ฉันคิดว่าเรามีคำแถลงปัญหาเพียงพอที่จะตระหนักว่าความท้าทายจะเป็นอย่างไร เมื่อคุณกำลังทำเอกสารคุณมักจะไม่รู้ว่าใครกำลังจะดูในภายหลังหรือสิ่งที่พวกเขากำลังมองหา ในทำนองเดียวกันเมื่อคุณดูเอกสารคุณมักจะไม่รู้ว่าคุณกำลังมองหาอะไร (ที่ดีที่สุดที่คุณอาจรู้เมื่อ)
ดังนั้น บริษัท ขนาดใหญ่อาจพยายามจัดการเรื่องนี้ในสองช่วงตึกใหญ่ ก่อนอื่นพวกเขาอาจพัฒนาข้อกำหนดตามสิ่งที่ผู้คนต้องการเมื่อทำการค้นคว้าเอกสาร จากนั้นพวกเขาใช้ข้อกำหนดเหล่านั้นเพื่อสร้างกระบวนการสำหรับการพัฒนาเอกสารดังกล่าว และถ้าฉันกล้าพูดอย่างนั้นทุกคนก็บ่นเพราะไม่มีใครรู้ว่าเอกสารควรมีหน้าตาเป็นอย่างไรในวันแรก เอกสารไม่สมบูรณ์อยู่เสมอและนักพัฒนามักบ่นว่ากระบวนการนี้เป็นภาระมากเกินไป
ได้เวลาว่องไว
คำแนะนำของฉันคือการเริ่มต้นความพยายามที่รวดเร็วเพื่อปรับปรุงกระบวนการเอกสารของคุณ: ทั้งเก้าหลาจาก squishyware ไปยังเอกสารและกลับไปที่ squishyware รับทราบล่วงหน้าว่าคุณจะสูญเสียข้อมูลบางส่วนเนื่องจากกระบวนการของคุณไม่สมบูรณ์แบบ แต่ก็ไม่เป็นไรเพราะคุณยังคงพยายามหากระบวนการ! คุณจะพลาดมากกว่านี้ถ้าคุณพยายามสร้างขนาดที่เหมาะกับโซลูชันทั้งหมด
เกร็ดเล็กเกร็ดน้อยโดยเฉพาะฉันจะดูที่: * สำรวจเอกสารทางการ เอกสารทางการนั้นยอดเยี่ยม แต่ใช้เวลานาน หนึ่งในวัตถุประสงค์ของการจัดทำเอกสารคือการเผยแพร่ข้อมูลจากนักพัฒนา squishyware และวางลงบนกระดาษ เอกสารอย่างไม่เป็นทางการช่วยลดค่าใช้จ่ายในการดำเนินการ
- ยอมรับรูปแบบเอกสารที่ไม่น่าเชื่อถือ ไม่มีอะไรจะถูกต้องในครั้งแรก เป็นการดีกว่าที่จะได้รับข้อมูลและหาวิธีทำให้เชื่อถือได้ในภายหลัง ตัวอย่างเช่นคุณอาจบันทึกเหตุผลของคุณในบล็อก <rationale> </rationale> หรือสิ่งที่คล้ายกันซึ่งจะทำให้ง่ายต่อการรวบรวมข้อมูลนั้นในภายหลัง การจัดเก็บเหตุผลในเรื่องราวของผู้ใช้สำหรับตอนนี้ก็ไม่เป็นไร!
- อย่าลืมคุณค่าขององค์กร ค้นหาว่าคุณในฐานะทีมต้องการค้นหาเหตุผลในเอกสารประกอบอย่างไรและลองทำตามเอกสารนั้น แต่ละทีมจะมีกระบวนการที่แตกต่างกัน ในหนึ่งในทีมของฉันเราไม่สามารถหาตั๋วที่มีเหตุผลได้ทันที สิ่งที่เราสามารถทำได้คือหาบรรทัดของรหัสที่มีความสำคัญทำ a
svn blameเพื่อค้นหาว่ามันเปลี่ยนไปเมื่อใดและเพราะอะไรจากนั้นไปดูตั๋ว เมื่อเราอยู่ที่นั่นเรามักจะใส่เหตุผลทั้งหมดที่เราต้องการลงในตั๋ว ที่เพิ่งได้ผลกับเราค้นหาว่าอะไรเหมาะกับคุณ
- เอกสารอินทรีย์สามารถเติบโตได้ตลอดเวลา เป็นเรื่องยากสำหรับนักพัฒนาที่จะรู้ว่าเหตุผลใดสำคัญที่สุดในวันที่พวกเขาต้องการเขียน เรามักจะพบสิ่งที่มีความสำคัญในภายหลัง หากคุณมีกระบวนการกรูมมิ่งสำหรับเอกสารที่อนุญาตให้นักพัฒนาจัดการสวนเล็ก ๆ ของพวกเขาเองเหตุผลที่สำคัญจะเพิ่มขึ้นถึงพื้นผิว เหตุผลที่สำคัญกว่านั้นอาจเปลี่ยนไป คุณอาจตระหนักว่าการเปลี่ยนแปลงที่แตกต่างกันสองประการด้วยเหตุผลที่แตกต่างกันสองข้ออธิบายได้ดีที่สุดโดยเหตุผลเดียวที่เหมาะกับทั้งคู่ ตอนนี้มีเนื้อหาระหว่างคุณกับการตัดสินใจน้อยลง!