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

From Vigyanwiki
(Text)
(Text)
Line 31: 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/>


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

Revision as of 17:21, 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=211435’