เป็นความคิดที่ดีหรือไม่ที่จะเขียนข้อกำหนดเฉพาะตามเรื่องราว?

เรากำลังใช้วิธีการที่คล่องตัวในโครงการปัจจุบันของฉันในขณะนี้และเรามีเรื่องราวมากมายเช่นนี้:

• ในฐานะผู้ช่วยฉันต้องการคืนเงินให้ลูกค้าเพื่อให้พวกเขาได้รับเงินเมื่อพวกเขาร้องขอ

• ในฐานะลูกค้าฉันต้องการชำระค่าสินค้าเพื่อให้สามารถรับสินค้าได้

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

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

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

การเขียนรายละเอียดตามเรื่องราวเป็นความคิดที่ดีหรือไม่? เราเคยเขียนเรื่องราวในทางที่ผิดหรือเปล่า?

นี่อาจจะเป็นข้อโต้แย้ง แต่ที่นี่มันจะไป!

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

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

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

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

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

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

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

ดังนั้นมาถึงคำถามของคุณ:

การเขียนรายละเอียดตามเรื่องราวเป็นความคิดที่ดีหรือไม่? เราเคยเขียนเรื่องราวในทางที่ผิดหรือเปล่า?

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

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

> Writing specs by stories? a good idea?

ใช่ถ้าคุณสามารถจัดการการพึ่งพาซึ่งกันและกันและลำดับความสำคัญของเรื่องราวของคุณ

นี่คือบทความเกี่ยวกับแผนที่เรื่องราวที่สามารถช่วยคุณในการสั่งซื้อและจัดการผู้ใช้จำนวนมาก

เมื่อเขียนคำตอบนี้ฉันรู้ว่ามันไม่เกี่ยวกับการทดสอบ แต่เป็นเรื่องของเอกสาร คุณควรอ่านแถลงการณ์ที่คล่องตัว :

[เราให้ความสำคัญ] ซอฟต์แวร์ที่ใช้งานได้บนเอกสารที่ครอบคลุม

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

การเขียนรายละเอียดตามเรื่องราวเป็นความคิดที่ดีหรือไม่?

ใช่ imho มันเป็น มันเรียกว่า "การพัฒนาพฤติกรรมขับเคลื่อน" หรือ "สเปคตามตัวอย่าง" ในทับทิมมีแตงกวาเครื่องมือยอดเยี่ยมที่ช่วยได้มาก

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

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

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

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

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

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

เราเคยเขียนเรื่องราวในทางที่ผิดหรือเปล่า?

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

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

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

เขียนรายละเอียดตามเรื่องราว? ความคิดที่ดี?

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

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

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

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

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

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