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

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

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

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

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

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

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

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

“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

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

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

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

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