हमने SCRUM कैसे किया

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

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

यदि आप पूरी तरह से अलग तरीके से जा सकते हैं तो ऐसा जोखिम क्यों लें?

क्यों SCRUM

प्रोजेक्ट से परिचित होने पर, एक समझ है "हम जानते हैं कि हम यह नहीं जानते हैं" और यहां तक ​​कि "हम यह नहीं जानते हैं कि हम जो नहीं जानते हैं उसकी सीमाएं" SCRUM मदद



एससीआरयूएम की बारीकियां डरा सकती हैं, अगर आपने कभी इस ढांचे के साथ काम नहीं किया है, तो इस तथ्य से कि काम की परियोजना शुरू करने के लिए आपको जिस रास्ते पर जाना है, उसकी लंबाई और 100% संतुष्टि अभी तक ज्ञात नहीं है।

ग्राहक के लिए यह मुश्किल है - वह विश्वसनीय रिलीज की तारीखों के साथ परियोजना के विकास के लिए एक रणनीतिक योजना तैयार नहीं कर सकता है। अज्ञात डरावना है, खासकर जब आपको इस तरह से भुगतान करने की आवश्यकता होती है।

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

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

SCRUM छोटे चरणों की अवधारणा पर निर्भर करता है: नियमित रूप से, जितनी बार संभव हो और पहले से चल रहे सॉफ़्टवेयर के संस्करण जारी करना। प्रत्येक पुनरावृत्ति विकास का एक सूक्ष्म चरण है, जिसे तुरंत अभ्यास द्वारा सत्यापित किया जाता है।

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



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

हमारे साथ भी ऐसा ही था, आइए देखते हैं?

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

SCRUM एक ऐसा ढांचा है जो कार्य प्रक्रिया के दौरान उन कार्यों को हल करने में मदद करता है, जो ग्राहकों को कुशलतापूर्वक और रचनात्मक रूप से उच्चतम मूल्य के साथ उत्पादों को वितरित करने के लिए काम करते हैं।

एससीआरयूएम का लाभ और, कुछ के लिए, नुकसान यह है कि यह एक बहुत ही हल्का ढांचा है। इसमें सभी सवालों के जवाब और टीम के सदस्यों के लिए विस्तृत निर्देश शामिल नहीं हैं। स्क्रम - "जानबूझकर अपूर्ण", और इस सार्वभौमिक के कारण।

SCRUM को प्रत्येक विशिष्ट परियोजना के लिए अनुकूलित किया जाना चाहिए

ग्राहक और ठेकेदार SCRUM पर कैसे काम करना शुरू करते हैं?

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









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

हेलीकॉप्टर दृश्य - एक विस्तृत विवरण के बजाय एक सामान्य विवरण या एक स्थिति की राय


वैश्विक उत्पाद रोडमैप

इस चरण के बाद हमारे निष्कर्ष क्या हैं?

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

तीसरा पैराग्राफ अनिवार्य है, इसके बिना कुछ भी काम नहीं करेगा। चूंकि दोनों पक्षों में निराशा के अंतिम नेतृत्व में पूरी तत्परता के बाद लॉन्च करने की उम्मीदें हैं:

• ग्राहक की ओर से: "यह वही है जो हमने अनुरोध किया था, लेकिन यह वह नहीं है जिसकी हमें आवश्यकता है।"
• कलाकार की ओर से: “हमने स्पष्ट रूप से वही किया जो तुमने पूछा था। और अब आपकी आवश्यकताएं हमारे लिए पूरी तरह से अलग हैं। हम सब कुछ फिर से करने के लिए सहमत हैं, लेकिन आपके खर्च पर। सामान्य तौर पर, बहुत सारे बदलाव होते हैं जिन्हें पूरा करने में एक और छह महीने लगेंगे। ”

उत्पाद के मालिक - उत्पाद का मालिक विकास टीम द्वारा किए गए कार्य के परिणामस्वरूप उत्पाद के अधिकतम मूल्य को प्राप्त करने के लिए जिम्मेदार है। उत्पाद विकास के लिए एकमात्र व्यक्ति जिम्मेदार है

एक छोटी सूची में हमारे सभी व्यवस्था।

चरण # 1: व्यापार विश्लेषण और कार्यप्रणाली अनुकूलन

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

समस्याग्रस्त साक्षात्कार और प्राप्त जानकारी के प्रसंस्करण के एक दौर के बाद, हमें उपयोग के उदाहरणों के रूप में विषय क्षेत्र का विवरण प्राप्त हुआ।



हालाँकि SCRUM को विकास विनिर्देश की आवश्यकता नहीं है, फिर भी हमारे पास तैयार किए गए विषय क्षेत्र का विवरण एक बड़ा प्लस था। इस दस्तावेज़ ने उत्पाद बैकलॉग का आधार बनाया - SCRUM लॉन्च का आधार। उत्पाद बैकलॉग - आवश्यकताओं, कहानियों, कार्यात्मकताओं की एक सूची, जो महत्व के द्वारा आदेशित हैं। ऐसी सूची के साथ, यह सब शुरू होता है। इसके अलावा, सभी आवश्यकताओं को उस भाषा में वर्णित किया जाता है जो ग्राहक के लिए समझ में आता है। इस सूची के तत्व उपयोगकर्ता कहानी , "उपयोगकर्ता कहानियां" हैं।

उपयोगकर्ता कहानी सिस्टम का उपयोग करने के लिए सबसे सरल उपयोगकर्ता परिदृश्यों का विवरण है, जिसका सार निम्नानुसार तैयार किया जा सकता है: "कौन, क्या, किस लिए, क्या विशेषताएं और सीमाएं हैं।"









203 कहानियों का हमारा उत्पाद बैकलॉग, आसानी से खंड द्वारा समूहीकृत


उपयोगकर्ता कहानी उदाहरण

इस चरण के बाद हमारे निष्कर्ष क्या हैं?

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

स्प्रिंट - वह समय अवधि जिसके दौरान "रेडी" बनाया जाता है, अर्थात्, उपयोग और रिलीज के लिए उपयुक्त उत्पाद

चरण # 2: स्प्रिंट योजना। हमने स्प्रिंट योजना को कैसे अनुकूलित किया

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



वह कैसा था? हमारे लिए, 2 चीजें प्राप्त करना आवश्यक था: स्प्रिंट का घोषित लक्ष्य और अनुमोदित स्प्रिंट बैकलॉग।

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

स्प्रिंट योजना एक बहुत महत्वपूर्ण SCRUM गतिविधि है। सही मूल्यांकन के लिए जिम्मेदारी के बारे में सभी जानते हैं, क्योंकि:

• यह व्यवसाय को यह समझने की अनुमति देता है कि स्प्रिंट के अंत में वह किस कार्यक्षमता की उम्मीद कर सकता है। ग्राहक के साथ "एक ही पृष्ठ पर" एक पूर्वानुमानित टीम हो और हो
• महसूस की गई एक आधी कहानी का मूल्य शून्य है, इसलिए एक स्प्रिंट के ढांचे के भीतर नियोजित सभी कहानियों को तय करने की आवश्यकता है।
• स्प्रिंट के दौरान स्कोर में किसी भी परिवर्तन को अनदेखा किया जाता है;

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


स्प्रिंट बैकलॉग उदाहरण

पहले स्प्रिंट के बाद ई-पत्रिका

पहले स्प्रिंट के लिए सरलीकरण और धारणाएं । सिस्टम में - 2 उपयोगकर्ता: शिक्षक और माता-पिता; एक वर्ग - 5 "ए"; वर्ग की वास्तविक संरचना, SQL प्रश्नों के माध्यम से सीधे प्रवेश किया 5 "ए" के लिए वर्तमान अनुसूची, तालिका में सीधे प्रवेश के माध्यम से भी बनाई गई।

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

वास्तविक मूल्य क्या देता है: वास्तविक वर्ग का डिजीटल प्रदर्शन, वर्तमान आकलन, मासिक, सेमेस्टर, त्रैमासिक रिपोर्ट की स्वचालित तैयारी की संभावना।

उपयोगकर्ता कहानी # 2 : मेल में प्रदर्शन के बारे में माता-पिता को एक साप्ताहिक रिपोर्ट।

क्या मूल्य जोड़ता है: वर्तमान प्रदर्शन के बारे में माता-पिता को सूचित करना; शिक्षक होमवर्क पर टिप्पणी करता है; न्यूनतम लेकिन वास्तविक विश्लेषण।

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

Svyatoslav, उत्पाद के मालिक

संदर्भ के लिए : अंतिम (आदर्श) संस्करण को ठीक करने के लिए, हमें कई स्प्रिंट के लिए इलेक्ट्रॉनिक पत्रिका में वापस लौटना पड़ा।


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


इलेक्ट्रॉनिक पत्रिका के इस संस्करण को 12 स्प्रिंट के बाद प्राप्त किया गया था और माता-पिता को दिखाया जा सकता है।

पुनरावृत्त SCRUM दृष्टिकोण का एक और ज्वलंत उदाहरण शेड्यूल कंस्ट्रक्टर है।

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

इसे "विज़ुअल एडिटर" को परिष्कृत करने के लिए तीन स्प्रिंट्स लगे। विकास फोकस को कई बार स्विच किया गया है, लेकिन स्कूल वर्ष की शुरुआत तक, ग्राहक को एक पूरी तरह कार्यात्मक शेड्यूल डिज़ाइनर प्राप्त हुआ, जिसकी मदद से उसने पहले (A, B, C, D) से केवल एक घंटे में आठवें ग्रेडर का शेड्यूल पेश किया।

मार्ग का अनुसरण करें "एक वास्तविक व्यवस्थापक के लिए क्रूर संपादक" - "दृश्य संपादक" - "शेड्यूल डिजाइनर"

और आपने पहले कैसे शेड्यूल बनाया?

शेड्यूल को व्हाट्स ए 1 पेपर की चिपके शीशों पर मैन्युअल रूप से तैयार किया गया था: रंगीन मार्करों के साथ चित्रित, चित्रित। मुख्य शिक्षक को ऐसा करने में हफ्तों और महीनों का समय लगा।


संपादक का पहला संस्करण: "एडमिन के लिए क्रूर संपादक" - जिसने 2018 के लिए शेड्यूल बनाया


दूसरा, बेहतर संस्करण, जिसकी मदद से अनुसूची 2018/2019 बनाई गई थी


अनुसूची डिजाइनर - अंतिम संस्करण

इस चरण के बाद हमारे निष्कर्ष क्या हैं?

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

टीम स्टोरी का वास्तविक रूप से मूल्यांकन करने के लिए एक टीम कैसे बनाई जाए

शर्तों को पूरा करने पर टीम हमेशा उपयोगकर्ता कहानी का पर्याप्त रूप से मूल्यांकन करेगी: वास्तविक उपयोगकर्ता के व्यवहार का विस्तार से वर्णन किया गया है, उपयोग और मान्यताओं की सीमाओं को इंगित किया गया है, स्वीकृति मानदंड सूचीबद्ध हैं। यही है, टीम समझती है कि "क्या" किया जाना चाहिए और मोटे तौर पर "कैसे" का सुझाव देता है।

क्यों "स्वीकृति मानदंड" और "उपयोग की सीमा" तैयार करना महत्वपूर्ण है - यह उत्पाद के मालिक और टीम दोनों की कहानियों के लिए काम के दायरे की समान समझ देता है।

रेटिंग स्केल, या SCRUM- पोकर

SCRUM में, कहानी मूल्यांकन घंटे या दिनों में नहीं, बल्कि कहानी बिंदुओं में होता है। यह जटिलता, जोखिम और प्रयास का मिश्रण है जो एक टीम को एक कहानी को पूरा करने के लिए खर्च करना चाहिए। प्रत्येक टीम के लिए, 1 कहानी बिंदु एक व्यक्तिगत, अनुभवजन्य मूल्य है, लेकिन प्रत्येक टीम के सदस्य इसे महसूस करते हैं।

ध्यान दें कि कार्ड पर मानों का क्रम गैर-रैखिक है। उदाहरण के लिए, 13 और 21 के बीच कुछ भी नहीं है। ऐसा क्यों?



सबसे पहले, बड़ी रेटिंग के लिए सटीकता की झूठी भावना की उपस्थिति से बचने के लिए यह आवश्यक है। यदि कहानी का अनुमान लगभग 17 कहानी बिंदुओं पर लगाया जाता है, तो यह चर्चा करने का कोई मतलब नहीं है कि यह 15, या 18, या 21 होना चाहिए। हम सभी को जानना आवश्यक है, यह इतिहास का मूल्यांकन करना कठिन है। इसलिए, हम उसे 21 की रेटिंग देते हैं।

दूसरे, लोग अपनी क्षमताओं को बढ़ा-चढ़ाकर पेश करते हैं, और समय और संसाधनों के आकलन में पैमाना बहुत गलत नहीं होने देता। उदाहरण के लिए, टीम ने सहमति व्यक्त की कि 6 कहानी बिंदु एक कार्य के लिए पर्याप्त हैं। लेकिन अगर आप सुनिश्चित नहीं हैं कि 5 पर्याप्त है, तो यह चुनना बेहतर है 8. यह आपको वास्तविक शब्द सेट करने की अनुमति देता है जिसमें टीम बिल्कुल फिट होगी। साथ ही, यह प्रतिभागियों के बीच संवाद शुरू करने, कहानी के कार्यान्वयन के अपने दृष्टिकोण को साझा करने, जोखिमों को आवाज देने और एक आम सहमति पर आने में मदद करता है।

बहुत महत्वपूर्ण : प्रत्येक टीम के सदस्य को एक मूल्यांकन देना चाहिए। क्यों?

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

हम इसे कहानियों में से एक के लिए अनुमान में व्यापक भिन्नता के उदाहरण से दिखाते हैं। कहानी को बज़ कहा गया।

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

उज्ज्वल मामला: बज़

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

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


अंतिम कार्यान्वयन में बज़

उज्ज्वल मामला: बज़

, « ».



, story points . , , : - 50, 5 story points. , . , . , .

1. , , QA UX .
2. story points, «» . , , story points.
3. 2-3 , — 1 story point

story point — , , .

№3: . sprint execution SCRUM

SCRUM-meeting, stand-up, SCRUM — , . «» «». , , . SCRUM : « ».



, checklist, , , . , . , , , , , .

:

- , . .

.

, . : - , .

, : , , sprint backlog , , , , . , , , , . .

, Scrum Master

sprint running

1. , , , .
2. , SCRUM , .
3. .

SCRUM meeting

№4: . sprint demo

. — , , , . , -, .

,

. , . . , - . . , , , . — user story, .

1. : product owner, scrum master, , , .
2. , .
3. , . -.
4. , . .
5. . , ,

—

№5: retrospective

— sprint demo. , - . , .





— . . , , 5 story points, , 13story points , , — - . — .

: . Scrum Master sprint backlog, . , , — — . , . . , , :

• जब कोई डेवलपर फ्रंट-एंड बनाता है और हम इसे लागू करना शुरू करते हैं, तो यह आवश्यक है कि डिजाइनर 100% सुलभ हों।
• पीओ के साथ कार्यप्रणाली के घंटों के समावेश पर चर्चा करें।
• एर्गोनॉमिक्स में, सबसे अधिक दस्तावेज प्राप्त करना महत्वपूर्ण है।
• तकनीकी ऋण जमा नहीं होना चाहिए। पीओ के साथ तकनीकी कहानियों के लिए 10% संरेखित करें।
• एक विशेषज्ञ होना चाहिए जो तकनीकी समस्याओं को हल करेगा जैसे ही वे उत्पन्न होते हैं।
• प्रत्येक स्प्रिंट प्लानिंग से पहले स्प्रिंट ग्रूमिंग करना अनिवार्य है।

"सभी समस्याग्रस्त स्टिकर के बारे में टीम के मंथन के बाद, मैं एक" स्पॉट वोटिंग "आयोजित करूंगा: टीम के प्रत्येक सदस्य के तीन वोट (स्टिकर पर तीन मार्कर अंक) हैं। वह एक बार में एक समस्या पर अपने सभी वोट डाल सकता है, या वह अलग तरीके से वितरित कर सकता है। इस टीम के वोट के आधार पर, हम 2-3 सुधारों का चयन करते हैं जिन्हें हम अगले स्प्रिंट में ध्यान केंद्रित करते हैं। और अगले पूर्वव्यापी की शुरुआत में, हम जांच करेंगे कि क्या हुआ था। तो कहने के लिए, "होमवर्क की जाँच" :)

पावेल काम्यशोव , एजाइल कोच

हां, SCRUM को टीम के सभी सदस्यों के सक्रिय समावेश की आवश्यकता है। ग्रूमिंग, योजना, दैनिक एससीआरयूएम जैसी गतिविधियों के लिए, हमें भुगतान किए गए समय का लगभग 12% हिस्सा लिया - यह पारदर्शिता, पूर्वानुमान और जोखिम में कमी के लिए एक प्रकार का मूल्य है।

एक सप्ताह के काम से एक घंटे की योजना बनाई जा सकती है।

पावेल काम्यशोव , स्क्रैम यूक्रेन के चुस्त कोच

12% बहुत है, लेकिन यह इसके लायक है, क्योंकि क्लासिक "झरना" में पद्धति का उपयोग करने की कीमत परियोजना प्रबंधक के लिए एक अलग भूमिका है। औसतन, विकास लागत का लगभग 15% हमारे बाजार क्षेत्र में प्रबंधन पर खर्च किया जाता है।

हमने पूर्वव्यापी कार्यप्रणाली पर क्या निष्कर्ष निकाला है

1. हमारे लिए, स्प्रिंट प्लानिंग के बाद SCRUM में पूर्वव्यापी दूसरी सबसे महत्वपूर्ण घटना है।
2. प्रत्येक टीम सदस्य बोलता है ताकि सभी एक ही जानकारी क्षेत्र में हों।
3. प्रत्येक परिवर्तन की एक कीमत होती है। स्प्रिंट बैकलॉग में तकनीकी कहानियों और पद्धति के घंटों को शामिल करने के लिए आपको पीओ से सहमत होना चाहिए।
4. ग्राहक द्वारा पद्धति के घंटे का भुगतान किया जाता है।

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

चरण संख्या 6: हमने उत्पाद बैकलॉग शोधन, या संवारने को कैसे अनुकूलित किया

कई सहयोगियों जो आईटी संदेह की बारीकियों से परिचित हैं: स्प्रिंट प्लानिंग के दौरान एक टीम के लिए यह इतना स्पष्ट कैसे हो सकता है कि यह सभी उपयोगकर्ता कहानियों को एक आकलन देने के लिए तैयार है।



हां, वास्तव में, ऐसी तैयारी के बिना काम नहीं चलेगा। इस तरह से काम करने के लिए, एक विशेष SCRUM गतिविधि है: उत्पाद बैकलॉग शोधन। इसे बाहर ले जाने के लिए, आपको उत्पाद के मालिक से एक योजना क्षितिज देने के लिए कहना होगा: इस बात की रूपरेखा तैयार करें कि अगले स्प्रिंट के लिए कौन सी कहानियां उम्मीदवार हो सकती हैं। अगर उनके बीच ऐसी कहानियाँ हैं, जिनके लिए गहन अध्ययन या विशेष दक्षताओं की आवश्यकता होती है, जो टीम के पास नहीं है, तो एक बैठक को बुलाया जाता है - ग्रूमिंग / प्री-प्लानिंग।


संवारने का परिणाम

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


यह एक ग्रूमिंग प्लान की तरह लगता है

शोधन के लिए हमने क्या निष्कर्ष निकाले हैं

1. यह एक महत्वपूर्ण घटना है जो हमें यह स्पष्ट करने की अनुमति देती है कि हम क्या नहीं जानते हैं, हमारे पास क्या योग्यता है। इसलिए, एक बार विशिष्ट मुद्दों में एक तृतीय-पक्ष डेवलपर-सलाहकार को आकर्षित करने का निर्णय लिया गया था, जिसका समाधान उस समय हमारे पास नहीं था।
2. ये चर्चाएँ हमारे साथ बहुत प्रभावी थीं, हमने कई विकल्पों और विकल्पों पर विचार किया, जिससे हमें समस्या को ध्यान में रखने की अनुमति मिली, और स्प्रिंट योजना के लिए, सबसे जटिल कहानी पहले से ही "रखी गई" थी।
3. जटिल, प्रतीत होता है अघुलनशील समस्याएं स्पष्ट समाधान ढूंढती हैं। कभी-कभी किसी लाइब्रेरी को खरीदने के लिए केवल एक जटिल साइट को विकसित करना ही काफी होता है।

स्प्रिंट प्लानिंग के दौरान कार्यान्वयन की विभिन्न स्थितियों में कहानियों की जटिलता का आकलन करने के लिए तैयार होने के लिए शोधन, नींव है, क्योंकि हमें उनकी मात्रा और जटिलता को समझने की आवश्यकता है।

Faile

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

परिचित पैटर्न पर काम करें

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

हमें आदत से पता चला कि वे परिचित अनुक्रमिक झरने में व्यवस्थित थे।

परिणामस्वरूप: कार्यों को क्रमिक रूप से पूरा किया गया, डेवलपर्स ने विभिन्न चरणों में अनुक्रमिक स्विचिंग पर समय बिताया, जो पहले से शुरू किए गए कार्यों को पूरा करने की आवश्यकता के कारण देरी के साथ था।

निष्कर्ष: शायद हमारे लिए सबसे दर्दनाक कहानी, जिसने सबसे ज्यादा नुकसान पहुंचाया और तुरंत सामने नहीं आई। यह नियमित रूप से जांचना आवश्यक है कि क्या सभी टीम के सदस्यों ने नए मानकों के अनुसार काम करने के लिए स्विच किया है।

अनावश्यक कार्यक्षमता पर अतिरिक्त काम

दूसरे स्प्रिंट में, उत्पाद के मालिक ने मुख्य शिक्षकों में से एक की राय के आगे घुटने टेक दिए, जो मानते थे कि "क्यूरेटर की पत्रिका" एक अत्यंत महत्वपूर्ण कार्यक्षमता थी। हमने इस कहानी को स्प्रिंट में लिया, इस पर प्रयास किया।

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

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

उन्नत उपयोगकर्ताओं के बराबर

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

निष्कर्ष: नियमित ग्राहकों पर कहानी की पुष्टि करें।

सामान्य निष्कर्ष

निष्कर्ष संख्या 1

प्रो लचीलापन: SCRUM आपको एक प्रभावी टीम बनने की अनुमति देता है

प्रत्येक स्प्रिंट के परिणाम परिचयात्मक कार्यों, दक्षता, समन्वय, टीम की जिम्मेदारी और गुणवत्ता प्रतिक्रिया पर निर्भर करते हैं।

उत्पाद स्वामी द्वारा इनपुट दिया जाता है। वह उस संदर्भ के लिए भी जिम्मेदार है जिसमें कार्यक्षमता का उपयोग किया जाएगा, आवश्यकताओं के निर्माण की गुणवत्ता, विस्तार की पर्याप्त गहराई प्रदान करती है।

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

निष्कर्ष संख्या 2

संसाधनों के सबसे कुशल उपयोग के बारे में

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

SCRUM - जब दोनों पक्षों को जोखिम के खिलाफ बीमा किया जाता है

देखें कि ग्राहक और ठेकेदार के बीच जिम्मेदारी कैसे साझा की जाती है
बैरिकेड गायब हो जाता है, जिसके दोनों तरफ ठेकेदार और ग्राहक शास्त्रीय परियोजना प्रबंधन में हैं। सिद्धांत रूप में, ग्राहक और ठेकेदार के पद गायब हो जाते हैं, टीम बनी रहती है। और संभावित टकराव के लिए कोई शर्तें नहीं हैं।

ग्राहक

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

ग्राहक प्रत्येक स्प्रिंट के लिए एक निश्चित राशि का भुगतान करता है, और अपने व्यवसाय को एक कदम और अधिक कुशल बनाता है

अभिनेता

ठेकेदार एक नया उपकरण, प्रत्येक स्प्रिंट के दौरान ग्राहक के लिए एक नया मूल्य तैयार करने में रुचि रखता है, क्योंकि यह प्रतिक्रिया और जानकारी / अनुभव का एक नया दौर देगा। जिसका उपयोग आगे उत्पाद विकास के लिए किया जा सकता है।

प्रत्येक स्प्रिंट कलाकार की क्षमता के स्तर को बढ़ाता है, परियोजना के कार्यान्वयन में तेजी लाता है।

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

वैश्विक स्तर पर, यह मामला उच्च स्तर की अनिश्चितता और लॉन्च से पहले सीमित समय की शर्तों के तहत एक सही ढंग से चयनित परियोजना प्रबंधन तकनीक के बारे में है।

इस तरह के मांग वाले ग्राहक के साथ, उच्च गुणवत्ता मानकों के साथ, यह हमारे लिए कई बार बहुत मुश्किल था, लेकिन एक ही समय में बहुत दिलचस्प था। वे चुनौतियाँ जो हम पर हावी हो गईं, जो गलतियाँ की गई थीं, हालाँकि, समय रहते, होश में और सुधार कर लिए गए निष्कर्षों ने हमारी टीम में हमेशा के लिए संस्कृति को बदल दिया।

संभवतः लंबे समय तक हर किसी को उत्पाद के बारे में जानने के लिए दिलचस्पी थी, जो निकला।

ग्राहक को एक उत्कृष्ट उत्पाद प्राप्त हुआ: एक आधुनिक स्कूल के लिए उपकरणों का एक सेट जो भविष्य के स्कूल में जल्दी से इसे बदल सकता है