क्या स्क्रम सक्रिय डेवलपर्स को निष्क्रिय डेवलपर्स में बदल देता है?


103

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

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

आप क्या करना है , या क्या किया जाना है , यह तय करने के बीच एक बड़ा अंतर है

स्कोर करने से पहले, मुझे ऐसा लगता था कि विकास, विश्लेषण, कार्यान्वयन को प्राथमिकता देने आदि से संबंधित निर्णय लेने में मुझे अधिक स्वतंत्रता है, मुझे अधिक महसूस हो रहा था जैसे मैं निर्णय ले रहा हूं कि मैं क्या कर रहा हूं

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

  1. मैं एक बेहतर समाधान, दृष्टिकोण या तकनीक खोजने के लिए कम खोज करता हूं
  2. मैं एक सुखद काम करने की उम्मीद में सुबह नहीं उठता। बल्कि, मुझे लगता है कि जीने के लिए काम करने के लिए मजबूर किया जा रहा है
  3. मुझे काम के बाद अपने खुद के हॉबी प्रोजेक्ट्स पर काम करने की ज्यादा भूख है
  4. मैं उच्च तकनीकी स्तरों तक पहुँचने के लिए टीम को आगे नहीं बढ़ाऊँगा
  5. मैं अब अधिक समय रात्रिभोज, या चाय-बार में बिताता हूं और काम पर वापस जाने का उत्साह कम होता है
  6. अब मैं काम को जल्द पूरा करने के लिए तैयार हूं, ताकि मुझे घर मिल सके

बड़ी समस्या यह है, मैं अपने सहयोगियों में भी इस व्यवहार को देखता हूं और निदान करता हूं। क्या यह घोटाले का नतीजा है? क्या वास्तव में विकास टीम को ऐसा लगता है कि उनके पास समग्र सॉफ्टवेयर बनाने में कोई भूमिका नहीं है, इस प्रकार यह परियोजना को निष्क्रिय बना देता है? मैं इस भावना को कैसे दूर कर सकता हूं?


4
क्या आप सुनिश्चित हैं कि आप अपने आप को बहुत पहले से ही दुखी नहीं कर रहे थे?
डोनल फैलो

27
अच्छा ब्लॉग पोस्ट।
रॉबर्ट एस।

20
जो आप बता रहे हैं वह

4
@Chad। मैंने यहां जो चर्चा की वह मेरे काम की स्थिति की शिकायत नहीं है। मुझे आश्चर्य है कि क्या यह मनोदशा स्कैम का परिणाम है? और क्या अन्य डेवलपर्स भी एक ही चीज़ का अनुभव कर रहे हैं या नहीं?
सईद नेमाटी

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

जवाबों:


51

हालांकि, मुझे अब ऐसा लगता है कि मुझे हमेशा कुछ करने के बजाय कुछ करने के लिए कहा जा रहा है।

यह एक गंभीर संकेतक है कि कुछ रेल से दूर चला गया है। एक फुर्तीली परियोजना को ऐसा महसूस नहीं करना चाहिए। उस "प्रक्रिया से अधिक लोग" बयानबाजी में शामिल होना चाहिए "हम अपने लोगों को ऐसे काम करने के लिए मजबूर नहीं करते हैं जो चूसते हैं।" यहाँ कुछ विचार हैं:

क्या आप "स्क्रैम लेकिन" कर रहे हैं? यही है, भाग घोटाला, कुछ और बात भाग। (अर्थात: "हम घोटाले कर रहे हैं, लेकिन हमारी सभी कहानियों को हमारे पीएमओ से आना है, उत्पाद के स्वामी से नहीं।") इन दिनों बहुत सारे पागल बकवास को स्क्रैम कहते हैं।

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

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


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

5
"लोग प्रक्रिया से अधिक": मजाकिया, फिर लोगों को अपने स्वयं के उपयोग करने देने के बजाय SCRUM प्रक्रिया क्यों थोपते हैं? और क्यों उन सभी उपायों (जोड़ी प्रोग्रामिंग, लगातार प्रगति की समीक्षा), जो पारदर्शिता के नाम पर, डेवलपर्स के काम की अधिक बारीकी से निगरानी करने की अनुमति देते हैं?
जियोर्जियो

3
@ जियोर्जियो: क्योंकि संरचित विकास टीमों को एक-दूसरे के पैर की उंगलियों पर हर समय कदम रखे बिना एक साथ काम करने में सक्षम बनाता है। हमने अभी यह पता नहीं लगाया है कि यह पूरी तरह से कैसे किया जाए।
फॉशी

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

62

आपकी समस्या स्क्रम नहीं है (और जैसा कि जारोड रॉबर्सन ने टिप्पणियों में उल्लेख किया है, यह स्क्रम नहीं है कि आप क्या वर्णन कर रहे हैं) - यह उत्पाद स्वामी का micromanagement और आपकी (और टीम की) मुखरता का अभाव है

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

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

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

BTW micromanagement निष्क्रिय डेवलपर्स में सक्रिय डेवलपर्स को चालू करता है।


38
उस अंतिम पंक्ति के लिए आमीन
विवान

6
"प्रोडक्ट ओनर बताता है कि क्या करना है, लेकिन यह टीम पर निर्भर है कि वह कैसे करे।" यह वास्तव में देव प्रेरणा के लिए एक समस्या हो सकती है: नवाचार की कमी। ज्यादातर समय ग्राहक तेज घोड़े चाहते हैं, कार नहीं। लेकिन मैं बिल्कुल micromanagement से सहमत हूँ।
MaR

1
+1 @Lukas, क्या और कैसे के बीच अंतर के कारण । धन्यवाद यार।
सईद नेमाटी

5
"उत्पाद स्वामी आपको बताता है कि क्या करना है" - मैं इससे सहमत नहीं हूं। उन्हें आपको यह बताना चाहिए कि उन्हें क्या चाहिए । एक मामूली लेकिन महत्वपूर्ण अंतर। दूसरे शब्दों में: वे समस्या / समस्या का वर्णन करते हैं, आप समाधान प्रदान करते हैं।
डैनमैन

2
@ एमआरआर यही कारण है कि देवता ग्राहकों से बात नहीं करते हैं। ग्राहक उत्पाद स्वामी से बात करते हैं और तेज घोड़ों के लिए पूछते हैं, पीओ वह है जो सभी ग्राहकों के मुद्दों को देखता है, उन्हें जोड़ता है और प्राथमिकता देता है, और इस प्रक्रिया में यह पता चलता है कि कारें तेज घोड़ों से बेहतर हैं
इजाका

29

आप जो वर्णन कर रहे हैं वह SCRUM नहीं है

यदि आपका उत्पाद तकनीकी रूप से अपना काम करने का तरीका बता रहा है, तो SCRUM बिल्कुल भी नहीं है, तो आपका उत्पाद स्वामी अपनी सीमा को पार कर रहा है।

जमघट डेवलपर्स को मुक्त कराने के विकास के मुद्दों पर ध्यान केंद्रित करने और के बारे में है को सशक्त बनाने के लिए उन्हें कितनी देर तक बातें ले निर्धारित करने के लिए और कैसे उन्हें करने के लिए के प्रभारी ले।

SCRUM सहयोग के बारे में है, यही वह है जो स्प्रिंट योजना बैठकों के लिए है, सभी हितधारकों के बीच सहयोग को बढ़ावा देने के लिए; उत्पाद के मालिक, डेवलपर्स और परीक्षण।

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

मैं इस बात से सहमत नहीं हूं कि डेवलपर्स को GUI और वर्कफ़्लोज़ को तब तक डिज़ाइन करना चाहिए जब तक कि उन्हें विशेष रूप से ग्राहकों के साथ काम करने और प्रशिक्षित करने के लिए प्रशिक्षित नहीं किया जाता है और सीधे ग्राहकों के साथ कार्यक्षमता का उपयोग किया जाता है। प्रोग्रामर ने GUI का निर्माण एक ऐसे निर्वात में किया है, जो ग्राहकों की जरूरतों को पूरा नहीं करता है।

SCRUM एक हल्की वजन प्रक्रिया डालने के बारे में है जो चुस्त और सुस्पष्ट है।

मुझे ऐसी कहानियाँ सुनकर दुःख होता है कि बहुत अच्छी चीजें इस तरह विकृत हो रही हैं।


3
मानव स्वभाव हमेशा जीत के जबड़े से हार को छीनने का रास्ता खोजेगा।
वॉरेन पी।

2
वहाँ क्या जमघट रहा है माना जाता है, और क्या यह वहाँ जा रहा समाप्त होता है , कम से कम ज्यादातर कंपनियों पर। SCRUM अपने आप में बुराई नहीं है, लेकिन यह एक ऐसा उपकरण है जो प्रबंधन द्वारा बुराई के लिए बहुत आसानी से उपयोग किया जाता है।
अर्सअवतार

11

मैं स्करम से पहले अनुमान लगा रहा हूं, हर कोई बस यही चाहता था: yippee ki-yay mf'er । आपके उपयोगकर्ता आपके लाभार्थी हैं और वे कहानी चलाते हैं और बिलों का भुगतान करते हैं। उत्पाद स्वामी सुनिश्चित करता है कि कहानी हो गई है। कुछ कैसे, आपका समूह इस नतीजे पर पहुंचा कि प्रोडक्ट ओनर आपको बताए कि कैसे प्रोग्राम करना है।

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

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


10

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

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

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


6
मुझे? हाँ - हम अच्छी तरह से काम करते थे, फिर प्रबंधन ने फैसला किया कि एजाइल भविष्य था, और लगाया गया घोटाला, जिसने हमें जबरदस्त रूप से प्रतिबंधित कर दिया। हम जो सहजता से करते थे, वह प्रक्रिया और नौकरशाही में फंस गया। मैंने एक बार स्क्रैम बोर्ड से 3 कार्ड लिए थे !! रोशनी भड़क गई और सायरन इस 'स्क्रम रास्ता' के उल्लंघन के लिए निकल गया, और मैंने एक बार कार्ड को अपनी डेस्क पर वापस ले लिया । परियोजना प्रबंधन पुलिस मेरे लिए आया था। और मैं रोजाना तफ्तीश में बैठ जाता था, जो अच्छी तरह से नीचे नहीं जाता था। सभी तुच्छ IMHO, लेकिन पहाड़ों में बनाए गए थे।
gbjbaanb

2
क्या आपको नहीं लगता कि आपके मामले में यह एक खराब, टॉप-डाउन कार्यान्वयन है जो कि उत्पादकता का नुकसान हुआ है? आप कहते हैं कि आप "प्रक्रिया और नौकरशाही में फंस गए हैं" जो कि अजीब है क्योंकि स्क्रैम दुनिया की सबसे सरल नौकरशाही पद्धति है ... वास्तव में पूरा स्क्रैम ढांचा एक शीट या 2 में फिट बैठता है। Btw जिसे आप "स्क्रैम बोर्ड" कहते हैं ढांचे का हिस्सा नहीं है। सईद के मामले में हालांकि मेरा मानना ​​है कि समस्या उस संगठन के प्रकार के बीच की खाई है जो उसने काम किया था (डेवलपर्स के लिए महान स्वतंत्रता और निर्णय की शक्ति के साथ) और संगठन के प्रकार पर स्क्रम लागू होता है।
guillaume31

3
@ ian31: हां, यह परियोजना विशेष रूप से खराब थी, लेकिन स्क्रैम खुद को उन प्रकार के प्रबंधकों से अपील करता है। आप उन्हें कभी भी कानबन या क्रिस्टल चुनने के बाद नहीं देखते। स्क्रम बहुत आसानी से "घबराता है" लेकिन जब ये लोग इसे पकड़ लेते हैं। अफ़सोस की बात है।
gbjbaanb

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

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

8

मुझे लगता है, कि बस आप लोगों को अधिक स्वामित्व रखने की आदत है - और मुझे लगता है कि हर कोई इसके मानवीय स्वभाव को पसंद करता है।

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

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


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

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

@ ऑंडोमर - यह एक संतुलन है। प्रत्येक पक्ष के आदर्श, मान्यताएँ और दोष हैं। इनमें से किसी को भी अनदेखा करना संकट का कारण बनता है।
जोन्को

5

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


4
एक डेवलपर के रूप में मैं इस तरह की उपयोगकर्ता कहानी को फिर से कभी नहीं देखना चाहता, ताकि मुझे कभी भी इसकी निर्जीवता पर काबू न हो सके।
वॉरेन पी।

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

4

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

एजाइल मैनिफेस्टो से:

हमारी सर्वोच्च प्राथमिकता मूल्यवान सॉफ़्टवेयर के शुरुआती और निरंतर वितरण के माध्यम से ग्राहक को संतुष्ट करना है।

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

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

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


3

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


3

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

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

और हम कभी-कभी सूक्ष्म प्रबंधन करते हैं, लेकिन यह एक अलग समस्या है।


3

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

प्रश्न: कार्यप्रणाली x निर्धारित करती है, लेकिन x अच्छी तरह से काम नहीं कर रहा है। क्या करे?

ए: एक्स के अपने कार्यान्वयन को परिष्कृत करें। शायद पूरी तरह से करना बंद कर दें। कार्यप्रणाली आप का बॉस नहीं है!

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


2

मैं वास्तव में पूरे घोटाले की धुन में नहीं हूं क्योंकि कुछ समय के लिए और अधिक झरना रहा हूं।

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


नहीं @temptar, हमारा रिश्ता वास्तव में अच्छा है। कोई अपराध नहीं, कोई घृणा नहीं, कुछ भी नहीं। सब कुछ ठीक है, सब कुछ छोड़कर हम काम के प्रति कैसा महसूस करते हैं।
सईद नेमाटी

2

एक स्व-आयोजन टीम पर नेताओं की भूमिका एक ब्लॉग पोस्ट होगी जो आपके पोस्ट से गायब प्रतीत होती है। स्प्रिंट में क्या काम होता है, यह टीम तय करती है। प्रक्रिया और कार्य में टीम का स्वामित्व कहां है? क्या आपके पास कोई ऐसा व्यक्ति है जो स्क्रम को काफी जानता है कि आप स्क्रम कर रहे हैं और इसके कुछ विकृत संस्करण नहीं हैं?


2

मुझे स्क्रम के साथ भी ऐसा ही अनुभव था और इसे "कहानी का अत्याचार" कहना पसंद था।

मेरे अनुभव से डेवलपर्स को रचनात्मक / डिज़ाइन / फ्रंटेंड की ओर से अधिक बैकेंड के काम में शामिल लोगों की तुलना में इससे अधिक नुकसान होता है।

मेरा अब तक का एकमात्र तरीका यह था कि या तो स्क्रैम को खोदा जाए - अक्सर संभव नहीं और / या उचित हो क्योंकि आखिरकार इसके फायदे हैं - या डेवलपर्स को "आप 'के अलावा एक रचनात्मक आउटलेट देने के लिए Google के 20% समय की तरह कुछ पेश करना। यह चुनने के लिए स्वतंत्र हैं कि लॉगिन पेज को कैसे लागू किया जाए ”, क्योंकि वास्तव में आप नहीं हैं क्योंकि आपका कार्यान्वयन मौजूदा कोड और सिस्टम आर्किटेक्चर द्वारा विवश है - जब तक कि कोई व्यक्ति for फॉर ए और फॉर लूप’ के बीच चयन करने की स्वतंत्रता पर विचार नहीं करता है आजादी।


1

आप क्या करना है , या क्या किया जाना है , यह तय करने के बीच एक बड़ा अंतर है

मेरे अनुभव में, वहाँ सिर्फ एक नहीं बल्कि लंबा रास्ता तय करना है से कहा जा रहा है कि क्या करना है करने के लिए क्या करना है तय करने।

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

ओह और मेरे अनुभव में इसका मूल रूप से स्क्रैम / फुर्तीली से कोई लेना-देना नहीं है। जो भी हो, घबराहट, पुनरावृत्ति, झरना के साथ हुआ। लगता है कि विश्वास की बात एर प्रक्रियावादी है


1

हमारी टीम में, उत्पाद स्वामी हमें बताता है कि हमें क्या करना है और हम यह तय करते हैं कि हम इसे कैसे करते हैं। इस पृथक्करण का होना वास्तव में महत्वपूर्ण है या आप जिस स्थिति में वर्णित हैं, उसे समाप्त कर देंगे।


1

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


"गुणवत्ता को स्क्रैम पद्धति के साथ समझौता किया जा रहा है।": शायद यह कहना थोड़ा अतिवादी है कि गुणवत्ता से समझौता हो जाता है लेकिन, हां, परियोजना की गुणवत्ता की तुलना में उच्च प्राथमिकता प्राप्त होती है।
जियोर्जियो

कमाल है कि कुछ लोग स्क्रैम या फुर्तीले के बारे में कैसे जानते हैं, और फिर भी वे अधिकारियों की तरह कैसे पोस्ट करते हैं। किसी को यह आभास हो जाता है कि किसी व्यक्ति ने कुछ हफ्तों के लिए एक बेकार समूह पर काम किया था, जहां उन्होंने कहा था कि वे "स्क्रैम कर रहे हैं" और निष्कर्ष निकाला कि स्क्रैम को कैसे माना जाता है। इस मामले में, यह 4 वर्षों में केवल एक पोस्ट या टिप्पणी के साथ पूरी तरह से गुमनाम लड़का है, और इस विषय पर विशेषज्ञता का कोई सबूत नहीं है। यही कारण है कि हम इनमें से कई टिप्पणियों को बहुत गंभीरता से नहीं ले सकते हैं।
कर्टिस
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.