در مدیریت محصول، تمرکز بر شناخت دقیق مشکل کاربران مهم‌تر از ارائه راه‌حل‌های سریع یا خلاقانه است. بدون درک درست از نیاز و درد کاربران، احتمال شکست محصول بالاست. شرکت‌های موفق مانند Intercom با تحلیل رفتار کاربران، مصاحبه‌های عمیق و ساخت MVP، ابتدا مشکل اصلی را شناسایی کرده و سپس راه‌حل مؤثر ارائه داده‌اند. تمرکز بر مشکل باعث استفاده بهتر از منابع، افزایش نرخ موفقیت و توسعه محصولی می‌شود که واقعاً به نیاز بازار پاسخ می‌دهد.

ادامه مطلب

در مدیریت محصول، تصمیم‌گیری‌های بدون تحلیل می‌تواند منجر به هدررفت منابع و شکست راه‌حل‌ها شود. ابزار Opportunity Tree، معرفی‌شده توسط Teresa Torres، یک فریم‌ورک مؤثر برای شناسایی و اولویت‌بندی فرصت‌های واقعی پیش از اجرای راه‌حل است.

ادامه مطلب

مدل کانو ابزاری برای دسته‌بندی نیازهای کاربران در توسعه محصول است که آن‌ها را به نیازهای اساسی، عملکردی، انگیزشی، بی‌تفاوت و معکوس تقسیم می‌کند. این مدل به تیم‌ها کمک می‌کند روی ویژگی‌هایی تمرکز کنند که بیشترین تأثیر را بر رضایت کاربران دارند و از توسعه قابلیت‌های کم‌ارزش جلوگیری کنند. استفاده از مدل کانو نقش مهمی در رسیدن به Product-Market Fit دارد.

ادامه مطلب

در مدیریت پروژه، دو روش Agile و Waterfall رویکردهای متفاوتی دارند. Waterfall مدلی خطی است که مراحل پروژه به ترتیب و بدون بازگشت انجام می‌شود و مستندسازی کامل دارد. Agile اما رویکردی چابک، تکرارشونده و منعطف است که تغییرات را حتی در مراحل پایانی می‌پذیرد و با مشارکت مستمر مشتری و تیم همراه است. Agile محصول را به‌صورت تدریجی تحویل می‌دهد و ارتباط تیمی بالایی دارد، در حالی که Waterfall محصول نهایی را پس از اتمام کل مراحل ارائه می‌کند. اگر پروژه شما نیازمند ثبات و چارچوب مشخص است، Waterfall مناسب‌تر است، ولی برای پروژه‌های پویا و تغییرپذیر، Agile انتخاب بهتری است.

ادامه مطلب

جلسه روزانه (Daily Standup) باید کوتاه، منظم و مؤثر باشد. برای این کار سه قانون مهم است: جلسه هر روز سر وقت و در زمان مشخص برگزار شود، همه اعضا ایستاده باشند تا جلسه کوتاه و متمرکز بماند، و فقط درباره سه سوال اصلی صحبت شود: دیروز چه کاری انجام شد، امروز چه کاری قرار است انجام شود، و چه موانعی وجود دارد. رعایت این نکات باعث می‌شود جلسه وقت‌گذرانی نباشد و به پیشرفت تیم کمک کند.

ادامه مطلب

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

ادامه مطلب

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

ادامه مطلب

دوره مدیریت پروژه چابک به همراه مفاهیم چارچوب اسکرام +  متدولوژی کانبان و ابزارهای جیرا و کانفلوئنس برای یکی از مشتریان آکادمی همراه اول برگزار گردید. تدریس این دوره توسط مهندس حمیدی و مهندس فرح زادی انجام شد.8 ساعت مباحث تئوری از مفاهیم مقدماتی مدیریت پروژه چابک(مختص پروژه های نرم افزاری) تشریح و سپس 8 ساعت به تدریس عملی و کار با ابزارهای جیرا و کانفلوئنس پرداخته شد.

ادامه مطلب

  دوره آفلاین + حضوری(کارگاهی) اسکرام مستری و ابزارهای اسکرام در استودیو ضبط مدرسه مهارت دانشگاه تهران آغازشد. این دوره با همکاری مدرسه مهارت دانشگاه تهران برگزار میگردد.15 ساعت این دوره به صورت آفلاین و 4 ساعت به صورت کارگاهی و حضوری خواهد بود.  مفاهیم اصلی این دوره به شرح زیر است: 1- مفاهیم مقدماتی، پیش درآمدی از ورود به دنیای چابکی 2- مقدمه‌ای براسکرام 3- ساختار تیم‌های اسکرام 4- رویدادها و مصنوعات اسکرامی …

ادامه مطلب

اغلب به دنبال یک معیار یا شاخص هستیم که بتوانیم با آن خط کش روی تیم بگذاریم و عملکرد تیم را بسنجیم.  اما  اعداد همیشه قابل اتکا نیستند. در تیم‌های توسعه محصول، به ویژه در توسعه نرم‌افزار، شاخص‌هایی مثل Velocity، Lead Time، Code Coverage، Technical Debt، و ... به تنهایی کافی نیستند. پس چگونه می‌توانیم عملکرد تیم را اندازه‌گیری کرده و بگوییم که این تیم به خوبی کار کرده و قابل تقدیر است؟ پاسخ به این سوال نیازمند درک دقیق دو مفهوم "خروجی" و "نتایج" است.

ادامه مطلب