Pivotal ट्रैकर के निर्माता कैसे काम करते हैं ... लोगों को डिजाइन करने, प्रबंधित करने और काम पर रखने के बारे में

तकनीकी प्रबंधक (इंजीनियरिंग प्रबंधक) डैनी बर्क (DANNY BURKES) का एक दिलचस्प व्याख्यान है कि कैसे Pivotal लैब्स में उनके काम को www.edx.org पर सर्विस कोर्स के रूप में सॉफ्टवेयर के एक भाग के रूप में प्रकाशित किया जाता है। रूसी में अनुवादित इस व्याख्यान के कुछ अंश, मैं आपके साथ साझा करना चाहता हूं।

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

निर्णायक लैब्स दर्शन (रणनीति)

सॉफ्टवेयर विकास संचार है। लोगों से संवाद करने और सीखने की क्षमता महत्वपूर्ण है।
सॉफ्टवेयर विकास के लिए अनुशासन और कठोरता की आवश्यकता होती है। हम निम्नलिखित प्रथाओं का उपयोग करते हैं:

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

युक्ति

डेवलपर्स के लिए

चरम प्रोग्रामिंग ( EP ) की विशेषताएं:

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

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

  - क्या आप टिप्पणी लिखते हैं?
  - नहीं, हमारे पास परीक्षण हैं।
  - यह "इस कोड का क्या करता है, क्यों कोड को इस तरह लिखा जाता है" जैसी टिप्पणियों के बारे में है?
  - टेस्ट पास करने का एकमात्र कारण कोड (एक ही रास्ता या अन्य) लिखा जाता है।

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

आरपी (परियोजना प्रबंधक, परियोजना प्रबंधक) के लिए

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

लोगों को किराए पर लेना

क्या नहीं करना है?

• डेवलपर्स का साक्षात्कार लेने की स्वीकृत "सर्वोत्तम प्रथाओं" पूरी तरह से गलत हैं।
• 5 घंटे तक लोगों को कमरे में रखने और अपने 10 कर्मचारियों के साथ साक्षात्कार आयोजित करने की आवश्यकता नहीं है।
• विशिष्ट तकनीकी कौशल का परीक्षण करने की आवश्यकता नहीं है। यह विशिष्ट तकनीकों को जानने के बारे में है। यानी, अगर हमारे पास iOS के लिए एक परियोजना है और इस तरह का ज्ञान रखने वाला एक कर्मचारी आता है, तो यह अच्छा है, लेकिन आपको उसके लिए विशेष रूप से देखने की जरूरत नहीं है। वास्तव में इस तथ्य के कारण कि कल आईओएस के लिए परियोजना समाप्त हो जाएगी, आइए एंड्रॉइड के लिए लिखना शुरू करें और आईओएस के लिए विशेषज्ञों के साथ क्या करें? इसे किसी व्यक्ति की सीखने और संवाद करने की क्षमता पर ध्यान देना चाहिए।
• यदि आप ईपी में संलग्न होना चाहते हैं तो आप संचार कौशल की उपेक्षा नहीं कर सकते। भले ही उम्मीदवार सुपर-स्पेशलिस्ट की तरह दिखता हो, लेकिन संवाद करने में कठिनाई होती है या अनुकूल नहीं दिखता है।
• हायरिंग ब्लाइंड नहीं होनी चाहिए। अक्सर कोडिंग कौशल का परीक्षण किए बिना साक्षात्कार आयोजित किए जाते हैं। आप किसी व्यक्ति को इस तरह से कैसे काम पर रख सकते हैं? इसका कोई मतलब नहीं है।

हम लोगों को कैसे काम पर रखें?

पहले भाग में एक जोड़ी साक्षात्कार होता है। लगभग 45 मिनट। शायद स्काइप पर, लेकिन बेहतर नियमित डेस्कटॉप पर रहते हैं।

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

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

• इस दौर का लक्ष्य अधिक विशिष्ट कौशल की पहचान करना है।
• "सांस्कृतिक फिट" (उम्मीदवार "सांस्कृतिक रूप से जाँच रहा है")।
• साक्षात्कार के अंत में, हम उम्मीदवार से पूछते हैं कि क्या वह इस व्यक्ति के साथ जोड़े जाने के लिए 6 महीने के लिए तैयार है? उम्मीदवार को यह समझना चाहिए कि उसका क्या इंतजार है। हम यह सुनिश्चित करना चाहते हैं कि आपको लोगों का साथ मिले।

तो, तीन चीजें हैं जो हम इस तरह से सत्यापित करते हैं:

1. प्रोग्रामिंग कौशल।
2. संचार कौशल।
3. डेवलपर्स के साथ सहयोग का कौशल।

साक्षात्कार के दौरान हम लोगों के लिए क्या देखते हैं?

1. प्रोग्रामिंग और सॉफ्टवेयर विकास में मौलिक कौशल।
2. नए कौशल के विकास के लिए जिज्ञासा और भूख। यह एक महत्वपूर्ण व्यक्तित्व विशेषता है जो हमारे कार्य क्षेत्र में आती है।
3. कहने की क्षमता "मुझे नहीं पता । " क्या आपके लिए यह कहना सुविधाजनक है? आपको समझना चाहिए कि आपके अज्ञान को स्वीकार करने की क्षमता सीखने का एकमात्र तरीका है।
4. पी। 3 का रिवर्स साइड: कहने की इच्छा: "चलो कोशिश करो और देखो कि क्या होता है । "
5. Personability।
6. विश्वास है कि आप सबसे अच्छी सलाह दे सकते हैं, साथ ही यह समझ भी कि ग्राहक इसे अनदेखा कर सकते हैं।

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