मेरा प्रोजेक्ट मैनेजर स्क्रैम में कैरी-ओवर स्वीकार नहीं करता है - क्या यह सामान्य है?


52

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

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

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

  1. क्या यह स्क्रैम की स्वीकार्य / सामान्य भिन्नता है जिसकी मुझे जानकारी नहीं है?

  2. आप कैसे सुझाव देते हैं कि मुझे इस पर कार्रवाई करनी चाहिए?


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

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

27
अपने आप से पूछें कि अगर आपने समय से पहले अपनी स्प्रिंट "प्रतिबद्धता" पूरी कर ली तो प्रबंधन का दृष्टिकोण क्या होगा। क्या टीम को बाकी स्प्रिंट ऑफ (भुगतान किए जाने सहित) मिलेगा?
क्वर्की

13
स्क्रैम में एक प्रोजेक्ट मैनेजर सामान्य नहीं है। Scrum Guide भूमिकाओं पर काफी स्पष्ट है: Scrum Master, Product Owner, Scrum Team। किसी पीएम का जिक्र नहीं। वास्तव में, कई लोगों (जिसमें एजाइल मेनिफेस्टो के अधिकांश हस्ताक्षरकर्ता शामिल हैं) ने बार-बार दावा किया है कि परियोजनाएं चपलता के लिए हानिकारक हैं। इसके अलावा, आप केवल वही हैं जो निर्णय लेते हैं कि स्वीकार्य है। यदि यह आपको स्वीकार्य नहीं है, तो अपना सीवी पॉलिश करें और बेहतर कंपनी की तलाश करें।
Blueriver

5
दो बातें: कमिटमेंट टीम द्वारा किया जाता है, पीएम नहीं, इसलिए कम से कम तात्कालिक सुधार के लिए प्रतिबद्ध हैं, हालांकि बड़ी समस्या यह है कि अगर आप डिलीवरी नहीं करते हैं तो क्या होता है? परिणाम क्या है? आमतौर पर पीएम, टीपीएम, स्क्रैम मास्टर्स, उत्पाद के मालिक आदि ... को टीम के साथ काम करने के लिए प्रोत्साहित किया जाता है ... क्योंकि मैट्रिक्स संरचना में टीम पर उनका कोई वास्तविक अधिकार नहीं होता है Agile / SCRUM खुद को उधार देता है। तो यह दूसरों की कीमत पर अपने करियर को आगे बढ़ाने के लिए एक @ कोशिश से ज्यादा कुछ नहीं हो सकता है।
आर

जवाबों:


75

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

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

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

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

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


2
शानदार जवाब - आप इसे हाइलाइट करके या TL करके भी सुधार सकते हैं? DR सबसे महत्वपूर्ण बिंदुओं को निपुण करता है: प्रतिबद्धता केवल डेवलपर से स्वतंत्र रूप से आ सकती है और काम को टिकाऊ बनाने की
Falco

साथ ही, यदि आपके पास अन्य टीमों से निर्भरता के कारण देरी है, तो आपके द्वारा अवरुद्ध समय की मात्रा आपकी टीम द्वारा दिखाई जानी चाहिए।
लुइजफ्स

2
मेरा मानना ​​है कि उन्होंने शब्दों को 'पूर्वानुमान' में बदल दिया; एक मौसम पूर्वानुमान की तरह, यह गलत हो सकता है, इसमें निश्चितता के स्तर हैं, और एक स्प्रिंट में पूरी की गई कहानियां भविष्य में अनुमान लगाने में टीम को बेहतर बनाने में मदद करती हैं।
जॉर्ज स्टॉकर

1
@GeorgeStocker हाँ - स्प्रिंट बैकलॉग और विशिष्ट आइटम आइटम के संबंध में "प्रतिबद्ध" के बजाय "पूर्वानुमान" शब्द का उपयोग किया जाता है। हालांकि, "प्रतिबद्ध" और "प्रतिबद्धता" का उपयोग टीम के लक्ष्यों के संबंध में किया जाता है।
थॉमस ओवेन्स

1
और यह भी हाँ, 9 महिलाएं 1 महीने में 1 बच्चा नहीं कर सकतीं :)
माइकल डुरंट

33

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

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

आप इसके बारे में क्या कर सकते हैं यह आपकी भूमिका पर निर्भर करता है।

यदि आप एक डेवलपर हैं, तो आप सबसे अच्छा कर सकते हैं

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

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

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

हां, और अनिश्चितता केवल तभी निकाल ली जाती है जब परियोजना समाप्त हो जाती है :-)
क्रिस्टोफ

3
अधिकांश लोग भविष्यवाणियों में बहुत अच्छे हैं। भविष्य के बारे में एकमात्र अपवाद।
माइकल ड्यूरेंट

21

आपके पीएम का आपके घोटाले में कोई व्यवसाय शामिल नहीं है।

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

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


1
"आपके पीएम का आपके घोटाले में कोई व्यवसाय नहीं है।" कुछ चुस्त तरीके (यानी डीएसडीएम) के तहत, वे करते हैं। शुद्ध स्क्रैम "प्रोजेक्ट मैनेजर" को एक भूमिका के रूप में भी नहीं पहचानता है।
निक ०

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

अनुमान लगाने के लिए बाध्य होने के लिए अन्य तार्किक प्रतिक्रिया वास्तविक कार्य का अनुमान लगाने से पहले सभी अज्ञात पर शोध करने के लिए समय निर्धारित करना है।
रोबिन बेनेट

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

DSDM एक फुर्तीली कार्यप्रणाली नहीं है, इसकी एक गंदी ढेर **** ****** **** कि *** *** ******* कि प्रबंधकों को पसंद है क्योंकि यह उन्हें बहुत कुछ देता है प्रक्रिया में शामिल होना।
gbjbaanb

12

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

कुछ बातें जिन पर आप विचार करना चाहते हैं:

स्प्रिंट में बहुत ज्यादा

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

संसाधन आवंटन

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

भिन्नता का अनुमान

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

वेग

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

अच्छा होगा

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

स्पाइक

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


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

1
मुझे लगता है कि आप समस्या के दिल में उतरते हैं। पीएम को यह समझने के लिए अपनी महत्वपूर्णता लानी होगी कि परियोजना में देरी क्यों हुई है, लेकिन # 1 कारण जो भी कारण हो उसके लिए 'अनुमान गलत थे'। (और # 1 कारण यह होगा कि पीएम उच्च अनुमानों की तरह नहीं होंगे!)
इवान

मेरे लिए, यह स्पष्ट रूप से अब तक का सबसे अच्छा जवाब है। +1
क्रोधितगीत

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

1
@MichaelDurrant एट अल। पर्याप्त रूप से उचित - मैंने पहले पैराग्राफ के शब्दों को संशोधित किया है।
रॉबी डे

10

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

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

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

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


हर जगह मैंने कभी स्क्रैम का उपयोग किया है, इसका झरना।
gbjbaanb

6

वह सही है, कि स्प्रिंट के बीच कोई कैरी-ओवर नहीं होना चाहिए। स्प्रिंट के बीच कैरी-ओवर होने वाली स्क्रम टीमें एक विरोधी पैटर्न है और ऐसा कुछ नहीं है जो कैनोनिकल स्क्रम मान्य परिणाम के रूप में स्वीकार करता है।

लेकिन, उनका दृष्टिकोण अच्छा नहीं है।

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

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

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


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

5

क्या यह स्क्रैम की स्वीकार्य / सामान्य भिन्नता है जिसकी मुझे जानकारी नहीं है?

नहीं । यह पूरी तरह से गलत है। मैं शायद भुगतान किए गए ओवरटाइम के साथ सहानुभूति रख सकता हूं , अगर पीओ ने स्प्रिंट समाप्त होने से पहले तथ्यों को अनुमान के रूप में बाहर करने की गलती की, लेकिन अवैतनिक ओवरटाइम पूरी तरह से हास्यास्पद है और मुझे एक और नौकरी एएसएपी की तलाश करेगा।

आप कैसे सुझाव देते हैं कि मुझे इस बारे में कार्य करना चाहिए?

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


अपवित्र, हालांकि अवैतनिक ओवर-टाइम परिप्रेक्ष्य उचित हो सकता है यदि अनुबंध उस तरह से तैयार किया जाता है (और सामान्य वेतन इसके लिए लेखांकन है, अर्थात औसत से ऊपर - या अन्य लाभ हैं)।
फ्रैंक होपकिंस

4

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

शुरुआत में एक उच्च वेग करने और इसे प्राप्त करने के लिए टीम को खींचने का कोई मतलब नहीं है।

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


1
अच्छा! +1। बालों को विभाजित करने के जोखिम में, आप एक वेग को "तय" नहीं करते हैं, यह सिर्फ एक चीज है जो कई प्रकार के स्प्रिंट के बाद धोती है लेकिन हां, स्प्रिंट 0 के साथ (या फिर हालांकि आप इसे संख्या देते हैं) - आप बोर्ड को ढेर कर देते हैं कई कहानियों के साथ जैसा कि आप मानते हैं कि प्राप्त करने योग्य हैं।
रॉबी डी

2

प्रतिबद्धता

क्या यह व्यवहार सामान्य है?

मुझे यकीन नहीं है।

क्या यह आश्चर्य की बात है?

नहीं। कुछ लोगों को हमेशा प्रतिबद्धता में सब कुछ पूरा होना चाहिए "प्रतिबद्धता" समझ जाएगा।

क्या यह एक अच्छा विचार है?

सं चंचल विकास में केंद्रीय विषय के रूप में स्थिरता है : केवल उतना ही / लंबे / कठिन काम करें जितना आप अनिश्चित काल तक कर सकते हैं। यह एक समझदार विचार है। (यदि आपका प्रबंधन इसे स्वीकार नहीं करता है, तो उन्हें अपने संगठन को चुस्त नहीं कहना चाहिए।)

क्या करे?

  • बता दें कि स्प्रिंट सामग्री एक अनुमान पर आधारित है । "अनुमान" का अर्थ है कि यह केवल कभी-कभी सही होगा - और आमतौर पर गलत होगा। जब यह गलत है, यह कभी-कभी बहुत कम है और कभी-कभी बहुत अधिक है।
  • बता दें कि काम की गति की तुलना में अनुमान व्यवहार को बदलना बहुत आसान है।
  • बता दें कि जब टीम को बहुत अधिक अनुमान लगाने के लिए दंडित किया जाता है, तो यह केवल कम अनुमान लगाएगा और प्रबंधन एक बार में किसी भी स्प्रिंट से कुछ सामग्री को आगे बढ़ाने की तुलना में बहुत अधिक प्रगति खो देगा।

अच्छी बात यह है कि आपका प्रोजेक्ट मैनेजर इन सभी बातों को पहले से ही जान लेगा और उन्हें सही होने की पहचान देगा। यह केवल इतना है कि अल्पावधि में कोई भी उन्हें अनदेखा करना पसंद कर सकता है।


2

मैं आपकी प्रबंधन टीम से सहमत नहीं हूं। उन्हें स्प्रिंट खत्म करने के लिए आपको ओवरटाइम काम नहीं करना चाहिए था।

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

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

पूर्व के मामले में, आपको यह सुनिश्चित करना होगा कि आप कहानी के दायरे को समझने से पहले उसे समझ लें। यदि यह बाद की बात है, तो आपके पास संस्कृति की समस्या है और ऐसा बहुत कम है जो किया जा सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.