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

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

اپیزود اول:

وقتی مشتری درخواست جدیدی می‌دهد، دست و دل ما می‌لرزد که نکند انجام این تغییرات، به جاهای دیگر سیستم هم گند بزند! چون سیستم بزرگ و پیچیده‌ای داریم، می‌ترسیم اینجا را تغییر دهیم و جای دیگری خراب شود و نفهمیم که خراب شده! یا وقتی بفهمیم که خیلی دیر شده! تا می‌آییم یک باگ را رفع کنیم، ۱۰ باگ دیگر ایجاد می‌شود! روحیه و انرژی تیم پایین آمده و جرات تغییر و دست زدن به کدهای قدیمی را نداریم!

اپیزود دوم:

همکارم رضا، هر روز باید قابلیت‌های جدید نرم‌افزار را دستی تست کند و مطمن شود که برای قابلیت‌های قبلی نرم افزار مشکلی به وجود نیامده است. کار هر روزش شده از این فرم به آن فرم رفتن، ورود اطلاعات تستی و کلیک پشت کلیک. کاری تکراری، وقت‌گیر و خسته کننده! ما هم باید ساعت‌ها منتظر بمانیم که کارش تمام شود و یک تایید (نه چندان دقیق)‌ بدهد تا نسخه را منتشر کنیم! نرم‌افزار که بزرگتر می‌شود، تست‌ کردنش هم سخت‌تر و خسته کننده‌تر می‌شود! از شما چه پنهان، از رضا شنیده‌ام که دنبال یک موقعیت شغلی بهتر می‌گردد.

اپیزود سوم:

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

اپیزودهای چهارم، پنجم و . را می‌توانید حدس بزنید. شرایطی مشابه و آشنا و البته ناخوشایند و طاقت فرسا.

مجموعه وبینارهای تست خودکار نرم افزار، از آغاز تا انجام» با این هدف ارایه می‌شوند تا موضوع تست خودکار نه تنها به عنوان یک مهارت بلکه به عنوان یک هنر، در تیم‌ها جدی گرفته شود. تست نوشتن با تستِ خوب نوشتن، متفاوت است. در قسمت اول به موضوع Unit Test پرداخته می‌شود.

تاریخ برگزاری: جمعه، 21 اردیبهشت، ساعت 15

کسب اطلاعات بیشتر و ثبت نام:

https://evand.com/events/softwaretesting

ناهید توسعه‌دهنده توانمندی است و در مدت حضورش در تیم، چالش‌های زیادی را در حوزه طراحی و توسعه محصول، با راهکارهای خلاقانه و سخت‌کوشی فراوان، حل کرده و به این ترتیب شایستگی خود را به عنوان یک توسعه‌دهنده‌ی ماهر، به اثبات رسانده است. مدتی بعد Team Leader  تیم‌شان از شرکت می‌رود. مدیران با توجه به عملکرد رضایت بخش ناهید تصمیم می‌گیرند که او را به عنوان Team Leader جدید معرفی کنند.

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

ماجرا از این قرار است که در علوم مدیریت منابع انسانی اصلی هست به نام اصل پیتر. این اصل به طور ساده می‌گوید:
در محیط‌های سازمانی، برای ارتقاء کارکنان به یک موقعیت جدید، به جای اینکه توانمندی‌ها و شایستگی‌های آنها برای فعالیت در موقعیت جدید سنجیده شود، به توانمندی‌ها و دستاوردهای آن‌ها در موقعیت قبلی توجه می‌شود.

به این ترتیب کارکنان در سازمان‌ها تا حدی پیشرفت می‌کنند که دیگر کفایت ایفای نقش در سطحی بالاتر را نداشته باشند. دکتر لارنس پیتر، اصل پیتر را در کتابی به همین نام مطرح می‌کند و تاکید می‌کند که موقعیت‌های شغلی در سلسله مراتب سازمانی در نهایت توسط کارمندانی پر می‌شود که برای ایفای وظایف مرتبط با آن موقعیت ناکارآمد هستند.

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

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

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