بیانیه‌ی توسعه چابک نرم‌افزار و ارزش‌های مطرح در آن

1. Individuals and interactions over processes and tools.

در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن به «افراد و تعاملات آنها» نسبت به «فرآیندها و ابزارها» ارزش و اهمیت بیشتری داده می‌شود.
به بیانی دیگر اگر در سازمان یا تیمی ناهنجاری‌ و مشکلاتی در رفتار افراد و تعاملات آنها وجود داشته باشد، تاکید و پافشاری در اجرای فرآیند یا استفاده از ابزاری خاص (هر چند مدرن) کمکی به چابک‌تر شدن نمی‌کند. برعکس، از میان تیمی که حال خوب و تعاملات مناسب دارند، ابزار و فرآیندهای مناسب هم پدیدار می‌شوند.
لذا ابزارها و فرآیندها بایستی در خدمت بهبود و بهینگی تعاملات افراد باشند.

2. Working software over comprehensive documentation

در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن به «نرم‌افزار در حال کار» نسبت به «مستندات مبسوط و جامع» ارزش و اهمیت بیشتری داده می‌شود.
به بیانی دیگر اگر سازمان یا تیمی در تحویل مرتب و منظم نرم‌افزار کاربردی، دچار مشکل باشد، تلاش برای تهیه مستندات جامع و مبسوط هم احتمالا کمکی به چابک‌تر شدن آنها نمی‌کند. مستنداتی ارزشمندند که بتوانند تحویل منظم و زود به زود نرم‌افزارِ در حال کار را تسهیل کنند.

3. Customer collaboration over contract negotiation

در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن به «مشارکت مشتریان» به نسبت «مذاکرات قراردادی» ارزش و بهای بیشتری داده می‌شود.
به بیانی دیگر اگر سازمان یا تیمی، سازوکار مناسبی برای جلب مشارکت فعالانه‌ی مشتری در فرآیند تولید محصول نداشته باشد، تلاش برای تنظیم یک قرارداد دقیق هم فایده‌ای نخواهد داشت.
لذا مذاکرات قراردادی باید به نحوی دنبال شوند که مشارکت فعالانه‌ی مشتری در فرآیند تولید محصول را ممکن و بلکه الزامی کنند. مذاکرات و توافقات حاصله، نباید باعث تضعیف این رکن اساسی از قرارداد گردند.

4. Responding to change over following a plan

در بیانیه‌ی توسعه‌ی چابک نرم‌افزار گفته شده روشی که چابک‌کاران در توسعه‌ی نرم‌افزار پیش می‌گیرند، روشی است که در آن «پاسخ‌گویی به تغییرات» از ارزش و اهمیت بیشتری به نسبت «پیروی از یک برنامه‌ی معین» برخوردار است.
به بیانی دیگر اگر سازمان یا تیمی، در پاسخ به تغییراتِ اثرگذار بر ویژگی‌های محصول، مشکلاتی داشته باشد و نتواند به موقع واکنش مناسب نشان دهد، اجرای مو به موی یک برنامه‌ی از پیش تعیین شده‌ هم احتمالا فایده‌ای نخواهد داشت.
لذا برنامه‌‌ها و برنامه‌ریزی‌ها باید به نحوی باشند وقوع تغییرات را حتمی دانسته و قابلیت پاسخ سریع نسبت به آنها را فراهم کنند.

چه ارتباطی بین تاکیدات Domain Driven Design و اصول چابکی وجود دارد و چرا آشنایی با DDD برای تیم‌های چابک مفید است؟

قبل از پاسخ به این سوال مختصرا توضیح می‌دهم که DDD رویکردی برای طراحی و مدل سازی دامین‌های پیچیده است. دامین‌هایی که نیازمندی‌ها در ابتدای پروژه شفاف نیستند و به مرور و به واسطه‌ی کسب آموخته‌های جدید، کشف و ظاهر می‌شوند.
هر چند در سالیان اخیر، توسعه به سبک چابک در بین توسعه دهندگان نرم افزار از اقبال بیشتری برخوردار شده است، اما کمتر دیده‌ام که مفاهیم و اصولی که می‌توانند به یک تیم اجایل قدرت بیشتری بدهند، به اندازه کافی مورد بررسی و توجه قرار بگیرند و این باعث می‌شود که متدولوژی‌های چابک، به تدریج ناکارآمد جلوه کنند و به یک شیر بی یال و دم تبدیل شوند.
استفاده از پیشنهادهای Domain Driven Design  در مدل‌سازی و توسعه محصول در دامین های پیچیده، از موضوعاتی است که می‌تواند یک تیم اجایل را اجایل‌تر کند و به تقویت میزان پایداری به اصول و شاخص‌های چابکی در تیم، بیانجامد. ولی چگونه؟ فرهنگ و زمینه‌های فکری چابکی، با فضای فکری DDD چه خویشاوندی دارند؟ ارتباط آنها چیست؟

شباهت‌ها و تفاوت‌های چابکی و مدیریت ذره بینی

امروزه "مدیریت ذره بینی" به شیوه ای از مدیریت تبدیل شده که فریاد خیلی ها را به آسمان بلند کرده و از آن گریزانند. اگر نمی دانید مدیریت ذره بینی چیست این جا را بخوانید اما به طور خلاصه این سبکی از مدیریت است که مدیر، نظارت و کنترل دقیق و موشکافانه‌ای بر عملکرد کارمندان و مجموعه‌ی تحت مدیریت خود دارد. معمولاً هم مدیریت ذره بینی و چابکی را دو سر متضاد یک طیف می‌دانند و معتقدند که این دو سبک مدیریت در تضاد با هم قرار دارند. اما در واقع این دو سبک مدیریت بسیار بیشتر از آنچه که به نظر می‌رسد، خویشاوند و نزدیک‌اند. 

اصل پنجم بیانیه‌ی چابک: در ستایش حمایت و اعتماد

پنجمین اصل بیانیه‌ی چابک می‌گوید:

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

"پروژه ها را با محوریت افراد با انگیزه بنا کنید. محیط را برای آنها فراهم کنید، حمایت‌شان کنید و اطمینان داشته باشید که کار را به سرانجام می‌رسانند."

بیایید کمی درباره‌ی این اصل تامل کنیم! 

بند اول بیانیه چابک

بند اول بیانیه چابک بیان می کند که افراد و تعاملات آنها به نسبت ابزارها و فرآیندها از ارزش و اهمیت بیشتری برخوردارند.

“Individuals and interactions” over processes and tools.

برداشت من از این بند بیانیه:

1. قبل از اینکه تصمیم بگیریم فرآیند را تصحیح کنیم یا تغییر دهیم، به بررسی این بپردازیم که تعاملات اعضای تیم به چه شکل است و آیا این تعاملات/ارتباطات/همکاری‌ها به نحو مطلوبی در جریان است یا خیر؟ ذره بین مدیران باید روی افراد، انگیزه‌ها و محرک‌های ایشان، مهارت‌های کار تیمی و مطالعه الگوی ارتباط بین آنها قرار بگیرد.
2. باور من این است که تا پیش از اینکه مطمئن شویم که کار تیمی را آموخته و قواعد آن را بلدیم و پایند آنیم، استفاده از فرآیندهای چابک و ابزارهای مدرن، دردی دوا نمی‌کند، بلکه بر پیچیدگی‌ها می‌افزاید.
3. باید تیم بسازیم. حق انتخاب ابزار و فرآیند و مسئولیت استفاده از آن را می‌شود به تیم واگذار کرد.

مرجع: http://agilemanifesto.org/

تاملی درباره‌ی ارزش‌های مطرح در متدلوژی XP - قسمت اول

 متدلوژی XP عضوی از خانواده‌ی متدلوژی‌های توسعه‌ی چابک نرم‌افزار[1] است که در سال 1999 توسط Kent Beck معرفی شد. هدف از ارائه این متدلوژی افزایش کیفیت نرم افزار و افزایش توان پاسخ‌گویی به تغییرات مستمر نیازمندی‌های مشتریان عنوان شده است. این متدلوژی مانند سایر متدلوژی‌های چابک، از انتشارهای زود به زود استقبال می‌کند و توصیه می‌کند تا توسعه محصول به چرخه‌های کوچکتری از فعالیت توسعه شکسته شود. این کار باعث می‌شود تا بهره‌وریِ فعالیتِ توسعه، بهبود یابد و برای تیم توسعه فرصتی پدید آید تا مسیر خود را با نیازمندی‌های در حال تغییر و تکمیل مشتریان منطبق کند.

متدلوژی XP پنج موضوع را به عنوان ارزش[2] به رسمیت می‌شناسد[3].

این ارزش‌ها عبارتند از:

• ارتباطات[4]
• میل به سادگی[5]
• دریافت بازخورد[6]
• داشتن شجاعت[7]
• رعایت احترام[8]