ฉันต้องการอธิบายว่าเพราะเหตุใดข้อกำหนดจึงต้องไม่เปลี่ยนแปลงในระหว่างการพัฒนา

ฉันต้องการอธิบายว่าเพราะเหตุใดจึงไม่มีการเปลี่ยนแปลงข้อกำหนดในระหว่างช่วงเวลาการพัฒนากับพนักงานฝ่ายวางแผนใหม่

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

เหตุผลคือ:

• การพัฒนาหรือการทดสอบการรวมเข้าด้วยกันของโครงการจะทำให้สิ่งต่าง ๆ ที่ไม่ได้สังเกตเห็นเมื่อทำสเป็คดั้งเดิมเสร็จสิ้น - จากกรณีที่มีขอบถึงด้านที่สำคัญ เช่นนักพัฒนาสังเกตว่าการยืนยันข้อความที่ไม่เรียบร้อยอาจมาถึง

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

• แรงกดดันกำหนดเวลาส่งผลให้มีการตัดคุณสมบัติ

• มีการค้นพบผู้มีส่วนได้ส่วนเสียเพิ่มเติมในโครงการ (เช่นตรงกลางผ่านโครงการพบโครงการที่คล้ายกันในพื้นที่ต่าง ๆ และระบบย่อยทั่วไปต้องถูกรวมศูนย์ / แชร์ - สิ่งนี้เกิดขึ้นกับฉันตรงกลางผ่านโครงการยาว 2 ปี architeching)

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

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

• การเปลี่ยนแปลงข้อมูลจำเพาะส่งผลให้เกิดการเปลี่ยนแปลงรหัสทำให้คุณไม่สนใจส่วนของโครงการที่ยังไม่ได้เขียน (อย่างที่เราทุกคนรู้จักและประกาศโดย Joel Spolsky การเปลี่ยนแปลงที่มุ่งเน้นนั้นแย่มากสำหรับนักพัฒนา)

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

• ในกรณีของ TDD ชิ้นงานขนาดใหญ่ที่นำไปทดสอบอาจถือเป็นโมฆะ

• หากการเปลี่ยนแปลงข้อมูลจำเพาะมาจากผู้มีส่วนได้เสียเพิ่มเติมตามที่ระบุไว้ข้างต้นพวกเขาอาจขัดแย้งกับข้อมูลจำเพาะที่มีอยู่ส่งผลให้คุณภาพของผลิตภัณฑ์ลดลงอย่างมีนัยสำคัญ (ดู Fighting Vehicle, Bradley)

• การเปลี่ยนแปลงข้อมูลจำเพาะอาจละเมิดข้อกำหนดทางธุรกิจที่มีอยู่ซึ่งผู้เปลี่ยน / ผู้ร้องขออาจไม่ได้รับทราบหรือได้รับการดูแล

แน่นอนว่าจำนวนเงินทั้งหมดนี้มีการขยายเวลาส่งมอบของโครงการ (บางครั้งอย่างมีนัยสำคัญ) และอาจเพิ่มโอกาสในการเกิดข้อบกพร่อง

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

Y2K

ทั้งหมดที่พวกเขาทำคือเปลี่ยนข้อมูลจำเพาะเพื่อพูดว่า " ต้องทำงานหลังจากปี 2000 "

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

• ส่วนหนึ่งของสเป็คคือ (หรือขึ้นอยู่กับ) สเปคของระบบภายนอกที่จะต้องมีการเชื่อมต่อกับ

• ส่วนหนึ่งของข้อมูลจำเพาะคือ (หรือขึ้นอยู่กับ) ฮาร์ดแวร์ที่ใช้กับระบบ

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

• ระบบอาจต้องปฏิบัติตามข้อกำหนดทางกฎหมายหรือข้อบังคับเฉพาะโดยไม่คำนึงถึงความต้องการของลูกค้า ตัวอย่าง: การเข้ารหัสบัตรเครดิต, การป้องกันข้อมูลภาษี

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

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

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

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

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

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

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

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

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

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

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