आप एम्बेडेड सिस्टम में स्क्रेम के साथ गैर-कार्यात्मक काम कैसे संभालते हैं?


15

मैं एम्बेडेड सिस्टम में Scrum के साथ दो मुद्दे हैं। सबसे पहले, कई कार्य करने हैं, विशेष रूप से शुरुआती चरणों में, जो प्रदर्शन नहीं हैं। हमने एक विकास बोर्ड, कोई ओएस, कोई प्रदर्शन, कोई सीरियल संचार आदि के साथ शुरुआत नहीं की। हमारे पास छह स्प्रिंट के लिए हमारा प्रदर्शन नहीं था।

पहले चार स्प्रिंट थे:

  • हो रही RTOS और चल
  • नेटवर्क और सीरियल ड्राइवर लिखने वाले कार्य बनाना
  • बटन, संचार, आदि के लिए रुकावट दिनचर्या लिखना
  • प्राथमिक डेटाबेस कक्षाओं और विधियों को लिखना
  • एक सीरियल डिबग मेनू लिखना

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

हमने "उपयोगकर्ता कहानियां" वाक्यांशों को समाप्त किया, जैसे कि, "एक डेवलपर के रूप में ...", जो कि मैं खुश नहीं हूं, लेकिन लक्ष्य प्रक्रिया (www.targetprocess.com) का उपयोग करने में, एक बैकलॉग आइटम की कोई अवधारणा नहीं है जो है एक कार्य या काम।

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

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

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

मुझे यह सुनना अच्छा लगेगा कि दूसरों ने इन स्थितियों को कैसे संभाला है।


2
चरण 1. एक ही प्रश्न के साथ अन्य लोगों के लिए खोजें। उदाहरण। stackoverflow.com/questions/5909533/… । यह एक बहुत ही सामान्य प्रश्न है।
लोट

यह मजेदार है कि लोग कितना समय और प्रयास करते हैं, जो एक विकास प्रक्रिया का पालन करने की कोशिश करते हैं, जो अंतिम परिणामों में कुछ भी नहीं जोड़ता है
स्टीव

जवाबों:


8

आप एक उत्पाद पर एक पद्धति का उपयोग कर रहे हैं जो संगत IMHO नहीं है।

जिस तरह से ज्यादातर लोग फुर्तीले को परिभाषित करते हैं, सभी कार्य बदलती प्राथमिकताओं, फिर से आदेश-सक्षम, या बदली के आधार पर परक्राम्य होते हैं।

जिस तरह से अधिकांश लोग झरने को परिभाषित करते हैं, वह यह है कि शुरुआत में एक महत्वपूर्ण वास्तुकला प्रयास से समय से पहले काम को क्रम से बाहर रखा गया है।

आपके द्वारा ऊपर सूचीबद्ध कार्य मुझे बहुत झरना लगते हैं। उन्हें एक निश्चित क्रम में होना चाहिए, और वे परक्राम्य नहीं हैं।

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

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


7

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

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

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

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


3
अंतिम उत्तर को छोड़कर, अच्छा उत्तर। डेवलपर्स भी उपयोगकर्ता हो सकते हैं, और कभी-कभी आपको टीम के अन्य डेवलपर्स का समर्थन करने के लिए काम करने की आवश्यकता होती है।
ब्रायन ओकले

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

1

आप एक बहुत ही विशिष्ट क्षेत्र में स्क्रैम का उपयोग करते हैं और आप हर कदम पर अपेक्षित प्रक्रिया का उल्लंघन करते हैं। आपका प्रश्न संभवतः होना चाहिए: क्या एक और चुस्त कार्यप्रणाली है जो मेरे पर्यावरण के लिए बेहतर होगी? यदि आपका वातावरण इसकी अनुमति नहीं देता है, तो आपको बेहतर स्क्रैम करने में मदद करना बहुत कठिन है। आपके वर्णन में मुझे जो समस्याएँ हैं:

  • कोई भी प्रदर्शनकारी कार्य जिन्हें बुनियादी ढाँचे के कार्यों के रूप में नहीं माना जा सकता है। यदि आपको कुछ ऐसा करने के लिए कई क्षेत्रों की आवश्यकता होती है जिसे व्यावसायिक मूल्य के रूप में नहीं माना जाता है, तो आपकी उपयोगकर्ता कहानियां संभवतः बुरी तरह से परिभाषित होती हैं। यदि आपको व्यावसायिक मूल्य देने में सक्षम होने के लिए एक उपकरण या कुछ और बनाने की आवश्यकता है, तो उत्पाद को दो भागों / रिलीज में विभाजित किया जा सकता है - एक उपकरण का निर्माण और एक व्यावसायिक मूल्य का निर्माण। ऐसे मामले में आपकी उपयोगकर्ता कहानियां "As Developer ..." पूरी तरह से मान्य होंगी, क्योंकि डेवलपर्स के लिए एक टूल बनाया गया है।

    यहां समस्या यह है कि इसे ग्राहक के साथ कैसे संवाद किया जाए, क्योंकि पहली रिलीज में उसकी भागीदारी शून्य है। यदि ग्राहकों के लिए कोई व्यावसायिक मूल्य नहीं है, तो वे कैसे भाग ले सकते हैं? उत्पाद स्वामी व्यावसायिक प्राथमिकता को कैसे परिभाषित कर सकता है?

    मुझे लगता है कि यहां मुख्य समस्या यह है कि यह ऐसा कुछ नहीं है जो स्क्रेम पर फिट बैठता है। स्क्रम सबसे महत्वपूर्ण व्यवसाय सुविधाओं को पहले वितरित करने की कोशिश करता है, लेकिन आपको पहले वितरित करने के लिए दो महीने की आवश्यकता होती है। स्क्रम और पूरे फुर्तीले परिवर्तन को गले लगाते हैं - क्या होगा यदि पहली विशेषताओं को वितरित करने के बाद, ग्राहक को कुछ बदलाव की आवश्यकता होती है जो आपके सभी शुरुआती स्प्रिट के माध्यम से वापस जाता है?

  • परिक्षण। एक और विफलता क्योंकि स्क्रैम में एक टीम को क्रॉस फंक्शनल सदस्यों के समूह के रूप में माना जाता है। इसका मतलब है कि हर कोई विकास और परीक्षण करता है और इस वजह से आपके अंतिम बिंदु (या कम से कम पांच दिन लंबा नहीं) में वर्णित परिस्थितियां नहीं हैं। इसका मतलब यह नहीं है कि कुछ अधिक जटिल और परिष्कृत परीक्षण करने के लिए अलग-अलग क्यूए नहीं हो सकता है, लेकिन टीम को पहले से ही परीक्षण / सत्यापित सुविधा प्रदान करनी चाहिए। आपके मामले में यह वास्तव में ऐसा लग रहा है कि स्क्रैम वह नहीं है जिसकी आपको आवश्यकता है। आपको उनके बीच अलग-अलग विकास और परीक्षण और पासिंग सुविधाओं की आवश्यकता होती है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.