การขาดข้อกำหนดด้านการทำงานมีความคล่องตัวหรือไม่?


10

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

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

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

ดังนั้นฉันคิดว่า - มันเป็นความว่องไวอย่างแท้จริงที่จะไม่มีความต้องการทางธุรกิจในกรณีที่เขียนระบบเก่าหรือไม่?


1
ระบบเก่าจะถูกใช้งานจนกว่าระบบใหม่จะมาแทนที่หรือจะใช้ทั้งสองระบบพร้อมกันพร้อมกับระบบใหม่จะค่อยๆเปลี่ยนฟังก์ชั่นในระบบเก่าหรือไม่
เกร็ก Burghardt

1
@GregBurghardt ตัวเลือกที่สอง
Landeeyo

1
ทีมของคุณวางแผนจะทำอะไรดี คุณจะรวบรวมพวกเขาคุยกับนักธุรกิจหรือไม่?
Filip Milovanović

2
นอกจากนี้โปรดจำไว้ว่าคุณสามารถแก้ไขข้อ จำกัด สองในสามข้อเท่านั้น: เวลาความพยายามและขอบเขต ถ้าเวลาได้รับการแก้ไข (ตามที่คุณพูดในความคิดเห็นของคุณ) และความพยายามได้รับการแก้ไขหรืออย่างน้อยที่สุด (หัวหน้าของคุณเต็มใจที่จะจ้างนักพัฒนาที่ไม่มีที่สิ้นสุด?) ดังนั้นขอบเขตไม่คงที่และคุณควรทำในเวลาที่กำหนด ที่คุณมี (นี่คือสิ่งที่ Scrum ทำกับ Sprints) หรือคุณควรยอมรับความล้มเหลวและดำเนินการต่อ (อาจเป็น บริษัท อื่นที่ผู้บังคับบัญชาเข้าใจการพัฒนาซอฟต์แวร์หรือปล่อยให้คนที่ทำ)
Blueriver

3
ฉันจะเรียกว่าเปราะบางจริง ๆ
Mason Wheeler

คำตอบ:


21

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

คุณต้องบอกเจ้าของธุรกิจว่าคุณไม่รู้ว่าระบบเก่าทำงานอย่างไร

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

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

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

คุณจะได้รับอย่างใดอย่างหนึ่งต่อไปนี้:

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

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

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


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

16

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

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

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

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


1
บางคนอาจโต้แย้งว่าสถานการณ์เช่นนี้เหมาะอย่างยิ่งกับความคล่องตัว คุณมีระบบที่เข้าใจได้ยากที่คุณพยายามแทนที่ ดังนั้นเข้าใจบิตเล็ก ๆ น้อย ๆ (เกณฑ์การยอมรับ) สร้างบิตเล็ก ๆ (วิ่ง) และรับคำติชม (สาธิต) นวดแล้วล้างซ้ำ
Bryan Oakley

4

ข้อกำหนดในการจับภาพเป็นส่วนสำคัญของโครงการซอฟต์แวร์ใด ๆ (สำเร็จ) แต่การเขียนข้อกำหนดเฉพาะไม่ใช่

  • วิธีการที่เป็นศูนย์กลางของเอกสารสามารถจบลงได้เหมือนเกม Chinese Whispers: ผู้เชี่ยวชาญเรื่องเสียงต้องการนักวิเคราะห์เขียนลง dev พยายามเขียนสิ่งที่ตรงกับคำอธิบายของนักวิเคราะห์ผู้ใช้สับสนเพราะซอฟต์แวร์ไม่ได้ ไม่สามารถแก้ปัญหาได้

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

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

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

    โดยแสดงความต้องการเป็นการทดสอบที่รันได้ ปรากฎว่า "สเปคที่อ่านได้" และ "การทดสอบที่รันได้" ไม่ใช่แนวคิดพิเศษ แต่สามารถจบลงด้วยการเป็นหนึ่งเดียวและเอกสารเดียวกัน เช่นแตงกวาและแนวคิดอื่น ๆ นอกพื้นที่ BDD มีประโยชน์มากที่นี่

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

การมีระบบการทำงานอยู่รอบ ๆ ก็มีประโยชน์มากสำหรับการทดสอบซอฟต์แวร์ใหม่ แต่นั่นไม่เกี่ยวข้องกับข้อกังวลใด ๆ

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

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


1

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

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

ดังนั้นในขณะที่ Agile สามารถถอดออกได้ในบางส่วนของระบบอย่างรวดเร็วคนอื่น ๆ จะต้องมีความคิดและเอกสารก่อนที่เราจะเริ่ม


0

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


0

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

กับดักที่ฉันกำลังพูดถึงกำลังคิดว่ามีวิธีที่คล่องตัวและถูกต้องในการทำสิ่งต่าง ๆ อาจเป็นเพราะคนคิดว่า Agile มีอยู่จริง คุณไม่สามารถทำ Agile ได้มากกว่าที่คุณสามารถทำได้ในทางปฏิบัติ

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

จะมีการเปิดเผยการอภิปรายการเรียนรู้การย้อนกลับและการเปลี่ยนซอฟต์แวร์หรือไม่ คุณกำลังสร้างsoft ware หรือฮาร์ดแวร์อยู่หรือเปล่า?

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

การระบุช่องโหว่ในแผนไม่ได้เกี่ยวกับการค้นหาความผิด แต่เป็นเพียงการพัฒนาซอฟต์แวร์

ด้วยเหตุนี้ฉันชอบคำตอบของ Guy

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