ความคล่องตัวสามารถนำไปใช้กับแอพพลิเคชั่นที่เกี่ยวกับการประมวลผลที่ซับซ้อน

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

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

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

• คอมไพเลอร์
• ระบบวิเคราะห์ภาพของรถยนต์ขับเคลื่อนด้วยตนเอง
• ระบบจำลองการไหลของของไหล

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

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

Agile ไม่ได้เฉพาะเจาะจงกับแอพ CRUD

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

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

เรื่องราวของผู้ใช้! = ข้อกำหนด

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

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

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

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

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

ตัวอย่าง

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

การเปิดเผยของผู้ใช้

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

เป็นไปได้หรือไม่ที่จะทำให้ผู้ใช้มองเห็นในทางใดทางหนึ่ง?

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

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

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

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

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

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

อย่างไรก็ตามข้อกำหนดอาจมีเพิ่มเติมเกี่ยวกับระบบ เช่น:

ฟังก์ชั่นabcในองค์ประกอบAจะต้องมีค่าเกณฑ์ความอดทนลดลงในอัลกอริทึมการเปรียบเทียบภาพเพื่อตรวจจับวัตถุที่เคลื่อนที่ช้า

สำหรับฉันแล้วนี่จะเป็นงานภายใต้เรื่องราวของผู้ใช้ที่ฉันกล่าวถึงข้างต้นโดยมีชื่อเรื่องดังนี้: ลดความอดทนในการทำงานA.abcแล้วรวมรายละเอียดอื่น ๆ ที่เกี่ยวข้องไว้ในนั้น

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

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

ความสัมพันธ์ระหว่างเรื่องและงาน

ที่นี่มันยากที่จะเกี่ยวข้องกับงานและเรื่องราวของผู้ใช้

วิธีการของเราคือเพื่อให้เรื่องที่ผู้ใช้มุ่งเน้นไปที่สิ่งที่ร้องขอคือเหตุผลที่มันถูกสร้างขึ้นและสิ่งที่จำเป็นจะต้องเป็นความจริงที่จะต้องพิจารณาสหรัฐฯ "ทำ" ว่าถูกทิ้งมักจะออกของสหรัฐและซ้ายให้กับนักพัฒนา (s)

นักพัฒนาซอฟต์แวร์จะแยกแยะปัญหาที่อธิบายในสหรัฐอเมริกาเป็นชุดของงานที่พวกเขาจะทำงาน

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

บางครั้งฉันก็ใช้ AJAX เพื่อแสดงภาพเคลื่อนไหว "loading ... " อย่างง่าย ๆ เพื่อให้ผู้ใช้รู้ว่าพวกเขาต้องการรอสักครู่เพื่อให้สิ่งอื่นเสร็จสมบูรณ์โดยไม่รู้สึกผิด บางครั้งมันก็ง่ายอย่างนี้ งานนี้จะเหมาะสม

กระบวนทัศน์ที่แตกต่างกันการฝึกฝนและประสบการณ์

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

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

เมื่อพิจารณาจากถ้อยคำก่อนหน้าของคุณคุณยังคงคิดถึงเรื่องราวราวกับว่ามันเป็น "ข้อกำหนดการเปลี่ยนชื่อ" ซึ่งฉันคิดว่าเป็นข้อสันนิษฐานที่ผิดพลาด ฉันคิดว่านี่เป็นอาการของปัญหาที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับความแตกต่างพื้นฐานระหว่างแนวทาง Agile และ Non-Agile

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

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

เรียนรู้จาก Sprints ของคุณ - ย้อนหลัง

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

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

หลักการที่คล่องตัวสามารถนำไปใช้ได้อย่างแน่นอนในกรณีเหล่านี้ อย่างไร?

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

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

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

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

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

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

ฉันคิดว่าปัญหาคือการให้ความหมายแก่เรื่องราวของผู้ใช้ที่พวกเขาไม่มี Scrum ใช้คำว่า PBI หรือ Product Backlog Item ซึ่งฉันคิดว่าดีกว่ามาก PBIs จะมักจะทำตามรูปแบบเรื่องราวผู้ใช้ตัวอย่างเช่นคุณอาจมี PBI เช่น "สมาชิกควรจะสามารถดูรายละเอียดการสมัครสมาชิกของพวกเขา" แต่คุณยังอาจได้อย่างง่ายดายเพียงมี PBI เช่น "สร้างกระบวนงานที่เก็บไว้เพื่อดูรายละเอียดสมาชิก "

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

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

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

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

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