اگر در یک پروژه‌ی نرم‌افزاری مشارکت دارید و موارد زیر را مشاهده کردید، بدانید که پروژه‌تان با چالش‌هایی روبرو خواهد شد:
-
فقدان مشارکت فعال مالک محصول و نداشتن قدرت کافی
-
کلان بودن نیازمندی‌ها، خیلی جزئی بودن نیازمندی‌ها یا فقدان نیازمندی‌ها
-
عدم تعریف مناسب نقش‌ها، مهارت‌ها و عدم تخصیص درستِ مسئولیت‌ها
-
عدم مشارکت تیم‌ها در ارائه‌ی تخمین‌ها
-
فقدان برنامه‌ریزی انتشار یا عدم انجام آن به اندازه‌ی کافی
-
مشارکت دیرهنگامِ آزمونگران در فرایند توسعه‌ی محصول
-
تبدیل شدن مدیریت به یک مانع به جای مشارکت فعال در رفع موانع
-
تمرکز مدیریت پروژه روی دادن گزارش‌های خوب به کارفرما و عدم ارائه‌ی گزارش به خود تیم
-
تولید کُدهای با کیفیت پایین که دارای نقایص متعددی است
-
تیم با قدرت ناکافی و عدم مشارکت آن در بحث‌های کلیدی
-
فقدان دید و اشرافی به پیشرفت واقعی یا مسائل روزانه
-
فقدان تمرکز بر تثبیت و اثبات مفهومی معماری در زودترین زمان ممکن
-
عدم اولویت‌بندی ویژگی‌ها به صورت دوره‌ای (تکرارشونده)
برای هر یک از مسائل فوق، باید چاره‌ای اندیشید. در غیر این صورت، زمینه‌های شکست پروژه فراهم می‌شود. در ادامه، راهکارهایی برای این مسائل پیشنهاد شده است. شما می‌توانید با تحلیل و دقت‌نظر در این مسائل راهکارهای دیگری را هم مدنظر قرار دهید.
مروری برخی پیشنهادات برای حل مسائل کلیدی پروژه‌های نرم‌افزاری:
-
فقدان مشارکت فعال مالک محصول و نداشتن قدرت کافی
- مالک محصول باید قدرت کافی داشته باشد، به صورت فعال در پروژه مشارکت داشته و دانش کافی داشته باشد.
- مالک محصول باید در خصوص نقش و مسئولیت‌هایش و همچنین فرایند توسعه‌ی محصول آموزش داده شود.
- فرد مناسبی باید به عنوان مالک محصول انتخاب شود.
-
نیازمندی‌ها خیلی سطح بالا هستند، خیلی جزئی هستند یا اصلاً وجود ندارند.
- تیم در خصوص سطوح مختلف نیازمندی‌ها آموزش داده شود به‌گونه‌ای که به موقع سطح درستی از نیازمندی‌ها را استخراج و گردآوری کند.
- اپیک‌های بزرگ به اجزاء ارزشمند کوچکتر شکسته شوند.
- جزئیات به موقع جمع‌آوری شوند و از تشریح زودهنگام نیازمندی‌ها پرهیز شود (Big Requirements Upfront)
-
نقش‌ها، مهارت‌ها و نحوه‌ی تخصیص مسئولیت‌ها به درستی انجام نشده است.
- نقش‌های تیم باید به‌گونه‌ای تعریف شده باشد که اعضای تیم بتوانند تمام کارهای انجام‌شدن یک ویژگی یا استوری را انجام دهند. بدین ترتیب که، تیم بتواند با درک نیازمندی‌ها، نسبت به طراحی و تولید و همچنین تست یک ویژگی یا استوری اقدام کند.
- از انجام چندین کار مختلف (multi-tasking) و اختصاص یک نفر به چندین پروژه اجتناب کنید.
- افراد با مهارت‌های درست را جذب کنید. افراد را برای Generalizing Specialist بودن، آموزش دهید.
-
تخمین‌ها توسط تیم درستی ارائه نشده است
- تیم را زودتر در جمع‌آوری نیازمندی‌ها و تخمین مشارکت دهید.
- تخمین‌ها باید بر اساس سنجش اندازه‌های نسبی مانند استوری پوینت باشد.
- زمان پروژه بر اساس اندازه‌ی تیم و سرعت تخمینی تیم در هر تکرار محاسبه شود.
-
برنامه‌ریزی انتشار به اندازه‌ی کافی صورت نپذیرفته است
- تیم را هر چه زودتر درباره‌ی برنامه‌ریزی مؤثر انتشار و به خصوص در ابتدای فرایند توسعه‌ی محصول (تکرار صفر یا iteration 0) آموزش دهید.
- افراد مناسب در زمینه‌ی سیستم، دیتابیس، امنیت، UI و معماری را در ابتدای فرایند توسعه‌ی محصول مشارکت دهید.
-
آزمون و آزمونگران دیرهنگام و بعد از تولید مشارکت داده می‌شوند
- آزمونگران نقش مهمی در موفقیت کار دارند و باید هر چه زودتر در برنامه‌ریزی انتشار مشارکت داده شوند.
- شرایط و معیارهای آزمون‌های پذیرش باید به عنوان بخشی از نیازمندی‌ها جمع‌آوری شوند و نه بعد از شروع تولید.
- آزمونگران سیستم و پذیرش کاربر باید با تیم در هر یک از تکرارها کار کنند.
-
مدیریت خود به یک مانع تبدیل شده به جای اینکه موانع را رفع کند
- مدیریت باید بر مسائلی نظیر اختصاص درست منابع به تیم‌ها، بهینه‌سازی نقش‌ها و بهبود مهارت‌های تیم یا آموزش‌های مورد نیاز، فراهم‌آوری ابزارها و آموزش‌های مناسب متمرکز شود.
- مدیریت باید وقفه‌های کاری تیم را کمینه کرده و موانع روزانه را رفع نماید.
-
مدیریت پروژه روی دادن گزارش‌های خوب به کارفرما متمرکز است و به خود تیم گزارش نمی‌دهد
- از درگیر کردن مدیران پروژه برای راهبری چندین پروژه‌ی مختلف پرهیز کنید.
- باید مهارت‌های اسکرام‌مستر را یاد گرفته یا یک اسکرام‌مستر خوب برای تیم پیدا کنید.
- دشبوردهای اطلاعاتی کاملا قابل مشاهده و گویا برای پروژه ایجاد کیند و خودتان (به عنوان مدیریت پروژه) با تیم همراه باشید.
-
تولید کُدهای با کیفیت پایین که دارای نقایص متعددی است
- تیم را هر چه سریع‌تر با روش‌هایی نظیر TDD،یکپارچه‌سازی خودکار، خودکارسازی بیلد، daily check-ins، الگوهای طراحی، refactoring، code review و سایر متدها برای ارتقاء سطح کیفی کُدها آشنا کنید.
- هر چه سریع‌تر باگ‌ها و نقایص را برطرف کنید تا بدهی فنی را کاهش دهید. بازبینی کُد و طراحی را تشویق کنید.
-
تیم قدرت کافی ندارد و در بحث‌های کلیدی مشارکت داده نمی‌شود
- مدیریت و تیم در خصوص ارزش‌های Servant Leadership آموزش داده شوند.
- به تیم قدرت کافی برای self-organize شدن (و نه self-leading!) بدهید.
- به طور پیوسته، بازپس‌اندیشی را برای دریافت بازخورد و پیگیری‌های بهبود فرایند کار انجام دهید.
-
دید و اشرافی به پیشرفت واقعی یا مسائل روزانه وجود ندارد
- کار را به یکسری چرخه‌ها/تکرارهای کوچک شکسته و پیشرفت کار را به صورت تکرارشونده، اندازه بگیرید.
- تعریف روشن و دقیقی از تعریفِ انجام شده (DoD) ایجاد کرده و آنچه را که انجام می‌شود، اندازه بگیرید و به صورت شفاف گزارش کنید.
- جلسات استندآپ روزانه برای گفتگو درباره‌ی کار کامل‌شده یا باقی‌مانده و موانع کار برگزار کنید.
-
فقدان تمرکز بر تثبیت و اثبات مفهومی معماری در زودترین زمان ممکن
- در مراحل اولیه‌ی فرایند توسعه‌ی محصول یا در واقع، در حین تکرار اولیه (iteration 0)، افراد کلیدی را در تعریف و شکل‌دهی به معماری (envisioning) مشارکت دهید.
- ریسک‌های فنی را شناسایی کنید و داستان‌ها یا spikeهایی برای اثبات مفهومی و حل و فصل این ریسک‌ها ایجاد کنید.
- دیاگرام‌های سطح بالا برای فرایند، جریان‌های UI، مدل‌های داده و مدل‌های معماری‌گونه ایجاد کنید.
-
عدم اولویت‌بندی ویژگی‌ها به صورت دوره‌ای (تکرارشونده)
- مالک محصول باید به صورت پیوسته در جستجوی حداقل ویژگی‌های با اهمیت (MMF) برای تولید باشد.
- مالک محصول باید کار انجام‌شده در هر چرخه/تکرار را بازبینی کند.