जलप्रपात विकास में एक उपकरण के रूप में निर्णायक ट्रैकर

रूसी आउटसोर्सिंग विकास बाजार में कई कंपनियां नहीं हैं जो चुस्त विकास विधियों का उपयोग करती हैं। हर कोई कैस्केड मॉडल ( झरना ) पर काम करने का आदी है। मोबाइल विकास क्षेत्र पर भी यही बात लागू होती है।

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



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

हमें क्या जरूरत थी?

जब एक टीम - एक परियोजना प्रबंधक, कई डेवलपर्स और एक परीक्षक - विकास पर काम कर रहा है, तो एक इकाई (एक इकाई एक कार्य, कार्य, उपयोगकर्ता कहानी या अन्य) कई राज्यों, एक जिम्मेदार व्यक्ति और एक निष्पादक हो सकता है। इसलिए, कई क्लासिक कार्य प्रबंधक विकास कार्यों के लिए लेखांकन के लिए उपयुक्त नहीं हैं।

अंततः, हम इस निष्कर्ष पर पहुंचे कि इकाई के निम्नलिखित अर्थ होने चाहिए:

• नाम
• अभिनेता
• मालिक (कार्य प्रबंधक)
• टैग (वर्गीकरण के लिए)
• लेबल (किसी उत्पाद के विशिष्ट संस्करण के लिए एक इकाई को निर्दिष्ट करने के लिए)
• sabtaski

और प्रत्येक इकाई को भी एक टिप्पणी जोड़ने में सक्षम होना चाहिए (और एक आरामदायक चर्चा का संचालन) और विभिन्न राज्यों (शुरू नहीं, शुरू, समाप्त, वितरित, आदि)।

मैं क्या कोशिश कर सकता हूं?

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

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

बेसकैंप

यह संभवतः ट्रैकिंग कार्यों, चर्चाओं, फाइलों और इस तरह के लिए सबसे प्रसिद्ध प्रणाली है। इसलिए, यह सरल, विश्वसनीय और सुविधाजनक है। प्रबंधकीय कार्यों के लिए महान - सरल जाँचकर्ता, चर्चाएँ, संयुक्त पाठ संपादन। लेकिन विकास कार्यों के लिए बिल्कुल उपयुक्त नहीं है।

एक कार्य एक विशिष्ट सूची पर हो सकता है, इसमें एक निष्पादक हो सकता है, और एक समय सीमा हो सकती है। मैं ऐसे लोगों को जानता हूं, जिन्होंने उत्पाद के एक विशिष्ट संस्करण (संस्करण 1.0) को कार्य सौंपने के लिए, कार्य नाम ("रेटिंग के लिए वोट [3.4]) में आवश्यक संस्करण लिखा था, और सूचियों का उपयोग कार्य की स्थिति (" अनुसूचित ") निर्धारित करने के लिए किया गया था," इस प्रक्रिया में। "," पूर्ण ")।
शायद सरल परियोजनाओं के लिए - एक प्रबंधक और एक डेवलपर - बेसकैंप काम कर सकता है, लेकिन जब सिस्टम 2-3 डेवलपर, एक परीक्षक और एक परियोजना में एक परियोजना प्रबंधक होता है।

Redmine

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

Jira

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

गितुब इशू

Github रिपॉजिटरी में कई (कंपनियों सहित) स्टोर कोड। हैरानी की बात है, कई लोग नहीं जानते कि उनका अपना कार्य ट्रैकर है। हालांकि, यह भी दिलचस्प है कि इश्यू को कमिट्स से जोड़ा जा सकता है - एक धक्का दिया और कार्यों को बंद कर दिया (यदि क्रमशः उनकी आईडी टिप्पणी में इंगित की गई थी)।

अन्य

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

क्यों महत्वपूर्ण ट्रैकर?

मूल्य निर्धारण

पीटी एक मुफ्त उत्पाद नहीं है, इसमें काफी पैसा खर्च होता है और सास मॉडल पर काम करता है।
$ 100 प्रति माह के लिए, आपको असीमित संख्या में प्रोजेक्ट बनाने और उनमें 25 प्रतिभागियों को शामिल करने का अवसर मिलता है।

मुख्य

पीटी Google ऐप्स के साथ एकीकृत कर सकता है, फिर कर्मचारियों को परियोजनाओं के लिए आमंत्रित करना आसान हो जाता है, और आप तुरंत Google ड्राइव से कार्यों के लिए दस्तावेज़ संलग्न कर सकते हैं (उदाहरण के लिए, वर्णित तर्क के साथ)।

पीटी में कई दिलचस्प और छिपी हुई विशेषताएं हैं, लगभग हर चीज का वर्णन लंबी मदद में किया गया है - www.pivotaltracker.com/help ।

सामान्य नियम

हम उपयोगकर्ता-कहानी की अवधारणा का उपयोग नहीं करते हैं क्योंकि यह वास्तव में है। हमारे साथ यह सिर्फ एक कार्य / कार्य है।



पीटी में 4 प्रकार के कार्य होते हैं- फीचर, बग, कोर और रिलीज। हम निम्न प्रकार का उपयोग करते हैं:

फ़ीचर - कार्यक्षमता को बदलने या सुधारने के लिए बुनियादी कार्य
बग - क्रैशशेटिक्स में बग संख्या, या बग का संक्षिप्त विवरण
रिलीज़ - बिल्ड संस्करण का नाम (अल्फा, बीटा और आरसी)
कोर - प्रबंधक के विकास या रिलीज से सीधे संबंधित कार्य



बैंगनी लेबल एक महाकाव्य है - हम इसे इसके संस्करण संख्या के रूप में उपयोग करते हैं, जो इस कार्यक्षमता पर जाते हैं।

ग्रीन लेबल एक टैग है - हम इसका उपयोग उन वर्गों को इंगित करने के लिए करते हैं, जिनके लिए यह सुविधा लागू होती है (उदाहरण के लिए, ब्लॉग दृश्य)।

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

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




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

प्रत्यक्ष रूप से वर्कफ़्लो

प्रबंधक के हाथ में टीके और संस्करण द्वारा रोडमैप है। कार्य बनाने की प्रक्रिया शुरू होती है। प्रत्येक कार्य आवश्यक रूप से एक महाकाव्य के साथ होता है (यदि यह खरोंच से विकास है, तो संस्करण आमतौर पर 1.0 है) और एक खंड लेबल (हम एक स्क्रीन के रूप में लेबल का उपयोग करते हैं, अर्थात टीम स्क्रीन "टीम" है, मैच स्क्रीन "मैच" है)। सभी कार्य आइसबॉक्स में आते हैं।

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

प्रत्येक कार्य में एक स्तर की जटिलता होती है - यह अंकों में एक प्रकार का सार है (इसका उपयोग वेग की गणना करने के लिए किया जाता है, लेकिन हम इसका उपयोग नहीं करते हैं)। हालाँकि, इस मान को सेट किए बिना, कार्य प्रारंभ नहीं होता है। डेवलपर द्वारा कार्य प्रारंभ करने के बाद, वह प्रारंभ पर क्लिक करता है। कार्य के अंत में, डेवलपर समाप्त पर क्लिक करता है। अगली संभावित कार्य स्थिति वितरित की गई है। ऐसा तब होता है जब डेवलपर असेंबली को कार्य सौंपता है।

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



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

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

जब कार्य वितरित और स्वीकार किया जाता है, तो यह हरा हो जाता है और कार्य बंद हो जाता है।
डेवलपर्स GitHub ID में प्रतिबद्ध कार्य निर्दिष्ट करना पसंद करते हैं, फिर जब धक्का दिया जाता है, तो कार्य स्वचालित रूप से समाप्त हो जाएगा।

विशेषताएं

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

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

Pivotal ट्रैकर में उत्कृष्ट iPhone / iPad अनुप्रयोग हैं (अब के लिए, हालांकि iOS7 के अनुकूलन के बिना), एंड्रॉइड के लिए तृतीय-पक्ष क्लाइंट भी हैं। सभी बाहरी सेवाओं के साथ एकीकरण है - गिटहब, कैम्प फायर, फ्लोडॉक, हिपचैट, ज़ेंडस्क्यू, आदि।

हम ग्राहक के लिए महत्वपूर्ण पहुँच प्रदान नहीं करते हैं, लेकिन इस तरह की आवश्यकता के मामले में, ट्रैकर के पास "केवल पढ़ने" के अधिकार के साथ एक "पर्यवेक्षक" को आमंत्रित करने का अवसर होता है।

निष्कर्ष

Aviasales के हमारे मित्र सर्वर विकास में भी इस उपकरण का उपयोग करते हैं (हालांकि वे धीरे-धीरे इससे कूदते हैं, क्योंकि वे पूर्ण स्क्रैम पर स्विच कर रहे हैं) और मोबाइल विकास विभाग में। Bambk के मित्र सर्वर विकास के लिए Pivotal का उपयोग करते हैं। हम सभी बहुत प्रसन्न हैं कि ऐसा उपकरण बाजार में मौजूद है और वास्तव में वे अवसर प्रदान करता है जिनकी हमें आवश्यकता होती है। छोटे ट्रैकर या किसी बड़ी उत्पाद परियोजना या आउटसोर्सिंग के विकास की गंभीर टीम का उपयोग करके पिकल ट्रैकर को लागू किया जा सकता है।

टिप्पणियों में, मैं यह बताने का सुझाव देता हूं कि विकास के लिए कौन से कार्य प्रबंधक को आपने चुना है और क्यों।
मैं विकास के संदर्भ में निर्णायक ट्रैकर में हमारे वर्कफ़्लो के बारे में सवालों के जवाब देने के लिए तैयार हूं।