การแบ่งเรื่องราวที่ซับซ้อนตั้งแต่เริ่มโครงการ


9

ฉันกำลังพยายามที่จะจับกับการจัดการโครงการเปรียว (กับ Pivotal Tracker) แต่พบว่าตัวเองวิ่งเข้าไปในกำแพงเมื่อพยายามที่จะกำหนดเรื่องราวสองสามเรื่องแรกของโครงการ ยกตัวอย่างเรื่องง่าย ๆ นี้:

"ผู้ใช้ควรแท็กผลิตภัณฑ์"

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

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

คุณจะเอาชนะสิ่งนี้ได้อย่างไร อะไรคือการปฏิบัติที่ดีที่สุด?

อัปเดต 25/08ขอบคุณทุกคนสำหรับคำแนะนำของคุณฉันได้รับคำแนะนำทั้งหมดเกี่ยวกับวิธีการกำหนดเรื่องราว ตอนนี้ฉันกำลังเปลี่ยนไปใช้ Jira Grasshopper ซึ่งได้รับการสนับสนุนที่ดีกว่าสำหรับงานในเรื่อง (การมอบหมายประมาณการและอื่น ๆ ) และการติดตามงานพัฒนาเมื่อเริ่มการวิ่ง


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

1
@ Baqueta แต่เป็นเรื่องราวที่มีการประเมินในคะแนนหรือไม่ และคะแนนเหล่านั้นจะถูกติดตามว่าเป็นความเร็วของทีมอย่างน้อยก็เป็นวิธีการตั้งค่าใน Pivotal Tracker
matthewrk

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

คำตอบ:


7

หากคุณต้องการให้เรื่องราวของคุณเป็นงานนักพัฒนา 1 ถึง 2 วันบางทีคุณควรแบ่งเรื่องราวแต่ละเรื่องออกเป็นงานผู้ใช้เฉพาะซึ่งเป็นงานนักพัฒนา 1 ถึง 2 วัน

พิจารณา "เรื่องราวผู้ใช้:" ต่อไปนี้

ผู้ใช้ควรสามารถรับใบแจ้งหนี้จากผลิตภัณฑ์ที่ซื้อได้

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

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

  • ผู้ใช้วางสินค้าลงในตะกร้า
  • ผู้ใช้ระบุปริมาณ
  • ผู้ใช้ระบุประเภทการจัดส่ง

และอื่น ๆ ในระยะสั้นคุณจะต้องแยกย่อยเรื่องราวผู้ใช้ของคุณให้ละเอียดยิ่งขึ้น


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

7

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

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

แต่คุณอาจจะเอาชนะสิ่งนี้ หลักการ XP ของYAGNIใช้ที่นี่ เพื่อความชัดเจนคุณไม่ควรใช้ "ระบบการติดแท็กแบบ polymorphic ภายใต้ประทุน" เว้นแต่คุณต้องการจริงๆ ถึงกระนั้นก็ควรได้รับการออกแบบโดยการปรับปรุงระบบที่มีอยู่ว่าคุณได้พัฒนาด้วยชุดการทดสอบที่ดี

หากคุณมั่นใจว่าคุณต้องการระบบการติดแท็กที่ซับซ้อนนี้คุณควรจะเรียกความซับซ้อนในเรื่องต่างๆ Mike Cohn อธิบายวิธีการออกแบบว่า " เจตนา แต่ยังเกิดขึ้นได้ "


ฉันไม่เห็นการแก้ไขของคุณ ฉบับดั้งเดิมของคุณบอกว่า "ไม่ทำ" ซึ่งฉันรู้สึกว่าไม่ได้เพิ่มคุณค่าใด ๆ สันนิษฐานว่า "ระบบการแท็ก polymorphic" เป็นส่วนหนึ่งของข้อกำหนด ฉันได้แก้ไขเพื่อยกเลิกการเน้นด้าน "overengineering" ของคำตอบของคุณและเปลี่ยน downvote ของฉันเป็น upvote
Robert Harvey

ฉันยังอยู่ข้างๆ "อย่าทำ" :) การแย่งชิงกันเป็นวิธีการเฉพาะที่ OP จะไปกับหลักการการแย่งชิงกัน
Dave Hillier

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

2
@matthewrk นั่นคือสิ่งที่YAGNIเป็นเรื่องเกี่ยวกับ: ไม่ได้พยายามที่จะทำให้เต็มรูปแบบระบบการติดแท็ก polymorphic เลย ทำให้เป็นเรื่องง่ายสำหรับกรณีการใช้งานเฉพาะอย่าง หากเจ้าของผลิตภัณฑ์กลับมาพร้อมกับอีกหนึ่งเรื่องราวที่เกี่ยวกับการติดแท็กสิ่งอื่น ๆแล้วคุณขยายระบบที่มีอยู่ที่เรียบง่ายเป็นระบบการติดแท็ก polymorphic เพียงเพราะคุณคิดว่ามันจะมีความจำเป็นไม่ได้หมายความว่ามันจะเป็น; มันอาจกลายเป็นว่าการติดแท็กรุ่นอื่น ๆ นั้นไม่จำเป็นเลยซักพักแล้วทุกคนก็ลืมเรื่องนี้ไป ดังนั้น "คุณจะไม่ต้องการมัน"
Izkata

7

ดูเหมือนว่าคุณกำลังสับสนเรื่องและงาน

เรื่องราวของผู้ใช้

เรื่องราวของผู้ใช้คือ "คุณสมบัติ" ที่สมบูรณ์ซึ่งเป็นสิ่งที่เมื่อเพิ่มเข้ากับผลิตภัณฑ์จะให้คุณค่ากับผลิตภัณฑ์มากขึ้น

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

งาน

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

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

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

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

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

มหากาพย์

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

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

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

ใช้ Pivotal Tracker

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


1
ขอบคุณนี่เป็นการล้างเวิร์กโฟลว์ให้ฉันอย่างแน่นอน เมื่อนักพัฒนาแบ่งเรื่องราวออกเป็นภารกิจพวกเขาสร้างเรื่องราวเพิ่มเติมเพื่อติดตามงานเหล่านั้นหรือไม่ หรือเพิ่มงานให้กับเรื่อง? พยายามหาวิธีใช้สิ่งนี้ใน Pivotal Tracker
matthewrk

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

4

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

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

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

... และฉันจะไปต่อ

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

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

ด้วยสิทธิ์ใช้งานที่เป็นศิลปะมากขึ้นฉันอาจแยก "ในฐานะผู้ใช้ระบบที่ฉันต้องการให้สามารถแนบแท็กเดียวกับผลิตภัณฑ์เดียว" เป็นชิ้นแนวตั้งต่อไปนี้:

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

แต่ละคนสามารถทดสอบได้ - หากไม่มีคุณค่าโดยเฉพาะในสิทธิของตนเอง


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

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

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

2

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

บ่อยครั้งที่ฉันพบว่าทีมพัฒนาพยายามหาทางแก้ปัญหาที่ซับซ้อนแทนที่จะใช้วิธีที่ง่ายที่สุด อาจเป็นเพราะเรื่องราวของตัวเองหรือเพราะทีมต้องการหาวิธีแก้ปัญหาที่ซับซ้อนมากเกินไปซึ่งไม่เพียง แต่แก้ไขเรื่องราวนี้ แต่ยังวางรากฐานสำหรับเรื่องราว x, y และ z ด้วย นี่เป็นความตั้งใจที่ดี แต่ bloats มีขอบเขตที่สามารถทำงานเดียวกันได้โดยมีงานน้อยลง เป็นการยากที่จะตัดสินว่าการออกแบบจะต้องมีเรื่องราวมากน้อยเพียงใดที่จะไม่ทำลายเรื่องราวในอนาคตโดยการออกแบบให้ยุ่งเหยิง การตัดสินใจครั้งนี้สำหรับทีมที่จะทำให้

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.