2008-10-07 10 views
23

मैं मार्क और लौरा सेवेल (Amazon link) द्वारा "द सॉफ़्टवेयर आर्किटेक्ट्स पेशे" पुस्तक पढ़ रहा हूं और मुझे यह आश्चर्य हुआ कि एक सॉफ्टवेयर आर्किटेक्ट पुराने गैर-चुस्त बीडीयूएफ दृष्टिकोण का हिस्सा है या नहीं।क्या सॉफ़्टवेयर आर्किटेक्ट में फुर्तीली, esp में कोई भूमिका है। स्क्रम?

क्या सॉफ़्टवेयर आर्किटेक्ट्स के लिए एक चुस्त दृष्टिकोण में कोई जगह है? मैं विशेष रूप से स्क्रम में रूचि रखता हूं।

बीटीडब्ल्यू मैं वर्तमान में एक प्रमुख कंपनी के लिए यूनिक्स एप्लिकेशन आर्किटेक्ट हूं।

चियर्स,

रोब

उत्तर

11

निश्चित रूप से।

याद रखें - चुस्त एक 'मुझे एक चट्टान' दृष्टिकोण नहीं है। अभी भी आवश्यकताएं हैं, अभी भी एक डिजाइन और अभी भी एक ठोस वास्तुकला की आवश्यकता है।

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

+0

"टीमों पर कोई शीर्षक नहीं है। टीमों की आवश्यकताओं और प्रौद्योगिकी को उत्पाद कार्यक्षमता में बदलने के लिए स्व-व्यवस्थित किया जाता है। राज्य-रहित, अहंकार कम, विकास टीम उत्पन्न होने वाले किसी भी शब्द को संबोधित करने के लिए लचीला है। स्क्रम उन लोगों से बचाता है जो कोड को अस्वीकार करते हैं क्योंकि वे सिस्टम आर्किटेक्ट्स या डिजाइनर हैं ... कोई शीर्षक नहीं, कोई अपवाद नहीं। " - स्क्रम के साथ Agile सॉफ्टवेयर विकास - केन Schwaber –

+0

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

+0

@DerekGreer चुस्त घोषणापत्र से कौन से लक्ष्य आर्किटेक्ट भूमिका के खिलाफ काम करते हैं? बस उत्सुक। मैं एक दृढ़ आस्तिक हूं कि, इच्छुक प्रतिभागियों के साथ, स्वयं संगठित समूह/जोड़े अच्छी तरह से काम करते हैं और वास्तव में मदद कर सकते हैं। लेकिन यह मेरा अनुभव रहा है कि व्यक्तियों को एक प्रणाली को वास्तुकार करने की क्षमता के साथ - और फिर उस प्रणाली के कम से कम एक हिस्से को लिखने में संलग्न होना - मूल्यवान है। मुझे लगता है कि चुनौती यह हो सकती है कि जो लोग कोड को मार सकते हैं - शायद बहुत अच्छी तरह से - जरूरी नहीं है कि वे लोग हों जो बड़े सिस्टम की कल्पना कर सकें। डेरेक टिप्पणी करने के लिए धन्यवाद। – itsmatt

1

मुझे लगता है कि है कि यह अधिक एक दृष्टिकोण मुद्दे की तुलना में एक कौशल मुद्दा है। तो हाँ, उसके पास एक भूमिका हो सकती है भले ही उसके पास वह शीर्षक हो।

2

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

3

पूरी तरह से।

आपके द्वारा वर्णित विकास/परियोजना प्रक्रिया उन वास्तुकलाओं के निर्माण के लिए है जो आर्किटेक्ट के रूप में डिजाइन किए गए हैं।

तो अक्सर उपयोग किए जाने वाले समानता, वास्तुकार डिजाइन और योजना - शहर, सड़कों, इमारतों।

डेवलपर्स शहर, सड़कों, इमारतों का निर्माण करते हैं।

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

बस आर्किटेक्ट्स के निर्माण के लिए इंजीनियरों के साथ इमारत की निगरानी करने के लिए हाथों के निर्माण के रूप में, सॉफ्टवेयर डेवलपर्स को भी विकास प्रक्रिया की निगरानी करने के लिए हाथ में होना चाहिए।

आर्किटेक्ट और डेवलपर दोनों भूमिकाएं संबंधित हैं - लेकिन अपने स्वयं के कार्य कार्यक्रम को प्राप्त करने के लिए विभिन्न प्रक्रियाओं का पालन कर सकती हैं।

4

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

6

Agile विकास का मतलब अराजकतावादी विकास नहीं है, फिर भी समय के साथ बनाए रखने योग्य रहने के लिए इसे समन्वय करने की आवश्यकता है।

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

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

+2

+1 "फुर्तीली विकास का मतलब अराजकतावादी विकास नहीं है" – user128807

1

हालांकि ... Agile छोटी परियोजनाओं के लिए सबसे अच्छा है, और विशेष आर्किटेक्ट आमतौर पर बड़ी परियोजनाओं में अधिक उपयोगी होते हैं।

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

दो चरणबद्ध स्क्रम की तरह।

+1

"छोटी परियोजनाओं के लिए Agile सबसे अच्छा है ..." क्या आपके पास इस दावे का समर्थन करने के लिए कोई सबूत है? – user128807

+0

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

+0

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

47

स्क्रम में वास्तुकार के रूप में मेरी भूमिका में निम्नलिखित शामिल हैं।

  1. तकनीकी स्पाइक्स - अवधारणा के सबूत - हम यह कैसे करेंगे। ("यह आसान होगा अगर आप सीधे एसएमटीपी लाइब्रेरी का उपयोग कर रहे हों, यह पहले से ही मौजूदा एसएमटीपी पुस्तकालयों को लपेटता है; हमारे रैपर के चारों ओर अपना खुद का रैपर लिखना ज्यादा मदद नहीं करता है। हम जिस विधि को आप चाहते हैं उसे जोड़ सकते हैं।")

  2. डेवलपर्स के बीच समन्वय इच्छित वास्तुकला फिट करने के लिए समन्वय। ("उम्म्म ... आप अपनी खुद की प्रॉपर्टी फाइल का उपयोग क्यों कर रहे हैं?"

  3. उपयोगकर्ताओं के साथ बैकॉग को उचित रूप से प्राथमिकता देने के लिए काम करना। ("ये तीन संबंधित हैं, अगर हम एक करते हैं, तो हम दूसरे को लगभग शून्य पर प्राप्त करते हैं अतिरिक्त लागत। ")

  4. बैकलॉग की लागत के लिए प्रबंधकों के साथ काम करना। (नहीं, एक प्रोजेक्ट मैनेजर ऐसा नहीं कर सकता; उनके पास तकनीकी गहराई नहीं है। नहीं, प्रोग्रामर ऐसा नहीं कर सकते हैं, वे सिंहावलोकन Articulating क्यों पैकेज के नाम इस तरह से कर रहे हैं, और क्यों डाटा मॉडल उन सुविधाओं की है जरूरत नहीं है।)

  5. उन चीज़ों को ढूंढना जिन्हें हम याद कर रहे हैं और तकनीकी आधार पर बैकलॉग को पुन: स्थापित करना चाहते हैं ("हमें [एक्स] को एकीकृत करने के लिए इस अतिरिक्त स्प्रिंट की आवश्यकता होगी, [वाई] अपग्रेड करें और [Z] को प्रतिस्थापित करें या हम उन स्पिंट्स को कभी नहीं प्राप्त करेंगे किया। ")

+1

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

+4

तकनीकी स्पाइक वास्तविक विकास कार्य है। असली कोड असली इकाई परीक्षण। मुझे यकीन नहीं है कि इससे कितना कम हाथीदांत टावर मिलता है। –

1

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

मुझे लगता है कि यद्यपि वास्तव में चुस्त परियोजना पर "औपचारिक" वास्तुकला नहीं हो सकती है, फिर भी हमेशा वास्तुशिल्प चिंताओं को संबोधित करने की आवश्यकता होती है और आमतौर पर यह अधिक अनुभवी टीम के सदस्य होते हैं जिनके पास कुछ को संबोधित करने का ज्ञान होगा ये बातें।

और यह भी ध्यान रखें कि आंतरिक परियोजना विधि पे-ग्रेड से अलग हो सकती है - इसलिए एक शीर्षक को "नौकरी पर" बोलने के लिए बड़े पैमाने पर अनदेखा किया जा सकता है। एस 12 लॉट के उत्तर पर

1

+1।वास्तुकार की भूमिका महत्वपूर्ण है, लेकिन एक चुस्त दृष्टिकोण आर्किटेक्ट को हाथीदांत टावर से नीचे आने और टीम के साथ अपने हाथ गंदे होने के लिए begs। यह कठिन हो सकता है, क्योंकि हाथीदांत टावर अक्सर सॉफ़्टवेयर बनाने के शिल्प के साथ डिस्कनेक्टनेस का कारण बनते हैं।

0

बिल्कुल। वैसे भी आर्किटेक्चर को आगे बढ़ने के लिए कोई कारण नहीं है।

1

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

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

2

बिल्कुल - एक वास्तुकार वांछित है और एक स्क्रम टीम में आवश्यक है। शायद आप इसे स्क्रम/फुर्तीली प्रचारकों, प्रशिक्षकों आदि से नहीं सुनेंगे लेकिन किसी भी अनुभवी उत्पाद मालिक आपको यह बताएगा। एक architect's role in scrum बहुत महत्वपूर्ण है।

-3

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

+0

प्रश्न "पवित्र ग्रंथों में निर्दिष्ट एक वास्तुकार नहीं है" :) लेकिन "एक वास्तुकार क्या करता है/इस ढांचे में उसकी भूमिका कैसे बदलती है।" व्यापक दस्तावेज़ीकरण पर – plaugg

0

हाँ बहुत ज्यादा तो

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

तो फुर्तीली विकास में सॉफ्टवेयर आर्किटेक्चर की भूमिका क्या है? इसे समझने के लिए, फुर्तीली सॉफ्टवेयर विकास के सिद्धांतों को समझना महत्वपूर्ण है।इन सिद्धांतों फुर्तीली सॉफ्टवेयर विकास के यहाँ http://agilemanifesto.org

  • व्यक्तियों और प्रक्रियाओं पर बातचीत और उपकरणों

  • व्यापक प्रलेखन से अधिक कार्य करना सॉफ्टवेयर अनुबंध बातचीत से अधिक

  • ग्राहक सहयोग के लिए घोषणा पत्र में पाया जा सकता

  • एक योजना के बाद बदलने के लिए प्रतिक्रिया

अधिक यहाँ जानकारी: http://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/

+0

कार्य सॉफ्टवेयर? – Simon

+0

ग्राहक सहयोग- तकनीकी (!!!) कारणों के लिए, समाधान/उत्पाद प्रबंधक – Simon

+0

तकनीकी (!) योजना में परिवर्तन के लिए जिम्मेदारी है – Simon

0

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

संबंधित मुद्दे