مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

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

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

بِث گفت: «به نظرم با این کار، تیکت‌های (Tickets) جیرا دارای اشکال‌اند و دیگه فایده‌ای ندارند».

«اگر افراد روی چیزهایی کار می‌کنند که توی جیرا نیست، پس دیگه نمی­‌تونیم به جیرا اعتماد کنیم.»

یوآخیم گفت: «پیشنهادی برای رفع این مشکل دارید؟» بث گفت: «خب! فکر می‌کنم اگه مطمئن باشیم که همه‌ی کارها توی جیرا ثبت شده، خود ابزار امکان مرتب‌سازی داره، درسته؟» و بعد ادامه داد «درنتیجه همه­‌ی کارها یک‌جا هستند و به ­آسانی می‌­تونیم اون‌ها را با افرادی که پیش ما نیستند، به اشتراک بزاریم.»

یوآخیم گفت: «حق با شماست. اما یک ابزار الکترونیکی هیچ ضعفی نداره؟»

اریک با عجله گفت: «نه جایی که من باشم.»

بث گفت: «آها…، اکثر کارها توی جیرا گم می‌­شه. در خیلی از موارد کار ما دوبرابر می‌شه. چون باید کلی وقت بذاریم تا کارها را توی جیرا پیدا کنیم.»

یوآخیم پرسید: «چه­‌طوری می‌­تونیم جستجو و پیدا کردن اقلام رو ساده­‌تر کنیم؟»

بث گفت: «خب! به‌نظرم باید کاری کنیم که همیشه جلوی چشم ما باشند. مثلاً روی دیوار بنویسیم.»

مارکوس که دیگر نمی‌توانست جلوی خودش را بگیرد، گفت: «کارها رو روی دیوار بچسبانید! عنوان هر کاری که مشغول انجامش هستید رو روی برگه‌ای بنویسید و روی دیوار بچسبونید. بعداً از تغییرات بزرگی که این کار کوچک در کارتان ایجاد می‌کنه تعجب می‌کنید.» مارکوس به تجربه فهمیده ­بود که این کار برای خیلی از سازمان­ها که توسعه‌ی چابک را تازه شروع کرده‌اند رخداد بزرگ و مهمی است.

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

بعد از یکی دو دقیقه یوآخیم پرسید: «تموم شد؟ لطفاً اون­ها رو روی تابلو بچسبونید.»

به شش برگه‌ی قبلی که از روی جیرا نوشته‌ شده بودند، هشت برگه‌ی جدید اضافه شد.

فرانک بعد از دیدن تابلو با صداي بلندگفت: «خدای من! نمی‌تونم باور کنم! این واقعیت داره؟»

بخش بعدی
بخش قبلی

گزیده:
ندارد

نوشته‌ای را در وب سایت “مدرسه‌ی کسب‌وکار لندن” (London Business School) خواندم که بسیار آموزنده بود.
عنوان نوشته این بود: سه دلیل برای توقف، تفکر و خوابیدن (three reasons to stop, think and sleep). بخشهایی از آن را در ادامه آورده‌ام. امیدوارم برای شما نیز آموزنده باشد.

Are you looking after your wellbeing? Richard Jolly shares why being mindful of three concepts could improve your work, and your life Why don’t we do the things we know we should be doing? It’s a question that Richard Jolly, Adjunct Professor of Organisational Behaviour at London Business School (LBS) asks executives daily.

“In our complex, technology-enabled lives, one of the hardest challenges is protecting our thinking time. Most executives are connected to their smartphones from the moment they wake up until they are lying in bed checking their emails at night. We need to regain our focus to succeed.”

Jolly calls for calm, mindful thinking time. To achieve that, consider three wellbeing concepts: stop, think and sleep.

1. Stop
You’re busy. …
“There’s a great phrase in Florida: ‘When you’re fighting off the alligators, it’s hard to remember you were trying to drain the swamp.’ We have become a generation of alligator fighters, so busy ‘doing’ that we struggle to focus on our key priorities.”

Jolly blames, in part, technology and a psychological condition he calls ‘technological arousal’: the idea that technology drives people to distraction. For example, posting photos on Instagram creates emotional, cognitive, or physiological arousal, but it also takes time and energy that could be allocated elsewhere. “We need to change our relationship with technology, we’ve become obsessed and addicted to it, so we’re on edge, in a state of heightened technological awareness,”

He puts it differently. Based on 10 years of executive interviews, he found that 95% of people suffer from ‘hurry sickness‘.

2. Think
The act of thinking is a lifestyle choice, and one that improves brain health.
When people are thinking, they often take their hands to their temples. It’s the place that generates people’s thoughts, feelings and movements. It’s also the home of ideas.
He suggests you carve out time to think. Not just in the shower, and not just for five minutes. “Figure out when you have your best ideas,” he says. “What time of the day is it? Is it before eating? Or after the gym? The time you have will only get more squeezed and the problems you need to solve will only get more complex, so you need to work out how to optimise your thinking time, now.”
Thinking time helps us survive, adapt and prosper. But no one can think without sleep.

3. Sleep
What’s good for the body is good for the brain, too. “We all need a good night’s sleep. But it’s hard to achieve,” he says.
If sleep increases productivity and happiness, and supports smarter decisions, why are people still bragging about their terrible sleep habits? Because bad sleep supports the outdated idea that if you’re busy, you’re important.

Jolly calls for senior executives to be role models of behaviour. “People aren’t really listening to what you say, but they are mimicking your behaviours. Role models have an infectious passion for their work and live according to their true beliefs.”

گزیده:
خوب بخوابید و خوب فکر کنید!

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

2-1-تابلو

«چه­‌طوری توی تیم می‌­فهمید که روی چی دارید کار می‌­کنید و چه‌طوری کارها توی تیم به گردش در میان؟ گردش‌کار (Workflow) شما چه‌طوریه؟». یوآخیم به سمت تابلو رفت و یک ماژیک بر­داشت.

سپس پرسید: «در حال حاضر بک­لاگ‌ها (Backlog) رو کجا نگه­ می‌­دارید؟ فکر کنم یه فهرستی از کارها باید داشته باشید.»

بِث خیلی سریع گفت: «البته که داریم.» یوآخیم و مارکوس حس کردند که این سوال به بِث برخورده و او احساس می‌کند به وی توهین شده است. «من همیشه کنترل می‌کنم که همه­‌ی نیازمندی­‌ها در جیرا (JIRA) ثبت و طبقه‌­بندی بشن. جیرا سیستم «ردگیری موضوعات» (Issue tracking) در پروژه ماست».

فرانک که احساس می­‌کرد سیستم ردگیری در وضعیت خوبی قرار دارد، گفت: «بله درسته. من هر وقت که فرصت کنم به جیرا سر می‌­زنم و سعی می­‌کنم ترتیب اقلام را با توجه به اولویت­­ها به­‌روز کنم».

سزار هم گفت: «با جیرا به راحتی می‌­شه دید که روی هر قلم چه کسی کار می‌کنه و کار هر قلم هم چقدر پیشرفت داشته».

مارکوس به لپ­‌تاپ دافنه اشاره کرد و پرسید: «الان می­‌تونیم به سیستم جیرای شما دسترسی داشته باشیم؟»

دافنه پاسخ داد «بله البته!» و با یک حرکت لپ­‌تاپش را باز کرد.

یوآخیم پیشنهاد کرد: «خوبه! لطفاً روی کاغذ بنویسید که هر کدوم از شما الان مشغول چه کاریه».

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

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

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

سزار، فرانک و بِث بلافاصله و هم­زمان پاسخ دادند: «بله». آدام و توسعه­‌دهنده‌­ها یعنی دافنه و فرانک به زمین خیره شدند و چیزی نگفتند.

مارکوس گفت: «الان موضوع ما، درست یا نادرست بودن این کارها نیست. چیزی که الان اهمیت داره اینه که تصویر درستی از وضعیت فعلی به دست بیاریم. کاری جا نمونده؟»

بعد از چند ثانیه آدام شروع به اعتراف کرد: «راستش این تصویر، تصویر کاملی نیست. ما کارهای زیادی انجام می­دیم که در جیرا ثبت نمی‌­شه».

یوآخیم پرسید: «چه کارهایی؟ می­‌تونی برامون مثال بزنی؟»

بخش بعدی
بخش قبلی

گزیده:

من تیم را مقدم بر هر چیزی می‌دانم و ابتدا به تیم فکر می‌کنم. این کار به من کمک می‌کند تا موفق بشوم، به تیمم هم کمک می‌کند تا موفق بشوند. لی‌بورن جیمز

The Product Owner is responsible for:

• Developing and maintaining a product vision and market strategy;
• Product management;
• Ordering and managing the Product Backlog;
• Involving stakeholders and end-users in Product Backlog refinement and backlog management;
• Alignment with other Product Owners when needed from an overall product, company or customer perspective

A Great Product Owner…

• Embraces, shares and socializes the product vision
• Exceeds the customer’s expectation
• Is empowered
• Orders the product backlog.
• Knows modeling techniques.
• Shares experiences.
• Owns user story mapping.
• Has a focus on functionality.
• Is knowledgeable
• Understands the business domain.
• Acts on different levels.
• Knows the 5 levels of Agile planning.
• Is available.
• Is able to say ‘no’.
• Acts as a “Mini-CEO”.
• Knows the different types of valid Product Backlog items.
• Takes Backlog Refinement seriously.

Reference: www.infoq.com

گزیده:

If we focus on profit over value to customers, we will obtain neither. If we focus on visible customer value over profit, we will profit.
Wikispeed Principle

مترجم‌ها: یاسر کازرونی، مریم معصومی‌راد

مارکوس گفت: «عالیه! اون طرف یه اتاق پیدا کردم که تابلو هم داره. یوآخیم، یادداشت­‌هات همراهته؟»

یوآخیم نگاهِ عاقل اندر سفیهی به او کرد و گفت: «بله! البته». او مربیِ متدهای چابک است؛ پس حتماً یادداشت‌­ها را همیشه همراهش دارد.

«عالیه، پس بیایید برویم.» مارکوس این جمله را گفت و راه افتاد.

وقتی به تابلو رسیدند و کنارش جمع شدند، یوآخیم پرسید: «کی می‌تونه به ما بگه که تیم‌تان چه‌کار می‌کنه؟»

سزار در حالی که لپ­‌تاپ رو در می‌آورد گفت: «اون نفر احتمالاً منم.»

اریک با ناراحتی فریاد زد: «نه! لطفاً اسلاید نه! به سزار بگید برای این کارا وقت نداریم.»

سزار با کمی دستپاچگی گفت: «بله، حق با شماست. اما این نسخه­‌ی خلاصه‌شده است.»

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

مارکوس پرسید: «چرا به کمک ما نیاز دارید؟» و درحالی‌­که منتظر پاسخ بود، شروع کرد به نوشتن عنوان چالش‌ها­ روی فلیپ­‌چارت^[۱].

فرانک، رهبر پروژه^[2] جلو آمد و گفت: «من می­‌تونم بخشی از این سؤال را جواب بدم. ما در هماهنگ کردن خودمان با سرعت مورد انتظار براي تحويل­دادنی­­‌ها مشکل داریم. تعداد زیادی شکایت از ذینفعان مختلف در سازمان دریافت کردیم که ویژگی­‌های درخواستی خودشون رو به موقع تحویل نگرفته‌اند.»

سزار گفت: «دقیقه به دقیقه وضع بدتر می‌شه. دیگه كسي به کیفیت كار ما اعتماد نداره و قطعاً به برآوردها و تاریخ‌های تحویل ما هم اعتماد ندارن.»

دافنه گفت: «برخی از ما در این تیم احساس می­‌کنیم که در باتلاقی از کارها گیر کردیم و نمی­‌دونیم چه کاری را باید اول انجام بدیم. تلاش برای راضی نگهداشتن همه باعث می­شه تندتند اولویت‌­ها تغییر کنه و همه­‌ی کارها بشه «اولویت شماره یک».»

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

فرانک که دیگر بی‌قرار شده بود گفت «خوب! بیایید برگردیم سرِکارمون. از کجا شروع کنیم؟»دافنه حرف بقیه را قطع کرد: «دست شما درد نکنه، فکر کنم بس باشه. زمان داره مي­گذره و می­‌دونید که فقط دو ساعت وقت داریم، درسته؟ بیایید کار مفیدی انجام بدیم.»

یوآخیم پاسخ داد: «درك مي­‌كنيم که شما دوست دارید زودتر شروع کنیم. ولی باید بفهمید که کانبان کمی با روش­های دیگه متفاوته. برای نمونه، اسکرام^[3] یا آر یو پی^[4] (از پیش) تعیین کرده‌اند که چه نقش‌­هایی^[5] در تیم وجود داشته ­باشه، چه جلسه­‌هایی برگزار بشه و حتی چگونه جلسه‌ها را برگزار کنید. ولی کانبان از جایی که هستید شروع می­‌کنه و کمک می­‌کنه تا وضعیت جاری خودتون رو بفهمید و قدم‌های بعدی رو برای بهبود شناسایی و تعیین کنید.»

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

یوآخیم پرسید: «راستی، اسم تیم­ شما چیه؟»

فرانک با یک لهجه‌ی کاملاً مکزیکی گفت: «از این به بعد تیم را صدا می‌کنیم: تیم کانبانِروسِ^[6] !». اعضای گروه ­خندیدند و مارکوس نام تیم را روی فلیپ‌­چارت نوشت.

یوآخیم شروع کرد: « بیایید با نمایش و گفتگو^[7] شروع کنیم تا کارمون کمی بیشتر تصویری^[8] بشه؛ همه موافق هستند؟»
بخش بعدی
بخش قبلی

[1] Flipchart [2] Project leader [3] Scrum [4]Rational Unified Process (RUP) [5] Role [6] Kanbaneros [7] Show-and-tell [8] Visual

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

گفتار:
۵ سال قبل بود که شروع کردم به نوشتن مقاله در Codeproject, بار اول که مقاله را فرستادم, یک جواب ناراحت کننده گرفتم : “این مقاله یک آشغال کد است”.

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

امروز سال ها از آن روز که کار تحقیقاتی کوچولویم با عنوان “آشغال” نام برده شده میگذرد. اگرچه روزی خبر از Codeproject میدادم و شما به من با تشویق هایتان دلگرمی میدادید, حالا اما خبر بزرگتری دارم.

نتایج تحقیقات ۳ سال گذشته را در قالب ۲ مقاله در زمینه استفاده از الگوریتم های یادگیری ماشین به کنفرانس کاربرد مهندسی در پزشکی و بیولوژی (EMBC) با قدمت ۳۸ ساله فرستادم. این کنفرانس که مهمترین کنفرانس در زمینه مهندسی در پزشکی در جهان است, هر ساله در کشور آمریکا برگزار میشود و پذیرای قشر متنوعی از محققان و پزشکان از دانشگاه های و مراکز تحقیقاتی از سراسر دنیاست.

ترسیدم که بگویند این ۲ تا آشغالت را بردار و برو پی کارت. اما میدانستم که آشغال ها را باید دوست داشت. گفتم اگر هم شکست خوردم, بر میگردم و تدارک میبینم و دوباره میفرستم. اما امشب نتایج بررسی ۳ ماهه مقالات آمد و هر ۲ مقاله در کمال نابوری ام پذیرفته شد.
میگویم میخواهم یک راز مهمی با شما در میان بگذارم. فقط هیس!! بیایید جلوتر. بیشتر…. بیشتر… ” آشغال ها بهترین دوستان ما هستند.. آشغال ها را دوست داشته باش! “.
گزیده:
«موفقیت یک نتیجه است نه یک هدف» گوستاو فلوبر

پیش‌گفتار

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

دوستان عزیزی که علاقه‌مند به حضور در این گروه هستند، می‌توانند به این آدرس مراجعه فرمایند: گروه تلگرامی نیازمندیها

گفتگوی تلگرامی

آقای قاقالو:

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

برای تحقق مورد کاربرد در سطح تحلیل چه کارهای باید انجام بدیم؟

من این کارها رو انجام میدم:

۱- یک مورد کاربرد انتخاب میکنم.

۲- سه نوع کلاس سطح تحلیل با کلیشه entity, boundary و control رو پیدا میکنم.

۳- رفتارها و صفات مربوط به هر کلاس سطح تحلیل رو شناسایی میکنم.

۴- روابط بین کلاس های سطح تحلیل رو مشخص میکنم.

نتیجه ۴ گام بالا میشه یک نمودار کلاس با سه نوع کلاس سطح تحلیل که صفات و رفتار هر یک شناسایی شده و روابط بین کلاس های سطح تحلیل نیز مشخص شده است.

نمودار کلاس روابط ساختاری و ایستای کلاس های مربوط به مورد کاربرد را مشخص میکنه.

۵- در این گام در صورت نیاز به مشخص کردن روابط پویایی بین نمونه های کلاس های سطح تحلیل اقدام به آماده کردن نمودار توالی میکنم.

۶- گام های بالا رو برای هر یک از موارد کاربرد تکرار میکنم.

۷- در گام آخر هم نمودار کلاس حاصل از تحقق هر مورد کاربرد را با هم ترکیب میکنم.

نتیجه کارم میشه یک نمودار کلاس سطح تحلیل مربوط به کل نرم افزارم که قرار است توسعه داده بشه

شما چطور عمل میکنید؟

مهرداد:

ضمن تشکر از آقای قاقالوی عزیز، اگر اجازه بفرمایید من هم نظرم را عرض کنم.

با گامهای دو به بعد برای تحلیل گر سیستم موافق نیستم.

اگر اشتباه نکنم در خود آر یو پی، این کار به تحلیلگر سیستم سپرده نشده است.

گام دو به بعد “فضای طراحی و تکنولوژی شی گرایی” دارد که لااقل در ایران تحلیل گران فاقد این مهارت هستند

آقای نوذری:

سلام وقت بخیر. من نظر آقای قاقالو رو قبول دارم. فقط باید به یک مساله مهم توجه کرد. همونطور که ایشون نوشتن، باید دقت شود که فعالیت های 2 به بعد “در سطح تحلیل” انجام شود. با توجه به اینکه تحلیل از نظر انتزاع سطحی بالاتر از طراحی دارد، اگر این دقت نظر انجام شود در فضای “طراحی” نخواهیم افتاد. موضوع یا نگرانی که استاد عزیزم مهندس مهرداد، با عنوان “فضای طراحی و تکنولوژی شی گرایی” اشاره فرمودن نگرانی به جایی هست. ولی مانع از انجام گام های 2 به بعد که جناب قاقالو ذکر کردن نخواهد شد. به نظر من باید نگرانی مهندس مهرداد رو صرفا با عبارت “جلوگیری از افتادن در فضای تکنولوژی” بیان کرد. چون (1) طراح کسی هست که Artifact تحلیلگر رو می گیره و روی اون تکنولوژی سوار می کنه و (2) تحلیل رو با رویکرد شیئ گرایی و در سطح بالایی از انتزاع هم میشه انجام داد.

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

موضوع یا توضیحی که باید به نوشته آقای قاقالو اضافه بشه این هست که با این مراحل ما داریم System Analysis رو انجام میدیم. ولی اگه بخوایم Business Analysis انجام بدیم اون وقت موضوع متفاوت خواهد بود.

آقای قاقالو:

اگر بخواهیم با دقت بیشتری به موضوع مطرح شده نگاه کنیم میبینیم که در RUP یک فعالیتی با نام use case analysis وجود داره و نقشی که مسول انجام این فعالیت هست Designer می باشد. در این فعالیت تقریبا تمام گام هایی که در بالا ذکر شد انجام میشه اما توسط طراح و نه تحلیلگر سیستم.

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

اساسا تحقق مورد کاربرد در سطح تحلیل که در فعالیت use case analysis انجام میشه وظیفه طراح هست و نه تحلیلگر سیستم. اما تحلیلگر سیستم میتونه نقش مثبت و موثری در این فعالیت داشته باشه.

در مقابل فعالیت use case analysis فعالیتی دیگر با عنوان use case design وجود داره که که مسئولیت انجام اون با طراح هست و این جایی هست که به طور واقعی حرف از تکنولوژی به میان میاد یعنی به عنوان مثال زبان برنامه نویسی و کیفیت مطرح میشه.

مهرداد:

خوشحال هستم که این گفتگو شکل گرفته است.

اگر اجازه دهید چند نکته را عرض کنم.

1) به نظرم قیاس مدل «تحلیل نرم‌افزار» بر مبنای «تکنولوژی شیءگرایی» با «مدل منطقی پایگاه داده» ما را به اشتباه خواهد انداخت.

در مدل منطقی پایگاه داده اثری از «رفتار» (behaviour) و «کارکرد» (function) نیست. ما فقط «ساختار» را در مدل مفهومی پایگاه داده داریم.

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

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

تحلیل نرم‌افزار یعنی این که:

– کلاسها، صفات و روابط ساختاری بین کلاسها را پیدا کنید

– تعیین کنید که هر کلاس باید چه متدها و مسئولیتهایی داشته باشد

– تعیین کنید که کلاسها چگونه با یکدیگر تعامل کنند تا سیستم بتواند قیمت ردیف و قیمت کل فاکتور را نشان دهد.

برای نمونه به سوالهای زیر پاسخ دهید

– کلاس فاکتور و قلم فاکتور چه متدهایی دارند؟ (لطفا از ذخیره، ویرایش، حذف، … نام نبرید) چگونه این متدها را پیدا می‌کنید؟

– قیمت ردیف و قیمت کل فاکتور را کدام کلاس محاسبه کند؟ فاکتور + فاکتور، قلم فاکتور + یک کلاس جدید + …

-این کلاس برای آن که بتواند قیمت کل و قیمت ردیف را حساب کند باید با کدام کلاسها پیغام پسغام کند؟

بی‌شک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.

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

– قیمت ردیف و قیمت کل فاکتور را کدام کلاس محاسبه کند؟ فاکتور + فاکتور، قلم فاکتور + یک کلاس جدید + …

-این کلاس برای آن که بتواند قیمت کل و قیمت ردیف را حساب کند باید با کدام کلاسها پیغام پسغام کند؟

بی‌شک برای پاسخ به این پرسشها، داشتن «دانش» و «مهارت» در «تکنولوژی شیءگرا» ضروری است.

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

آقای نوذری:

سلام استاد وقت بخیر. مرسی از وقتی که میگذارید. اینجا واسه من حکم کلاس درس رو داره.

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

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

شاید به نوعی بتوان گفت تحلیل سیستم در واقع به نوعی “طراحی اولیه” یا به عبارتی “طراحی در سطح بالایی از انتزاع” می باشد. این مطلب در کتاب زیر به تفصیل آمده است:

Use Case Driven Object Modeling with UML, Theory and Practice. By: Doug Rosenberg and Matt Stephens

این کتاب فصلی با عنوان ROBUSTNESS ANALYSIS دارد. در این بخش از کتاب هدف از ROBUSTNESS ANALYSIS این طور بیان شده است:

To get from use cases to detailed design (and then to code), you need to link your use casesto objects. The technique we describe in this chapter, robustness analysis, helps you to bridgethe gap from analysis to design by doing exactly that. In a nutshell, it’s a way of analyzing youruse case text and identifying a first-guess set of objects for each use case. These are classifiedinto boundary objects, entity objects, and controllers (which are often more like functionsthan objects).

همچنین در ادامه بیان شده است که تحلیل یا تکنیکی که نویسنده از آن با عنوان Robustness Analysis نام برده است برای پر کردن فاصله یا گپی است که بین تحلیل و طراحی وجود دارد:

نویسنده کتاب در ادامه در خصوص شکل فوق و تشریح Robustness Analysis این توضیح را بیان نموده است:

Looking at Figure 5-1, robustness analysis sort of takes place in the murky middle groundbetween analysis and design. If you think of analysis (i.e., the use cases) as the “what” anddesign as the “how,” then robustness analysis is really preliminary design. During this phase,you start making some preliminary assumptions about your design, and you start to thinkabout the technical architecture (also see Chapter 7) and to think through the various possibledesign strategies. So it’s part analysis and part design.

همچنین وی برای مدلسازی و ترسیم نمودارها نیز چنین اصطلاحی را با توضیح زیر بیان می نماید:

… a robustness diagram is an object picture of a use caseAnatomy of a Robustness DiagramA robustness diagram is somewhat of a hybrid between a class diagram and an activity diagram.It’s a pictorial representation of the behavior described by a use case, showing bothparticipating classes and software behavior, although it intentionally avoids showing whichclass is responsible for which bits of behavior. Each class is represented by a graphical stereotypeicon (see Figure 5-2). However, a robustness diagram reads more like an activity diagram(or a flowchart), in the sense that one object “talks to” the next object. This flow of action isrepresented by a line between the two objects that are talking to each other.

There’s a direct 1:1 correlation between the flow of action in the robustness diagram andthe steps described in the use case text.

مهرداد:

پیشنهاد می‌کنم ابتدا چند عبارت زیر را از هم تفکیک کنیم

تحلیل سیستم

تحلیل نیازمندی‌ها

تحلیل (در ادبیات ما در ایران)

تحلیل نرم‌افزار

طراحی نرم‌افزار

آن چه در ایران به نام تحلیل شناخته می‌شود به «تحلیل نیازمندی‌ها» و به عبارت درست‌تر «نیازمندی‌ها» نزدیک‌تر است (requirements)

تحلیل نیازمندی‌ها کاری است که ما از «تحلیل‌گر سیستم» انتظار داریم.

دقت بفرمایید که «تحلیل نرم‌افزار» به کلی با «نیازمندی‌ها» متفاوت است. (به پسوند نرم‌افزار دقت بفرمایید)

تحلیل نرم‌افزار همان طور که فرموده بودید «پیش طراحی» است. به عبارت ساده‌تر تکنیکی است برای گذار از نیازمندی‌ها و ورود به طراحی نرم‌افزار.

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

همان طور که عرض کردم فکر می‌کنم که «تحلیل نرم‌افزار» به مهارتها و دانش طراحی نرم‌افزار نزدیک‌تر است تا دانش و مهارت «تحلیل‌گر سیستم».

البته این فقط یک دسته‌بندی مفهومی است. ما می‌توانیم افرادی را پیدا کنیم که به خوبی از عهده‌ی همه‌ی این کارها بر آیند. ولی باید بدانیم که «جنس» این کارها با هم متفاوت است.

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

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

شاد باشید

آقای نوذری:

مرسی استاد از صحبت هاتون. خیلی استفاده کردیم.

با شما و فرمایشتون: “جمع‌بندی بنده از فرمایشات حضرتعالی این است که ما برداشت‌های یکسانی از واژه‌ها نداریم، وگرنه در باقی قضایا هم‌نظر هستیم.” کاملا موافقم. توی پست قبلی هم اشاره کرده بودم. چه قدر قشنگ از لحاظ مفهومی چندتا Term بالا رو از هم تفکیک کردین. اجازه بدین من هم یه موضوع دیگه رو به نقل از پرسمن اشاره کنم. و اون “مهندسی کردن سیستم” قبل از شروع “مهندسی کردن نرم افزار” هست:

Software engineering occurs as a consequence of a process called systemengineering. Instead of concentrating solely on software, system engineeringfocuses on a variety of elements, analyzing, designing, and organizing thoseelements into a system that can be a product, a service, or a technology for thetransformation of information or control.

The system engineering process is called business process engineering whenthe context of the engineering work focuses on a business enterprise. When aproduct (in this context, a product includes everything from a wireless telephoneto an air traffic control system) is to be built, the process is called productengineering…

… Before software can be engineered, the ”system” in which it resides must be understood. To accomplish this, the overall objective of the system must be determined; the role of hardware, software, people, database, procedures, and other system elements must be identified; and operational requirements must be elicited, analyzed, specified, modeled, validated, and managed. These activities are the foundation of system engineering.

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

گزیده:

The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want. Steve McConnell