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

From Vigyanwiki
(Created page with "{{short description|Time management method}} {{software development process}} एजाइल सॉफ्टवेयर डेवलपमेंट#एजाइल सि...")
 
(Text)
Line 2: Line 2:
{{software development process}}
{{software development process}}


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


== परियोजना प्रबंधन में ==
== प्रोजेक्ट प्रबंधन में ==


टाइमबॉक्सिंग का उपयोग [[ परियोजना की योजना बना ]] तकनीक के रूप में किया जाता है। शेड्यूल को कई अलग-अलग समयावधियों (टाइमबॉक्स) में विभाजित किया गया है, प्रत्येक भाग की अपनी डिलिवरेबल्स, [[समय सीमा]] और बजट है।{{Citation needed|date=November 2011}}कभी-कभी अनुसूची को स्वतंत्र चर (SAIV) के रूप में संदर्भित किया जाता है।<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 29: Line 31:
=== सॉफ्टवेयर विकास में अपनाना ===
=== सॉफ्टवेयर विकास में अपनाना ===


कई सफल सॉफ़्टवेयर विकास परियोजनाएँ टाइमबॉक्सिंग का उपयोग करती हैं, विशेषकर छोटी परियोजनाएँ।<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/>


टाइमबॉक्सिंग को कुछ उल्लेखनीय सॉफ्टवेयर विकास पद्धतियों द्वारा अपनाया गया है:
टाइमबॉक्सिंग को कुछ उल्लेखनीय सॉफ्टवेयर विकास पद्धतियों द्वारा अपनाया गया है:
Line 36: Line 38:
* [[रैपिड अनुप्रयोग का विकास]] (आरएडी) [[सॉफ्टवेयर विकास प्रक्रिया]] में [[पुनरावृत्तीय और वृद्धिशील विकास]] और [[सॉफ़्टवेयर प्रोटोटाइप]] की सुविधा है। स्टीव मैककोनेल के अनुसार, टाइमबॉक्सिंग आरएडी के लिए एक सर्वोत्तम अभ्यास है और एक सामान्य टाइमबॉक्स की लंबाई 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>
* [[रैपिड अनुप्रयोग का विकास]] (आरएडी) [[सॉफ्टवेयर विकास प्रक्रिया]] में [[पुनरावृत्तीय और वृद्धिशील विकास]] और [[सॉफ़्टवेयर प्रोटोटाइप]] की सुविधा है। स्टीव मैककोनेल के अनुसार, टाइमबॉक्सिंग आरएडी के लिए एक सर्वोत्तम अभ्यास है और एक सामान्य टाइमबॉक्स की लंबाई 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 = 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>{{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>
* [[चरम कार्यक्रम]] पद्धतियों में, विकास योजना को आम तौर पर 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>
* [[चरम कार्यक्रम]] पद्धतियों में, विकास योजना को प्रायः 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=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=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" />
विस्तृत विशिष्टताओं की कमी प्रायः समय की कमी, या वांछित अंतिम परिणाम (समाधान) के ज्ञान की कमी का परिणाम है। कई प्रकार की प्रोजेक्टओं में, और विशेष रूप से सॉफ्टवेयर इंजीनियरिंग में, कार्यान्वयन चरण की शुरुआत से पहले सभी आवश्यकताओं और विशिष्टताओं का विश्लेषण और परिभाषित करना असंभव है। टाइमबॉक्सिंग उन प्रोजेक्टओं के लिए अनुबंध का एक अनुकूल प्रकार हो सकता है जिसमें समय सीमा सबसे महत्वपूर्ण पहलू है और जब सभी आवश्यकताओं को पूरी तरह से पहले से निर्दिष्ट नहीं किया जाता है। यह प्रोजेक्ट के दौरान खोजे गए नए फीडबैक या अंतर्दृष्टि को अंतिम परिणाम में प्रतिबिंबित करने की भी अनुमति देता है।<ref name=":0" />




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


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

Revision as of 17:03, 5 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] ऐसी स्थिति में जब यह स्पष्ट हो जाता है कि कुछ डिलिवरेबल्स को नियोजित समयसीमा के भीतर पूरा नहीं किया जा सकता है, तो या तो समय सीमा बढ़ानी होगी (तय किए गए दायरे को पूरा करने के लिए अधिक समय देने के लिए) या अधिक लोगों को शामिल करना होगा (तय किए गए दायरे को उसी में पूरा करने के लिए) समय)। प्रायः दोनों होते हैं, जिसके परिणामस्वरूप डिलीवरी में देरी होती है, लागत में वृद्धि होती है, और प्रायः गुणवत्ता में कमी आती है (पौराणिक मानव-महीना सिद्धांत के अनुसार)।

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


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

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

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

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

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

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

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

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


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

Main article: Timeblocking

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

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


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

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


यह भी देखें

संदर्भ

  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=211434’