กระบวนการ Agile: ควรทำอย่างไรและควรมีการบันทึกไว้อย่างไร?

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

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

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

ดังนั้นฉันมีคำถาม 2 ข้อ

1. นี่เป็นเรื่องปกติสำหรับความคล่องตัวหรือเป็นข้อแก้ตัวที่ไม่ต้องการเขียนหรือไม่?
2. บรรทัดฐานอุตสาหกรรมสำหรับเอกสารในโครงการแบบว่องไวเพื่อบันทึกความต้องการการพัฒนาการออกแบบการตัดสินใจที่สำคัญและบริบทคืออะไร

นี่เป็นเรื่องปกติสำหรับความคล่องตัวหรือเป็นข้อแก้ตัวที่ไม่ต้องการเขียนหรือไม่?

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

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

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

จะสั้น:

ทีมควรกำหนดว่าต้องใช้เอกสารจำนวนเท่าใด

พวกเขารู้โดเมนพวกเขาเป็นผู้เชี่ยวชาญและที่สำคัญพวกเขาสร้างสิ่ง!

นั่นคือสิ่งที่ซอฟแวร์การทำงานมากกว่าเอกสารครอบคลุมในAgile Manifestoหมายถึง

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

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

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

2. ลิงค์คู่ที่อาจเป็นที่สนใจเป็นเรื่องที่ดีที่สุดที่ฉันสามารถทำได้:

   • แนวทางปฏิบัติที่ดีที่สุดสำหรับเอกสาร Agile / Lean
   • เอกสาร Agile และเทคนิค

เปรียวมีบางจุดเฉพาะในแถลงการณ์ซึ่งฉันจะชี้ให้เห็นสิ่งนี้พร้อมกับบันทึก:

ซอฟต์แวร์ทำงานผ่านเอกสารที่ครอบคลุม

นั่นคือในขณะที่มีค่าในรายการทางด้านขวาเราให้ความสำคัญกับรายการทางด้านซ้ายมากขึ้น

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

อาจไม่ละเอียดเท่าความพยายาม ทฤษฎีคือเมื่อสแตกเวลาสเปคไม่ตรงกับรหัสอีกต่อไป ดังนั้นคุณมีเอกสารเพียงพอที่จะเขียนรหัสและไม่พยายามที่จะกำหนดในรายละเอียด (เรียงลำดับเช่นการเขียนรหัสในบางรหัสปลอม-verbalized-text / diagram-code แล้วในรหัสที่แท้จริง)

ปัญหาของคุณไม่เกี่ยวข้องกับ Agile พวกเขาควรจัดทำเอกสารที่คุณขอมา โครงการมีการจัดการไม่ดี

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

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

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

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