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

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

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

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

گزیده:
«جلوگیری از تکرار تاریخ کاری بیهوده است زیرا شخصیت آدمی طوری است که اجتناب از تکرار را غیر ممکن می‌سازد.» مارک تواین

“Self-organizing teams can decide everything by themselves. So they don’t need an architect.” writes Samudra Kanankearachchi on the Software Architecture group of LinkedIn.

This feels to me like one of these strange agile koans. If you repeat it often and long enough, it will gradually become the truth.
Self-organizing teams have very little to do with the architecture of your system. Self-organizing teams are about: task allocation, collaboration, communication, accountability, … it may have to do with time-boxing and therefore what gets accomplished in a certain time-frame. Architecture is about making decisions (choices) about the structure, composition, organization of the software system. It also feels like “architect” is necessarily not a member of the team. Not my personal experience or recommendation. Architect is a role, not necessarily a person (whose only role is to be an architect, though these exist in large organizations.)

Most systems tackled by small agile teams have a pre-defined stable architecture. So yes, they do not need to have anyone playing the role of architect. For novel complex systems, where architectural decisions need to be made, if they are made “by the team”, it means that the team plays the role of architect, and hopefully they have the knowledge and experience to do so. Like some teams have a scrummaster and a product owner, such teams should have an architecture owner, who drives the discovery of architectural issues and their resolution. Because an architecture is not going to gradually emerge out of weekly refactorings (another agile koan), unless this emergence is guided somehow.
Philippe Kruchten

P.S.: Agile Architecture by Scott Ambler

Quote:
Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.
Dave Quick

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

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

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

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

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

چند وقت پیش خواسته شد تا در جلسات مصاحبه جذب یکی از پستهای کلیدی و مدیریتی یک شرکت حضور داشته باشم. يكي از بخشهايي كه به عهده‌ام گذاشته شده بود، موضوع متدولوژی بود.
از مصاحبه‌شونده پرسیده مي‌شد که به چه متدهایی آشنایی دارد و کمی از تجاربش را بیان کند. بعد کمی پرسشهایی جزئی‌تر پرسیده می‌شد تا مصاحبه‌شونده فرصت پیدا کند تا بینش، دانش و مهارت خود را شرح دهد.
یکی از نکاتی که خیلی برایم جالب بود نگاه مصاحبه‌شونده‌ها به متدهای چابک بود. خیلی از آنها متدهای چابک را به این دلیل می‌پسندیدند که «مستندسازی» ندارد! وقتی از آنها می‌خواستم که شرح دهند که چگونه تکنیک‌های چابک مثل بازسازی و توسعه آزمون‌ محور را در تیمهایشان اجرا می‌کردند، پاسخ‌ها ناامید کننده بود.
یاد این جمله از کتاب Balancing Agility and Discipline از بوهم و ترنر افتادم که خیلی شبیه اتفاق گفته شده بود:

eXtreme Programming expert Bob Martin said at the 2001 XP Universe conference that he ran into someone who said his organization was using XP. Martin asked him how the pair programming was viewed, and the reply was, “We don’t do that.” Martin asked how refactoring was working out, and the reply was, “We don’t do that.” Martin asked how well the planning game was working, and the reply was, “We don’t do that.” “Well,” Martin asked, “then what are you doing?” “We don’t document anything!” was the answer.

گزیده:

Poor management can increase software costs more rapidly than any other factor.
Barry Boehm

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

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

پرسش دشوار: اگر شما چند ماه وقت داشته باشید، چه می‌کنید؟

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

مقدمه:
ورود اغلب ما به رشته کامپیوتر به دلیل لذت بردن از موجود ناشناخته‌ای بود که روز به روز کاربردش وسیع‌تر می‌شد.
وقتی برنامه لذت نقاشی را می‌دیدم، واقعاً لذت می‌بردم. لذت از این که مجری برنامه چقدر از کارش لذت می‌برد و به زیبایی این لذت را به شما منتقل می‌کند. همان لحظه دوست داشتم که ابزار نقاشی را بردارم و شروع کنم به خلق دنیایی که دوست می‌داشتم.
وقتی موضوعِ علاقه و عشق درونی به ابزار معاش تبدیل می‌شود، یادتان می‌رود که قرار بوده از آن لذت ببرید. لذت بردن حلقه گم‌شده‌ای می‌شود که کم‌کم به فراموشی سپرده می‌شود، انگار هیچ وقت وجود نداشته است. دردسرهای امرار معاش نیز – مسائل متعدد تولید، استقرار و نگهداری نرم‌افزار، مشتریان، حقوق و جبران خدمات نیروی انسانی- این موضوع را روز به روز تشدید می‌کند.
موضوع اصلی:
از قدیم گفته‌اند که کوزه‌گر همیشه از کوزه شکسته آب می‌خورد! نرم‌افزار می‌نویسیم برای دیگران ولی خود از آن لذت نمی‌بریم!
چند وقت پیش یکی از نوجوانان فامیل گفت که برایم متن آهنگهای خارجی را دانلود کن تا به یادگیری زبان انگلیسی‌ام کمک کند. فلانی گفته است که این کار خیلی تأثیر دارد! به هر حال یکی از خدمات متخصصان کامپیوتر در خانواده، ارائه خدمات مهمی از این دست است هر چقدر سعی کردم که بقبولانم که سواد و تجربه‌ام به اندازه‌ای نیست که بتوانم این کار را انجام دهم، میسر نیفتاد! در نتیجه مجبور به ارائه خدمت شدم و آن هم خدمات رایگان. برای مفرح شدن موضوع، تصور کردم اگر قرار بود این مسأله را خودم حل کنم چگونه آن را انجام می‌دادم. راه حل باید سادگی لازم برای استفاده کاربر عادی و غیرمتخصص را می‌داشت و بدون حضورم قابل انجام می‌بود. به‌علاوه باید می‌توانست برای آهنگ‌هایی که نام و خواننده آنها نیز مشخص نبود، پاسخ‌گو باشد. مسیر انجام، نتیجه کار و لذت آن جالب‌تر از آنی بود که تصور می‌کردم.
پرسش دشوار: شما چه کارهایی در حوزه تخصصی خود انجام می‌دهید که از آن لذت می‌برید؟

پانوشت:
یکی از دوستان می‌گفت دلیل این که کوزه‌گر از کوزه شکسته آب می‌خورد، این است که کوزه‌های سالم را می‌فروشد!

گزیده:
غزلی در نتوانستن
از دست‌های گرمِ تو
کودکانِ توأمانِ آغوشِ خویش
سخن‌ها می‌توانم گفت
غمِ نان اگر بگذارد.

نغمه در نغمه درافکنده
ای مسیحِ مادر، ای خورشید!
از مهربانیِ بی‌دریغِ جانت
با چنگِ تمامی‌ناپذیرِ تو سرودها می‌توانم کرد
غمِ نان اگر بگذارد.

رنگ‌ها در رنگ‌ها دویده،
از رنگین‌کمانِ بهاریِ تو
که سراپرده در این باغِ خزان رسیده برافراشته است
نقش‌ها می‌تواند زد
غمِ نان اگر بگذارد.

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

احمد شاملو، ۱۳ دیِ ۱۳۴۳