আপনি এম্বেড থাকা সিস্টেমে স্ক্রমের সাথে অ-কার্যকরী কাজটি কীভাবে পরিচালনা করবেন?

Question

এম্বেড থাকা সিস্টেমে স্ক্রাম নিয়ে আমার দুটি সমস্যা আছে। প্রথমত, কাজ করার জন্য অনেকগুলি কাজ রয়েছে, বিশেষত প্রাথমিক পর্যায়ে, যা প্রদর্শনযোগ্য নয়। আমরা একটি উন্নয়ন বোর্ড, কোনও ওএস, কোনও প্রদর্শন, কোনও সিরিয়াল যোগাযোগ ইত্যাদি দিয়ে শুরু করেছিলাম আমাদের ছয়টি স্প্রিন্টের জন্য আমাদের প্রদর্শন নেই have

প্রথম চারটি স্প্রিন্ট ছিল:

• পথ RTOS আপ এবং চলমান
• নেটওয়ার্ক এবং সিরিয়াল ড্রাইভার লেখার কাজ তৈরি করা
• বোতাম, যোগাযোগ ইত্যাদির জন্য বিঘ্নিত রুটিনগুলি লিখছি
• প্রাথমিক ডাটাবেস ক্লাস এবং পদ্ধতি রচনা
• সিরিয়াল ডিবাগ মেনু লিখছেন

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

আমরা "ব্যবহারকারীর গল্প" বাক্যাংশগুলি লিখেছিলাম, যেমন "বিকাশকারী হিসাবে ...", যা আমি সন্তুষ্ট নই তবে টার্গেট প্রক্রিয়া (www.targetprocess.com) ব্যবহার করে, ব্যাকলগ আইটেমটির কোনও ধারণা নেই যা একটি কাজ বা কাজ

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

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

আমি রুচিশীল হয়ে উঠছি, তবে নিয়ম মেনে চলার চেষ্টা করা এটি একটি আসল সমস্যা। এখন, আমি নিয়মগুলি বাঁকানো নিয়ে ঠিক আছি, তবে আমার কাছে সমস্যাটি হ'ল এটি পরীক্ষা না করা পর্যন্ত যদি আমি জিনিসগুলি চিহ্নিত না করতে পারি তবে এটি আমার সমস্ত বোরডাউন মেট্রিকগুলি স্ক্রু আপ করে দেয়।

অন্যরা কীভাবে এই পরিস্থিতিগুলি পরিচালনা করেছে তা শুনতে আমি পছন্দ করি।

Comments

পদক্ষেপ 1. একই প্রশ্ন সহ অন্যান্য ভাবেনদের অনুসন্ধান করুন। উদাহরণ। stackoverflow.com/questions/5909533/… । এটি একটি খুব সাধারণ প্রশ্ন।

— এস .লট

এটি মজার বিষয় যে লোকেরা কোনও উন্নয়ন প্রক্রিয়া মেনে চলার চেষ্টা করে কত সময় এবং প্রচেষ্টা নষ্ট করে, যা শেষ ফলাফলগুলিতে কিছুই যোগ করে না বলে মনে হয়

— স্টিভ

Answer 1

আপনি এমন কোনও পণ্যটিতে একটি পদ্ধতি ব্যবহার করছেন যা আইএমএইচও-এর সাথে সামঞ্জস্যপূর্ণ নয়।

বেশিরভাগ লোকেরা চটপটে সংজ্ঞায়িত করার সাথে সাথে পরিবর্তনগুলি অগ্রাধিকার, পুনঃ-অর্ডার-সক্ষম, বা প্রতিস্থাপনযোগ্য এর ভিত্তিতে সমস্ত কাজ আলোচনা সাপেক্ষে।

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

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

আমি বলছি না যে যে কোনও প্রক্রিয়া সম্পর্কে আপনাকে কারও দৃষ্টিভঙ্গি মেনে চলতে হবে, তবে কমপক্ষে এই কাজের জন্য আপনি আমার কাছে একটি চতুর প্রকল্প হিসাবে মনে করছেন। চটজলদি প্রক্রিয়াতে তা ঠাট্টা করার চেষ্টা করা সবচেয়ে ভাল opালু ফিট হতে চলেছে।

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

Answer 2

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

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

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

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

Comments

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

— ব্রায়ান ওকলে

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

— স্টিভ

Answer 3

আপনি স্ক্রামকে খুব নির্দিষ্ট ক্ষেত্রে ব্যবহার করেন এবং আপনি প্রতিটি পদক্ষেপে অনুমিত প্রক্রিয়াটি লঙ্ঘন করেন। আপনার প্রশ্নটি সম্ভবত হওয়া উচিত: এমন কি আরও চটজলদি পদ্ধতি আছে যা আমার পরিবেশের সাথে আরও ভাল মানায়? কেবল আপনার পরিবেশ যদি এটির অনুমতি না দেয় তবে আপনাকে আরও ভাল স্ক্র্যাম করতে সহায়তা করা খুব কঠিন। আপনার বিবরণে আমি যে সমস্যাগুলি দেখছি:

• কোনও প্রদর্শনযোগ্য কাজ যা অবকাঠামোগত কাজ হিসাবে বিবেচিত হতে পারে। আপনার যদি এমন কিছু করার জন্য বেশ কয়েকটি স্প্রিন্টের প্রয়োজন হয় যা ব্যবসায়িক মূল্য হিসাবে বিবেচিত হয় না তবে আপনার ব্যবহারকারীর গল্পগুলি সম্ভবত খারাপভাবে সংজ্ঞায়িত হয়েছে। ব্যবসায়ের মূল্য সরবরাহ করতে যদি আপনাকে কোনও সরঞ্জাম বা অন্য কোনও কিছু তৈরি করতে হয় তবে পণ্যটি দুটি ভাগে / রিলিজে ভাগ করা যায় - একটি সরঞ্জাম তৈরি করা এবং ব্যবসায়ের মূল্য তৈরি করা। এই ক্ষেত্রে আপনার ব্যবহারকারীর গল্পগুলি "বিকাশকারী হিসাবে ..." সম্পূর্ণ বৈধ হবে, কারণ একটি সরঞ্জাম বিকাশকারীদের জন্য তৈরি করা হয়েছে।

  এখানে সমস্যাটি হ'ল গ্রাহকের সাথে এটি কীভাবে যোগাযোগ করবেন, কারণ প্রথম প্রকাশে তার জড়িততা শূন্য। গ্রাহকদের জন্য যদি কোনও ব্যবসায়িক মূল্য না থাকে তবে তারা কীভাবে অংশ নিতে পারে? কীভাবে পণ্য মালিক ব্যবসায়ের অগ্রাধিকার সংজ্ঞা দিতে পারেন?

  আমি মনে করি যে এখানে মূল সমস্যাটি এটি স্ক্রমের সাথে মানানসই নয়। স্ক্র্যাম প্রথমে সবচেয়ে গুরুত্বপূর্ণ ব্যবসায়িক বৈশিষ্ট্যগুলি সরবরাহ করার চেষ্টা করে, তবে প্রথমটি সরবরাহ করতে আপনার দুই মাস প্রয়োজন need স্ক্রাম এবং পুরো চটপটে পরিবর্তনটি আলিঙ্গন করে - কী হবে যদি প্রথম বৈশিষ্ট্যগুলি সরবরাহ করার পরে, গ্রাহকের কিছু পরিবর্তন প্রয়োজন যা আপনার সমস্ত প্রাথমিক স্প্রিন্টের মধ্যে ফিরে যায়?

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