स्प्रिंट समीक्षा: नीचे - नीचे

"हम लेट गए, हमने रोशनी जलाई, यूनिवर्स में हम ही हैं।" ऐसा लगता है कि स्प्लिन समूह के गीत की इस पंक्ति को डोडो पिज्जा में स्प्रिंट रिव्यू अभ्यास की शुरूआत के साउंडट्रैक के रूप में सुरक्षित रूप से पहचाना जा सकता है।

अस्वीकरण: एक लेख में, एंटोन एक व्यवहार्य स्प्रिंट समीक्षा के पहले संस्करण का वर्णन करता है। हमारे पास पहले से ही अधिक उन्नत है, लेकिन अगली श्रृंखला में इसके बारे में।

डोडो पिज्जा में स्प्रिंट समीक्षा अभ्यास शुरू करने का पहला प्रयास बुरी तरह विफल रहा।
हो सकता है कि आपको लगता है कि स्क्रैम पिज्जा चेन प्रथा आम तौर पर बेकार है। हालांकि, डोडो पिज्जा के मुख्य लाभों में से एक, अजीब तरह से पर्याप्त है, इसकी अपनी आईटी प्रणाली है, जो 12 देशों में नेटवर्क के 495 पिज़्ज़ेरिया में सभी प्रक्रियाओं का प्रबंधन करती है।

80+ डेवलपर्स और विश्लेषक आज इस प्रणाली पर काम कर रहे हैं (और दो सौ से अधिक समय के साथ आएंगे)। तेजी से बढ़ते स्टार्टअप के रूप में, हम अधिकतम दक्षता के लिए प्रयास करते हैं, इसलिए, हम कई "लचीले विकास" ढांचे का उपयोग करते हैं: स्क्रैम, लेएसएस, चरम प्रोग्रामिंग।

लेकिन यह क्या बकवास है, आप पूछते हैं, बिना स्प्रिंट समीक्षा के? और आप सही होंगे।

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

हालांकि, किसी कारण से यह दृष्टिकोण हमारे लिए काम नहीं कर पाया। उदाहरण के लिए, पहली स्प्रिंट समीक्षा में से एक में हमने कजाकिस्तान के डोडो पिज्जा फ्रेंचाइजी को अपनी नई साइट - dodopizza.kz दिखाया। प्रतिक्रिया प्रेरणादायक थी: भागीदारों ने कहा कि साइट बहुत खूबसूरत लग रही है, और प्रतियोगियों की पृष्ठभूमि के खिलाफ यह एक उत्कृष्ट कृति की तरह प्रतीत होगा।

जब हमने इसे रोल आउट किया, तो यह पता चला कि इसमें बहुत सारी चीजें गायब थीं। यही है, हमने स्प्रिंट समीक्षा पर समय बिताया है, लेकिन वास्तव में भागीदारों से उपयोगी प्रतिक्रिया नहीं मिली है।

सामान्य तौर पर, जल्द ही हमने चुपचाप ऐसी स्प्रिंट समीक्षाओं को रोक दिया।

कुछ महीनों के बाद, मैंने फिर से कोशिश करने का फैसला किया। उस समय तक, हमारे पास पहले से ही एलएसएस ढांचे में एक ही बैकलॉग पर काम करने वाली आठ टीमें थीं। हमने बड़े पैमाने पर स्क्रम के सभी नियमों का पालन करने की कोशिश की, और स्प्रिंट समीक्षा की कमी उल्लंघन में से एक थी।

मैंने इस तथ्य के लिए अग्रिम रूप से तैयार किया कि पहले तो सब कुछ खराब होगा, और आपको परीक्षण और त्रुटि पद्धति का उपयोग करके सही प्रारूप देखने की आवश्यकता होगी। प्रत्येक समीक्षा के बाद, मैंने प्रतिभागियों से घटना को 1 से 10 के पैमाने पर रखने के लिए कहा (नीचे - ओम्निशे)। पहले, रेटिंग बहुत कम थी, "नीचे" के करीब। हालाँकि, हमने कुछ समय नहीं दिया, प्रयोग किया और कहीं न कहीं कुछ महीनों में वे ओग्निस्ट में शिफ्ट होने लगे।

यही हमने बदल दिया

घर का काम करना

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

अधूरा न दिखाएं

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

खुली जगह के बजाय बातचीत

LeSS लेखक "बाज़ार" के रूप में स्प्रिंट समीक्षा की सलाह देते हैं। सभी टीमों को एक बड़े कमरे में अपना काम दिखाना होगा, और जो लोग रुचि रखते हैं, वे उन स्टेशनों पर जा सकते हैं। हमने कई बार कोशिश की, यह शोर और उधम मचाता था।

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

संक्रमण निषिद्ध हैं!

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

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

प्रिय मेहमान

हमने महसूस किया कि "मेहमान" की रचना का बहुत महत्व है। कुछ भी एक डेवलपर को स्प्रिंट रिव्यू सीईओ पर दिखाई देने के लिए प्रेरित नहीं करता है। खासतौर पर तब जब आपको उसे किसी तकनीकी चीज़ को दिखाने की ज़रूरत हो, जैसे क्यूब में एक सेवा या .Net कोर में ट्रांसफ़र। हमें यह समझाना होगा कि हम ऐसा क्यों कर रहे हैं। डोडो पिज्जा के सीईओ फेडर ओविचिनिकोव ने सभी को खुश करने और तीन मिनट में कंपनी के विकास के क्षितिज को रेखांकित करने का तरीका बताया। खैर, जब हम ग्राहक सुविधाओं को दिखाते हैं, उदाहरण के लिए, एक मोबाइल एप्लिकेशन में एक आधा-पिज्जा निर्माता, अब हम बाहरी मेहमानों को एक नियम, परिचितों और फेसबुक के दोस्तों के रूप में कहते हैं।

हटाए गए सदस्य

जब एक कमरे में सब कुछ होता है तो बैठक आयोजित करना आसान होता है। लेकिन हमारे पास Syktyvkar, Nizhny Novgorod, Kazan और Goryachy Klyuch में कई दूरस्थ कर्मचारी हैं। उनके लिए उपस्थित होना भी महत्वपूर्ण है।

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

प्रतिक्रिया अस्वीकरण

जब यह लगने लगा कि सब कुछ अच्छा है और प्रारूप में सुधार करने के लिए कहीं नहीं है, तो हमने खुद से सवाल पूछा: क्या हम कचरा नहीं कर रहे हैं? स्प्रिंट समीक्षा एक महंगी घटना है (यदि आप इसे निष्ठा से देखते हैं - प्रतिभागियों की संख्या, उनके वेतन और खर्च किए गए घंटों के संदर्भ में)। क्या हम इन दो घंटों का उपयोग यथासंभव उत्पादक रूप से कर रहे हैं? नतीजतन, हमने स्प्रिंट समीक्षा के दौरान प्रतिक्रिया एकत्र करने से पूरी तरह इनकार कर दिया।

इस तरह की घटना के प्रारूप में, इसे गहराई से और गुणात्मक रूप से नहीं किया जा सकता है (कजाकिस्तान के साथ एक मामला याद करें)। इसके अलावा, हम स्प्रिंट के दौरान अधिकांश महत्वपूर्ण और उच्च-गुणवत्ता की समीक्षा एकत्र करते हैं, आंतरिक ग्राहकों से उपयोगकर्ताओं के लिए रुचि रखने वाले सभी को आकर्षित करते हैं ... आपको आश्चर्य होगा, यहां तक ​​कि स्क्रम गाइड भी यह नहीं कहता है कि स्प्रिंट समीक्षा पर प्रतिक्रिया एकत्र की जानी चाहिए: "स्प्रिंट रिव्यू के दौरान। स्प्रिंट में क्या किया गया था, इस बारे में स्क्रैम टीम और हितधारक सहयोग करते हैं। " टीम और हितधारक, उपयोगकर्ता नहीं। सहभागिता करें, प्रतिक्रिया एकत्र न करें। एक बिल्कुल अलग अर्थ।

"किचन" खोलें

सभी हितधारक विकास प्रक्रिया में गहराई से डूबे हुए नहीं हैं। लेकिन हर कोई जानना चाहता है कि वहां क्या चल रहा है। यह इन उद्देश्यों के लिए है कि हमने स्प्रिंट समीक्षा को फिर से करने का फैसला किया।

हम अभी भी किए गए काम को दिखाते हैं, लेकिन इसके अलावा, टीम नई सुविधाओं के पीछे की कहानी बताती है। उद्देश्य क्या था? स्प्रिंट के दौरान क्या हुआ? किस बात ने हमें विचलित किया या हमें अपने लक्ष्य तक पहुँचने से रोका? लक्ष्य को बचाने के लिए हमने क्या उपाय किए हैं? यह मदद करता है: यह प्रबंधकों को स्पष्ट करता है, उदाहरण के लिए, "सितारों में चेक के साथ क्लाइंट के ईमेल को छिपाना" एक बहुत मुश्किल काम है ("एक प्रोग्रामर के काम के आधे घंटे," जैसा कि प्रबंधकों ने सोचा था)। इसके विपरीत, इस तरह की बातचीत से डेवलपर्स को "ग्राहकों" और उनकी समस्याओं के बारे में सोचने में मदद मिलती है, बजाय इसके कि वे जिस विशिष्ट समाधान पर काम कर रहे हैं।

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

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