SAFe এবং Scrum-এর প্রেক্ষাপটে বার্ন ডাউন চার্ট ব্যবহারের অভিজ্ঞতা

এই নিবন্ধে আমি বলার পরিকল্পনা করছি যে আমাদের অভিজ্ঞতায় SAFe পদ্ধতিতে কাজ করার প্রক্রিয়ায় আমরা কীভাবে বার্ন ডাউন চার্ট ব্যবহার করি

আমি বোধহয় সবচেয়ে মজার বিষয় দিয়েই শুরু করি। আর তা হলো, SAFe-তে এই চার্টের ব্যবহারের SCRUM-এ এই চার্টের ব্যবহারের তুলনায় কোনো বিশেষত্ব থাকা উচিত নয়। নাকি থাকা উচিত?

আমাদের SAFe-তে RTE-এর মতো একটি ভূমিকা রয়েছে, যা SCRUM-এ নেই। বার্ন ডাউন চার্ট হলো স্প্রিন্টে কাজের পরিমাণ ট্র্যাক করার একটি হাতিয়ার এবং এটি সবার আগে SCRUM দলের জন্য প্রয়োজন, বাইরের কারও জন্য নয়, তাই না?

সুতরাং, সবকিছু সত্ত্বেও এবং এখনও SAFe ফ্রেমওয়ার্কের ভেতরেই থেকে, আমি তবুও বলি আমরা কীভাবে বার্ন ডাউন চার্ট ব্যবহার করি।

আমি Scrum Master -এর ভূমিকায় আছি এবং প্রতিদিন পুরো Dev Team-এর জন্য এই চার্টটি তুলে ধরার চেষ্টা করি। যে মাধ্যমটি আমি ব্যবহার করি তা হলো টিম চ্যাট, "@" দিয়ে পুরো দলকে উল্লেখ করা, চার্টের বর্তমান অবস্থার স্ক্রিনশট। পুরো দলকে উল্লেখ করা বেশ সূক্ষ্ম একটি হাতিয়ার এবং এটি যতটা সম্ভব কম ব্যবহার করা গুরুত্বপূর্ণ (কারণ, আমরা, স্ক্রাম মাস্টাররা, দলকে আরামে এবং সর্বনিম্ন সম্ভাব্য মনোযোগ বিচ্যুতি নিয়ে কাজ করতে সাহায্য করব, তাই না?)

ফলে দল প্রতিদিন স্প্রিন্টের বর্তমান অবস্থা দেখে এবং নিম্নলিখিত ঘটনাগুলো ট্র্যাক করতে সক্ষম হয়

• অপরিকল্পিত কাজের আবির্ভাব
• অসম্পূর্ণ অবস্থায় কাজের দীর্ঘকাল ঝুলে থাকা
• অতিরিক্ত ঝুঁকি সংযোজন
• কাজটি সঠিক গতিতে এগোচ্ছে কি না তা বোঝা

এরপর আমি এই প্রতিটি ঘটনা ব্যাখ্যা করার এবং নিজের অভিজ্ঞতা থেকে উদাহরণ দেওয়ার চেষ্টা করব।

অপরিকল্পিত কাজের আবির্ভাব

এই চার্টে খুব ভালোভাবে দেখা যায় কীভাবে নতুন কাজের আবির্ভাব ঘটে (দুই সপ্তাহের স্প্রিন্টের দ্বিতীয় মঙ্গলবারে)।

অভিজ্ঞতার একটি ঘটনা: "একজন ডেভেলপার, agile নীতিগুলো ভাগ করে নেওয়া scrum দলের সদস্য হিসেবে, Product-এর সাথে সরাসরি দুর্দান্তভাবে যোগাযোগ করেন। Product তাকে বলেন যে এটা তাড়াতাড়ি করে বানিয়ে ফেলতে হবে, তুমি তো নিজেই বোঝো, এখানে দ্রুত এবং ঝুঁকি ন্যূনতম।

ডেভেলপার দুর্দান্ত, তিনি agile সম্পর্কে এবং ব্যবসায়িক মূল্য সরবরাহের গুরুত্ব সম্পর্কে সবকিছু জানেন, গিয়ে বোর্ডে ব্যাকলগ থেকে একটি হিস্টোরি ফেলে দেন, দল এটি 6 sp-তে অনুমান করেছে।

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

অবশ্যই, আদর্শভাবে দলের চার্ট ছাড়াই স্ট্যান্ডআপে নতুন কাজের আবির্ভাব লক্ষ্য করা উচিত। কিন্তু চার্টটি একটি ভালো সূচক, যা পুরো দলের জন্য এত গুরুত্বপূর্ণ এই পরিবর্তনটি না লক্ষ্য করার ঝুঁকিকে ন্যূনতম করে।

এখানে বোঝা গুরুত্বপূর্ণ যে দলের স্তরের উপর নির্ভর করে পরিস্থিতি ভিন্নভাবে এগোতে পারত। দুর্দান্ত দলগুলোতে প্রোডাক্ট ওনার সম্ভবত এমন করতেন না, আর করলেও "এটা তাড়াতাড়ি বানিয়ে ফেলা যায়" বলে নয়, বরং "আমি অনুমান করছি 55% সম্ভাবনা আছে যে এখন এটি বানালে পরের মাসে আমাদের মুনাফা 20% বাড়তে পারে" বা অন্য কোনো পরিমাপযোগ্য মেট্রিক দিয়ে যুক্তি দিতেন।

অসম্পূর্ণ অবস্থায় কাজের দীর্ঘকাল ঝুলে থাকা

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

• কাজের দুর্বল বিভাজন

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

• সঠিকভাবে প্রণীত নয় এমন DOD

  DOD (Definition of Done) - স্প্রিন্টে User Story-এর প্রস্তুতির মানদণ্ডের বর্ণনা। কখনও কখনও সেগুলো একেবারেই থাকে না বা খুব বিমূর্তভাবে বর্ণিত থাকে। এটি অবশ্যই একটি সমস্যা হতে পারে, যা স্বাভাবিকভাবেই সমাধান করতে স্ক্রাম মাস্টারকে সাহায্য করতে হবে

ঝুঁকির অতিরিক্ত সংযোজন

এই ক্ষেত্রে আমরা এমন পরিস্থিতি দেখতে পাই যেখানে দল ঝুঁকি অতিরিক্ত ধরেছে।

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

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

বোঝাপড়া - কাজটি কি সঠিক গতিতে এগোচ্ছে

এখানে আমি Burn Down Chart প্রদর্শনের গ্রাফিকভাবে অনুপযুক্ত পদ্ধতিগুলোর দিকে মনোযোগ দিতে চাই

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

• স্প্রিন্টে নতুন SP যোগ হওয়া লক্ষণীয় নয়

  এখানে, উপরের চার্টে, প্রায় বোঝা যায় না যে অপরিকল্পিত কাজ যোগ হয়েছে। নিচেরটিতে এটি আরও স্পষ্ট।

• কাজের আপেক্ষিক অবশিষ্টাংশ সঠিকভাবে প্রদর্শিত হয় না

  উপরের চার্ট অনুসারে আরও ৩ দিন কাজ বাকি। প্রকৃতপক্ষে ২ দিন, ছুটির দিনে, সম্ভবত কেউ বিশ্রামের পরিকল্পনা করছে।

অবশ্যই, কারও কাছে এই ধরনের ছোট বিষয় তুচ্ছ মনে হতে পারে। কিন্তু বুঝতে হবে যে দলের প্রতিটি সদস্য কেবল এক পলকেই এই চার্টের দিকে তাকাবে এবং এটি সর্বোচ্চ উপকারী তথ্য পৌঁছে দিতে হবে।