वित्त में पागल फुर्तीली

सिस्टम के बारे में

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

परियोजना के विकास में लगभग 3 साल लगे और लगभग 20 इंजीनियरों की एक टीम। इस परियोजना में एक भी परियोजना प्रबंधक, समन्वयक, परियोजना योजना, गैंट आरेख, वास्तुकला दस्तावेज, आवश्यकताओं के विनिर्देश और परीक्षण योजनाएँ नहीं हैं।

उत्कृष्ट प्रौद्योगिकी के लिए पुरस्कार के अलावा, कंपनी को अपने सरल और कुशल विकास प्रक्रिया के लिए फुर्तीली समुदाय में मान्यता प्राप्त है। मैं इस पोस्ट में उनके बारे में बात करना चाहता हूं।

प्रक्रिया के बारे में

कंपनी अपनी एजाइल-आधारित विकास प्रक्रिया का उपयोग करती है। सिस्टम का विकास कभी नहीं रुकता है, और नए ग्राहकों की आवश्यकताओं को नियमित रूप से पूरा किया जाता है, हर 2 सप्ताह में एक नया संस्करण जारी करने के लिए एक चक्र के साथ।

कंपनी के डेवलपर्स को 3-4 समूहों में विभाजित किया गया है, जिनमें से प्रत्येक एक निश्चित दिशा में लगे हुए हैं। प्रत्येक समूह में 5-6 प्रोग्रामर, एक परीक्षक और एक विश्लेषक होता है।

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

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

योजना की दीवार को लंबवत रूप से टीमों में विभाजित किया गया है, और क्षैतिज रूप से पुनरावृत्तियों में विभाजित किया गया है। पूरी दीवार में एक वर्ष के एक चौथाई, 6 पुनरावृत्तियों के कार्य शामिल हैं। नए कार्ड बहुत ऊपर से चिपके हुए हैं, और बैकलॉग सबसे नीचे है। उनके बीच - 6 पुनरावृत्तियों।

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

विश्लेषक अगले पुनरावृत्ति कार्ड के लिए विस्तृत आवश्यकताओं को एकत्र करता है। आवश्यकताएँ मिंगले प्रणाली में दर्ज की जाती हैं। एक नियमित कार्ड में 5-10 स्वीकृति मानदंड होते हैं, जैसे "यदि व्यापारी ने ऑर्डर आकार निर्धारित किया है, तो उसे अगले परिवर्तन तक सहेजा जाना चाहिए"

पुनरावृति में काम के बारे में

प्रत्येक दूसरे बुधवार को सुबह 10 बजे एक पूर्वव्यापी शुरुआत होती है और अगले पुनरावृत्ति की शुरुआत होती है। बैठक कक्ष या सोफे (जो पर्याप्त नहीं है) के आसपास टीमें बिखरी हुई हैं, और एक केक खाकर बैठक शुरू करें।

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

पूर्वव्यापी समाप्त होने के बाद, रोटेशन होता है, जिसके परिणामस्वरूप प्रत्येक टीम एक डेवलपर को खो देती है और दूसरे को प्राप्त करती है।

फिर नई कहानियों का विश्लेषण शुरू होता है, जहां विश्लेषक अगले पुनरावृत्ति की योजना के बारे में बात करते हैं। डेवलपर्स आवश्यकताओं को स्पष्ट करके प्रश्न पूछते हैं।

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

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

आमतौर पर पहला काम परीक्षण लिखना है। यह प्रोग्रामर और परीक्षक, परीक्षक और विश्लेषकों, या विश्लेषकों और प्रोग्रामर के एक जोड़े द्वारा किया जाता है। परीक्षण स्वीकृति मानदंडों के आधार पर लिखे गए हैं।
सभी परीक्षण निष्पादन योग्य विनिर्देश हैं। टेस्ट सिस्टम कोड का एक सीधा हिस्सा हैं, और निरंतर एकीकरण (CI) वातावरण में भाग लेते हैं। फिलहाल हमारे पास लगभग 20,000 परीक्षण हैं, और प्रत्येक प्रतिबद्ध इन परीक्षणों के खिलाफ स्वत: परीक्षण के अधीन है।

प्रत्यक्ष विकास हमेशा जोड़े में होता है। सबसे अधिक बार, 2 प्रोग्रामर विकास में लगे हुए हैं, हालांकि यह अक्सर एक परीक्षक या एक विश्लेषक का संयोजन होता है। जोड़ी प्रोग्रामिंग के परिणामस्वरूप, कोड की गुणवत्ता बढ़ जाती है, सिस्टम का ज्ञान वितरित किया जाता है (प्रलेखन की आवश्यकता को समाप्त करना), और अधिक सही निर्णय किए जाते हैं।

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

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

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

यह विकास प्रक्रिया, जो वित्तीय संगठनों के लिए atypical है, लंदन डायवर्स एसेट्स एक्सचेंज (LMAX) में उपयोग की जाती है। सभी नियोजन को सार्वजनिक प्रदर्शन पर रखा गया है, प्रत्येक डेवलपर संपूर्ण प्रणाली के संचालन और लगभग हर विशिष्ट कार्य को जानता है। "बाँधना" और "भीड़" विनिर्देशों के परिणामस्वरूप, संगठन के विभिन्न हिस्सों के बीच कोई संघर्ष नहीं है। हर कोई हमेशा एक नया समाधान पेश कर सकता है, अपने आप को पड़ोसी टीम की "दीवार पेंटिंग" से परिचित करा सकता है। दस्तावेज़ एक वर्ग के रूप में गायब हैं, ईमेल व्यावहारिक रूप से उपयोग नहीं किया जाता है। योजनाओं पर चर्चा के लिए कोई निर्णय समितियां और उबाऊ बैठकें नहीं हैं ...

वैसे, हमें हमेशा प्रतिभाशाली जावा परीक्षक और प्रोग्रामर की आवश्यकता होती है।

पीएस लंदन में काम करते हैं