بایگانی دسته: مهندسی نرم افزار

از کلاسهای concrete (پایین دست) برای پاس دادن پارامتر استفاده نکنید!

یکی از بدیهات برنامه نویسی شی گرا پاس دادن یک نوع کلاس بین کلاس ها میباشد که معمولاً دیده میشه برنامه نویسان بدون آینده نگری کلاسی که نیاز دارند رو دقیقاً همون رو پاس میدهند برای روشنتر شدن قضیه به شبه کد زیر توجه کنید :

class TestActivity extends Activity { ……..}

class Test {

public Test(TestActivity ta){}

}

در اینجا کلاس Test بعنوان مصرف کننده کلاس TestActivity فقط و فقط میتواند کلاس TestActivity را بعنوان ورودی بگیرد، حال میتوان حالتی را در نظر گرفت که کلاس Test میخواهد کارآیی خود را افرایش داده و همه نوع کلاسهایی که از جنس Activity هستند را در بر بگیرد در این حالت باید دست به جراحی عمده در کلاس Test بزنیم و هرکجا از TestActivity استفاده برده ایم آنرا تغییر به کلاس بالاتر خود یعنی Activity دهیم.

این کار شاید در برخی مواقعی بعنوان technical debt قابل قبول باشد اما بصورت کلی این نوع کار کرد به هیچ عنوان حتی بصورت چابک (در این حالت بخوانید عجله ایی) هم توصیه نمیشود و حتماً باید از کلاس بالاتر و یا interface مخصوص به کلاس استفاده برد.

مثال دنیای واقعی :

 

import java.util.Calendar;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;

import android.widget.TextView;

import com.github.praytimes.Clock;
import com.github.praytimes.Coordinate;
import com.github.praytimes.PrayTime;
import com.github.praytimes.PrayTimesCalculator;

import cal.Main_Calendar;

/**
* Pray time helper. It is like an aspect for activity class somehow
*
* @author ebraminio
*/
public class PrayTimeActivityHelper {
private final Utils utils;

private final Main_Calendar calendarActivity;
private Date date = new Date();
private final TextView prayTimeTextView;

public PrayTimeActivityHelper(Main_Calendar calendarActivity) {
this.calendarActivity = calendarActivity;
this.utils = calendarActivity.utils;
prayTimeTextView = (TextView) calendarActivity
.findViewById(R.id.today_praytimes);
}

public void setDate(int year, int month, int dayOfMonth) {
Calendar c = Calendar.getInstance();
c.set(year, month, dayOfMonth);
date = c.getTime();
}

public static Map<PrayTime,Clock> prayTimeClockMap = new HashMap<PrayTime, Clock>();
public String getPrayTime(PrayTime pt)
{
Coordinate coord = utils.getCoordinate(calendarActivity);
PrayTimesCalculator ptc = new PrayTimesCalculator(
utils.getCalculationMethod(calendarActivity));
Map<PrayTime, Clock> prayTimes = ptc.calculate(date, coord);
prayTimeClockMap = prayTimes;
char[] digits = utils.preferredDigits(calendarActivity);
switch (pt)
{
case Imsak:
return utils.clockToString(prayTimes.get(PrayTime.Imsak), digits);
case Sunrise:
return utils.clockToString(prayTimes.get(PrayTime.Sunrise), digits);
case Dhuhr:
return utils.clockToString(prayTimes.get(PrayTime.Dhuhr), digits);
case Sunset:
return utils.clockToString(prayTimes.get(PrayTime.Sunset), digits);
case Maghrib:
return utils.clockToString(prayTimes.get(PrayTime.Maghrib), digits);
case Midnight:
return utils.clockToString(prayTimes.get(PrayTime.Midnight), digits);
default:
return “”;
}
}

منبع  سورس بالا :

https://github.com/ebraminio/DroidPersianCalendar/blob/master/PersianCalendar/src/main/java/com/byagowi/persiancalendar/PrayTimeActivityHelper.java

(خدایا چقدر باید refactor کرد حتی کدهای خوب رو!!!)

برنامه بهینه تر یا برنامه کاراتر؟

معمولاً تو کلاسهای درسیم دانش آموزانی رو دارم که آشنایی کمی با مبحث شی گرا دارند که بعضاً میگویند که کسی که خوب شی گرا بنویسه لزوماً برنامه های خیلی سریعی هم میتونه بنویسیه!

یک نکته ایی رو نباید فراموش کنید این هست که کامپیوترها بطور پیشفرض مسائل رو بطور خطی یعنی دستورات را زیر هم حل میکنند و اصولاً کامپیوترها (منظور همان CPU میباشد) در این حالت یعنی در حالت برنامه نویسی خطی بیشترین و بالاترین سرعت را دارا میباشند.

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

اما چرا ما انسانها حاضریم برنامه های کندتر بنویسیم؟

دلیل اصلی این امر در نوع نگاه ما انسانها به حل مسئله نهفته است. اینکه ما برای حل مسائل پیچیده ابتدا آنها را به اجزای کوچکتر تبدیل میکنیم سپس سعی در حل نمودن مسائل کوچک نموده تا مسئله اصلی را حل کنیم.

اگر با این نگاه به دنیای شی گرا نگاه کنیم، آنگاه درک خواهید کرد که هر کلاس را میتوان همانند یک تکه کوچک از پازل بزرگی به نام سیستم(مسئله) در نظر بگیریم که برای حل کل مسئله نیاز به تکه تکه کردن آن داریم.

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

 

 

توصیه های بهداشتی برای برنامه نویس شدن

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

برای همین مسئله تصمیم گرفتم چندین نکته که بصورت تجربی در زمینه برنامه نویس شدن رو یاد گرفتم اینجا ذکر کنم بلکه به درد دوستان هم بخوره:

۱- استراحت نکنید

اگر میخواهید به جمع برنامه نویسان بپیوندید این نکته رو یادتون باشه که هیچ comfort zoneیی در برنامه نویسی وجود نداره، همه چیز جدیده از مشکلاتی که بر سر راه شما قرار میگیره تا تکنولوژیهایی که هرروز عوض میشه، پس اگر دوست دارید قدم در دنیای برنامه نویسی بگذارید اونهم بطور جدی و نه آماتور، خودتون رو برای درگیری های ذهنی روزانه آماده کنید.

۲-به هیچ شرکتی اعتماد نکنید

قبل از اینکه بخوام این نکته رو بسط بدم یک سوال میپرسم، ما برای چی برنامه مینویسیم؟

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

۳-کار گروهی یاد بگیرید

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

۴-دید جهانی داشته باشید

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

۵-به روز باشید

این نکته تلفیقی هست از نکات ۱ و ۴ اما در اینجا بیشتر منظورم یادگیری تکنولوژیهای به روز دنیا هست مثل یادگیری زبان برنامه نویسی جدید و یا یادگیری یک فریمورک جدید کار با سیستمهای جدید، مثلاً لطف کرده هر ده سال یکبار یک نسخه از اوبنتو و یا لینوکس مینت رو نصب کنید تا متوجه بشید همه دنیا ویندوز نیست!

۶-روشهای برنامه نویسیتون رو بهتر کنید

صرف اینکه از ۲۰ سال پیش تا به امروز میتونستید با یک حلقه for ساده در همه کلکسیونها و اشیا چرخ بزنید به این معنی نیست که نباید foreach رو یاد بگیرید!

۷-متعهد و با اخلاق باشید

مهمتر از برنامه نویس حرفه ایی شدن، در دنیای واقعی باید یادبگیرید که اخلاق داشته باشید، باید معنی تعهد کاری رو درک کنید، باید به این نکته توجه داشته باشید که کارفرما نیاز به افراد متخصص و متعهد داره، صرف تخصص داشتن شما رو به جایی نمیروسنه. برفرض اگر قول دادید که ۱۰ روز دیگه فلان کار رو انجام بدین حتماً اون کار رو تا همون روز انجام بدین حتی اگه شده از خوابتون بزنید، اینطوری کارفرما روی شما حتماً جور دیگه ایی حساب باز میکنه. در کنار مسئله تعهد با اخلاق بودن هم مهمه، آدمهای گنده دماغ و بی ادب در کار گروهی محکوم به شکستند!

۸-یادبگیرید تشکر کنید

این نکته هم برای تازه کارها مفیده و هم برای اونایی که فکر میکنند مادرزاد برنامه نویس بودن! یه مثلی هست که میگه “همه چیز رو همگان دانند”، پس اگر چیزی از همکار بقل دستیت و یا رفیقت یادگرفتی حتماً تشکر کن چون با اینکارت اون رو راقب میکنی بیشتر بهت یادبده و صمیمیت رو بینتون بالا میبره.

۹-اگر حقوقت کافی نیست یا محل کارت رو عوض کن یا تخصصت رو ببر بالا

این نکته هم خودش گویا هست و فکر نمیکنم چیزی برای توضیح دادن بخواد!

 ۱۰-رزومه خوب داشته باشید

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

امیدوارم این چندتا توصیه بهداشتی بتونه کمکی باشه برای دوستانی که نمیدونن چطوری میشه از صنعت نرم افزار بطور مستقیم کسب درآمد داشت.

فرق شرکت مهندسی نرم افزار با سبزی فروشی و یا چطور یاد بگیریم سفارش نرم افزار بدهیم (سخنی دوستانه با مشتریان حوزه نرم افزار ایران)

چند روز پیش بود که تلفنم زنگ خورد،

من : الو

شخص نامعلوم : سلام، شما برنامه اندروید مینویسید؟

من : بله، بفرمایید

ش.ن : به من گفتن که شما کارت خوبه برای همین به شما زنگ زدم.

من : لطف داشته هرکی اینو گفته بفرمایید چه کمکی از دستم برمیاد؟

ش.م : یه نرم افزار برای وب سایت شارژ … چقدر درمیاد؟

من : در وحله اول به این شکل دراومدم ۰٫o انگاری با آجر زده باشن توی سرم و برق سه فاز از کله م پریده بود بعد از چند ثانیه مکث به خودم اومدم پرسیدم، خب این نرم افزار چه ویژگیهایی میخواهید داشته باشه؟

ش.ن : خب مثل همه نرم افزارهای دیگه باشه که کار میکنن.

من : یعنی شما هیچ مشخصاتی یا تعریفی تو ذهنتون نیست؟

ش.ن : چرا ما مشخصات کامل رو داریم.

من : راستی شما جناب آقای؟

ش.ن : یک آقایی شما رو به من معرفی کرده.

من : خب اون آقا کیه؟

ش.ن : شماره تلفنش هست …..

من : خب اسم شریف خودتون چی بود؟

ش.ن : من “رحیم خالقی” هستم!(اسم این نبودش ولی …)

من : خب جناب رحیم خالقی من ایمیلم رو برای شما اس ام اس میکنم شما مشخصات کامل نرم افزاری که مد نظرت هست رو برای من بفرست.

و پایان مکالمه!

 

کد زدن برای غذا

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

اما صنعت نرم افزار در کل جهان کلاً کمتر از ۵۰ ساله که پا گرفته تو کشورمون خیلی خوشبینانه میتوان گفت که ۲۰ سال هست که به این صورت امروزی در اومده پس به ما خادمان خودتون این فرصت رو بدین تا بفهمیم شما دقیقاً چه چیزی مد نظر دارید.

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

برای اینکه یک کارگردان بتونه برروی ساخت یک اثر هنری کار کنه نیاز به یک دستمایه(زیاد بحث رو فنی نمیکنیم) داره، دستمایه دقیقاً همون چیزی هست که بعنوان مشخصات کلی تهیه کننده باید تهیه بکنه و بده دست کارگردان!

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

اینکه ما یه شب پنجشنبه میریم بیرون و خودمون و خانوادمون رو در یکی از رستورانهای شهرمون مهمان یک شام لذیذ میکنیم با فرض چهار نفره بودن خانواده چیزی نزدیک به ۲۰۰هزار تومن برامون درمیاد اما از طرفی وقتی یک برنامه نویس برای نوشتن یک اثر هنری که باید رو اون فکر و ذهنش رو متمرکز کنه اگر از ما مبلغی کمتر از ۱ میلیون تومان درخواست کنه برای یک ماه کارکرد خودش و ما اون رو به حساب گران فروشی اون شخص بذاریم و بگیم که میدم یکی دیگه بنویسه با قیمت پایینتر از اینها، به نظرم کمی بی انصافیه.

در مورد اینکه پروژه های نرم افزاری رو بشه به اشخاص مختلف واگذار کرد تا انجام بدهند، بله کاملاً حق مشتری هست که بتونه انتخاب بکنه، اما کیفیت و نوع کار نرم افزارهای تجاری یک عرف خاص خودش رو داره مثل همه صنوف که براساس خدمتی که ارائه میدهند براساس عرف خودشون با مشتری حساب میکنند، اما اینکه برفرض یک بچه ۱۶ ساله میگه من میتونم یه نرم افزار حسابداری بنویسم که مثل فلان برنامه حسابداری کار کنه و آخ هم نگه و با قیمتی فوق العاده پایینتر از قیمت فلان برنامه، اینجاست که من یاد مثلی میفتم با این مضمون “روی سرکچل کسی کار یادگرفتن”.

کلام آخر

اگر واقعاً وقتتون و پولتون براتون ارزش داره به نظرم قبل از رفتن به اصل مطلب یعنی ساخت نرم افزار به دنبال یک مشاور بگردید حدالامکان کسی که ۷-۸ سالی در زمینه تولید نرم افزار فعالیت کرده و پروژه های موفقی هم ارائه داده و یا در مراکز شناخته شده کار کرده و رزومه قابل توجهی در این زمینه داره.

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

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

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

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

کمدی به نام اسکرام در صنعت نرم افزار ایران

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

راغب میشم بیشتر بدونم که دقیقاً چطور اسکرام رو پیاده کردن ازشون میپرسم آیا اسکرام مستر دارین؟

میگن آره آقا/خانم فلانی اسکرام مسترمون هست. ،خب ایشون دقیقاً چکار میکنن؟

جوابها اکثراً با جملاتی اینچنینی به پایان میرسه که اسکرام مستر خودشون مدیرعامل شرکت هستند یا یکی از اعضای هیئت مدیره هستند که البته سرشون خیلی شلوغه و بیشتر کارهای مدیریتی رو انجام میدن!

در مورد نحوه کار کرد اسکرام در شرکت میپرسم و اینکه چطوری اون رو پیاده کردن میپرسم از اینکه آیا لیست کارهای هفتگی یا دوهفتگیشون رو جایی نگه میدارن آیا کارهای براساس هزینه انها اولیت بندی میشوند؟ آیا جلسات روزانه برگزار میکنید؟

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

این نوع برخوردها عموماً محدود به وسعت جغرافیایی ایران نمیشه و میشه از این دست مدیریتهای سلیقه ایی ولی با اسم جدید را در تمام دنیا مشاهده کرد، این نوع برخورد در اسکرام معروف است به  scrum-but بدین معنا که ما در حال اجرا اسکرام هستیم اما کار خودمون رو میکنیم. لزوماً اینکه گروهی یا شرکتی کارخود را میکند و شیوه مدیریت خود را دارد بد نیست ولی اینکه بخواهیم کارهای قدیمی و بعضاً و غلط خود را به متدلوژیهای جدید نسبت بدهیم و بعد انتظار داشته باشیم با پیاده سازی روشهای قدیم ولی با اسم جدید به نتایج جدیدتر و مطلوبتری برسیم کمی دور از منطق و انصاف هست!

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

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

اسکرام به دلیل نگاه سطح بالایی و نسبتاً ناقصی که به مدیریت پروژه داره نمیتونه بعنوان یک متدلوژی کامل و در سطح کاربردی مطرح بشه و بیشتر میتونه در حد یکسری اصول و قرارداد اولیه در یک شرکت و یا گروه بر اون حساب بازکرد.

اما یک تیم توسعه واقعاً نیاز داره که بدونه باید چه کاری انجام بده، نیاز داره که بدونه از چه استراتژی برای تست، از چه استراتژی برای ریلیز و چه از استراتژی برای نگهداری و تلفیق ادامه دار باید استفاده کنه که هیچکدوم از اینها توی اسکرام جواب داده نمیشه.

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

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