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

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

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

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

ข้อมูลเชิงลึกของคุณยินดีต้อนรับมากที่สุด

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

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

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

เป็นส่วนใหญ่ของงานของนักพัฒนาในการค้นหาว่าลูกค้าต้องการอะไรเมื่อพวกเขาไม่รู้บ่อยครั้ง

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

สิ่งนี้อาจฟังดูใช้เวลานาน แต่เมื่อเทียบกับการพัฒนาผลิตภัณฑ์ที่เสร็จสิ้นตามสมควรแล้ว

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

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

นั่นไม่ใช่เสียง "XP" มากสำหรับฉัน

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

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

เพื่อสรุปคุณอยู่ในสถานการณ์ต่อไปนี้:

1. คุณยังใหม่อยู่
2. โครงการ (ฉันถือว่าคุณกำลังพูดถึงโครงการที่กำลังทำงานอยู่) มีข้อ จำกัด เรื่องเวลา
3. ผู้พัฒนาคาดว่าจะกรอกข้อมูลลงในช่องว่างตามดุลยพินิจของเขาเอง
4. บริษัท ที่คุณกำลังทำงานตั้งใจจะฝึกหัด XP อย่างไรก็ตามเรื่องราวของผู้ใช้ดูเหมือนจะไม่ถูกนำไปใช้ในทางที่สอดคล้องกับวิธีการของ XP ในทางกลับกัน " นักพัฒนาคาดว่าจะเติมช่องว่างตามดุลยพินิจของเขา "

คิดเกี่ยวกับประเด็นที่ 4: ความคิดเห็นของฉันคือการปฏิบัติที่คล่องตัวควรปรับให้เข้ากับความต้องการและวัฒนธรรมของ บริษัท / ทีม (ไม่ใช่วิธีอื่น ๆ ) ระบุตำแหน่งที่ บริษัท ยึดมั่นกับวิธีการของ XP และสถานที่ที่เบี่ยงเบน นี่เป็นรากฐานสำหรับแนวทางที่สร้างสรรค์สำหรับข้อกังวลของคุณ

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

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

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

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

ที่กล่าวว่านักพัฒนายังต้องถาม : "คุณคาดหวังว่าสิ่งนี้จะทำงานอย่างไร", "เกิดอะไรขึ้นเมื่อมันทำงานกับฟีเจอร์ Z" นักพัฒนาไม่ทำตามข้อกำหนดพวกเขาใช้งาน

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

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

จากนั้นถามคำถามของคุณและทำให้แน่ใจว่าคำตอบเป็นส่วนหนึ่งของเรื่องราว

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

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

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

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

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

บางคนควรถามคำถามว่าเรื่องราวนั้นคลุมเครือเกินไปหรือไม่ สถานที่ที่ไม่ทดสอบการยอมรับเกิดขึ้น?

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

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

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

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

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

XYZ ไม่ชัดเจนสำหรับฉัน มันหมายถึง ABC หรือไม่? หรือฉันกำลังพลาดอะไรอยู่? (สมมติว่า XYZ เป็นข้อกำหนดสมมติว่า ABC เป็นข้อสมมติที่ฉันต้องการให้เป็นนักพัฒนา)

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

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

ในฐานะนักพัฒนา

ฉันต้องเข้าใจรายละเอียดเฉพาะของเรื่องราวของผู้ใช้

เพื่อให้ฉันสามารถประเมินและใช้งานได้อย่างมั่นใจ

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