2009-06-12 7 views
13

स्रोत नियंत्रण के बारे में सीखने के बाद मैंने पहली चीज svn के साथ एक परियोजना की है। गिट के बारे में सीखने के बाद मैंने इसे एक निजी परियोजना में इस्तेमाल किया। यूएमएल/डिजाइन पैटर्न/डिजाइन सिद्धांतों/टीडीडी के बारे में सीखने के बाद मैंने उन्हें एक निजी परियोजना में लागू किया। मैं फुर्तीली विकास के लिए भी ऐसा कैसे कर सकता हूं? सिर्फ टीमों और बड़ी परियोजनाओं के लिए चुस्त है? मैं इन पुनरावृत्ति चीजों को कैसे स्थापित करूं?निजी परियोजनाओं के लिए चुस्त कैसे लागू करें?

उत्तर

16

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

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

  • एक विकासवादी डिज़ाइन है: सरलतम चीज से शुरू करें जो संभवतः काम कर सकता है और बेकार ढंग से रिफैक्टर कर सकता है।

  • अंतिम जिम्मेदार क्षण तक निर्णय स्थगित करें।

  • स्प्रिंट या पुनरावृत्तियों में टाइमबॉक्स स्वयं (विश्वविद्यालय परियोजनाओं पर बहुत महत्वपूर्ण)।

  • ...

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

इस उत्तर को लिखते समय, कम से कम 3 अन्य उत्तरों आए और मुझे इसे हराया। मैं उन सभी के साथ सहमत हूं। :)

+0

आपने किस विश्वविद्यालय परियोजना की कोशिश की है। मैं इसे अपने चौथे वर्ष प्रोजेक्ट पर करना चाहता हूं (8 टीआई 16 महीने) के बीच हो सकता है। – kthakore

+1

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

+0

अच्छा विचार! आखिरी उचित पल तक स्थगित निर्णयों का क्या मतलब है। क्या यह दौड़ के अंत तक है? – kthakore

0

उदाहरण के लिए, यदि यह काम करता है, तो भी यह आपके कोड को दोबारा करने के लिए डरो मत, अगर परिणाम अधिक लचीला और मजबूत है।

+0

तो मैं पुनरावृत्तियों में प्रतिक्रिया करता हूं? या मैं पहले कुछ विशेषताओं को विकसित करता हूं, फिर उन पर फिर से जारी रहता हूं? – kthakore

+0

यूनिट आपके कोड का परीक्षण करें। * फिर * kmarsh की सलाह और रिफैक्टर ले लो। अक्सर एक विशेष कार्ड के अनुमान को ध्यान में रखा जाता है ताकि नई सुविधा छूने वाले कोड के क्षेत्र को दोबारा करने के लिए आवश्यक समय को ध्यान में रखा जा सके। – JeffH

2

एक व्यक्ति परियोजनाओं में वास्तव में फुर्तीली कोडिंग लागू करना मुश्किल है क्योंकि इसके कई लाभ छोटे टीमों के लिए लक्षित हैं जहां आप ध्यान केंद्रित क्षेत्रों पर तेजी से सहयोग कर सकते हैं।

कहा कि, आप तकनीक के कुछ गोद ले सकते हैं:

  • रिलीज अक्सर अपने उपयोगकर्ताओं की आवश्यकताओं पर
  • फोकस
  • मुख्य संस्करण की योजना से विचलित करने के लिए स्वतंत्र महसूस - आप दिशा बदल सकते हैं जब भी आप महसूस करें
  • प्रमुख ढांचे को स्थापित करने में कम समय बिताएं और जितनी जल्दी हो सके काम करें। फिर वापस जाएं और अपनी मूल जरूरतों को पूरा करने के लिए प्रतिक्रिया दें (यदि वे अभी भी लागू होते हैं)
+0

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

3

अपने आवेदन में इच्छित कार्यों और विशेषताओं की सूची बनाएं। उन कार्यों को ले लो और उन्हें card wall पर रखें।

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

+0

कहानियों के लिए कार्ड के साथ आने का एक तरीका है? TDD? डिजाइन और वास्तुकला कहां किया जाता है? – kthakore

+1

एक एकल व्यक्ति परियोजना के लिए, मैं फ़ीचर संचालित कहूंगा। डिज़ाइन किया जाता है जब आप जानते हैं कि आप किस सुविधा का निर्माण कर रहे हैं। –

1

एक व्यक्ति परियोजनाओं के लिए स्क्रम का उपयोग करना संभव है।

  • बैकलॉग
  • इष्टतम समय बनाएँ के लिए एक स्प्रिंट शुक्रवार को आधे दिन

है अगले सप्ताह और प्रत्येक परियोजनाओं के लिए हर आधे दिन अद्यतन burndowns के लिए योजना बना सकते हैं।

0

इस पर कुछ विचार:

  • पुनरावृत्ति की जब तक कि आप चाहें के रूप में होने के लिए
  • IPMS अभी भी संभव हो रहे हैं जहां आप यह चुन क्या आप समय की है कि लंबाई से अधिक करना चाहते हैं
  • अंत में डेमो आपके छोटे डिबगिंग क्षेत्र की बजाय कामकाजी कार्यक्षमता को देखने के लिए अभी भी उपयोगी हैं जो स्वच्छ या व्यवस्थित नहीं हो सकते हैं
  • रेट्रोस्पेक्टिव अभी भी यह देखने के लिए उपयोगी हैं कि क्या है और क्या काम नहीं कर रहा है अपने आप के लिए एक बिंदु पर जहां आप कर सकते हैं ई पेड़ों के लिए वन

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

0

यहां सभी सलाह अच्छी है, लेकिन एग्इल के एक महत्वपूर्ण पहलू हैं जो आम तौर पर अनियमित हो जाते हैं: निगरानी।

Agile आपको यह देखने के लिए कहता है कि आपने क्या किया है, आप क्या कर रहे हैं, आप कहां जा रहे हैं, और यदि आवश्यक हो तो उपयुक्त पाठ्यक्रम सुधार करें।

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

शुभकामनाएं।

+0

अच्छी परियोजना। ... मैं दृष्टिकोण का उपयोग नहीं करता ... क्षमा करें। अच्छा लगता है हालांकि मैं कुछ इसी तरह का निर्माण करूंगा और आशा करता हूं कि यह अन्य लोगों के लिए खुला स्रोत बनाये। – kthakore

2

जोड़ी के विकास के अलावा, यदि आप कई भूमिकाएं निभाने के इच्छुक हैं तो आप शेष अभ्यास कर सकते हैं। यदि आपके पास कोई ऐसा व्यक्ति है जो आपके साथ काम करने के इच्छुक है, तो आप जोड़ी विकसित कर सकते हैं।

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

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

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

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

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

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

डेवलपर के रूप में आपको निरंतर एकीकरण का उपयोग करना चाहिए, स्वचालित निर्माण आपके स्रोत कोड नियंत्रण प्रणाली में लगातार जांच के साथ लात मारी जाती है।

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

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

संबंधित मुद्दे