एक व्यक्ति के लिए सर्वश्रेष्ठ विकास पद्धति?

Question

मैं परियोजनाओं पर काम करने में बहुत समय बिताता हूं जिसमें मैं एकमात्र डेवलपर, परियोजना प्रबंधक, डिजाइनर, क्यूटी व्यक्ति (हां, मुझे पता है ... बुरा!) है, और कभी-कभी मैं भी ग्राहक हूं।

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

आप में से जो लोग अकेले काम करने में ज्यादा समय बिताते हैं, उनके लिए खुद को व्यवस्थित करने, बड़ी (एक व्यक्ति के लिए) परियोजनाओं को प्रबंधित करने और उत्पादकता को यथासंभव उच्च रखने का सबसे अच्छा तरीका क्या है?

Comments

टेस्ट-प्रथम और फुर्तीली या दुबला, और छोटी टीमों के लिए एक्सपी।

— ctrl-alt-delor

एक चीज हम खोजते हैं। इस विषय पर कई, कई सवाल हैं। उदाहरण के लिए programmers.stackexchange.com/questions/50658/… । ये सभी। programmers.stackexchange.com/search?q=solo+programmer

— S.Lott

मैं काम करने की इच्छा रखता हूं, मेरे पास काम करने के लिए कम से कम एक अन्य सक्षम डेवलपर है।

— ChaosPandion

एकल डेवलपर के लिए डिजाइन और विकास के तरीके की संभव नकल ।

— gnat

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

— रॉकलन

Answer 1

अपने लक्ष्यों की स्पष्ट सूची रखना महत्वपूर्ण है। सेल्फ-मैनेज्ड प्रोजेक्ट को संभालने के लिए फीचर रेंगना आसान है। टीडीडी "यह तब किया जाता है जब यह काम करता है" दृष्टिकोण सहायक होता है। यह आपको पूर्णतावादी बनने से रोकता है।

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

Comments

TDD दृष्टिकोण "यह तब होता है जब यह काम करता है" नहीं है। टीडीडी दृष्टिकोण "यह तब होता है जब यह काम करता है और कोड साफ होता है "

— बेंजामिन हॉजसन

टीडीडी दृष्टिकोण "यह तब होता है जब यह काम करता है और जारी किया गया है ।"

— माइक चेम्बरलेन

यह सॉफ्टवेअर है। यह कभी नहीं किया है। कुछ बिंदु पर आप बस उस पर काम करना बंद कर देते हैं। तब भी आप फिर से शुरुआत कर सकते हैं।

— कैंडिड_ओरेंज

Answer 2

यहां आप जाएं ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP अच्छी तरह से नीचे तराजू क्योंकि यह छोटी फोकस्ड टीमों के लिए इष्टतम है ..

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

केवल एक चीज जो आप किसी टीम में नहीं कर सकते थे वह है PairProgramming।

Answer 3

अगर आप सोलो वर्क कर रहे हैं। यहाँ सलाह हैं:

1. जितना हो सके कम स्तर के काम करें। जितना संभव हो उतने पुस्तकालय और उपकरणों का उपयोग करें, जिनमें आपको लगता है कि आप आसानी से कोड कर सकते हैं (ऐसा न करें, बस पुस्तकालय का उपयोग करें)।
2. ऊपर-नीचे का दृष्टिकोण अपनाएँ। केवल उन चीजों को कोड करें जिनकी आपको वास्तव में आवश्यकता है।
3. जब आप सार शब्द में कोई समस्या देखते हैं, तो Google पर खोजें और अकादमिक समुदाय से शोध पत्र का उपयोग करें जो पहले से ही साबित हो चुका है। आपको केवल उनके एल्गोरिथ्म को कोड करने की आवश्यकता है।
4. अपने सिस्टम को डिज़ाइन करें ताकि आप स्वतंत्र रूप से जितना संभव हो चीजों को बदल सकें। (यहां से वहां तक ​​कुछ कोड कॉपी और पेस्ट करें)। उद्देश्य यह है कि आप समय बचाएं जब आपको एहसास हो कि आपने गलती की है। जब आप गलती करते हैं तो आपको जितना काम फेंकना पड़ता है उसे कम से कम करने की कोशिश करें। कोड का एक टुकड़ा जिसे फेंकना पड़ता है (यहां और वहां से कॉपी-पेस्ट के बजाय) उस कोड को लिखने के समय की समानता।
5. बहुत सारे स्वचालित परीक्षण करें ताकि आप नियमित रूप से हर बार जब आप बदलाव करें तो प्रतिगमन परीक्षण कर सकें
6. अपने डिजाइन की जिम्मेदारियों को अलग करें (यानी युग्मन को कम करें)। जितना संभव हो चीजों को मॉड्यूलर बनाएं
7. डिबग करने के लिए डीबगर का उपयोग करें और दोष खोजने के लिए द्विआधारी खोज का उपयोग करें।
8. लगातार (स्पष्ट) युग्मन और सार्वजनिक तरीकों के जोखिम (निहित युग्मन) को कम करने के लिए अपने कोड को लगातार रिफ्लेक्टर करें।
9. कुछ भी सच नहीं। यह सिर्फ इस मामले में है कि मैं कुछ नया कर सकता हूं: पी

Answer 4

कोड समीक्षा।

ये विशेष रूप से उपयोगी हैं क्योंकि आप किसी ऐसे व्यक्ति को कोड समझा रहे होंगे जिसने एक ही परियोजना पर काम नहीं किया है, इसलिए उन्हें आपकी कोई धारणा नहीं होगी कि यह कैसे काम करना चाहिए।

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

Answer 5

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

Answer 6

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

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

Answer 7

मैं आपको निम्नलिखित सुझाव देता हूं:

1. परीक्षण संचालित विकास
2. अपने कोड में "TODO: नोट नोट" का इवी उपयोग जब आप कुछ ऐसा देखते हैं जो आप तुरंत करने में सक्षम नहीं होते हैं, और उनके पास वापस आते हैं जब आपके पास समय होता है बजाय इसके कि आप फेसबुक पर रुकें अपने क्लाइंट को वापस बुलाने का इंतजार करें।
3. अपने कोड को लिखें क्योंकि आपका ग्राहक इसे केवल परिणाम पर नहीं कोड को देखकर खरीदेगा, एक कोड समीक्षा के लिए अध्यक्ष के रूप में अपने ग्राहक की कल्पना करें।
4. अपना कोड भरें

Comments

कृपया समझाएं "कृपया अपना कोड भरें" भाग?

— इकाॅनडिल्ली

Answer 8

काश मैं कह सकता हूं कि मैं अभ्यास करने में सक्षम था कि मैं समय का 100% क्या उपदेश देता हूं, लेकिन बीडीडी आपकी स्थिति में लेने के लिए एक अच्छा तरीका है:

यहाँ अधिक जानकारी के लिए एक लिंक है: http://en.wikipedia.org/wiki/Behavior_driven_development

Answer 9

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

Answer 10

मुझे लगता है कि ReSharper जैसे कोड फॉर्मेटिंग टूल का उपयोग करना सुनिश्चित करता है कि, कम से कम नेत्रहीन, कोड अन्य डेवलपर्स के लिए चुनना आसान है।

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

Answer 11

दर्शन: XP / TDD + GTD

सामान्य रूपरेखा:

• हितधारकों का साक्षात्कार करें
• स्क्रीन मॉकअप, वॉकथ्रू, पेपर प्रोटोटाइप (आवश्यक के रूप में)
• फ़ीचर / स्टोरी मंथन (हितधारकों के साथ और बिना)
• परीक्षण के मामले मंथन (हितधारकों के साथ और बिना)
• समग्र डिजाइन / वास्तुकला सोच-समय (आवश्यक के रूप में)
• यात्रा योजना (हितधारकों के साथ)
• पुनरावृत्तियों
• प्रक्रिया की समीक्षा, प्रशिक्षण, रखरखाव की योजना, आदि (आवश्यक के रूप में)

Comments

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

— विलियम पीट्री

@William अगर क्लाइंट कंबन को समझता है, या कोई क्लाइंट नहीं है, तो इसके लिए जाएं

— Steven A. Lowe

Answer 12

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

शायद अधिक दिलचस्प यह पूछना है कि क्या कार्यप्रणाली दूर नहीं फेंकनी चाहिए क्योंकि परियोजना पर केवल 1 व्यक्ति काम कर रहा है।

और मेरे लिए जो प्रमुख है वह है सोर्स कंट्रोल (हाँ यह एक उपकरण है, लेकिन यह आपके कार्य प्रवाह का हिस्सा है, इसलिए यह एक प्रक्रिया भी है)। लोगों को यह देने के लिए लुभाया जा सकता है क्योंकि वे "एक ही समय में कोड को संपादित करने वाले कई लोगों का समर्थन करने की आवश्यकता नहीं है"।

विडंबना यह है कि मुझे लगता है कि जीआईटी जैसा एक वितरित संस्करण नियंत्रण समाधान एक व्यक्ति के लिए बेहतर है कि एसवीएन जैसा कुछ।

Answer 13

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

अगले आदमी को पढ़ने के लिए अपना कोड लिखें, न कि आप ... उसके साथ अच्छा व्यवहार करें। यहां तक ​​कि "थ्रो दूर" कोड हमेशा के लिए रहता है।

Answer 14

चुस्त

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

पुनरावृत्तियों के बीच काम बंद करना भी आसान है।

Answer 15

एक सलाहकार के रूप में मेरे स्व, मैं सुझाव दूंगा कि आप किसी भी काम पर कम से कम दो डेवलपर्स होने के लिए हमेशा एक रास्ता खोजें।

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

Answer 16

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