অন্যান্য বিকাশকারীদের জন্য কার্যক্রমে কোনও প্রোগ্রামিং প্রকল্প কীভাবে ভাঙবেন? [বন্ধ]


164

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

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

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


27
আপনি কি কখনও কোনও স্থাপত্য সফটওয়্যার ডিজাইন করেছেন? আপনার বস হয় বিশ্বাস করেন আপনি এটি করতে পারেন, বা আপনাকে ব্যর্থতার জন্য সেট আপ করছেন।
রবার্ট হার্ভে

15
আপনি কি গিটের মতো সংস্করণ নিয়ন্ত্রণ ব্যবস্থা সম্পর্কে জানেন ? এটি বিভিন্ন স্থানের ইস্যুতে একই ফাইলের সম্পাদনা সমাধানে সহায়তা করতে পারে , যদি লোকেরা এটি সঠিকভাবে ব্যবহার করে!
বেসিল স্টারিনকিভিচ

2
আমি সবসময় প্রযুক্তিগত স্পেসিফিকেশন প্রথমে লেখা থাকতে চাই। তাহলে কী দরকার তা জানা সহজ to এর পরে কাজটি টাস্কে বিভক্ত হতে পারে "ডাটাবেস, ব্যবসায়, ইউআই, পরীক্ষা-কেস" সব সমান্তরালে করা যায়। যদি প্রকল্পটি বড় হয়, আপনি মডিউলে বিভক্ত করতে পারেন (উদাহরণস্বরূপ) "ব্যবহারকারী মডিউল, চালান মডিউল, চুক্তি মডিউল"। এছাড়াও, প্রযুক্তিগত নির্দিষ্টকরণের দ্বারা প্রতিটি কাজের জন্য এটি কতটা সময় নেবে তা জানার বিষয়টি অনেক সহজ (উদাহরণস্বরূপ: আমাদের কাছে 3 টেবিল থাকবে, 10 টি স্টোর পাওয়া যাবে, এতে 4 দিন সময় লাগবে। সত্তার 15 টি ব্যবসার নিয়ম রয়েছে, 3 নিতে হবে দিন)
the_lotus

6
উপলভ্য সময়, লোকের সংখ্যা, আনুমানিক ঘন্টা, কার্যের সংখ্যা ইত্যাদির ক্ষেত্রে আপনার সুযোগের আকার কত?
rmayer06

1
দেখে মনে হচ্ছে অনেক লোক কীভাবে কোনও প্রকল্প পরিচালনা করতে পারে তার জন্য টিপস সন্ধান করছে (একটি প্রকল্পের কাজ ভাঙ্গার কাঠামোটি আপনি প্রকল্প পরিচালনায় প্রথম কাজ করছেন)। এটি কি প্রধানমন্ত্রীর টিউটোরিয়ালের জন্য খুব ভাল ফর্ম্যাট?
rmayer06

উত্তর:


214

আপনার প্রশ্নের যথাযথ উত্তর বেশ কয়েকটি বই পূরণ করে । আমি বাজে শব্দের একটি বুলেট তালিকা নিয়ে আসব যা এই সম্পর্কে আমার মনে আসে, গুগল এবং বইগুলি আপনার জন্য বাকী কাজ করবে।

  1. বুনিয়াদি

    • একা যাবেন না । আপনার সতীর্থদের যতটা সম্ভব জড়িত করার চেষ্টা করুন।
    • ট্র্যাভেল লাইটওয়েট
    • গণতন্ত্র, তবে খুব বেশি নয়। কখনও কখনও, এটি সর্বাধিক সংখ্যক লোককে সন্তুষ্ট করার বিষয়ে নয়, তবে কম সংখ্যক লোককে কী ব্যথা দেয় hur
    • কী ( কী করা দরকার) এবং কীভাবে (এটি করা হয়) আলাদা রাখুন
    • জানুন স্ক্রাম ( "কি"), এক্সপি (এক্সট্রিম প্রোগ্রামিং, "কিভাবে"), Kanban ( "যাদের সাথে") ( "কত"), নিষ্ফলা ( "কি") এবং DevOps।
    • হ্রাস এছাড়াও প্রবাহ সম্পর্কে : সামগ্রিক দক্ষতার জন্য, প্রবাহ দক্ষতা সাধারণত পৃথক দক্ষতার চেয়ে বেশি গুরুত্বপূর্ণ।
    • সফটওয়্যার কারুশিল্প , ক্লিন কোড এবং প্র্যাগমেটিক প্রোগ্রামিং সম্পর্কে জানুন ।
    • গুড স্থাপত্য সম্পর্কে গ্রহণ সিদ্ধান্তের সংখ্যা বাড়ানোর
    • স্ক্রাম / এক্সপি / চর্বি / চটপটি না করা কাজের পরিমাণকে সর্বাধিকীকরণের বিষয়ে : YAGNI
    • সফ্টওয়্যারের প্রাথমিক মূল্য যে আপনার পারে সহজে পরিবর্তন করুন। এটি এটি করা উচিত যা গুরুত্বপূর্ণ তা গুরুত্বপূর্ণ তবে এটি কেবলমাত্র তার দ্বিতীয় মান।
    • একটি পুনরাবৃত্তি এবং বর্ধনশীল পদ্ধতির পছন্দ করুন , প্রায় প্রতিটি কিছুর জন্য টাইম বক্স ব্যবহার করুন, বিশেষত সভাগুলি, পারকিনসন আইনকে আপনার বন্ধু বানান কারণ হাফস্টাডটারের আইন প্রযোজ্য।
    • কনওয়ের আইন এবং টিম বিকাশের টাকম্যান স্টেজের বোঝাপড়া সহ ভারসাম্য দল কাঠামো ।
    • প্রোগ্রামিং একটি চতুরতা, এটি বিজ্ঞান , প্রকৌশল , শিল্প এবং কারুশিল্প সব একই সাথে এবং সেগুলি ভারসাম্যপূর্ণ হওয়া দরকার।
    • শুধু কারণ স্ক্রাম / এক্সপি / XYZ কেউ জন্য ভাল (আমি সহ) অগত্যা এটা আপনার জন্য ভাল মানে এই নয় / আপনার পরিবেশ suits। অন্ধভাবে হাইপ অনুসরণ করবেন না, প্রথমে এটি বুঝতে।
    • পরিদর্শন এবং অভিযোজিত! (স্ক্রাম মন্ত্র)
    • সদৃশ এড়ানো - একবার এবং কেবল একবার! (এক্সপি মন্ত্র) ওরফে ডিআরওয়াই - নিজেকে আরএফ স্পট পুনরাবৃত্তি করবেন না - সত্যের একক পয়েন্ট
  2. "হোয়াট ওয়ার্ল্ড" ওয়ার্ক ব্রেকডাউন প্রক্রিয়া

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

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

    • ওওএ / ডি , ইউএমএল এবং সিআরসি কার্ডগুলি ব্যবহার করুন তবে বড় ডিজাইনের সামনে এড়ান
    • বাস্তবায়ন অবজেক্ট-মুখী , কাঠামোগত এবং কার্মিক একই সময় যতটা সম্ভব এ প্রোগ্রামিং ভাষা নির্বিশেষে।
    • সংস্করণ নিয়ন্ত্রণ ব্যবহার করুন (পছন্দসই বিতরণ )।
    • স্বীকৃতি পরীক্ষা দিয়ে শুরু করুন ।
    • টিডিডি প্রয়োগ করুন , বিডিডি থেকে সিঙ্গল-অ্যাসেট-রুল , 4 এএস , জিডাব্লুটি (যখন দেওয়া হবে) সহ টিডিডি-তিনটি আইন আপনাকে রেড-গ্রিন-রিফ্যাক্টর-সাইকেলের মাধ্যমে চালিত করবে ।
    • " ইউনিট পরীক্ষা হয় পরীক্ষা যা দ্রুত রান ।" - মাইকেল পালক
    • কাপলিং এবং সংহতি পরিচালনা করতে SOLID এবং প্যাকেজ নীতিগুলি প্রয়োগ করুন । উদাহরণ: SOLID এ এসআরপি = একক দায়িত্বের নীতি, উল্লেখযোগ্যভাবে সম্পাদনার সংখ্যা হ্রাস করে। দলে সংহত-বিবাদ।
    • ডেমিটারের আইন জানুন / বলুন, জিজ্ঞাসা করবেন না
    • ব্যবহার করুন ক্রমাগত ইন্টিগ্রেশন , যদি প্রযোজ্য হয় এমনকি ক্রমাগত ডেলিভারি (DevOps)।
    • সম্মত সাধারণ কোডিং স্ট্যান্ডার্ড (যা সম্পন্ন সংজ্ঞায়নের অংশ হওয়া উচিত ) এর ভিত্তিতে কালেক্টিভ কোডের মালিকানা ব্যবহার করুন ।
    • অবিচ্ছিন্ন নকশা উন্নতি প্রয়োগ করুন (fka ধারাবাহিক রিফ্যাক্টরিং)।
    • উত্স কোড ডিজাইন । তবুও সামনের চিন্তাভাবনা অপরিহার্য, এবং কেউ ইউএমএল ডায়াগ্রামগুলি পরিষ্কার করার জন্য কয়েকটি ভাল আপত্তি করবে না।
    • এক্সপি মানে এই নয় যে কোনও দিন আর্কিটেকচার ডে নয়, এর অর্থ প্রতিটি দিন আর্কিটেকচার ডে is এটি আর্কিটেকচারের উপর ফোকাস, কোনও ডিফোকস নয়, এবং ফোকাসটি কোডে রয়েছে।
    • আপনার Keep কারিগরী ঋণ কম, চার নকশা এড়াতে গন্ধ পাচ্ছি ভঙ্গুরতা , অনমনীয়তা , অচলতা এবং সান্দ্রতা
    • আর্কিটেকচার ব্যবসায়ের যুক্তি সম্পর্কিত, দৃ ,়তা এবং বিতরণ প্রক্রিয়া সম্পর্কে নয়।
    • আর্কিটেকচারটি একটি টিম স্পোর্ট ( আর্কিটেকচারে 'আমি' নেই )।
    • নকশার প্যাটার্নস , রিফ্যাক্টরিং এবং ট্রান্সফর্মেশন অগ্রাধিকার প্রাইমস
    • প্রজেক্ট কোডটি অগ্রাধিকার সহ এটিপি-ট্রিনিটি : ১. অটোমেশন কোড , ২. টেস্ট কোড , ৩. উত্পাদন কোড
    • আপনার টিম পিয়ারদের সাথে নিয়মিত পরীক্ষা করে দেখুন যে কীভাবে দল সরবরাহ করে উন্নতি করা যায়। (স্ক্রাম সভা: স্প্রিন্ট রেট্রোস্পেক্টিভ )
    • টেস্টগুলি প্রথম হওয়া উচিত - দ্রুত, স্বতন্ত্র, পুনরাবৃত্তিযোগ্য, স্ব-যাচাইকরণ এবং সময়োপযোগী।

উপরের তালিকাটি অবশ্যই অসম্পূর্ণ এবং কিছু অংশগুলি বিতর্কিতও হতে পারে!

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

আরো দেখুন

আরও পড়া (অনলাইন)

আরও পড়া (বই)

  • রবার্ট সি মার্টিনের ক্লিন কোড
  • চতুর সফ্টওয়্যার বিকাশ: রবার্ট সি মার্টিনের নীতি, প্যাটার্নস এবং অনুশীলনগুলি
  • প্র্যাকমেটিক প্রোগ্রামার - অ্যান্ড্রু হান্ট এবং ডেভিড থমাস দ্বারা জার্নিম্যান থেকে মাস্টার
  • মাইকেল পালক দ্বারা লিগ্যাসি কোড নিয়ে কার্যকরভাবে কাজ করা
  • রিফ্যাক্টরিং - মার্টিন ফওলারের বিদ্যমান কোডের নকশা উন্নত করা
  • জোশুয়া কেরিভস্কির প্যাটার্নসে রিফ্যাক্টরিং
  • স্টিভেন সিলবিগারের দশ দিনের এমবিএ (sic!)
  • এরিক ইভান্স দ্বারা ডোমেন-চালিত ডিজাইন
  • ব্যবহারকারী গল্প মাইক কোহান দ্বারা প্রয়োগ করা
  • গ্রে বুচ এবং অন্যান্য অ্যাপ্লিকেশনগুলির সাথে অবজেক্ট-ওরিয়েন্টেড এনালাইসিস এবং ডিজাইন
  • গ্যাং অফ ফোর ডিজাইনের প্যাটার্নস
  • কেন্ট বেক দ্বারা চালিত টেস্ট চালিত বিকাশ
  • ক্যান্ট বেকের চরম প্রোগ্রামিং
  • [যদি জাভা] জোশুয়া ব্লচের কার্যকর জাভা

1
+1, আকর্ষণীয় উত্তর যা রেফারেন্স হিসাবে ব্যবহার করা যেতে পারে। এর শৈলীটি আমাকে ভাবতে বাধ্য করে যে কোনও ওয়েব অ্যাপ্লিকেশনটির প্রোগ্রামার সাইটটিকে সর্বজনীন করার আগে কোন প্রযুক্তিগত বিবরণ বিবেচনা করা উচিত?
আর্সেনী মোরজেনকো

3
বই সাহায্যে আসতে পারে এমন (কিছু যেমন ই বই পাওয়া যায়): Addison Wesley - The Pragmatic Programmer, From Journeyman To Master by Andrew Hunt, David Thomas & Addison Wesley - 1999, O'reilly - The Productive Programmer by Neal Ford, Prentice Hall - Clean Code, a Handbook of Agile Software Craftsmanship ny Robert C. Martin, ..., O'Reilly - Head First Object-Oriented Analysis & Design by Brett D. McLaughlin, Gary Pollice & David Westএবং আরও অনেক কিছু ...
BlueCacti

4
ক্ষমা করবেন স্যার, আমি এই উত্তরটি নেব, এটি একটি পিডিএফ তৈরি করব, এটি মুদ্রণ করব এবং এটি আমার অফিসের দেয়ালে পেস্ট করব ...
আগস্টিন মেরিলস

1
@ অগাস্টিনমেরিলস এগিয়ে যান, কেবলমাত্র তিনটি ছোট ছোট অনুরোধ - যদি সম্ভব হয় এবং আপনি যদি চান 1. উত্স হিসাবে প্রোগ্রামারস.স্ট্যাকেক্সচেঞ্জ.কমের উল্লেখ করুন। 2. লেখক হিসাবে আমার উল্লেখ করুন। ৩. যদি আপনার সহকর্মীদের প্রতিক্রিয়া বা সংযোজন থাকে তবে দয়া করে এটি এখানে পোস্ট করুন যাতে আমি এবং সম্প্রদায়ের অন্য প্রত্যেকে উত্তর আরও উন্নত করতে পারে।
খ্রিস্টান হুজার

হ্যাঁ, তাতে কোনও সমস্যা নেই :)
আগস্টিন মেরিলস

34

চটফটে পান

আমি নিম্নলিখিতটি সুপারিশ করব:

একই ফাইলগুলি সম্পাদনা করা হচ্ছে

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

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

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

সমস্ত বৈশিষ্ট্য তালিকাবদ্ধ করুন

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

এগুলি ব্যবহারকারীর দৃশ্যমান বৈশিষ্ট্য হওয়া উচিত, আপনি পরে বাস্তবায়ন কৌশল সম্পর্কে কথা বলতে পারেন।

সূচক কার্ডগুলিতে সমস্ত পরামর্শ লিখুন, এমনকি বোবাও। সদৃশগুলি মুছে ফেলার জন্য দ্রুত তালিকাকে যুক্তিযুক্ত করুন এবং সমস্ত কার্ড একটি বড় টেবিল বা এমনকি মেঝেতে রেখে দিন।

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

এখন আপনার কার্ডগুলি গোষ্ঠীগুলিতে বাছাই করুন, এগুলি সম্পর্কে শ্যাফাল করুন, তাদের জন্য অনুভূতি পান। এটি আপনার প্রকল্পের সুযোগ।

পরিকল্পনা জুজু

পোকার পরিকল্পনা করতে যান। তবুও সবার সাথে একসাথে, "1 পয়েন্ট", "2 পয়েন্ট", ইত্যাদির সমস্ত বিকাশকারী কার্ডকে "4 পয়েন্ট" পর্যন্ত দিন। এছাড়াও একটি "আরও" কার্ড। একটি বিন্দু প্রায় এক ঘন্টা সমান।

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

যদি আপনি সম্মত হন যে কোনও বৈশিষ্ট্যটি "আরও", তবে বৈশিষ্ট্যটি খুব বড়। আপনাকে সেই বৈশিষ্ট্যটি ভেঙে ফেলতে হবে। এটি আগের মতো করুন।

আপনার যেমন চুক্তি রয়েছে, কার্ডগুলিতে নম্বরগুলি আলাদা রঙের কলমে লিখুন।

পয়েন্টগুলি ঘন্টা চেয়ে ভাল

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

এবার একটি স্প্রিন্ট রচনা করুন

একটি স্প্রিন্ট একটি লক্ষ্যের দিকে দ্রুত ফেটে যায়। স্প্রিন্ট দৈর্ঘ্যের বিষয়ে সিদ্ধান্ত নিন, সম্ভবত 5 বা 10 দিন। বিকাশকারীর সংখ্যা দ্বারা প্রতিদিনের পয়েন্ট সংখ্যা দ্বারা দিনের সংখ্যাকে গুণ করুন।

প্রাথমিকভাবে বিকাশকারীকে প্রতিদিন 6 টি পয়েন্ট ধরুন। এটি একটি অর্জনযোগ্য সংখ্যা। আপনার যদি 5 জন থাকে তবে তা 5 * 5 * 6 = 150 পয়েন্ট। সমস্ত বিকাশকারী এবং পরিচালনার সাথে একযোগে, 150 টি পয়েন্ট পর্যন্ত তালিকা থেকে বৈশিষ্ট্যগুলি বেছে নিন। এটি আপনার স্প্রিন্ট

মাপসই করা হবে তার চেয়ে বেশি কষতে কখনও প্রলোভন করবেন না। ওভার-প্রতিশ্রুতিবদ্ধতা আপনাকে সহ দীর্ঘকালীন সবাইকে কষ্ট দেয়।

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

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

অতিরিক্ত অতিরিক্ত কখনই চেপে ধরার প্রলোভন করবেন না। অতিরিক্ত-প্রতিশ্রুতিবদ্ধতা আপনাকে প্রায় 1 দিনের মূল্যবান ক্লায়েন্ট দেয়, তারপরে 4 দিনের টিম স্ট্রেস দেয় এবং শেষ পর্যন্ত সম্ভবত দলটি সময়মতো বিতরণ করতে না পারলে বেশ কয়েকজন অসন্তুষ্ট ক্লায়েন্ট থাকে।

এখন এটি যান।

কার্ডগুলি হ্যান্ড আউট করুন, জিজ্ঞাসা করুন কে কি করতে চায়। কী হচ্ছে তার আপনার সম্পূর্ণ দৃশ্যমানতা রয়েছে এবং আপনি পয়েন্টগুলি শূন্যের নিচে টিকতে পারেন। প্রতিটি দিনের শুরুতে একটি স্ট্যান্ডআপ রাখুন যাতে কে জানে এবং কী করা হয়েছে তা কে সবাই জানেন everyone

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

দৃশ্যমানতা বজায় রাখুন

প্রকল্পটির স্থিতি কী তা প্রত্যেকে দেখতে পাবে তা নিশ্চিত করুন। দেয়াল থেকে সমস্ত কার্ড ব্লুয়েট্যাক। বামদিকে এমন কার্ড রয়েছে যা এখনও কাজ করেনি। ডানদিকে কার্ড সম্পন্ন হয়।

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

সূচক কার্ডগুলির জন্য প্রযুক্তিগত বিকল্প রয়েছে, তবে প্রাচীরের উপরে প্রকল্পের স্থিতির একটি বিশাল কাগজ প্রদর্শন থাকা কিছুই বটে না।

সম্ভব হলে প্রকল্পের সময়কালের জন্য সবাইকে একই ঘরে রাখুন। আদর্শ হিসাবে প্রতিদিন যতটা সম্ভব স্টেকহোল্ডারদের রাখুন।

দগ্ধ করা

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

আপনি যদি ব্যর্থ হতে চলেছেন তবে তাড়াতাড়ি ব্যর্থ হন।

আপনি সফ্টওয়্যার ব্যবহার করে একটি বোরডাউন তৈরি করতে পারেন, তবে আমি দেয়ালে কেবল একটি বড় টুকরো কাগজ পছন্দ করি। এটি আঁকুন এবং সব লিখুন।

স্বয়ংক্রিয় পরীক্ষা

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

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

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

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

প্রযুক্তিগত debtণ এড়ানো এবং সম্পন্ন করা

প্রযুক্তিগত debtণ এমন একটি ধারণা যা সেই জিনিসগুলিকে বর্ণনা করে যা পরে পরিষ্কার করতে হবে। Debtণের একটি সাধারণ উত্স এমন বৈশিষ্ট্য যা সম্পন্ন হিসাবে চিহ্নিত হয়েছিল, তবে যা কখনও "সম্পন্ন" হয় নি। সম্পন্ন বৈশিষ্ট্যটি গিট-এ চেক ইন করা হয়েছে, স্টেকহোল্ডার দ্বারা অনুমোদিত হয়েছে এবং একটি পরীক্ষা রয়েছে।

আপনার বৈশিষ্ট্যগুলি সম্পন্ন না হওয়া অবধি পরীক্ষা করবেন না। গ্রাফটি কখনই ম্যাসাজ করবেন না। আবার এটি আপনাকে সহ দীর্ঘকালীন সবাইকে কষ্ট দেয়।

এটি প্রাথমিকভাবে কেন আমরা প্রাথমিকভাবে প্রতি বিকাশকারী প্রতি 6 টি পয়েন্ট উদ্ধৃত করি। সম্পন্ন করা অতিরিক্ত কাজ করে তবে দুর্দান্ত বোধ করে এবং দলকে একটি উত্সাহ দেয়।


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

আমি হালকাতার সাথে একমত আপনার কখনই একটি স্বয়ংক্রিয় মার্জ করা উচিত নয়। বিকাশকারীরা তাদের পরিবর্তিত ফাইলের সাথে সামঞ্জস্য রয়েছে কিনা তা নিশ্চিত করার জন্য প্রতিটি তফাত পরীক্ষা করা উচিত।
ডঙ্ক

@ লাইটনেসেসেসিনআরবিট - হ্যাঁ, আমি জিনিসগুলিকে কিছুটা সহজ করছি। গিট কোনও প্যানিসিয়া নয়, তবে কমপক্ষে একত্রিত হওয়া আসলে সম্ভব। আমার সম্ভবত ইউনিট এবং গ্রহণযোগ্যতা পরীক্ষার উল্লেখ করা উচিত।
সুপারলুমিনারি

3
চতুরতা প্রতিটি সমস্যার সমাধান নয় এবং আপনি যদি বেসিক প্রকল্প পরিকল্পনা এবং পরিচালনা ধারণাটি না জানেন তবে এটি কোনও লাভ করবে না।
rmayer06

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

10

একই ফাইলগুলি সম্পাদনা করা নিজেই কোনও সমস্যা নয়। আপনি যদি দুটি ভিন্ন জিনিস করতে একই ফাংশনটি সম্পাদনা করেন তবে এটি কেবল একটি সমস্যা।

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

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

কিছু কাজ ক্রমানুসারে সম্পন্ন করতে হবে ("প্রোগ্রামটি কনফিগারেশন ফাইলের সমস্ত ক্ষেত্র বিশ্লেষণ করবে" "প্রোগ্রামটি কনফিগারেশন ফাইলটি লোড করবে" এর পরে আসতে হবে))। অন্যরা তা করবে না (আপনি একই সাথে ডিবি এবং নেটওয়ার্কে কাজ করতে পারবেন)।

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

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


1
যদি টিমের সদস্যরা একে অপরের সাথে কথা বলে, তবে মাঝে মধ্যে দ্বন্দ্ব (সংস্করণ নিয়ন্ত্রণ অর্থে) সহজেই সমাধান করা যেতে পারে। দৈনিক স্ট্যান্ড আপ সভাটি এটিকে সহায়তা করে।
জানু হুডেক

10

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

মডিউলগুলি পৃথকভাবে কাজ করে তা নিশ্চিত করার জন্য আপনি বিকাশকারীদের উপর টিডিডি প্রয়োগ করেছেন তা নিশ্চিত করুন।

আমি কী বলতে চাইছি তার একটি উদাহরণ দিতে:

ধরা যাক আপনি আপনার বিকাশকারীদের মধ্যে একটি এসকিউএল লগার তৈরি করতে চান।

আপনি একটি ইন্টারফেস সংজ্ঞায়িত করেছেন এবং আপনার ডেভেলপারদের ( বা আপনি যদি চপল ব্যবহার করছেন তবে একটি গল্প তৈরি করুন ) জিজ্ঞাসা করুন যে আপনি নিম্নলিখিত স্পেসিফিকেশন অনুসারে একটি এসকিউএল নির্দিষ্ট লগার চান:

interface ILogger
{
    void Log(string message, int level);
}

আমি তখন বিকাশকারীদের কাছ থেকে ফিরে যা প্রত্যাশা করি তা হ'ল:

  1. লগারের জন্য এসকিউএল সুনির্দিষ্ট বাস্তবায়ন

    class SqlLogger : ILogger
    {
        private readonly SqlLogRepository _logRepository;
    
        public SqlLogger(SqlLogRepository _logRepository)
        {
            this._logRepository = _logRepository;
        }
    
        public void Log(string message, int level)
        {
            _logRepository.CreateLog(message,level);
        }
    }
  2. যে কোনও নির্ভরশীল কোড যেমন এর জন্য একটি বাস্তবায়ন SqlLogRepository

  3. যা চেয়েছিল তা নির্ভর করে ইউনিট বা মক টেস্ট tests উপরের ক্ষেত্রে একটি মক পরীক্ষা (যেখানে আমাদের অন্যান্য বাহ্যিক নির্ভরতা রয়েছে), বা যদি এটি যেমন একটি সাধারণ ইউটিলিটি ফাংশন যেমন String.ReverseCharacters(string input), তবে আমি কেবল ইউনিট পরীক্ষা দেখতে চাই যা কয়েকটি ভিন্ন পরিস্থিতিতে পরীক্ষা করে।

এই যে মানে:

আপনি এবং আপনার দল এখন এই ইন্টারফেসটি ব্যবহার করে বিকাশ চালিয়ে যেতে পারেন। যেমন

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

এবং যদি আপনার কোডটি স্থাপনের আগে চালানোর দরকার হয় তবে আপনি SqlLoggerসাধারণভাবে একটি তৈরি করতে পারেন NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

এবং এর মধ্যে আপনি কীভাবে এটি পরীক্ষা করতে পারেন (আমি নির্ভর করে ইনজেকশনের জন্য কোনও আইসিও দেখার পরামর্শ দিই)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

সারাংশ

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

আমি অত্যন্ত পরামর্শ দিচ্ছি যে আপনি নকশা এবং অবজেক্ট ওরিয়েন্টেড দৃষ্টান্তটি পড়ুন। আপনি এই প্রকল্পের জন্য ওওপিতে প্রচুর নির্ভর করবেন।


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

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

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

আমি মনে করি যে টিডিডি দরকার। টিডিডি না করা হ'ল ডাক্তার হিসাবে হাত না ধুয়ে বা হিসাবরক্ষক হিসাবে ডাবল-এন্ট্রি বই না করার মতো। আমি জানি পিপিএল এর সাথে একমত নন, তবে ডাক্তাররাও ডঃ সেমেলওয়েসের সাথে একমত নন। তবে আমি মনে করি টিডিডি "প্রয়োগ" করা যায় না। টিডিডি উদাহরণ দিয়ে শেখানো ও বাঁচানো যায়, তবে এটি "প্রয়োগ করা" হয়, তবে আমি আশঙ্কা করি এটি কার্যকর হবে না, কারণ বল সর্বদা প্রতিরোধ-প্রতিরোধ / প্রতিরোধের কারণ হয়ে দাঁড়ায়।
ক্রিশ্চিয়ান হুজার

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

2

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

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

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

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


1

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

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

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