Scrum এবং SAFe প্রেক্ষাপটে Cumulative Flow ব্যবহারের অভিজ্ঞতা
এই নিবন্ধে আমি বলতে চাই কীভাবে আমাদের অভিজ্ঞতায় আমরা SAFe ফ্রেমওয়ার্কে কাজ করার প্রক্রিয়ায় Scrum-এ Cumulative Flow Chart ব্যবহার করি।ব্যক্তিগত ব্লগ।
এই ছবিটি লোড করা যায়নি।এই নিবন্ধে আমি বলতে চাই কীভাবে আমাদের অভিজ্ঞতায় আমরা Cumulative Flow Chart ব্যবহার করি Scrum-এ, SAFe
ফ্রেমওয়ার্কে কাজ করার প্রক্রিয়ায়। শুরু করি, সম্ভবত, এই নিবন্ধটির লিঙ্ক দিয়ে — এখানে, আমার মতে, এর আদর্শ রূপে উদ্দেশ্য ভালোভাবে বর্ণিত হয়েছে, আমার নিবন্ধ পড়ার আগে এটি পড়ার পরামর্শ দিচ্ছি। নিচে আমি বর্ণনা করব কীভাবে আমরা এটি Scrum-প্রক্রিয়ার জন্য অভিযোজিত করেছি(মূলত এটি Kanban-এ ব্যবহৃত হয়) এবং স্প্রিন্টে কাজ করার সময় এটি কোন সমস্যাগুলো সমাধান করতে সাহায্য করে।
আগে, Burn Down Charts সম্পর্কিত নিবন্ধে আমি ইতিমধ্যে বলেছি যে সেখানে আমরা নতুন কাজের আবির্ভাব এবং পুরোনো কাজের নিঃশেষণ দেখি। Burn Down Chart-এর সমস্যা হলো, Cumulative Flow Chart-এর বিপরীতে, এতে আমরা স্ট্যাটাস অনুযায়ী ইউজার স্টোরির গতিবিধি দেখি না। কিন্তু যখন আমরা Cumulative Flow Chart-এ স্ট্যাটাস অনুযায়ী গতিবিধি পর্যবেক্ষণ শুরু করি, তখন আমরা দৈনন্দিন পরিবর্তন দেখতে শুরু করি (Burn Down Chart কয়েক দিন অপরিবর্তিত থাকতে পারে এবং কিছু প্রেক্ষাপটে এটি সম্পূর্ণ স্বাভাবিক হতে পারে) এবং আরও সূক্ষ্ম সমস্যা লক্ষ্য করতে পারি।
গতিশীলতায় এটি এমন দেখাতে পারে(ছবিতে বাস্তব ডেটার ভিত্তিতে তৈরি চার্ট)।
এই উদাহরণে আমরা নিম্নলিখিত বিষয় দেখি
- স্প্রিন্টের প্রথম ৭ দিনে টেস্টিং-এ খুব অল্প পরিমাণ কাজ থাকে এবং তা পরিবর্তিত হয় না
- DOR (এখানে এটি ড্রাফট) থেকে কাজে ইউজার স্টোরিগুলো বেশ সমানভাবে যায় — এটি ভালো।
- Burn Down-এর মতোই, আমরা দেখি যে প্রবণতা অনুযায়ী ইউজার স্টোরিগুলো স্প্রিন্টের শেষে সম্পন্ন হবে না
এই ৩টি পর্যবেক্ষণ একসাথে নিম্নলিখিত সিদ্ধান্তে নিয়ে যায়। এখানে স্পষ্টতই আরও প্রাথমিক পর্যায়ে (স্প্রিন্টের দ্বিতীয়-তৃতীয় দিনের দিকে) Scrum Master-এর "টেস্টিং" স্তরটিতে মনোযোগ দেওয়া উচিত ছিল, যা খুব ছোট এবং বেশ দীর্ঘ সময় ধরে পরিবর্তিত হচ্ছে না(কারণ নিশ্চিত করা)। অনুমান করা যায়, টেস্টিং-এর জন্য প্রস্তুত কাজের পরিমাণ কোনো কারণে টেস্ট করা সম্ভব নয়, কিন্তু তাহলে এর অর্থ হলো টেস্টাররা অলস সময় কাটাচ্ছে, এবং তাই, অন্তত নিকটতম স্ট্যান্ডআপে তাদের আরও মনোযোগ দিয়ে শোনা উচিত।
ব্যবহারের অভিজ্ঞতার কথা বলতে গেলে, আমি উদাহরণস্বরূপ, প্রতিদিন স্ট্যান্ডআপের আগে টিম চ্যাটে সমগ্র টিমকে উল্লেখ করে সব মেট্রিক প্রকাশ করি।
সামগ্রিকভাবে, ভুলে যাওয়া উচিত নয় যে মেট্রিকগুলোকে সঠিকভাবে ব্যাখ্যা করতে হবে। যদি সত্যিই সিস্টেমিক সমস্যা থাকে তা দেখতে পারা এবং আপনার প্রেক্ষাপটে যা এমনকি ইতিবাচক লক্ষণও হতে পারে তাকে সমস্যা হিসেবে না ধরা