স্প্রিন্ট পরিকল্পনা: Agile সেরা অনুশীলন

পরিকল্পনার মূলনীতি

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

1. পরিকল্পনার জন্য প্রস্তুতি আগেই শুরু হওয়া উচিত। মিটিংয়ের অন্তত এক দিন আগে Product Owner backlog গুছিয়ে অগ্রাধিকার ঠিক করে রাখবেন। ডেভেলপমেন্ট দলও যেন আগেই user story পড়ে দেখতে পারে এবং অস্পষ্ট জায়গা নিয়ে প্রশ্ন করতে পারে।
2. ক্লাসিক বরাদ্দের নিয়ম: স্প্রিন্টের প্রতি সপ্তাহের জন্য দুই ঘণ্টা পরিকল্পনা। দুই সপ্তাহের স্প্রিন্টে তাহলে চার ঘণ্টা। তবে অভিজ্ঞতা বলে, একটা লম্বা মিটিংয়ের চেয়ে এই সময় কয়েকটা ছোট সেশনে ভাগ করলে প্রায়ই ভালো ফল আসে।

প্রস্তুতি পর্যায়

ভালো প্রস্তুতি ছাড়া স্প্রিন্ট পরিকল্পনা উন্নত করা যায় না। এই ধাপটিকে প্রায়ই হালকাভাবে নেওয়া হয়। অথচ পুরো প্রক্রিয়া সফল হবে কি না, তা ঠিক হয় এখানেই।

• Definition of Ready (DoR) ঠিক করে দেয়, কোন user story স্প্রিন্টে নেওয়ার মতো তৈরি। প্রতিটি story-তে থাকা উচিত স্পষ্ট গ্রহণযোগ্যতার মানদণ্ড, জটিলতার অনুমান আর অন্য কাজের ওপর নির্ভরতার তালিকা। DoR না মানলে পরিকল্পনা এলোমেলো হয়ে যায়। দল তখন পরিকল্পনার বদলে প্রশ্নের জট খুলতেই সময় কাটায়।
• Backlog refinement নিয়মিত হওয়া উচিত, শুধু স্প্রিন্ট পরিকল্পনার আগে নয়। এই কাজে স্প্রিন্টের সময়ের 10% রাখা প্রচলিত রীতি। দল সপ্তাহে কয়েকবার ছোট refinement সেশন করে ধাপে ধাপে সামনের স্প্রিন্টের story গুছিয়ে নিতে পারে।
• Velocity বিশ্লেষণ দলকে দেখায়, সে আসলে কতটা কাজ ডেলিভার করতে পারে। শেষ 3-5 স্প্রিন্টের গড় Velocity দেখাই যথেষ্ট নয়। সামনের স্প্রিন্টে কাজের গতি কমাতে পারে এমন বিষয়ও হিসাবে ধরতে হবে: ঠিক করা ছুটি, সরকারি ছুটির দিন, জমে থাকা প্রযুক্তিগত ঋণ বা বাইরের নির্ভরতা।

পরিকল্পনা সেশন

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

1. দল, Product Owner এর সাথে একসাথে, এমন একটি স্প্রিন্ট লক্ষ্য ঠিক করে, যা বেছে নেওয়া সব user story-কে এক সুতোয় বাঁধে। লক্ষ্যটি হওয়া উচিত নির্দিষ্ট, মাপা যায় এমন এবং সবার কাছে অর্থবহ। দুর্বল লক্ষ্য: "ব্যবহারকারীর অভিজ্ঞতা উন্নত করুন।" ভালো লক্ষ্য: "ব্যবহারকারীরা এক ক্লিকে সোশ্যাল মিডিয়ার মাধ্যমে নিবন্ধন করতে পারবেন।"
2. ডেভেলপমেন্ট দল বেছে নেওয়া story-গুলো ছোট কাজে ভাঙে এবং ঘণ্টার হিসাবে অনুমান করে। ভাঙলেই বেরিয়ে আসে এমন জটিলতা আর নির্ভরতা, যা story-র স্তরে চোখে পড়ে না। কোনো কাজে 8 ঘণ্টার বেশি লাগা উচিত নয়। এর বেশি লাগলে কাজটিকে আরও ছোট সাবটাস্কে ভাঙতে হবে।

ভূমিকা এবং দায়িত্ব

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

• Scrum Master প্রক্রিয়াটি চালান, টাইমবক্স মেনে চলা নিশ্চিত করেন এবং দলকে সিদ্ধান্তে পৌঁছাতে সাহায্য করেন। তিনি সমাধান চাপিয়ে দেন না। তিনি ঠিক প্রশ্নগুলো করেন এবং খেয়াল রাখেন, আলোচনা যেন কাজের দিকে থাকে।
• Product Owner backlog-এর অগ্রাধিকার এবং কোন ফিচার আগে তৈরি হবে, সেই সিদ্ধান্তের দায়িত্বে থাকেন। প্রতিটি story-র ব্যবসায়িক মূল্য বোঝাতে আর ডেভেলপমেন্ট দলের প্রশ্নের এমন নির্দিষ্ট উত্তর দিতে তাঁকে তৈরি থাকতে হবে, যাতে দল অনুমান করতে পারে।
• ডেভেলপমেন্ট দল ফলাফল ডেলিভারের প্রতিশ্রুতি দেয়। এই প্রতিশ্রুতি বাইরে থেকে ঠিক করে দেওয়া হয় না, দল নিজেই দেয়। নিজের দেওয়া কথায় যে তাগিদ আর দায়বোধ থাকে, চাপিয়ে দেওয়া লক্ষ্যে তা আসে না।

সাধারণ ভুল

• ক্ষমতা অতিমূল্যায়ন হল সবচেয়ে ঘন ঘন স্প্রিন্ট পরিকল্পনা ত্রুটি। দল প্রায়ই যতটা শেষ করতে পারে, তার চেয়ে বেশি কাজ হাতে নেয়, বিশেষ করে প্রকল্পের শুরুতে বা একটা সফল স্প্রিন্টের পরে। কাজের নিয়ম সহজ: কম কথা দিয়ে বেশি করে দেখানো ভালো। কথা রাখতে না পারলে স্টেকহোল্ডারদের আস্থা কমে, পরের স্প্রিন্টগুলোতে দলের উৎসাহও কমে যায়।
• সময় বাফারের অনুপস্থিতি একটি সমালোচনামূলক কাঠামোগত ত্রুটি। স্প্রিন্ট পরিকল্পনায় অপ্রত্যাশিত কাজ, বাগ আর প্রযুক্তিগত সহায়তার অনুরোধের জন্য 10-20% বাফার সময় রাখা উচিত। এই রিজার্ভ আগে থেকে বাড়তি story দিয়ে ভরে রাখা চলবে না। এর কাজ হলো প্রতিটি স্প্রিন্টে যে অপরিকল্পিত কাজ আসেই, তা সামলে নেওয়া।
• নির্ভরতা উপেক্ষা করা স্প্রিন্টের মাঝামাঝি ব্লকার তৈরি করে। বাইরের সব নির্ভরতা পরিকল্পনার সময়েই চিহ্নিত করে মিটিয়ে ফেলা উচিত। কোনো কাজ অন্য দল বা বাইরের সরবরাহকারীর ওপর নির্ভর করলে স্প্রিন্ট শুরুর আগেই সময়সীমায় একমত হতে হবে এবং তার নিশ্চয়তা নিতে হবে।

প্রক্রিয়া পর্যবেক্ষণ

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

বিশ্লেষণের জন্য মেট্রিক্স:

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

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

পরিকল্পনা অভিযোজন

• দূরবর্তী দলগুলির স্প্রিন্ট পরিকল্পনার জন্য নির্দিষ্ট অভিযোজন প্রয়োজন। একসঙ্গে কাজ করার উপযোগী সরঞ্জাম হাতে থাকতে হবে, আর দূর থেকে যুক্ত সবাই যেন সমানভাবে অংশ নিতে পারেন, সেদিকে সক্রিয়ভাবে নজর রাখতে হবে। ছড়িয়ে থাকা দলে একটা লম্বা মিটিংয়ের চেয়ে কয়েকটা ছোট সেশনে পরিকল্পনা করলে অংশগ্রহণ আর ফলাফল দুটোই নিয়মিতভাবে ভালো হয়।
• একাধিক দল সহ বড় প্রোগ্রামগুলির প্রোগ্রাম স্তরে সমন্বয় প্রয়োজন। Scrum of Scrums বা SAFe (Scaled Agile Framework) এমন দলগুলোর স্প্রিন্ট পরিকল্পনা মেলানোর কাঠামো দেয়, যাদের মধ্যে নির্ভরতা আছে।
• রক্ষণাবেক্ষণ প্রকল্প, যেখানে স্প্রিন্টের বড় একটা অংশ যায় সহায়তা আর বাগ সারাইয়ে, সেখানে অপরিকল্পিত কাজের জন্য আলাদা করে সক্ষমতা রেখে দিতে হয়। প্রচলিত হিসাবে স্প্রিন্ট সক্ষমতার 30-50% রাখা হয় সহায়তার কাজে, বাকিটা নতুন ফিচারের জন্য। এতে সহায়তাকে পরিকল্পনার বাইরের বোঝা ধরে নেওয়ার ভুল এড়ানো যায়, ডেলিভারিও ভেস্তে যায় না।

সংশ্লিষ্ট নিবন্ধ:

প্রকল্প ব্যবস্থাপনার কাঠামো আর সীমাবদ্ধতার ভারসাম্য নিয়ে পড়ুন প্রকল্প ব্যবস্থাপনা ত্রিভুজ: পরিধি, সময় এবং খরচের ভারসাম্য।

Kanban বোর্ড আর ভিজ্যুয়াল ওয়ার্কফ্লো ব্যবস্থাপনার ব্যবহারিক পরিচয় পাবেন এখানে: Kanban বোর্ড কী? ভিজ্যুয়াল ওয়ার্কফ্লো ব্যবস্থাপনার একটি নির্দেশিকা।

প্রকৃত ব্যবহারকারীর চাহিদার সঙ্গে তাল রাখতে Agile দল কীভাবে পারসোনা ব্যবহার করে, তা জানতে পড়ুন Agile ব্যক্তিত্ব: Agile প্রকল্পগুলিতে ব্যবহারকারী-কেন্দ্রিক উন্নয়ন উন্নত করা। আরও পড়ুন: কানবান বোর্ড।

উপসংহার

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