🤰🏼 🚠 🍌 85 पतन और चुस्त विकास को लागू करने की बाधा 📧 🈺 📸

शब्द "स्क्रैम-बैट" ("स्क्रम, लेकिन .." से) का उपयोग पहली बार केन शुबाइबर द्वारा स्क्रैम नियमों की गलत व्याख्या या जानबूझकर संशोधन का वर्णन करने के लिए किया गया था, ताकि इस प्रक्रिया के बारे में दर्दनाक सच्चाई से बच सकें जो इसे खोलने में मदद करता है।

एक विशिष्ट स्क्रैम-बॉट शब्द इस तरह दिखता है:
हमारे पास एक स्क्रैम है, लेकिन <कारण>, <वर्कअराउंड>

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

क्रमशः, चमगादड़ के चमगादड़ों के विशिष्ट उदाहरण इस प्रकार हैं:

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

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

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

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

यदि आप पहले से ही एक स्क्रैम फ्रेमवर्क पर काम कर रहे हैं, या इसे संशोधित कर रहे हैं, तो आपको यह सूची स्व-निदान के लिए उपयोगी लग सकती है। अपने आप से सवाल पूछने की कोशिश करें: "हम्म, यह वास्तव में हमारे साथ ऐसा क्यों है?" और "हम स्थिति को बदलने के लिए और क्या कर सकते हैं?" प्रत्येक आइटम के लिए जो आपकी प्रक्रिया से संबंधित है।

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

MISCTIONS और OBSTACLES को AGILE / SCRUM PROJECTS में आने वाली परीक्षाओं में भाग लेना है।

प्रक्रिया

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

उत्पाद

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

प्रौद्योगिकी

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

उत्पाद OWNER

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

SCRUM मास्टर

कोई समर्पित स्क्रम मास्टर नहीं है या यह हर स्प्रिंट को बदलता है
स्क्रेम-मास्टर टीम से अलग स्थान पर है
फुर्तीली विकास (सिद्धांतों, मूल्यों, प्रथाओं) के क्षेत्र में स्क्रेम-मास्टर के पास पर्याप्त ज्ञान नहीं है
स्क्रेम-मास्टर के पास लोगों के साथ काम करने के लिए पर्याप्त सामाजिक कौशल (सॉफ्ट स्किल) नहीं है
एग्री वैल्यू के विपरीत टीम के फैसलों का विरोध करने की हिम्मत नहीं है
स्क्रैम-मास्टर एक तकनीकी नेता है और टीम के लिए अपने फैसले तय करता है
स्क्रेम-मास्टर "संयोजन में" उत्पाद के मालिक के रूप में कार्य करता है
एक स्क्रैम मास्टर 3-4 से अधिक टीमों पर काम करता है

टीम

कोई सामान्य लक्ष्य नहीं है (उत्पाद, रिलीज़, स्प्रिंट)
ऐसा कोई एहसास नहीं है कि हर कोई "एक ही नाव में नौकायन" कर रहा है
टीम के सदस्यों में एक गहरी विशेषज्ञता और अपने सहयोगियों के काम की एक खराब समझ है
विकास टीम को घटकों / परतों के लिए विशेष उप-टीमों में विभाजित किया गया है
स्प्रिंट के दौरान टीम की संरचना बदल जाती है
टीम के सदस्य समानांतर में अन्य परियोजनाओं पर काम करते हैं
टीम के सदस्यों को व्यक्तिगत रूप से प्रोत्साहित / दंडित किया जाता है

दैनिक कार्य

दैनिक रैलियां अनिश्चित और / या देर से होती हैं
दैनिक रैली नौकरियों पर बैठी होती है
स्क्रीम मास्टर या प्रोडक्ट ओनर को डेली डेवलपमेंट टीम रिपोर्ट करती है
डेली के दौरान तकनीकी और व्यावसायिक समाधान पर चर्चा की जाती है, इस बैठक में 15 मिनट से अधिक की देरी होती है
एक वितरित टीम में, व्यक्तिगत दैनिक स्थान आयोजित किए जाते हैं
बैठक के दौरान टीम विचलित होती है (योजना, दैनिक, रेट्रो, डेमो)
बैठकों में गैजेट्स से टीम के सदस्य विचलित हुए
टीम उत्पाद स्वामी की प्राथमिकताओं को ध्यान में नहीं रखते हुए, यादृच्छिक क्रम में बैकलॉग पर काम करती है

योजना

योजना तैयार करने के लिए बैकलॉग के साथ कोई प्रारंभिक कार्य नहीं है (सौंदर्य, शोधन, आदि)
योजना के दौरान टिप्पणी करने वाली टीम का ध्यान स्प्रिंट बैकलॉग पर है, न कि उसके लक्ष्य पर।
टीम सहमत है कि स्प्रिंट के दौरान कौन से कार्य होंगे
पिछले स्प्रिंट का अधूरा काम स्वचालित रूप से अगले पर जाता है

प्रदर्शन

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

पूर्वव्यापी

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

प्रबंधन

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

कार्य अंतरिक्ष

वितरित टीम में संचार को व्यवस्थित करने के लिए कोई सुविधाजनक साधन नहीं हैं
टीम की बैठकों के आयोजन के लिए असुविधाजनक स्थान
टेबल पर विभाजन के साथ खुले स्थान प्रारूप में कार्यालय
जोड़ी के काम के लिए असुविधाजनक कमरा

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

यदि आप सूची में से कुछ वस्तुओं को चुनौती देना चाहते हैं, तो मुझे डर है कि मेरे पास बहस करने के लिए कुछ नहीं होगा: कोई भी आपके संदर्भ को आपके बारे में बेहतर नहीं जानता है। ये बिंदु दिखाई दिए क्योंकि वे उन टीमों में हुए जिन्हें हमें SCRUMguides या हमारे सहयोगियों के साथ काम करना था।

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

85 पतन और चुस्त विकास को लागू करने की बाधा