কার্যকরী প্রয়োজনীয়তার অভাব কি চঞ্চল?


10

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

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

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

সুতরাং আমি ভাবছি - পুরানো সিস্টেমটি পুনর্লিখনের ক্ষেত্রে ব্যবসায়ের কোনও প্রয়োজনীয়তা না পাওয়া কি সত্যই চটুল?


1
নতুন সিস্টেমটি প্রতিস্থাপন না করা পর্যন্ত পুরানো সিস্টেমটি ব্যবহারে থাকবে, বা নতুন সিস্টেমটি ধীরে ধীরে পুরানো সিস্টেমে ফাংশনগুলি প্রতিস্থাপনের সাথে উভয় সিস্টেমই একই সাথে ব্যবহৃত হবে?
গ্রেগ বার্গার্ড্ট

1
@ গ্রেগবার্গার্ড্ট দ্বিতীয় বিকল্প
ল্যান্ডিও

1
আচ্ছা, আপনার দল কী পরিকল্পনা করবে? আপনি কি তাদের সংগ্রহ করতে যাচ্ছেন, ব্যবসায়ীদের সাথে কথা বলছেন ইত্যাদি?
ফিলিপ মিলোভানোভিć

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

3
আমি আসলে এই ভঙ্গুর কল করব ।
ম্যাসন হুইলারের

উত্তর:


21

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

আপনাকে ব্যবসায়ের মালিককে বলতে হবে যে পুরাতন সিস্টেমটি কীভাবে কাজ করে তা আপনার কোনও ধারণা নেই।

আপনার সেরা বিকল্পটি হ'ল খেলায় ব্যবসায়ের প্রক্রিয়াগুলি বোঝার জন্য আপনার ব্যবসায়ের মালিক বা কয়েক অভিজ্ঞ ব্যবহারকারীর সাথে কাজ করা এবং আপনার নিজের গ্রহণযোগ্যতা পরীক্ষাগুলি বিকাশ করা। আপনি যদি কিছু শেষ ব্যবহারকারীদের সাথে কাজ করতে পারেন তবে পুরানো সিস্টেম কীভাবে কাজ করে সে সম্পর্কে আপনি আরও প্রতিক্রিয়া পেতে পারেন।

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

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

আপনি নিম্নলিখিতগুলির একটি পাবেন:

  • যথাযথ প্রয়োজনীয়তা এবং একটি দ্রুত বিকাশ চক্র
  • প্রয়োজনীয়তা সংগ্রহ এবং সফ্টওয়্যারটি পুনর্নির্মাণের সময়
  • একটি নতুন প্রকল্প যা আপনার ক্যারিয়ারের কালো চিহ্ন হিসাবে শেষ হবে না

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

6
@ ল্যান্ডিও: একটি শক্তিশালী সময়সীমা থাকার পরে এটি থাকা শক্ত জায়গা। এজন্য প্রয়োজনীয়তার অভাবে যোগাযোগ করা আরও গুরুত্বপূর্ণ কারণ আপনাকে সময়সীমাটি মিস করতে বাধ্য করবে। আপনার দলটির যা প্রয়োজন তা আপনাকে পাওয়ার জন্য সময়সীমাটি হারিয়ে যাওয়ার ঝুঁকি হতে পারে।
গ্রেগ বার্গার্ট


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

16

চৌকস ক্রিয়ামূলক প্রয়োজনীয়তার প্রয়োজনীয়তা পরিবর্তন করে না, তবে আপনি কীভাবে তাদের সংগ্রহ করবেন তা সাধারণত পরিবর্তিত হয় । অবিচল উপায় হ'ল কেউ দীর্ঘ প্রক্রিয়া চালিয়ে যাওয়ার পরে আপনাকে সিস্টেমের জন্য সমস্ত প্রয়োজনীয়তা সম্বলিত একটি প্রকারের নথি দেয়।

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

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

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


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

4

ক্যাপচারিং প্রয়োজনীয়তা যে কোনও (সফল) সফ্টওয়্যার প্রকল্পের একটি প্রয়োজনীয় অংশ essential তবে একটি প্রয়োজনীয়তার স্পেসিফিকেশন লেখা নয়।

  • একটি ডকুমেন্টেশনকেন্দ্রিক দৃষ্টিভঙ্গি চাইনিজ ফিসফিসার খেলাগুলির মতো শেষ হতে পারে: একটি বিষয় বিশেষজ্ঞ প্রয়োজনীয়তার জন্য কণ্ঠ দেয়, একটি বিশ্লেষক এটি লিখে রাখেন, কোনও দেব এমন কিছু লেখার চেষ্টা করেন যা বিশ্লেষকের বর্ণনার সাথে মিলিত হয়, শেষ ব্যবহারকারী বিভ্রান্ত হয় কারণ সফ্টওয়্যারটি না করে তাদের সমস্যা সমাধান করবেন না।

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

  • সামনে সমস্ত প্রয়োজনীয়তা একত্রিত করার পরিবর্তে (এবং এভাবে বৃহত্তর ভুল বোঝাবুঝির ঝুঁকিপূর্ণ হওয়া), চৌকস দলগুলি সম্ভবত প্রয়োজনীয়তাগুলির একটি ছোট টুকরা দিয়ে শুরু করবে, একটি প্রোটোটাইপ তৈরি করবে এবং পরবর্তী পুনরাবৃত্তির প্রতিক্রিয়া সংগ্রহ করতে এটি ব্যবহার করবে।

  • সময়ের সাথে প্রয়োজনীয়তার বোঝাপড়াটি পরিবর্তিত হওয়ার সাথে সাথে একটি স্থিতিশীল প্রয়োজনীয়তার স্পেসিফিকেশন পুরানো হয়ে যাবে। এই কিভাবে প্রতিরোধ করা যায়?

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

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

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

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

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


1

আমরা এটি কীভাবে করেছি তা এখানে। আমরা মালিকদের সাথে কথা বলেছি। আমরা ম্যানেজারদের সাথে কথা বললাম। আমরা কাজটি ব্যবহারকারীদের সাথে কথা বলেছি। ব্যবহারকারীর ডেস্কে বসে এবং দেখে (এবং প্রশ্ন জিজ্ঞাসা করে) আমরা যা পেয়েছি তা আশ্চর্যজনকভাবে কার্যকর। পরিচালকরা জানতেন আমাদের কোন ব্যবহারকারীদের সাথে বসতে হবে।

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

সুতরাং যখন Agile দ্রুত সিস্টেমের কিছু অংশগুলি বন্ধ করতে পারে, অন্যরা আমাদের শুরু করার আগে আরও কিছুটা চিন্তাভাবনা এবং ডকুমেন্টিং করতে হয়েছিল।


0

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


0

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

আমি যে ফাঁদটির কথা বলছি তা ভাবছে যে জিনিসগুলি করার জন্য একটি নির্ধারিত এবং সঠিক চতুর উপায় রয়েছে। এটি হতে পারে কারণ লোকেরা মনে করে যে চপল বিদ্যমান। তুমি পারবে না কি কোনো অধিক আপনি পারেন তত্পর না বাস্তবমুখী।

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

নিত্যনতুন প্রকাশ, আলোচনা, শেখা, ফিরে যাওয়া এবং সফ্টওয়্যার পরিবর্তন করা হবে? আপনি নরম গুদাম বা হার্ডওয়্যার নির্মাণ করছেন?

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

পরিকল্পনার ছিদ্র সনাক্তকরণ ত্রুটি সন্ধান করা নয়, এটির সফ্টওয়্যার বিকাশ।

এই কারণে আমি গায়ের উত্তর পছন্দ করি।

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