आप एक "फुर्तीली" टीम को कैसे समझाते हैं कि उन्हें अभी भी अपने द्वारा लिखे गए सॉफ़्टवेयर की योजना बनाने की आवश्यकता है?

Question

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

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

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

इसलिए, आप एक डेवलपर के रूप में टीम को कैसे समझाते हैं कि यह उनके काम की योजना बनाने के लिए "अन-एजाइल" नहीं है, और आप चुस्त प्रक्रिया में योजना बनाने के लायक कैसे हैं? (मैं आईपीएम के बारे में बात नहीं कर रहा हूं; मैं एक समस्या के साथ बैठकर बात कर रहा हूं और एक एंड-टू-एंड डिजाइन का वर्णन करता हूं जो कहता है कि समस्या को कैसे पर्याप्त रूप से हल किया जाना चाहिए कि जो कोई भी समस्या पर काम करता है वह जानता है कि क्या वास्तुकला और पैटर्न जो उन्हें उपयोग करने चाहिए और जहां नया कोड मौजूदा कोड में एकीकृत होना चाहिए)

Comments

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

+1 बहुत दिलचस्पी है कि लोग इसे व्यावहारिक तरीके से कैसे हल करते हैं जो आपको सबसे अच्छा झरना और फुर्तीली दोनों की सुविधा प्रदान करता है। वैसे: फुर्तीली "कोई डिज़ाइन नहीं" के बराबर है, लेकिन डिजाइन स्प्रिंट के अथक चक्र में पहला शिकार करने के लिए करते हैं ...

— मार्जन वेनेमा

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

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

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

— रीइन हेनरिक

Answer 1

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

यह निश्चित रूप से सभी बैल है: आपको यह जानना होगा कि आप क्या कर रहे हैं - और एक विनिर्देश एक साधन है जिसके द्वारा डेवलपर और ग्राहक संचार कर सकते हैं कि क्या इरादा है।

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

इन चरणों में से प्रत्येक में पुनरावृत्ति होगी: आप चीजों को गलत या गायब पाते हैं, और उन्हें ठीक कर सकते हैं। यह डिबगिंग है। यह किसी भी कोड को लिखे जाने से पहले किया जाता है।

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

एक बार जब आपके पास WHAT (जो आपकी कल्पना है) और HOW (जो कि आर्किटेक्चर है - जो एक उच्च-स्तरीय डिज़ाइन है) तो आपके पास कार्य हैं। आमतौर पर उनमें से बहुत सारे।

हालाँकि आप जो काम चाहते हैं, उन्हें फोड़ लें, हालाँकि आप उन्हें चाहते हैं। सप्ताह के जो भी तरीके आपको पसंद हैं, या जो आपके लिए काम करता है, उसका उपयोग करें। और उन कार्यों को पूरा करें, यह जानते हुए कि आप कहाँ जा रहे हैं और आपको क्या पूरा करना है।

रास्ते में झूठे रास्ते, गलतियाँ, समस्याएँ और वास्तुकला के साथ पाया जाएगा। यह इस तरह की चीजों का संकेत देता है: "वैसे तो यह सब योजना समय की बर्बादी थी।" जो बैल भी है। यह सिर्फ मतलब है कि आप बाद में निपटने के लिए कम बेईमानी से है। जैसा कि आप उच्च स्तर के शुरुआती दिनों के सामान, FIX THEM के साथ समस्याओं का पता लगाते हैं।

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

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

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

[क्या आप गंभीरता से 1000 मजदूरों को साइट पर रखकर और उन्हें कुछ काम करने के लिए टीम बनाने के लिए कहकर 25 मंजिला इमारत बनाने की उम्मीद करेंगे? बिना योजनाओं के। संरचनात्मक गणना के बिना। एक डिजाइन या दृष्टि के बिना कि इमारत कैसे दिखनी चाहिए। और केवल यह जानते हुए कि यह एक होटल है। नहीं - ऐसा नहीं सोचा था।]

Comments

+1। +10 अगर मैं कर सका। यदि आपको यह पता नहीं है कि आप आखिरकार क्या बना रहे हैं - जो केवल कुछ अप-फ्रंट डिज़ाइन के काम से आ सकता है, भले ही आप उस डिज़ाइन को बाद में संशोधित करें - तो आपके द्वारा पीछा किया जा रहा विकास प्रतिमान "फेंक" है दीवार पर बकवास करो और देखो कि क्या चिपक जाता है ”।

— एंट

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

— मार्टिन विकमैन

+1। +10 अगर मैं +1 कर सका। मैं इमारत सॉफ्टवेयर के लिए एक कुल चूसने वाला हूं, एक इमारत सादृश्य बनाने की तरह है क्योंकि यह सिर्फ है। हाँ सॉफ्टवेयर भौतिक नहीं है, हाँ सही ढंग से किया गया यह अत्यधिक मॉड्यूलर और डिकूप्ड हो सकता है। लेकिन इसे अत्यधिक मॉड्यूलर और डिकौप्ड बनाना बहुत कठिन है; यही समय और नियोजन लेता है। मुझे पता चला है कि सॉफ्टवेयर इंजीनियरिंग में हमेशा दो शिविर होंगे: जो लोग सोचते हैं कि योजना बनाना समय की बर्बादी है और जो नहीं करते हैं। और आप जानते हैं कि मैंने महसूस किया है कि लोग शिविरों को नहीं बदलते हैं, वास्तव में नहीं। मैंने अत्यधिक नियोजित वातावरण में काम किया है और ...

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

— सारा

काई - मैं देख रहा हूँ कि चंचल का उपयोग करने के लिए कोई बहाना नहीं किया जा रहा है कोई विनिर्देश, कोई योजना नहीं, बस में गोताखोरी। और यह सिर्फ सादा गलत है।

— जल्‍दी से जल्‍दी_जुन

Answer 2

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

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

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

जलप्रपात प्रक्रिया से बहुत सी चीजें संचार और स्वचालित परीक्षणों से बदल दी जाती हैं। कोई भी नहीं कहता है कि आप किसी भी उच्च स्तरीय दस्तावेज या डिज़ाइन को नहीं लिख सकते हैं! आप और कई टीमें उदाहरण के लिए विकी का उपयोग कर सकते हैं।

Comments

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

— स्टीवन ए लोवे

Answer 3

[हमारा उत्पाद था] का उपयोग करने के लिए बहुत धीमा, छोटी गाड़ी, भूलभुलैया जटिल और पूरी तरह से अनम्य।

फुर्तीलेपन से इसका कोई लेना-देना नहीं है, यह प्रोग्रामर का काम ठीक से नहीं करने का संकेत है।

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

अंत में यह कोड गुणवत्ता के बारे में समझाने और इसे बढ़ाने के तरीके पर सहमत होने की कोशिश करने का एक तरीका है। सामान्य प्रोग्रामिंग प्रथाओं वास्तव में लागू होते हैं।

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

Comments

"उन्होंने अपनी स्वतंत्रता को स्वीकार किया, लेकिन अपनी जिम्मेदारियों की उपेक्षा की" शायद फुर्तीली दीवार पर एक बैनर होना चाहिए "क्या आपने अपनी स्वतंत्रता के साथ-साथ अपनी जिम्मेदारियों को स्वीकार किया है?"

— एंडी डेंट

महान जवाब, क्या मैं यह सुझाव दे सकता हूं कि जब आप DoD का उपयोग इस तरह से एक अनुबंध के रूप में करते हैं, तो यह पूर्वव्यापी में भी केंद्रीय हो जाता है? इस DoD ने हमारे ग्राहकों के लिए मूल्य को जोड़ने में हमारी सहायता या बाधा कैसे की?

— ग्राहम ली

Answer 4

हाँ। आपके टीम के साथी बेवकूफ हैं। आपका प्रोजेक्ट चुस्त होने के कारण चूसा। बेहतर महसूस करना? ठीक है, चलो आगे बढ़ते हैं। : पी

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

फुर्तीली कभी-कभी काम करती है। इस बार इसने आपकी टीम के लिए काम नहीं किया। कुछ लोग कहेंगे ऐसा इसलिए है क्योंकि आपने एजाइल को गलत किया है। सब के बाद, फुर्तीली काम करता है, इसलिए यदि आपने इसे सही किया होता तो यह सही काम करता, ठीक? जो कुछ।

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

इसके बजाय, विफलता के सबसे प्रत्यक्ष कारणों को कम करने पर ध्यान केंद्रित करें और यह सुनिश्चित करने के लिए टीम के साथ काम करें कि वे फिर से न हों। इसके लिए लोगों के कौशल की आवश्यकता होगी।

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

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

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

Answer 5

यदि आप अपनी चर्चाओं में एक तीखी बोली जोड़ना चाहते हैं, तो आइजनहावर के पास एक अच्छी बात थी:

"योजनाएं कुछ भी नहीं हैं; योजना सब कुछ है।"

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

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

Answer 6

+1 यह हाल ही में मैंने पढ़ा है उद्यम फुर्तीले का सबसे अच्छा विवरण है।

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

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

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

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

मैं कम चिड़चिड़े रोजगार की तलाश करूंगा कि वह कहीं और फुर्तीला हो या नहीं।

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

Comments

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

— B:овиЈ

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

— बिल

Answer 7

मैं एक तरह के हाइब्रिड का उपयोग करता हूं। समग्र योजना झरना है, लेकिन निष्पादन में चुस्त है।

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

Comments

मैं भी यही सोचता हूं। मुझे यकीन है कि असली फुर्तीली योजना नहीं है, यह सिर्फ इतना है कि इसकी एक व्याख्या है।

पूंजी के बीच अंतर की दुनिया है- "ए" फुर्तीली और लोअरकेस- "ए" फुर्तीली।

— Aaronaught

Pssst ... फुर्तीले लोगों को यह मत बताइए कि चूंकि लगभग सभी झरने लोग ऐसा करते हैं, क्योंकि यह काम करता है। वे अभी भी मानते हैं कि सभी जलप्रपात डेवलपर्स किसी भी कोड को लिखे बिना बहुत अंत तक अखंड दस्तावेजों का निर्माण करते हैं और प्रत्येक चरण में सब कुछ गलत है क्योंकि कोई कार्यान्वयन नहीं है।

— डंक

Answer 8

कुछ कर्मचारियों के साथ हमारी भी यही समस्या है।

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

अगर हमारे पास "डिलीट / इंटरेस्टिंग / प्लान वगैरह" समान डिलिवरेबल स्प्रिंट में "फन एंड इंटरेस्टिंग कोड" है तो पहला भाग कभी नहीं होता ...

लेकिन अगर मुझे जगह मिलती है, तो आपको कोई मजेदार और दिलचस्प कोड नहीं मिलता है जब तक कि आपने यह नहीं कहा है कि आपका क्या बनने वाला है और ग्राहक ने "बंद" कर दिया है।

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

फुर्तीला हिस्सा तब आता है जब ग्राहक योजना से बदल जाता है और आप 2 सप्ताह के भीतर अपने पैंट की सीट से उड़ान नहीं भर सकते हैं और इसे ऊपर की तरफ कर सकते हैं।

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

छोटी परियोजनाओं में हमारे पास बस वही डेवलपर है जो पहले डिजाइन करते हैं> साइन इन करें> चालान> विकसित> साइन ऑफ> चालान ... चक्र में।

परीक्षण नामकरण समस्या

परीक्षण के कई चेहरे हैं, औपचारिक रूप से उप खंडों के साथ प्रत्येक के लगभग 7 कैटगिरीज़ हैं ... इनमें से एक बाद में "स्वचालित इकाई परीक्षण लिखना" है।

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

Answer 9

एजाइल के प्रमुख तत्वों में से एक निरंतर सुधार का विचार है, और यह विचार कि पूरी टीम परियोजना का मालिक है। इसलिए सही दृष्टिकोण टीम के साथ मुद्दों की समीक्षा करने के लिए होता, और टीम यह तय करती है कि इसे कैसे ठीक किया जाए।

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

Comments

मुझे लगता है कि परियोजना को आगे बढ़ाने की तरह यह ठीक था कि उसने क्या किया । "टीम के साथ समीक्षा" वास्तव में एक समाधान नहीं है, यह केवल समाधान को स्थगित करने और जिम्मेदारी फैलाने का एक तरीका है।

— Aaronaught

परिणाम के लिए टीम पहले से ही जिम्मेदार है। किसी को कहने के लिए उन्हें क्या ज़रूरत है, "हम गड़बड़ कर रहे हैं, हम अपनी कार्यप्रणाली कैसे बदलेंगे?" फिर वे इसे ठीक करते हैं।

— डेव

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

— Aaronaught

Answer 10

उन्हें काम करने का एक तरीका टी-मैप बनाना हो सकता है जो आपके सभी स्प्रिंट बैक-लॉग को कवर करता है

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

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

Answer 11

आपको दो समस्याएं हैं: आवश्यकताओं और खराब वास्तुकला पर पर्याप्त आकार नहीं।

आवश्यकताएँ

आपको एक समग्र अंत लक्ष्य और वहां पहुंचने के विस्तृत रोडमैप दोनों की आवश्यकता है।

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

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

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

सिस्टम आवश्यकताएँ दस्तावेज़ होने के बारे में अच्छी बात यह है कि तब उपयोगकर्ता की कई कहानियों के लिए स्वीकृति मानदंड निकाला जा सकता है।

उच्च स्तरीय सिस्टम आवश्यकताओं के दस्तावेज़ को "कट शीट" के रूप में सोचें, जो विपणन तकनीकी रूप से प्रेमी ग्राहक को उत्पाद बेचने के लिए उपयोग कर सकता है।

आर्किटेक्चर

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

यदि आपकी टीम के पास इस तरह के दस्तावेज़ जल्दी थे, तो आपको बाद में सिस्टम को फिर से तैयार करने के दर्द से नहीं गुजरना होगा।

---

दरअसल, आपके पास एक तीसरी समस्या खराब संचार है। संचार एक दो-तरफ़ा सड़क है (या कई लोगों के बीच बहु-मार्ग)। हालाँकि, यह सिर्फ एक मानवीय असफलता है और सही होने के लिए (कभी-कभी) अलौकिक प्रयास करता है।