نکسوس: توسعه نرم افزار مقیاس‌پذیر

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

گزارش یک پروژه چابک – Simplydesk – بخش دوم

در قسمت اول این گزارش در مورد نحوه برنامه ریزی بیشتر صحبت کردیم، در قسمت دوم بیشتر مسائل فنی را پوشش خواهیم داد. شما هر چقدر برنامه ریزی قوی داشته باشید، ولی اگر از سطح فنی خوبی برخوردار نباشید، سطح چابکی مناسبی نخواهید داشت. یکپارچه سازی مداوم و تحویل مداوم لازم و ملزوم:) بدلیل اینکه پروژه از ساختار و لایه های مختلفی تشکیل شده بود و لایه ها به صورت مستقل Build می شدند، و بخصوص اینکه یک فریم ورک هم داشتیم که خود آن کاملا مستفل بود، یکپارچه سازی مداوم یا Continuous Integration  امری بسیار ضروری بود. این کار...
Continue reading...

گزارش یک پروژه چابک Simplydesk – قسمت اول

در سه سال گذشته در کنار تمام فعالیت های آموزشی و مشاوره ای، به عنوان مدیرتوسعه و مربی چابک محصولی با نام Simplydesk نیز بودم. این محصول در همکاری مشترک دو شرکت ایرانی با یک شرکت فرانسوی به اسم PCI شروع شده بود. کسب کار این محصول میز خدمات و مدیریت دارایی فناوری اطلاعات مبتنی بر استانداردهای ITIL  و بازار هدف این محصول کشورهای فرانسوی زبان تعریف شده است. این محصول که بر بستر Cloud یا رایانش ابری ارائه شده و امروز بیشتر از 80 مشتری سازمانی در اقصی نقاط فرانسوی زبان دنیا مانند شمال و جنوب فرانسه، کبک کانادا،...
Continue reading...

چابک شدن خوب اما برای چه کسی؟

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

پست مهمان: چرا مدیرانی که متدولوژی تولید ندارند فکر می کنند Agile هستند؟

نویسنده: مهیار ابراهیمی وفا حدود ده دوازده سال پیش در شرکتی مشغول به کار بودم. آنجا هم مثل بسیاری دیگر از شرکتها متدولوژی مشخصی برای تولید نرم افزار نداشتیم و به قول معروف Code & Fix می کردیم. بابت این مساله هم گاهی در جلسات با مشتری شرمنده می شدیم و در جواب اینکه “از چه متدولوژی استفاده می کنید؟”، آسمان و ریسمان می بافتیم و توجیه می کردیم. تا اینکه اسم Agile یا چابک به گوش مدیران شرکت خورد. آن زمان تازه متدولوژی های چابک مطرح شده بود و بخصوص XP مورد توجه بود. با وجود واژه نوظهور چابک که...
Continue reading...

مقدمه ای بر Disciplined Agile Delivery

بسیاری از شرکت ها و سازمان ها چابک سازی خود را با اسکرام شروع کرده اند، زیراکه این چارچوب استراتژی خوبی برای شروع کار و آغاز این تغییر معرفی کرده است. اما با اجرای بیشتر این چارچوب و نیاز به چابک کردن کل فرآیند تولید/توسعه و دخیل کردن کل سازمان در فرآیند چابک شدن، نیاز به ترکیب فرآیند های مختلف باشد. در چند مدت اخیر فرآیندهای چابک زیادی معرفی شده اند، که یکی از معروفترین آنها Disciplined Agile Delivery یا تحویل چابک منظم است. در این نوشته قصد دارم خلاصه ای از این فرآیند را معرفی کرده و در مورد اینکه...
Continue reading...

چیزهایی که نمی دانیم ولی فکر می کنیم می دانیم

IMAG0221

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

از پروژه بعدی این اشتباه رو تکرار نمی کنم، ولی چرا باز تکرار می شود؟

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

مدیرهایی که می خواهند رهبر باشند نه رئیس، ولی چگونه؟

یکی از ترندهای روز، کلید واژه “رهبر” یا “رهبری بجای مدیریت” است. بعبارتی مدیرانی که تا دیروز رئیس بودند، باید امروز شیوه برخورد را عوض کنند و مانند رهبران خدمت گذار عمل کنند. اما چگونه؟ در همین راستا چندی پیش عکسی در شبکه های اجتماعی دست به دست می شد که از جمله عکس های خوشمزه به حساب می آمد. به نظر من این عکس یک عکس خوب و انسانی است و از همین نظر قابل تحسین، ولی مفهومی که می خواهد برساند را اشتباه انتقال می دهد، در این عکس می بینیم فرق رئیس با رهبر در این دیده...
Continue reading...

7 روش برای مقابله با جلسات برنامه ریزی خسته کننده

در گذشته روش های توسعه نرم افزار معمولا Plan-driven بودند یعنی در ابتدای پروژه زمان زیادی (مثلا نصف زمان پروژه) صرف طراحی و تحلیل پروژه می کردیم و در نهایت با داشتن یک طرح کامل می توانستیم پیاده سازی را شروع کنیم. اما به تدریج با زیر سوال رفتن این روش ها (که اثبات کردند طراحی های پیچیده قابل پیش بینی نیستند و باید در مرور زمان و در خلال پیاده سازی پروژه کشف شوند) و ظهور روش های برنامه ریزی تجربی گرا مانند اسکرام، ما دائما در روند پروژه درحال برنامه ریزی هستیم. اما مشکل این است که این روش خود مشکلات اساسی برای...
Continue reading...