এটি আমার পরিকল্পনার চেয়ে দীর্ঘ হতে পারে (এটি একটি মন্তব্য হিসাবে শুরু হয়েছিল), তবে আমি আশা করি যে যোগ করা দৈর্ঘ্য / বিবরণ সহায়ক হবে এবং আপনি এটিকে ন্যায়সঙ্গত বলে মনে করেন।
চতুরতা CRUD অ্যাপ্লিকেশনগুলির সাথে নির্দিষ্ট নয়
চটপটে সাহিত্যের বেশিরভাগ অংশই CRUD প্রকারের ব্যবসায়িক অ্যাপ্লিকেশনগুলির প্রতি পক্ষপাতদুষ্ট বলে মনে হয় যেখানে পর্দার আড়ালে কী ঘটছে তা সম্পর্কে ব্যবহারকারী যথেষ্ট সচেতন। (এটি ঠিক আছে কারণ বেশিরভাগ কোড লেখা হচ্ছে সম্ভবত এই শ্রেণীর অন্তর্গত))
আমি মনে করি এটি কারণ এই ধরণের উদাহরণ অনুসরণ করে সহজেই অনুসরণ করা সহজ, কারণ এই পদ্ধতিটি সেই ধরণের সিস্টেমে নয়। যদি আপনি খুব সহজে-অনুসরণযোগ্য-অনুসরণ না করে তৈরি উদাহরণ তৈরি করেন তবে আপনার বক্তব্যটি যখন পাঠককে চতুর ধারণা সম্পর্কে শিখিয়ে দেওয়ার কথা ছিল তখন উদাহরণটি বোঝার চেষ্টা করে আটকে যাওয়ার ঝুঁকি হোন।
ব্যবহারকারীর গল্প! = প্রয়োজনীয়তা
এই ধরণের অ্যাপ্লিকেশনটির জন্য ব্যবহারকারীর গল্প (প্রয়োজনীয়তা) এবং বিকাশমূলক কার্যগুলির মধ্যে সম্পর্ক বেশিরভাগ সহজলভ্য: কেবলমাত্র ব্যবহারকারী কাহিনীকে কয়েকটি কার্যে বিভক্ত করুন।
একটি ব্যবহারকারী গল্প প্রয়োজন হিসাবে একই নয় । সত্য, প্রয়োজনটি কীভাবে 'উচ্চ-স্তরের' হয় তার উপর নির্ভর করে কিছু ওভারল্যাপ হতে পারে, তবে সাধারণত একই হয় না। আমি এই ধারণাটি পেয়েছি যে আপনি একই প্রবণতাটি নিয়ে আমার প্রচুর প্রাক্তন ব্যবস্থাপক হয়ে পড়েছিলেন: "গল্পের" প্রয়োজনের প্রতিশব্দ হিসাবে কেবল ব্যবহারকারী গল্পগুলি নিয়েই ভাবছেন, যা এসভিএন ব্যবহারকারীরা গিটে স্থানান্তরিত করার চেষ্টা করার অনুরূপ, তবে চালিয়ে যান এসভিএন হিসাবে বিবেচনা (তারা তখন খারাপ শুরু অনুমানের কারণে সমস্যার মধ্যে চলে যায় run)
আইএমএইচও, প্রয়োজনীয়তা এবং ব্যবহারকারীর গল্পগুলির মধ্যে একটি মূল পার্থক্য হ'ল প্রয়োজনীয়তাগুলি নির্দিষ্টভাবে সিস্টেমের উপাদানগুলির কীভাবে আচরণ করা উচিত তা বিশদভাবে নির্দিষ্ট করে; এগুলি স্পেসিফিকেশন যার মধ্যে ইনপুট, আউটপুটস, অনুমান / প্রাক-শর্তাদি, সম্ভাব্য ব্যতিক্রম উত্থাপিত ইত্যাদি রয়েছে They তারা সিস্টেমটি কী করে তাতে মনোনিবেশ করে।
ওটিওএইচ, ব্যবহারকারীর গল্পগুলি সিস্টেমের উপাদানগুলির জন্য বিশদ আচরণের নির্দিষ্টকরণ তৈরি করার চেষ্টা না করে শেষ-ব্যবহারকারীর প্রত্যাশিত ফলাফলের উপর দৃষ্টি নিবদ্ধ করে। তারা প্রত্যাশিত ব্যবহারকারীর অভিজ্ঞতার উপর ফোকাস দেয় ।
আমি যা করতাম, এবং এটি আমার দলটি গ্রহণ করেছিল, তা ছিল ব্যবহারকারী গল্পগুলিকে কাজগুলিতে ছড়িয়ে দেওয়া। আপনার কাজগুলি আপনার যেমন প্রয়োজন / সুনির্দিষ্ট হতে পারে তত সুনির্দিষ্ট বা অস্পষ্ট হতে পারে তবে গল্পটি একটি সম্পন্ন অবস্থায় নিয়ে যাওয়ার জন্য প্রকৃত কাজের জন্য আপনার অগ্রগতি সূচক হিসাবে বোঝানো হয়েছিল।
উদাহরণ
আমি বেশিরভাগ বছর আগে এমন একটি মার্কিনের কথা স্মরণ করি যা আমি বেশ কয়েক বছর আগে কাজ করেছি যেখানে ব্যবহারকারীদের পরীক্ষার মামলাগুলি স্ব-নিয়োগের প্রয়োজন হয়েছিল যাতে দলের প্রত্যেককেই সচেতন হতে পারে যে তারা নকল প্রচেষ্টা এড়াতে কোন টিসি-তে কাজ করছে; UI ছিল একটি (এন অভ্যন্তরীণ) ওয়েব অ্যাপ্লিকেশন। ব্যবহারকারী কেবল একটি বোতাম দেখেছিলেন, তবে গল্পটি কয়েকটি টাস্কে বিভক্ত ছিল যার মধ্যে কিছু প্রযুক্তিগত বাস্তবায়ন বিশদ ইত্যাদি ছিল included
ব্যবহারকারীর দৃশ্যমানতা
তবে অন্য ধরণের অ্যাপ্লিকেশন রয়েছে যেখানে বেশিরভাগ কোডকে জটিল প্রসেসিংয়ের সাথে মোকাবিলা করতে হয় যা ব্যবহারকারীর কাছে সরাসরি দেখা যায় না।
এটি কি কোনও উপায়ে ব্যবহারকারীর কাছে দৃশ্যমান করা সম্ভব?
একটি জিপিএস বিবেচনা করুন। আপনি যখন নিজের পালাটি মিস করেছেন, আপনি আসল রুট পুনরায় গণনা প্রক্রিয়াটি দেখতে পাবেন না তবে ব্যবহারকারী কিছু কার্যকর প্রতিক্রিয়া পাবেন (যেমন "পুনঃসংযোগ ...")।
সংকলকগণ সতর্কতা বা ত্রুটি প্রদর্শন করতে পারে বা নতুন কিছু যুক্ত করা হয়েছে তা দেখার জন্য জিইউআইতে নতুন সেটিংস / বিকল্পগুলি অন্তর্ভুক্ত করতে পারে। আমি মনে করি সংকলকগুলির জন্য ব্যবহারকারীরা প্রোগ্রামার হবেন, তাই না? তারা কি নতুন স্ট্যান্ডার্ড যুক্ত করার জন্য সমর্থন দেখতে পাবে না?
একটি নতুন মান সমর্থন করার সময় বৈশিষ্ট্যটি স্তরে থাকতে পারে এবং এটি ব্যবহারকারী গল্পগুলিতে বিভক্ত হওয়া দরকার ছিল, আপনি কি নিশ্চিত করেছেন যে কমপক্ষে কিছু ক্ষেত্রে আপনি গল্পগুলি ব্যবহার করার চেষ্টা করছেন না যখন পরিবর্তে বৈশিষ্ট্যগুলি ব্যবহার করা উচিত ?
একটি গাড়ীর চিত্র বিশ্লেষণকে এমনভাবে অঙ্কিত করা যেতে পারে যা ব্যবহারকারীর জানাতে পারে যে গাড়ি দুর্ঘটনায় শেষ হওয়ার সম্ভাবনা হ্রাস পেয়েছে। উদাহরণ স্বরূপ:
একটি স্ব-ড্রাইভিং গাড়িতে যাত্রী হিসাবে আমার অজ্ঞাতপরিচয়টিকে ধাক্কা দিয়ে দুর্ঘটনা ঘটাতে থাকা গাড়ির সম্ভাবনাটি যতটা সম্ভব শূন্যের কাছাকাছি হওয়া দরকার, যাতে আমি আরও নিরাপদে ভ্রমণ করতে পারি।
মার্কিন যুক্তরাষ্ট্রটি উচ্চ-স্তরে ক্যাপচার করে, যে জিনিসগুলি আপনি সাধারণত ক্রিয়ামূলক এবং অ-কার্যকরী প্রয়োজনীয়তার সংমিশ্রণ ব্যবহার করে নির্দিষ্ট করতে চান - সুরক্ষা, সুরক্ষা ইত্যাদি ing
যাইহোক, একটি সিস্টেম সম্পর্কে আরও হতে পারে; উদাহরণ:
abcউপাদানগুলিতে ফাংশনটি Aধীরে ধীরে চলমান অবজেক্টগুলিকে আরও ভালভাবে সনাক্ত করতে চিত্রের তুলনা অ্যালগরিদমে সহনশীলতার প্রান্তিক মান হ্রাস করতে হবে।
আমার কাছে, এটি সহজেই আমি উপরে উল্লিখিত ব্যবহারকারীর গল্পের অধীনে একটি কাজ হয়ে উঠবA.abc , যার শিরোনাম: ফাংশনে সহনশীলতা হ্রাস করুন এবং তারপরে এটি অন্যান্য প্রাসঙ্গিক বিবরণ অন্তর্ভুক্ত করুন।
তরল সিমুলেশন সিস্টেমের জন্য, আপনার কাছে এমন একটি অগ্রগতি বারও থাকতে পারে যা যদি সিস্টেমটি সম্পাদন করে যা পটভূমি কাজগুলি সম্পর্কে প্রতিক্রিয়া প্রদান করে, যদি এটি বোঝা যায়। (ব্যবহারকারীকে কোনও কিছুর বিষয়ে অবহিত করার একটি উপায় রয়েছে, যদিও আপনি স্প্যামি হওয়া এড়াতে চাইতে পারেন))
আপনি যে নির্দিষ্ট ডোমেনগুলি ভাল এবং / অথবা আরও বাস্তব উদাহরণগুলির সাথে উল্লেখ করার জন্য উল্লেখ করেছেন সেগুলি সম্পর্কে আমি যথেষ্ট পরিমাণে জানি না, তবে এখানে যদি কিছুটা গ্রহণ করা যায় তবে তা হ'ল আপনি কিছু কম দৃশ্যমান সম্পর্কে ব্যবহারকারীদের প্রতিক্রিয়া জানানোর জন্য বিভিন্ন উপায়ে ব্যবহার করতে পারেন যা সিস্টেমটি করছে, অর্থাত্ অদৃশ্য জিনিসগুলিকে কিছুটা আরও দৃশ্যমান করার উপায় থাকতে পারে। (এমনকি এটি যদি রিলিজ নোটের একটি সেট লেখার জন্য উত্সাহিত করে তবে এটি প্রমাণ করে যে আপনার প্রচেষ্টা ইত্যাদির কারণে সিস্টেমের কার্য সম্পাদন এখন কত দ্রুত হয়)
গল্প এবং কাজগুলির মধ্যে সম্পর্ক
এখানে কার্যগুলি এবং ব্যবহারকারীর গল্পগুলিকে সম্পর্কিত করা সত্যিই কঠিন হয়ে উঠতে পারে।
আমাদের পদ্ধতির ব্যবহারকারী গল্প নিবদ্ধ রাখা ছিল কি অনুরোধ ছিল কেন এটি তৈরি করা হয়েছিল, এবং কি জিনিস হতে প্রয়োজন সত্য মার্কিন "সম্পন্ন হয়েছে" বিবেচনা করতে হবে। কিভাবে সবসময় আমাদের জন্য ফেলে এবং বিকাশকারী (গুলি) তে রাখা হয়।
বিকাশকারীরা যুক্তরাষ্ট্রে বর্ণিত সমস্যাটি তারা যে কাজ করবে সেগুলির একটি সেটগুলিতে ভাগ করে দেবে।
আমি এটি এমন একজন হিসাবে বলছি যিনি বেশিরভাগ অংশে ব্যাক-এন্ড সার্ভার-সাইড প্রোগ্রামিং করেছিলেন যা সম্ভবত আপনি "ব্যবহারকারী হিসাবে শেষ" হিসাবে পেতে পারেন "অদৃশ্য" "
আমার যা করা দরকার তার উপর নির্ভর করে আমি মাঝে মাঝে একটি সাধারণ "লোডিং ..." অ্যানিমেশন / জিআইএফ দেখানোর জন্য এজেএক্স ব্যবহার করি যাতে ব্যবহারকারী বুঝতে পারে যে তাদের ভুল ধারণা না পেয়ে অন্য কিছু শেষ হওয়ার জন্য কিছুটা অপেক্ষা করা দরকার। কখনও কখনও এটি এই হিসাবে সহজ ছিল। এর জন্য একটি কাজ উপযুক্ত হবে।
বিভিন্ন দৃষ্টান্ত, অনুশীলন এবং অভিজ্ঞতা
এই সমস্যাটি কাটিয়ে ওঠার জন্য কি কৌশল আছে বা এটি আমাদের গ্রহণ এবং এটির সেরাটি তৈরি করার মতো কিছু আছে?
দৃষ্টান্তের শিফট গ্রহণ, অনুশীলন এবং অর্জিত অভিজ্ঞতা গ্রহণের বাইরে সম্ভবত আরও কিছু বলার নেই। আমি প্রায়শই লোকেদের প্রক্রিয়াটির মাধ্যমে শর্টকাট নেওয়ার চেষ্টা করতে দেখেছি। আমি এর বিরুদ্ধে পরামর্শ দেব, বিশেষত যদি আপনি শুরু করেন। আপনি আরও অভিজ্ঞতা পেতে, আপনি কিছু নমনীয়তা অনুমতি দিতে পারেন, কিন্তু নিজেকে হ্রাস এড়াতে।
আপনার পূর্বের শব্দটি দেওয়া, আপনি এখনও গল্পগুলি নিয়ে ভাবছেন যেন সেগুলি "নাম পরিবর্তিত প্রয়োজনীয়তা", যা আমি মনে করি এটি একটি ভুল ধারণা um আমি মনে করি এটি Agile এবং নন-অ্যাগিল পদ্ধতির মধ্যে মৌলিক পার্থক্য সম্পর্কে গভীরতর সমস্যার একটি লক্ষণ ।
দ্বিতীয়ত, আমি মনে করি যে আপনি জলপ্রপাতের তুলনায় চটপটি একটি দৃষ্টান্ত বদল হিসাবে গ্রহণ করবেন , যার অর্থ প্রক্রিয়াটির একই লক্ষ্য রয়েছে, তারা খুব ভিন্ন উপায়ে এটি নিয়ে যান। (এসভিএন বনাম গিতকে ভাবুন, যদি তা সাহায্য করে))
প্রয়োজনীয়তা এবং ব্যবহারকারীর গল্পগুলির মধ্যে ধারণাগত পার্থক্য সম্পর্কে আপনার বর্তমান বোঝার উন্নতি করার চেষ্টা করুন এবং সেগুলি একই জিনিস নয় বলে স্বীকার করুন।
আপনার স্প্রিন্ট থেকে শিখতে - পূর্ববর্তী
আমি কি যথেষ্ট চাপ সৃষ্টি করতে পারে ভূতাপেক্ষ প্রতিটি স্প্রিন্ট শেষে স্ক্রাম মাস্টার এবং ডেভেলপারগণ মধ্যে। এটি সেই জায়গা যেখানে তারা এমন বিষয় নিয়ে আলোচনা করেন যা "ভাল হয়েছে" বা "ভাল হয়নি" সত্যবাদী / স্বচ্ছ উপায়ে এবং "স্পষ্টভাবে যায়নি" পয়েন্টগুলিকে সম্বোধন করার জন্য পরবর্তী স্প্রিন্টের জন্য কী কার্যকর পরিবর্তনগুলি প্রয়োগ করা হবে ।
এটি আমাদের একে অপরের অভিজ্ঞতা থেকে খাপ খাইয়ে নিতে এবং এমনকি শিখতে দেয় এবং এটি জানার আগে আমাদের দলের গতিবেগের সাধারণ ধারাবাহিকতা অনুসারে আমরা উল্লেখযোগ্যভাবে উন্নতি করেছি।