Scrum সঙ্গে কাজ

ব্যবহারকারীর গল্প

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

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

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

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

গল্পের কাঠামোটি এইরকম দেখায়: "একজন ব্যবহারকারী <ব্যবহারকারীর ধরন> হিসাবে, আমি <ফলাফল> পেতে <ক্রিয়া> করতে চাই" (একজন পণ্যের মালিক হিসাবে আমি চাই ...)। এই ধরনের একটি কাঠামো শুধুমাত্র সহজ নয়, কিন্তু প্রত্যেকের কাছে বোধগম্য।

ব্যবহারকারীর গল্প ব্যবহারের সুবিধা:

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

ব্যবহারকারীর গল্পের অসুবিধা:

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

জমা কাজ

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

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

দুটি গুরুত্বপূর্ণ ব্যাকলগ শর্ত

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

"টিম ইন স্পেস" ওয়েবসাইট তৈরি করা হল রোডম্যাপের প্রথম প্রস্তাব। এটিকে মহাকাব্যে বিভক্ত করা দরকার (চিত্রে সেগুলি সবুজ, নীল এবং ফিরোজা রঙে দেখানো হয়েছে) এবং প্রতিটি মহাকাব্যের জন্য একটি ব্যবহারকারীর গল্প।

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

কোন বিষয়গুলির উপর ভিত্তি করে গ্রাহককে অগ্রাধিকার দেওয়া উচিত?

• ব্যবহারকারীদের প্রাসঙ্গিকতা।
• প্রতিক্রিয়া উপস্থিতি.
• উন্নয়নের জটিলতা।
• কাজের মধ্যে সম্পর্ক ("B" সম্পূর্ণ করতে, আপনাকে প্রথমে "A" করতে হবে)।

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

কিভাবে একটি ব্যাকলগ রাখা

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

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

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

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

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

স্প্রিন্ট

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

“স্ক্রাম ব্যবহার করে, আপনি একটি পরিষ্কার সময়কাল - স্প্রিন্ট সহ একাধিক পুনরাবৃত্তিতে একটি পণ্য বিকাশ করতে পারেন। এটি বড় প্রকল্পগুলিকে ছোট ছোট কাজের মধ্যে ভেঙ্গে ফেলতে সাহায্য করে,” মেগান কুক বলেছেন, আটলাসিয়ানের জিরা লিড৷

কিভাবে স্ক্রাম পরিকল্পনা করে এবং স্প্রিন্ট চালায়?

স্ক্রাম পদ্ধতির লেখকদের মতে, ভবিষ্যতের স্প্রিন্টের পরিকল্পনা করার জন্য, প্রত্যেককে আলাদা মিটিংয়ে দেখা করতে হবে। এই ইভেন্টে, দলের সদস্যদের অবশ্যই দুটি প্রধান প্রশ্নের উত্তর খুঁজে বের করতে হবে: এই স্প্রিন্টে কী করা দরকার এবং কীভাবে এটি করা যায়?

সফ্টওয়্যার গ্রাহক, স্ক্রাম মাস্টার এবং প্রোগ্রামাররা কাজের কাজের তালিকা নির্ধারণের সাথে জড়িত। গ্রাহক ব্যাকলগ থেকে স্প্রিন্টের লক্ষ্য এবং কাজগুলি ব্যাখ্যা করে।

তারপর দলটি একটি পরিকল্পনা তৈরি করে যা অনুযায়ী স্প্রিন্টের কাজগুলি সম্পন্ন করা হবে। এই পরিকল্পনা, নির্বাচিত কাজের আইটেম সহ, স্প্রিন্ট ব্যাকলগ বলা হয়। পরিকল্পনা মিটিং শেষে, দল কাজ পায়. বিকাশকারীরা ব্যাকলগ থেকে কাজগুলি নির্বাচন করে, কাজ শেষ হওয়ার সাথে সাথে প্রতিটি কাজের স্থিতি "প্রগতিতে" থেকে "সম্পন্ন" এ পরিবর্তিত হয়।

স্প্রিন্টের সময়, দলটি বর্তমান সমস্যা এবং অগ্রগতি নিয়ে আলোচনা করার জন্য দৈনিক স্ক্রাম মিটিং (স্ট্যান্ড-আপ) করে। স্প্রিন্টের সমাপ্তিকে প্রভাবিত করতে পারে এমন অসুবিধাগুলি চিহ্নিত করার জন্য এই ধরনের সভাগুলি প্রয়োজন।

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

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

কিসের দিকে মনোযোগ দিতে হবে আর কি করা উচিত নয়

বেশিরভাগ তরুণ দল প্রথমবারের মতো তাদের কর্মপ্রবাহে স্প্রিন্ট চালু করা কঠিন বলে মনে করে। সমস্যাগুলি এড়াতে, আমরা সুপারিশ করি যে আপনি অগ্রাধিকারের মনোযোগ প্রয়োজন এমন কর্মের তালিকা পর্যালোচনা করুন৷

আমরা কি করতে হবে:

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

কি এড়ানো উচিত:

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

স্ক্রাম বোর্ড

স্ক্রাম বোর্ড হল একটি টুল যা দেখায় কিভাবে স্ক্রাম টিমের কাজ করা হয়। আপনি কাগজে, দেয়ালে বা ইলেকট্রনিক আকারে (JIRA, Trello) এই জাতীয় বোর্ডে তথ্য প্রদর্শন করতে পারেন।

একটি স্ক্রাম বোর্ডে কমপক্ষে তিনটি কলাম থাকে: করণীয়, অগ্রগতিতে এবং সম্পন্ন। এখানে একটি উদাহরণ বোর্ড আছে:

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

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

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

বার্নডাউন চার্ট

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

দুটি ধরণের চার্ট রয়েছে:

• বার্নডাউন চার্ট একটি স্প্রিন্টে কাজের অগ্রগতি দেখায়।
• পণ্য প্রকাশ না হওয়া পর্যন্ত কাজের অগ্রগতি দেখানো বার্নডাউন চার্ট (ডেটা বেশ কয়েকটি স্প্রিন্ট থেকে সংক্ষিপ্ত করা হয়েছে)।

চার্ট উদাহরণ:

এই উদাহরণটি মনোবিজ্ঞান ব্যবহার করে: চার্টটি সম্পূর্ণ করা কাজের সংখ্যা দেখায় না, তবে অবশিষ্টের সংখ্যা (সম্পন্ন হয়নি)।

অর্থাৎ, যদি দলটি 100টির মধ্যে 90টি কাজ করে থাকে, তাহলে একটি মিথ্যা অনুভূতি হতে পারে যে সবকিছু প্রস্তুত। সর্বোপরি, 90 থেকে 100টি কাজের অগ্রগতি আসলে কিছুই পরিবর্তন করে না।

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