2010-01-08 14 views
9

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

क्या अन्य इस तरह के काम के लिए समर्पित उत्पाद बैकलॉग बनाते हैं? या इसे संभावित रूप से शिप करने योग्य होने की आवश्यकता के तहत मौजूदा आवश्यकताओं में रोल करें? या आप स्प्रिंट योजना के भीतर भी इसे शामिल नहीं करते हैं? वहां विभिन्न दृष्टिकोणों में रूचि है। धन्यवाद!

+1

यह प्रश्न ऑफ-विषय है क्योंकि यह इस साइट के दायरे में नहीं है, जैसा कि [मैं यहां कौन से विषय पूछ सकता हूं?] (// stackoverflow.com/help/on-topic) यह भी देखें: [क्या प्रश्नों के प्रकारों से मुझे पूछने से बचना चाहिए?] (// stackoverflow.com/help/dont-ask) आप [अन्य स्टैक एक्सचेंज साइट] (// stackexchange.com/sites#name) पर पूछने में सक्षम हो सकते हैं, उदाहरण के लिए [ pm.se] या [softwareengineering.se]। किसी भी साइट पर किसी प्रश्न को पोस्ट करने का इरादा रखने के लिए सहायता केंद्र में विषय-वस्तु पृष्ठ को पढ़ना सुनिश्चित करें। – Makyen

उत्तर

7

एक कहानी के लिए आदेश में "किया-हो गया", यह शिप करने योग्य होने की जरूरत है, जो भी शामिल है सिर्फ परीक्षण नहीं किया लेकिन यह भी तैनात किए गए और कॉन्फ़िगर के रूप में माना जा सकता है।

आप बुनियादी सुविधाओं को पहले से ही तो स्थापित इस कहानी के लिए अपने अनुमान में शामिल किया जाना चाहिए।

यदि आपके पास बुनियादी ढांचा नहीं है, तो बिल्ड स्क्रिप्ट और तैनाती प्रणाली का निर्माण अपने ही अधिकार में एक कहानी है: सिवाय इसके कि यहां "ग्राहक" डेवलपर या इंफ्रास्ट्रक्चर लड़का है, डेवलपर नहीं।तो:

डेवलपर के रूप में, मुझे XYZ एप्लिकेशन को तैनात करने और सत्यापित करने की आवश्यकता है कि यह इसके कार्यात्मक परीक्षणों को पारित करे ताकि हम अन्य कहानियों को पूरा कर सकें।

इस संदर्भ में पूरी तरह स्वीकार्य कहानी होगी।

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

2

मुझे प्रश्न में "खो गया" समझ में नहीं आता है। यह काम आपको करना चाहिए। तो यह कैसे खोया जा सकता है?

Agile के पीछे "सिद्धांत" यह है कि आपके पास परिपक्व आधारभूत संरचना है।

दो अलग-अलग बुनियादी ढांचे के मुद्दे हैं।

  • नया आधारभूत संरचना बनाना।

  • मौजूदा आधारभूत संरचना का उपयोग करना।

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

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

कुछ चीजें (जैसे हमारी नई फ़ायरवॉल) ने कुछ रिलीज में वास्तविक जटिलताओं को फेंक दिया।

लेकिन आम तौर पर, कॉन्फ़िगर और डिप्लॉयमेंट - परिपक्व बुनियादी ढांचे की तरह - आधारभूत होते हैं। वे पहले से ही आपकी प्रक्रिया का हिस्सा हैं। आप पहले से ही कर रहे हैं। वे "खो" कैसे हो सकते हैं?

"प्रयास खोने का प्रयास" से आपका क्या मतलब है? "खोया" मतलब क्या है? आप जानते थे कि आपको यह करना है। तुमने यह किया। क्या खो गया है


संपादित करें। यह विचार है कि इस बार "खो गया" या "दिखाई नहीं दे रहा है" या "प्रभाव" या सामान्य रूप से व्यवसाय के अलावा कुछ भी अन्य टिप्पणियों के बावजूद, कोई समझ नहीं आता है।

यह सिर्फ सामान है जो आप करते हैं। यह रिलीज का हिस्सा है। यह सिर्फ काम की तरह है, विकास की तरह, आप बस करते हैं।

"माइग्रेशन का एक दिन लंबा समय है" लेकिन अगर ऐसा होता है, तो यही वह होता है। आप बस इसके लिए अनुमति देते हैं। यह केवल एक कार्य है जिसे आप हर रिलीज के साथ करते हैं।

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

+0

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

+0

एक दिन? आपकी दौड़ कितनी देर तक हैं? 2 सप्ताह? फिर यह 10% है। शायद कोई परवाह करता है। यदि आपकी दौड़ 4 से 6 सप्ताह हैं; तो यह 5% है। शोर। –

+0

आम तौर पर स्पिंट्स कुछ हफ्तों होते हैं और हम आम तौर पर प्रयास (अनुमानतः!) पर प्रयास करने और अनुमान लगाने का प्रयास करते हैं, इसलिए 10% उल्लेखनीय है। प्रवासन का एक दिन एक लंबा समय है और निश्चित रूप से यह हमेशा मामला नहीं है। यह लंबे समय तक क्यों हो सकता है कि यह एक "कॉर्पोरेट" वातावरण है इसलिए दस्तावेज़, अनुमोदन, प्रक्रियाएं इत्यादि। –

4

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

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

मुझे लगता है कि यह प्रासंगिक है: http://joelonsoftware.com/articles/SetYourPriorities.html - विशेष रूप से अंत जहां वह सुविधाओं को प्राथमिकता देने के लिए अपनी विधि की रूपरेखा की दिशा में।

साक्ष्य आधारित शेड्यूलिंग पर यह लेख भी प्रासंगिक लगता है: http://joelonsoftware.com/items/2007/10/26.html

0

हम दो दृष्टिकोण का उपयोग करें। ऐप को तैनात करने जैसी चीजें उपयोगकर्ता की कहानी के जीवनकाल में शामिल हैं। जब यह तैनात किया जाता है तो कहानी पूरी की जाती है।

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

2

कोई भी डेवलपर समेत उत्पाद बैकलॉग में जोड़ सकता है, लेकिन इसके उत्पाद मालिकों का निर्णय है कि काम का टुकड़ा क्या होता है।

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

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

आप एक refactor कार्य वास्तव में है कि सुचारू रूप से तो मुझे लगता है कि होगा जारी रखने के लिए वहाँ उत्पाद बैकलॉग में कुछ ऐसा है जो इस refactor करने के लिए पीठ पर सूअर का बच्चा और कर सकता है विकास को सक्षम करने के लिए किया जाना है, तो है कि बैकलॉग आइटम के लिए अनुमान इसे प्रतिबिंबित करना चाहिए।

0

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