एक रूसी स्टार्टअप में सॉफ्टवेयर विकास के लिए एक लचीला दृष्टिकोण लागू करने का एक जीवित उदाहरण

हाय, हब्रद्रग। क्या आपको लगता है कि सॉफ्टवेयर विकास में झरना ( झरना ) केवल नस्लीय-सही दृष्टिकोण है? हाँ या नहीं - बिल्ली को जल्दी करो।
उदाहरण के लिए, हम अपने स्मार्टनेट वेब सेवा को विकसित करने के लिए ईएक्सटीएमई प्रोग्रामिंग तकनीकी प्रथाओं के साथ स्क्रैम का उपयोग करते हैं। हम अपने ग्राहकों को हर 2 सप्ताह (रिलीज चक्र) पर व्यापार मूल्य कैसे दे सकते हैं। मुझे लगता है कि लीन स्टार्टअप करने वाले लोगों के लिए हमें जिम्मेदार ठहराया जा सकता है।

Scrum c XP का उपयोग मेरी पिछली टीम में भी किया गया था, लेकिन यहां हम विषय को और अधिक उत्पादक रूप से विकसित कर रहे हैं।
मैं आपको संक्षेप में scrum और XP की बुनियादी तकनीकों को बताने की कोशिश करूंगा, जिन्हें हमने दक्षता बढ़ाने के लिए लागू करने, समर्थन करने, संशोधित करने और सुधार करने में कामयाब रहे हैं।

0. हमारी टीम

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

1. मैं बदलाव

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

हम परियोजना के प्रत्येक चरण में कितने लचीले हैं?

2. योजना

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

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

2.5 रेटिंग

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

3. काम करने की स्थिति

हमारी टीम के लिए एक अलग और उज्ज्वल कार्यालय है। कुछ भी हमें कार्यों पर चर्चा करने, रैलियां आयोजित करने और बाधाओं को खोजने और समाप्त करने से रोकता है। हर सुबह 11-30 बजे हम एक स्टैंड-अप मीटिंग करते हैं, जो सबसे अच्छी परंपराओं में 15 मिनट तक चलती है। हम गति की गणना करते हैं और इसे हर समय बढ़ते रहने की कोशिश करते हैं, न कि अपने आप में वृद्धि को एक अंत के रूप में गिनते हैं।
प्रोग्रामिंग सहयोगी के बगल में बैठना अपराध नहीं माना जाता है। बुनियादी ढांचे की समस्याओं और पर्यावरणीय समस्याओं को सुलझाने में सहायता को एक सम्मानजनक काम माना जाता है।

4. सिस्टम डिजाइन

सबसे कठिन हिस्सा विकास का संचालन करना है, ताकि सिस्टम अंतिम उपयोगकर्ता और टीम के सभी प्रोग्रामर के लिए सरल और समझ में आता है। यदि यह सुविधा स्पष्ट नहीं है, यदि गलियारे के 2 लोग पीओ या डेवलपर्स क्या योजना बना रहे हैं, यह पता लगाने के लिए कंप्यूटर पर नहीं बैठ सकते हैं, तो कुछ को बदलने की आवश्यकता है। हम, एक टीम के रूप में, सादगी की दिशा में आगे बढ़ रहे हैं, यह हमेशा काम नहीं करता है, लेकिन हम कोशिश करते हैं।
यह उन कार्यों पर लागू होता है जिनके लिए बाजार ने अभी तक जरूरत नहीं दिखाई है। मैं उन्हें जोड़ना चाहूंगा, ऐसा लगता है कि यह आवश्यक है, लेकिन उनका उपयोग कौन करेगा?

5. विकास की प्रक्रिया में

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

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

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

बाकी सब कुछ, प्रत्येक पुनरावृत्ति के अंत में, हम एक डेमो रखते हैं, दूसरों को घमंड करते हैं, अन्य विभागों के सहयोगियों ने जो हमने पुनरावृत्ति के लिए किया था। हमें उपयोगी और बहुत सुझावों का एक गुच्छा नहीं मिलता है, और यह भी होता है कि हम ऐसे कीड़े ढूंढते हैं जिन्हें पहले नहीं देखा गया है।

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

यदि आपका लक्ष्य एक लहर के शिखर पर होना है और केवल वास्तविक झरने का आनंद लेना है, तो अपने क्लाइंट को जितनी बार संभव हो अपडेट प्रदान करें। और scrum और xp इसमें आपकी मदद करेंगे।


PS यदि आप एक हब्रद्रग हैं, तब भी सोचें कि हम जो कर रहे हैं, वह वैचारिक रूप से गलत है या इसके विपरीत आप प्रशंसा करना चाहते हैं, तो टिप्पणियों में आपका स्वागत है।