https://virgool.io/feed/@samiraamiri227 سمیرا امیری هستم که به عنوان اجایل کوچ، اسکرام مستر و مدیریت پروژه در شرکت های نرم افزاری فعالیت میکنم اینجا مکانی برای برون ریزهای ذهنی ام است. fa 2026-06-18 20:47:00 https://files.virgool.io/upload/users/105658/avatar/Jl83eh.png?height=120&width=120 https://virgool.io/@samiraamiri227 https://virgool.io/@samiraamiri227/%D8%A7%D9%87%D9%85%DB%8C%D8%AA-dod-%D8%AF%D8%B1-%D9%81%D8%B1%D8%A2%DB%8C%D9%86%D8%AF-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%85%D8%AD%D8%B5%D9%88%D9%84-chkxo04vdvil ?مقدمه:در شرکت های برنامه نویسی با رویکرد اجایل مسملما این واژه زیاد به گوشتان خورده است و حتی ممکن است در تیمی که بوده اید از آن استفاده میکردید ولی تا به حال در مورد چگونگی شکل گرفتن این معیارها و تعریف ها میدانستید؟ یا در جلساتی که تعریف میشوند حضور داشته اید؟ آیا سطوح انجام کار برای شما تعریف شده است؟ و شما اگر به عنوان یک مالک محصول یا توسعه دهنده فعالیت میکنید چه تعریفی از این قسمت برای خود دارید؟ در ادامه میخواهیم کمی شفاف تر کنیم و از روی Case Study های بررسی شده و تجربه شده به شما نشان دهیم که میتواند چقدر منعطف باشد و چه پارامترهایی اجباری است و شما با توجه به اینکه اجایل چارچوبی کاملا منعطف است چقدر میتوانید در آن دست ببرید.شرایط پذیرش (DoD):DoD یعنی بتوانیم توسط آن بگوییم کاری انجام شده و قابلیت استفاده دارد و کیفیت آن تضمین شده است حالا اینکه چگونه میتوان با اطمینان این تاییدات داد برمیگردد به نقش هر بخش در DoD.ممکن است شما یک تیمی داشته باشید که از قسمت های مختلف فنی و غیر فنی مختلفی شکل گرفته باشد (هدف این نیست که Spotify را مثال بزنیم چون کاملا نحوه مدیریت و رشد تیم در Spotify متفاوت است) در نظر بگیرید تیم شما شامل Front-end ، Back-end، QC، QA میشود چگونه برای هر کدام DoD تعریف میکنید و در نهایت میگویید به چه چیزی در تحت چه سنجه ای میگویید انجام شده؟در استاندارد جهانی برای مراحل مختلف از پیاده سازی تا تست و Deploy نهایی تعریف انجام شده شکل میگیرد. اگر یک اسپرینت را در نظر بگیرید میتوانیم بدین صورت تعریف داشته باشیم:در استاندارهای جهانی برای مراحل مختلف با وجود تعریف اجایل DOD تعریف میگردد این بدان معناست که ما میتوانیم لیستی جامع از DoD ها داشته باشیم و برای هر قسمت بسته به نیاز از آن استفاده کنیم قرار نیست همه چی در این لیست تیک بخورد بلکه لازمه هر آن چیزی که در اول اسپرینت تعیین شده است محقق شود.برای نمونه استاندار جهانی برای تیک خوردن DoD کد نویسی :ü کد مورد بررسی قرار می گیردü کد بررسی می شودü کد برای آزمایش محیط استفاده می شودü کد/ویژگی از آزمون رگرسیون عبور می کندü کد/ویژگی تست دود را پشت سر می گذاردü کد مستند استü مستندات راهنما به روز شده استü ویژگی توسط ذینفعان خوب استبا توجه به ساختار تیم های اجایل عموما Team Leader ها و Scrum Master ها تهیه کننده لیست نهایی و مسئول اشتراک گذاری و بررسی آن هستند؛ ولی برای تعریف لیست باید مشارکتی و با تیم محصول باشد.**: همچنین چک لیست تهیه شده میتواند برای یک اسپرینت یا میتوان برای مدت چرخه عمر یک محصول استفاده کرد.یک تعریف کلی که در بیشتر شرکت هایی با متدلوژی اجایل فعالیت میکنند مشترک است:"زمانی میگیم شرایط DoD محقق شده همه استوری های تعریف شده در یک اسپرینت قابلیت ورژن شدن و به دست مشتری رسیدن را دارا باشند."تعریف DoD باعث صرفه جویی در زمان و جلوگیری از انجام مجدد کارها میشود چون یک کار براساس چک لیست تمام میشود و قابلیت ارائه را دارد . (جلوگیری از بدیهی فنی)مزایای DoD:§ باعث کاهش دوباره کاری§ باعث مشخص بودن استوری و جلوگیری از گستردگی استوری های کاربری§ باعث ایجاد کیفیت در کار§ جلوگیری از ارائه داستان اشتباه به مشتری§ جلوگیری از بازسازی های مداوم زیرساختیارزش DoD را میتوان اینگونه تعریف کرد:"تعریف DoD باعث صرفه جویی در زمان و جلوگیری از انجام مجدد کارها میشود چون یک کار براساس چک لیست تمام میشود و قابلیت ارائه را دارد . (جلوگیری از بدیهی فنی)"نقش تیم محصول در تعیین DoD:برای جلوگیری از بدهی فنی تیم بهتر است تمامی شرایط پذیرش (acceptance criteria) یک استوری توسط مالک محصول قبل آن برآورد شود که نه تیم از لحاظ فکری درگیر باشد و نه در پایان اسپرینت با موضوع بدهی فنی مواجهه شویم. و از طرفی در چک لیست DoD نیز با موفقیت پشت سر بگذارد.لیست DoD میتواند یک بار تعریف شود و چک لیست متناسب با پروژه باشد ولی هر DoD نیاز به معیارهایی دارد که میگوییم acceptance criteria و خاصا برای هراستوری تعریف میشود.**: تعریف پذیرش یک استوری باید ساده و کوتاه باشد.چک لیست DoD باید کوتاه باشد یعنی یک لیست 20 تایی ندهید و انتظار تیک خوردن همه موارد را داشته باشید بلکه مواردی تیک میخورد که لازم باشدو همچنین باید خاصیت تمرکز پذیری را دارا باشد.DoD ها را با این جمله بسنجید:"من به عنوان [نوع کاربر] [برخی ویژگی های خاص] را می خواهم تا [برخی از مزایا] دریافت شود."**: طبق چک لیست ممکن است کاری تمام باشد ولی هیچ گاه در سمت تیم فنی کاری را تمام شده فرض نکنید بلکه تا زمانی که در چرخه محصول هستید باید به توسعه محصول و وابستگی های آن فکر کنید.معیار های انجام شده یا Acceptance criteria:o کد نوشته شده است اساسی ترین چیزی که باید تکمیل شود تا هرگونه داستان یا مسئله کاربر "انجام شود".o کد مستند است در این سطح ، شما به احتمال زیاد می خواهید برخی از اسناد توسعه دهنده را تکمیل کرده و در دسترس قرار دهید. بسته به اندازه پروژه ، ممکن است بخواهید نوعی سند مستند برای راهنمایی برای پشتیبانی (که به سوالات مربوط به انتشار به کاربران پاسخ می دهد) ایجاد کنید.o بررسی کد تکمیل شد. به عنوان بخشی از اسپرینت خود ، می خواهید کد خود را برای بررسی با معیارهای مشخص (و معیارهای پذیرش) آماده کنید. برای "انجام شدن" ، کد باید توسط تیم شما مورد بررسی قرار گیرد.o Build در محیط توسعه ساخته شده و به کار گرفته شده است. تعریف شما از انجام شده باید فراتر از محدوده محیط توسعه کد باشد.با درنظر گرفتن استقرار، به حفظ اجایل بودن تیم خود را حفظ کنید.o آزمایشات به پایان رسیده است. آیا کار می کند؟ قبل از اتمام کار ، باید مطمئن شوید که برنامه تست های لازم خود را گذرانده است و مطمئن شوید که در این بین هیچ چیز دیگری را تغییر پیدا نکرده است.o با یک تعریف واضح از انجام ، شما باید اطمینان حاصل کنید که این قوانین در مورد همه کارها یا مسائل قابل اجرا درفریم ورک مورد استفاده شما اعمال میشود. چه انتشار ویژگی مهمی داشته باشید و یا چه رفع باگ فقط تفاوت در نوع اطلاع رسانی به مشتری است ولی حتما چک لیست "انجام شده" شما را بررسی کند.**: نقطه ای است که خیلی ها fail میشوند.بهتر است در مواقعی که فشار کاری زیاد است و شما باید به ددلاین مشخص در کمینه ترین زمان ممکن برسید تمرکز خود را برای روی معیارهای انجام استوری به جای DoD بگذارید. هرچند که در این نوع تائید کردن شما باید قسمت به قسمت بررسی کنید و نمیتوانید مجموعه ای ارائه دهید.ساده ترین مشکلاتی که در صورتی که در تیم برسر وجود DoD ها توافق نکرده باشیم:بدون تعریف واضح از کار انجام شده ، تیم توسعه شما نمی داند که در حال انجام چه کاری است ، ذینفعان شما در افزایش دامنه نیازهای خود مختارمیشود و نه شما دیگر میتواند از سیستم اولویت بندی استفاده کنید و نه میتوانید توافقی مشترک داشته باشید؛ و کاربران شما به احتمال زیاد با محصولی شلوغ ، گیج کننده و غیرقابل استفاده به پایان رو به رو میشوند.پیشنهاد میشود که ابتدا از پایان به ابتدای آن بررسی کنید و Workflow آن را رسم کنید یک وضوح کامل از فرآیند ها به شما میدهد، زبان مشترکی ایجاد میکند، کیفیت وانتظارات را متعادل میکند و مهمترین فاکتور از کمال گرایی جلوگیری میکند.**: اگر برای خود اهداف مشخص را تعیین نکنید تیم به صورت مداوم در حالت بلاکی است و بدیهی فنی زیادی به بار میآورد که بعد از آن باید ابتدا آن بدیهی را پرداخت کنید.خلاصه ای از مزایای DoD از لحاظ ساختار:- ایجاد یک درک مشترک از کیفیت و کامل بودن این امر به ویژه در برنامه ریزی اجایل بسیار مهم است.- ایجاد یک چک لیستی از نیازهای مشتری از قسمت های مختلف محصول این کار باعث میشود در آینده زمان صرفه جویی و جلوگیری از دوباره کاری های خسته کننده شود.- اطمینان حاصل کنید که در هر اسپرینت محصول در حال تولید الزامات و کیفیت لازم توافق شده را دارا میباشد این کار باعث میشود در نتیجه مشتریان راضی بیشتری داشته باشید.- اگر درخواستی خارج از برنامه وارد شد به جای اینکه روی تیم فشار بیاورید خیلی محکم آن را به اسپرینت بعدی منتقل کنید.- تعریف انجام کار و معیارهای پذیرش به مشخص شدن زمان اتمام پروژه کمک میکند.چه کسی "انجام شده" را برای داستان کاربر/ویژگی/پروژه شما تعریف می کند؟در حالی که تعریف "انجام شده" باید شامل ورودی تیم محصول ، کنترل کیفیت و ذینفعان مربوطه باشد ، در نهایت این به تیم فنی بستگی دارد که به چه معنا تصمیم می گیرد.مراحل ارائه لیست DoD:برای تعریف شرایط پذیرش و انجام شده باید ابتدا مالک محصول لیستی را تهیه کند و در یک جلسه به اعضای تیم بدون حضور اشخاص خارجی ارائه دهد و تیم روی آن به جمع بندی و شفافیت برسد بعد از آن به منظور اطلاع رسانی و همچنین بهبود آن ارسال به واحد های تحت تاثیر صورت بگیرد.**: همانطور که معیارها و چک لیست DoD را تعیین می کنید ، مطمئن شوید که فقط از جنبه های فنی عقب نشینی کرده و در مورد کل محصول فکر می کنید.با ذینفعان یا صاحب پروژه صحبت کنید و بپرسید آیا مسائل دیگری وجود دارد که مانع از "افزایش" واقعی این پیشرفت می شود و به آن فکر نمی کنید.برای تعریف انجام شده مالک محصول به عنوان اولین فردی که دارد تعریف میکند باید در دسترس بودن و دلیل تعریف آن ها مشخص باشد اصل شفافیت و واضح بودن و طبق لیست همه باید متوجه اینکه چرا یک فیچر توسعه اش متوقف شده و یا چرا دارد به سرعت پیشرفت میکند مشخص باشد.روی لیست معیارها وسواس نداشته باشید:پیشتر ، ما تعریف انجام شده را "درک مشترک" بین تیم توسعه و مالک محصول نامیده بودیم. اما تعداد زیادی از موارد DoD باعث جلب توجه تیم شما می شود. آنها عوامل مختلف زیادی را در ذهن خود دارند که منجر به یکی از دو نتیجه می شود:o آنها فقط بر روی زیرمجموعه کوچکی از موارد DoD کار خواهند کردo آنها سعی می کنند همه کارها را انجام دهند (و به احتمال زیاد شکست می خورند)یک قاعده کلی خوب این است که تعریف خود را از انجام شده به عنوان حداقل کار مورد نیاز برای برآوردن سطح کیفی مورد توافق در نظر بگیرید.معنی کلمه "حق" ممکن است در طول زمان تغییر کند. این بدان معناست که شما باید تعریف خود را از انجام شده در طول زمان مدیریت کرده و آن را مرور کنید تا ببینید آیا می توانید معیارهایی را حذف کنید.**: در نهایت ، انجام شده همیشه بهتر از کامل است.اطمینان حاصل کنید که هر وظیفه فردی معیارهای پذیرش خاص خود را داردتقریباً در همه موارد ، تعریف انجام شده باید توسط کل تیم اسکرام تعیین شود. در Agile ، تیم شما تنها مسئول تبدیل مطالب عقب افتاده محصول شما به نرم افزارهای اسپرینت و قابل استفاده است.با این حال ، مشکل این است که بیش از حد روی کار موردنظر تمرکز کنید و اهداف ، نیازها و قراردادهای بزرگتر شرکت خود را فراموش کنید. گاهی اوقات باید تعریف انجام شده را بر اساس ارزشها و اصول اصلی شما بررسی کنید تا مطمئن شوید که هیچ مسأله آشکاری از قلم نمی افتد.یکی از بهترین ویژگی های Agile این است که به سرعت تیم و محصول اجازه می دهد تا با نیازهای کاربر سازگار شوند. با این حال ، چیزی که به راحتی تغییر نمی کند ، چیزی است که "انجام شده" تلقی می شود.ممکن است اگر تعریف های چک لیست را تغییر دهید در تیم سردرگمی و اتفاقا بدیهی فنی ایجاد کنید ولی اگر نیاز بود یک عامل مهم را تغییر دهید چه؟هیچ زمان مشخصی برای ایجاد این چنین تغییرات وجود ندارد ولی در راهنمای اسکرام این گونه میگوید:"در صورت لزوم در طول هر Sprint Retrospective ، تیم Scrum راه هایی را برای افزایش کیفیت محصول و یا بهبود فرایندهای کاری با اقتباس از تعریف" انجام شده "برنامه ریزی می کند ، که در تضاد با استانداردهای محصول یا سازمان نیست."یک قاعده خوب این است که در بحث حین انجام کارآماده هرگونه تغییر باشید که میتواند درمرحله برنامه ریزی انجام کار یا در پیش از شروع باشد.یک دلیل نهایی وجود دارد که باید به تعریف "انجام شده" اهمیت دهید: این باعث ایجاد اعتماد در تیم و کل سازمان می شود. ایجاد یک دیدگاه مشترک ، باز و صادقانه در مورد ظاهر نرم افزار با کیفیت ، همه را در یک جبهه قرار می دهد و از دردسر شنیدن بهانه های مختلف جلوگیری می کند "اما من فکر کردم ما در حال ساخت [X] هستیم!" Samira Amiri Samira Amiri Fri, 20 Aug 2021 18:58:22 +0430 https://virgool.io/@samiraamiri227/%D8%AA%D8%A7%D8%AB%DB%8C%D8%B1-%D8%AF%D8%B3%D8%AA%DA%AF%D8%A7%D9%87-%D9%87%D8%A7%DB%8C-%D9%85%D9%88%D8%B3%DB%8C%D9%82%DB%8C-%D8%A7%D8%B5%DB%8C%D9%84-%D9%88-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7-%D8%A2%D9%86-%D8%A8%D8%A7-%D8%AD%D8%A7%D9%84%D8%A7%D8%AA-%D8%B1%D9%88%D8%A7%D9%86%DB%8C-q6ruzt43nrmc به بهانه روز روانشناس تصمیم گرفتم مطلبی بنویسم تلفیقی از علم موسیقی و روانشناسی خودم حدود سه سال هست که دارم سعی میکنم با تلفیق این دو شاخه به زندگی خودم انرژی بدم و از تنش های اون تاحدی در پایان روز کم کنم؛ میتونم هم ادعا کنم که تا حدی موفق بودم و ساعتی هایی غرق در پادکست های روانشناسی و بعد پرداختن به تمرین های موسیقی من رو از دنیای شغلی، زندگی روزمره دور میکنه ولی مدتی است که به زیاده خواهی در هر دوشاخه رسیدم یعنی دیگه الان نمیتونم نگاه صرفا کاهش تنش های روزانه داشته باشم و دوست دارم اطلاعات بیشتری کسب کنم و حتی به عنوان یک حرفه بهش نگاه کنم که البته هنوز خیلی راه تا رسیدن به این مرحله پیش رو دارم ولی در حد بضاعت زمانی که دارم تصمیم گرفتم گه گداری به جستارهایی این چنینی بپردازم.یکی از موضوعات جذابی که امروز دیدم بیان حالات روانی با کمک دستگاه های موسیقی بود که وقتی داشتم مطالعه میکردم بهش پی بردم چقدر من این حالت ها رو موقع نواختن درک میکنم و تو خودم پر رنگه چه ارتباط نزدیکی میگیرم با ساز. گاهی دستم به تمرین هایی که استادم داده نمیره و همیشه برام سوال بود چرا وقتی این مطلب رو خوندم شاید کمی برام واضح تر شد اینکه چرا یک دفعه ترغیب میشم برم از تمرین های قدیمی ترم که ممکنه تو دستگاه های دیگه باشه بزنم مثلا موقعی که حالم خوش نیست یا دوست دارم یک حس درونگراییم رو نشون بدم و به نوعی شاید شاکی باشم میرم سراغ دشتی (البته الان بیشتر به این مورد رسیدم) قبلا فکر میکردم چون بهتر بلدم بزنم میرم سراغش. ولی الان میفهمم به دلیل جذابیتی و یک جور تخلیه انرژی که ازم اتفاق می افته میرم سراغش و خسته ام نمیکنه چون دارم خودم رو میسازم مثل یک مواد مخدری هست که داره با هر بار زخمه روی سیم ها بهم تزریق میشه و سبک تر میشم و رهاتر گاهی سرشار از احساساتی هستم که نمیتونم بیان (که البته خیلی الان خوشبختم چون دستگاهی که دارم آموزش میبینم دقیقا اصفهان هست) میرم سراغ اصفهان. وقتی روزهای پر از تنش و تصمیم سازی و شاید کنار اومدن و اندیشیدن به اشتباهاتی که تا الان داشتم فکر میکنم آخرش رو با شور تموم میکنم. حالا برای اینکه کنجکاوی کم کنم براتون دستگاه ها و حالات روانی همین پایین تیتر وار و خلاصه میارم اگر خواستید بیشتر بدونید جستجو گوگل اولین راهنما شما میشه که میبرتون به کلی مقاله و کتاب هایی مرتبط من خودم تا الان فقط دوتا مقاله فرصت کردم بخونم ولی چون هنوز باید مطالعه بیشتری بکنم الان منتشر نمیکنم.1-دستگاه شور: آگاهی- درک- تفکر و اندیشه۲-آواز دشتی: سوز و گداز- گریه و مویه۳-آواز ابوعطا: گله وشکایت۴-آواز افشاری: افسوس و حسرت- هجران از معشوق۵-آواز بیات ترک: تعلیم- شادی درون۶-دستگاه همایون: متانت- سربلندی- نصیحت و پذیرش۷-آواز بیات اصفهان: اوج احساس۸-دستگاه سه گاه: بزم و شادمانی- شور و شوق۹-دستگاه چهارگاه: ستیز و جنگ، حتی رو در روی معشوق- مقاومت و پیروزی- تلاش در رسیدن به آرزوهای دیرین عاشقی۱۰-دستگاه ماهور: رویا پردازی- پرش از قله شادی به همراه ذهنی رویایی- آرزو۱۱-دستگاه نوا: رازداری- حکایت۱۲-دستگاه راست و پنجگاه: ستایش معبود (خدا)- بزرگمندی و تعریف آواز اصفهان Samira Amiri Samira Amiri Fri, 30 Apr 2021 15:40:13 +0430