टीम लगातार स्प्रिंट लक्ष्यों को पूरा करने में विफल रहती है

Question

हम एक उत्पाद के साथ एक छोटी सॉफ्टवेयर कंपनी हैं।

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

मैंने बहुत सारे पोस्ट / उत्तर पढ़े हैं, "कुछ किया है जब सॉफ्टवेयर की तर्ज पर कुछ कहा जाता है, जल्दी नहीं, बाद में नहीं ... यह टीम पर दबाव बनाने में मदद नहीं करता है, इस पर अधिक लोगों को डालने के लिए" ... "मुझे अपने प्रश्न पर डेवलपर्स में से एक समान प्रतिक्रिया मिली है कि हम स्प्रिंट की सफलता दर में सुधार कैसे कर सकते हैं। ओह, और हाँ हम रेट्रोस्पेक्टिव का उपयोग करते हैं ।

मेरा प्रश्न मूल रूप से है:

डेवलपर्स की गुणवत्ता में समस्या को देखना कब उचित है?

मैं यह सोचना शुरू कर रहा हूं कि यदि आपको अपने काम / सुविधाओं को चुनने के लिए मिलता है और फिर भी प्रत्येक स्प्रिंट विफल रहता है: - आप अपने स्वयं के कोड की जटिलता की देखरेख करने में सक्षम नहीं हैं; - या कोड इतना जटिल है कि कोई भी जटिलता की देखरेख नहीं कर सकता है।

क्या मैं कुछ भूल रहा हूँ?

Comments

आपकी टीम स्प्रिंट लक्ष्यों को पूरा क्यों नहीं कर रही है? क्या आप किसी भी उपयोगकर्ता की कहानियों को पूरा कर रहे हैं (या हालाँकि आप अपने द्वारा लागू की जा रही सुविधाओं को कैप्चर कर रहे हैं) क्या आप पिछले स्प्रिंट के वेग के आधार पर आगामी स्प्रिंट के लिए अपने वेग को समायोजित कर रहे हैं? क्या आपका उत्पाद स्वामी उत्पाद बैकलॉग को प्राथमिकता दे रहा है? क्या उत्पाद स्वामी सवालों के जवाब देने के लिए उपलब्ध है? स्प्रिंट रेट्रोस्पेक्टिव्स पर क्या हो रहा है?

— थॉमस ओवेन्स

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

— जिमीजैम

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

— मेसन व्हीलर

यदि "डेवलपर्स एक स्प्रिंट में नहीं जाते हैं तो चुनते नहीं हैं", आप घोटाले नहीं करते हैं।

— स्टीवन बर्नैप

शब्दावली बदल गई है। फुर्तीली टीमें अब स्प्रिंट के लिए प्रतिबद्ध नहीं हैं, वे इसका पूर्वानुमान लगाते हैं। और मौसम के पूर्वानुमान की तरह, आप अगले सप्ताह क्या उम्मीद करते हैं और वास्तव में क्या होता है बदल सकता है। scrum.org/About/All-Articles/articleType/ArticleView/articleId/…

— एंडी

Answer 1

आपको पहले पूछना चाहिए, 'कौन परवाह करता है'?

स्प्रिंट को पूरा करना अच्छा लगता है, और कुछ कंपनियों में स्क्रैम पेरेंट से कुकीज़ प्राप्त होते हैं। लेकिन अंतिम परीक्षण यह है कि क्या कंपनी अपने लक्ष्यों को पूरा कर रही है।

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

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

Comments

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

— जिम्मीजैम

यही कारण है कि scrum.org ने 2011 में अपनी प्रतिबद्धता को "प्रतिबद्धता" से "पूर्वानुमान" में बदल दिया।

— स्टीव जेसप

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

— जैच लिप्टन

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

— कार्सन63000

@SteveJessop, वाह, उन्होंने कहा कि बहुत अच्छी तरह से प्रचारित नहीं किया है। पिछले पाँच वर्षों से मैंने जिस "स्कैम मास्टर्स" में से कोई भी काम नहीं किया है, उसका उल्लेख किया है। हो सकता है कि उन्होंने जानबूझकर इसका उल्लेख नहीं किया हो।

— Kyralessa

Answer 2

क्या मैं कुछ भूल रहा हूँ?

हाँ!

आप 18 महीने गए - या कहीं-कहीं रेट्रोस्पेक्टिव के साथ 36 स्प्रिंट्स के पड़ोस में, लेकिन किसी तरह इसे ठीक नहीं कर पाए? प्रबंधन ने टीम को जवाबदेह नहीं ठहराया, और फिर उनके प्रबंधन ने उन्हें टीम के लिए जिम्मेदार नहीं ठहराया?

आपको याद आ रहा है कि आपकी कंपनी पूरी तरह अक्षम है ।

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

लेकिन इससे पहले, मैं प्रबंधन को देखता हूं कि चीजों को लंबे समय तक चलने दें, और यह पता लगाएं कि वे अपना काम क्यों नहीं कर रहे हैं ।

Comments

"1 उत्पाद के साथ एक छोटी सॉफ्टवेयर कंपनी" में प्रबंधन के कई स्तर नहीं होते हैं, और संभवतः संभवतः मौजूदा प्रबंधकों के पास प्रबंधन में औपचारिक शिक्षा नहीं होती है।

— माइकल बोरगवर्ड

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

— माइकल बोर्गवर्ड

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

— लिंडसे मोर्सिलो

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

— corsiKa

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

— gbjbaanb

Answer 3

मैं आपको एक छोटा सा बदलाव करने की सलाह देना चाहता हूं और कान्बन को स्क्रम के बजाय कुछ हफ़्ते के लिए आज़माना चाहता हूं । यह आपकी टीम के लिए बेहतर काम कर सकता है।

जबकि स्प्रैम एक स्प्रिंट में उपलब्ध कार्य समय को सीमित करके उत्पादकता चलाता है, कानबन सक्रिय, समवर्ती मुद्दों की संख्या को सीमित करके उत्पादकता और वेग चलाता है। समय का अनुमान प्रक्रिया का हिस्सा नहीं है। ( स्रोत )

संक्षेप में, कंबन क्या है?

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

SCRUM और कानबन समान कैसे हैं?

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

शेष विवरण इस लिंक से देखें

Comments

डाउनवोट होगा (लानत, छोटे प्रतिनिधि के लिए)। मेरी राय में, कंबन को घोटाले की तुलना में अधिक अनुशासन की आवश्यकता है क्योंकि कोई समय बॉक्स नहीं है। चूंकि टीम बिना किसी सुधार के महीनों तक "पीड़ित" रहती है, ऐसा लगता है कि या तो कहानियों को छोटे-छोटे खंडों में विभाजित करने में असमर्थ है (वे निश्चित समय अवधि के भीतर क्या कर सकते हैं) या यहाँ तक कि अक्षम भी है। कोई लाइन खत्म होने के बाद से कंबन शायद चीजों को और भी बदतर बना देंगे। और हवालात के बारे में " Kanban drives productivity and velocity by limiting the number of active, concurrent issues." - स्क्रैम के पास यह गर्भनिरोधक भी है: एक के बाद एक कहानी को पूरा करें ।

— -कैच-अंततः

हाँ, यहाँ कुछ महीनों के लिए कानबन की कोशिश की जाती है ।

— फेटी

Answer 4

मेरा प्रश्न मूल रूप से है: डेवलपर्स की गुणवत्ता में समस्या की तलाश करना कब उचित है

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

यदि मैं अविश्वसनीय रूप से उपहार देने वाले डेवलपर्स की एक टीम पर एक अविश्वसनीय रूप से उपहार देने वाला डेवलपर हूं, और हम दो कहानियों (या 36!) में एक्स कहानियों को खत्म करने में विफल रहते हैं, तो क्या हम अक्षम हैं? या, हम सिर्फ अनुमान पर चूसते हैं? यह इस बात पर निर्भर करता है कि क्या कहानियाँ "लॉगिन स्क्रीन का निर्माण करती हैं" या "एक आदमी को सुरक्षित रूप से मंगल पर भेजें"।

समस्या बुरी कहानियों और / या बुरे अनुमानों से शुरू होती है

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

आपके स्टोर क्या हैं? क्या वे अच्छी तरह से लिखे गए हैं, अच्छी स्वीकृति मानदंडों के साथ? क्या वे प्रत्येक छोटे से कुछ दिनों में करने के लिए पर्याप्त हैं? अच्छी तरह से लिखित कहानियों के बिना (जो उत्पाद स्वामी सहित पूरे विकास दल की गलती है), टीम से अच्छे अनुमान की उम्मीद नहीं की जा सकती है।

समस्या खराब पूर्वव्यापी द्वारा जटिल है

आप जो गलत कर रहे हैं, प्रतीत होता है, वह यह है कि आप रेट्रोस्पेक्टिव का लाभ नहीं उठा रहे हैं। आप इस समस्या को हल किए बिना 18 महीने चले गए हैं, इसलिए या तो टीम समस्या को नोटिस नहीं कर रही है, या अपने पूर्वव्यापी में इसे संबोधित करने में विफल हो रही है।

क्या प्रत्येक भूतलक्षी अगले स्प्रिंट पर बेहतर करने के लिए, टीम के लिए कम से कम एक कार्रवाई आइटम के साथ समाप्त होता है। क्या प्रत्येक पूर्वव्यापी में पिछले स्प्रिंट से एक्शन आइटम के बारे में बात करना शामिल है यह देखने के लिए कि क्या वे किए गए थे और यदि वे प्रभावी थे?

समाधान को दोष देना नहीं है, यह सीखना है

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

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

निरंतर सुधार इसका समाधान है

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

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

Comments

+1 लक्ष्य को दोष देने या सीखने / सुधारने के लिए नहीं होना चाहिए।

— डेविड

Answer 5

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

मेरे लिए, पूर्वव्यापी प्रक्रिया का सबसे महत्वपूर्ण हिस्सा है। आप जो भी चाहते हैं, उसके बारे में कुछ भी बाहर फेंक दें या बदल दें (एक पूर्वव्यापी के दौरान टीम के आपसी समझौते से), लेकिन नियमित रूप से समय निकालकर बात करने के लिए प्रतिबद्ध रहें कि कैसे प्रक्रिया सभी के लिए काम कर रही है, क्या काम किया और क्या किया। 't काम, और विचारों को सुधारने का प्रस्ताव। हर स्प्रिंट को अपनी प्रक्रिया में थोड़ा-थोड़ा सुधारने की कोशिश करते रहें, और जल्दी या बाद में, आपके पास कुछ ऐसा हो सकता है जो बहुत अच्छी तरह से काम करता है।

आपके मामले में, यह प्रक्रिया काम नहीं कर रही है। चूंकि स्प्रिंट लक्ष्य पूरा नहीं किया जा रहा है, यह विवेकपूर्ण है कि इस मामले में एक पूर्वव्यापी फोकस क्यों है। जाहिर है, स्प्रिंट के लिए टीम ने बहुत अधिक काम किया। लेकिन उन्होंने ऐसा क्यों किया?

• क्या उन्होंने काम की जटिलता को कम करके आंका था?
• क्या प्रबंधन ने उन्हें टीम से अधिक काम लेने के लिए दबाव डाला, सोचा कि टीम इसे संभाल सकती है?
• क्या उनके पास बहुत अधिक रुकावटें / आपात स्थिति थीं जो संसाधनों को नियोजित कार्य को पूरा करने से दूर ले गईं?
• क्या उन्हें काम में देरी होने का अनुभव हुआ (बाहरी डिजाइन टीम से संपत्ति की प्रतीक्षा करते हुए)?
• और यहां तक ​​कि: एक या एक से अधिक टीम के सदस्य काम करने में असमर्थ थे?

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

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

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

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

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

Comments

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

— एरिक हार्ट

@ एरिकहार्ट अलग चीज़ों के एक पूरे समूह की तरह लगता है जो पहले से ही टूट चुके हैं, और समय अनुमान और योजना बनाते समय होना चाहिए।

— Xiong Chiamiov

Answer 6

"सॉफ्टवेयर तब किया जाता है जब उसका काम किया जाता है, जल्दी नहीं, बाद में नहीं।"

यह सच है, लेकिन प्रत्येक कार्य के लिए जिस पर आपके डेवलपर्स काम करना शुरू करते हैं, क्या आपके संगठन में हर व्यक्ति प्रत्येक कार्य के लिए परिभाषा की समझ रखता है ?

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

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

हालाँकि, अधिकांश डेवलपर्स के पास एक निश्चित अवधि के लिए प्रयास करने की मात्रा पर एक उचित (यद्यपि आशावादी ) हैंडल होता है ।

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

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

जब कार्य का वर्णन किया जाता है तो डिस्कनेक्ट बहुत शुरुआत में शुरू होता है; और यह आमतौर पर एक गैर-तकनीकी व्यक्ति द्वारा आवश्यक प्रयासों की मात्रा का कोई सुराग न होने के बिना आवश्यकताओं की एक सूची को चित्रित करके किया जाता है।

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

कभी-कभी परियोजनाएं विफल हो जाती हैं, इससे पहले कि कोई डेवलपर कोड की एक पंक्ति भी लिख दे क्योंकि कोई व्यक्ति, कहीं अपना काम सही तरीके से नहीं कर रहा है।

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

यदि विकास टीम आवश्यकताओं को कैप्चर करने और सहमत करने में शामिल होती है, तो यह टीम की असफलता हो सकती है, जो विवरणों को स्पष्ट करने के लिए जिम्मेदार हैं (और स्वीकृति मानदंड - यानी "डिलिजेबल कैसा दिखता है? कब किया जाता है ?" )। विकास टीम भी NO कहने के लिए जिम्मेदार है जब रास्ते में अन्य अवरुद्ध मुद्दे हैं, या यदि एक आवश्यकता सिर्फ अवास्तविक है।

तो अगर डेवलपर्स आवश्यकताओं को पकड़ने में शामिल हैं:

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

संभावना यह है कि आपकी टीम की उत्पादकता कोई मुद्दा नहीं है; आपकी टीम संभवतः वे सभी प्रयास कर रही है जो वे विकास के संबंध में करने में सक्षम हैं। आपके वास्तविक मुद्दे निम्नलिखित में से एक या अधिक हो सकते हैं:

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

... सूची इससे कहीं अधिक लंबी हो सकती है।

आपको कुछ "फैक्ट फाइंडिंग" करने की जरूरत है और यह पता लगाना है कि अनुमानों को वास्तविकता से अलग क्यों किया गया है। क्या मौजूदा बेसलाइन सॉफ्टवेयर खराब है? क्या इसमें यूनिट टेस्ट कवरेज की कमी है? क्या आपके डेवलपर्स प्रबंधन के साथ संचार से बचते हैं? क्या प्रबंधन डेवलपर्स के साथ संचार से बचता है? जब "डेऑन ऑफ डेन" की बात आती है, तो क्या प्रबंधन की उम्मीदों और डेवलपर की उम्मीदों के बीच कोई अंतर है ?

Answer 7

टीम को रिबूट करने के लिए मेरी सलाह है कि प्रति टीम छोटी कहानी को प्रति स्प्रिंट, और उस एक कहानी को पूरा करना, और वह केवल एक कहानी को पूरा करना है!

मैं अन्य पोस्टरों से सहमत हूं, या तो टीम अक्षम है, या वे बहुत अधिक सामान बनाने की कोशिश कर रहे हैं।

सबसे छोटी सामग्री के साथ शुरू करें, सबसे नीचे की कहानियों को पार करें, और एक ही स्प्रिंट को पूरा करें। एक स्प्रिंट खत्म करने और सफल होने के लिए टीम प्राप्त करें, और यह उन्हें यह देखने में मदद करेगा कि अपने समय और कार्य प्रतिबद्धताओं को कैसे प्राथमिकता दें। समय के साथ टीम अपने चरम उत्पादकता पर पहुंचने तक अधिक से अधिक काम करने में सक्षम होगी।

Answer 8

आपको पिछले प्रदर्शन के आधार पर डेटा एकत्र करना चाहिए और विश्वास स्तर बनाना चाहिए।

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

सबसे सरल उदाहरण निरंतर समय स्प्रिंट के साथ है, जैसे कि हर दो सप्ताह में। अनुमान लगाएं कि टीम दो सप्ताह के भीतर कितने कहानी बताएगी। फिर दो सप्ताह के स्प्रिंट खत्म होने के बाद, देखें कि वास्तव में कितने कहानी बिंदु पूरे हुए। समय के साथ, आप देख सकते हैं कि आप 15 अंकों का अनुमान लगा सकते हैं, लेकिन केवल 10. समाप्त करते हैं। उस सरल मामले में, आप एक वेग समायोजन के साथ आगे बढ़ना शुरू कर सकते हैं, इसलिए आप प्रति अंक 10 अंक की योजना बनाते हैं। या कि आप अनुमानित काम का 66% खत्म करने की योजना बनाते हैं।

मानक विचलन के साथ आत्मविश्वास के स्तर का निर्माण करके, आप प्रबंधन को बता सकते हैं: वर्तमान परियोजना लक्ष्यों के अनुसार, हम केवल 50% विश्वास की उम्मीद करते हैं जिसे हम 3 सप्ताह में समाप्त कर सकते हैं, लेकिन 95% आत्मविश्वास हम 5 सप्ताह में समाप्त कर सकते हैं।

Answer 9

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

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

4. समस्याओं का निवारण करें (प्रतिक्रिया और अनुकूलन का विश्लेषण करें)

   • कब तक चीजें पूरी हो गई हैं?
   • क्या कार्यों को पूरा होने से रोका गया?
   • क्या टीम के सदस्य कहानियों (सुविधाओं) को 1 दिन या उससे कम समय में पूरा कर सकते हैं? यदि नहीं, तो ऐसा करें और इसे सूची में करने का हिस्सा बनाएं।
   • स्प्रिंट के दौरान कार्य सूची या कार्य सूची के आइटम में क्या परिवर्तन किए गए थे? क्या यह खत्म न होने का एक कारण था? यदि ऐसा है, तो सूची, या सुविधाएँ न बदलें। जब तक यह स्थिर नहीं होता तब तक बैकलॉग में परिवर्तित फीचर को फेंक दें।
   • आप कुछ वस्तुओं के आकार और दायरे को कम कैसे कर सकते हैं जो एक स्प्रिंट में समाप्त हो सकते हैं? एक लॉगिंग सुधार, एक साधारण बग फिक्स, एक टाइपो जैसे कुछ छोटे उठाओ, बस कुछ चीजों को समाप्त करने के लिए टीम को एक गेज प्राप्त करने दें कि वे क्या कर सकते हैं। यदि आप ऐसा नहीं कर सकते, तो स्प्रिंटिंग और री-प्लान बंद कर दें ।

5. वापस एक कदम और रिलीज तक दोहराएं ...

क्या प्रलेखन बाधाएं हैं, निर्भरता, संचार समस्याएँ पैदा करने वाली युग्मन समस्याएं, आवश्यकताओं में पर्याप्त जानकारी नहीं है? ... क्या? क्या डेवलपर्स ने अपना समय नई तकनीकों को सीखने में बिताया है? क्या वे डिजाइन में भारी मात्रा में समय बिताते थे? क्या सीखने जैसी चीजें स्प्रिंट टास्क लिस्ट में शामिल हैं?

क्या आपको लगता है कि आपकी टीम को लगता है कि उन्होंने अपनी समस्याओं को प्रत्येक पूर्वव्यापी रूप से अलग कर दिया था? क्या टीम ने समस्याओं को ठीक करने के लिए कार्य किया। क्या टीम ने जवाब नहीं दिया और प्रबंधन ने कार्रवाई के समाधान और पाठ्यक्रम को निर्धारित किया?

लंबे समय के अंतराल को देखते हुए, कुछ व्यवस्थित रूप से गलत है, न कि केवल डेवलपर्स के साथ। कुछ बिंदु पर (एक वर्ष से पहले) टीम पर किसी (स्क्रम मास्टर सहित) को पूछा जाना चाहिए कि क्या, हालांकि, छोटा, क्या हम पूरा कर सकते हैं ?

Answer 10

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

Comments

यह पोस्ट पढ़ना मुश्किल है (पाठ की दीवार)। आप आपत्ति तो नहीं है संपादित एक बेहतर आकार में यह ing?

— gnat

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

— सिनच

@Sinc: आपके पास यह जानने का कोई तरीका नहीं है कि आपके जवाब को किसने डाउन-वोट किया है। आपको यह नहीं मानना ​​चाहिए कि यह टिप्पणी करने वाला पहला व्यक्ति था। हम में से कई लोग बिना वोट दिए, और वीज़ा के बिना टिप्पणी करेंगे। एक अच्छा जवाब केवल तथ्यात्मक जानकारी से अधिक है - यह संदेश को पढ़ने और साफ करने के लिए आसान होने की आवश्यकता है जो इसे व्यक्त करने की कोशिश कर रहा है। कुछ लोग एक ऐसे उत्तर को पढ़ने के लिए तैयार होते हैं जो एक एकल सघन अनुच्छेद है, और यदि कोई उत्तर पढ़ने के लिए तैयार नहीं है या यदि यह समझना कठिन है, तो यह एक उपयोगी उत्तर नहीं है। जब आप एक उत्तर लिखते हैं, तो इसे अपने तकनीकी लेखन कौशल को सुधारने के अवसर के रूप में उपयोग करें।

— ब्रायन ओकली

Answer 11

एक जटिल कार्य को पूरा करने के लिए आवश्यक प्रयास और समय का अनुमान लगाना, जैसे कि प्रोग्रामिंग कोड, मुश्किल है। जैसा कि जोएल स्पोल्स्की इसे कहते हैं:

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

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

Answer 12

स्क्रम कुछ चीजें करता है।

सबसे पहले, यह प्राथमिकता को प्रोत्साहित करता है। काम के आपूर्तिकर्ता को कहना है कि वे पहले क्या करना चाहते हैं, और यह नहीं कहें कि "सब कुछ उतना ही महत्वपूर्ण है"।

दूसरा, यह सब कुछ समाप्त होने पर भी कुछ उपयोग योग्य उत्पाद उत्पन्न करता है। यह प्रत्येक पुनरावृत्ति के अंत में "संभावित रूप से शिप करने योग्य उत्पाद" होने की बात है।

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

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

यह इन समस्याओं को हल करने का एकमात्र तरीका नहीं है। आपको ऐसा लगता है कि यह समय-समय पर प्रत्येक कार्य के लिए डेवलपर्स को काम की एक धारा प्रदान करता है, जिसमें समय-समय पर नए काम करने, और प्रगति की जाँच करने के लिए काम की एक धारा प्रदान की जाती है।

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

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

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

इस प्रक्रिया में मौजूद सामान के लक्ष्य के अधीन है।

दूसरी ओर, क्योंकि वे SCRUM के नियमों का पालन नहीं कर रहे हैं, आपको एक ही तरह का फीडबैक नहीं मिल रहा है । आपको यह देखने के लिए परिणामी सामग्री की जांच करनी चाहिए कि क्या उत्पादित खामियां उस तरह की खामियां हैं जिनसे निपटने के लिए SCRUM को डिजाइन किया गया था; क्या ऐसी कहानियां हैं जो हमेशा के लिए लाश की तरह रहती हैं, और केवल देर से ही मारे जाते हैं? क्या ऐसी कहानियां हैं जो आसान लगती हैं, वे फट जाती हैं, और पूर्वव्यापी में जहां कुल काम के लायक नहीं है? क्या उत्पाद वास्तव में उस समय के लिए जहाज योग्य है जिसकी आपको आवश्यकता है / इसे जहाज करना चाहते हैं?

Comments

ज्यादातर बात मैं बनाने जा रहा था। यह जानने के लिए पर्याप्त जानकारी नहीं है कि "टीम ने एक बार स्प्रिंट के लिए प्रतिबद्ध सुविधाओं को वितरित नहीं किया है।" एक समस्या है। यदि सबसे अधिक, या सबसे महत्वपूर्ण, सुविधाएँ की जा रही हैं, तो कुछ भी गलत नहीं है। मैं उन स्कैम्स को पसंद करता हूं जो लगातार या उससे अधिक लोगों के लिए प्रतिबद्ध हैं जो अधिक यादृच्छिक हैं। एक टीम जो हमेशा अपनी प्रतिबद्धता को पूरा करती है, वह संभवतः करीब से जांच के लायक है।

— itj

Answer 13

"सॉफ़्टवेयर तब किया जाता है जब उसका किया हुआ, जल्दी नहीं, बाद में नहीं" विफलता का एक नुस्खा है यदि आपने परिभाषित नहीं किया है कि "किया" कैसा दिखता है।

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

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

Comments

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

— एरिक हार्ट

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

— ग्राहम

Answer 14

ओह, और हाँ हम रेट्रोस्पेक्टिव का उपयोग करते हैं।

ओह अच्छा, तो आप जानते हैं कि आपकी टीम सही क्यों विफल हो रही है? आपके पास 36 अवसर हैं जो बात करने और काम नहीं करने के लिए, इसलिए स्क्रैम मास्टर्स को पूरी तरह से समझना चाहिए कि मुद्दों को कैसे हल करें?

मेरे पास एक कूबड़ है, जो विवरण आप देते हैं कि आपकी कंपनी "SCRUM हमें उत्पादक बनाती है" मानसिकता में गिर गई है। सच्चाई यह है कि SCRUM आपके उत्पादक नहीं है। बल्कि, यह एक ऐसा उपकरण है जो आपको खुद को उत्पादक बनाने में मदद करता है जो विकास की वास्तविकताओं की पहचान करता है जो कि प्रबंधन और डेवलपर्स द्वारा समान रूप से अनदेखी की जाती हैं।

टीम के साथ संभावित मुद्दों के रूप में पहचान करने वाले मास्टर को क्या कहा गया है? क्या वे लगातार दो बार काम कर रहे हैं जितना वे संभाल सकते हैं? यदि ऐसा है, तो स्क्रैम मास्टर को धीरे से सुझाव देना चाहिए कि वे कम काम करें, क्योंकि स्क्रैम मास्टर टीम के वेग को देख सकता है।

डेवलपर्स की गुणवत्ता में समस्या को देखना कब उचित है?

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

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

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

यदि वास्तव में यह समस्या कंपनी के पास है, तो डेवलपर्स के पास नहीं, इन अधूरी कहानियों से आपको जो जानकारी मिलती है, वह वास्तव में उस उत्पाद से अधिक हो सकती है, जो आप सफल लोगों से लेते हैं! यह पूरी कंपनी को बचाने वाली जानकारी हो सकती है! यह मेरे लिए वास्तव में मूल्यवान जानकारी की तरह लगता है, और आप इसे इकट्ठा करने में मदद करने के लिए एक उपकरण के रूप में SCRUM का उपयोग कर सकते हैं।

Answer 15

"डेवलपर्स की गुणवत्ता को देखना कब उचित है?"

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

मुश्किल सा यह है कि आप इसे कैसे करते हैं। मेरी सलाह है कि अपने परमिट के लोगों द्वारा अनुमानित कार्यों के समान सेट पर अपने परमिट के कर्मचारियों के साथ काम करने के लिए कुछ अनुभवी ठेकेदार को काम पर रखें और देखें कि क्या उनके पास उच्च वेग है।

यह आपको वर्तमान बाजार के साथ एक लंबी अवधि के भाड़े में बंद किए बिना एक अच्छी तुलना देगा।

यह भी परमिट लोगों को गधे को एक लात का एक सा दे सकता है।

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

यदि यह लंबे समय तक सामान है तो यह आपको इसे मात्रा देने और आवश्यक रूप में स्प्रिंट में डालने के लिए मजबूर करेगा!

Comments

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

— आंद्रेई रिनिया

? दो बार सुविधाओं को लागू नहीं। वह पागल होगा। मैं टीम में काम करता हूं। लेकिन मौखिक लोगों को अनुमान लगाने दें

— इवान

obvs अगर समाचार लोगों ने उन अनुमानों का अनुमान लगाया, जिन पर उन्होंने आप पर काम किया था, तो पता चल जाएगा कि क्या वे सिर्फ आसान काम थे

— इवान

Answer 16

पहले से ही कई उत्कृष्ट उत्तर हैं। विशेष रूप से, बुरा अनुमान, अति-प्रतिबद्धता और / या अनिर्धारित कार्य अक्सर फिसलन के कारण होते हैं।

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

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

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

---

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