সফ্টওয়্যার সময়সূচী সংজ্ঞায়িত করা এত কঠিন কেন?


39

দেখে মনে হয়, আমার অভিজ্ঞতায়, আমাদের সঠিক ইঞ্জিনিয়ারিং পাওয়া কাজগুলি সঠিকভাবে নির্ধারণ করা এবং শেষ হওয়া কাজগুলি নির্ধারণ করা দাঁত টানার মতো। ২-৩ সপ্তাহ বা 3-6 মাসের জন্য কেবল সোয়াট প্রাক্কলন দেওয়ার চেয়ে ... সফ্টওয়্যার শিডিয়ুলগুলি সংজ্ঞায়িত করার এত সহজ উপায় কী যে সেগুলি সংজ্ঞায়িত করতে এত বেদনাদায়ক নয়? উদাহরণস্বরূপ, গ্রাহক এ 02/01/2011 এর মধ্যে একটি বৈশিষ্ট্য চান। পথের পাশাপাশি অন্যান্য বাগ ফিক্সগুলির প্রয়োজন হতে পারে এবং অতিরিক্ত ইঞ্জিনিয়ারিং সময় নিতে পারে তা জেনে আপনি এই বৈশিষ্ট্যটি বাস্তবায়নের জন্য কীভাবে সময় নির্ধারণ করবেন?


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

2
@ ড্যান ম্যাকগ্রা: আপনি প্রমাণযুক্ত লিঙ্কটি পোস্ট করবেন না কেন? অপেক্ষা করুন, আপনি কি ফার্মাট এবং তার শেষ উপপাদ্য প্রমাণের মতো হওয়ার চেষ্টা করছেন, যা কখনও পাওয়া যায় নি: |
শামীম হাফিজ

9
একই কারণে যে যখন ন্যাভিগেটর গন্তব্য সম্পর্কে নিশ্চিত না হন, ট্রিপ পরিকল্পনা করা কঠিন, ড্রাইভার রাস্তাগুলি জানেন না এবং যাত্রীরা সকলেই আইসক্রিম চান want
স্টিভেন এ। লো

1
আপনার আগ্রহী এমন কিছু হ'ল এভিডেন্স বেসড শিডিউলিং।
ক্রেগ

2
তাদের সংজ্ঞা দেওয়া শক্ত নয়। রাখা অসম্ভব।
টনি হপকিনসন

উত্তর:


57

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

চিত্রশিল্পী, গালিচা ইনস্টলকারী, ল্যান্ডস্কেপ ইত্যাদির নিয়মিত অভিজ্ঞতা রয়েছে এগুলি। তবে এটি অনেকগুলি (বা বেশিরভাগ) সফ্টওয়্যার প্রকল্পগুলির জন্য ভাল ফিট নয়।

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


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

2
@ জেফ এটি একটি খুব ভাল তুলনা। আমাকে
ডেভ ম্যাককেলল্যান্ড

1
@ জেফ ... তবে আপনি জানেন যে এটি হুড়োহুড়ি সময় এবং এটি আপনার অনুমানের সাথে যুক্ত করে ... আপনি এখনও
অবসর

2
@ পেমদাস: আসলে, আপনার অনুমানের সমস্ত তথ্য যুক্ত করার জন্য আপনি যথেষ্ট পরিমাণে জানতে পারবেন না । আপনি জানতে পারবেন না দমকল বিভাগ কোনও কলটিতে সাড়া দিচ্ছে কিনা। আপনি জানতে পারবেন না বৈদ্যুতিক তারটি পড়েছে এবং রাস্তাটি ব্লক করছে কিনা। ভবিষ্যতের বিষয়ে আপনি জানতে পারবেন না এমন অসংখ্য জিনিস রয়েছে। এটা ভবিষ্যত। এটি অনুমান করা শক্ত - সংজ্ঞা অনুসারে।
এস .লট

1
@ পেমদাস - এই কাজটি যত জটিল, বিশৃঙ্খলার দেবতারা হস্তক্ষেপ করবেন। অবশ্যই এটি সম্ভবত আপনার মন্তব্যের কয়েকটি চেয়ে বেশি মাপসই - পরিচিত কাজগুলির সাথে, আপনি জানেন যে এইসব বেঁচে থাকা দেবতারা কীভাবে আগ্রহী হন।
স্টিভ 314

35

আমার ব্যক্তিগত অভিজ্ঞতা অনুসারে, এটি পেমদাস যা বলেছিল তার ঠিক বিপরীত : অনুশীলনের সাথে, আমি কেবল বুঝতে পেরেছি যে কোনও কার্যে কত সময় প্রয়োজন হবে তা অনুমান করা সম্পূর্ণ অসম্ভব। সফ্টওয়্যার বিকাশে আমার ক্যারিয়ারের শুরুতে, আমি প্রায়শই "45 দিন", "পাঁচ সপ্তাহ" ইত্যাদির মতো অনুমান দিয়েছিলাম, তারপরে সময় শেষ করার জন্য খুব চেষ্টা করেছি tried কয়েক বছর পরে, আমি "প্রায় এক মাস", "পাঁচ থেকে সাত সপ্তাহ" ইত্যাদির মতো কম সুনির্দিষ্ট অনুমান দিতে শুরু করি আসলে, আমি চেষ্টা করি কোনও অনুমান না দেওয়ার জন্য, বা গ্রাহককে তার নিজস্ব অনুমান দিতে বলার চেষ্টা করি বা সময়সীমা বা আমি যতটা সম্ভব রুক্ষ হিসাবে একটি অনুমান দিতে।

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

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

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

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

  4. আপনি কেবলমাত্র সংশ্লিষ্ট অংশটি শেষ করার পরে গ্রাহকরা তাদের প্রয়োজনীয়তা পরিবর্তন করতে পছন্দ করেন এবং তারা বুঝতে পারেন না কেন আপনি আরও দুটি সপ্তাহ এবং 2000 ডলারকে একটি ক্ষুদ্র পরিবর্তন করার জন্য অনুরোধ করছেন কারণ তারা দেখতে পান না যে এই ক্ষুদ্র পরিবর্তনের প্রয়োজন আছে অন্যান্য জিনিস পরিবর্তন করুন, যার জন্য অন্যকে পরিবর্তন করা প্রয়োজন ইত্যাদি ইত্যাদি

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

  6. আপনার অনুমান অন্যান্য লোকের উপর নির্ভর করে যখন জিনিসগুলি সত্যই খারাপ হয়ে যায় । উদাহরণস্বরূপ, এক 2 মাসের প্রকল্পে আমাকে নিজের কাজ শেষ করার জন্য ডিজাইনারের কাজটি করতে অপেক্ষা করতে হয়েছিল। এই ডিজাইনারটি অব্যবহারযোগ্য শঙ্কার একটি টুকরো সরবরাহ করার আগে 3 মাস সময় নিয়েছিল। অবশ্যই প্রকল্পটি দেরিতে ছিল।

  7. আপনার অনুমানও আপনার গ্রাহকের উপর নির্ভর করে । আমার গ্রাহকরা ছিল যারা তাদের মেলের উত্তর দেওয়ার আগে কয়েক সপ্তাহ ব্যয় করে। এটি যখন আপনার উত্তরটির জন্য অপেক্ষা করতে হবে (উদাহরণস্বরূপ যদি আপনি তাদের প্রয়োজনীয়তা সুনির্দিষ্ট করতে বলছেন) তখন এটি আপনার তফসিলটিকে সত্যই প্রভাবিত করতে পারে।

আপনি কি করতে পারেন?

  1. একটি বৃহত্তর সময়সূচী দিন । আপনি যদি মনে করেন আপনি এই কাজটি দুই সপ্তাহের মধ্যে করতে পারেন তবে বলুন আপনি এক মাসে এটি সরবরাহ করবেন।

  2. পরিষ্কার থাকুন । আপনি যদি ডিজাইনারের উপর নির্ভর করেন, অন্য বিকাশকারী ইত্যাদি it "আমি তিন মাসের মধ্যে পণ্যটি সরবরাহ করব" বলার পরিবর্তে বলুন "ডিজাইনার আমাকে পিএসডি ফাইল দেওয়ার পরে আমি দুই মাসের মধ্যে পণ্যটি সরবরাহ করব।"

  3. ব্যাখ্যা করুন যে প্রয়োজনীয়তাগুলি প্রতিদিন পরিবর্তিত হলে, প্রকল্পটি খুব কম সময়েই সরবরাহ করা হবে।

  4. আপনার সময়সূচী কাটা । একটি বৃহত প্রকল্পের অংশগুলি যথাসময়ে বিতরণ করা সহজ।

  5. আপনি যখন এমন কোনও পণ্য ব্যবহার করেন যখন আপনি ভাল জানেন না বা বিশেষত যখন আপনি অন্য কারও উত্স কোড নিয়ে কাজ করবেন তখন কখনই অনুমান করবেন না: উত্স কোডটি কতটা কৃপণ হতে পারে এবং আপনি কতটা সময় ব্যয় করবেন তা আপনি কখনই অনুমান করতে পারবেন না এটি ডেইলি ডাব্লুটিএফ-তে বোঝা এবং অনুলিপি করা।


1
@ জেফ ও: আমি জানি না। আমার জন্য, একটি ডেলিভারি তারিখ মানে একটি সময়সীমা। এবং একটি সময়সীমা মানে প্রকল্পটি এর পরে বিতরণ করা যাবে না। এছাড়াও, মনস্তাত্ত্বিকভাবে, গ্রাহকরা কম রাগ করতে পারেন যখন আপনি বলেছিলেন যে আপনি এক মাসে কিছু সরবরাহ করবেন এবং আপনি চার দিন পরে বিতরণ করবেন, than ই জানুয়ারী, ২০১১-এ, আপনি বলেছেন যে আপনি এটি 8 ই ফেব্রুয়ারী, 2011 এ বিতরণ করবেন এবং আপনি 12 ফেব্রুয়ারী এটি সরবরাহ করুন।
আর্সেনী মোরজেঙ্কো

10
@ পেমাস: এটি অলসতার প্রশ্ন নয়। আপনি কেবল হতাশ হতে পারেন, বা মনোনিবেশ করতে অস্থায়ী অসুবিধাগুলি বা ব্যক্তিগত / পারিবারিক সমস্যায় পড়তে পারেন, বা অন্য গ্রাহকরা বা যা কিছু দ্বারা চাপে পড়তে পারেন।
আর্সেনী মোরজেঙ্কো

2
মাইনমার পয়েন্টগুলিতে যুক্ত হওয়া, আপনি যদি একটি দলে কাজ করেন তবে এমন পরিস্থিতি রয়েছে যখন কাউকে ছুটিতে থাকতে হয়, আনন্দ বা অসুস্থতার জন্য।
শামীম হাফিজ

5
@ পেমডাস প্রতিটি প্রোগ্রামারের সাথে এগুলি কিছুটা হলেও ঘটে। এটি ঠিক যে এটি নিজেকে এমনভাবে প্রকাশ করে যা সর্বদা সুস্পষ্ট নয়। এক সপ্তাহে প্রদত্ত সমস্যার জন্য কাজ করতে 3 ঘন্টা সময় লাগতে পারে কারণ আপনি অতি-তীক্ষ্ণ এবং "জোনে", যখন পরের সপ্তাহে 3 দিন সময় লাগে।
ম্যাথু ফ্রেডরিক

7
@ 0 এ 0 ডি যদি আপনি প্রকল্পটি সবচেয়ে দানাদার সাব টাস্কগুলিতে ভাঙেন এবং সেগুলির প্রতিটি কীভাবে ঠিকঠাক কাজ করে তা নির্ণয় করেন, তবে সেই সমস্ত টুকরোগুলির সংশ্লেষগুলি কীভাবে আপনার বোঝা যায় তা নিশ্চিত করার জন্য সমস্ত কিছু দিয়ে কাজ করুন এবং কোনও নতুন বা সতেজ- আপনার মনের প্রযুক্তিগুলি এতে জড়িত থাকে এবং প্রতিটি অজানা পথ থেকে সরিয়ে দেয়, তবে আপনি একেবারে চমকপ্রদ নির্ভুল অনুমান দিতে পারেন। অবশ্যই, আপনি কেবল কোডিংয়ের অংশটি রেখে প্রায় সমস্ত প্রোগ্রামিংও করেছেন, এবং এই অনুমানের মধ্যে কতক্ষণ সময় লাগবে তা আপনি আগেই জানতে পারবেন না। ;)
ম্যাথু ফ্রেডরিক

15

একটি খুব অনুরূপ প্রশ্ন "এই ক্রসওয়ার্ড ধাঁধাটি সমাধান করতে কতক্ষণ সময় লাগবে?"

আপনি এর উত্তর না দিতে পারছেন যতক্ষণ না আপনি এটির দিকে লক্ষ্য না করে এই পর্যন্ত অসংখ্য জিনিস দেখার জন্য:

  • এটি কোনও পরিচিত ভাষায়? (স্প্যানিশ বনাম ইংরেজি বনাম চীনা)
  • এটি কি এমন এক ধরণের সমাধান যা আমরা আগে সমাধান করেছি? (একটি ম্যাগাজিনে চলছে এমন একটি সিরিজের উদাহরণ)
  • আমরা এমনকি এটি বুঝতে পারার আগে কি সীসাগুলির কোনওটির জন্য অতিরিক্ত জ্ঞানের প্রয়োজন হয়?
  • ধাঁধা জিনিসগুলির কোথাও কি এমন কিছু আছে যা আপনার জ্ঞানের জন্য অতিরিক্ত কাজের প্রয়োজন হবে?

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

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


11

আপনার প্রকৌশলীরা আপনাকে সঠিক অনুমান দিতে না পারার সর্বাধিক সুস্পষ্ট কারণ হ'ল এটি অসম্ভব

অবশ্যই আপনি অনুমান করতে পারেন যে আপনার বাড়ি থেকে কাজ করতে কত সময় লাগবে + -2 মিনিট। আপনি কীভাবে গাড়ি চালাবেন জানেন, আপনি ট্র্যাফিক এবং অন্যান্য কিছু বাহ্যিক কারণগুলি মূল্যায়ন করতে পারেন।

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

সফ্টওয়্যার, এটি আরও খারাপ:

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

এজন্য আপনার গ্রাহককে বলা সম্ভব নয় যে আপনি 02/01/2011 এর জন্য ভাল নির্ভুলতার সাথে কী জাহাজে পাঠাতে পারবেন এবং 03/01/2011 সম্পর্কে ভুলে যাবেন।

সেই সব সমস্যার সুরাহা করার জন্য, আমি সুপারিশ করছি যেন আপনি যেমন প্রাক্কলন কৌশল উন্নত পরিকল্পনা জুজু (দাবিত্যাগ: এই আমার ওয়েবসাইট অন্যতম) এবং পুনরুক্তিকারী উন্নয়ন সঙ্গে বেগ হিসাব।

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

সুতরাং কেউ যদি কোনও বৈশিষ্ট্যের জন্য 02/01/2011 এর ডেলিভারির তারিখের জন্য জিজ্ঞাসা করেন, তবে সেরা বাজিটি "এটিতে কাজ করার সাথে সাথেই আমি আপনাকে জানাতে পারি যে এটি কতক্ষণ সময় নেবে"? আমি নিশ্চিত যে এটি সীসা বেলুনের মতো ভালই চলে যাবে;)
ব্রায়ান

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

@ 0 এ 0 ডি, ইউরোপে 02/01/2011 মানে ২ রা জানুয়ারী। কমপক্ষে 8 ই জানুয়ারী জিজ্ঞাসা করা হলে উত্তরটি আরও সহজ করে তোলে: D

6

সফ্টওয়্যার বিকাশ হ'ল সংজ্ঞা অনুসারে - আবিষ্কার এবং আবিষ্কারের একটি কাজ act এটি সর্বদা অজানা কিছু জড়িত থাকতে হবে।

সফ্টওয়্যারটি বিকাশের সাথে সম্পর্কিত সমস্ত কিছু যখন সফ্টওয়্যারটি সম্পূর্ণ হয় তখনই তা জানা যায়।

ডাউনলোডের জন্য সম্পূর্ণ, প্যাকেজযুক্ত সমাধান প্রস্তুত হওয়ার সময় কেবল কোনও অজানা প্রযুক্তি বা ব্যবসায়ের বৈশিষ্ট্য নেই।

আমরা নতুন সফ্টওয়্যার লেখার কারণটি হ'ল আমাদের একটি নতুন বৈশিষ্ট্য বা নতুন প্রযুক্তি বা উভয়। নতুন অর্থ নতুন - অজানা - প্রত্যাশিত।

যেহেতু সফ্টওয়্যার বিকাশ অবশ্যই অভিনবত্ব জড়িত, বিকাশের প্রচেষ্টা পূর্বাভাস করা যায় না।


3

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


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

আমি একই পণ্যটিতে কাজ করি তবে সমস্যাটি সর্বদা প্রকাশের সাথে পরিবর্তিত হয়। আমি স্বীকার করব যে আমাকে এমন কিছু অনুমান করতে হয়নি যা শেষ করতে 6-8 মাসের বেশি সময় লেগেছিল।
পেমদাস

পেরেন্ডাস, কেবল এটির মজাদার জন্য: C # বা জাভাতে আপনার পণ্যটি পুনরায় লিখতে আর কত সময় লাগবে? গুগল ক্লাউডে চালাবেন? ওপেনজিএলে সরাসরি ডেটা কল্পনা করতে? কোনও Wi-তে কোনও শেষ-ব্যবহারকারী ক্লায়েন্ট চলমান আছে?

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

2

এটি কখনই সহজ নয়। আপনি এটিতে আরও ভাল হওয়ার চেষ্টা করুন।

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

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

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


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

2

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


2

আমি এই বইটি থেকে অনেক কিছু শিখেছি:

সফ্টওয়্যার অনুমান: ব্ল্যাক আর্টকে ক্ষমা করা

সংক্ষেপে আরও ভাল অনুমানের ফলাফল পেতে আমরা এটি করি:

  1. তুচ্ছ কাজগুলি ব্যতীত অন্য এক ব্যক্তির দ্বারা অনুমান করা হয় (আমাদের ক্ষেত্রে দুটি)
  2. আমরা কাজকে আরও ছোট টাস্কে ভাগ করি। আপনার যত বেশি কাজ করার সম্ভাবনা রয়েছে ততই আপনার অনুমানটি ভাল হবে - আমি যদি বু থেকে সঠিকভাবে মনে করি তবে প্রচুর সংখ্যক আইন
  3. আমরা সবচেয়ে খারাপ, সর্বোত্তম এবং সম্ভবত দৃশ্যমান পরিস্থিতি অনুমান করি। কখনও কখনও আমাদের প্রত্যেকে সেই গাছের পরিস্থিতিগুলি সম্পূর্ণ আলাদাভাবে অনুমান করে। তার মানে আমাদের কথা বলতে হবে এবং সাধারণত এটি সক্রিয় হয় যে আমাদের মধ্যে কেউ কাজটি বুঝতে পারে নি। যদি একজন ব্যক্তি কাজটি একা অনুমান করেছিলেন তবে এটি ভুল অনুমান করা হবে।
  4. আমরা উপরের দিক থেকে 3 নম্বর সমীকরণে রেখেছি এবং অনুমান (এক্সেল) কে পেয়েছি

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


1

দ্রষ্টব্য: এটি কেবলমাত্র সেই প্রকল্পগুলিতে প্রযোজ্য যেখানে আপনি স্থির / ফ্ল্যাট হারের বিপরীতে ঘন্টা দ্বারা বিল করেন।

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

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


1

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

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


আমি লেখার ইউনিট পরীক্ষাগুলি অ-বিকাশীয় কার্যকে কল করব না;) এবং আমাদের কর্তারা আমাদের প্রতিদিন 6 ঘন্টা ধরে গণনা করেন। যদি আমি 60 ঘন্টা বলি তবে তারা 10 দিন বলে।
পাইওটর পেরাক

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

1

যখন কাজগুলির জন্য সময় অনুমানের বিষয়টি আসে যা কয়েক ঘন্টা সময় নিতে পারে তবে আমি এই নিয়মগুলি ব্যবহার করার জন্য যথাসাধ্য চেষ্টা করি:

  1. না কি ভবিষ্যদ্বাণী করা যদি আপনি এটি উপর নির্ভর করে ঘটতে যখন অন্য মানুষ তাদের কাজ শেষ হবে চেষ্টা করুন। শুধু নিজের জন্য কথা বলুন।
  2. প্রথমে কার্য বিশ্লেষণ করুন, তারপরে অনুমান করুন। বিশ্লেষণ করে আমি বলতে চাইছি কমপক্ষে লিখে রাখছি (এবং আপনার মাথায় সব কিছু রাখার চেষ্টা করা হচ্ছে না!) তাদের প্রত্যেকের অনুমান সহ সাবটাস্কগুলির একটি তালিকা।
  3. যদি কোনও কাজ যথেষ্ট জটিল হয় তবে এই জাতীয় বিশ্লেষণের জন্য সময়টি অনুমান করুন। অনুমানটি আলাদা প্রক্রিয়া হতে দিন। আপনি এটি নিশ্চিত করতে পারেন যে আপনার বস এটি সম্পর্কে জানেন।
  4. চাপে অনুমান করবেন না। এটি পরিষ্কার করুন যে একটি যুক্তিসঙ্গত অনুমান করতে সময় লাগে এবং কেবলমাত্র এটিকে কিছু বলার মতো "আমি কাজটি বিশ্লেষণ শেষ করার পরে আগামীকাল 11:00 টার মধ্যে একটি তারিখের নাম রাখব"। আমি জানি কিছু গ্রাহক / পরিচালক কঠোর চাপ দিতে পারেন, তবে তারা পাস করবেন না। আপনার ব্যস্ত চেহারা রাখুন এবং আপনার সময় দাবি!
  5. একটু বেশি সময় জিজ্ঞাসা করুন আপনি মনে কারণ আপনার সম্ভবত আপনার প্রাক্কলন একটি কফি বিরতি সময় (এবং Othe distrctions) যোগ করতে ভুলে গেছি আপনার প্রয়োজন হবে।
  6. বড় কাজগুলির জন্য আরও বেশি জিজ্ঞাসা করুন - সম্ভবত একাধিক কফি ব্রেক হবে।
  7. যদি আপনি সত্যিই অনুমান করতে না পারেন (কাজটি খুব কঠিন / অপরিচিত) বা সত্যই অনিশ্চিত হয়ে থাকে - আপনার বিশ্লেষণে সহায়তার জন্য যোগ্য কাউকে জিজ্ঞাসা করুন।

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

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


1

আছে "নামে পরিচিত অজানা" এবং "অজানা অজানা।" :-)

  1. অনুমানগুলি প্রায়শই সময়সীমা হয়ে যায়।

    • কেউ একটি সময়সীমা মিস এবং শিরোনাম হতে চান!
  2. প্রয়োজনীয়তা পরিবর্তন হয় (প্রায়শই যুক্তিযুক্তভাবে) এবং প্রোগ্রামার এটি ভেটো দিতে পারে না।

  3. প্রোগ্রামারগুলির / যেমন নিয়ন্ত্রণের কারণগুলিতে নিয়ন্ত্রণ থাকতে পারে না

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