बिल्ड के बीचोबीच बिज़नेस एक मुख्य requirement बदल देता है। आप क्या करते हैं?

बदलाव को आंकने से पहले पता करें कि बिज़नेस में क्या बदला, क्योंकि उससे पता चलता है कि आगे और आने वाला है या नहीं। फिर impact analysis करें: क्या बन चुका है, क्या डिजाइन हो चुका है, क्या टेस्ट हो चुका है, और क्या दोबारा करना पड़ेगा। लागत सहित विकल्प रखें और फैसला स्पॉन्सर पर छोड़ें, और traceability अपडेट करें ताकि बदलाव अपने पीछे अनाथ टेस्ट और बासी दस्तावेज न छोड़ जाए।

मेरा पहला सवाल बदलाव के बारे में नहीं होता, यह होता है कि वह बदला क्यों, क्योंकि इससे मुझे पता चलता है कि यह इकलौता है या कई में से पहला। अगर कोई नियम बदला या उनका कोई बड़ा क्लाइंट चला गया, तो और बदलाव आने वाले हैं और मुझे उसका प्लान बनाना चाहिए, न कि इसे अलग थलग अनुरोध मानना चाहिए। फिर मैं impact analysis ढंग से करता हूं: क्या पहले से बन चुका है, क्या डिजाइन है पर शुरू नहीं हुआ, कौन से टेस्ट केस मर जाते हैं, कौन सी डॉक्युमेंटेशन बासी हो जाती है, और क्या दोबारा बनाना पड़ेगा। वह नंबर आमतौर पर लोगों की उम्मीद से बड़ा होता है, और टेस्टिंग वाला हिस्सा वही है जिसे कोई गिनता नहीं। मैं इसे लागत सहित विकल्पों के रूप में वापस ले जाता हूं, ताकि स्पॉन्सर चुन सके कि उसे झेलना है, टालना है, या कुछ और छोड़ना है, और फिर हम दोबारा baseline बनाते हैं। आखिरी कदम उबाऊ वाला है: मैं traceability में जाकर सफाई करता हूं, क्योंकि वरना आप एक ऐसी requirement के खिलाफ टेस्ट करते रह जाएंगे जो अब मौजूद ही नहीं है।