একটি স্ক্র্যাম দলের ইনপুট কি হওয়া উচিত?


11

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

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


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

উত্তর:


4

প্রথম: এই সুন্দর কটাক্ষপাত আছে আলাপ , ফ্লোরিয়ান হাস FROSCON (জার্মানি) এ দিলেন। এটি আদৌ স্ক্রাম করার ব্যবহারিক অসম্ভবতা সম্পর্কে।

ভাল খবর : যেহেতু স্ক্রাম হয় অসম্ভব বাস্তবায়ন, আপনি যা ইচ্ছে করতে করতে পারবেন।

দুঃসংবাদ : যে স্ক্রাম কল করবেন না।

এটি আপনাকে এই প্রশ্ন থেকে মুক্তি দেয়: "আমি কি ঠিক স্ক্রাম করছি?" (উত্তর: না আপনি তা করেন না ) এবং আপনি জীবনের ব্যবহারিক প্রশ্নগুলিতে যেতে পারেন।


আমাদের কাছে কোনও ইউআই / ইউএক্স ডিজাইনার নেই এবং বিকাশকারীরা পণ্য মালিকের সাথে ইউআই / ইউএক্স কাজ করে

এটি একটি অস্বাভাবিক পরিস্থিতি নয়। তবে আফার স্ক্র্যাম বিশেষায়নের বিরুদ্ধে: প্রত্যেকের একই স্কিলসেট থাকা উচিত এবং বিনিময়যোগ্যভাবে কাজ করতে পারে।

প্রতিবারই আমরা ব্যাকলগ তৈরি করতে চলেছি এবং বসন্ত শুরুর আগে আমরা সঠিক ইউআই / ইউএক্স ডিজাইনটি সংজ্ঞায়িত করি না আমরা স্প্রিন্টের সময় ইউআই / ইউএক্স নকশা চূড়ান্ত করার চেষ্টা করে খুব বেশি সময় ব্যয় করি।

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

তারপরে কিউএ-ফেজ এসে আবার আলোচনা শুরু করে।

স্প্রিন্ট করার পর, আমরা যেমন স্ক্রাম দাবী করেনি পর্যালোচনা যেখানে নকশা পৃথক্ ripped ছিল পোঃ । দুর্ভাগ্যক্রমে আমাদের গ্রাহক পর্যালোচনাগুলিতে এটি তৈরি করেনি, তাই তিনি সেই সময়ে সফ্টওয়্যারটি দেখেন নি।

তবে পিও সন্তুষ্ট না হওয়া পর্যন্ত চক্রটি আবারও শুরু হয়েছিল over

এবং তারপরে গ্রাহক এসেছিলেন ...

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

শেষ পর্যন্ত আমাদের জন্য যা কাজ করেছিল তা হ'ল বোর্ডের উপরে স্ক্র্যাম ফেলে দেওয়া ।

তবে এটি আপনার প্রশ্নের সমাধান নয়;)

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

এই উভয়সঙ্কট একটি সমাধান মধ্যে আঁট feedbackloops) গ্রাহক নিজেই এবং জড়িত করা হবে পোঃ , যাতে মানদণ্ড অপেক্ষাকৃত টাইট প্রণয়ন করা হয়। খ) স্ক্রাম-টিম মধ্যে একটা সংকুচিত feedbackloop পোঃ রাস্তা বন্ধ চালাতে সুযোগ কমানোর জন্য।

আমি একটি ব্যাকলজিটেম সংজ্ঞায়িত করার জন্য কিছু (আরও) স্ক্র্যামের নিয়মগুলি ভঙ্গ করব: একটি »ওয়ার্কিং ডামি« কোন সাধারণ আইটেমটির জন্য বিকাশকারী সময় কমিয়ে আনতে পিও এবং গ্রাহকরা যা দ্রুত পর্যালোচনা করতে পারেন ।

TL; ড

একটি স্ক্র্যাম দলের ইনপুট কি হওয়া উচিত?

যতটা সম্ভব অল্প সময়ে চশমাগুলি পূরণ করার জন্য পর্যাপ্ত তথ্য।


অন্য প্রসঙ্গ:

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


মিঃ হাঃ স্ক্র্যাম কাঠামো সম্পর্কে বেশ অজ্ঞ। এটি এই ধরণের ভুল বোঝাবুঝির প্রতিফলন ঘটে যা এতগুলি সংস্থায় দেখা যায়।
অ্যালান ল্যারিমার

সেই গল্পটি বারবার বলা হয়: "যদি কেবল আপনি স্ক্র্যামটি করতেন"। স্ক্র্যাম কাজ করে এমন কোনও সংস্থা আমি কখনও দেখিনি। সুতরাং স্ক্রামের বিরুদ্ধে আমার দৃ strong় পক্ষপাত রয়েছে - যা আমাদের সংস্থায় স্ক্র্যামের প্রথম অভিজ্ঞতা অর্জনের পরেও বেড়েছে। এবং এখানে একই গল্প: এটি কার্যকর হয়নি (আমাদের জন্য)।
থমাস জাঙ্ক

7

ক্যানোনিকাল উত্তর হল "আপনার পক্ষে যা কাজ করে তা করুন" do

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

প্রক্রিয়া এবং সরঞ্জামগুলির উপর ব্যক্তি এবং ইন্টারঅ্যাকশনগুলি
বিস্তৃত নথিপত্রের উপর কাজ করে সফ্টওয়্যার
চুক্তি সমঝোতার বিষয়ে গ্রাহক সহযোগিতা
একটি পরিকল্পনার পরে পরিবর্তনটির প্রতিক্রিয়া ( চৌকস ইশতেহার )

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


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

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


4

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

আমাদের জন্য যা কাজ করেছে তা হ'ল:

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

টিএল; ডিআর: কোডিংয়ের আগে ইউএক্সকে সম্পূর্ণরূপে সংজ্ঞায়িত করবেন না। ব্যবহারকারীরা এটি না পাওয়া পর্যন্ত এটির সাথে অপেক্ষা করুন।


4

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

সোজা কথায়, যদি পণ্য মালিক স্প্রিন্টের আগে ui / ux নকশা সরবরাহ করতে সক্ষম না হয় তবে ui / ux এর বিকাশ একটি গল্প হওয়া উচিত , কোনও কাজ নয়।

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


3

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

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


3

আপনি যদি স্ক্র্যাম হন তবে যে কেউ ইউআই / ইউএক্স ডিজাইনার হতে পারেন।

ইউআই / ইউএক্সের কোনও চিন্তাভাবনা হওয়া উচিত নয়। এটি একটি বিতরণযোগ্য হতে হবে। এটি আপনার পণ্য মালিকের দ্বারা অনুমোদিত হওয়া উচিত। এটি প্রদান করা উচিত, এমনকি কেবল একটি জিআইএফ হিসাবে প্রদান করার সময়ও।

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

একমাত্র চূড়ান্ত ইউআই / ইউএক্স ডেড সফ্টওয়্যারটিতে রয়েছে।

আপনার মন্তব্য থেকে:

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

অযথাই আপনাকে ধীর করে দেয় এমন সমস্ত কিছু মুছুন।

আপনার একটা ধারণা আছে পণ্যের মালিককে বলুন। তারা আপনার পাশে বসে থাকা উচিত।

তারা এটা ঘৃণা? চলো এগোই. ভাল লাগছে? এটা কর. বুঝতে পারছেন না? তাদের দেখান.

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

যদি পণ্যের মালিক কাছাকাছি না থাকে তবে কোনও সুবিধাজনক মানবকে ধরে নিয়ে তাদের জিজ্ঞাসা করুন। এটি পুনরাবৃত্তি শুরু করতে যাই লাগে না। যত তাড়াতাড়ি সম্ভব পণ্য মালিককে আবার লুপ করুন।

এটিকে সুন্দর করে তুলতে এক সেকেন্ড ব্যয় করবেন না। শুধু পয়েন্ট পেতে। আপনার ধারণাগুলি ছোট এবং বর্ধমান রাখুন এবং যে কেউ এমনকি প্রাক্কলন জিজ্ঞাসা করার আগে আপনি সম্পন্ন করতে পারেন।


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

@ রাশিদ নোট আপডেট
candied_orange

@ রাশিদ যদি আপনি জটিলতার পরিবর্তে সময় অনুমান করে থাকেন তবে আপনি এটি ভুল করছেন!
এসভিডজেন

2

আমার অভিজ্ঞতা:

  • খুব সামান্য আপ-ফ্রন্ট বিশ্লেষণ অদক্ষ, স্টপ-স্টার্ট বিকাশের কারণ হয়ে থাকে
  • খুব বেশি আপ-ফ্রন্ট বিশ্লেষণ বিশ্লেষণের পক্ষাঘাত সৃষ্টি করে (স্প্রিন্ট কখনই শুরু হয় না)

আমরা কি করি:

  • কিছু " উন্নয়নের জন্য প্রস্তুত " মানদণ্ড সংজ্ঞা দিন
  • ইউএক্স গল্পগুলির জন্য, এটি হতে পারে "আমাদের কাছে একটি ওয়্যারফ্রেম রয়েছে যা দলটি ভালভাবে বুঝতে পারে"

স্প্রিন্ট পরিকল্পনার সময়:

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

এই সিস্টেমটি আমাদের প্রতিটি স্প্রিন্টের বেশিরভাগটি কার্যকর করার জন্য উত্সর্গ করতে দেয় অর্থাৎ আমরা আরও দক্ষতার সাথে কাজ করি।


2

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

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

এখন আমি আপনার স্ক্রমে "ফিচার এক্স এর জন্য একটি ইউজার ইন্টারফেস ডিজাইন" করেছি task এটি অনুমান করা যায়, এবং ফলাফলটি যাচাইযোগ্য। এটি একটি স্ক্রমের মধ্যে একটি ওকে কাজ। কাজটি শেষ হয়ে গেলে, আপনি এটি সম্পন্ন করেছেন।

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

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


1

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

স্প্রিন্ট শুরুর আগে আমরা সঠিক ইউআই / ইউএক্স ডিজাইনটি সংজ্ঞায়িত করি না

এই মুহুর্তে লক্ষ্যটি নিখুঁত হতে পারে না। প্রয়োজনীয়তার জন্য যথাযথ ইনপুট পান যাতে বিকাশকারীরা এমন কিছু তৈরি করতে পারেন যা যতটা সম্ভব কাছাকাছি জিজ্ঞাসা করা হয়েছে তার সাথে মেলে। একগুচ্ছ টুইটস তৈরি করবেন না বা এমন জিনিস ডিজাইনের চেষ্টা করবেন না যা জিজ্ঞাসা করা হয়নি। আপনি আপনার সময় নষ্ট করা হবে।

আমরা স্প্রিন্টের সময় ইউআই / ইউএক্স ডিজাইন চূড়ান্ত করার চেষ্টা করে খুব বেশি সময় ব্যয় করি।

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

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

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

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

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