एक लचीला विकास पद्धति एक महान विचार है जो बहुत जटिल है। एजाइल लाइट स्थिति को सरल बनाने का एक प्रयास है। एजाइल लाइट को समझाने के लिए आपको पुस्तकों या सेमिनारों की आवश्यकता नहीं है। केवल कुछ बिंदुओं के साथ एक छोटा पाठ आवश्यक है। यहाँ पाठ है।

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

मूल नियम:

• प्रत्येक चक्र का पहला सप्ताह, परियोजना प्रबंधक, डेवलपर्स और अन्य हितधारक आगामी स्प्रिंट का निर्धारण करते हैं। हालांकि एक सप्ताह अलग रखा गया है, स्प्रिंट की योजना में दो घंटे से अधिक नहीं लगेगा, और सही संगठन के साथ, इसमें लगभग 45 मिनट लगेंगे। यह जानबूझकर आसान सप्ताह है: कई लोग सर्फ, पेंट, या कुछ और करने के लिए छुट्टी ले सकते हैं।
  
• शेष तीन सप्ताह में स्प्रिंट चलता है। इस अवधि के दौरान, इंजीनियर उन कार्यों पर काम करते हैं जो नियोजन के दौरान उन्हें आवंटित किए जाते हैं। चूंकि कर्मचारी दूरस्थ हो सकते हैं और समय क्षेत्र में वितरित किए जा सकते हैं, लाइव मीटिंग अक्सर नहीं होती हैं, और अधिकांश संचार एक ट्रैकर (जो ईमेल की तुलना में तेजी से काम करता है) के माध्यम से जाता है। ट्रेलो की तरह एक सामान्य कानबन बोर्ड ठीक है, और एक स्प्रेडशीट की संभावना नहीं है। दैनिक ग्लाइडर को प्रोत्साहित नहीं किया जाता है: परियोजना की समग्र पल्स पूरी तरह से ट्रैकर अपडेट द्वारा ट्रैक की जाती है।
  
• स्प्रिंट शुरू होने के बाद, आप स्प्रिंट में कार्यों को नहीं जोड़ सकते हैं, लेकिन आप उन्हें हटा सकते हैं। यह संदर्भ स्विचिंग को कम करता है, जो अच्छा है।
  
• अधूरे कार्यों को अगले स्प्रिंट योजना सत्र में माना जाता है - और यह कार्य को अगले स्प्रिंट में स्थानांतरित करने का निर्णय लिया जाता है, इसे इच्छा सूची में लौटा देता है, या इसे किसी अन्य डेवलपर को पुन: असाइन करता है।
  
• प्रत्येक कार्य या तो इच्छा सूची में या वर्तमान स्प्रिंट में है। प्रत्येक कार्य को पूरा करने में 4-8 घंटे लगने चाहिए।
  
• जैसा कि पहले ही उल्लेख किया गया है, डेवलपर्स को योजना सप्ताह के दौरान आराम करने की सलाह दी जाती है ताकि मस्तिष्क पिछले स्प्रिंट से उबर सके। यह धर्मयुद्ध नहीं है। डेवलपर्स सप्ताहांत पर काम नहीं करते हैं। यह सब बर्नआउट से बचने में मदद करता है, जो सभी के लिए उपयोगी है।

यद्यपि स्प्रिंट में मुख्य कार्य की योजना बनाई जा सकती है, कभी-कभी कुछ अप्रत्याशित होता है। इन अप्रत्याशित मुद्दों को समर्थन मुद्दे कहा जाता है।

स्प्रिंट प्लानिंग के दौरान, हम उन समर्थन कार्यों को हल करने के लिए समय आवंटित करने का सुझाव देते हैं जो योजना के लिए उत्तरदायी नहीं हैं। उदाहरण के लिए, "अगले स्प्रिंट के दौरान, डेव को समर्थन कार्यों को हल करने के लिए 12 घंटे दिए गए हैं (जिनमें से विवरण बाद में निर्धारित किया जाएगा)।" यह रोटेशन को बनाए रखने के लिए अक्सर उपयोगी होता है, जहां समर्थन मुद्दों के लिए जिम्मेदार डेवलपर (ओं) को प्रत्येक स्प्रिंट में परिवर्तन होता है।

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

व्यवहार में, विभिन्न समूहों के समर्थन कार्यों के लिए अलग-अलग परिभाषाएं हैं। शायद इसका मतलब ग्राहक / ग्राहक सहायता है। शायद अन्य डेवलपर्स का समर्थन। यह तय करना है कि आपकी टीम के लिए इस सामान्य कार्यप्रणाली के कौन से तत्व सर्वोत्तम हैं।

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

डेवलपर्स के लिए एजाइल लाइट

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

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

छुट्टी या छुट्टी पर जाना चाहते हैं, तो आप एक लोफर की तरह लगेंगे जो टीम का समर्थन नहीं करता है। आप एक खुले कार्यालय में काम कर रहे होंगे; हर कोई जानता है कि कोई कब आता है और क्या छोड़ता है, और हर कोई दूसरों से कम काम नहीं करने के लिए एक अनिर्दिष्ट अनुबंध पर हस्ताक्षर करता है। इसलिए, लोग व्यस्त देखना जानते हैं। जब कोई पूछता है कि आप कैसे हैं, तो आप बस जवाब देते हैं: “व्यस्त! मैं व्यस्त हूँ! ”

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

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

लगभग पूरी प्रणाली ऊपर छह बिंदुओं में वर्णित है। इसे अपने लक्ष्यों के अनुसार बदला जा सकता है। लेकिन मैं एजाइल लाइट की एक विशेषता को उजागर करना चाहूंगा। यहाँ हम स्पष्ट रूप से कहते हैं: “अरे, लचीली टीमें उसी तरह से बाहर निकलती हैं जैसे अन्य विकास के तरीके। इंजन की ओवरहीटिंग को रोकने के लिए स्पष्ट नियम लिखना सार्थक हो सकता है, जो इंजीनियरिंग टीम है। ”

चलो इंजन को गर्म करना बंद कर दें। हमारे पास बहुत काम है। वास्तव में, यह एक अथाह गड्ढा है। लेकिन जीवन पूरी तरह से काम, तनाव और अंततः जलने पर खर्च करने के लिए बहुत छोटा है।

प्रबंधकों के लिए एजाइल लाइट

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

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

यह तेल या ईंधन को जोड़े बिना बहुत लंबे समय तक उच्च गति पर कार इंजन चलाने के समान है। अंत में, यह इंजन टूट जाएगा और इसे वापस इकट्ठा करना मुश्किल होगा।

एजाइल लाइट के मूल सिद्धांतों को ऊपर वर्णित किया गया है और आपके लक्ष्यों के अनुसार परिवर्तन के अधीन हैं।

सामान्य प्रश्न + सामान्य कथन

फुर्तीले विकास की दुनिया में एकमात्र सामान्य नियम यह है कि हर कोई इसे गलत करता है। @fwip

तो, इंजीनियरों को सर्फिंग और पेंटिंग के लिए प्रति वर्ष 12 सप्ताह की छूट मिलती है? एक ऐसी दुनिया में यह काम कैसे होगा, जहां हफ्ते में 9-00 से 21-00 छह दिन काम होता है?

मुझे लगता है कि आपके डेवलपर्स को जितना चाहिए उतना आराम करना चाहिए।

मैं ध्यान देता हूं कि 40-घंटे के कार्य सप्ताह को एक बार एक कट्टरपंथी विचार माना गया था। Google ने प्रमुख परियोजनाओं के लिए 80% कार्य समय के साथ शुरू किया, अब हमारे पास 75% है, मैं 2020 के अंत तक इसे घटाकर 10% (फेरिस विधि) करना चाहूंगा।

सिस्टम 996 (सुबह 9 बजे से 9 बजे तक और सप्ताह में 6 दिन) विपरीत दृष्टिकोण है, जो 40 घंटे के कार्य सप्ताह को 72-घंटे तक बढ़ाने का प्रयास करता है। मैं इसे एक प्रतिगमन के रूप में देखता हूं और मुझे लगता है कि हमें ओवरटाइम करना बंद कर देना चाहिए। वास्तव में, यह उत्पादकता में वृद्धि नहीं करता है।

इसके अलावा, आप तय करते हैं कि "रेस्ट वीक" के दौरान क्या करना है: छुट्टी पर जाएं, एक हल्का वर्कलोड या कुछ और असाइन करें। उत्तर विशेष सप्ताह पर निर्भर हो सकता है।

शायद "आसान सप्ताह" "आराम के सप्ताह" की तुलना में लोगों के लिए आसान है। जो आपके लिए अधिक सुविधाजनक है, उसका उपयोग करें।

सर्फिंग और पेंटिंग किसी भी तरह से अनिवार्य नहीं हैं, वे उदाहरण के रूप में दिए गए हैं। मैं खुद भी सर्फ और पेंट नहीं करता हूं।

क्या लोगों को कार्य सौंपे जाते हैं या वे स्वयं भविष्यवाणी करते हैं कि उन्हें क्या मिलेगा?

वे भविष्यवाणी करते हैं। यदि आपका अनुमान गलत है तो यह ठीक है। यह प्रक्रिया का हिस्सा है, और सभी एक टीम में हैं।

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

बेशक! स्प्रिंट मेरे लिए सही है।

क्या कंबन शैली में एक स्लाइडिंग पुनरावृत्ति करना संभव है, जहां शुरुआत और समाप्ति तिथियां अलग-अलग होती हैं और परिस्थितियों पर निर्भर करती हैं?

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

ठीक तीन सप्ताह के स्प्रिंट्स क्यों?

क्योंकि विकास प्लस रिकवरी प्रति वर्ष 13 स्लॉट में रखी गई है। जब चक्र पूरा हो जाता है, तो एक नया शुरू होता है। "आराम" का एक सप्ताह आपको नए स्प्रिंट की शुरुआत से पहले रिबूट करने की अनुमति देता है। यह एक ताल और स्पष्ट, लगातार अंतराल प्राप्त करने के बारे में है।

इसका मतलब यह है कि स्प्रिंट की शुरुआत और समाप्ति तिथियां अक्सर कैलेंडर महीने के मध्य में आती हैं?

हां।

क्या डेवलपर्स स्प्रिंट प्लानिंग में शामिल हैं?

हां। उन्हें बैठक में जाने की मनाही नहीं है। यह आवश्यक नहीं है, खासकर यदि कार्य ट्रैकर अच्छा काम करता है, और टीम ने पिछले स्प्रिंट के दौरान अगले स्प्रिंट के लिए कुछ बिंदुओं पर चर्चा की।

मैं कम बैठकों के लिए हूं। कुछ लोग उन्हें पसंद करते हैं। यदि आप उनमें से एक हैं, तो मुझ पर भरोसा मत करो।

क्या स्प्रिंट की योजना बनाने में एक सप्ताह लगता है?

नहीं, वह बात है। यह एक आसान सप्ताह है।

क्या स्टैंड-अप वास्तव में एक समस्या है?

मेरे अनुभव में, हाँ। आमतौर पर हर कोई एक सर्कल में खड़ा होता है, एक व्यक्ति को 20 मिनट तक सुनता है। बेशक, यह "गलत" दृष्टिकोण है, लेकिन मैंने कभी किसी को इसे सही तरीके से करते नहीं देखा, और दैनिक ग्लाइडर्स को पूरी तरह से छोड़ना पसंद करेंगे। इससे भी कठिन (या कम से कम असुविधाजनक) ऐसा करने के लिए जब आपकी टीम भौगोलिक रूप से वितरित हो। लेकिन अगर वे आपके लिए बहुत मूल्यवान हैं, तो मुझे आपको रोकने न दें।

क्या हमें इसे इस तरह करना चाहिए?

नहीं। कोई भी आपको कुछ भी करने के लिए मजबूर नहीं करता है। ये सिफारिशें हैं, नियम नहीं।

यह कोई धर्म नहीं है।

ये नियम केवल उस अर्थ में राजनीतिक हैं, जिसमें 40 घंटे के कार्य सप्ताह का प्रचार राजनीतिक था।

आपके लिए जो काम करता है वह दूसरों के काम नहीं आ सकता। क्या आप इसके बारे में जानते हैं?

मुझे उस पर यकीन है!

बार-बार दावे

आपको समय पर भविष्यवाणियां करने की आवश्यकता नहीं है, क्योंकि अनुमान असंभव हैं।

पूर्वानुमान को पूर्वानुमान माना जाता है, न कि रक्त में हस्ताक्षरित अनुबंध। इसलिए, यदि उनका सम्मान नहीं किया जाता है, तो यह सामान्य है। हर संभव प्रयास करें और 4 घंटे की वृद्धि में पूर्वानुमान लगाने का प्रयास करें।

डेवलपर्स पर भरोसा नहीं किया जा सकता है, और आपको अपने सभी समय का ट्रैक रखने की आवश्यकता है, क्योंकि यह काम कैसे किया जाता है।

मैं वास्तव में असहमत हूं, लेकिन मैं जल्दी समझा नहीं सकता कि क्यों। विश्वदृष्टि में हमारे मूलभूत अंतर हैं।

यह फुर्तीली नहीं है।

बेशक, चुस्त, वह शीर्षक में सही है।

यह अवास्तविक है।

और फिर भी यह काम करता है।

आप फुर्तीले गलत कर रहे हैं।

दुर्भाग्य से, चंचल के साथ समस्या यह है कि यह सही ढंग से नहीं किया जा सकता है।