SAFe में Scrum की तुलना में Agile टीम के काम की विशिष्टताएँ व्यवहार में

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

पहले मैं संक्षेप में वे सबसे मुख्य बातें सूचीबद्ध करता हूँ जो मेरी राय में SAFe में काम को SCRUM से अलग करती हैं।

• Scrum में Increment और SAFe में Program Increment
• ART - Agile Release Train
• परस्पर क्रिया करने वाली टीमों की संख्या
• PIPE
• SOS
• PO - व्यवसाय का स्वामी नहीं
• RTE
• प्रशिक्षण के लिए पाँचवाँ स्प्रिंट
• System Demo

Scrum में Increment और SAFe में Program Increment। वास्तव में अलग-अलग शब्द हैं, लेकिन इनमें उलझना आसान है क्योंकि हमारे यहाँ कोई भी Program Increment शब्द का उपयोग नहीं करता, सभी बस Increment कहते हैं - और यह पहले से ही एक अलग शब्द है जिसका उपयोग SCRUM में होता है। लेकिन मेरी राय में अर्थ की दृष्टि से वे काफी समान हैं। SCRUM में Increment - यह मूल रूप से वर्तमान उत्पाद + स्प्रिंट के लिए नियोजित कहानियाँ पूर्ण अवस्था में (टीम के DOD पास कर चुकी)। Program Increment - यह वह समय अंतराल है जिसके दौरान ट्रेन (Agile Release Train) उत्पादन में वृद्धिशील मूल्य पहुँचाती है। अवधि के अनुसार हमारे यहाँ यह विकास के लिए 2 सप्ताह के 4 स्प्रिंट और प्रशिक्षण के लिए एक स्प्रिंट है।

Agile Release Train - यह टीमों की टीम है जो मूल्य सृजन के एक ही प्रवाह पर काम करती हैं। हम इसे बस ट्रेन कहते हैं, लेकिन फ्रेमवर्क के अनुसार इसे "Solution" कहना सही है। हमारे मामले में, यह नियम पूरी तरह पालन नहीं होता और टीमें अक्सर तकनीकी दृष्टि से अलग-अलग उत्पादों पर काम करती हैं, क्योंकि अधिकांश व्यावसायिक फीचर व्यापक रूप से लागू होते हैं और कई उत्पादों को प्रभावित करते हैं। यह तकनीकी पक्ष है। लेकिन, मुझे विश्वास है कि कोई-कोई सभी IT-सिस्टम को कंपनी का एक उत्पाद मानता है और, संभवतः, यह और भी सही है।

परस्पर क्रिया करने वाली टीमों की संख्या हमारे SAFe में काफी अधिक है, कुल मिलाकर एक ट्रेन में 125 लोगों तक की सिफारिश की जाती है। हमारे यहाँ 3 ट्रेनें हैं और हर एक में यह नियम पालन नहीं होता, कुछ ट्रेनों में 125 से अधिक लोग हैं। SCRUM यह नहीं बताता कि अन्य टीमों के साथ कैसे परस्पर क्रिया करनी है, जहाँ तक मुझे पता है, SAFe के विपरीत, जहाँ इस बारे में बहुत स्पष्ट सिफारिशें हैं। मेरी राय में इसके लिए सबसे स्पष्ट आर्टिफैक्ट है Program Board।

इसमें ट्रेन की टीमों के बीच के संबंध दिखाए जाते हैं और इस पर चर्चा करते हुए हमारे यहाँ साप्ताहिक Scrum Of Scrums (SOS) गतिविधियाँ होती हैं।

लगभग हर 2.5 महीने में (हर 5 स्प्रिंट में) एक घटना होती है PIPE - Programm Increment Planning Event. यह तब होता है जब सभी वितरित टीमें 2 दिनों के लिए एक ही हॉल में इकट्ठा होती हैं और अगले 2.5 महीनों के लिए अपने काम की योजना बनाती हैं। इस गतिविधि के दौरान Program board जैसे आर्टिफैक्ट बनते हैं, उदाहरण के लिए, जिस पर प्रत्येक ट्रेन के लिए टीमों के आपसी सभी निर्भरताएँ दिखाई जाती हैं, ऊपर मैंने पहले ही दिखाया है कि यह कैसा दिखता है। इस गतिविधि में प्रत्येक टीम के स्क्रम मास्टर का कार्य अधिकतम निर्भरताओं की पहचान की सुविधा देना है, फिर जहाँ तक संभव हो, उन्हें हटाना (उदाहरण के लिए, मौखिक रूप से क्षमताओं को एक टीम से दूसरी टीम को हस्तांतरित करके या एक टीम से निर्भरता को दूसरी टीम में ले जाकर, ताकि टीम किसी पर निर्भर हुए बिना अपना फीचर स्वायत्त रूप से लागू कर सके)। व्यवहार में हमारे यहाँ ऐसा ही होता है। पहले फीचर को User Story में विघटित किया जाता है, User Story को 4 स्प्रिंट में बाँटा जाता है। फीचर को Program Board पर रखा जाता है और अन्य टीमों से जो निर्भरताएँ हैं वे दर्शाई जाती हैं। गतिविधि के दौरान इस पर चर्चा होती है, सुधार किया जाता है।

SOS - Scrum Of Scrum. यह गतिविधि प्रत्येक ट्रेन के लिए अलग से सप्ताह में एक बार होती है। ट्रेन की सभी टीमों के स्क्रम मास्टर ऑनलाइन इकट्ठा होते हैं, ट्रेन का Program Board प्रसारित किया जाता है और विशिष्ट ट्रेन की टीमों की सभी निर्भरताओं और फीचर की स्थितियों पर चर्चा की जाती है। मूल रूप से यह गतिविधि ट्रेन के भीतर टीमों के केंद्रीकृत समन्वय के लिए आवश्यक है। कुछ-कुछ स्टैंडअप जैसा, लेकिन सप्ताह में एक बार और टीम के लिए नहीं, बल्कि स्क्रम मास्टर के लिए।

PO (उत्पाद स्वामी) - व्यवसाय का स्वामी नहीं है। एक Product Manager होता है - वह संबंधित व्यवसाय दिशाओं के Bussiness Owner'ों के साथ काम करता है और मूल रूप से उत्पाद स्वामियों को फीचर बाँटता है। उत्पाद स्वामी सीधे टीम में काम करता है - फीचर को User Stories में तोड़ता है (हमारे मामले में टीम के साथ मिलकर) और हमेशा नहीं तोड़ता, लेकिन हम इस दिशा में लगातार प्रगति कर रहे हैं।

RTE (Release Train Engineer - ट्रेन ड्राइवर। स्क्रम मास्टर ऑफ स्क्रम मास्टर्स। अपनी ट्रेन के SOS कार्यक्रम आयोजित करता है। फीचर स्तर पर Product Manager के साथ बातचीत करता है। PIPE को सुविधाजनक बनाता है।

सीखने के लिए पाँचवाँ स्प्रिंट - हाँ, Scrum के विपरीत, यहाँ इंक्रीमेंट के अंत में टीम को सीखने के लिए पूरा एक स्प्रिंट आवंटित किया जाता है। हम, एक नियम के रूप में, व्यवहार में इसका उपयोग सबसे पहले आंतरिक प्रशिक्षणों में भाग लेने के लिए करते हैं, जिनमें SAFe से संबंधित भी शामिल हैं, लेकिन केवल वे ही नहीं। निजी पाठ्यक्रमों और मीटअप्स को जहाँ तक संभव हो इस समय के लिए निर्धारित करने का प्रयास करते हैं। साथ ही, हमारे पास ऐसे डेवलपर्स हैं जो 5वें स्प्रिंट के दौरान अपना स्टैक बढ़ाते हैं, ताकि टीम में किसी की भी क्षमता को कवर करने का अवसर हो (आवश्यकता पड़ने पर बैकअप के रूप में)।

System Demo। PIPE के परिणामस्वरूप, प्रत्येक टीम के पास इंक्रीमेंट के लिए लक्ष्यों की एक सूची होती है और इनमें से प्रत्येक लक्ष्य को ट्रेन के Buisseness Owner द्वारा 10-बिंदु पैमाने पर मूल्यांकित किया जाता है। इसे Business Value कहा जाता है। ये लक्ष्य मुख्य और विस्तारित में विभाजित होते हैं। मुख्य लक्ष्य वे होते हैं जिनमें टीम को प्राप्त करने में कोई जोखिम नहीं दिखता। विस्तारित वे लक्ष्य होते हैं जिनमें प्राप्ति के जोखिम होते हैं। सभी लक्ष्य अनिवार्य हैं और कार्य की मात्रा सभी लक्ष्यों के लिए नियोजित की जाती है। System Demo पर Business Owner इंक्रीमेंट के लिए कार्य के परिणाम स्वीकार करता है। मान लीजिए, एक टीम के पास 10, 6, 8 मूल्यांकन वाले 3 मुख्य लक्ष्य और 10, 3 मूल्यांकन वाले 2 विस्तारित लक्ष्य थे। कल्पना करें कि Business Owner ने क्रमशः निम्नलिखित मूल्यांकन दिए: 8, 6, 4, 2, 0। अब लक्ष्यों की प्राप्ति का प्रतिशत गणना किया जा सकता है: 100% के लिए मुख्य लक्ष्यों के लिए प्रारंभिक अंकों का योग लिया जाता है, हमारे मामले में यह 10+6+8=24 है। प्राप्त अंक विस्तारित लक्ष्यों को ध्यान में रखते हुए गिने जाते हैं (अर्थात टीम ने 24 में से 20 प्राप्त किए), अर्थात परिणामस्वरूप टीम के लक्ष्यों की प्राप्ति का प्रतिशत (20*100)/24 = 83.3% होगा। सामान्य परिणाम 80% से 100% तक की प्राप्ति माना जाता है।

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

facebook से सहकर्मियों की टिप्पणियाँ

«झेन्या, नमस्ते! अच्छा है कि तुम लिख रहे हो, शाबाश! ट्रेनों के बारे में थोड़ा सुधार करूँगा - वे उत्पाद के इर्द-गिर्द नहीं, बल्कि मूल्य सृजन प्रवाह के इर्द-गिर्द इकट्ठा होती हैं। और खुदरा में हमारे पास SAFe की दृष्टि से ट्रेन नहीं, बल्कि Solution है। बस संचार की सुविधा और समझ को सरल बनाने के लिए, हम इसे ट्रेन कहना जारी रखते हैं)»

– कोन्स्तान्तिन वोरोनिन (इंगोस्स्त्राख के प्रोजेक्ट ऑफिस के प्रतिनिधि)

«और हो सकता है कि कोई ध्यान दे कि SAFe की दृष्टि से लक्ष्यों का मूल्यांकन I&A पर होता है; (जहाँ SD एक भाग के रूप में शामिल है, लेकिन सीधे मूल्यांकन से जुड़ा नहीं है) और SD को हर स्प्रिंट में होना चाहिए (टीमों के डेमो के बाद)। लेकिन हम अभी इससे दूर हैं, इसलिए सचेत रूप से सब कुछ वैसा ही कहते हैं जैसा तुम्हारे लेख में लिखा है)»

– कोन्स्तान्तिन वोरोनिन (इंगोस्स्त्राख के प्रोजेक्ट ऑफिस के प्रतिनिधि)

«झेन्या, कृपया जारी रखो, बहुत उपयोगी है!»

– अलेक्सेई इओनोव (SAFe में प्रमाणित प्रशिक्षक)