কীভাবে প্রয়োজনীয়তা পরিচালনার কাজ দীর্ঘস্থায়ী প্রকল্পের সাথে কাজ করে?


14

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

স্ক্র্যাম এঙ্গেল থেকে নতুন প্রয়োজনীয়তা বা বিদ্যমান প্রয়োজনীয়তার পরিবর্তনগুলি ব্যবহারকারী গল্পগুলির মাধ্যমে সরবরাহ করা হয়। এবং ব্যবহারকারী গল্পগুলি একটি এপিক বা বৈশিষ্ট্যের অধীনে গোষ্ঠীযুক্ত আরও বড় জটিল প্রয়োজনীয় সরবরাহের সুবিধার্থে।

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

সুতরাং, যদিও ব্যবহারকারী গল্পগুলি আনুষ্ঠানিক প্রয়োজনীয়তা নয়, সেগুলির মাধ্যমে ব্রাউজ করা আপনাকে তাদের অন্তর্নিহিত প্রয়োজনীয়তার সম্পর্কে একটি পরিষ্কার ধারণা দিতে পারে। স্বল্প মেয়াদে.

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

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

এখন, কোনও প্রকল্পের বিকাশের পুনরাবৃত্তির (2 টি উত্পাদন স্থিতিশীল) মধ্যে 2 বছরের ব্যবধানটি কল্পনা করুন। আসল দলটি চলে গেছে এবং তাদের সমস্ত জ্ঞান।

যদি মূল দলটি জানত যে এটি ঘটতে চলেছে (যেমন, এটি ব্যবসায়ের প্রকৃতি), তবে পরবর্তী দলগুলিকে সহায়তা করার জন্য তারা কী ব্যবস্থা নিতে পারে?

অবশ্যই, ব্যাকলগটি কিছু তথ্য সরবরাহ করবে তবে এটি সহজেই ব্রাউজযোগ্য ফর্মের মধ্যে নয়।

সুতরাং, কেন এবং কীভাবে সেখানে এসেছিল সহ পরবর্তী দলগুলি প্রকল্পের অবস্থা বুঝতে সহায়তা করার জন্য কী করা যেতে পারে ?

আমার অভিজ্ঞতায়, নিম্নলিখিত জিনিসগুলি কাজ করে না:

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

সুতরাং, পুনরাবৃত্তি করতে:

দীর্ঘমেয়াদে একজন কীভাবে চপল প্রকল্পের প্রয়োজনীয়তা পরিচালনা করে?


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

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

1
চতুরতা প্রকল্প সম্পর্কে নয় বরং পরিবর্তে পণ্য বিকাশ করে । এত দীর্ঘ মেয়াদী প্রকল্পগুলি প্রকৃতপক্ষে আগলে নেই। প্রতিটি বিকাশের অংশটি স্বয়ংসম্পূর্ণ থাকতে হবে।
ডেভ হিলিয়ার 13

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

1
"বিকাশকারীদের দলকে ওঠানামা করা" এটি এখানে আসল সমস্যা বলে মনে হচ্ছে। আপনার ক্ষেত্রে এটি কতটা খারাপ?
ইওফোরিক

উত্তর:


10

এটি আমার কাছে Agile প্রকল্পগুলির সাথে কক্ষের অপ্রত্যাশিত হাতি বলে মনে হচ্ছে: কীভাবে আপনি তাদেরকে বিশৃঙ্খলায় পরিণত হতে আটকাবেন?

আসুন এক মুহুর্তের জন্য এজিলে ম্যানিফেস্টোটি দেখুন। চতুর ইচ্ছা:

  1. প্রথম দিকে এবং অবিচ্ছিন্ন ডেলিভারি
  2. পরিবর্তন প্রয়োজনীয়তা আলিঙ্গন
  3. ঘন ঘন ওয়ার্কিং সফ্টওয়্যার বিতরণ
  4. বিকাশকারী এবং ব্যবসায়ের অংশীদাররা প্রতিদিন একসাথে কাজ করে
  5. অনুপ্রাণিত ব্যক্তিদের চারপাশে প্রকল্পগুলি তৈরি করা, তাদের প্রয়োজনীয় পরিবেশ এবং সহায়তা প্রদান এবং কাজটি করার জন্য তাদের উপর আস্থা রেখে
  6. যোগাযোগের প্রাথমিক মোড হিসাবে মুখোমুখি কথোপকথন
  7. অগ্রগতির প্রাথমিক পরিমাপ হিসাবে ওয়ার্কিং সফটওয়্যার
  8. টেকসই উন্নয়ন
  9. প্রযুক্তিগত উত্সাহ এবং ভাল নকশায় অবিচ্ছিন্ন মনোযোগ
  10. সরলতা - আপনার যে কাজটি করতে হবে না তা সর্বাধিক করা
  11. নিয়মিত বিরতিতে, দলটি আরও কার্যকর কীভাবে হওয়া যায় তার উপর প্রতিফলিত করে, তারপরে সুর করে এবং সে অনুযায়ী তার আচরণটি সামঞ্জস্য করে

আমি শেষ চারটি হাইলাইট করেছি। কেন? কারণ তারা হ'ল এই প্রকল্পটি তার নিজস্ব ওজনে ডুবে যাওয়া রোধ করবে।

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

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

এবং তিনিই হলেন যে মাস্টার প্রয়োজনীয়তার নথিটি বজায় রাখে।

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

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


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

এখন পর্যন্ত আমাদের দুর্বলতম অঞ্চলটি নির্দিষ্ট, পরীক্ষামূলক, পরিমাপযোগ্য প্রয়োজনীয়তা সংগ্রহ করছে এবং প্রকল্পের ক্ষেত্রের তুলনায় গ্রাহকের প্রত্যাশা পরিচালনা করে। তবে আমরা এটি নিয়ে কাজ করছি।


1
হাতি কি ম্যামথ? লোল :)
ডেভ হিলিয়ার

1
বাঃ। আপনি যদি উপবিষ্ট হন তবে আপনি রসিকতা করতে পারেন। :)
রবার্ট হার্ভে

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

@ জর্জিও: এজন্যই আমি বলেছিলাম যে তারা তর্কবিতর্ক নয়। প্রতিটি নতুন সফ্টওয়্যার প্রকল্প Agile এর অধীনে নির্মিত হয় না এবং সবাই যেভাবেই চতুর অনুসারী হয় না।
রবার্ট হার্ভে

@ রবার্টহারভে: মূল বিষয়টি হল আপনি কোনও বড় প্রকল্পের সাথে চটপটে ব্যবহার করতে পারবেন কিনা। যেমনটি আপনি ব্যাখ্যা করেছেন, আপনার কমপক্ষে কিছু পরিকল্পনা এবং প্রকল্পের সামগ্রিক কাঠামোর সংক্ষিপ্ত বিবরণ প্রয়োজন যাতে আপনি এটিকে একটি সাবজেক্টে বিভক্ত করতে পারেন যা চতুর উপায়ে করা যেতে পারে। আমি মনে করি না পার্থক্যটি পুরানো এবং নতুন মধ্যে তবে বড় এবং ছোটের মধ্যে।
জর্জিও

3

প্রশ্নটি পুরোপুরি স্পষ্ট নয় তবে মনে হচ্ছে আপনি প্রয়োজনীয়তাগুলি সনাক্তকরণের সাথে সম্পর্কিত । আমার অভিজ্ঞতায় Agile এ হারিয়ে যাওয়ার ঝোঁক একটি ধারণা হ'ল ব্যবসায়ের প্রয়োজনীয়তা গ্রাহকরা সিস্টেমটি যা চায় তা হ'ল , যখন ব্যবহারকারী গল্পগুলিতে সিস্টেমটি কীভাবে কাজ করে তা জানায় সত্যই কার্যকর প্রয়োজন function "একজন ব্যবহারকারী হিসাবে আমি এক্সে সক্ষম হতে চাই want" তবে এটি একটি প্রয়োজনীয়তা পূরণের জন্য করা হয়, যা ব্যবহারকারীর গল্পে হারিয়ে যেতে পারে।

আমার অভিজ্ঞতায় যা ভাল কাজ করে তা হ'ল উভয় দিকের ব্যবসায়ের প্রয়োজনীয়তা এবং ব্যবহারকারীর গল্পগুলিকে সংযুক্ত করে। বিআর # 1 ক এবং খ গল্পের দ্বারা উপলব্ধি হতে পারে গল্প সি বিআর # 2 এবং # 3 কভার করতে পারে। আপনি যা যা ব্যবহার করছেন তা আপনার প্রোজেক্ট ট্র্যাকার, স্প্রেডশিটে রাখুন।

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

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


2

আমি আসলে একটি বড় ওয়েব শপের কানবান মেইনটেনেস প্রকল্পে কাজ করছি যেখানে মূল বিকাশকারীদের আর আর পাওয়া যায় না।

প্রতিটি ইউজারস্টোরি / প্রয়োজনীয়তা / বাগফিক্সের টিকিট সংখ্যা থাকে এবং প্রতিটি উত্সকোড-পরিবর্তন সোর্সকন্ট্রোল-মন্তব্য-ক্ষেত্রের একটি টিকিটবারের সাথে যুক্ত থাকে।

সোর্সকন্ট্রোল-চেকিন-এস (এসএনএন) মূলত কোরসপন্ডিংয়ের টিকিট আপডেট করুন যাতে টিকিটে আমার সাথে সমস্ত উত্সের কন্টোল-চেঞ্জসেটের লিঙ্ক থাকে।

যদি কোনও মডুল / ফাংশন নতুনভাবে প্রয়োগ করা হয় তবে উত্সকোডে টিকিট সংখ্যাগুলিও রয়েছে।

টিকিট-সিস্টেমে (পুনর্নির্মাণ) টিকিট একে অপরের মধ্যে সংযুক্ত রয়েছে যেমন (সদৃশ, বাগটি, এর পরিশোধন, ....)

যাতে আপনি টিকিটগুলি অনুসরণ করতে পারেন এবং সময়ের সাথে সাথে প্রয়োজনীয় পরিবর্তনগুলিও দেখতে পারেন।

উদাহরণ: আমাকে "অর্ডার কনফার্মেশন-ওয়েব-পৃষ্ঠা" তে কিছু করতে হবে। পৃষ্ঠার সোর্সকোডে আমি একটি মন্তব্য দেখতে পেয়েছি: '# 4711 "এর জন্য তৈরি করা হয়েছে যাতে আমি আমার নতুন টিকিটটিকে পুরানো টিকিট" 4711 "বা এর উত্তরসূরির একজনের সাথে সংযুক্ত করতে পারি।


টিকিট ব্যবস্থায় সম্পর্ক বজায় রাখার দায়িত্বে কে থাকবেন?
মেটাফাইট

1

ব্যক্তিগতভাবে, আমি সিস্টেমগুলি কী করতে পারে তার ডকুমেন্টেশনের উত্স হিসাবে ব্যবহারকারী গল্পগুলি বাতিল করে দিই। ডকুমেন্টেশন তৈরি করার জন্য সক্রিয় পদক্ষেপ না নেওয়া (যদি আমরা আমাদের আরও কিছু traditionalতিহ্যবাহী ক্লায়েন্টদের জন্য করেছি) অ্যাপ্লিকেশন বেসটি সত্যই সেখানে সেরা ডকুমেন্টেশন।

যদিও, এটি নতুন কিছু নয়।

আপনি যদি Agile ( SAFe এর মতো ) এর আরও মাপানো সংস্করণ ব্যবহার করে থাকেন তবে আপনার কাছে অন্যান্য ব্যাকলোগগুলি রয়েছে যা বাস্তবায়ন ব্যাকলগ নয়। এটি দেখতে মূলত:

  1. পোর্টফোলিও ব্যাকলগ (মহাকাব্য এবং বাজেটের কৌশলগত পরিকল্পনা)
  2. প্রোগ্রাম / প্রকাশের ব্যাকলগ (বৈশিষ্ট্য এবং এপিক্স)
  3. প্রকল্প / টিম ব্যাকলগ (গল্প, স্পাইকস, বাগ)

আমি টিম ব্যাকলগ স্তরে ডকুমেন্টিংয়ের পরামর্শ দেব না। এটি খুব দানাদার এবং খুব কমই কেউ বিশদে এই স্তরে যেতে চায় না। একটি রিলিজের মধ্যে এমন গল্পগুলি থাকতে পারে যা টিমের ব্যাকলগে পূর্বের গল্পগুলির সাথে বিরোধিতা করে।

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

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