मेरी कंपनी में SCRUM और उसका कार्यान्वयन। शुरुआत

शुरुआत prosaic है। अर्थात्, मैं कैसे काम करता हूँ। कंपनी का मालिक आता है, मुझे काम बताता है, मैं खुद को कुचलता हूं और करता हूं। फिर एक और व्यक्ति मेरी टीम में आया और मैंने हम दोनों के कार्यों को विभाजित करना शुरू किया। यदि मैं सफल नहीं हुआ, या किसी प्रकार का प्लग था, तो मैंने डेवलपर को दूसरी तकनीक की ओर मोड़ दिया। उन्होंने मेरी मदद की और तकनीकी पक्ष पर मेरे बॉस की तरह थे। उदाहरण के लिए: जब मैं Zend पर एक नई परियोजना लिखना चाहता था, और Codeigniter'e पर नहीं (जिस पर हमारे पास सभी परियोजनाएं हैं), उसने मुझे दो सप्ताह दिए: यदि मेरे पास समय नहीं है, तो इसे करने के लिए दो दिनों में जल्दी से Codeigniter'e पर। मेरे काम में जो एकमात्र नकारात्मक मैंने देखा, वह था मेरे हिस्से में परीक्षण की पूरी कमी और सामान्य रूप में परीक्षक।

आपने SCRUM को लागू करने का निर्णय क्यों लिया

तो, हमारे बगल में एक और परियोजना है। इसमें लोग लगातार बहस करते हैं, चिल्लाते हैं और दो, तीन घंटे तक किसी बात पर चर्चा करते हैं। हमारे पक्ष में उनके पास कोई व्यक्त नेता नहीं है। और सब ठीक हो जाएगा, लेकिन यहां हमारे मठ में घोटाले आए, जो अनिवार्य रूप से इस विभाग से एक टीम बनाने का इरादा था, और हमारे विभाग को कंपनी के लिए मान लिया गया था, अगर हर जगह लागू किया गया। पहले मुझे खुशी हुई, अब हमारे पास दो टीमों के लिए एक परीक्षक है। और विक्रम विकास में, आपको इकाई परीक्षण लिखना होगा। "कूल," मैंने सोचा, अब वे शनिवार को मुझे नहीं लिखेंगे: "मरम्मत - कुछ काम नहीं कर रहा है।" और सब कुछ ओपनवर्क में होगा।

और इसलिए प्रशिक्षण चला गया

यह धारणा दुगुनी है, मैंने महसूस किया कि अब न केवल पड़ोसियों को एक या दो घंटे तक चिल्लाहट और चर्चा होगी, अब यह "हमारी भूमि" पर आ जाएगा। अब हम में से प्रत्येक के पास एक व्यक्तित्व है, प्रत्येक अपने वजनदार राय व्यक्त करता है। और किसी भी चीज के लिए कोई भी जिम्मेदार नहीं है क्योंकि टीम अब हर चीज के लिए जिम्मेदार है। हमारे पास प्रशिक्षण का एक कार्य था, एक लेगो निर्माता था, एक ग्राहक था और दो टीमें थीं। दो घंटे का समय। कार्य एक शहर का निर्माण करना है। हमने ग्राहक के लिए मुख्य बात को उजागर करके शुरू किया। जिसके बिना उसकी परियोजना बस मौजूद नहीं होगी। कार्य की जटिलता को तोड़ें। करने लगे। और फिर गड़बड़ अपने सभी महिमा में हो गया। जो कोई पहले एक आकलन किए गए कार्य के साथ कागज के टुकड़े को पकड़ लेता है, और जब उससे पूछा जाता है कि क्या मैं आपकी मदद कर सकता हूं, तो वह उसे जंगल में भेज देता है। इस पुनरावृत्ति में, सबसे चुस्त कंस्ट्रक्टर को इकट्ठा किया गया था, बाकी लोगों ने बस विवरणों में चारों ओर पोक किया और यह दिखावा किया कि वे कुछ महत्वपूर्ण हैं। अगली पुनरावृत्ति में, फिर से अलग न खड़े होने के लिए, सभी ने एक ऐसा काम पकड़ लिया जिसे वह खुद नहीं खींच पा रहे थे। यह भरा। खैर, सब कुछ अभिभूत करने के लिए नहीं, ग्राहक ने जो स्थापित किया था, उसका लगभग 50-70 प्रतिशत हिस्सा कहीं ले गया। यह ध्यान दिया जाना चाहिए कि समय में निर्माणकर्ता में जटिलता और खुद को चुनने का आकलन बहुत अलग था। एक घंटे से अधिक समय तक मूल्यांकन किया गया ... और क्या ध्यान दिया जाना चाहिए, लोगों को खुशी हुई जब उन्हें पता चला कि स्प्रिंट एक विफलता हो सकती है। और हाँ, हमने एक शहर बनाया, लेकिन एक स्टोर के बिना। स्टोर विफल हो गया और ग्राहक का पैसा भाग गया। अब निवासी कीड़े खाएंगे।

परिणाम

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

सामान्य तौर पर, हम सर्वश्रेष्ठ की उम्मीद करते हैं।