جلسات برای تصمیمات است و این تصمیمات باید مستند شود.
- تصمیم باید مستند شوید و علاوه بر تصمیم اتخاذ ، اطلاعات اضافی زیر را نیز درج کنید یا به آن مراجعه کنید:
- دلایلی که تصمیم گرفته شد
- هر گزینه ای در نظر گرفته شده است
- هرگونه پیامدهای پذیرفته شده ناشی از تصمیم
- وقتی تصمیم گرفته شد
- به دنبال یک تصمیم ، آن باید تعریف شود که چه کسی باید در مورد تصمیم توسط زمان و به چه شکلی مطلع شود.
- تصمیمات مربوط به معماری نرم افزار باید در قالب تصمیم گیری در مورد معماری زیر (ADR) مستند شود.
وضعیت: [Draft, Proposed, Accepted, Deprecated, Superseded]
زمینه
توصیف ارزش خنثی از نیروهای بازی (تکنولوژیکی ، سیاسی ، اجتماعی و خاص پروژه)
تصمیم
تصمیم اتخاذ شده ، از جمله استدلال پشت آن.
طرف دیگر
هر گزینه دیگری که در نظر گرفته شده است ، از جمله دلایل رد آنها.
متفاوتی
اطلاعات اضافی مانند “ایجاد بر” ، “پذیرفته شده” ، …
- ADR باید تحت کنترل منبع قرار گیرد و در پروژه مربوطه در آن ذخیره شود
docپوشه - درخواست ها قوطی برای بحث و تأیید ADR استفاده کنید.
حتماً پست مایکل نیگارد را در مورد مستندسازی تصمیمات معماری بررسی کنید
تصمیمات در جلسات مکرر
برای جلسات مکرر ، من دوست دارم آنها را در یک سند بزرگ که حاوی دقایقی از جلسه است ، به DOS ، … فرمت تصمیم گیری ها شبیه به مورد برای DOS است ، ببینید.
مدیریت DOS در جلسات مکرر ، هنگامی که هیچ ابزار توافق نشده ای وجود ندارد.
- تصمیم-001 تصمیمات معماری باید تحت کنترل منبع قرار گیرد
- دلیل: تصمیمات را می توان در درخواست های کشش مورد بحث قرار داد ، تغییرات ردیابی می شوند ، تصمیمات به راحتی برای توسعه دهندگان و نزدیک به کد در دسترس است
- عواقب: دسترسی به خوانندگان مخزن محدود است
- گزینه های دیگر: تلاقی ، ویکی ، اسناد کلمه
- all-001 جان 2025-02-14: به همه معماران و توسعه دهندگان در مورد این تصمیم اطلاع دهید
- اگر هیچ ابزار ردیابی تصمیم گیری در سطح سازمان وجود ندارد ، قالب فوق قوطی استفاده شود
