टाइमबॉक्सिंग: Difference between revisions

From Vigyanwiki
(Text)
No edit summary
 
(6 intermediate revisions by 3 users not shown)
Line 6: Line 6:
== प्रोजेक्ट प्रबंधन में ==
== प्रोजेक्ट प्रबंधन में ==


टाइमबॉक्सिंग का उपयोग [[ परियोजना की योजना बना |प्रोजेक्ट प्लानिंग]] तकनीक के रूप में किया जाता है। शेड्यूल को कई अलग-अलग समयावधियों (टाइमबॉक्स) में विभाजित किया गया है, प्रत्येक भाग की अपनी डिलिवरेबल्स, [[समय सीमा]] और बजट है।{{Citation needed|date=November 2011}} कभी-कभी शेड्यूल को स्वतंत्र चर (एसएआईवी) के रूप में संदर्भित किया जाता है।<ref>{{Cite book|url=https://books.google.com/books?id=MWhXwkHsS0gC&q=%22Schedule+as%22&pg=PA212|title=Balancing Agility and Discipline: A Guide for the Perplexed|last1=Boehm|first1=Barry W.|last2=Boehm|first2=Barry|last3=Turner|first3=Richard|date=2004|publisher=Addison-Wesley Professional|isbn=9780321186126|language=en}}</ref> "टाइमबॉक्सिंग मल्टीस्टेज प्रोजेक्ट्स या कार्यों में सबसे अच्छा काम करती है जिनमें कम समय लगता है और आप उन्हें एक ही टाइम स्लॉट में फिट कर सकते हैं। यह उन कर्तव्यों के मामले में भी लागू करने लायक है जिनके पूरा होने की अनुमानित समय-सीमा है।"<ref>{{Cite web|date=2022-01-17|title=Timeboxing – why you should use it?|url=https://firmbee.com/timeboxing-why-you-should-use-it/|access-date=2022-01-25|website=Firmbee|language=en}}</ref>
टाइमबॉक्सिंग का उपयोग [[ परियोजना की योजना बना |प्रोजेक्ट प्लानिंग]] तकनीक के रूप में किया जाता है। शेड्यूल को कई अलग-अलग समयावधियों (टाइमबॉक्स) में विभाजित किया गया है, प्रत्येक भाग की अपनी डिलिवरेबल्स, [[समय सीमा]] और बजट है।{{Citation needed|date=November 2011}} कभी-कभी शेड्यूल को स्वतंत्र चर (एसएआईवी) के रूप में संदर्भित किया जाता है।<ref>{{Cite book|url=https://books.google.com/books?id=MWhXwkHsS0gC&q=%22Schedule+as%22&pg=PA212|title=Balancing Agility and Discipline: A Guide for the Perplexed|last1=Boehm|first1=Barry W.|last2=Boehm|first2=Barry|last3=Turner|first3=Richard|date=2004|publisher=Addison-Wesley Professional|isbn=9780321186126|language=en}}</ref> "टाइमबॉक्सिंग मल्टीस्टेज प्रोजेक्ट्स या कार्यों में सबसे अच्छा काम करती है जिनमें कम समय लगता है और आप उन्हें एक ही टाइम स्लॉट में फिट कर सकते हैं। यह उन कर्तव्यों की स्थिति में भी लागू करने लायक है जिनके पूरा होने की अनुमानित समय-सीमा है।"<ref>{{Cite web|date=2022-01-17|title=Timeboxing – why you should use it?|url=https://firmbee.com/timeboxing-why-you-should-use-it/|access-date=2022-01-25|website=Firmbee|language=en}}</ref>




=== स्कोप फिक्सिंग करने के विकल्प के रूप में ===
=== स्कोप फिक्सिंग करने के विकल्प के रूप में ===


प्रोजेक्ट प्रबंधन में, प्रायः [[परियोजना प्रबंधन त्रिकोण|प्रोजेक्ट प्रबंधन त्रिकोण]] माना जाता है: समय (कभी-कभी [[अनुसूची (परियोजना प्रबंधन)|अनुसूची (प्रोजेक्ट प्रबंधन)]]), लागत (कभी-कभी [[बजट]]), और [[दायरा (परियोजना प्रबंधन)|दायरा (प्रोजेक्ट प्रबंधन)]]।<ref>[http://www.projectmanagement.net.au/triple_constraints ''What are the Triple Constraints in Project Management''] {{webarchive|url=https://archive.today/20060820021929/http://www.projectmanagement.net.au/triple_constraints |date=2006-08-20 }}, article by Rod Hutchings on [http://projectmanagement.net.au/ Project Management Australia] {{webarchive|url=https://web.archive.org/web/20090216052557/http://projectmanagement.net.au/ |date=2009-02-16 }} (22 Oct 2008)</ref><ref name="Chat">{{Cite news| first=Carl | last=Chatfield | title=परियोजना प्रबंधन में एक लघु पाठ्यक्रम| url=http://office.microsoft.com/en-us/project/HA102354821033.aspx| publisher=Microsoft}}</ref><ref>{{cite book | last = Dobson | first = Michael | title = परियोजना प्रबंधन में तिहरी बाधाएँ| publisher = Management Concepts | location = Vienna, Va | year = 2004 | isbn = 1-56726-152-3 }}</ref><ref name=Kanabar/><ref name=Leffingwell/>([[गुणवत्ता (व्यवसाय)|गुणवत्ता]] को प्रायः चौथी बाधा के रूप में जोड़ा जाता है---एक त्रिकोण के मध्य के रूप में दर्शाया जाता है।<ref>{{cite book |last= Snedaker |first= Susan |author2=Nels Hoenig  |title= आईटी परियोजना प्रबंधन में धोखा कैसे दें|publisher= Syngress |year= 2005 |isbn= 1-59749-037-7 }}</ref><ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained: embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages = [https://archive.org/details/extremeprogrammi00beck/page/15 15]–19 | url = https://archive.org/details/extremeprogrammi00beck | url-access = limited }}</ref><ref name=Dangelo>{{cite book | last = Dangelo | first = Mark | title = Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose | publisher = iUniverse | location = New York | year = 2005 | isbn = 978-0-595-67081-9 | page=53 | url=https://books.google.com/books?id=LQx3lab0KnIC}}</ref>) धारणा यह है कि एक बाधा में परिवर्तन अन्य को प्रभावित करेगा।<ref name=Kanabar>{{cite book | last = Kanabar | first = Vijay | title = MBA Fundamentals: Project Management | publisher = Kaplan Pub | location = New York | year = 2008 | page = 51 | isbn = 978-1-4277-9744-5 }}</ref>
प्रोजेक्ट प्रबंधन में, प्रायः तीन [[परियोजना प्रबंधन त्रिकोण|बाधाएं]] मानी जाती हैं: समय (कभी-कभी [[अनुसूची (परियोजना प्रबंधन)|अनुसूची (प्रोजेक्ट प्रबंधन)]]), लागत (कभी-कभी [[बजट]]), और [[दायरा (परियोजना प्रबंधन)|कार्यक्षेत्र]]।<ref>[http://www.projectmanagement.net.au/triple_constraints ''What are the Triple Constraints in Project Management''] {{webarchive|url=https://archive.today/20060820021929/http://www.projectmanagement.net.au/triple_constraints |date=2006-08-20 }}, article by Rod Hutchings on [http://projectmanagement.net.au/ Project Management Australia] {{webarchive|url=https://web.archive.org/web/20090216052557/http://projectmanagement.net.au/ |date=2009-02-16 }} (22 Oct 2008)</ref><ref name="Chat">{{Cite news| first=Carl | last=Chatfield | title=परियोजना प्रबंधन में एक लघु पाठ्यक्रम| url=http://office.microsoft.com/en-us/project/HA102354821033.aspx| publisher=Microsoft}}</ref><ref>{{cite book | last = Dobson | first = Michael | title = परियोजना प्रबंधन में तिहरी बाधाएँ| publisher = Management Concepts | location = Vienna, Va | year = 2004 | isbn = 1-56726-152-3 }}</ref><ref name=Kanabar/><ref name=Leffingwell/>([[गुणवत्ता (व्यवसाय)|गुणवत्ता]] को प्रायः चौथी बाधा के रूप में जोड़ा जाता है---एक त्रिकोण के मध्य के रूप में दर्शाया जाता है।<ref>{{cite book |last= Snedaker |first= Susan |author2=Nels Hoenig  |title= आईटी परियोजना प्रबंधन में धोखा कैसे दें|publisher= Syngress |year= 2005 |isbn= 1-59749-037-7 }}</ref><ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained: embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages = [https://archive.org/details/extremeprogrammi00beck/page/15 15]–19 | url = https://archive.org/details/extremeprogrammi00beck | url-access = limited }}</ref><ref name=Dangelo>{{cite book | last = Dangelo | first = Mark | title = Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose | publisher = iUniverse | location = New York | year = 2005 | isbn = 978-0-595-67081-9 | page=53 | url=https://books.google.com/books?id=LQx3lab0KnIC}}</ref>) धारणा यह है कि एक बाधा में परिवर्तन अन्य को प्रभावित करेगा।<ref name=Kanabar>{{cite book | last = Kanabar | first = Vijay | title = MBA Fundamentals: Project Management | publisher = Kaplan Pub | location = New York | year = 2008 | page = 51 | isbn = 978-1-4277-9744-5 }}</ref>


टाइमबॉक्सिंग के बिना, प्रोजेक्ट प्रायः एक निश्चित दायरे में काम करती हैं,<ref>{{cite book |last= Godin |first= Seth |title= Getting Real: The smarter, faster, easier way to build a successful web application |publisher= 37signals }}</ref> ऐसी स्थिति में जब यह स्पष्ट हो जाता है कि कुछ डिलिवरेबल्स को नियोजित समयसीमा के भीतर पूरा नहीं किया जा सकता है, तो या तो समय सीमा बढ़ानी होगी (तय किए गए दायरे को पूरा करने के लिए अधिक समय देने के लिए) या अधिक लोगों को शामिल करना होगा (तय किए गए दायरे को उसी में पूरा करने के लिए) समय)। प्रायः दोनों होते हैं, जिसके परिणामस्वरूप डिलीवरी में देरी होती है, लागत में वृद्धि होती है, और प्रायः गुणवत्ता में कमी आती है ([[पौराणिक मानव-महीना]] सिद्धांत के अनुसार)।
टाइमबॉक्सिंग के बिना, प्रोजेक्ट्स प्रायः एक निश्चित कार्यक्षेत्र में काम करते हैं,<ref>{{cite book |last= Godin |first= Seth |title= Getting Real: The smarter, faster, easier way to build a successful web application |publisher= 37signals }}</ref> ऐसी स्थिति में जब यह स्पष्ट हो जाता है कि कुछ डिलिवरेबल्स को नियोजित समयसीमा के भीतर पूरा नहीं किया जा सकता है, तो या तो समय सीमा बढ़ानी होगी (तय किए गए कार्यक्षेत्र को पूरा करने के लिए अधिक समय देने के लिए अधिक समय देने के लिए) या अधिक लोगों को (एक ही समय में तय कार्यक्षेत्र को पूरा करने के लिए) सम्मिलित किया जाता है। प्रायः दोनों होते हैं, जिसके परिणामस्वरूप डिलीवरी में देरी होती है, लागत में वृद्धि होती है, और प्रायः गुणवत्ता में कमी आती है ([[पौराणिक मानव-महीना|द मिथिकल मैन-मंथ]] सिद्धांत के अनुसार)।


टाइमबॉक्सिंग के साथ समय सीमा तय हो गई है, यानी दायरा कम करना होगा। इसका मतलब यह है कि संगठनों को पहले सबसे महत्वपूर्ण डिलिवरेबल्स को पूरा करने पर ध्यान केंद्रित करना होगा, टाइमबॉक्सिंग प्रायः डिलिवरेबल्स को प्राथमिकता देने की योजना के साथ-साथ चलती है (जैसे कि [[MoSCoW विधि]] के साथ)।<ref name=":0">{{Cite book|title=DSDM, dynamic systems development method: the method in practice|last=Jennifer.|first=Stapleton|date=1997|publisher=Addison-Wesley|isbn=0201178893|location=Harlow, England|oclc=36755892}}</ref>
टाइमबॉक्सिंग के साथ समय सीमा तय हो गई है, यानी कार्यक्षेत्र कम करना होगा। इसका मतलब यह है कि संगठनों को पहले सबसे महत्वपूर्ण डिलिवरेबल्स को पूरा करने पर ध्यान केंद्रित करना होगा, टाइमबॉक्सिंग प्रायः डिलिवरेबल्स को प्राथमिकता देने की योजना के साथ-साथ चलती है (जैसे कि [[MoSCoW विधि|मॉस्को पद्धति]] के साथ)।<ref name=":0">{{Cite book|title=DSDM, dynamic systems development method: the method in practice|last=Jennifer.|first=Stapleton|date=1997|publisher=Addison-Wesley|isbn=0201178893|location=Harlow, England|oclc=36755892}}</ref>




Line 21: Line 21:
=== जोखिम का प्रबंधन करने के लिए ===
=== जोखिम का प्रबंधन करने के लिए ===


टाइमबॉक्स का उपयोग [[जोखिम प्रबंधन]] के एक रूप के रूप में किया जाता है, ताकि अनिश्चित कार्य/समय संबंधों की स्पष्ट रूप से पहचान की जा सके, यानी, वह कार्य जो आसानी से अपनी समय सीमा से आगे बढ़ सकता है। योजना बनाने में समय की कमी प्रायः प्राथमिक चालक होती है और इसे प्रोजेक्ट या उप-प्रोजेक्ट के महत्वपूर्ण पथों पर विचार किए बिना नहीं बदला जाना चाहिए। यानी, समय सीमा को पूरा करना प्रायः महत्वपूर्ण है। समय-सीमा छूटने के जोखिम कारकों में प्रोजेक्ट की जटिलताएँ, प्रोजेक्ट के भीतर योजना संबंधी त्रुटियाँ, टीम से संबंधित मुद्दे या योजना का दोषपूर्ण निष्पादन शामिल हो सकते हैं। अपस्ट्रीम मुद्दों में प्रोजेक्ट मिशन में बदलाव या प्रबंधन से समर्थन/समर्थन शामिल हो सकता है। एक सामान्य नियोजन त्रुटि अपर्याप्त कार्य विभाजन है, जिसके कारण कार्य को पूरा करने के लिए आवश्यक समय का कम अनुमान लगाया जा सकता है। टीम से संबंधित मुद्दों में अंतर-टीम संचार में परेशानी शामिल हो सकती है; अनुभव या आवश्यक क्रॉस-फ़ंक्शनलिटी की कमी; प्रतिबद्धता/अभियान/प्रेरणा की कमी (यानी खराब टीम निर्माण और प्रबंधन)।
टाइमबॉक्स का उपयोग [[जोखिम प्रबंधन]] के एक रूप के रूप में किया जाता है, ताकि अनिश्चित कार्य/समय संबंधों की स्पष्ट रूप से पहचान की जा सके, यानी, वह कार्य जो आसानी से अपनी समय सीमा से आगे बढ़ सकता है। योजना बनाने में समय की कमी प्रायः प्राथमिक चालक होती है और इसे प्रोजेक्ट या उप-प्रोजेक्ट के महत्वपूर्ण पथों पर विचार किए बिना नहीं बदला जाना चाहिए। यानी, समय सीमा को पूरा करना प्रायः महत्वपूर्ण है। समय-सीमा छूटने के जोखिम कारकों में प्रोजेक्ट की जटिलताएँ, प्रोजेक्ट के भीतर योजना संबंधी त्रुटियाँ, टीम से संबंधित मुद्दे या योजना का दोषपूर्ण निष्पादन सम्मिलित हो सकते हैं। अपस्ट्रीम मुद्दों में प्रोजेक्ट मिशन में बदलाव या प्रबंधन से समर्थन/सहारा सम्मिलित हो सकता है। एक सामान्य नियोजन त्रुटि अपर्याप्त कार्य विभाजन है, जिसके कारण कार्य को पूरा करने के लिए आवश्यक समय का कम अनुमान लगाया जा सकता है। टीम से संबंधित मुद्दों में अंतर-टीम संचार में परेशानी सम्मिलित हो सकती है; अनुभव या आवश्यक क्रॉस-फ़ंक्शनलिटी की कमी; प्रतिबद्धता/अभियान/प्रेरणा की कमी (यानी खराब टीम निर्माण और प्रबंधन) हो सकती है।


समय सीमा पर बने रहने के लिए, ट्रिपल बाधाओं के विरुद्ध निम्नलिखित कार्रवाइयों का प्रायः मूल्यांकन किया जाता है:
समय सीमा पर बने रहने के लिए, ट्रिपल बाधाओं के विरुद्ध निम्नलिखित कार्रवाइयों का प्रायः मूल्यांकन किया जाता है:


* दायरा कम करें: कम प्रभाव वाली आवश्यकताओं को कम करें (वे जो सीधे उपयोगकर्ता से छूट नहीं जाएंगी)
* कार्यक्षेत्र कम करें: कम प्रभाव वाली आवश्यकताओं को कम करें (वे जो सीधे उपयोगकर्ता से छूट नहीं जाएंगी)
* यहां समय निश्चित बाधा है
* यहां समय निश्चित बाधा है
* लागत बढ़ाएँ: उदाहरण के लिए, ओवरटाइम या संसाधन जोड़ें
* लागत बढ़ाएँ: उदाहरण के लिए, अतिरिक्त समय या संसाधन जोड़ें


=== सॉफ्टवेयर विकास में अपनाना ===
=== सॉफ्टवेयर विकास में स्वीकरण ===


कई सफल सॉफ़्टवेयर विकास प्रोजेक्टएँ टाइमबॉक्सिंग का उपयोग करती हैं, विशेषकर छोटी प्रोजेक्टएँ।<ref name=Capers>For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 [[function point]]) projects ranked 7 and rated a "Best Practice" by the survey in {{cite book | last = Jones | first = Capers | title = Software engineering best practices lessons from successful projects in the top companies | publisher = McGraw-Hill | location = New York | year = 2010 | isbn = 978-0-07-162162-5}}</ref> 80 के दशक में ड्यूपॉन्ट में टाइमबॉक्सिंग को अपनाने से डेवलपर उत्पादकता तीन गुना हो गई।<ref name=McConnell/>कुछ मामलों में, एप्लिकेशन केवल [[कार्यात्मक विनिर्देश]] को पूरा करने के लिए अनुमानित समय के भीतर पूरी तरह से वितरित किए गए थे।<ref name=McConnell/>हालाँकि, [[स्टीव मैककोनेल]] का तर्क है कि हर उत्पाद उपयुक्त नहीं है<ref name=McConnell/>और टाइमबॉक्सिंग का उपयोग केवल तभी किया जाना चाहिए जब ग्राहक सुविधाओं में कटौती के लिए सहमत हो, गुणवत्ता में नहीं।<ref name=McConnell/>प्रोजेक्टओं के सबसे बड़े वर्ग के बीच सशक्त रूप से अपनाने के बहुत कम सबूत हैं।<ref name=Capers/>
कई सफल सॉफ़्टवेयर विकास प्रोजेक्ट्स टाइमबॉक्सिंग का उपयोग करती हैं, विशेषकर छोटी प्रोजेक्ट्स हैं।<ref name=Capers>For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 [[function point]]) projects ranked 7 and rated a "Best Practice" by the survey in {{cite book | last = Jones | first = Capers | title = Software engineering best practices lessons from successful projects in the top companies | publisher = McGraw-Hill | location = New York | year = 2010 | isbn = 978-0-07-162162-5}}</ref> 80 के दशक में ड्यूपॉन्ट में टाइमबॉक्सिंग को अपनाने से डेवलपर रचनात्मकता तीन गुना हो गई।<ref name=McConnell/> कुछ स्थितियों में, एप्लिकेशन केवल [[कार्यात्मक विनिर्देश]] को पूरा करने के लिए अनुमानित समय के भीतर पूरी तरह से वितरित किए गए थे।<ref name=McConnell/> हालाँकि, [[स्टीव मैककोनेल]] का तर्क है कि हर उत्पाद उपयुक्त नहीं है<ref name=McConnell/> और टाइमबॉक्सिंग का उपयोग केवल तभी किया जाना चाहिए जब ग्राहक सुविधाओं में कटौती के लिए सहमत हो, गुणवत्ता में नहीं।<ref name=McConnell/> प्रोजेक्ट्स के सबसे बड़े वर्ग के बीच सशक्त रूप से अपनाने के बहुत कम प्रमाण हैं।<ref name=Capers/>


टाइमबॉक्सिंग को कुछ उल्लेखनीय सॉफ्टवेयर विकास पद्धतियों द्वारा अपनाया गया है:
टाइमबॉक्सिंग को कुछ उल्लेखनीय सॉफ्टवेयर विकास पद्धतियों द्वारा अपनाया गया है:


* [[गतिशील सिस्टम विकास विधि]] (डीएसडीएम)<ref name=":0" />* लीन सॉफ्टवेयर विकास में, [[नाम का तख़्ता]] के साथ [[कानबन (विकास)]] अल्पकालिक समय प्रबंधन प्रदान करता है। एक बड़ी और जटिल प्रणाली विकसित करते समय, जब दीर्घकालिक [[योजना]] की आवश्यकता होती है तो टाइमबॉक्सिंग ऊपर [[अमूर्त परत]] होती है।<ref>{{cite book | last = Poppendieck | first = Mary | title = Leading Lean Software Development: Results are not the Point | publisher = Addison-Wesley | location = Upper Saddle River, NJ | pages = 137–140 | year = 2010 | isbn = 978-0-321-62070-5 }}</ref>
* [[गतिशील सिस्टम विकास विधि|डायनेमिक सिस्टम डेवलपमेंट मेथड]] (डीएसडीएम)<ref name=":0" />
* [[रैपिड अनुप्रयोग का विकास]] (आरएडी) [[सॉफ्टवेयर विकास प्रक्रिया]] में [[पुनरावृत्तीय और वृद्धिशील विकास]] और [[सॉफ़्टवेयर प्रोटोटाइप]] की सुविधा है। स्टीव मैककोनेल के अनुसार, टाइमबॉक्सिंग आरएडी के लिए एक सर्वोत्तम अभ्यास है और एक सामान्य टाइमबॉक्स की लंबाई 60-120 दिन होनी चाहिए।<ref name=McConnell>{{cite book | last = McConnell | first = Steve | title = Rapid Development: taming wild software schedules | publisher = Microsoft Press | location = Redmond, Wash | year = 1996 | isbn = 1-55615-900-5 | pages = [https://archive.org/details/rapiddevelopment00mcco/page/575 575]–583 | url = https://archive.org/details/rapiddevelopment00mcco | url-access = limited }}</ref>
*लीन सॉफ्टवेयर विकास में, [[कानबन (विकास)|कानबन]] के साथ [[नाम का तख़्ता|पुल शेड्यूलिंग]] अल्पकालिक समय प्रबंधन प्रदान करता है। एक बड़ी और जटिल प्रणाली विकसित करते समय, जब दीर्घकालिक [[योजना]] की आवश्यकता होती है तो टाइमबॉक्सिंग ऊपर [[अमूर्त परत|स्तरित]] किया जाता है।<ref>{{cite book | last = Poppendieck | first = Mary | title = Leading Lean Software Development: Results are not the Point | publisher = Addison-Wesley | location = Upper Saddle River, NJ | pages = 137–140 | year = 2010 | isbn = 978-0-321-62070-5 }}</ref>
* [[स्क्रम (विकास)]] टाइमबॉक्सिंग और पुनरावृत्त विकास के विचारों से प्रभावित था।<ref>{{cite book | last = Coplien | first = James | title = एजाइल सॉफ्टवेयर डेवलपमेंट के लिए लीन आर्किटेक्चर| publisher = Wiley | location = Chichester Hoboken, N.J | year = 2010 | url = https://books.google.com/books?id=lpvY36MPMUwC | page = 25 | isbn = 978-0-470-68420-7 }}</ref> [[ पूरे वेग से दौड़ना ]] के रूप में जानी जाने वाली नियमित टाइमबॉक्स इकाइयां विकास की मूल इकाई बनाती हैं।<ref>{{cite book | last = Cohn | first = Mike | title = Succeeding with Agile: Software Development using Scrum | url = https://archive.org/details/succeedingwithag00cohn_599 | url-access = limited | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2010 | pages = [https://archive.org/details/succeedingwithag00cohn_599/page/n284 257]–284 | isbn = 978-0-321-57936-2 }}</ref> स्प्रिंट की सामान्य लंबाई 30 दिनों से कम होती है।<ref name=Schwaber/><ref>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 15 | url = https://books.google.com/books?id=pTExbNmZwZUC }}</ref> स्प्रिंट योजना, स्प्रिंट पूर्वव्यापी और स्प्रिंट समीक्षा बैठकें समयबद्ध हैं।<ref name=Schwaber>{{cite book | last = Schwaber | first = Ken | title = स्क्रम के साथ चुस्त परियोजना प्रबंधन| publisher = O'Reilly Media, Inc | location = New York | year = 2009 | url = https://books.google.com/books?id=RpYX01XVMksC | isbn = 978-0-7356-3790-0 }}</ref>
* [[रैपिड अनुप्रयोग का विकास|रैपिड एप्लिकेशन डेवलपमेंट]] (आरएडी) [[सॉफ्टवेयर विकास प्रक्रिया]] में [[पुनरावृत्तीय और वृद्धिशील विकास|पुनरावृत्तीय विकास]] और [[सॉफ़्टवेयर प्रोटोटाइप]] की सुविधा होती है। स्टीव मैककोनेल के अनुसार, टाइमबॉक्सिंग आरएडी के लिए एक "सर्वोत्तम अभ्यास" है और एक सामान्य टाइमबॉक्स की अवधि 60-120 दिन होनी चाहिए।<ref name="McConnell">{{cite book | last = McConnell | first = Steve | title = Rapid Development: taming wild software schedules | publisher = Microsoft Press | location = Redmond, Wash | year = 1996 | isbn = 1-55615-900-5 | pages = [https://archive.org/details/rapiddevelopment00mcco/page/575 575]–583 | url = https://archive.org/details/rapiddevelopment00mcco | url-access = limited }}</ref>
* [[चरम कार्यक्रम]] पद्धतियों में, विकास योजना को प्रायः 1, 2 या 3 सप्ताह की अवधि के पुनरावृत्तियों में समयबद्ध किया जाता है। व्यवसाय की आवश्यकता प्रत्येक पुनरावृत्ति से पहले लंबित उपयोगकर्ता कहानी को प्राथमिकता देती है।<ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained: embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages = [https://archive.org/details/extremeprogrammi00beck/page/85 85]–96 | url = https://archive.org/details/extremeprogrammi00beck | url-access = limited }}</ref>
* [[स्क्रम (विकास)|स्क्रम]] टाइमबॉक्सिंग और इटरेटिव डेवलपमेंट के विचारों से प्रभावित था।<ref>{{cite book | last = Coplien | first = James | title = एजाइल सॉफ्टवेयर डेवलपमेंट के लिए लीन आर्किटेक्चर| publisher = Wiley | location = Chichester Hoboken, N.J | year = 2010 | url = https://books.google.com/books?id=lpvY36MPMUwC | page = 25 | isbn = 978-0-470-68420-7 }}</ref> नियमित टाइमबॉक्स वाली इकाइयाँ जिन्हें स्प्रिंट के नाम से जाना जाता है, विकास की मूल इकाई बनती हैं।<ref>{{cite book | last = Cohn | first = Mike | title = Succeeding with Agile: Software Development using Scrum | url = https://archive.org/details/succeedingwithag00cohn_599 | url-access = limited | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2010 | pages = [https://archive.org/details/succeedingwithag00cohn_599/page/n284 257]–284 | isbn = 978-0-321-57936-2 }}</ref> स्प्रिंट की सामान्य अवधि 30 दिनों से कम होती है।<ref name="Schwaber" /><ref>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 15 | url = https://books.google.com/books?id=pTExbNmZwZUC }}</ref> स्प्रिंट योजना, स्प्रिंट पूर्वव्यापी और स्प्रिंट समीक्षा बैठकें समयबद्ध हैं।<ref name="Schwaber">{{cite book | last = Schwaber | first = Ken | title = स्क्रम के साथ चुस्त परियोजना प्रबंधन| publisher = O'Reilly Media, Inc | location = New York | year = 2009 | url = https://books.google.com/books?id=RpYX01XVMksC | isbn = 978-0-7356-3790-0 }}</ref>
एजाइल सॉफ्टवेयर विकास योजना संचालित से मूल्य संचालित विकास की ओर बढ़ने की वकालत करता है। गुणवत्ता और समय तय है लेकिन दायरे में लचीलेपन की अनुमति है। सबसे महत्वपूर्ण सुविधाएँ पहले प्रदान करने से [[झरना मॉडल]] की तुलना में निवेश पर पहले रिटर्न मिलता है।<ref name=Leffingwell>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 17–19 | url = https://books.google.com/books?id=pTExbNmZwZUC }}</ref>
* [[चरम कार्यक्रम|चरम प्रोग्रामिंग]] पद्धतियों में, विकास योजना को प्रायः 1, 2 या 3 सप्ताह की अवधि के पुनरावृत्तियों में समयबद्ध किया जाता है। व्यवसाय प्रत्येक पुनरावृत्ति से पहले लंबित उपयोगकर्ता कहानियों का पुनर्मूल्यांकन करता है।<ref>{{cite book | last = Beck | first = Kent | title = Extreme programming eXplained: embrace change | publisher = Addison-Wesley | location = Reading, MA | year = 2000 | isbn = 0-201-61641-6 | pages = [https://archive.org/details/extremeprogrammi00beck/page/85 85]–96 | url = https://archive.org/details/extremeprogrammi00beck | url-access = limited }}</ref>
विस्तृत विशिष्टताओं की कमी प्रायः समय की कमी, या वांछित अंतिम परिणाम (समाधान) के ज्ञान की कमी का परिणाम है। कई प्रकार की प्रोजेक्टओं में, और विशेष रूप से सॉफ्टवेयर इंजीनियरिंग में, कार्यान्वयन चरण की शुरुआत से पहले सभी आवश्यकताओं और विशिष्टताओं का विश्लेषण और परिभाषित करना असंभव है। टाइमबॉक्सिंग उन प्रोजेक्टओं के लिए अनुबंध का एक अनुकूल प्रकार हो सकता है जिसमें समय सीमा सबसे महत्वपूर्ण पहलू है और जब सभी आवश्यकताओं को पूरी तरह से पहले से निर्दिष्ट नहीं किया जाता है। यह प्रोजेक्ट के दौरान खोजे गए नए फीडबैक या अंतर्दृष्टि को अंतिम परिणाम में प्रतिबिंबित करने की भी अनुमति देता है।<ref name=":0" />
एजाइल सॉफ्टवेयर विकास ''योजना संचालित से मूल्य संचालित'' विकास की ओर बढ़ने की वकालत करता है। गुणवत्ता और समय तय है लेकिन कार्यक्षेत्र में लचीलेपन की अनुमति है। सबसे महत्वपूर्ण सुविधाएँ पहले प्रदान करने से [[झरना मॉडल|वॉटरफॉल मॉडल]] की तुलना में निवेश पर पहले रिटर्न मिलता है।<ref name=Leffingwell>{{cite book | last = Leffingwell | first = Dean | title = Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise | publisher = Addison-Wesley | location = Upper Saddle River, NJ | year = 2011 | isbn = 978-0-321-63584-6 | pages = 17–19 | url = https://books.google.com/books?id=pTExbNmZwZUC }}</ref>
 
विस्तृत विशिष्टताओं की कमी प्रायः समय की कमी, या वांछित अंतिम परिणाम (समाधान) के ज्ञान की कमी का परिणाम है। कई प्रकार की प्रोजेक्ट्स में, और विशेष रूप से सॉफ्टवेयर इंजीनियरिंग में, कार्यान्वयन चरण की शुरुआत से पहले ''सभी'' आवश्यकताओं और विशिष्टताओं का विश्लेषण और परिभाषित करना असंभव है। टाइमबॉक्सिंग उन प्रोजेक्ट्स के लिए अनुबंध का एक अनुकूल प्रकार हो सकता है जिसमें समय सीमा ''सबसे महत्वपूर्ण'' पहलू होती है और जब सभी आवश्यकताओं को पूरी तरह से पहले से निर्दिष्ट नहीं किया जाता है। यह प्रोजेक्ट के दौरान खोजे गए नए फीडबैक या अंतर्दृष्टि को अंतिम परिणाम में प्रतिबिंबित करने की भी अनुमति देता है।<ref name=":0" />
 




== व्यक्तिगत समय प्रबंधन में ==
== व्यक्तिगत समय प्रबंधन में ==
{{Main|Timeblocking}}
{{Main|टाइमब्लॉकिंग}}
टाइमबॉक्सिंग का उपयोग व्यक्तिगत कार्यों के लिए किया जा सकता है, जिस स्थिति में यह समय के कम पैमाने (उदाहरण के लिए, तीस मिनट) और डिलिवरेबल्स (उदाहरण के लिए, प्रोजेक्ट डिलिवरेबल के बजाय एक घरेलू काम) का उपयोग करता है, और इसे प्रायः [[ समय अवरोधन ]] कहा जाता है।
टाइमबॉक्सिंग का उपयोग व्यक्तिगत कार्यों के लिए किया जा सकता है, जिस स्थिति में यह समय के कम पैमाने (उदाहरण के लिए, तीस मिनट) और डिलिवरेबल्स (उदाहरण के लिए, प्रोजेक्ट डिलिवरेबल के बजाय एक घरेलू काम) का उपयोग करता है, और इसे प्रायः [[ समय अवरोधन |टाइमब्लॉकिंग]] कहा जाता है।


यह भी कहा जाता है कि व्यक्तिगत टाइमबॉक्सिंग पूर्णतावादी प्रवृत्तियों पर अंकुश लगाने में मदद करने के लिए [[लाइफ हैकिंग]] के रूप में कार्य करती है (एक निश्चित समय निर्धारित करके और किसी कार्य के लिए अधिक प्रतिबद्ध न होकर) जो रचनात्मकता और फोकस को भी बढ़ा सकती है (तात्कालिकता या बढ़े हुए दबाव की भावना पैदा करके)।<ref>{{cite book | last = Pash | first = Adam | title = लाइफ़हैकर अधिक स्मार्ट, तेज़ और बेहतर तरीके से काम करने के लिए मार्गदर्शिका| publisher = Wiley | location = Indianapolis, Ind | year = 2011 | isbn = 978-1-118-13345-3 | url = https://books.google.com/books?id=d-FYJceblAMC | at=Hack 29}}</ref>
यह भी कहा जाता है कि व्यक्तिगत टाइमबॉक्सिंग पूर्णतावादी प्रवृत्तियों पर अंकुश लगाने में मदद करने के लिए [[लाइफ हैकिंग]] के रूप में कार्य करती है (एक निश्चित समय निर्धारित करके और किसी कार्य के लिए अधिक प्रतिबद्ध न होकर) जो रचनात्मकता और ध्यान को भी बढ़ा (तात्कालिकता या बढ़े हुए दबाव की भावना पैदा करके) सकती है।<ref>{{cite book | last = Pash | first = Adam | title = लाइफ़हैकर अधिक स्मार्ट, तेज़ और बेहतर तरीके से काम करने के लिए मार्गदर्शिका| publisher = Wiley | location = Indianapolis, Ind | year = 2011 | isbn = 978-1-118-13345-3 | url = https://books.google.com/books?id=d-FYJceblAMC | at=Hack 29}}</ref>




== अन्य तरीकों से संबंध ==
== अन्य तरीकों से संबंध ==


टाइमबॉक्सिंग अन्य व्यक्तिगत समय प्रबंधन विधियों में बिल्डिंग ब्लॉक के रूप में कार्य करता है:
टाइमबॉक्सिंग अन्य व्यक्तिगत समय प्रबंधन विधियों में मूलभूत अंग के रूप में कार्य करता है:


* [[पोमोडोरो तकनीक]] मन को ठीक होने की अनुमति देने वाले ब्रेक द्वारा अलग किए गए केंद्रित एकाग्रता के 25 मिनट के टाइमबॉक्स पर आधारित है।<ref>{{cite book | last=Nöteberg | first=Staffan | title=पोमोडोरो तकनीक का चित्रण| year=2009 | publisher = Pragmatic Bookshelf | location = Raleigh, N.C | isbn=978-1-934356-50-0 }}</ref>
* [[पोमोडोरो तकनीक]] मन को ठीक होने की अनुमति देने वाले ब्रेक द्वारा अलग किए गए केंद्रित एकाग्रता के 25 मिनट के टाइमबॉक्स पर आधारित है।<ref>{{cite book | last=Nöteberg | first=Staffan | title=पोमोडोरो तकनीक का चित्रण| year=2009 | publisher = Pragmatic Bookshelf | location = Raleigh, N.C | isbn=978-1-934356-50-0 }}</ref>
* [[एंडी हंट (लेखक)]] [[स्मार्ट मानदंड]] में टाइमबॉक्सिंग को अपना 'टी' बताते हैं।<ref>{{cite book | last = Hunt | first = Andrew | title = Pragmatic thinking and learning: refactor your wetware | publisher = Pragmatic | location = Raleigh | year = 2008 | isbn = 978-1-934356-05-0 | url = https://archive.org/details/pragmaticthinkin00hunt_1 }}</ref>
* [[एंडी हंट (लेखक)|एंडी हंट]] [[एसएमएआरटी]] में टाइमबॉक्सिंग को अपना 'टी' बताते हैं।<ref>{{cite book | last = Hunt | first = Andrew | title = Pragmatic thinking and learning: refactor your wetware | publisher = Pragmatic | location = Raleigh | year = 2008 | isbn = 978-1-934356-05-0 | url = https://archive.org/details/pragmaticthinkin00hunt_1 }}</ref>




Line 63: Line 66:
== संदर्भ ==
== संदर्भ ==
{{reflist}}
{{reflist}}
[[Category: समय प्रबंधन]] [[Category: गतिशील सिस्टम विकास विधि]] [[Category: सॉफ्टवेयर परियोजना प्रबंधन]] [[Category: चुस्त सॉफ्टवेयर विकास]] [[Category: अनुत्पादक निर्माण]]


[[Category: Machine Translated Page]]
[[Category:All articles with unsourced statements]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:Articles with unsourced statements from November 2011]]
[[Category:CS1 English-language sources (en)]]
[[Category:Created On 25/06/2023]]
[[Category:Created On 25/06/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Translated in Hindi]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Webarchive template archiveis links]]
[[Category:Webarchive template wayback links]]
[[Category:अनुत्पादक निर्माण]]
[[Category:गतिशील सिस्टम विकास विधि]]
[[Category:चुस्त सॉफ्टवेयर विकास]]
[[Category:समय प्रबंधन]]
[[Category:सॉफ्टवेयर परियोजना प्रबंधन]]

Latest revision as of 16:13, 13 July 2023

Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries
Outlines

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

प्रोजेक्ट प्रबंधन में

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


स्कोप फिक्सिंग करने के विकल्प के रूप में

प्रोजेक्ट प्रबंधन में, प्रायः तीन बाधाएं मानी जाती हैं: समय (कभी-कभी अनुसूची (प्रोजेक्ट प्रबंधन)), लागत (कभी-कभी बजट), और कार्यक्षेत्र।[3][4][5][6][7](गुणवत्ता को प्रायः चौथी बाधा के रूप में जोड़ा जाता है---एक त्रिकोण के मध्य के रूप में दर्शाया जाता है।[8][9][10]) धारणा यह है कि एक बाधा में परिवर्तन अन्य को प्रभावित करेगा।[6]

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

टाइमबॉक्सिंग के साथ समय सीमा तय हो गई है, यानी कार्यक्षेत्र कम करना होगा। इसका मतलब यह है कि संगठनों को पहले सबसे महत्वपूर्ण डिलिवरेबल्स को पूरा करने पर ध्यान केंद्रित करना होगा, टाइमबॉक्सिंग प्रायः डिलिवरेबल्स को प्राथमिकता देने की योजना के साथ-साथ चलती है (जैसे कि मॉस्को पद्धति के साथ)।[12]


जोखिम का प्रबंधन करने के लिए

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

समय सीमा पर बने रहने के लिए, ट्रिपल बाधाओं के विरुद्ध निम्नलिखित कार्रवाइयों का प्रायः मूल्यांकन किया जाता है:

  • कार्यक्षेत्र कम करें: कम प्रभाव वाली आवश्यकताओं को कम करें (वे जो सीधे उपयोगकर्ता से छूट नहीं जाएंगी)
  • यहां समय निश्चित बाधा है
  • लागत बढ़ाएँ: उदाहरण के लिए, अतिरिक्त समय या संसाधन जोड़ें

सॉफ्टवेयर विकास में स्वीकरण

कई सफल सॉफ़्टवेयर विकास प्रोजेक्ट्स टाइमबॉक्सिंग का उपयोग करती हैं, विशेषकर छोटी प्रोजेक्ट्स हैं।[13] 80 के दशक में ड्यूपॉन्ट में टाइमबॉक्सिंग को अपनाने से डेवलपर रचनात्मकता तीन गुना हो गई।[14] कुछ स्थितियों में, एप्लिकेशन केवल कार्यात्मक विनिर्देश को पूरा करने के लिए अनुमानित समय के भीतर पूरी तरह से वितरित किए गए थे।[14] हालाँकि, स्टीव मैककोनेल का तर्क है कि हर उत्पाद उपयुक्त नहीं है[14] और टाइमबॉक्सिंग का उपयोग केवल तभी किया जाना चाहिए जब ग्राहक सुविधाओं में कटौती के लिए सहमत हो, गुणवत्ता में नहीं।[14] प्रोजेक्ट्स के सबसे बड़े वर्ग के बीच सशक्त रूप से अपनाने के बहुत कम प्रमाण हैं।[13]

टाइमबॉक्सिंग को कुछ उल्लेखनीय सॉफ्टवेयर विकास पद्धतियों द्वारा अपनाया गया है:

  • डायनेमिक सिस्टम डेवलपमेंट मेथड (डीएसडीएम)[12]
  • लीन सॉफ्टवेयर विकास में, कानबन के साथ पुल शेड्यूलिंग अल्पकालिक समय प्रबंधन प्रदान करता है। एक बड़ी और जटिल प्रणाली विकसित करते समय, जब दीर्घकालिक योजना की आवश्यकता होती है तो टाइमबॉक्सिंग ऊपर स्तरित किया जाता है।[15]
  • रैपिड एप्लिकेशन डेवलपमेंट (आरएडी) सॉफ्टवेयर विकास प्रक्रिया में पुनरावृत्तीय विकास और सॉफ़्टवेयर प्रोटोटाइप की सुविधा होती है। स्टीव मैककोनेल के अनुसार, टाइमबॉक्सिंग आरएडी के लिए एक "सर्वोत्तम अभ्यास" है और एक सामान्य टाइमबॉक्स की अवधि 60-120 दिन होनी चाहिए।[14]
  • स्क्रम टाइमबॉक्सिंग और इटरेटिव डेवलपमेंट के विचारों से प्रभावित था।[16] नियमित टाइमबॉक्स वाली इकाइयाँ जिन्हें स्प्रिंट के नाम से जाना जाता है, विकास की मूल इकाई बनती हैं।[17] स्प्रिंट की सामान्य अवधि 30 दिनों से कम होती है।[18][19] स्प्रिंट योजना, स्प्रिंट पूर्वव्यापी और स्प्रिंट समीक्षा बैठकें समयबद्ध हैं।[18]
  • चरम प्रोग्रामिंग पद्धतियों में, विकास योजना को प्रायः 1, 2 या 3 सप्ताह की अवधि के पुनरावृत्तियों में समयबद्ध किया जाता है। व्यवसाय प्रत्येक पुनरावृत्ति से पहले लंबित उपयोगकर्ता कहानियों का पुनर्मूल्यांकन करता है।[20]

एजाइल सॉफ्टवेयर विकास योजना संचालित से मूल्य संचालित विकास की ओर बढ़ने की वकालत करता है। गुणवत्ता और समय तय है लेकिन कार्यक्षेत्र में लचीलेपन की अनुमति है। सबसे महत्वपूर्ण सुविधाएँ पहले प्रदान करने से वॉटरफॉल मॉडल की तुलना में निवेश पर पहले रिटर्न मिलता है।[7]

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


व्यक्तिगत समय प्रबंधन में

Main article: टाइमब्लॉकिंग

टाइमबॉक्सिंग का उपयोग व्यक्तिगत कार्यों के लिए किया जा सकता है, जिस स्थिति में यह समय के कम पैमाने (उदाहरण के लिए, तीस मिनट) और डिलिवरेबल्स (उदाहरण के लिए, प्रोजेक्ट डिलिवरेबल के बजाय एक घरेलू काम) का उपयोग करता है, और इसे प्रायः टाइमब्लॉकिंग कहा जाता है।

यह भी कहा जाता है कि व्यक्तिगत टाइमबॉक्सिंग पूर्णतावादी प्रवृत्तियों पर अंकुश लगाने में मदद करने के लिए लाइफ हैकिंग के रूप में कार्य करती है (एक निश्चित समय निर्धारित करके और किसी कार्य के लिए अधिक प्रतिबद्ध न होकर) जो रचनात्मकता और ध्यान को भी बढ़ा (तात्कालिकता या बढ़े हुए दबाव की भावना पैदा करके) सकती है।[21]


अन्य तरीकों से संबंध

टाइमबॉक्सिंग अन्य व्यक्तिगत समय प्रबंधन विधियों में मूलभूत अंग के रूप में कार्य करता है:

  • पोमोडोरो तकनीक मन को ठीक होने की अनुमति देने वाले ब्रेक द्वारा अलग किए गए केंद्रित एकाग्रता के 25 मिनट के टाइमबॉक्स पर आधारित है।[22]
  • एंडी हंट एसएमएआरटी में टाइमबॉक्सिंग को अपना 'टी' बताते हैं।[23]


यह भी देखें

संदर्भ

  1. ↑ Boehm, Barry W.; Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline: A Guide for the Perplexed (in English). Addison-Wesley Professional. ISBN 9780321186126.
  2. ↑ "Timeboxing – why you should use it?". Firmbee (in English). 2022-01-17. Retrieved 2022-01-25.
  3. ↑ What are the Triple Constraints in Project Management Archived 2006-08-20 at archive.today, article by Rod Hutchings on Project Management Australia Archived 2009-02-16 at the Wayback Machine (22 Oct 2008)
  4. ↑ Chatfield, Carl. "परियोजना प्रबंधन में एक लघु पाठ्यक्रम". Microsoft.
  5. ↑ Dobson, Michael (2004). परियोजना प्रबंधन में तिहरी बाधाएँ. Vienna, Va: Management Concepts. ISBN 1-56726-152-3.
  6. ↑ 6.0 6.1 Kanabar, Vijay (2008). MBA Fundamentals: Project Management. New York: Kaplan Pub. p. 51. ISBN 978-1-4277-9744-5.
  7. ↑ 7.0 7.1 Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. pp. 17–19. ISBN 978-0-321-63584-6.
  8. ↑ Snedaker, Susan; Nels Hoenig (2005). आईटी परियोजना प्रबंधन में धोखा कैसे दें. Syngress. ISBN 1-59749-037-7.
  9. ↑ Beck, Kent (2000). Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. pp. 15–19. ISBN 0-201-61641-6.
  10. ↑ Dangelo, Mark (2005). Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose. New York: iUniverse. p. 53. ISBN 978-0-595-67081-9.
  11. ↑ Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals.
  12. ↑ 12.0 12.1 12.2 Jennifer., Stapleton (1997). DSDM, dynamic systems development method: the method in practice. Harlow, England: Addison-Wesley. ISBN 0201178893. OCLC 36755892.
  13. ↑ 13.0 13.1 For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 function point) projects ranked 7 and rated a "Best Practice" by the survey in Jones, Capers (2010). Software engineering best practices lessons from successful projects in the top companies. New York: McGraw-Hill. ISBN 978-0-07-162162-5.
  14. ↑ 14.0 14.1 14.2 14.3 14.4 McConnell, Steve (1996). Rapid Development: taming wild software schedules. Redmond, Wash: Microsoft Press. pp. 575–583. ISBN 1-55615-900-5.
  15. ↑ Poppendieck, Mary (2010). Leading Lean Software Development: Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. pp. 137–140. ISBN 978-0-321-62070-5.
  16. ↑ Coplien, James (2010). एजाइल सॉफ्टवेयर डेवलपमेंट के लिए लीन आर्किटेक्चर. Chichester Hoboken, N.J: Wiley. p. 25. ISBN 978-0-470-68420-7.
  17. ↑ Cohn, Mike (2010). Succeeding with Agile: Software Development using Scrum. Upper Saddle River, NJ: Addison-Wesley. pp. 257–284. ISBN 978-0-321-57936-2.
  18. ↑ 18.0 18.1 Schwaber, Ken (2009). स्क्रम के साथ चुस्त परियोजना प्रबंधन. New York: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0.
  19. ↑ Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. p. 15. ISBN 978-0-321-63584-6.
  20. ↑ Beck, Kent (2000). Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. pp. 85–96. ISBN 0-201-61641-6.
  21. ↑ Pash, Adam (2011). लाइफ़हैकर अधिक स्मार्ट, तेज़ और बेहतर तरीके से काम करने के लिए मार्गदर्शिका. Indianapolis, Ind: Wiley. Hack 29. ISBN 978-1-118-13345-3.
  22. ↑ Nöteberg, Staffan (2009). पोमोडोरो तकनीक का चित्रण. Raleigh, N.C: Pragmatic Bookshelf. ISBN 978-1-934356-50-0.
  23. ↑ Hunt, Andrew (2008). Pragmatic thinking and learning: refactor your wetware. Raleigh: Pragmatic. ISBN 978-1-934356-05-0.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=टाइमबॉक्सिंग&oldid=214812’