Microsoft DevDiv TFS - भागों 6 (+ जोड़) और 7 का उपयोग कैसे करता है

कई परियोजनाओं पर नज़र रखना।

आज मैं आपको यह दिखाने जा रहा हूं कि एक साथ कई परियोजनाओं में परिवर्तन को रिपोर्ट करने के लिए रिपोर्ट का उपयोग करके टीएफएस का उपयोग करके सभी परियोजनाओं के प्रबंधन के लिए हमारा कार्यक्रम प्रबंधक कैसे जिम्मेदार है।

शुरुआत के लिए, मैं आपको इस प्रक्रिया के बारे में थोड़ा बता दूं।

हर हफ्ते हमने प्रबंधकों की बैठकें कीं, जिसका उद्देश्य उन परियोजनाओं के स्वास्थ्य की जाँच करना था जिन पर हमने काम किया था।

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

हर हफ्ते, जिम ने हमें एक रिपोर्ट दिखाई जो इस तरह दिखती थी। उन्होंने हमारे द्वारा काम की गई सभी परियोजनाओं को प्रदर्शित किया।

कुछ स्पष्टीकरण:

• ग्रीन - पूरी परियोजना के संबंध में पूरा काम का प्रतिशत।
• पीला - अंतिम रिपोर्टिंग अवधि (आमतौर पर 1 सप्ताह) के लिए पूरा काम का प्रतिशत।
• लाल - आगामी काम के घंटे की संख्या।
• कार्यात्मक पर काम की अंतिम तिथि निष्पादक के नाम के साथ है।

इस रिपोर्ट के प्रदर्शित होने के बाद, जिम ने इस तरह के सवाल पूछना शुरू किया:

• पिछले एक सप्ताह में कोई प्रगति क्यों नहीं देखी गई?
• इतना कम क्यों किया जाता है?
• आपके पास केवल 1450 कार्य घंटे बचे हैं, इस तथ्य के बावजूद कि अंतिम तिथि 3 जनवरी निर्धारित है। क्या आपको अभी भी लगता है कि आप इन समयसीमाओं को पूरा करेंगे?

जिम ने मेज पर अपनी मुट्ठी पीटना शुरू नहीं किया और पूछा, "क्या आप कुछ नहीं कर रहे हैं?" डेटा में एक विरोधाभास दिखाई दिया, और उसने इसे आवाज़ दी।

यहाँ कुछ जवाब दिए गए हैं:

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

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

ग्रीग बोअर

अनुपूरक।

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

उद्धरण:

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

साथ

प्रोफ़ाइल [उपाय]। [ValueOfCompletedWorkAsOfNDaysAgo] के रूप में

(

[उपाय]। [Microsoft_VSTS_Scheduling_CompletedWork],

[कार्य आइटम]। [Microsoft_DeveloperDivision_Classifications_Group]। [सभी]।

[कार्य आइटम]। [Microsoft_DeveloperDivision_Classifications_Project]। [सभी]।

[कार्य आइटम]। [System_Title]। [सभी]

[कार्य आइटम]। [System_State]। [सभी];

[कार्य आइटम]। [Microsoft_DeveloperDivision_Features_RiskLevel]। [सभी]

STRTOMEMBER (@MDXDateForWorkCompletedSinceDate)

)

प्रोफ़ाइल [उपाय]। [ValueOfRemainingWorkAsOfNDaysAgo] के रूप में

(

[उपाय]। [Microsoft_VSTS_Scheduling_RemainingWork],

[कार्य आइटम]। [Microsoft_DeveloperDivision_Classifications_Group]। [सभी]।

[कार्य आइटम]। [Microsoft_DeveloperDivision_Classifications_Project]। [सभी]।

[कार्य आइटम]। [System_Title]। [सभी]

[कार्य आइटम]। [System_State]। [सभी];

[कार्य आइटम]। [Microsoft_DeveloperDivision_Features_RiskLevel]। [सभी]

STRTOMEMBER (@MDXDateForWorkCompletedSinceDate)

)

प्रोफ़ाइल [उपाय]। [फ़ीचरइंडेट] के रूप में

एक्सट्रैक्ट (

NonEmpty (

[Microsoft_DeveloperDivision_Features_DateEnd]। [दिनांक]। [दिनांक] *

[कार्य आइटम]। [System_Id]

[उपाय]। [वर्तमान कार्य आइटम गणना]

)

[Microsoft_DeveloperDivision_Features_DateEnd]। [दिनांक]

) .Item (0) .Member_Value

का चयन करें

खाली न होना

{

[उपाय]। [FeatureEndDate],

[उपाय]। [वर्तमान कार्य आइटम Microsoft_VSTS_Scheduling_CompletedWork],

[उपाय]। [वर्तमान कार्य आइटम Microsoft_VSTS_Scheduling_RemainingWork],

[उपाय]। [ValueOfCompletedWorkAsOfNDaysAgo],

[उपाय]। [ValueOfRemainingWorkAsOfNDaysAgo]

} COLUMNS पर,

NonEmpty (

STRTOSET (@WorkItemMicrosoftDeveloperDivisionClassificationsGroup, समेकित *)

STRTOSET (@WorkItemMicrosoftDeveloperDivisionClassificationsProject, CONSTRAEDED *

[कार्य आइटम]। [System_Id]। [System_Id] *

[कार्य आइटम]। [Microsoft_DeveloperDivision_Features_RiskLevel]। [Microsoft_DeveloperDivision_Features_RiskLevel] *

[कार्य आइटम]। [System_Title]। [System_Title]

[उपाय]। [वर्तमान कार्य आइटम गणना]

) आयाम PRO_ERTIES PRO_ERAP, ROWS पर MON_UNIQUE_NAME

[करंट वर्क आइटम] से

कहां

(

[कार्य आइटम]। [System_WorkItemType]। & [Orcas फ़ीचर]]

स्ट्रैटोसैट (@WorkItemSystemState, CONSTRAINED)

) "



एफसी उच्च स्तर Summary- की-Work.rdl



ग्रीग बोअर

जोखिम ट्रैकिंग

पिछली बार हमने एक ही समय में कई परियोजनाओं की प्रगति पर नज़र रखने के बारे में बात की थी, इसमें हम इन परियोजनाओं में ट्रैकिंग जोखिमों के बारे में बात करेंगे।

सबसे पहले, आइए एक फीचर रिकॉर्ड की प्रगति टैब देखें।



इस तस्वीर में आप जोखिमों से संबंधित दो क्षेत्रों को देखते हैं। जोखिम स्तर - यातायात प्रकाश के प्रकार का एक संकेतक। हरा = हम समय पर काम पूरा करेंगे। पीला = जोखिम हैं। लाल = हम समय पर काम पूरा नहीं करेंगे। दूसरे क्षेत्र में व्याख्यात्मक पाठ होता है।

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

परिणाम निम्नलिखित रिपोर्ट है:



यह रिपोर्ट एक्सेल में बनाई गई थी, जिसमें एक क्वेरी का इस्तेमाल किया गया था जहां रिस्क लेवल <> ग्रीन। एक्सेल का उपयोग करके पृष्ठभूमि का रंग जोड़ा गया।

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

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

आप सोच सकते हैं कि उपरोक्त रिपोर्ट बर्फबारी / बर्फीले पूर्वानुमान की तरह है। हम सिएटल में बर्फबारी को बहुत अच्छी तरह से संभाल नहीं पाते हैं। आप बस इस पर हंस सकते हैं, हालांकि, मुझे लगता है कि स्थानीय लोगों ने मुझे पूरी तरह से समझा। :)

इस प्रणाली को कैसे काम करना है?

आप पूछ सकते हैं: किसी को ईमानदारी से अपने जोखिम को पीले या लाल के रूप में क्यों दिखाना चाहिए? सिर्फ उन्हें हरा क्यों नहीं छोड़ा? यह इतना गर्म नहीं होगा, यह होगा?

मेरे पास इसके दो उत्तर हैं।

पहले वाला। बेशक, अगर परियोजना में समस्याएं हैं, तो टीम को तिथियों को शिफ्ट करना होगा। अगर अचानक जोखिमों को बदले बिना 4 सप्ताह से एक दिन की तारीख में बदलाव किया जाता है, तो अन्य लोग पूछ सकते हैं: "आपने इस बारे में पहले क्यों नहीं लिखा?" या "यदि आप इसके बारे में पहले से जानते थे, तो आपने हमें क्यों नहीं बताया?" यह टीमों के बीच अखंडता बनाए रखने में मदद करता है।

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

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