عامل ۷-سرویس‌ها را از طریق اتصال به پورت (port binding) در اختیار استفاده‌کنندگان بیرونی‌ قرار دهید
[ مترجم؛ برگردان Port به فارسی درگاه است ولی در این متن همان واژ‌ه‌ی پورت استفاده شده است.]

گاهی برنامه‌های وب در داخل یک کانتینر سرویس‌دهنده‌ وب (web-server container) اجرا می‌شوند. برای مثال، برنامه‌های PHP می‌توانند به عنوان یک ماژول داخل apache HTTPD اجرا شوند یا برنامه‌های جاوا می‌توانند داخل Tomcat اجرا شوند.

برنامه‌های ۱۲ عاملی کاملا خودکفا و بی‌نیاز از کانتینر سرویس‌دهنده‌های وب هستند (self-contained). آنها برای ایجاد سرویسی که در محیط اجرا از طریق وب در دسترس باشد (web-facing service) نیازی به سرویس‌دهنده وب (web server) که در زمان اجرا در اختیار آن قرار گیرد ندارند. برنامه وب ۱۲ عاملی، HTTP را به کمک اتصال به پورت (Port Binding) به‌ عنوان یک سرویس در اختیار استفاده‌کنندگان بیرونی قرار می‌دهد و سپس منتظر دریافت درخواست‌هایی می‌ماند که روی آن پورت ارسال می‌شوند.
[مترجم؛ در متن اصلی از واژه‌ی Runtime Injection برای فراهم کردن سرویس‌دهنده وب مورد نیاز برنامه استفاده شده است]

در محیط توسعه شخصی (local development environment)، توسعه‌دهندگان برای دسترسی به سرویسی که توسط برنامه‌ در اختیار استفاده‌کنندگان بیرونی قرار گرفته فقط به سراغ آدرسی شبیه به ‘http://localhost:5000/’ می‌روند. اما در محیط استقرار، یک لایه مسیریابی (routing layer) وظیفه‌ی هدایت درخواست‌های دریافتی روی یک نام میزبان عمومی (public-facing hostname) به برنامه را بر عهده می‌گیرد. ارتباط لایه‌ مسیریابی با برنامه توسط پورت مذکور برقرار می‌گردد.

معمولا برای پیاده‌سازی این ویژگی از اعلان وابستگی (dependency declaration) برای اضافه کردن سرویس‌دهنده‌ی وب به برنامه استفاده می‌شود. [برای اطلاعات بیشتر رجوع کنید به عامل دوم در برنامه‌های ۱۲ عاملی یعنی وابستگی‌ها؛ مترجم]
HTTP تنها سرویسی نیست که می‌توان به کمک اتصال به پورت در اختیار استفاده‌کنندگان قرار داد. تقریباً همه‌ی نرم‌افزارهای سرویس‌دهنده‌‌ (server software) می‌تواند به کمک اتصال به پورت و سپس انتظار و پاسخ به درخواست‌های دریافتی اجرا شوند. به عنوان مثال می‌توان به Redis یا Remote Dictionary Server اشاره کرد.
توجه داشته باشید که روش اتصال به پورت به این معناست که یک برنامه می‌تواند تبدیل به یک سرویس کمکی (backing service) برای سایر برنامه‌‌ها شود. برای این کار آدرس (URL) ارائه‌شده توسط برنامه‌‌ در قالب یک منبع (Resource Handle) در پیکربندی (config) برنامه‌‌ای که می‌خواهد از آن استفاده کند قرار داده می‌شود.

نوشته‌های قبلی:
قسمت هفتم: پردازش

مترجم: حمید آقای خاتمی

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

عامل ۶: پردازش‌ها (process)

برنامه را به صورت یک یا چند پردازش بدون حالت (stateless processes) اجرا کنید.

برنامه‌ها در محیط اجرا به صورت یک یا چند پردازش اجرا می‌شود.

در ساده‌ترین حالت، کد برنامه شامل چندین خط است که با یک زبان برنامه‌نویسی نوشته شد و به تنهایی و بدون نیاز به اجزای خارجی می‌تواند اجرا شود؛ محیط اجرای برنامه نیز لپ‌تاپ توسعه‌دهنده‌ای است که محیط اجرای آن زبان روی آن آماده ‌شده است؛ پردازش (Process) هم با نوشتن دستور در خط فرمان(command line) اجرا می‌شود. به عنوان مثال با نوشتن دستور python my_script.pyُ پایتون برنامه‌ی شما را با ایجاد یک پردازش جدید در کامپیوتر اجرا خواهد کرد. از سوی دیگر، استقرار یک برنامه‌ی پیچیده در محیط عملیاتی ممکن است به چندین نوع پردازش‌ نیاز داشته باشد. توجه داشته باشید که از هریک از انواع می‌تواند چندین نسخه در حال اجرا وجود داشته باشد .

پردازش‌های دوازده عاملی بدون حالت (Stateless) هستند و هیچ چیزی را با دیگران به اشتراک نمی‌گذارند (Share Nothing). اگر داده‌ای نیاز به ثبت و نگهداری داشته باشد،‌ باید آن را در یک سرویس کمکی (backing service) که دارای حالت است (stateful) ذخیره کرد. این سرویس کمکی معمولاً یک پایگاه داده (database) است.

توضیح تکمیلی از سایت ردهت (اینجا):
اصل پردازش‌ها که بهتر است آن را پردازش‌های بدون حالت (Stateless Processes) نامید، ادعا می‌کند برنامه‌ی ۱۲ عاملی باید به صورت مجموعه‌ای از پردازش‌های بدون حالت اجرا شود. این بدان معناست که هیچ پردازشی خبری از وضعیت پردازش‌‌های دیگر ندارد و به هیچ اطلاعاتی از سایر پردازش‌ها مانند وضعیت نشست (session state) یا وضعیت گردش‌کار (workflow state) دسترسی ندارد و آنها را دنبال نمی‌کند.
وجود پردازش‌های بدون حالت، مقیاس‌پذیری (scaling) را آسان‌تر می‌کنند. اگر پردازشی بدون حالت باشد می‌توان در هر لحظه، تعداد نسخه‌های در حال اجرای آن را اضافه یا حذف کرد و به کمک آن بار (load) روی سیستم را مدیریت کرد. از آنجایی که هر پردازش مستقل از بقیه کار می‌کند، بدون حالت بودن کمک می‌کند تا از وقوع پیامدهای ناخواسته جلوگیری شود.

نوشته‌های قبلی:
قسمت ششم: ساخت، انتشار و اجرا

مترجم: حمید آقای خاتمی

گزیده:
هرگز به آینده اجازه نده که مزاحم امروز تو شود. تو با آینده، اگر مجبور باشی، با همان سلاح عقلانیتی که امروز سپر توست رو به رو خواهی شد.
مارکوس آئورلیوس

پیش‌گفتار:
مدتی است که با خود می‌اندیشم تجربیات‌م را در حوزه‌ی نرم‌افزار در اینجا بنویسم، هم ماندگار خواهد شد و هم شاید به دوستی کمک کند. نمی‌دانم “الگوی ایجاد نرم‌افزار” عبارت مناسبی هست یا نه، ولی تا یافتن عبارت مناسب‌تر از آن استفاده خواهم کرد.

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

منبع عکس: اینجا

داستان ناشناخته‌ها در برنامه‌نویسی
وقتی کاری را شروع می‌کنید که تجربه‌ای در آن ندارید و برای شما جدید و ناشناخته است، پا در راهی می‌گذارید که با اما و اگرهای فراوان همراه است.

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

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

نیازی به گفتن نیست که این تلاش بی‌نتیجه چگونه چون آج‌های سوهان تا کجا می‌تواند اعصاب و روان‌تان را ذره ذره براده‌برداری کند.

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

در مقام یک برنامه‌نویس چاره‌ای نیست جز پذیرش این بازی هزار تو ، کنار آمدن با آج‌های سوهان‌ش و تلاش برای یادگیری تکنیک‌های کسب پیروزی در آن.

از بازی لذت ببرید و برای پیروزی، سخت تلاش کنید!

گزیده:
ابتدا تلاش کنید کدتان کار کند، بعد تلاش کنید درست کار کند و سرانجام تلاش کنید سریع باشد. کنت بک

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

مقدمه‌ی مترجم (۲)

تجربه­ نشان می­دهد که استفاده از فناوری و دانش­ نوین اگر با آموزش و استفاده از مراجع معتبر همراه نباشد، به بیراهه خواهد رفت. تجربه­هایی چون شیءگرایی، UML و RUP در گذشته و متدهای Agile در چند سال اخیر، گواه این مطلب است و متأسفانه نمونه­های زیادی از این موارد وجود دارد. مدیرعامل یکی از شرکت­های بزرگ نرم­افزاری می‌گفت: «از تیمی خواستم تا برای پروژه­اش برنامه­ی بلندمدت­تری ارائه کند، مدیر تیم گفت: چون متدولوژی ما اسکرام است برنامه­ریزی بلندمدت نداریم! فقط کارهای یک ماه آینده [اسپرینت جاری] را برنامه­ریزی می­کنیم!». با چهره­ای متعجب از من پرسید: «آیا متدهای چابک واقعاً این گونه­اند؟!». پاسخ واضح است: خیر!

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

در این کتاب می‌توانید پاسخِ پرسش‌های مهمی را پیدا کنید که فقط هنگام استفاده از اسکرام برای شما مطرح خواهند شد: اجرای یک پروژه‌ی جدید بر اساس اسکرام شامل چند مرحله (فاز) است؟ نقش‌ها، فراورده‌‌ها و فعالیت‌های هر مرحله کدامند؟، چگونه متدهای چابک، پروژه‌‌ها‌ی بزرگ را (که شامل چندین سیستم هستند) مدیریت می‌کنند؟ چگونه می‌توان از اسکرام در شرکت‌های بزرگ که دارای چندین تیم توسعه هستند استفاده کرد؟ و آیا می‌توان در برنامه‌ریزی سالانه‌ی شرکت‌های نرم‌افزاری از متدهای چابک استفاده کرد؟

به جرأت می‌توان گفت شرکت‌هایی که برنامه‌ریزی را جدی می‌گیرند و دانش و مهارت انجام آن را دارند، انگشت‌شمارند. در حالی که در متدهای چابک نمی‌توان از برنامه‌ریزی به سادگی گذشت. همان‌طور که در جلد اول نیز گفته شد متدهای چابک بر دو نکته‌ی کلیدی تأکید می‌کنند: پیش‌بینی در ابتدای کار (Up-front Anticipation) و تطبیق به‌موقع (Just in time Adaptation) در میانه‌ی راه. اما اکثر شرکت‌ها و تیم‌های ما فقط «تطبیق» را انجام می‌دهند و آن هم نه تطبیق به‌موقع بلکه تطبیق موردی (Ad-hoc). در نتیجه فرهنگ مدیریتی کوتاه‌مدت و حتی مدیریت لحظه‌ای (موردی) و نداشتن برنامه‌ی میان‌مدت و بلندمدت، چالشی بسیار بزرگ و سدی محکم برای استفاده‌ی درست از متدهای چابک در کشورمان است. این کتاب، مرجع بسیار مفیدی برای برنامه‌ریزی میان‌مدت و بلندمدت در شرکت‌های نرم‌افزاری است.

تیم‌های توسعه‌ی نرم‌افزار معمولاً به نداشتن برنامه مشهورند! حکایت روابط نامناسب واحدهای PMO با تیم‌های توسعه، مثنوی هفتاد من است. واحدهای PMO با حمایت مدیران ارشد، تیم‌های توسعه را وادار می‌کنند تا برنامه‌های خود را در قالب‌های مرسوم مانند نمودار گانت‌ تهیه کنند و میزان پیشرفت کار را بر اساس آن گزارش کنند. مشاجرات، اتهام‌زنی و فرافکنی‌ها بخش ناخوشایندی از این مثنوی است. در یکی از شرکت‌ها، مدیرعامل از مدیرانش خواسته بود تا برنامه‌های خود را به واحد برنامه‌ریزی ارائه دهند. طبیعی بود که واحد توسعه‌ی محصول از همه‌ی واحدها عقب‌تر باشد! برای جبران این عقب‌ماندگی، ابتدا آموزش‌هایی بر اساس این کتاب به اعضای تیم داده شد و از آنها خواسته شد بر اساس رویکردهای برنامه‌ریزی انتشار (تاریخ‌ثابت و محدوده‌ثابت)، کارها را برنامه‌ریزی کنند و به واحد برنامه‌ریزی ارائه نمایند. بعد از مدتی که از اجرای برنامه‌ریزی انتشار گذشت، واحد توسعه‌ی محصول، بانظم‌ترین و دقیق‌ترین واحد در همکاری با واحد برنامه‌ریزی شد.

گزیده:

برای موفق شدن،
اشتیاق به پیروزی باید بیشتر از ترس از شکست باشد.

بیل کازبی

پیش‌گفتار:

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

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

گزارش یک Meetup:

اگر نخوام زیاد کشش بدم و از خلقت آدم و حوا شروع کنم! باید بگم که با استفاده از نرم افزار Meetup برای شرکت در نشست Software Craftsmanship (مهارت در نرم افزار) که توسط آقای Mark Seemann در شرکت NNIT برگزار میشد، اعلام آمادگی کردم و روز Meetup اونجا حاضر شدم.

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

در مورد مسیریابی تو شهر کپنهاگ تنها این نکته رو ذکر میکنم که با وجود یک نرم افزار کامل که تمام اطلاعات لحظه ای قطارها، اتوبوس ها و مترو و همین طور مختصات، مشخصات و نقشه مسیر پیاده روی و دوچرخه سواری رو به شما میده؛ اما شما باید به دروس ساختمان داده ها و طراحی الگوریتم اشراف کامل داشته باشید که ضمن محاسبه مسیر بهینه بتونید وزن (قیمت) مسیر رو هم با توجه به زونی [ناحیه‌ای] که در اون هستید در هر لحظه محاسبه کنید تا دچار جریمه ۷۵۰ کرونی نشید! من که یه خرده تو این دروس ضعیف هستم ترجیح دادم یه قسمتی از مسیر رو رکاب بزنم!

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

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

بگذریم. برسیم به اهم سخنان مارک سیمن متخصص معماری نرم افزار و برنامه نویس.
۱- نقل قولی از آقای مارتین فاولر به این مضمون:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
۲- فرضیه خوانایی کد رو مطرح شد. ” Code is read much more than written ” پس یه جوری بنویسید که راحت قابل خوانده شدن باشه. توصیه اکید بر کامنت گذاشتن در کدها داشتن!
۳- از نوشتن کدهای طولانی خودداری کنید. کدهای شما تا حد ممکن باید کوتاه باشند. برنامه‌های بلند را به کلاس ها، متدها و کدهای دیگر بگنجانید!
۴- از بازی تنیس بخاطر خاصیت رفت و برگشتی سریع به عتوان مدلی مناسب برای برنامه‌نویسی نام برد
۵- کدهایی بنویسید که مهربان و زیبا باشند!!
۶- از کدهای بد یا کثیف دوری کنید.
۷- عدم استفاده بیش از حد از حلقه‌ها و دستورات کنترلی و …
۸- لزوم رعایت اصول شی‌گرایی در برنامه‌نویسی مثل: تجرید، چسبندگی، وارونگی وابستگی، وارونگی کنترل، خودت را تکرار نکن و ….
۹- لزوم Refactoring و اصلاح مجدد کدها
۱۰- حتما برای کدهای خود تست بنویسید! (خنده ی حضار!!)
۱۱- لزوم استفاده از Source Code Control System
۱۲- حتما به زبان مورد علاقه خودتون برنامه نویسی کنید، با این حال از یادگرفتن زبان های دیگر غافل نشوید!

گزیده:
ندارد.

مترجم: مهندس علیرضا اسماعیلی

بخش اول
بخش دوم
بخش سوم
بخش چهارم
بخش پنجم
بخش ششم
بخش هفتم

۷-۲- بازنگری اسپرینت (Sprint Review)
در پایان اسپرینت، دو فعالیت دیگر از جنس بازرسی(inspect) و تطبیق (adapt) نیز انجام می‌شود. اولین فعالیت، بازنگری اسپرینت نامیده می‌شود.
هدف از این فعالیت، بازبینی و منطبق‌سازی محصولِ در حال ساخت است. نکته اساسی این فعالیت، گفت‌وگو و نشستی است که بین همه دست‌اندرکاران از جمله اعضای تیم اسکرام، ذینفعان، حامیان مالی، مشتریان و اعضای مدعو از سایر تیمها انجام می‌شود. موضوع اصلی این نشست، بازنگری ویژگی‌های کامل‌شده در اسپرینت است. هر یک از شرکت‌کنندگان تصویر روشنی از امور جاری به دست می‌آورد و به تیم کمک می‌کند تا مسیر توسعه آتی محصول را مطابق با انتظارات کسب‌وکار انتخاب کند.

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

۷-۳-بازاندیشی اسپرینت (Sprint Retrospective)
بازاندیشی اسپرینت، دومین فعالیت بازرسی و تطبیق در پایان اسپرینت است. این فعالیت اغلب پس از بازنگری اسپرینت جاری و پیش از برنامه‌ریزی اسپرینت (Sprint Planning) بعدی انجام می‌شود.

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

پس از پایان بازاندیشی اسپرینت، چرخه با برگزاری جلسه برنامه‌ریزی اسپرینت و تعیین باارزش‌ترین مجموعه کارهای قابل انجام، تکرار می‌شود.

گزیده:
من این راز را کشف کرد ه ام که فرد بعد از بالا رفتن از یک تپه بلند متوجه می شود تپه های زیادی برای بالا رفتن وجود دارد.
نلسون ماندلا

مترجم: مهندس علیرضا اسماعیلی

بخش اول
بخش دوم
بخش سوم
بخش چهارم
بخش پنجم
بخش ششم

۱-۵-اجرای اسپرینت(Sprint execution)
پس از برنامه­ریزی اسپرینت و توافق در مورد دستور کار اسپرینت جاری، تیم توسعه­ وظیفه­ها(Task) را با هدایت استاد اسکرام انجام می­دهد، با این هدف که ویژگی­ها به عنوان «انجام­شده»(Done) پذیرفته شوند. «انجام­شده» بدین معناست که کارهای لازم برای توسعه­ی یک ویژگی­ با کیفیت، با درجه­ی بالایی از اطمینان انجام شده است.

وظایفی که تیم انجام می­دهد، دقیقاً به ماهیت کار بستگی دارد. برای نمونه می­تواند کارهای صرفاً نرم­افزاری یا ترکیب آن با کارهای سخت­افزاری و حتی کارهای بازاریابی باشد.

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

۱-۶-اسکرام روزانه(Daily Scrum)
اعضای تیم توسعه، جلسه‌ی «اسکرام روزانه» را در هر روز از اسپرینت و ترجیحاً در یک زمان مشخص برگزار می‌نمایند که مدت آن ثابت و حداکثر ۱۵ دقیقه است. برای ترغیب به کاهش زمان جلسه، افراد آن را به صورت ایستاده برگزار می‌کنند و از این رو آن را «جلسه ایستاده روزانه»(Daily stand-up) نیز می­نامند.

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

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

اسکرام روزانه جلسه‌ای برای حل مشکلات نیست. در بسیاری از تیم‌ها گفت‌وگو درباره‌ی مشکلات پس از جلسه و در گروه‌هایی کوچک با حضور افراد علاقه‌مند به موضوع انجام می‌شود. اسکرام روزانه با جلسات مرسومِ گزارش وضعیت کار در پروژه‌ها متفاوت است؛ به‌ویژه جلساتی که اغلب به دعوت مدیر پروژه و برای به‌روزرسانی وضعیت پروژه برگزار می‌شود. با وجود این تفاوت، اسکرام روزانه نیز برای اطلاع‌رسانی وضعیت اقلام بک‌لاگ به اعضای تیم مفید است. اساساً اسکرام روزانه فعالیتی برای «بازرسیِ» برنامه­ریزی روزانه، ایجاد هماهنگی و تطبیق آن با شرایط جاری است که به تیم خودسازمانده(Self-organizing team) در انجام بهتر کارها کمک می‌کند.

اسکرام از تمثیل «خوک» و «مرغ» استفاده می­کند تا افراد شرکت‌کننده در اسکرام روزانه را به دو دسته تقسیم کند: دسته اول افرادی هستند که باید مشارکت و حضوری فعال داشته باشند (افراد اصلی) و دسته دوم افرادی که فقط می‌توانند شنونده باشند (افراد فرعی). حیوانات مزرعه از یک داستان قدیمی اقتباس شده‌اند: «خوک و مرغ تصمیم می‌گیرند تا شریکی رستورانی تأسیس کنند. مرغ پیشنهاد می‌کند که فهرست غذای آنها شامل ژامبون گوشت (سهم خوک) و تخم‌مرغ (سهم مرغ) باشد. خوک با این پیشنهاد مخالفت می‌کند، چرا که سهم آن دو در شراکت به یک اندازه نیست. خوک برای تهیه ژامبون گوشت باید از جانش (گوشتش) مایه بگذارد ولی مرغ نیازی ندارد که از جانش مایه بگذارد و فقط کافی است که تخم بگذارد.» در اینجا، «مرغ فقط مشارکت می‌کند، در حالی که خوک متعهد (Committed) است و باید از جانش مایه بگذارد». روشن است که کاربرد چنین تمثیلی در اسکرام، جداکردن افراد فرعی (مرغ‌ها) از افرادی اصلی (خوک‌ها) است که متعهد به تحقق اهداف اسپرینت هستند. در اسکرام روزانه، فقط خوک‌ها مجازند صحبت کنند و مرغ‌ها و افراد دیگر فقط به عنوان شنونده حضور دارند.

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

۱-۷-انجام‌شده (Done)
نتیجه‌ی هر اسپرینت بخشی از محصول است که بالقوه قابل عرضه است و بدین معناست که هر آن چه که قرار بود تیم اسکرام انجام دهد، بر اساس توافق صورت گرفته در مورد واژه‌ی «تعریف انجام‌شده» (Definition of Done)، واقعاً تمام شده است. این واژه درجه‌ی اطمینان از کیفیت و قابل عرضه بودن کارهای تمام‌شده را مشخص می‌کند. برای مثال واژه‌ی «انجام‌شده» در توسعه‌ی نرم‌افزار می‌تواند به معنای طراحی، ساخت، یکپارچه‌سازی، آزمایش و مستندسازی بخشی از محصول باشد.

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

لازم به یادآوری است که «قابل عرضه بودن» (Potentially shippable) بدین معنا نیست که آن‌چه ساخته شده، حتماً تحویل می‌شود. تصمیم درباره‌ی تحویل محصول، تصمیمی در سطح مدیران کسب‌وکار است که اغلب متأثر از موضوعاتی مانند موارد زیر است:

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

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

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

گزیده:
آن‌که انتظار دارد هر چهار فصل سال بهار باشد، نه خود را می‌شناسد، نه طبیعت را و نه زندگی را !
فرانسوا ولتر