उनके बिना किसी संगठन में मानकों और प्रक्रिया में सुधार कैसे पेश किए जाने चाहिए?

10

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

standards cmmi process-improvement

— rjzii
स्रोत

बस जिज्ञासु, क्या आपको पहले से ही पता है कि अधिक कीड़े क्यों वांछित हैं?

— क्रिस पिटमैन

2

@ S.Lott क्या आप मानकों के बिना बग (उपभोक्ता पक्ष पर) कम नहीं होने के लिए मामला बना सकते हैं? मेरा अनुभव एक प्रक्रिया और मानकों को बहुत कम कर देता है जो उपभोक्ता बग पर देखता है ... ऐसा नहीं है कि वे मौजूद नहीं हैं जो ग्राहक द्वारा कभी नहीं देखा जाता है।

— रिग

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

— S.Lott

@Robz: "कोडिंग मानक" "औपचारिक मानक" नहीं है। यह प्रश्न स्पष्ट करेगा। फिर। "औपचारिक मानक" W3C, Posix, ISO, IEEE, ANSI मानक हैं। मान्यता प्राप्त स्टैंड-सेटिंग संगठन द्वारा प्रारूपित और अनुमोदित। यदि आप कोडिंग मानकों के बारे में बात कर रहे हैं, तो कृपया "औपचारिक" शब्द को हटाने के लिए प्रश्न को अपडेट करें और "कोडिंग" शब्द का उपयोग करें। उस परिवर्तन के साथ आपका प्रश्न समझ में आता है। और डुप्लिकेट है।

— S.Lott

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

— S.Lott

2

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

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

— altern
स्रोत

6

हार्ड दस्तक के स्कूल से कुछ विचार:

1) अधिकांश प्रक्रिया सुधार पहलें प्रक्रिया डिजाइन पर अपना 80% समय और शिक्षा और समाजीकरण पर 20% खर्च करती हैं। इन प्रतिशत को पलटें। एक सामान्य मानक जिसका पालन किया जाता है, वह एक परिपूर्ण है जो नहीं है।

2) स्पष्ट कारणों को पहचानें कि आप लोगों को यह बताने के लिए क्यों काम कर रहे हैं कि वे कैसे काम करते हैं। व्यवसाय का मामला क्या है? आदर्श रूप से यह प्रत्येक टीम को व्यक्तिगत रूप से लाभान्वित करता है। कभी-कभी यह सिर्फ प्रणालीगत सुधार होता है। किसी भी तरह से, मामले को दिखाई दे।

3) सरलीकृत करें, फिर मानकीकरण करें, न कि दूसरे तरीके से।

4) आप इसे पूरी तरह से एक पीएमओ को नहीं सौंप सकते। प्रत्यक्ष प्रबंधकों को खरीदे जाने की आवश्यकता होती है, और शिकायतें आने पर व्यावसायिक इकाई के प्रमुख को संबंधों को तोड़ना होगा।

5) मिलनसार शुरुआती अपनाने वाले। लोग शिकायत करेंगे कि यह सब कितना समय लेता है। आपको किसी ऐसे व्यक्ति की आवश्यकता है जिसे आप इशारा कर सकें और कह सकें, "इसमें उन्हें केवल 15 मिनट लगे"

6) मैट्रिक्स के लिए, गुणात्मक पर मात्रात्मक के लिए कड़ी मेहनत करें। अन्यथा आपके पास ऐसे प्रोजेक्ट हैं जो गो लाइव से एक दिन पहले तक ग्रीन हैं, जब एक महीने तक सब कुछ फिसल जाता है।

7) उपकरणों पर तकनीकों पर जोर देना। एमएस प्रोजेक्ट की तुलना में अच्छी प्लानिंग ज्यादा जरूरी है।

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

सौभाग्य!

— MathAttack
स्रोत

1

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

— मटकाव

1

अगर आप इसे सही तरीके से लागू करते हैं तो @mattnz - मुझे नहीं पता, त्रुटि / SLOC एक उपयोगी मीट्रिक हो सकती है। अगर कोई कहता है कि वे औसतन 1 त्रुटि / 10 एसएलओसी की संभावना है तो मुझे चिंता होगी। चाल यह है कि आपको यह जानना होगा कि बार कहां हैं, जो कठिन हो सकता है।

— rjzii

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

— मैथअटैक

1

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

— मटनज

1

@mattnz - यही कोड की समीक्षा है, अगर कोई इस तथ्य को छिपाने के लिए अपने कोड को अनावश्यक रूप से क्रिया कर रहा है कि यह बग से ग्रस्त है, तो संभावना है कि इन्हें शुरू करने के लिए कोड नहीं लिखना चाहिए। आप प्रति फ़ंक्शन बिंदु पर दोषों को भी देख सकते हैं जो नकली के लिए बहुत कठिन है क्योंकि आप या तो नीचे जाने वाले संख्याओं (बुरे संकेत) के साथ कार्यों की संख्या में एक प्रदर्शनी देखते हैं, या कोड ठीक होने के साथ ही संख्या कम होने लगती है (अच्छा संकेत)।

— rjzii

2

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

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

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

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

— थॉमस ओवेन्स
स्रोत

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

— rjzii

@RobZ परिभाषा के अनुसार, आप जमीनी स्तर के प्रयासों को आगे नहीं बढ़ा सकते हैं - यह स्वाभाविक रूप से नीचे से ऊपर तक आना है। जब तक परियोजना की टीमों को यह पता नहीं चलता कि वास्तव में समस्या है, प्रवृत्ति में बदलाव नहीं करना है और उन परिवर्तनों का विरोध करना है जिन्हें किसी तरह से बुरा माना जाता है (जैसे काम को और अधिक जटिल या कठिन बनाना, जो अक्सर प्रक्रिया में सुधार के साथ जुड़ा होता है, हालांकि यह isn है) 't अक्सर मामला)।

— थॉमस ओवेन्स

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

— rjzii

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

— थॉमस ओवेन्स

कोई भी वास्तव में उम्मीद नहीं कर रहा है कि मामला होने के लिए और हम पहले से ही प्रतिरोध का सामना कर रहे हैं, इस बिंदु पर हम इसे कम करने के तरीकों की तलाश कर रहे हैं।

— rjzii

0

प्रत्येक परिवर्तन के लिए:

1 परिवर्तन को कॉल करें और यह कैसे विकास में सुधार करेगा।
परिवर्तन को लागू करें।
प्रदर्शन में सुधार
उन परिवर्तनों को निकालें, जिनमें सुधार प्रदर्शित नहीं हुआ था

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

वास्तव में आपके पर्यावरण के लिए सबसे अच्छा अभ्यास है यह दिखाने के लिए विश्लेषण किए बिना सर्वोत्तम प्रथाओं का पालन करने से अधिक मुझे कुछ भी परेशान नहीं करता है। एक सबसे अच्छा अभ्यास जो सुधार को प्रदर्शित नहीं करता है वह सबसे बेकार और सबसे खराब नुकसानदायक है।

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

— dietbuddha
स्रोत