छोटी टीमों के लिए प्रोग्रामिंग की योजना बनाने का सबसे अच्छा तरीका? [बन्द है]

Question

मैं एक छोटे स्टार्टअप संगठन का निदेशक हूं। वर्तमान में हमारे पास दो प्रोग्रामर (एक अनुभवी, एक कम अनुभवी) जो एक वेब एप्लिकेशन प्लेटफॉर्म का निर्माण कर रहे हैं।

अब तक की सबसे बड़ी चुनौतियों में से एक योजना प्रक्रिया है। प्रोग्रामर आमतौर पर अपने स्वयं के काम की योजना बनाने के प्रभारी होते हैं, लेकिन हम उनकी स्वयं की समय सीमा को पार कर लेते हैं। उदाहरण के लिए, एक कार्य जिसके बारे में वे अनुमान लगाते हैं कि २ दिन लगेंगे, that दिन लगेंगे।

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

क्या तुम्हारे पास कोई विचार है:

1. इसका कारण क्या है, क्या यह प्रोग्रामर के लिए सामान्य है?
2. योजना बनाने में उनका समर्थन करने के लिए मैं क्या कर सकता हूं? क्या ऐसी कोई विधि या उपकरण हैं जो छोटी टीमों के प्रोग्रामर के लिए उपयोगी हैं?

Comments

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

— ल्यूक फ्रेंकिन

@ जॉन बी, आप यहां ऐसे ही सवालों पर एक नज़र डाल सकते हैं ( programmers.stackexchange.com/questions/tagged/… ), लेकिन यह तथ्य कि आप गैर-तकनीकी हैं, उनमें से अधिकांश को सहायक के रूप में समाप्त कर देंगे। लेकिन ये मददगार हो सकते हैं: programmers.stackexchange.com/questions/16326/… , programmers.stackexchange.com/questions/39468/… , programmers.stackexchange.com/questions/208700/…

— superM

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

— जॉन बी

इस विषय पर एक बहुत अच्छी पुस्तक है: माइक कोहनेस एजाइल एस्टिमेटिंग एंड प्लानिंग। mountaingoatsoftware.com/books/agile-estimating-and-planning

— HbAS

मैं हैरान हूँ कि कोई भी अभी तक इस से जुड़ा हुआ है: joelonsoftware.com/items/2007/10/26.html

— पॉल

Answer 1

सामान्य तकनीकें कुछ हद तक सामान्य हैं, यह जानना महत्वपूर्ण है कि उन्हें बहुत तकनीकी विशेषज्ञता की आवश्यकता नहीं है।

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

एक बार जब आप आवश्यकता को पहचान लेते हैं तो आपको इसे हल करने में शामिल कार्य कार्यों की पहचान करने की आवश्यकता होती है। यह एक क्लासिक विभाजन है और व्यायाम को जीतना है - कोई भी कार्य जिसे आगे तोड़ा जा सकता है उसे और नीचे तोड़ने की आवश्यकता है।

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

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

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

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

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

Comments

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

— जॉन बी

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

— ग्लेनट्रॉन

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

— मॉर्फ

Answer 2

[2 दिनों के उनके अनुमान 8 दिन लगने का] क्या कारण है, क्या यह प्रोग्रामर के लिए सामान्य है?

यह है, अगर:

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

कुछ चीजों का नाम लेने के लिए।

शायद अपने डेवलपर्स से पूछना सबसे अच्छा है कि उन्हें क्यों लगता है कि उनका अनुमान बंद है। :-)

Comments

इस उत्तर को पोस्ट करने के लिए धन्यवाद। हम इस सूची को एक चेक सूची के रूप में हाथ में रखेंगे ताकि यह सुनिश्चित हो सके कि हमारी नियोजन प्रक्रिया में न्यूनतम 'अज्ञात' है। मुझे लगता है कि इससे प्रोग्रामरों को भी इस सूची को पढ़ने में मदद मिलेगी। अगर मैं कर सकता था तो Ps मैं इसे बढ़ा दूंगा, लेकिन जैसा कि मैं नया हूं मेरे पास अभी पर्याप्त प्रतिष्ठा अंक नहीं हैं :)

— जॉन बी

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

— नील

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

— द मॉर्फ

Answer 3

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

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

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

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

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

मुझे आशा है कि वह मदद करेंगे!

Comments

परिशिष्ट: दोहराव का अनुमान लगाने के साथ प्रोग्रामर को कुछ समस्याएं हैं । मैं, कम से कम, पुनरावृत्ति से ऊब के साथ बहुत सारी समस्याएं हैं (जो कभी-कभी स्वचालन के खरगोश के छेद की ओर जाता है, एक अल्पकालिक समय सिंक जो लंबे समय तक भुगतान कर सकता है);)

— इजाका

@ इज़काटा, अगर प्रोग्रामिंग कॉपी और पेस्ट करने के बारे में होती, तो मैं इस व्यवसाय में नहीं आता। यह दोहराव की कमी है कि मैं अपनी नौकरी के बारे में आनंद लेता हूं। :)

— नील

Answer 4

कारणों में से एक अनुमान अक्सर रास्ता बंद होता है क्योंकि अनुमान वास्तव में काफी कठिन होता है और सिस्टम को बदलने के लिए अनुभव और ज्ञान की आवश्यकता होती है। अक्सर यह छोटे लोगों में बड़े कदमों को तोड़ने में मददगार होता है।

अब आप उन लोगों की बहुत संभावनाएं हैं जिनका मैं दो उल्लेख करूंगा:

• योजना पोकर
• PERT (कार्यक्रम मूल्यांकन और समीक्षा तकनीक)

योजना पोकर

यह छोटी फुर्तीली टीमों में काफी काम करता है।

विकिपीडिया से उद्धरण:

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

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

पीईआरटी

एक सटीक अनुमान देना अक्सर कठिन होता है। क्या आसान है एक संभावना देना है। PERT अनुमान के लिए 3 मानों का उपयोग करता है:

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

उन तीन अनुमानों को भारित करने से आपको अधिक विश्वसनीय अनुमान मिलता है।

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

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

वास्तव में PERT में इन पहलुओं का उल्लेख किया गया है, जो कि मैं संक्षिप्तता के लिए छोड़ देता हूं।

Comments

मैंने आँकड़ों का उपयोग करने पर विचार नहीं किया, लेकिन यह एक शानदार विचार है!

— नील

Answer 5

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

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

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

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

Answer 6

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

-पिस्टल ट्रैकर - कहानियों पर नज़र रखने और डाउन-टास्क को तोड़ने के लिए प्रोत्साहित करने के लिए शानदार कार्यक्रम, यह कहानियों में प्रवेश करने में जल्दी हल्का होता है और स्वचालित रूप से वेग को कम करता है। https://www.pivotaltracker.com/ ।

-दस्तावेज़ के लिए दस्तावेज़ के रूप में एक ही समय में कई उपयोगकर्ताओं को संपादन और चर्चा करना आसान है।

-एक कंपनी के लिए मैं काम करता था, हम एक-एक कहानी के लिए एक बैठक करते थे जो हमने शुरू की थी, इस बैठक में एक वरिष्ठ प्रोग्रामर को शामिल करना था क्योंकि वह यह देखते हुए बेहतर होगा कि कोई कार्य कितना समय लेगा। वह यह निर्णय लेने में भी बेहतर होगा कि किसी कार्य में मुश्किल हिस्सा क्या हो सकता है।

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

उम्मीद है की यह मदद करेगा