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

From Vigyanwiki
(text)
Line 72: Line 72:
[[Category: Machine Translated Page]]
[[Category: Machine Translated Page]]
[[Category:Created On 25/06/2023]]
[[Category:Created On 25/06/2023]]
[[Category:Vigyan Ready]]

Revision as of 13:05, 10 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=211439’