ออกแบบเอกสารโดยเป็นส่วนหนึ่งของ Agile

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

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

มีมาตรฐานที่มีประสิทธิภาพสำหรับสิ่งนี้หรือไม่?

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

"ข้อกำหนดที่คลุมเครือเกณฑ์การยอมรับที่ไม่ดีโชคดี!"

ใช่นี่เป็นข้อกำหนดแบบเดียวกับที่คุณได้รับแม้ว่าคุณจะพยายามตอกตะปูลง! (ตัวอย่างเช่นเอกสารข้อกำหนด 10,000 ข้อที่ใช้เวลา 4 ปีในการสร้างลูกค้ารัฐบาลยังคงเต็มไปด้วยความไม่สอดคล้องกันความคลุมเครือและแม้กระทั่งข้อความที่ขัดแย้งกันภายในหากเอกสารข้อกำหนด 4 ปีไม่สามารถทำให้คุณได้รับความถูกต้องถูกต้องแม่นยำ คุณเคยคิดบ้างไหมว่าคุณจะได้อะไรที่ไม่คลุมเครือ?)

ดังนั้น ... วิธีการที่ว่องไวได้ถูกคิดค้นขึ้นเพื่อทำความเข้าใจว่าสิ่งนี้เกิดขึ้นและทำงานร่วมกับมันแทนที่จะพยายามที่จะทำงานกับมัน

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

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

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

ก่อนสิ่งอื่นให้แน่ใจว่าจะอ่านบทความเกี่ยวกับเปรียว / เอกสารแบบ อ่านดีมาก

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

คุณต้องถามตัวเองว่าทำไมคุณถึงต้องการออกแบบเอกสารก่อนการเข้ารหัส สำหรับพวกเราด้วยเหตุผลเหล่านี้:

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

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

(2) หรือ (3) ไม่จำเป็นในระหว่างการพัฒนาเรื่องราวปัจจุบันและมากกว่านั้นพวกเขาจะไม่จำเป็นสำหรับการวนซ้ำในภายหลัง

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

ดังนั้นสิ่งที่ฉันอยากจะแนะนำ:

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

"มนต์" Agile ไม่ควรทำโดยไม่มีเอกสารประกอบทั้งหมด

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

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

ลุงบ๊อบมีนโยบายที่ดีสำหรับการจัดทำเอกสาร

ผลิตเอกสารไม่เว้นแต่มันจำเป็นที่จะต้องได้ทันทีและอย่างมีนัยสำคัญ

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

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

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

กล่าวคือ ทำให้ความต้องการในทันทีและมีความสำคัญ

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

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

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

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

เรามีอีกเรื่องหนึ่งในงานในมือของเราเพียงเพื่อปรับปรุงเอกสารประกอบสำหรับชิปที่เราใช้เพื่อให้ง่ายขึ้นสำหรับทีมอื่น ๆ ในการรับผลิตภัณฑ์ของตนเอง

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

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

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

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