เรื่องราวของผู้ใช้ประเภทใดที่ควรเขียนในระยะเริ่มต้นของโครงการ


11

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

สิ่งนี้ไม่สอดคล้องกับแนวคิดของ "งาน" ของฉัน: สำหรับฉันฉันอยากได้งาน "ต่อไปนี้":

  • แสดงข้อมูลจำลองสำหรับ foos ของผู้ใช้ใน HTML ซึ่งได้มาจากวัตถุ JavaScript
  • ตั้งค่าเลเยอร์ตรรกะการนำเสนอและเชื่อมต่อวัตถุ JavaScript กับมัน
  • ตั้งค่าเลเยอร์ตรรกะของโดเมนและเชื่อมต่อเลเยอร์ตรรกะการนำเสนอกับมัน
  • ตั้งค่าชั้นการเข้าถึงข้อมูลและเชื่อมต่อกับชั้นตรรกะของโดเมน

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

คำตอบ:


6

นี่เป็นคำถามที่ดีและอาจมีคำตอบที่ดีหลายข้อ สิ่งที่ฉันใช้คือ:

เรื่องราวเป็นเรื่องราวของผู้ใช้ดังนั้นจึงต้องกำหนดในแง่ที่อธิบายถึงประโยชน์ของผู้ใช้

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

ในช่วงเริ่มต้นของโครงการเมื่อคุณไม่มีกรอบที่เหมาะสมในการพัฒนาCRUD ( C reate, R ead, U pdate, D elete ) การพัฒนาอย่างรวดเร็วและง่ายดายเรื่องราวของคุณจะต้องเล็กลงเพิ่มมากขึ้น ชิ้น

แทนที่จะเป็น"ผู้ใช้ควรดู foo ของพวกเขา" ได้ดังนี้:

  1. ผู้ใช้ควรจะเห็นหน้าเว็บที่มีข้อมูลตัวอย่าง
  2. ผู้ใช้ควรจะเห็นหน้าเว็บที่มีข้อมูลตัวอย่างแบบโต้ตอบ
  3. ผู้ใช้ควรจะเห็นหน้าเว็บที่มีข้อมูลตัวอย่างแบบโต้ตอบสด

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

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


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

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

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

3

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

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

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

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

คุณต้องนำเสนอสิ่งนี้กลับคืนและแสวงหาข้อตกลง

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

บางคนจะเล่าเรื่อง - จากนั้นนำเสนอและอธิบาย

บางคนจะเขียนเอกสารที่เข้มงวดและวิเคราะห์อย่างรอบคอบ

แต่ละเทคนิคมีข้อดีและข้อเสีย

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

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

อย่าปล่อยทิ้งไว้ในการวิเคราะห์ส่วนหน้าและเอกสาร


+1 สำหรับการสนับสนุนการคิดล่วงหน้ามากขึ้น
Gary Rowe

1

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

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


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