কোন প্রোগ্রামিং পদ্ধতিটি আমাদের পক্ষে উপযুক্ত?


11

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

আমরা একটি খুব ছোট দল - দুটি বিকাশকারী, একটি ডিবিএ, একজন ডিজাইনার। আমি যে সংস্থাটির জন্য কাজ করি তার আকারের তুলনায় অপ্রয়োজনীয় পরিমাণে প্রচুর পরিমাণে অর্থ উপার্জন করে এবং এর প্রায় 95% খাঁটি অনলাইন বিক্রয়।

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

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


আপনি আমার একটি পুরানো কর্মক্ষেত্রটি এত নির্ভুলভাবে বর্ণনা করছেন যে এটি অস্বস্তিকর।
জন এন

2
প্রথম বাক্যটি মনে মনে একটি দিলবার্ট স্ট্রিপ নিয়ে আসে। :)
মেটালমাইকস্টার

@ মেটালমিকেস্টার - আমি মনে করি মাউয়ের সবচেয়ে বেশি র‍্যাম রয়েছে। সেই লাইনটি পড়ার বিষয়েও আমার চিন্তাভাবনা ছিল।
jfrankcarr

1
দুর্ভাগ্যক্রমে, আমি এই কয়েকটি ছোট সংস্থার "বৈশিষ্ট্যগুলি" সাথে পরিচিত। আমি মনে করি তারা "চটজলদি" "দ্রুত" এর জন্য ভুল করেছে।
মিস্টার স্মিথ

1
@jfrankcarr আমি এই দুটি বোঝাতে চাইছিলাম: dilbert.com/strips/comic/2007-11-26 এবং dilbert.com/strips/comic/2005-11-16 (ভেবেছিল মাউও জিনিসটিও বিজয়ী। :))
মেটালমাইকেস্টার

উত্তর:


10

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

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

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


1
"যদি ব্যবস্থাপনা সত্যই ক্রয় করে থাকে এবং প্রক্রিয়াটিকে বিকৃত করে না" <- যে কোনও চূড়ান্ত সাফল্যের মূল বিষয়। আমি আশা করি যে বাস্তবতা তৈরি করতে কিছু ম্যাজিক স্পেল ছিল। এটি এমন কিছু দেখতে দুর্গন্ধযুক্ত হয় যা ভাল শুরু হয় ভয়াবহভাবে মোচড় হয়ে যায়।
আনন

আমি মনে করি যে এটি আপনার উত্তরের সাথে ভাল হয়েছে ... joelonsoftware.com/articles/DevelopmentAbstration.html
জো ইন্টারনেট

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

10

আমি বলতে চাই যে আপনার পরিচালনার ঝকঝকে সুযোগ নিন! মনে হচ্ছে তারা আপনার কাজ করছে এবং আপনার কাজের পদ্ধতিগুলি উন্নত করার জন্য আপনাকে কিছু উপার্জন দিচ্ছে।

তাদেরকে বলুন ঠিক আছে আমরা অন্যান্য জিনিসগুলির মধ্যে এটির প্রয়োজনে চট করে যাব: -

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

যদি তারা এটি গ্রহণ না করে তবে তাদের বলুন আপনি চটপটে যেতে পারবেন না।


এগুলি দুর্দান্ত পরামর্শ তবে তাদের যখন সংস্কৃতি পরিবর্তন হয় এবং সংস্কৃতি পরিবর্তন হয় কেবল তখনই ঘটে না যখন অর্থ গড়িয়ে পড়ে এবং সহজ হয়।
ম্যাপেল_শ্যাফ্ট

1
হ্যাঁ তবে মুল্যটি হ'ল ম্যানেজমেন্ট তাদের উদ্বোধন দিয়েছে! তারা চটপটে পদ্ধতিগুলির জন্য জিজ্ঞাসা করেছিল টিমটিকে একটি কার্যকর প্রস্তাব নিয়ে ফিরে আসা উচিত যা চতুর প্রক্রিয়াগুলির উচ্চ কাঠামোগত প্রকৃতির উপর জোর দেয়।
জেমস অ্যান্ডারসন

8

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

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

এই দৃশ্যে আমার পরামর্শ হ'ল এটি কীভাবে সামনের পংক্তিতে রয়েছে সে সম্পর্কে পরিচালনা করা, বেয়ারেট না করা management


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

এবং এগ্রিলের শীর্ষ থেকে শুরু করার একটি উদাহরণের মধ্যে তারা ঠিক কী পদ্ধতিটি ব্যবহার করতে চান তা বেছে নেওয়া জড়িত!
Snorbuckle

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

5

কোনও সফ্টওয়্যার বিকাশ এবং প্রকল্প পরিচালনার পদ্ধতি এমন কোনও প্রতিষ্ঠানে সহায়তা করতে পারে না যেখানে বিক্রয় লোকেরা প্রতিদিনের সময়সূচী নির্ধারণ করে। এমন বিশৃঙ্খলা ও বিক্ষিপ্ত পরিচ্ছন্ন কাজের সপ্তাহের মধ্যে আপনি কীভাবে একটি প্রকল্প পরিচালনা করবেন?

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

সংস্কৃতিতে কি এই পরিবর্তন সম্ভব? হ্যাঁ, তবে আপনার ক্ষেত্রে অবশ্যই না।

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

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

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


2
ম্যাপেল_শ্যাফট ঠিক: রান! এখন!
ল্যান্ডেই

হ্যাঁ, আমি আশঙ্কা করছি সে সঠিক হতে পারে :)
মিকি হোগার্থ

1

তাকান extremeprogramming.org - এক্সপি সহজে বোঝা দিক আছে যা আপনি বাছাই এবং লা কার্ট নির্বাচন করতে পারবেন সঙ্গে তত্পর একটি ফর্ম হয়; শুরু করার জন্য খুব ভাল জায়গা

কোনও ইন্টিরিশন চলাকালীন গ্রাহক তাদের মন পরিবর্তন না করার প্রতিশ্রুতি আপনার পরিবেশের জন্য এটির আওয়াজ থেকে ভাল শুরু করার জায়গা হবে ;-)


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

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

@ মিশেল: কিছু পরিবেশে আপনাকে ব্যাঙকে আস্তে আস্তে সিদ্ধ করতে হবে ;-)
স্টিভেন এ লো

@ স্টিভেনএ.লাউয়ে: এটি সত্য - তবে ক্রেতা অকাল টয়লারিং সম্পর্কে সতর্ক থাকুন। এইখানেই "স্ক্রাম-বিট" এর মতো শব্দগুলি এসেছে যেমন "হ্যাঁ, আমরা স্ক্রাম করছি, কিন্তু আমরা [এখানে অনুশীলনগুলি সন্নিবেশ করাই না" "যা আপনি যদি না জানেন তবে গুরুতর সমস্যা দেখা দেয়) আবার করছি
মাইকেল 19

1

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

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

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

তবুও, চতুর যোগ্যতা হ'ল এটি প্রবাহিত প্রক্রিয়াগুলিকে উত্সাহ দেয় এবং এক্সিকিউটেবল কোডে মনোনিবেশ করে - যা অনিবার্যভাবে আপনার চূড়ান্ত বিতরণযোগ্য।

এখন, আপনার প্রশ্নের আরও সরাসরি উত্তর দিতে:

আপনার পরিবেশ সম্পর্কে আপনার ওভারভিউ দেওয়া, আমি আপনাকে প্রথমে একটি চতুর বাস্তবায়ন (যেমন স্ক্রাম, এক্সপি, ইত্যাদি) নির্বাচন করার পরামর্শ দিই। তারপরে আপনার দলটি কীভাবে কাজ করবে তার একটি স্পষ্ট প্রক্রিয়া বর্ণিত করে আপনার পরিবেশের স্যুট করতে পন্থাটি কাস্টমাইজ করুন, যেমন:

  • ব্যবহারকারীর কাছ থেকে অনুরোধ গ্রহণ করুন;

  • ব্যবহারকারীর অনুরোধকে অগ্রাধিকার দিন;

  • বিদ্যমান সিস্টেমে বর্ধনের প্রভাব (সম্ভবত আপনার দৈনিক / সাপ্তাহিক স্ট্যান্ড-আপ মিটিং চলাকালীন);

  • প্রতিটি বর্ধনের বিকাশের সময়টি অনুমান করুন - এবং এগুলি বিভিন্ন অনুরোধকারী ব্যবহারকারীদের সাথে যোগাযোগ করুন;

  • বিদ্যমান সিস্টেমে প্রকৃত বর্ধন (গুলি) কোডিং করুন)

  • ব্যবহারকারীর পরীক্ষা নিরীক্ষণ করুন - এবং ব্যবহারকারীদের কাছ থেকে প্রতিশ্রুতি পান (যেমন ইমেলের মাধ্যমে) যে অনুরোধকৃত পরিবর্তনগুলি সফলভাবে প্রয়োগ করা হয়েছে।

এটি কিছু কাঠামো সরবরাহ করতে পারে (এবং অর্ডার), তবুও একটি চতুর পদ্ধতির কিছুটা দৃষ্টিভঙ্গি বজায় রাখে।

উপরের কথাটি বলে মনে রাখবেন, প্রাচীন বান্ধব ব্যক্তির বক্তব্যটি "বানর হিসাবে চটপটি" কোনও কারণ ছাড়াই তৈরি করা হয়নি!


0

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

আপনি যদি আপনার বিক্রয় লোকদের পিছনে ফিরে যান এবং বাস্তবসম্মত সময়সীমার দাবি করেন তবে আপনাকে সংগঠিত পরিকল্পনার মাধ্যমে এটি সমর্থন করতে হবে।

এছাড়াও একটি পৃথক নোটে যদি তারা প্রযুক্তিগত পরামর্শ ছাড়াই অনুমান নিয়ে আপনার কাছে আসে তবে কেবল তাদের বিন্দু ফাঁকা প্রত্যাখ্যান করুন।


1
আমি সম্মত হই যে, Agile তাদের দুর্দশার সম্ভাব্য সমাধান, তবে, ক) এটি অবশ্যই বোঝার দরকার, দৃ commitment় প্রতিশ্রুতি এবং পরিচালনার কাছ থেকে সমর্থন, খ) চাপ দেওয়া এবং অস্বীকার করা কেবল বিরূপ প্রতিক্রিয়া সৃষ্টি করে যা সমাধানের সম্ভাবনা কমিয়ে দেয় (এবং ঘটনাক্রমে এটিকে আরও বাড়িয়ে তুলতে পারে) সম্ভাবনা না পেয়ে গুলি চালালেন :-()।
পিটার Török

0

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

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


0

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

আপনি যদি একটি চটচটে "খাঁটি" ফর্মটি নিয়ে যান তবে আপনার দলের পক্ষে সমর্থন ভূমিকাটিও পালন করা শক্ত হবে tough আসুন এটির মুখোমুখি হোন, আপনার মনিব "আপনার ব্যাকলগ আইটেমটি তৈরি করতে দিন, আমি স্প্রিন্ট শেষ হওয়ার সপ্তাহে) পেয়ে যাব" এই বলে হেল্প-ডেস্কের অনুরোধগুলির প্রতিক্রিয়া জানিয়ে আপনার দলের সদস্যদের গ্রহণ করতে অসুবিধা হতে পারে।

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

শুভকামনা করছি.


0

বিপরীতে, আমার কাছে মনে হয় এগিলি পদ্ধতি হ'ল সময়সীমা, অবাস্তব প্রত্যাশাগুলি এবং দুর্বল পরিকল্পনাযুক্ত প্রকল্পগুলি মোকাবেলার জন্য আপনার ঠিক যেমন প্রয়োজন need

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

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

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

আমি নিম্নলিখিতটি পড়ার জন্য খুব কম সময়ে সুপারিশ করব:

এবং অতিরিক্ত creditণের জন্য (কারণ আমি মনে করি যে এটি উল্লেখ করা অন্যান্য বইয়ের জন্য এটি একটি দুর্দান্ত সহচর):

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.