วิธีจัดการกับการออกแบบส่วนต่อประสานกับผู้ใช้และรองรับคุณสมบัติต่าง ๆ ในการพัฒนา Agile?

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

ตัวอย่างเช่นลูกค้าอาจขอหน้าค้นหาสำหรับผู้ใช้ทั้งหมดในฟอรัมและมีการดำเนินการหลายอย่างที่อาจเกิดขึ้นกับผู้ใช้แต่ละรายเช่นผู้ใช้แบนผู้ใช้ลบผู้ใช้รีเซ็ตรหัสผ่าน ฯลฯ

เราอาจแบ่งคุณลักษณะนี้ออกเป็นเรื่องราวของผู้ใช้อย่างน้อย 4 เรื่อง:

1. ค้นหาผู้ใช้
2. แบนผู้ใช้
3. ลบผู้ใช้
4. รีเซ็ตรหัสผ่าน

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

หากเขาตัดสินใจที่จะทำงานกับคุณลักษณะทั้งหมด (การค้นหา + การกระทำ) จะเกิดอะไรขึ้นถ้าการกระทำที่มีลำดับความสำคัญต่ำและจะต้องดำเนินการซ้ำหลายครั้งหลังจากฟังก์ชั่นการค้นหาเสร็จสิ้นแล้ว

เอามันซ้ำ ๆ คุณกำลังทำงานกับผู้ใช้โดยตรงใช่ไหม ดังนั้นจึงไม่ควรเป็นระเบียบ

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

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

ตอนนี้เพิ่มรายการถัดไปและรายการถัดไป ...

วิธีการที่คล่องตัวบอกว่าคุณมีข้อเสนอแนะอยู่เสมอดังนั้นคุณควรจะดี

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

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

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

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

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

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

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

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

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

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

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

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