সফটওয়্যার ম্যানেজার যিনি ডেভেলপারদের প্রজেক্ট ম্যানেজমেন্ট করেন


12

আমি একটি এম্বেড থাকা সিস্টেম সংস্থায় কর্মরত একটি সফ্টওয়্যার বিকাশকারী। আমাদের একটি প্রজেক্ট ম্যানেজার রয়েছে, যিনি সামগ্রিক প্রকল্পের সময়সূচী (বৈদ্যুতিক, গুণমান, সফ্টওয়্যার এবং উত্পাদন সহ) কেয়ার করেন তাই তার সফ্টওয়্যার শিডিউলটি খুব সংক্ষিপ্ত is

আমাদের একজন সফ্টওয়্যার ম্যানেজারও রয়েছে, যিনি আমার মনিব। তিনি আমাকে সফ্টওয়্যার শিডিউল, ডিজাইনের ডকুমেন্টস (উচ্চ এবং নিম্ন স্তরের নকশা), এসআরএস, পরিবর্তন পরিচালনা, যাচাইকরণ পরিকল্পনা এবং প্রতিবেদনগুলি, রিলিজ ম্যানেজমেন্ট, পর্যালোচনা এবং অবশ্যই সফ্টওয়্যারটি লিখতে এবং বজায় রাখতে বাধ্য করেন।

পুরো সফটওয়্যার টিমের জন্য আমাদের কাছে কেবলমাত্র একজন পরীক্ষক ইঞ্জিনিয়ার রয়েছে (10 জন সদস্য) এবং যে কোনও সময়ে, বেশ কয়েকটি প্রকল্প চলছে।

আমি আমার ডকুমেন্টগুলি তৈরি করতে আমার 80% সময় ব্যয় করছি। আমার বস একটি প্রক্রিয়া ব্যাকগ্রাউন্ড থেকে আসে এবং আমাদের যা প্রয়োজন তা সফ্টওয়্যার উন্নত করার জন্য আরও ভাল ডকুমেন্টেশন বিশ্বাস করে:

  1. তিনি নকশাকে सर्वोपरि বলে বিবেচনা করেছেন, কোডিংটি "স্রেফ ডিজাইনটি লিখে রাখছি", এটি খুব বেশি সময় নেয় না এবং "হার্ডওয়্যার প্রস্তুত হওয়ার আগে সমস্ত কোড লেখা উচিত"।
  2. কোনও বিতরণকারী মডেলের সাথে সহযোগিতা করা সহজ করার পরেও আমরা তাকে বলার পরেও কোনও কেন্দ্রীয় এবং বিতরণযোগ্য সংস্করণ নিয়ন্ত্রণের মধ্যে পার্থক্য বুঝতে পারে না।
  3. কোড বোঝে না এবং প্রতিটি বাগ এবং এর প্রস্তাবিত সমাধান বুঝতে চায়।
  4. বিশ্বাস করে যাচাইকরণ বিকাশকারী দ্বারা করা উচিত, এবং পরীক্ষক দ্বারা বৈধকরণ। তবে বিষয়টি হল, বাস্তবায়ন সঠিক হলে আমাদের যাচাইকরণ যাচাই করে (আমরা ইউনিট পরীক্ষাগুলি লিখি না, এটি কখনই তফসিল হিসাবে বিবেচনা করা হয় না), এবং বৈধতা ব্ল্যাক বক্স পরীক্ষা, সুতরাং ইউনিট পরীক্ষা অনুপস্থিত।

আমি সত্যি বিভ্রান্ত.

  1. আমি কি এই সমস্ত নথি রক্ষণাবেক্ষণের জন্য দায়বদ্ধ? এটি আমার মনে করে যে আমি সংক্ষেপে সফ্টওয়্যার প্রকল্প পরিচালনা করছি। আমি প্রযুক্তিগত ডকুমেন্টেশন সহ ঠিক আছি তবে আমি বিশ্বাস করি শিডিউলিং / পরিকল্পনা বিকাশকারী দ্বারা করা উচিত নয়।
  2. আমি নথি তৈরি করতে পছন্দ করি না, আমি সমস্যাগুলি সমাধান করতে এবং কোড লিখতে চাই। আমার অভিজ্ঞতায় ডিজাইনের ডকুমেন্টগুলি তৈরি করা কেবলমাত্র একটি পরিমাণে সহায়তা করে, এটি কখনই আরও ভাল বা দ্রুত কোডের সমাধান নয়।
  3. আমি অনুভব করি বস আরও ভাল পণ্য তৈরি করার বিষয়ে যত্নবান হন না, তবে কেবল পরিচালকের দৃষ্টিতে একজন ভাল পরিচালক হওয়ার বিষয়ে।

আমি কি করতে পারি? এই পুরো বছর আমি 3 মাসের আসল কোডিং করেছি, বাকিটি কেবলমাত্র নথি তৈরি করতে এবং ক্লায়েন্টদের কাছ থেকে বাগ রিপোর্টের জন্য অপেক্ষা করতে ব্যয় করেছে।


16
যদি তিনি আপনার বস হন এবং বলে থাকেন যে আপনি এই নথির জন্য দায়বদ্ধ তবে আপনি দায়ী।
রিগ

1
সফটওয়্যার ম্যানেজারটি পণ্য মালিকের জন্য অন্য একটি পদ। এটি সাধারণত একটি প্রযুক্তিগত ভূমিকা থাকে তাই তিনি প্রযুক্তিগত ডকুমেন্টেশনও লেখেন না। তারা মূলত ক্লায়েন্ট এবং স্টেকহোল্ডারদের সাথে কাজ করে এবং প্রদত্ত রিলিজগুলিতে কোনও প্রদত্ত পণ্যতে কী বৈশিষ্ট্য এবং পরিবর্তনগুলি ঘটতে হবে সে সম্পর্কে সিদ্ধান্ত নেয়। তারা বিভিন্ন প্রতিযোগিতামূলক চাহিদা সহ একাধিক স্টেকহোল্ডার থাকার জটিলতা হ্রাস করে।
maple_shaft

2
আমি এটি কয়েকবার আনার চেষ্টা করেছি। সমস্যাটি হচ্ছে, প্রধানমন্ত্রীর কাছ থেকে নির্ধারিত সময়সীমার প্রচেষ্টার পরিমাণ কতটা আসবে তা আমি জানি না এবং এতে আমার এসএম কী ভূমিকা নেবেন। এখন

1
@hdman এখন কিছুটা আলাদা। প্রধানমন্ত্রীর উচিত গ্যান্ট চার্ট, রিসোর্স বরাদ্দ এবং ট্রেসিবিলিটি ম্যাট্রিক্স করা উচিত। তাহলে প্রধানমন্ত্রী কী করবেন?
ম্যাপেল_শ্যাফ্ট

1
@ ম্যাপেল_শ্যাফ্ট আমি একটি তরুণ লোক এবং আমি জিনিসগুলি, কোড তৈরি করতে এবং নতুন জিনিসগুলি চেষ্টা করতে চাই। আমি প্রজেক্ট ম্যানেজমেন্টকে ক্যারিয়ারের পছন্দ হিসাবে নিতে আগ্রহী নই। আমার ধারণা এটি পরিবর্তনের সময় হতে পারে।

উত্তর:


19

আপনি একটি সফটওয়্যার ইঞ্জিনিয়ার মত শব্দ।

কোনও প্রকল্প ব্যবস্থাপক সামগ্রিক প্রকল্পের স্থিতি এবং মাইলফলকগুলি যথাযথভাবে পূরণ হচ্ছে এবং তা নিশ্চিত করার জন্য কার্যকর উপায়ে সংস্থানগুলি বরাদ্দ করার দিকে বেশি মনোনিবেশিত হয়। তারা রাস্তাঘাটগুলিও সরিয়ে দেয় এবং প্রকল্পের সংস্থানগুলিকে তাদের নির্দিষ্ট কাজের জন্য ফোকাস করতে সহায়তা করে।

ডিজাইন এবং প্রযুক্তিগত ডকুমেন্টেশন রাইটিং এবং বজায় রাখা সফ্টওয়্যার ইঞ্জিনিয়ার হওয়ার একটি গুরুত্বপূর্ণ অঙ্গ এবং এটি আপনার ভূমিকার জন্য উপযুক্ত। খুব ভাল কোনও জিনিস খারাপ হতে পারে যদিও ( বিশ্লেষণ প্যারালিসিস দেখুন ) See

তিনি নকশাকে সর্বমুঠ্য হিসাবে বিবেচনা করেন, কোডিংটি "কেবল নকশাকে কেবল লিখে রাখছি"

যদি প্রোজেক্ট ম্যানেজার ডিজাইনের নথিগুলিকে সর্বাধিক বলে বিবেচনা করে তবে তিনি নথিগুলি প্রক্রিয়াটিতে বিতরণযোগ্য হিসাবে প্রত্যাশা করেন। আপনার পক্ষে এটি সময় নষ্ট করার সময় নয় যদি সে মনে করে যে তারা আপনার সময়ের ৮০% বরাদ্দ করার পক্ষে যথেষ্ট গুরুত্বপূর্ণ।

এটি খুব বেশি সময় নেয় না এবং "হার্ডওয়্যার প্রস্তুত হওয়ার আগে সমস্ত কোড লেখা উচিত"।

এটি ইচ্ছুক চিন্তাভাবনা এবং সফ্টওয়্যার বিকাশ কীভাবে কাজ করে তা সম্পর্কে একটি পুরানো জলপ্রপাতের স্টাইল দৃশ্য। আপনি যতটা ডিজাইন এবং প্রস্তুতি নিবেদিত হন তা নির্বিশেষে এটি কখনই পরিষ্কার নয়। তবে এই নোটটিতে, আপনার কোডটির সাথে ইন্টারঅ্যাক্ট করার জন্য আপনার স্পষ্ট হার্ডওয়্যার স্পেস এবং সঠিক পরীক্ষার পরিবেশ এবং মক হার্ডওয়্যার সিমুলেশন থাকা উচিত তবে আবার, আসল পৃথিবী অগোছালো।

প্রকল্প পরিচালনা নিখুঁত বিশ্বে অবিশ্বাস্যরকম সহজ। বাস্তব প্রকল্প পরিচালনকে অবিশ্বাস্যরকম কঠিন করে তুলতে আপনি যতই ইচ্ছা করেন তা বিশ্ব ঠিক নিখুঁত নয়। এ কারণেই তাদের বড় অঙ্কের টাকা দেওয়া হয়।

(২) কেন্দ্রীয় এবং বিতরণযোগ্য সংস্করণ নিয়ন্ত্রণের মধ্যে পার্থক্য বুঝতে পারে না।

কেন তার যত্ন নেওয়া উচিত? এটি কীভাবে মাইলফলককে প্রভাবিত করে? এটা হয় না।

3) কোড বোঝে না, এবং প্রতিটি বাগ এবং এর প্রস্তাবিত সমাধান বুঝতে চায়

তার লক্ষ্য ওয়ার্কিং সফটওয়্যার এবং আপনারও হওয়া উচিত। কোডটি বোঝার দরকার নেই তবে ওয়ার্কিং সফটওয়্যারটি রোধ করছে এমন সমস্যাগুলি তাকে বুঝতে হবে। আপনারা দু'জন একবার এই বেসিক স্তরে নজর রাখেন তবে আপনার পারস্পরিক লক্ষ্য আপনাকে আরও কার্যকরভাবে একসাথে কাজ করতে সহায়তা করবে।

(4) বিশ্বাস করে যাচাইকরণ বিকাশকারী দ্বারা করা উচিত, এবং পরীক্ষক দ্বারা বৈধকরণ।

এই অনুভূতিতে কী ভুল? গুণমান নিশ্চিতকরণের ভূমিকার পরীক্ষকগণ বৈধকরণের বৈশিষ্ট্য এবং প্রয়োজনীয়তাগুলির সাথে সংশ্লিষ্ট হতে হবে। বিকাশকারীদের পরীক্ষা পরীক্ষা করার আগে তাদের কাজ যাচাই ও পরীক্ষার জন্য সর্বাত্মক প্রচেষ্টা করা উচিত।

আমি নথি তৈরি করতে পছন্দ করি না, আমি সমস্যাগুলি সমাধান করতে এবং কোড লিখতে চাই।

আপনি যদি বরং একজন সাধারণ প্রোগ্রামার হয়ে থাকেন তবে সম্ভবত আপনার বসের সাথে এই সম্পর্কে কথা বলা উচিত এবং প্রকল্পে আপনার জন্য আরও ভাল ভূমিকা আছে কিনা তা দেখুন। কারও কারও কাছে প্রযুক্তিগত ডকুমেন্টেশন রাইটিং এবং রক্ষণাবেক্ষণ করা প্রয়োজন, সুতরাং অন্য বিকাশকারীদের মধ্যে একটির আপনাকে এই কয়েকটি কাজে সহায়তা করতে পারে যাতে আপনি ডকুমেন্টেশন লেখার ক্ষেত্রে আপনার 80% সময় ব্যয় করেন না।

আমার অভিজ্ঞতায় ডিজাইনের ডকুমেন্টগুলি তৈরি করা কেবলমাত্র একটি পরিমাণে সহায়তা করে, এটি কখনই আরও ভাল বা দ্রুত কোডের সমাধান নয়।

এটি বেশিরভাগ ক্ষেত্রেই সত্য ... তবে কেবলমাত্র যদি দশটি বিকাশকারী তাদের প্রযুক্তিগত ডকুমেন্টেশন লেখার জন্য তাদের সময়ের 80% ব্যয় করে যা কেউ কখনও পড়বে না। এটি একটি বিশাল ব্যবস্থাপন্থী বিন্যাস যা আমি আগে বাস করেছি। যদি আপনি দেখতে পান যে আপনি দলের বেশিরভাগ ডকুমেন্টেশন করছেন তবে এটি খুব কমই ন্যায্য বলে মনে হচ্ছে যে আপনি আরও কোডিংয়ের কাজ সম্পাদনের অধিকারকে অস্বীকার করেছেন।

বিষয়টির সত্যতা হল সর্বোত্তম প্রযুক্তিগত ডকুমেন্টেশন হ'ল কোডই।

আমি অনুভব করি বস আরও ভাল পণ্য তৈরি করার বিষয়ে যত্নবান হন না, তবে কেবল পরিচালকের দৃষ্টিতে একজন ভাল পরিচালক হওয়ার বিষয়ে

আমি যে তিনি মনে করেন কারণ পণ্যের তার ওয়ার্ডে এবং প্রকল্প এবং বৈশিষ্ট্য সম্পন্ন না করা হয়, তাহলে এবং ক্লায়েন্ট খুশি নয় তারপর উপরের ব্যবস্থাপনা খুব তার যত্ন করা হবে না যত্ন। সমস্যাটি হ'ল প্রয়োজনীয় মানের উন্নতির বিষয়ে আপনার দৃষ্টিভঙ্গি তাঁর এবং উচ্চতর পরিচালনার সাথে মেলে না এবং ক্লায়েন্টরা তাদের কী গুরুত্বপূর্ণ তা অনুধাবন করছে।

পণ্যটির জন্য কী গুরুত্বপূর্ণ তা বোঝার চেষ্টা করুন, কারণ আপনি যখন কোনও প্রক্রিয়াটির দক্ষতা 3 গুন বাড়িয়ে তুলতে পারেন, আপনি যদি পুরো সপ্তাহটি এটি করে ব্যয় করেন তবে ক্লায়েন্টটি দাবি করছে এটি অন্য একটি গুরুত্বপূর্ণ বৈশিষ্ট্যের জন্য ব্যয় হবে।

আমরা সকলেই আমাদের সেরাের চোখে দেখতে চাই। এতে কোনও ভুল নেই, স্ব-পরিবেশন করা মানুষের স্বভাব। এটি জীবনের সত্য।


1
উত্তরের জন্য ধন্যবাদ, আমি কিছু বিষয়গুলিতে একমত তবে সফটওয়্যার ম্যানেজারের ভূমিকা কী?

6

কিছু কিছু ডিগ্রী পর্যন্ত, আমি আপনার প্রকল্প পরিচালকের সাথে একমত। সফ্টওয়্যার ডেভলপমেন্ট কোডিং বৈশিষ্ট্যগুলি ছাড়িয়ে যায়। :-)

আপনার পরিস্থিতি বিবেচনা করে, আমি তাঁর কাছে গিয়ে ব্যাখ্যা করব যে তাঁর অনুরোধগুলি আপনার 80% সময় নিচ্ছে, এবং এটি কেন গুরুত্বপূর্ণ তা বোঝার চেষ্টা করুন যে আপনি এই সময়টি বিকাশের চেয়ে ডকুমেন্টেশন বজায় রাখতে ব্যয় করছেন (যা কোডিংয়ের বাইরে চলে যায়)।

এফওয়াইআই, অ্যাটলিশন , একটি সফ্টওয়্যার সংস্থা, একজন কিউএ ব্যক্তির জন্য 13 বিকাশকারীর অনুপাত এবং বেশিরভাগ টেস্টিং (পরিকল্পনা এবং সম্পাদন) বিকাশকারীরা করে থাকেন। আমি এগিল 2012-তে তাদের উপস্থাপনার একটি সময়ে এটি শিখেছি এবং আমাদের দলগুলি বর্তমানে এই অনুশীলনটি অনুকরণ করার চেষ্টা করছি।

তবে আমি আপনার প্রকল্প পরিচালকের সাথেও আলোচনা করব যদি তিনি পুরো দলকে এগিয়ে নিয়ে যেতে সহায়তা করার পদ্ধতি হিসাবে স্ক্রাম ব্যবহারের জন্য উন্মুক্ত হন। আপনার বিবরণ দেওয়া, আমি মনে করি না আপনি স্ক্র্যাম ব্যবহার করছেন।

আপনার মত, আমি নিয়মিত পরিবর্তিত হয়ে যাওয়া পরিকল্পনাগুলি বজায় রাখতে অত্যন্ত হতাশ হয়ে পড়েছিলাম এবং একটি স্ক্রামের হালকা ওজনের দৃষ্টিভঙ্গি আমাকে এই হতাশা কাটিয়ে উঠতে সহায়তা করেছিল।


2
উত্তর করার জন্য ধন্যবাদ. আমি Agile পরামর্শ দেওয়ার চেষ্টা করেছি, কিন্তু তারা সিএমএমআই অনুসরণ করতে চায়। এছাড়াও, আমি কি উল্লেখ করেছি যে আমারও একটি সফটওয়্যার ম্যানেজার রয়েছে?

@hdman ঠিক আছে, আসুন এখানে বাস্তববাদী। আপনার দু'জনের সাথেই আপনার কথোপকথন হওয়া উচিত এবং প্রকাশ করতে হবে যে আপনি বড় ছবিটির প্রতি যত্নশীল রয়েছেন: টিম যতটা সম্ভব উত্পাদনশীল তা নিশ্চিত করা যাতে সংস্থাটি আয় বাড়িয়ে তুলতে পারে। এই কথোপকথনগুলি ভাল যেতে পারে বা সেগুলি নাও পারে তবে একজন পেশাদার হিসাবে এটি আপনার দায়িত্ব, এটি টেবিলে আনার এবং এটি তাদের উপর নির্ভর করে যে এটি পরিচালনা করবে বা না করবে। নিশ্চিত করে নিন যে ইতিবাচক পদ্ধতিতে পরিস্থিতি সম্পর্কে 'ঝকঝকে' নয় বরং সবার জন্য পরিস্থিতির উন্নতি করতে চান।
ডেভিড সেগন্ডস

আমি সম্মত, তবে বিষয়টি হ'ল আমি প্রাথমিক থেকে মধ্য বয়সী পরিবেশে সবচেয়ে কনিষ্ঠ। বেশিরভাগ সময় এটি অনভিজ্ঞ হয়ে পড়ে আমার কাছে ফোটে।

4

আমার অভিজ্ঞতার মধ্যে সবচেয়ে পারফরম্যান্সকারী দলগুলি হ'ল যারা তাদের কাজটি করার জন্য প্রয়োজনীয় ন্যূনতম প্রক্রিয়ার মুখোমুখি হয়েছিল। কিছু সময়ে অতিরিক্ত প্রক্রিয়া পণ্য থেকে গুণমান কেড়ে নেওয়া শুরু করে। যদি QA বাগগুলি মিস করতে শুরু করে কারণ তারা কাগজপত্র না পেয়ে আরও বেশি উদ্বিগ্ন হয়, এবং ডিইভি বৈশিষ্ট্যগুলি কোডিং বা বাগ সংশোধন না করে কারণ তারা ডকুমেন্টেশন লিখছে তবে আপনার সমস্যা আছে। যাইহোক, আপনার কোম্পানির ক্ষেত্রে এটি যদি সত্যিই ঘটে থাকে তবে তা নির্ধারণ করা একটি অত্যন্ত স্থানীয় প্রশ্ন যা কেবলমাত্র আপনার দলের লোকেরা উত্তর দিতে পারে (আমাদের নয়)।

একটি বিষয় আছে যা সম্পর্কে আপনার বস খুব ভুল, এবং এটি হ'ল আপনার কিউএ খুব কম এবং ইউনিট পরীক্ষা নেই। অ্যাডেলিভার দ্বারা তৈরি একটি বাগ সংজ্ঞা দ্বারা তাদের পক্ষ থেকে একটি তদারকি করা হয়। বিকাশকারীদের সর্বদা তাদের নিজস্ব বৈশিষ্ট্যগুলি পরীক্ষা করে দেখার আশা করা এবং এ থেকে কিছুটা কম পরীক্ষা করা একটি প্রক্রিয়া সমস্যা। কিউএ আপনার ডোমেনের উপর নির্ভর করে কিছুটা স্বয়ংক্রিয় পরীক্ষার দ্বারা প্রতিস্থাপন করা যেতে পারে, তবে আপনার যদি না থাকে তবে আপনি সম্ভবত বাগগুলি স্লিপ করতে দিচ্ছেন (এবং এটি সাধারণত তাড়াতাড়ি সন্ধান করার চেয়ে বেশি দাম ব্যয় করে)।

এছাড়াও, কঠোর ব্যবসায়ের দৃষ্টিকোণ থেকে, QA নিয়োগ করা বিকাশকারীদের নিয়োগের চেয়ে সস্তা। দলগুলির যদি ভাল কিউএ / ডিইভি অনুপাত থাকে তবে আপনি ব্যয় করা অর্থের জন্য আরও বেশি ক্ষেত্রটি কভার করতে সক্ষম হবেন।


QA can be replaced by automated testing depending on your domain-1 আমি এর সাথে দৃ .়ভাবে একমত নই। কোনও পরিমাণ স্বয়ংক্রিয় পরীক্ষার কিউএর জন্য কার্যকর প্রতিস্থাপন নয়, বিশেষত বিশেষত যখন বিশেষ হার্ডওয়্যার জড়িত থাকে।
ম্যাপেল_শ্যাফ্ট

1
@ ম্যাপেল_শ্যাফ্ট সংশোধন করা হয়েছে। আমি বলতে চাইছি আপনার ডোমেনের উপর নির্ভর করে কিউএ একটি পরিমাণে প্রতিস্থাপন করা যেতে পারে। উদাহরণস্বরূপ, যদি এটি কোনও যন্ত্রের জন্য একটি নিয়ামক ডিভাইস আপনি জানেন যে নির্দিষ্ট ইনপুটগুলি আপনি নির্দিষ্ট ফলাফলগুলি আশা করেন - এটি স্বয়ংক্রিয়ভাবে পরীক্ষা করা যেতে পারে। তবে এটি যদি কোনও জিইউআই অ্যাপ্লিকেশন হয় তবে আসল লোকেরা বসে থাকা এবং এতে ঝুঁকছেন এমন কোনও উপায় নেই।
মিস্টার ফক্স

অসাধারণ! এটি এখন আরও বোধগম্য হয়। আমি আমার downvote +1 বিপরীত
maple_shaft

আমাদের সত্যিই কিউএ বিভাগ নেই। আমাদের একটি পরীক্ষক রয়েছে, এবং সেখানে QE ​​বিভাগ রয়েছে। এটি যান্ত্রিক, এমএফজি, নির্ভরযোগ্যতা ইত্যাদির সামগ্রিক মান নিয়ন্ত্রণ করে

2

আমি যে সিএমএমআই বাস্তবায়ন দেখেছি বা সরাসরি শুনেছি সেগুলি প্রক্রিয়া এবং ডকুমেন্টেশনগুলি ভারী ছিল; আপনার কর্তারা বিশ্বাস করেন যে বাস্তবায়নটিকে তুচ্ছ করে তোলার জন্য ডকুমেন্টেশনটি যথেষ্ট পরিমাণে বিশদ হওয়া উচিত strongly

আপনি যদি ডকুমেন্টেশন রাইটিং / রক্ষণাবেক্ষণের একটি অপ্রয়োজনীয় ভাগ পেয়ে থাকেন তবে আরও সমানভাবে বিতরণ করা জিজ্ঞাসা করা যুক্তিসঙ্গত। কোডিং অনুপাতের ক্ষেত্রে অন্যান্য বিকাশকারীদের যদি অনুরূপ ডকুমেন্টেশন থাকে এবং আপনি আপনার বেশিরভাগ সময় কোড লেখার জন্য ব্যয় করতে চান; এটি একটি নতুন নিয়োগকারী সন্ধানের বিবেচনা করার সময় হতে পারে।


যথাযথভাবে। তিনি পুরোপুরি সিএমএমআই সম্পর্কে। এখন আমরা স্তর 3, তিনি 5 স্তরের জন্য যেতে চান "নেতৃত্ব" বেশিরভাগ পরিকল্পনা / সময়সূচী কাজ করে যা আমি এখন করছি doing তবে আমাদের সংস্থার কাঠামোটি সমস্ত এসईকে সমান করে তোলে, তাই একজনকে নেতৃত্ব হিসাবে বেছে নেওয়া হয় এবং এই সমস্ত কাজ দেওয়া হয়, প্রতি সেয়ে স্থায়ী সীসা নেই।

এবং আমি আপনার শেষ বাক্যটি গুরুত্বের সাথে ভাবছি। এখানে মনে হচ্ছে আমি তাদের মধ্যে বাকী 70s এর মধ্যে আটকে রয়েছি, যেখানে কোড জটিলতা রেখার সংখ্যা দ্বারা গণনা করা হয়। দেখে মনে হচ্ছে এখানকার লোকেরা তাদের উপায় পরিবর্তন করতে চায় না, কোনও সৃজনশীলতা নেই।

@hdman এতে কোনও ভুল নেই এবং এটি আপনার বা তাদের দোষের প্রয়োজন নয়। কখনও কখনও লোকেরা একটি পরিবেশের সাথে ঠিক ফিট করে না।
ম্যাপেল_শ্যাফ্ট

হ্যাঁ, আমার ধারণা এটি কোনও সংস্কৃতির সমস্যা হতে পারে।

5 স্তরের কাগজের কাজের বোঝা বিশাল হতে চলেছে; মনে হচ্ছে এটি পালানোর অবশ্যই সময় এসেছে।
ড্যান ফায়ারল্ড ফায়ারলাইট

2

আপনি চিকিত্সা সিস্টেমের বিষয়ে কথা বলছেন ... সুতরাং সুরক্ষা সর্বজনীন - এবং তাই ডকুমেন্টেশন (বিশেষত ট্রেসেবিলিটি) প্রয়োজনীয় essential

একটি পরীক্ষককে কিছুটা হালকা মনে হয় তবে অন্যটি হ্যাঁ - ডকুমেন্টেশনটি যথাযথভাবে রয়েছে তা নিশ্চিত করার জন্য আপনি দায়বদ্ধ।

চিকিত্সা বিশ্বে আমার অভিজ্ঞতা সীমাবদ্ধ তবে আমাদের মহাকাশ / প্রতিরক্ষা বিশ্বে আমাদের ডু -178 বি (এখন সি) রয়েছে যা একটি জীবনচক্রীয় মডেল নির্ধারণ করে যা প্রয়োজনীয় নথিপত্র এবং পরীক্ষার স্তরকে নির্দিষ্ট করে দেয় (সুরক্ষা সমালোচনার উপর নির্ভর করে [আরও নির্দিষ্টভাবে, সফ্টওয়্যারটির নকশা আশ্বাসের স্তর]) এবং স্বয়ংচালিত বিশ্বে আমাদের ISO26262 রয়েছে যা একইভাবে রয়েছে।

যদি ডকুমেন্টেশন জায়গায় না থাকে তবে পণ্যটি শংসাপত্র প্রাপ্ত হয় না।

তবে গুরুত্বপূর্ণ বিষয়টি হল আপনার পণ্যটিকে আরও উন্নত করতে প্রয়োজনীয় ডকুমেন্টেশনগুলির সাথে কাজ করা ... ডকুমেন্টেশনটিকে কোনও চিন্তা-ভাবনা হিসাবে বিপরীত ইঞ্জিনিয়ার করার চেষ্টা করবেন না এবং তারপরে এটি কোনও বাস্তব-বিশ্বের উদ্দেশ্য হিসাবে কাজ করে না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.