एक भी प्रोग्रामर के लिए घोटाला? [बन्द है]


31

मुझे मेरी बहुत छोटी कंपनी में "विंडोज एक्सपर्ट" के रूप में बिल दिया गया है, जिसमें खुद, एक सेल्स एंड ट्रेनिंग रोल में काम करने वाले मैकेनिकल इंजीनियर और एक डिजाइन, डेवलपमेंट और सपोर्ट रोल में काम करने वाली कंपनी के प्रेसिडेंट हैं।

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

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

यदि यह है, तो आप सिर्फ एक प्रोग्रामर के उपयोग के लिए स्क्रम को अपनाने का सुझाव कैसे देंगे? क्या उपकरण, क्लाउड-आधारित या अन्यथा, उस छोर तक उपयोगी होगा?

यदि यह नहीं है, तो आप किसी एकल प्रोग्रामर को अपने प्रयासों को दिन-प्रतिदिन व्यवस्थित करने के लिए क्या सुझाव देंगे? (शायद यह प्रश्न उस सरल प्रश्न को कम कर देता है।)


पॉडकास्ट यूआरएल साझा करने के लिए देखभाल? ; ओ)
जॉन ऑनस्टॉट

है ना? क्या पॉडकास्ट?
रोब पेरकिंस

मुझे लगता है कि वह इसका मतलब है वेब डाली;)
प्रहार

ओह, क्षमा करें, नहीं, मैं नहीं कर सकता। यह गो-मीटिंग द्वारा, एक-आमंत्रण कार्यक्रम के रूप में पेश किए गए उन वन-ऑफ्स में से एक था।
रोब पर्किंस

ऐसी विडंबना। 3 1/2 वर्षों के बाद "बहुत व्यापक" के रूप में बंद, जहां अंतिम गतिविधि केवल उससे थोड़ी कम पुरानी थी। और यह अभी भी उत्थान हो रहा है!
रोब पेरकिंस

जवाबों:


14

स्करम जानें: हाँ। यदि केवल इसके बारे में जानने के लिए अपने सामान्य कौशल सेट में जोड़ें। (लेकिन इसका एक स्वाद "स्क्रम-प्रतिबंध" शायद वही है जो आप खोज रहे हैं ...)

स्क्रैम एक अच्छा ढांचा है, लेकिन एक मुख्य सिद्धांत है "Iterations (स्प्रिंट्स) की निश्चित अवधि होगी" मैंने इस काम को कभी भी बहुत छोटी टीमों में नहीं देखा है जो कि अधिक से अधिक बाधित नहीं हैं। यदि आप एक निश्चित समय बॉक्स (1 सप्ताह?) में काम करने के लिए सही मायने में साइन अप कर सकते हैं, तो स्क्रैम एक अच्छा ढांचा है। यदि आप नहीं कर सकते ... तो स्क्रैम के बारे में जानकर अच्छा लगा क्योंकि इसमें कुछ अच्छी अवधारणाएँ हैं जो अन्य चीजों के साथ अच्छी तरह से अनुवाद करती हैं ... जैसे ...।

बैकलॉग - स्क्रैम या नहीं, उन चीजों की प्राथमिकता सूची रखें जिन्हें आपको करने की आवश्यकता है। मुझे एक्सेल (या Google डॉक स्प्रेडशीट ...) पसंद है आप कुछ और पसंद कर सकते हैं। यदि आप बहुत छोटी टीम हैं तो मैं एक बहुत छोटा उपकरण रखूंगा। (स्प्रेडशीट >> वर्ड प्रोसेसर क्योंकि आप आसानी से सॉर्ट कर सकते हैं।)

प्लानिंग और कमिटेशन का पृथक्करण - एक अमूर्त अंकन (अंक) में योजना और सुसंगत होना (8 अक्षर 2x के बारे में एक 4pt कहानी और 4x एक 2 बिंदु कहानी है) जब "काम" समय पर समस्या को देखते हैं और स्केच करते हैं घंटों में। अंक मत बदलो।

प्रतिबद्धता - जब आप प्रतिबद्ध होते हैं, तो दूसरों को दिखाई देते हैं और अपनी प्रतिबद्धताओं को पूरा करते हैं

पूर्वव्यापी - आपके द्वारा वितरित किए जाने के बाद, इस पर प्रतिबिंबित करें कि क्या बेहतर किया जा सकता था।

आदि आदि।

स्क्रम काफी आसान है यह समझने के लिए कि यह एक अच्छा प्रारंभिक बिंदु हो सकता है। यदि आप इसे पसंद करते हैं, तो मैं "स्क्रम-प्रतिबंध" संस्करण का उपयोग करने पर विचार करूंगा - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban । इसके समर्थन के लिए एक और सक्रिय समुदाय के साथ और कुछ भी मुझे "इतनी अच्छी तरह से प्रलेखित" नहीं करता है।

मुझे एलिस्टेयर कॉकबर्न की क्रिस्टल कार्यप्रणाली (http://alistair.cockburn.us/Crystal+methodologies+main+foyer और http://www.amazon.com/Crystal-Clear-Human-Powered -Methodology- की सिफारिश करना अच्छा लगेगा छोटे / डी पी / 0201699478 / रेफरी = ntt_at_ep_dpt_3 ), लेकिन इसमें अधिक पढ़ने और खुदाई करने का तरीका शामिल है।

XP जैसी चीजें विशिष्ट प्रथाओं पर अधिक विवरण प्रदान करती हैं, इसलिए मैं कहूंगा कि पुस्तक पढ़ें: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1s= पुस्तकें और यानी = UTF8 और QID = १३०४३५९८३४ और एसआर = 1-1

अंतिम पढ़ने की सलाह: जब तक आप एजाइल घोषणापत्र से सहमत होते हैं, और सिद्धांतों का पालन करते हैं: http://agilemanifesto.org/principles.html आपको सभ्य आकार में होना चाहिए।


व्यक्तिगत अनुशंसा: TDD (गैर-परक्राम्य, IMHO) को अपनाएं। एक बैकलॉग बनाए रखें (स्क्रैम के अनुसार) हमेशा इसे आकार में रखें और प्राथमिकता पर हल करें "रुकावटों के बीच करने के लिए चीजों को बहुत बड़ा करें" अंतर छोटे चक्रों को किसी ने निर्धारित किया है / समीक्षा प्राथमिकता (कोई नहीं) दो वस्तुओं को एक जैसी प्राथमिकता मिलती है। आपका ग्राहक इससे सहमत है। ढेर के ऊपर से कहानियों को खींचो और उन पर काम करो क्योंकि आप वर्तमान कहानी को पूरा करते हैं किसी भी एक समय में 2 से अधिक चीजें खुली न रखें। दूसरे को शुरू करने से पहले एक व्याकुलता को समाप्त करें।

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


यह मदद करता है, लेकिन आपको "कहानियों" से क्या मतलब है?
रोब पेरकिंस

क्षमा करें, एक "कहानी" एक "उपयोगकर्ता कहानी" या पर्याप्त विवरण में वर्णन है कि ग्राहक क्या हासिल करना चाहता है (एक अर्थ में आवश्यकताओं का संग्रह)। आम तौर पर ये "As a << उपयोगकर्ता भूमिका >> I want << फ़ीचर >> को प्राप्त करने के लिए << व्यापार लक्ष्य >>" विकिपीडिया का अच्छा सारांश है: en.wikipedia.org/wiki/User_story
Al बिगलान

अच्छा जवाब। क्या आप स्क्रैम-प्रतिबंध पर किसी अन्य संसाधन की सिफारिश कर सकते हैं?
बेंटसाई

पृष्ठभूमि जानकारी के लिए Google खोज से परे कुछ भी नहीं। मुझे यह पसंद आया: infoq.com/articles/hiranabe-lean-agile-kanban और यह: leansoftwareengineering.com/ksse/scrum-ban सामान्य रूप से इसे आज़माएं और इसे
सुधारें

13

आप Scrum में उपयोग की जाने वाली कुछ प्रथाओं का उपयोग कर सकते हैं जैसे उत्पाद बैकलॉग, प्राथमिकता, सापेक्ष अनुमान, वृद्धिशील वितरण लेकिन स्व-संगठित क्रॉस फंक्शनल सदस्यों की एक टीम द्वारा उत्पाद विकास के प्रबंधन के लिए एक प्रक्रिया के रूप में पूरे Scrum का उपयोग करना शायद एक आदमी दिखाने के लिए नहीं है। ।

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


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

2
छोटे प्रोजेक्ट प्रोग्रामर के
।stackexchange.com

नहीं नहीं। एक प्रोग्रामर। बड़ी परियोजना।
रोब पर्किंस

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

@ रब: मेरी राय यह है कि जब टीम एक ही साइट पर नहीं होती है तो स्क्रम काम नहीं करता है - स्क्रम स्टैंड-अप नहीं कर रहा है। निरंतर सहयोग और संचार के बारे में स्क्रेम अधिक है।
लादिस्लाव मृंका

5

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

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


यह सामान्य रूप से अच्छा है, लेकिन वास्तव में इतना खास नहीं कि मेरा मार्गदर्शन कर सके। मैं हालांकि इन शब्दों को गूगल करूंगा।
रोब पेरकिंस

@ रब: यदि आप कंबन के बारे में कुछ जानना चाहते हैं, तो सबसे अच्छा स्रोत एक पुस्तक है: डेविड जे एंडरसन द्वारा
कानाबन

5

मैंने यह कोशिश की जब मैं एक बिंदु पर अकेले काम कर रहा था। अच्छी तरह से काम करने वाली चीजें थीं:

  1. एक व्हाइटबोर्ड पर सभी काम-आइटम होने। मैं बहुत जल्दी देख सकता था कि वहाँ क्या उत्कृष्ट काम था; जहां निर्भरता और रुकावटें थीं। इसके अलावा, बहुत सारे लोग मेरे बोर्ड को बंद कर देते हैं और इसे पढ़ते हैं - और हम इसके बारे में बातचीत करेंगे। मुझे लगता है कि इससे उन्हें यह समझने में मदद मिली कि "गीक" पूरे दिन क्या कर रहा था ;-)
  2. बर्न-डाउन चार्ट भी बहुत अच्छा था। मैंने इसके लिए सिर्फ एक्सेल का इस्तेमाल किया। इसने मुझे उस माहौल में अनुमान लगाने में बेहतर होने दिया। इसने मुझे एक महान अवलोकन दिया जहां मैं पुनरावृत्ति के साथ जा रहा था। मेरा प्रबंधक, जो एक तकनीकी व्यक्ति नहीं था, उसे भी यह पसंद था क्योंकि वह एक फीचर में शामिल सभी अलग-अलग चीजों को देख सकता था, और जहां वे थे।
  3. दैनिक स्टैंड अप। खैर मैं सबसे अच्छा कर सकता था। प्रत्येक सुबह, मैंने सभी कार्य-आइटम और बर्न-डाउन चार्ट को अपडेट किया और सभी बाधाओं का नोट किया, जिन्हें हल करने की आवश्यकता थी।
  4. स्वचालित परीक्षण और निरंतर एकीकरण (MSTest / TFS), अधिमानतः TDD, किसी भी कार्यप्रणाली का उपयोग करने में किसी भी विकास टीम की मदद करेगा - लेकिन यहाँ ध्यान देने योग्य है।
  5. लघु पुनरावृत्तियों (1 सप्ताह) ने वास्तव में मुझे कुछ वितरित करने पर ध्यान केंद्रित करने में मदद की।
  6. एक बैकलॉग को बनाए रखना बहुत अच्छा था क्योंकि जब मुझे नया काम दिया गया था तो मैं इसे अन्य सभी कामों के संदर्भ में रखने और उत्पाद के मालिक को फिर से प्राथमिकता देने में सक्षम था।

क्या काम नहीं किया गया था:

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

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

मुझे लगता है कि सभी को बैक-लॉग रखना चाहिए, और हालांकि टीडीडी करना चाहिए।


+1: "मुझे लगता है कि सभी को बैक-लॉग रखना चाहिए और टीडीडी करना चाहिए" - 100% सहमत हों। टीडीडी के बिना स्क्रम केवल अंततः स्प्रिंट में देर से फसल लगाने वाले कीड़े के कारण झरना में वापस आ जाता है।
ब्रुक

2

एजाइल / स्क्रैम / कंबन के तत्व जो मुझे लगता है कि एक ही डेवलपर की दुनिया में मायने रखते हैं:

  1. एक बोर्ड है जिस पर आप अपनी उपयोगकर्ता कहानियों / सक्रिय-बैकलॉग-आइटम, कोनबन की तरह, इंडेक्स कार्ड पर व्यवस्थित करते हैं।

  2. इन सिद्धांतों के मूल्य पर गैर-डेवलपर्स से खरीदें-इन करें:

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

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

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

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

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


2

मैंने इस बारे में कुछ ब्लॉग पढ़ा है और मुझे लगता है कि यह आपके प्रश्न में आपकी मदद कर सकता है।

पहला भाग: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

दूसरा भाग: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day8/

आपको इस ब्लॉग पर कुछ और जानकारी मिल सकती है।

मैं किसी भी तरह से जुड़ा नहीं हूं; बस मेरे पसंदीदा में कुछ था। आशा है कि यह आपकी मदद कर सकता है।


1

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


5
इसलिए आप रॉब से कह रहे हैं कि वह 15 मिनट तक खुद के साथ बैठक करें ;-)
LRE

3
जिन लोगों को यह गलत लगता है और घोटाले के बारे में सोचते हैं, उनकी छोटी-मोटी मीटिंगें होती हैं, जो मुझे रोज चकित करती हैं ...
डग

1
हा! मैं काम के लिए एक स्टैंड-अप डेस्क का उपयोग करता हूं, इसलिए, y'know, यह सब ओर्थोगोनल नहीं है ...
रोब पर्किन्स

1
15 मिनट खड़े हो जाओ => स्वयं की जांच?
ओनेसिमसबाउंड

1
मैं कैसे काश मैं प्रतिनिधि के 125 था ...
speeder

1

इनमें से बहुत सारे उत्तर एक महत्वपूर्ण बिंदु को याद कर रहे हैं।

एक टीम को शुद्ध रूप से प्रोग्रामर से बाहर करने की आवश्यकता नहीं होती है।

आपका एक सहकर्मी 'डिजाइन' / 'विकास' करता है और एक 'बिक्री' करता है।

शायद आपकी 'बिक्री' सहकर्मी उत्पाद स्वामी (प्रॉक्सी) हो सकती है। ग्राहक की उम्मीदें क्या हैं?

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

आप तीनों के साथ स्क्रैम प्रक्रिया कर सकते हैं।

'यह ’करने के लिए क्या करना पड़ता है? स्क्रम की स्प्रिंट नियोजन बैठकें इस प्रश्न पर ज़ूम करती हैं कि यह क्या है। उत्पाद के मालिक को इसके लिए क्या देखने की उम्मीद की जाती है?

स्प्रिंट प्लानिंग मीटिंग के दौरान आप अपने अन्य सहयोगियों को इस बात का संदर्भ दे सकते हैं कि 'उत्पाद का अंतर्राष्ट्रीयकरण और स्थानीयकरण' तकनीकी रूप से लागू करने में मुश्किल क्यों हो सकती है।

स्कोर्स इम्हो का उपयोग करने के कई कारण।


1

मैं सुझाव देता हूं कि कानबन की कोशिश करना, और मूल बातें शुरू करना: दृश्य और कार्य-प्रगति (WIP) को सीमित करना।

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

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

आपके संदर्भ के लिए मेरे पास कुछ विचार हैं:

  • दृश्यता कुंजी है, इसलिए यदि आप इसे (बड़ी) स्क्रीन पर स्थायी रूप से (यदि आप सह-स्थित हैं) प्रदर्शित नहीं कर सकते, तो डिजिटल टूल की तुलना में भौतिक व्हाइटबोर्ड का उपयोग करें
  • अपनी वर्तमान प्रक्रिया से शुरू करें
  • केवल अपस्ट्रीम और डाउनस्ट्रीम हैंड-ऑफ फेज (आपके लिए कतार बन जाना, जैसे, देव के लिए तैयार की गई विशेषताएं, या आप से कतार, उदाहरण के लिए, तैयार विशेषताएं, बिक्री के लिए तैयार) सहित अपने प्रभाव क्षेत्र के साथ शुरू करें।
  • यदि आपके सहकर्मी दृश्य अपस्ट्रीम या डाउनस्ट्रीम, सभी बेहतर का विस्तार करने में रुचि रखते हैं। हो सकता है कि आप अपनी कंपनी के लिए संपूर्ण मूल्य धारा (या नेटवर्क) की कल्पना कर रहे हों, यानी कि मूल्य अवधारणा से नकदी तक कैसे प्रवाहित होता है
  • WIP को सीमित करके मल्टीटास्किंग (!) कम करें। यदि आपके सहयोगियों को काम का प्रवाह दिखाई देता है, तो उन्हें समझना चाहिए कि क्यों, और आसानी से देखें कि आपकी प्लेट में क्या है
  • शायद यह काम को 3 या 4 कार्य प्रकारों (सेवा की कक्षाओं) में अलग करने के लिए उपयोगी होगा, जिनकी उन पर अलग-अलग मांगें हैं: f.ex. बग, महत्वपूर्ण मुद्दे, काम w / कठिन समय सीमा, बिना समय सीमा के काम करते हैं
  • निरीक्षण करें कि आपका काम कैसे बहता है, उदाहरण के लिए, अगर आपको कहीं पर अड़चनें आती हैं, या काम अवरुद्ध हो जाता है या आप कुछ पूर्वानुमानित पैटर्न में काम के लिए "भूखे" रहते हैं। यह लंबी अवधि के लिए आसान है यदि आप डिजिटल टूल का उपयोग करते हैं, तो मेरी कुछ अंतिम स्लाइड्स को देखें।
  • कदम से कदम काम के प्रवाह में सुधार

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


0

यहाँ अन्य सभी उत्तरों को पढ़ने के बाद, मुझे लगता है कि सरल व्यावहारिक उत्तर है:

प्रक्रियाओं या तकनीकों या विधियों का उपयोग करें जो कुछ सीखने के लिए उपयोग में हैं जो आपको अपना काम बेहतर तरीके से करने में मदद करेंगे।

अब इसका अर्थ आपके कार्यों को प्राथमिकता देना हो सकता है - हर दिन - धार्मिक रूप से।

यह बैकलॉग बाहर काम करने के लिए हो सकता है।

इसका मतलब हो सकता है प्रगति को रिपोर्ट करना - अपने बॉस को (भले ही वह परवाह न करे ... ऐसा करना मानसिक रूप से आपको जहाँ आप हैं, उसका जायजा लेने की अनुमति देना अच्छी बात है)।

आप सभी प्रकार के तरीकों या तकनीकों का उपयोग कर सकते हैं क्योंकि वे अंततः आपको बेहतर काम करने देते हैं, जो रात में बेहतर नींद लेते हैं।

सामान है कि काम करता है (आप के लिए, अपने वर्तमान परिस्थितियों में), सामान है कि नहीं है त्यागें।


0

जब तक आपके पास निम्न स्थान न हो

  • आने वाली आवश्यकताओं को व्यवस्थित करने और प्राथमिकता देने का मतलब है।

  • सटीक रूप से किए गए प्रयास का अनुमान लगाने के लिए ताकि आप जान सकें कि आप एक पुनरावृत्ति में क्या कर सकते हैं

  • Iterations और Continuous Improvement - पुनरावृत्तियों की अवधारणा जिसमें कोई लगातार निरीक्षण और अनुकूलन कर रहा है, वह अमूल्य है। यह अभ्यास प्रयोग को प्रोत्साहित करता है और यह निरंतर सीखने में बनाता है। चर्च में घोटाला, पृष्ठ 4

  • ठीक है, आप एक दैनिक बैठक नहीं कर सकते हैं, लेकिन कम से कम आप अपने आप को उस कार्य की याद दिला सकते हैं जो आप आज करेंगे। डेली स्क्रेम मीटिंग का उपयोग किया जाता है ताकि टीम एक दूसरे के साथ तालमेल बिठा सके कि वे क्या कर रहे हैं।

  • स्प्रिंट के बाद परावर्तन - स्क्रेम में इसे स्प्रिंट रेट्रोस्पेक्टिव कहा जाता है, प्रत्येक पुनरावृत्ति के अंत में, आप पुनरावृत्ति के बाद क्या होता है, इस पर प्रतिबिंबित कर सकते हैं और सोच सकते हैं कि क्या गलत हुआ और आप इसे कैसे सुधार सकते हैं, उन्हें रखने के लिए सबसे अच्छा अभ्यास क्या है करते हुए

मेरा सुझाव है कि आप एक न्यूनतम दृष्टिकोण अपनाएं, और निरंतर सुधार से, आपके पास एक ऐसा घोटाला हो सकता है जो आपकी आवश्यकताओं के अनुरूप हो।

यदि आप इसे अपनी आवश्यकताओं के अनुसार फिट नहीं कर सकते हैं और अपनी वर्तमान स्थिति के अनुकूल नहीं हैं, तो स्क्रैम नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.