जोखिम प्रबंधन और चुस्त कैसे पार करें?

हम कस्टम विकास में स्क्रैम की विशेषताओं के बारे में बात करना जारी रखते हैं , और इस लेख में मैं आपको बताऊंगा कि जोखिम प्रबंधन और चुस्त कैसे पार करें।

कस्टम विकास में, ग्राहक और उसके व्यवसाय से जुड़ी अतिरिक्त संभावित समस्याएं हैं, इसलिए जोखिम प्रबंधन महत्वपूर्ण हो जाता है। पारंपरिक स्क्रैम में ऐसा अनुशासन नहीं होता है, इसलिए आपको एजाइल के सिद्धांतों को भूलकर क्लासिक जोखिम प्रबंधन दृष्टिकोण को अपनाने की आवश्यकता है।

हालाँकि, Scrum में कोई प्रतिष्ठित प्रबंधन अभ्यास नहीं हैं, यह ध्यान दिया जाना चाहिए कि किसी भी पुनरावृत्ति और वृद्धिशील कार्यप्रणाली की तरह, Scrum ग्राहक से प्रारंभिक प्रतिक्रिया प्राप्त करके जोखिम को काफी कम करता है। स्प्रिंट के पास स्प्रिंट के अंत में रेट्रोस्पेक्टिव्स का संचालन करने का एक बहुत अच्छा अभ्यास है, यह जोखिमों के प्रति प्रतिक्रिया विकसित करने में मदद करेगा, लेकिन दुर्भाग्य से प्रतिक्रियाशील, जोखिमों का एहसास होने के बाद।

जोखिमों के साथ काम कई चरणों में किया जाता है, जिन्हें इस चित्र में दर्शाया गया है:


पहला जोखिम बुद्धिशीलता सत्र को शून्य स्प्रिंट में शामिल किया जा सकता है (वैसे, इसे अभिनव स्पीड बोट गेम के रूप में किया जा सकता है), और फिर प्रत्येक स्प्रिंट को अतिरिक्त रूप से विश्लेषण किया जाना चाहिए और काउंटरमेस विकसित किया जाना चाहिए। मैं, ध्यान दें कि countermeasures कि सक्रिय होना चाहिए, ताकि यह पता चला है सस्ता :) लेकिन किसी भी मामले में, की तुलना में आवश्यक है, ईमानदारी से की सिद्धांतों का अनुसरण अधिक मत करो KISS और YAGNI । ग्राहक के प्रतिनिधि भी एक बुद्धिशीलता में भाग ले सकते हैं, संभावित समस्याओं के बारे में उनकी दृष्टि को देखते हुए।
बुद्धिशीलता सत्र को प्रोत्साहित करने के लिए, मैं निम्नलिखित जोखिम कार्यशालाओं में से एक का उपयोग करने की अत्यधिक सलाह देता हूं:

• एसईआई टैक्सोनॉमी-आधारित जोखिम पहचान - सॉफ्टवेयर इंजीनियरिंग संस्थान से जोखिम वर्गीकरण और प्रश्नावली
• MSF जोखिम प्रबंधन अनुशासन 1.1 देखें - Microsoft से सॉफ़्टवेयर जोखिम वर्गीकरण का हल्का संस्करण

जोखिमों की कल्पना की जानी चाहिए ताकि पूरी टीम (और ग्राहक) उन्हें जानता हो और उन्हें प्रबंधित करने में पूरी तरह से भाग ले। सबसे खराब विकल्प जोखिम (सबसे एकांत कोने में) के साथ एक एक्सेल फाइल बनाना है और कहना है, "मेरे पास यह जोखिम है 37 नंबर के तहत रजिस्ट्री में, एक फेकैप के साथ"। सबसे "सहायक" विकल्प एक जोखिम बोर्ड बनाना और उनके जीवन चक्र को ट्रैक करना है।

लेकिन इस कार्य में विशेष रूप से ग्राहक को शामिल करते हुए जोखिमों को अधिक नहीं करना महत्वपूर्ण है, क्योंकि यह और टीम यह सोच सकती है कि परियोजना में कुछ संभावित समस्याएं हैं। यह स्थिति उन टीमों में बहुत स्पष्ट रूप से प्रकट होती है जिन्होंने पहले एक विस्तृत जोखिम विश्लेषण नहीं किया था, लेकिन बस आंखों पर पट्टी बांधकर कदम रखा था।

जोखिम विश्लेषण और प्राथमिकता के चरण पर अधिक विस्तार से ध्यान दें। हम इस प्रक्रिया को यथासंभव सरल बनाने के लिए सहमत हुए, इसलिए मैं गुणात्मक और मात्रात्मक जोखिम मूल्यांकन के बीच एक मध्य आधार खोजने का प्रस्ताव करता हूं। मात्रात्मक अनुमान और गणितीय मॉडलिंग बल्कि मनमानी चीजें हैं और निर्माण मॉडल के गुणों को अच्छी तरह से समझना आवश्यक है।

जोखिम की संभावना और खतरों (कितना नुकसान होगा) का आकलन करने के लिए हम केवल तीन ग्रेडेशन लेते हैं, और हम मौद्रिक अनुमान का उपयोग नहीं करेंगे:



बेशक, "लाल" जोखिमों पर अधिकतम ध्यान दिया जाना चाहिए, न केवल वे सबसे अधिक संभावना है, बल्कि उनसे होने वाले नुकसान अधिकतम होने का वादा करते हैं।

जोखिमों की परिचालन निगरानी और परिणामों के सुधार से संबंधित गतिविधियां दैनिक स्टैंड-अप पर ले जाने के लिए बहुत सुविधाजनक हैं: अब टीम आभासी समस्याओं के साथ नहीं, बल्कि विशिष्ट जोखिमों के साथ काम करेगी।

सबक के लिए सीखा है, पूर्वव्यापी इसके लिए एकदम सही है। मैं बस ध्यान देता हूं कि इन पाठों और सर्वोत्तम प्रथाओं को भी टीमों के बीच वितरित करने की आवश्यकता है, उदाहरण के लिए, स्करम के स्क्रेम पर।

बोरिस वोल्फसन द्वारा पोस्ट किया गया - सॉफ्टलाइन डेवलपमेंट के प्रमुख