দীর্ঘমেয়াদী পরিকল্পনা ও চটজলদি?


16

আমার দলটি সম্প্রতি আমাদের কাজের জন্য প্রায় এক বছরের পরিকল্পনা প্রণয়নের প্রক্রিয়াটি পেরিয়েছিল। আমরা পরিকল্পনাটি তিনটি পর্যায়ে আলাদা করেছিলাম। প্রতিটি ধাপে কয়েকটা লঞ্চ অন্তর্ভুক্ত থাকবে।

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


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

হিহেহে ... এটি কি মন্তব্য করা উচিত নয় (এখানে মজা করছে)? ;-) না, মজা করছে না, এটি বিপণনের পরিকল্পনার মতো মনে হতে পারে, তবে তা নয়। আমি সহজভাবে আমার জ্ঞানটি একটি ওপির সাথে ভাগ করে নিতে চেয়েছিলাম যিনি একটি সহজ প্রশ্নবিদ্ধ জিজ্ঞাসা করেছিলেন এবং আমি সহায়তা করেছি বলে আশা করি তাকে সহায়তা করার জন্য তাকে প্রচুর তথ্য সরবরাহ করতে চাই। আমি ব্যক্তিগতভাবে স্ক্র্যামকে প্রাধান্য দিই, তবে আমি জানি যে অন্যান্য উপায় আছে যা ঠিক কাজ করতে পারে, এটি সবগুলি ওপির দৃশ্যের উপর নির্ভর করে। যাইহোক আপনার লবণের শস্যের জন্য ধন্যবাদ! =)
মারকুইলারের

1
সত্যি কথা বলুন, প্রজেক্ট এক্সটি 3 সপ্তাহ সময় নেবে এমন কথা বলার পরিবর্তে, আপনি বলছেন যে 2% সম্ভাবনা আছে এটি 2 সপ্তাহ লাগবে, 60% চান্সটি 3 সপ্তাহ লাগবে, 10% সুযোগ এটি গ্রহণ করবে 4 সপ্তাহ, 10% সম্ভাবনা যে এটি 5 সপ্তাহ সময় নেবে, 10% সম্ভাবনা যে এটি 6 সপ্তাহ লাগবে, এবং 8% সম্ভাবনা বেশি সময় লাগবে। একটি এন.ইউইকিপিডিয়া.আর / উইকি / লং_টাইল দিয়ে বিতরণ ব্যবহার করে আপনি সৎ হচ্ছেন। এখন বড় প্রকল্পটি 10 ​​এলোমেলো ভেরিয়েবলের যোগফল হিসাবে সমাপ্ত করার জন্য আনুমানিক সময়টিকে চিকিত্সা করুন। শেষে ভেরিয়েন্সটি খুব বেশি তবে আপনি সৎ হচ্ছেন। একটি দীর্ঘ টেল ব্যবহার কী!
কাজ

উত্তর:


11

যেখানে প্রকল্পের যেতে হয় একটি দৃষ্টি রয়ে একটি হল ভাল জিনিস টি এম

এটি ঠিক যে ঘটবে তা বিশ্বাস করে।

"যুদ্ধের জন্য প্রস্তুতি নেওয়ার সময় আমি সর্বদা খুঁজে পেয়েছি যে পরিকল্পনাগুলি অকেজো, তবে পরিকল্পনা অপরিহার্য।"

- ডুইট ডি আইজেনহওয়ার

চতুর পদ্ধতিগুলি যে পদ্ধতির গ্রহণ করে তা হ'ল জিনিসগুলি হজমযোগ্য টুকরো টুকরো টুকরো করে ফেলা এবং প্রতিটি টুকরো হজম হওয়ার পরে দৃষ্টি পুনরায় সমন্বয় করা।

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


কোনও গ্রাহক এই উত্তর পছন্দ করবেন না।
eddy147

3
অন্য গ্রাহক পেতে! ;-)
পিটার কে।

10

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

আপনি সম্ভবত মনে করেন যে আমি কেবল কৌতুকময় হয়ে উঠছি। সর্বোপরি আপনি কেবল অনির্দিষ্ট নির্দিষ্ট বৈশিষ্ট্যগুলির জন্য অস্পষ্ট সময়গুলি জানিয়েছিলেন যা প্রত্যেকেই জানেন যে অনুমানের চেয়ে অনেক ধীর বা দ্রুত ঘটতে পারে, তাই না? দুঃখিত, এর বেশিরভাগটি সত্য হতে পারে, তবে লোকেরা এই সংখ্যাগুলি শুনতে ঝোঁক tend তারা তারিখগুলি শুনেছে, এবং একবার কথা বলা তারিখটি আপনি যা বলেছিলেন তার চেয়ে আরও দৃ being় বলে শোনা যায়। তদুপরি যদি যোগাযোগের একটি শৃঙ্খলা থাকে তবে এটি আরও দৃ still় হয়ে উঠবে। আপনি একবার যা বলেছিলেন তার উপর ভিত্তি করে বাহ্যিক গ্রাহকদের যখন কিছু বিক্রির মাধ্যমে প্রতিশ্রুতি দেওয়া হয়েছিল, আপনি হঠাৎ করে দেখতে পাবেন যে এই সংখ্যাগুলিতে যে পরিমাণ হওয়া উচিত তার চেয়ে অনেক কম নমনীয়তা রয়েছে। এবং আমি গ্যারান্টি দিচ্ছি যে আপনি যে জিনিসগুলি সময় নেবেন তা আপনি অবমূল্যায়ন করেছেন।

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

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

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


আপনি এই ভুলটি প্রমাণ করার একমাত্র উপায় হ'ল যদি প্রকল্প এবং এর প্রাক্কলনগুলি প্রায়শই প্রয়োজনীয়তার আশেপাশে ঘুরে বেড়ায় আপনার বাস্তবায়নের ব্যাপক অভিজ্ঞতা রয়েছে।
ফিলিপ দুপানভিভিć

@ ফিলিপ-দুপানোভিচ: কী ভুল প্রমাণ করুন?
btilly

5

যতক্ষণ আপনি এটিকে কার্য-অগ্রগতি হিসাবে বিবেচনা করেন এবং পাথর লিখিত কিছু না হিসাবে এটি পরিকল্পনা করা ঠিক আছে।

এখানে কীটি হ'ল নিয়মিত প্রকাশ করা (কমপক্ষে মাসিক) আপনার ব্যবহারকারীদের কাছ থেকে সত্য প্রতিক্রিয়া সংগ্রহ করা এবং সেই প্রতিক্রিয়ার ভিত্তিতে আপনার পরিকল্পনা আপডেট করা

এর অর্থ হ'ল যখন প্রকল্পের ক্ষেত্র পরিবর্তন হবে তখন আপনার পরিকল্পনা পরিবর্তন হবে। এটি একটি ভাল জিনিস , কারণ এর অর্থ আপনার ব্যবহারকারীরা কী চান সে সম্পর্কে আরও শিখেছে।


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

2

ধরে নেওয়া project-managementএবং agileআপনি স্ক্র্যাম বোঝাচ্ছেন, এটি যাওয়ার সঠিক উপায় হবে না।

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

Sprintআর এক মাসের বেশি হতে পারে না, যেখানে Teamএটির Sprint Backlog Itemsস্থিতিতে আনার প্রতিশ্রুতি দেয় Done

Doneএখানে একটি গুরুত্বপূর্ণ শব্দ, এবং প্রতিটিগুলির Scrum Teamঅবশ্যই একটির সংজ্ঞা করা উচিত, এটি হ'ল যেখানে কাজ করার বাকি নেই। যখন একটি Sprint Backlog Itemহয় সম্পন্ন , এর মানে হল বিশ্লেষণ, স্থাপত্য ও প্রযুক্তিগত নথিপত্রে লিখিত যে হয়, এবং বৈশিষ্ট্য পুঙ্খানুপুঙ্খভাবে পরীক্ষা করা হয়েছে যে (ইউনিট পরীক্ষা, সংহত পরীক্ষা কার্মিক পরীক্ষার ...)।

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

এটি Sprint Planning Meetingটিম পরবর্তীটির জন্য কী বিকাশ ঘটবে সে বিষয়ে প্রতিশ্রুতি দেবে যে Sprintসময়টি তৈরি করে Sprint BacklogSprint Backlogএকটি উপসেট উপর ভিত্তি করে গঠিত Product Backlog Itemsযে Teamকরে স্প্রিন্ট শেষে কাজ করতে হবে। উদাহরণস্বরূপ 50 টি আইটেমের একটি পণ্য ব্যাকলগ বিবেচনা করে এবং 50 টি আইটেমের জন্য এক বছর করা প্রয়োজন, তারপরে টিমটি পণ্য ব্যাকলগ থেকে 5 টি আইটেম বলতে বেছে নিতে এবং এই 5 টি আইটেম সহ স্প্রিন্ট ব্যাকলগ তৈরি করতে চায়। এই একই 5 টি আইটেমগুলি যখন প্রয়োজন হয় তখন অন্য একাধিক আইটেমগুলিতে প্রসারিত / বিস্ফোরিত হতে পারে, সুতরাং টিমটি সম্ভবত পুনর্বিবেচনার পরে তাদের মন পরিবর্তন করবে এবং পণ্য ব্যাকলগ থেকে পূর্বে নির্বাচিত 5 টি আইটেমের মধ্যে কেবল 4 টি আইটেম করার প্রতিশ্রুতিবদ্ধ।

একবার স্প্রিন্ট পরিকল্পনা সভা শেষ হয়ে গেলে, এটি পুরো মাসের স্প্রিন্টের জন্য 8 ঘন্টার বেশি সময় ধরে চলতে পারে না, যার মধ্যে টিম কেবলমাত্র নির্বাচিত আইটেমগুলির জন্য কাজ করার জন্য প্রতিশ্রুতি দেয় না, তবে কীভাবে এটি কাজটি সম্পন্ন করবে তা নিয়ে পরিকল্পনা করে যাতে দলের প্রত্যেককে তার / তার কী করতে হবে তা সঠিকভাবে জানে, Sprintশুরু হবে। প্রকল্পের জন্য দলের পক্ষে ক্রস-কার্যকরী হওয়া গুরুত্বপূর্ণ important

এটি বলেছিল যে, প্রতিটি স্প্রিন্টের শেষে, যা বর্তমান পরিস্থিতিতে এক মাস স্থায়ী হয়, Teamপ্রতিশ্রুতিবদ্ধ সমস্ত আইটেমগুলি পণ্য ব্যাকলগ থেকে নির্বাচিত আইটেমগুলিকে লক্ষ্য করে সম্পূর্ণরূপে কার্যকরী বৈশিষ্ট্য (গুলি) এর একটি বিতরণযোগ্য টুকরা হবে। এটি বিতরণযোগ্য হতে হবে, তবে এটি যদি বাধ্যতামূলক হয় না যে যদি এটি মেনে চলা মেনে না বুঝে তা সরবরাহ করা হয় Product Owner

এটি Sprint Review Meetingযেখানে Product Ownerতলব করার প্রয়োজন Teamহয়েছিল সেই সময়েই স্প্রিন্ট চলাকালীন যা করা হয়েছিল তা প্রদর্শন করে এবং যেখানে এটি করা হয়নি কেন তা প্রযোজ্য হলে, এটি যে সমস্ত প্রতিশ্রুতিবদ্ধ হয়েছিল তা বলা দরকার। পূর্বাবস্থায় ফিরে আসা কাজটি আবার রেখে দেওয়া হয় Product Backlogএবং পরবর্তীটির জন্য উপলব্ধ Sprint। নিশ্চিত হয়ে নিন যে এই পূর্বাবস্থায় ফিরে আসা আইটেমগুলি পরবর্তী স্প্রিন্টে অন্তর্ভুক্ত করা হবে যদি না অন্যথায় পণ্য মালিক দ্বারা না বলা হয়, যদি উদ্দেশ্যটি পরিবর্তিত হয়। তবে সর্বাধিক গুরুত্বপূর্ণ, একটি স্প্রিন্ট চলাকালীন কোনও পদ্ধতির উদ্দেশ্য পরিবর্তিত হলেও একেবারে প্রয়োজনীয় না হলে এটিকে বাধা দেবেন না। স্প্রিন্টটিতে বাধা দেওয়ার অধিকার কেবলমাত্র পণ্যের মালিকেরই রয়েছে।

একবার Sprint Review Meetingশেষ হয়ে গেলে , যা মাসিক স্প্রিন্টের জন্য 4 ঘণ্টার বেশি সময় ধরে চলবে না (যদি আমি সঠিকভাবে মনে করি), এটি পাওয়ার সময় Sprint Retrospective MeetingSprint Retrospectiveপ্রয়োজন হয় Teamতাই ঘটতে আলোচনা করতে পারে যে, স্ক্রাম মাস্টার এবং পণ্য মালিক (ঐচ্ছিক) কি ভুল হয়েছে, কিভাবে স্ক্রাম টিম তার কর্মক্ষমতা, ইত্যাদি এবং সমন্বয় তদনুসারে আনা উন্নতি হতে পারে উপস্থিতিতে।

যখন সময়টির বাক্সটি Sprint Retrospectiveশেষ হয়ে Sprint Planning Meetingযাবে তখন নতুনটি পরবর্তীটির পরিকল্পনা করার জন্য Sprintএবং নতুনটি তৈরি করার জন্য ঘটবে Sprint Backlog

মনে রাখবেন, এটি 15 মিনিটের স্থায়ী সভাটি Teamবজায় রাখতে দায়বদ্ধ Daily Scrumযেখানে প্রতিটি টিম সদস্য তিনটি প্রশ্নের উত্তর দেয় (সেই নির্দিষ্ট ক্রমে নয়):

  1. গত ডেইলি স্ক্রামের পরে আপনি কী করেছেন?
  2. পরবর্তী ডেইলি স্ক্রাম পর্যন্ত আপনি কী করার পরিকল্পনা করছেন?
  3. গত দৈনিক স্ক্রাম থেকে আপনি যে সমস্যা বা প্রতিবন্ধকতাগুলির মুখোমুখি হয়েছিলেন?

Scrum Masterনয় বাধ্য সেখানে হতে কিন্তু যে আশ্বাস টিম দৈনিক স্ক্রাম এ পূরণ করে এবং যে সদস্যদের তিনটি প্রশ্ন সঠিকভাবে উত্তর প্রয়োজন।

স্ক্রাম মাস্টার অন্য স্ক্রাম টিম সদস্যদের (স্ক্রাম মাস্টার, পণ্য মালিক এবং দল) কর্তৃক স্ক্রাম বিধি সম্মানের জন্য দায়বদ্ধ।

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

আপনার যদি স্ক্রাম এবং চতুর সফটওয়্যার ডেভলপমেন্ট সম্পর্কে আরও বিস্তারিত তথ্যের প্রয়োজন হয় তবে দয়া করে স্ক্রাম.আরোগ এবং তাদের স্ক্র্যাম গাইড দেখুন

ঠিক আছে, এটি বেশ উত্তর! আমি আশা করি এটি আপনার প্রকল্প পরিচালনার মাধ্যমে কমপক্ষে আপনাকে সহায়তা করবে।

সম্পাদনা # 1

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


1
+1, তবে 6th ষ্ঠ অনুচ্ছেদের পরে আপনার থামানো উচিত ছিল। :)
পি শেভ করা হয়েছে

1
ব্যাকটিক্সে অনেকগুলি নন-কোড শব্দ।
রেন হেনরিচস

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

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

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

সংক্ষেপে, আমি মনে করি আপনি যত বেশি পরিদর্শন করবেন এবং মানিয়ে নেবেন আপনি তত বেশি চটুল হয়ে উঠবেন।


0

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

তোমার উচিত:

  1. একটি মাস্টার প্ল্যান করুন (পছন্দসই সময়সীমা সংযুক্ত না করে), যা আপনার যাওয়ার সাথে সাথে বিকশিত হবে।

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

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

আমি মনে করি ব্যাকলগ এবং বড় প্রকল্প পরিকল্পনা পৃথক কাঠামো হলে এটি সবচেয়ে ভাল। বড় প্রকল্পের মালিক প্রাসঙ্গিকতা বজায় রাখার জন্য মাস্টার প্ল্যানকে হায়ারারিকিকাল আউটলাইন ফর্ম্যাটে রাখেন এবং তারপরে ফিচার / টাস্কগুলি থেকে ব্যাকলগটি খাওয়ানোর জন্য এটি থেকে টানা যেতে পারে, যা পরবর্তীতে পরবর্তী স্প্রিন্টকে খাওয়ায়।

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

এই পদ্ধতিটি চৌকস শক্তি এবং আপনার প্রকল্পের সমস্ত উপাদানগুলি সারিবদ্ধ করার শক্তি বজায় রাখে বড় চিত্র পরিকল্পনার মাধ্যমে একটি নির্দিষ্ট সময়ে আপনি পারেন সেরা।

জিম


-3

আমি এখানে আমার অ্যান্টি-এজিলেল রেন্টের সংক্ষিপ্ত রূপটি যুক্ত করব।

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

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

পাঠটি হ'ল, আপনি যে ছোট ছোট জিনিস ফেলে দিতে ইচ্ছুক তার জন্য চৌকস ব্যবহার করুন। এটি কখনও কখনও দুর্দান্ত হতে পারে। তবে এটি ওয়ান ট্রু সফটওয়্যার ডেভলপমেন্ট ওয়ে নয়। ফাউন্ডেশনাল কোডটি লেখার সময় যা উচ্চ ঝুঁকিপূর্ণ বা দীর্ঘকালীন জীবনকাল থাকবে, বড় নকশাটি করুন।


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

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

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

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

1
ঠিক আছে, আমি অনুমান করি আপনি "আইজিল পছন্দ করি" ব্যাজটি জিতেছেন। যদিও আপনার শেষ মন্তব্যটি দেওয়া হলেও আমি এখনও বিভ্রান্ত হয়েছি যে আপনি কেন স্ক্রমের ক্রমাগত উল্লেখ করে এটির পক্ষে চেষ্টা করছেন। আমিও স্ক্র্যাম পছন্দ করি; আমি এটির বিষয়ে পছন্দ করি তার মধ্যে একটি হ'ল চতুর মান সহ কিছু সমস্যা এড়ানো যায়।
স্মিথকো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.