चंचल (जमघट, एक्सपी, FDD, ...), झरना, RUP, ... क्यों एक छोटी सी कंपनी पहली जगह में एक गोद लेने परेशान करेगा। क्यों न केवल प्रत्येक परियोजना को पूरा करने के लिए हैक-दूर (एक सामान्य टीम आकार 1 ~ 2 के साथ)।एक सॉफ्टवेयर विकास प्रक्रिया क्यों अपनाने?
मैं तर्क के खिलाफ एक छोटी प्रस्तुति की तैयारी कर रहा हूँ, लेकिन क्या हर कोई सोचता है कि सुनना पसंद करेंगे।
ऊह, प्रश्न का मेरा पसंदीदा प्रकार। जब भी एसडीएलसी आता है, उचित उत्तर हमेशा होता है, "यह निर्भर करता है!" :) मैं उस उत्तर से जितना ज्यादा नफरत करता हूं, तो चलो गहरी खुदाई करें।
अपनी परियोजनाओं एक व्यक्ति द्वारा प्रबंधनीय और बहुत ही कम है (यानी < 3 महीने) कर रहे हैं तो कोई औपचारिक प्रक्रिया को शायद समझ में आता है। कुछ प्रक्रियाओं के प्रिंसिपल महत्वपूर्ण हैं, लेकिन अधिकांश समारोह सुरक्षित रूप से गिराए जा सकते हैं। उदाहरण के लिए, जिस तरह के एक चंचल-y प्रकार में, मैं अभी भी कार्ड है कि तकनीकी कहानियों था (एक वाक्य या तो), उपयोगकर्ता कथाएँ (एक वाक्य या दो), कार्य, आदि तो मैं कुछ भी पर गेंद ड्रॉप नहीं होगा ट्रैक करना चाहते हैं । मैं केवल रोलिंग-लहर, जरूरी पुनरावृत्ति नहीं करता। यदि आपको पता है कि बीटा/पूर्वावलोकन/जो भी हो, उसके लिए आपके पास कुछ कठिन तिथि है, तो आप सप्ताह-दर-सप्ताह काम कर रहे कार्ड की प्राथमिकता चुनकर तदनुसार अपनी लहर की योजना बना सकते हैं।
कुछ प्रक्रिया होने का एक लाभ यह है कि आप कुछ योजना/प्रबंधन कलाकृतियों (पूर्ववत कार्ड, बैकलॉग इत्यादि) छोड़ देंगे ताकि अगर आपको या किसी और को परियोजना पर विकास फिर से शुरू करने की आवश्यकता हो, तो आप इसे और अधिक चुन सकते हैं आसानी से।
एक परियोजना 6mo और 2 या अधिक लोगों के साथ निश्चित रूप से इस प्रक्रिया में किसी प्रकार का भी अराजक और टीम के सदस्यों के बीच सिंक से बाहर निकलने से बातें रखने के लिए होना चाहिए। टास्क कार्ड और जवाबदेही के रूप में यहां स्टैंड-अप महत्वपूर्ण हैं।
इस सामग्री के सभी, वैसे, परियोजना प्रबंधन/प्रक्रिया है। यहां तक कि 1-मैन टीम पर भी, मैं अभी भी स्रोत नियंत्रण, निरंतर एकीकरण, टीडीडी इत्यादि का उपयोग करता हूं। यह गुणवत्ता सॉफ्टवेयर के लिए एक आवश्यकता है, भले ही आप कार्य असाइनमेंट के लिए किस प्रक्रिया का उपयोग कर रहे हों।
"हैकिंग दूर" एक विकास प्रक्रिया है, यह केवल इतना नहीं है जिसे आसानी से ट्रैक किया जा सकता है या भविष्यवाणी की जा सकती है!
प्रक्रिया की बात स्थिरता और पूर्वानुमान
सत्य। जबकि सॉफ़्टवेयर इंजीनियरिंग पुनर्विक्रय अभी भी काफी हद तक अप्रत्याशित हैं, एक ऐसी पद्धति के बाद जो "आपकी सामग्री का परीक्षण करें" कहती है, चीजों को और अधिक अनुमानित रूप से उत्पन्न कर सकती है :) –
@chadmyers का जवाब बहुत बेहतर है। एक चेकलिस्ट/बैग-ओ-ट्रिक्स एक कठोर 'पद्धति' –
संगति कुंजी है। आप बस "दूर हैकिंग" परियोजना से परियोजना जाना है, तो यह एक सहकर्मी (या विशेष रूप से एक नए कर्मचारी) एक लंबा समय लग एक परियोजना पर लाने के लिए, अगर तुलना में वहाँ जगह में मानकों और परंपराओं हैं आने के लिए होगा। यह वास्तव में कोई फर्क नहीं पड़ता कि आप कौन से मानक/पद्धति को चुनते हैं, बस जब तक आप अपनी टीम के लिए काम करेंगे, और इसे लगातार इस्तेमाल करेंगे।
की तुलना में कहीं अधिक लचीला है लेकिन इस तरह के मामले में 'ढांचा' अधिक प्रासंगिक नहीं होगा? – tamersalama
"दूर हैकिंग" प्रक्रिया वितरित करने के लिए है कि उनके ग्राहक चाहता है और एक लागत ग्राहक के साथ खुश है के लिए, कंपनी के किसी अन्य प्रक्रिया को अपनाने के लिए, स्पष्ट रूप से परेशान नहीं करना चाहिए छोटी सी कंपनी की अनुमति देता है।
बेशकसमस्या यह है कि,, दूर हैकिंग भी एक छोटी सी कंपनी में इन परिणामों और अधिक कठिन उत्पादन करता है। इसके अलावा, अगर कंपनी या उसके अनुप्रयोग बढ़ने की सोच रहे हैं, तो हैकिंग तेजी से अस्थिर हो जाएगी।
आप परियोजना पर समय और संसाधनों का प्रबंधन करने के लिए एक सॉफ्टवेयर प्रक्रिया का उपयोग करें। 'दूर हैकिंग' एक भी व्यक्ति परियोजना जहां परवाह नहीं है कि तुम क्या उत्पादन overbudget, वितरित अतीत सब समय सीमा है और वास्तव में ग्राहकों की आवश्यकताओं को पूरा नहीं करता है, तो * के लिए ठीक है। उन परियोजनाओं के लिए जो इनके बारे में परवाह करते हैं, फिर एक सॉफ्टवेयर प्रक्रिया प्रबंधन की एक परत के रूप में पेश की जाती है।प्रबंधक तब विकासशील जीवन चक्र पर अधिक प्रभावशाली ढंग से निगरानी कर सकते हैं, महत्वपूर्ण, महत्वपूर्ण, आदि के रूप में पहचाने गए कार्यों पर ध्यान केंद्रित कर सकते हैं, ग्राहक को फीडबैक प्रदान कर सकते हैं कि वे किस चरण में हैं, और अन्य सभी चीजें जो डेवलपर्स के लिए महत्वहीन लगती हैं लेकिन प्रबंधकों और ग्राहकों को प्यार है क्योंकि यह दिखाता है कि हम वास्तव में कुछ ऐसा कर रहे हैं जो उन्हें लगता है उपयोगी है :)
* मैं यह सुझाव नहीं दे रहा हूं कि ये हमेशा हैकिंग के लिए परिणाम हैं या एक और संरचित प्रक्रिया उन्हें हटा देगी। उन्हें हैकिंग दूर विधि के 'उच्च जोखिम' क्षेत्रों को बेहतर ढंग से बुलाया जाता है और इसलिए एक परियोजना जो सिर्फ हैक्स और हैक और हैक बहुत ज्यादा परवाह नहीं करती है अगर वे होती हैं या नहीं :)
मुझे लगता है कि वही कारण है कार बनाने और घर बनाने के लिए एक प्रक्रिया है?
विकास प्रक्रिया को अपनाने से आप कितनी बार कह सकते हैं "ओह, इसके बारे में सोचना चाहिए"।
एक "दूर हैकिंग" परियोजना में विफल रहता है ऐसा होता है:
"lazy programmers, they should work harder""next time I will really do unit testing" या "we should have taken *this* tools or *that* language...""Bye everybody, I'm leaving"और अगर एक चल रहा है "हैकिंग दूर" परियोजना देरी, प्रबंधकों को परियोजना में अधिक लोगों को जोड़ने के लिए जाते हैं।
"I need this baby in a month send me nine women!" मुश्किल बात आपकी कंपनी और टीम के लिए एक मौजूदा प्रक्रिया अनुकूल करने के लिए है: there से कहावत है प्रक्रिया एकीकरण को पेश करना और मापना चाहते हैं
या नहीं, आप यह महसूस में)
प्रक्रिया सुधार प्रक्रिया की नींव है। प्रक्रिया को अपनाने का मुद्दा यह सीख रहा है कि व्यवस्थित तरीके से सुधार कैसे किया जाए ताकि सुधार टुकड़ों में काम को हिलाएं।
तथ्य यह है कि टीम में केवल दो लोग ही प्रवेश के लिए बाधा नहीं हैं। मैं लीन सिद्धांतों और कन्नबान का उपयोग उन परियोजनाओं पर भी करता हूं जो मैं एक व्यक्ति टीम के रूप में करता हूं। मैं इनसे लाभ उठा सकता हूं क्योंकि मैंने उनसे सीखा है, और उस सीखने से मेरा दिमाग अधिक उत्पादक होने के तरीकों से खोला गया था जिसे मैंने अतीत में नहीं माना था।
यदि आप पहले से ही महसूस करते हैं कि आपके पास सुधार करने के लिए कुछ भी नहीं बचा है, तो आपको संभवत: आप जो भी कर रहे हैं उसके बाहर प्रक्रियाओं को देखने की आवश्यकता नहीं है। यदि आप वास्तव में इस तरह महसूस करते हैं, तो विकास प्रक्रियाओं की खोज के अपने दिमाग में विचार रखने पर अपनी भावनात्मक स्थिति को विस्तार से देखें।यदि आप ऐसा करते हैं तो तनाव का सबसे छोटा क्षण भी होता है, तो आप काम से सीखने और दूसरों की खोज के लाभों के बजाय शामिल काम की धारणा से पीछे हट सकते हैं। उस तरह का अंतर्निहित मनोवैज्ञानिक रीकोल असामान्य नहीं है, लेकिन सार्थक प्रश्न का सामना करते समय इसका शायद ही कभी सहायक होता है।
मुझे लगता है कि स्वचालित रूप से 1-मैन टीमों के लिए भी स्वचालित जरूरतों को पूरा करने की आवश्यकता है क्योंकि यह लगभग बेकार है और इससे बड़ी परेशानी होती है। – rshimoda