सॉफ्टवेयर विकास पद्धति

उन्होंने मुझे कंपनी में एक प्रेजेंटेशन देने और उस कार्यप्रणाली के बारे में बात करने के लिए कहा, जिसके द्वारा हम काम करते हैं, और हम अपना एप्लिकेशन विकसित कर रहे हैं। मैंने तुरंत कहा, "हमारे पास स्क्रम है," और एक प्रस्तुति बनाने के लिए बैठ गया। लेकिन मैं पहली स्लाइड में ही रुक गया, और यहाँ क्यों है।

एजाइल में कई पद्धतियां हैं- XP, Scrum, Lean, Kanban, ScrumBut (ScramNO)। विधियों का विश्लेषण करने के लिए बैठ जाने के बाद, मुझे एहसास हुआ कि मैं यह नहीं कह सकता कि मेरी टीम उनमें से एक पर काम करती है। सामान्य तौर पर, हमारे वर्कफ़्लो को निम्नानुसार दर्शाया जा सकता है:




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

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




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

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

सामान्य तौर पर, काम की प्रक्रिया में, मैंने अपने लिए दो सत्य सीखे:
1. ग्राहक इस बात की परवाह नहीं करता है कि आप किस कार्यप्रणाली पर काम कर रहे हैं; वास्तव में, वह अंतिम परिणाम में रुचि रखता है;
2. यदि आप ग्राहक को उसकी अपेक्षा से अधिक देते हैं, तो वह खुश हो जाता है।

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

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