آموخته‌های ازرشمند مدیر پروژه نرم‌افزار

چیزی که به‌شدت در مورد پروژه متن‌باز بلوپنسیل (PencilBlue) مورد علاقه من است، این است که با افرادی از سراسر جهان رابطه داشتم. وقتی برای اولین بار شروع کردیم، فقط دو نفر بودیم، اما وقتی زمان سپری شد ناگهان ما توسعه‌دهندگان بسیار بیشتر از قبل بودیم. این موضوع من را بر آن داشت تا به فکر فرو روم که چگونه می‌توان یک پروژه موفق داشت و چگونه یک پروژه می‌تواند مدت‌ها بعد از توسعه هنوز پابرجا باشد؟

چه مقدار افراد در کل دنیا هستند که درحال توسعه برنامه‌های آزاد / متن‌باز هستند؟ اگر افرادی که در گیت‌هاب فعال هستند را در نظر بگیریم ما بیش از 80 میلیون توسعه‌دهنده برنامه‌های آزاد / متن‌باز داریم. این رقم واقعا رقمی خیره‌کننده است که تا این تعداد افراد آماده توسعه و برنامه‌نویسی برنامه‌ها وجود دارند. با این‌حال این ارقام شامل افرادی نمی‌شود که برنامه‌های مختلف را دریافت یا توسعه می‌دهند و گمنام هستند. حال ما می‌دانیم که چه تعداد از افراد ممکن است جذب پروژه ما شوند اما چگونه آنان را جلب پروژه خود کنیم و چگونه توجه آنان به ما جلب خواهد شد؟

برایان هایدرمهم‌ترین نکات در مدیریت یک پروژه مخصوصا متن‌باز نکات زیر هستند:

  • دید و بصیرت
  • فرایندها
  • ادراک
دید و بصیرت

پروژه شما باید یک دید کلی داشته باشد. یعنی دیدگاهی بر پروژه شما حاکم باشد. از مخاطبین سخنانم در ایالات NC سؤالی پرسیدم که «چه زمانی تصمیم گرفتید یک پروژه‌ متن‌باز را شروع کنید؟» تقریبا اکثر جواب‌ها یکسان بودند؛ یا خسته بودم یا می‌خواستم مشکلی را حل کنم.
مشکل این است که شما می‌خواهید مشکلی را حل کنید که همه با آن درگیر هستند، معمولا افراد به پروژه‌های کمک می‌کنند و به پروژه‌هایی می‌پیوندند که خود در میانه راه حل آن مشکل باشند. افرادی که بر روی برنامه‌ای کار می‌کنند یا می‌خواهند به آن برنامه کمک کنند باید دقیقا به طور واضح بدانند اهداف و دید شما برای اجرای این پروژه چیست و آیا دید شما با دید آنان هم‌راستا است که به شما کمک کنند.
این موضوع به آسانی با قرار دادن توضیحاتی در مورد اهداف و دید شما در README قابل حل است پس به ارائه یک دید خوب از پروژه خود بسیار دقت کنید. این موضوع که بگویید «من تقریبا 20 درصد را رفته‌ام اما ادامه کار سخت است و این هم نکات قابل توجه برای ادامه کار است» بسیار خوب است و مشکلی هم برای شما به وجود نمی‌آورد جز این که ممکن است اطمینان بیشتری را جلب کند پس صادق باشید.

نقشه راه داشته باشید

مشکل اکثر ما ایرانی‌ها این است که بی‌برنامه عمل می‌کنیم کاری را شروع می‌کنیم و جو زده تا جایی پیش می‌بریم. سپس بدون برنامه رهایش می‌کنیم! شما هم اگر به گذشته خود نگاه کنید خواهید دید که چه کارهایی را که کلید زده‌اید؛ اما به پایان نرسانده‌اید. چه قدر زیاد هستند؟ برای جلوگیری از آن باید یک نقشه راه داشته باشید تا بدانید می‌خواهید چه کنید و سرخورده نشوید. در نقشه‌ی راه خود بسیار معقول و منطقی عمل کنید.

سال گذشته ما یک نقشه راه ساده داشتیم که چهار ماه آخر سال ۲۰۱۴ چه‌کار کنیم. این کار جواب داد به این خاطر که ما ویژگی‌هایی که قرار بود اضافه کنیم بسیار دیر به دیر مطرح می‌کردیم و حتی در تقویم تاریخ‌های خاصی را مشخص می‌کردیم به این صورت که مثلا کاری را برای دو هفته بد مشخص نمی‌کردیم در عوض می‌گفتیم تا دسامبر باید تمام شود به این صورت فشار کم‌تری را بر خود وارد می‌کردیم. و واقعا هم برای ما کارساز بود.

باز خورد کاربران را دریافت کنید

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

hands2
ما کاملا آن چه یک CMS کامل می‌خواهد را آماده کرده بودیم، اما یک‌دفعه بازخورد کاربران را دیدم که «این خیلی باحال‌تر بود اگر …» این موضوع بسیار رضایت‌بخش بود چون ما می‌دیدیم که مردم از آن استفاده کرده‌اند و یا اینکه حداقل آن را آزمودهاند. بازخورد همیشه خوب است به این دلیل که همیشه حق با مشتری است! پس اگر درخواستی چند بار انجام شد آن را ترتیب اثر دهید زیرا شاید آنان چیزی بدانند که شما نمی‌دانید!

فرآیندها

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

پروسه و فرآیند و نگهداری پروژه در مسیر خود نیاز به پرداخت به جزییات زیادی دارد و شیطان هم در جزییات است! ولی باید با این شیطان کنار آمد! این کار باعث توسعه‌پذیری و رفع ایراد راحت‌تر کد می‌شود پس باید انجام شود!

چند دفعه پیش‌آمده است که به‌جای Commit تغییرات در یک شاخه ویژگی‌ها، آنان را مستقیم به Master فرستاده‌اید؟ در اولین Admit احساس گناه می‌کردم! این موضوع در هفته چند باری رخ می‌داد اما نه در مورد هسته پروژه بلکه بیشتر در مورد افرونه‌ها این موضوع رخ می‌داد. این کد نویسی بسیار سرکش است، بااین‌حال جواب می‌دهد اما بار اصلی بر روی دوش تیم می‌افتد؛ برای جلوگیری و مجبور کردن خود و دیگران برای انجام کارهای درست باید مقرراتی را تعیین کنید. برای رفع سندرم کدنویسی سرکش، بهتر است کارهای زیر را انجام دهید:

  • برای هر اشکال و یا ویژگی یک شاخه ایجاد کنید
  • هر مشکل بهتر است که یک شاخه داشته باشد
  • مطمئن شوید همه آزمون‌های انجام‌شده بر روی شاخه‌ها با Master ادغام شده باشد
  • تلاش نکنید درخواست pull خود را ادغام کنید.
  • اگر کاری که می‌کنید یک آزمایش و یا یک تجربه است در کامنت summit بگویید و مشکلات را بازگو کنید؛ هیچ‌وقت از آنان خجالت نکشید این موضوع به دیگران کمک خواهد کرد.

تمامی موارد بالا باعث می‌شود که تمی اعضای گروه همیشه همگام و Sync باقی بمانند.

درک و مشاهده

تصور کنید به دو پروژه به‌صورت همزمان دعوت‌شده‌اید. به کدام پروژه خواهید پیوست؟ و کدام یک ارزش وقت گذاشتن را دارد؟ این یک جدال ثابت است. من هنگام ارزیابی کتابخانه‌های دیگر برای Include کردن در بلوپنسیل دچار تردیدهای زیادی بودم. زیرا که هر یک کاری مشابه را به نحوه‌ای دیگر انجام می‌دادند. من دنبال تفاوت‌هایشان بودم اما برای کتابخانه‌های زیادی که یک کار را می‌کنند باید تمیزدهنده‌ای وجود داشته باشد. صادقانه بگویم که گیج‌کننده است. README پروژه یا محصول شما بسیار مؤثر خواهد بود تا دیگر افراد در انتخاب آن بهتر عمل کنند و پروژه‌ی شما را به‌حساب آوردند.

به‌عنوان یک توسعه‌دهنده معمولا به بهبود عناصر بصری می‌پردازم کد تروتمیز با مستندات خوب  باشد که باعث شود فکر کنیم که کد با انسان صحبت می‌کند. اما برای 300 کیلو کد بهتر است که همیشه مراقب کیفیت کد خود باشید تا طول عمر بیشتری به برنامه خود ببخشید.

هر نگه‌دارنده‌ای باید همیشه شفافیت در اولویت اولش باشد! پروژه‌های متن‌باز همیشه کمک‌کننده کاربران و توسعه‌دهندگان هستند. برخی از این پروژه‌ها به شما کمک می‌کنند که پروژه‌ی بهتری داشته باشید.

  • Travis CI : پشتیبانی از تصحیح ادامه دار
  • Coveralls: محیا کردن پوشش کامل
  • Code Climate: مهیا کردن آنالیزر کد
  • David: آنالیزر وابستگی‌ها را مهیا می‌کند

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

Shortlink: