आप एजाइल में पुनरावृत्तियों के पहले जोड़े में क्या वितरित करते हैं?


22

जैसा कि मैं समझता हूं, फुर्तीली कार्यप्रणाली के साथ विचार यह है कि आप कुछ कार्यात्मक प्रदान करते हैं और आप इसे अक्सर वितरित करते हैं। आवेदन वृद्धि के बाद अपने अंतिम आकार वृद्धि में हो जाता है।

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

इन पहले पुनरावृत्तियों में क्लाइंट को क्या दिया जाता है? मचान कोड बनाते समय आप सही दिशा में प्रगति कैसे दिखाते हैं?


2
एक संपूर्ण रूपरेखा या नींव का निर्माण परियोजना में जितनी देर हो सके उतनी देर से किया गया निर्णय होना चाहिए।
जेफो

@ जेफ़ो: जितना देर हो सके उतनी देर का क्या मतलब है? क्या आप एक उत्तर में विस्तार कर सकते हैं?
JohnDoDo

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

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

जवाबों:


15

यह 2 सप्ताह के स्प्रिंट के लिए विशिष्ट है।

मेरे लिए, पहले स्प्रिंट या 2 की संभावना इस सटीक कारण के लिए बाद में स्प्रिंट की तुलना में कम "दृश्यमान" विशेषताओं की होगी ("कम" के कुछ कठिन विवरण के लिए)।

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

हो सकता है कि आप पहले स्प्रिंट में हर मचान वाली वस्तु को बाहर नहीं निकालते हैं या 2. हो सकता है कि कुछ हिस्सों को इंतजार किया जाए और बाद में जोड़ा जाए।

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


6
अंतिम पैराग्राफ के लिए +1 - उपयोगकर्ता सत्यापन के लिए एक प्रोटोटाइप के साथ विकास शुरू करना एक अच्छा विचार है।
कोनामिमन

4
"हो सकता है कि आपके पहले स्प्रिंट में" डमी डेटा के साथ वेबपेज एक्स बनाएं "ताकि आप अपने ग्राहक को दिखाने के लिए कुछ चमकदार हो सकें।": IMO यह ग्राहक पर और परियोजना के समय पैमाने पर निर्भर करता है: 2 महीने की परियोजना के लिए, एक ग्राहक हो सकता है 1 सप्ताह या 2 में कुछ देखना चाहते हैं। 18 महीने के प्रोजेक्ट के लिए, 1 या 2 महीने में पहला डेमो प्राप्त करना ठीक हो सकता है। किसी भी मामले में, जबकि कुछ ग्राहक डमी पेज देखना पसंद कर सकते हैं, अन्य लोग कुछ अधिक सार्थक देखना चाहते हैं और यह महसूस कर सकते हैं कि आप अपना समय बर्बाद कर रहे हैं। मुझे लगता है कि आप सामान्यीकरण नहीं कर सकते।
जियोर्जियो

4
+1, लेकिन हमेशा, अपने ग्राहक joelonsoftware.com/articles/fog0000000356.html पर
डॉक्टर ब्राउन

1
@MatthewFlynn - Scrum में "सही" आवश्यकताएं नहीं हो सकती हैं, लेकिन इसका मतलब यह नहीं है कि ZERO आवश्यकताएं या दस्तावेज उपलब्ध हैं। मैं कभी ऐसे प्रोजेक्ट से नहीं जुड़ा, जहां एक ग्राहक ने कहा कि "बस आगे बढ़ें और निर्माण शुरू करें और हम इसका पता लगा लेंगे"। मुझे लगता है कि इसके लिए एक शब्द है। आमतौर पर किसी परियोजना का किसी प्रकार का स्खलन चरण होना चाहिए जिसमें कुछ चर्चा और समझौते शामिल होते हैं जो वितरित होने जा रहे हैं। मैंने बिक्री पिच के दौरान प्रोटोटाइप प्रस्तुत किया है
hanzolo

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

13

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

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

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

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

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


8

इन पहले पुनरावृत्तियों में क्लाइंट को क्या दिया जाता है?

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

का भी सवाल है

आप ढांचे या नींव का निर्माण कर सकते हैं

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


3

हम जो करने की कोशिश करते हैं, वह पहली पुनरावृत्तियों में सबसे सरल अनुप्रयोग संभव (हम क्या वितरित कर रहे हैं का एक हैलो वर्ल्ड संस्करण) में वितरित करना है। हम इसमें 3 महत्वपूर्ण लाभ देखते हैं:

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

"वितरण प्रक्रिया सेट करें" लोगों की सोच से बहुत कठिन है।
फ्रैंक शीयर

हाँ यही है। इसीलिए आपको इसे जल्द से जल्द करना चाहिए।
user99561

2

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

यह गलत है, क्योंकि आपको भविष्य में उपयोग किए जाने वाले ढांचे का निर्माण करने की आवश्यकता नहीं है। विचार केवल उसी चीज का निर्माण करना है जिसकी आवश्यकता है ( YAGNI भी देखें )।

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

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

इन पहले पुनरावृत्तियों में क्लाइंट को क्या दिया जाता है? मचान कोड बनाते समय आप सही दिशा में प्रगति कैसे दिखाते हैं?

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

यदि आपका प्रश्न "कैसे एक्सेंशन एक्स में चला जाता है?" चुनना है, तो इन विडोकॉस्ट (पुनरावृत्ति 0 ए और बी के भाग के लिए वीडियो) पर एक नज़र डालें ।



मैं स्प्रिंट ज़ीरो के लिए बिल्ड प्रोसेस सेट करने और फ्रेमवर्क कार्यों को चुनने पर विचार नहीं करता। आप कैसे जान सकते हैं कि आपको किस ढांचे की जरूरत है अगर आप नहीं जानते कि क्या बनाना है? मैं हमेशा स्प्रिंट 0 को नंगे न्यूनतम तक सीमित करता हूं। लोगों को पीसी प्राप्त करें और एक स्थान खोजें जहां वे बैठ सकते हैं। पता करें कि आपको व्यवसाय से किससे बात करने की आवश्यकता है। पहले प्लानिंग मीटिंग सेट करें। बाकी के लिए मैं YAGNI लागू करता हूं।
user99561

@ user99561 फ्रेमवर्क बड़े फैसले हैं, और आमतौर पर बदलने के लिए मुश्किल है। उदाहरण के लिए, आपको पता होना चाहिए कि क्या आप कोड लिखना शुरू करने से पहले यूनिट टेस्ट के लिए gtest या cppunit का उपयोग करने जा रहे हैं। बाद में इसे बदलने से गधे को बहुत दर्द होगा और बहुत समय बर्बाद होगा।
B:овиЈ

@ B @овиЈ: हां फ्रेमवर्क बड़े फैसले हैं, इसीलिए आपको निर्णय स्थगित करना चाहिए। अगर आपको पता नहीं है कि एक रूपरेखा तय करने का कोई मतलब नहीं है, तो क्या विकसित होने की आवश्यकता है और आवेदन और वास्तुकला कैसा दिखेगा। आपको यह तय करना चाहिए कि अंतिम संभव क्षण पर किस रूपरेखा का उपयोग करना है। अन्यथा आप निश्चित रूप से उस जोखिम को चलाते हैं जिसे आपको बदलना होगा।
user99561

@ user99561 यदि आपको नहीं पता है कि क्या विकसित करने की आवश्यकता है, तो आप भी शुरू नहीं कर सकते :) :) आवश्यकताओं और उपयोगकर्ता की कहानियों को लिखना होगा, अन्यथा पुनरावृत्ति 1 भी शुरू नहीं हो सकती है।
BЈовић

2

आप बहुत कुछ आप चाहते हैं वितरित कर सकते हैं। बुनियादी ढाँचे का निर्माण केवल गलत है / फुर्तीली / अस्थिर नहीं है।

उदाहरण के लिए: पूरी तरह कार्यात्मक हैलो वर्ल्ड ऐप का निर्माण घंटों में किया जा सकता है। एक सर्वर (यहां तक ​​कि अस्थायी रूप से) को क्लाउड में लाना या एक वीएम के रूप में घंटों में किया जा सकता है।

ये विकास शुरू करने के लिए पर्याप्त हैं । फिर, यदि आपको CI की आवश्यकता है, तो आप एक CI कहानी जोड़ सकते हैं, यदि आप एक भौतिक सर्वर को लीड करते हैं, तो निश्चित रूप से, उसके लिए एक कहानी जोड़ें।

लेकिन 1 दिन पर वितरित करना शुरू करें और कभी भी बंद न करें!


1

शुरुआती पुनरावृत्तियों, विशेष रूप से 1 में, वास्तु स्पाइक्स के लिए कम से कम योजना होनी चाहिए या होनी चाहिए, जिसमें एक निश्चित मात्रा में खोज समय और शायद कुछ वास्तुशिल्प प्रोटोटाइप शामिल हैं।

जैसा कि आपने कहा, आम तौर पर, संरचनात्मक आवश्यकताएं होती हैं जो हितधारक / ग्राहक के लिए बहुत मायने नहीं रखती हैं, लेकिन एक मजबूत मंच या पैटर्न अभिविन्यास बनाने के लिए आवश्यक हैं। जब तक A पूर्ण नहीं होता तब तक आप B का निर्माण शुरू नहीं कर सकते हैं।

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

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

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

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