تست جوئل قسمت چهارم: bug tracker

قبل از شروع باید اشاره کنم با توجه به راه افتادن بخش صفحات سایت، می‌توانید کلیه نوشته‌های مربوط به سری "تست جوئل: 12 گام برای کد برتر" رو در این آدرس مشاهده کنید.

تست چهارم جوئل: آیا بانک اطلاعاتی از اشکالات (bugs) دارید؟

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


این حشره که در Harvard Mark II گیر کرده بود اولین باگ کامپیوتری است. حتی این باگ هم ثبت شده است!

گام دوم بعد از پیدا کردن باگ‌ها رفع آن‌ها نیست، ثبت آن‌هاست! جوئل در این مورد این‌طور توضیح می‌دهد:

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

چه اطلاعاتی درباره باگ‌ها را ثبت کنیم؟

جوئل می‌گوید حداقل اطلاعات زیر در مورد هر باگ باید ثبت شود:

  • مراحل کامل برای باز تولید اشکال
  • رفتاری که انتظار آن می‌رود
  • رفتار (ایراد داری) که واقعاً رخ می‌دهد
  • فردی که رفع اشکال به او واگذار شده است
  • آیا اشکل رفع شده است یا خیر؟
اما با توجه به توضیحی که در مورد تست سوم یعنی build روزانه دادم، خوب است مشخص شود که ایراد در چه نسخه‌ای یا بهتر بگوییم در چه build ای از نرم‌افزار مشاهده شده است.
البته اطلاعات دیگری هم هست که بعداً می‌تواند به باگ ثبت شده اضافه شود مثل اینکه باگ در چه changeset ای از کد برطرف شده است یا زمان لازم برای رفع آن چقدر است تا در برنامه‌ریزی تیم مورد استفاده قرار بگیرد.
 

به چه روشی اطلاعات باگ‌ها را نگهداری و باگ‌ها را رفع کنیم؟

اگر اهل استفاده از نرم‌افزارهای bug tracker نیستید خیلی راحت می‌توانید یک فایل اکسل درست کنید و ستون‌های ذکر شده را به آن اضافه کنید. اما من استفاده از TFS را توصیه می‌کنم. همین‌طور که در نوشته مربوط به تست اول جوئل گفتم TFS فقط یک نرم‌افزار برای استفاده به صورت source control نیست. بخش مهم‌تر TFS مکانیزه کردن پروسه تولید نرم‌افزار از طریق امکاناتی که برای build‌ و test و برنامه‌ریزی دارد می‌باشد.
روال نسبتاً‌ استاندارد کار برای نگهداری اطلاعات باگ‌ها و کار بر روی آن‌ها در TFS به شرح زیر است:

ابتدا برای نرم‌افزار موجود تعدادی Test Case را در یک Test Plan تعریف می‌کنید. این Test Case ها می‌توانند مربوط به یک تست اتوماتیک یا تست توسط کاربر tester باشد. در مراحل هر Test Case مشخص می‌کنید که نتیجه مورد انتظار چیست. کاربر tester می‌تواند هر مرحله و کلیت تست را fail یا pass کند. در صورت fail کردن می‌تواند یک bug ایجاد کند. از آنجایی که می‌توانید تنظیم کنید کل روال تست ضبط شود، موقع ایجاد باگ حتی فیلمی از دسکتاپ tester هم به باگ ایجاد شده attach می‌شود به همراه کلی اطلاعات دیگر که مشخص کننده این است که مراحل بازتولید اشکال کدام است. لازم است اشاره کنم که تست‌ها می‌توانند از پیش تعریف شده هم نباشند، یعنی یک tester کاملاً به صورت آزمون و خطایی با کار نرم‌افزار کار کند و سعی کند در عملکرد آن ایرادی پیدا کند. به این نوع تست‌ها exploratory test گفته می‌شود. در مورد Microsoft Test Manager به صورت مفصل صحبت خواهم کرد.

بعد از تعریف باگ نوبت به تایید آن می‌رسد، مسئول تایید می‌تواند لیستی از باگ‌های گزارش شده را مشاهده کند و آن‌هایی که به نظرش درست گزارش شدند را تایید کند و برای انجام به برنامه‌نویسان تیم assign کند. البته در برنامه‌ریزی کلان‌تر حتی می‌توان تعیین کرد که رفع باگ مثلاً در چه اسپرینتی انجام شود.
بعد از آن هر برنامه‌نویس وقتی Visual Studio خودش را باز می‌کند در Team Explorer و از بخش My Work می‌تواند کارهایی که به وی assign شده اعم از ایجاد feature‌های جدید یا رفع باگ‌ها را مشاهده کند و بعد از انجام کار و هنگام تحویل کد (check in) مشخص کند که کدی که در حال check in هست مثلاً باگ شماره x یا y را حل کرده است.

روالی که توضیح دادم علاوه بر ثبت باگ‌ها، کلیه مراحل مربوط به کشف تا رفع باگ را نیز پوشش می‌دهد. 

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

تست جوئل قسمت سوم: build روزانه

در نوشته‌های قبلی سری بررسی و شرح تست جوئل درباره Source Control و همچنین build یک مرحله‌ای صحبت کردم. در این نوشته درباره موضوعی صحبت می‌کنم که شاید کمتر برای شرکت‌های ایرانی کاربرد داشته باشد، اما اطلاع از مزایای آن ممکن است شما را مشتاق کند تا درباره سیاست فنی در تیم نرم‌افزاری‌تان تجدید نظر کنید.

آیا دارای build روزانه هستید؟

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


می‌توانید به برنامه‌نویسانی که باعث شکست build می‌شوند، چیزی مثل این را بدهید تا حداقل برای همان روز شرمگین باشند!

اجازه بدهید موضوع را با یک مثال توضیح بدهم: وقتی شما از یک نرم‌افزار source control استفاده می‌کنید، هر زمان بخواهید روی فایل سورسی تغییری بدهید باید آن فایل را تحویل بگیرید (check out) و هر زمان که کارتان بر روی آن فایل به اتمام برسد آن را تحویل می‌دهید (check in) بعد از اینکه همه فایل‌ها check in شوند، در واقع نسخه جدیدتری از نرم‌افزار را خواهید داشت (که یا feature ای به آن اضافه شده یا bug برطرف شده یا هر دو) البته ممکن است بسته به نوع نرم‌افزار source control و نحوه مدیریت شما بر کد مراحل دیگری نیز نیاز باشد، مثلاً اگر در تیم شما branch هایی از سورس اصلی ایجاد شده باشد، در نهایت لازم است کدها را ادغام (merge) کنید. صرفنظر از روش کار با سورس‌ها، فایل‌های نهایی که ایجاد می‌شوند ممکن است باعث fail شدن پروسه build بشوند! یعنی برنامه‌نویسی کدی را check in کرده که روی سیستم خودش درست بوده و کار می‌کرده اما باعث fail شدن build‌ محصول نهایی شود و محصول نهایی دیگر یک نرم‌افزار سالم و stable (چنانکه در نسخه قبل بوده) نباشد. به این مساله شکستن build هم گفته می‌شود. جوئل در این مورد پیشنهادی دارد و آن استفاده از build روزانه است. build روزانه یعنی build کامل روزانه اتوماتیک تمام source. خودش درباره پیشنهاد build روزانه برای رفع مساله شکستن build چنین توضیح می‌دهد:

"شكستن بیلد آنقدر بد (و رایج) است كه درست كردن بیلد روزانه کمک می‌كند كه چنین موضوعی ناشناخته نماند. در تیم‌های بزرگ، یک راه این كه مطمئن شوید كه چنین مشكلاتی در اولین فرصت برطرف شوند، این است كه بیلد روزانه را هر روز، هنگام ناهار انجام دهید.
همه تمامی check in هایی را كه می‌توانند قبل از رفتن به ناهار انجام می‌دهند. بیلد، زمانی كه همه برگشتند تمام شده است. اگر كه همه چیز درست است، كه فبحال! آخرین نسخه سورس توسط همه check out شده و كار ادامه پیدا می‌كند. اما اگر كه عمل بیلد با موفقیت روبرو نشده باشد، افراد با نسخه سالم قبلی به كار خود ادامه می‌دهند."

مزایای build روزانه

اسپالسکی در نوشته دیگری به معرفی مزایای build‌ روزانه و روش اجرایی کردن آن می‌پردازد. خلاصه‌ای از آن مزایای build روزانه از نظر جوئل اسپالسکی به شرح زیر هستند:

  • اگر باگی fix شده باشد، tester ها خیلی سریع آخرین نسخه را دریافت می‌کنند و می‌توانند با تست مجدد بررسی کنند که آیا باگ واقعا fix شده یا خیر؟
  • توسعه‌دهنده‌ها خیالشان راحت است که کدی که تغییر دادند باعث شکسته شدن 1024 تا نسخه قبلی نرم‌افزار نشده است.
  • توسعه‌دهنده‌هایی که قبل از زمان برنامه‌ریزی شده برای build روزانه کدشان را check in می‌کنند مطمئن هستند که کدی که تغییر دادند باعث شکست build نمی‌شود (شرایطی پیش نمی‌آید که بقیه نتوانند کل source را کامپایل کنند) این حالت معادل صفحه آبی مرگ برای کل تیم نرم‌افزاری است!
  • گروه‌های خارج از تیم فنی، مثل تیم بازرگانی، تست کننده‌های نسخه بتا و ... می‌توانند از یک نسخه‌ روزانه که تا حد قابل قبولی stable است تا مدتی استفاده کنند.
  • با نگه داشتن history کل build های روزانه، وقتی که یک خطای عجیب و غریب که مشخص نیست از کدام check in به بعد ایجاد شده به وجود می‌آید. با یک جستجو بر روی build ها می‌توانید متوجه شوید که خطا از کدام build به بعد ایجاد شده و اگر از یک نرم‌افزار source control‌ قوی استفاده کنید حتی می‌توانید مشخص کنید که کدام check in‌ باعث بروز این خطا شده است.
  • وقتی tester مشکلی را گزارش می‌کند که برنامه‌نویس گمان می‌کند قبلاً fix شده، tester می‌تواند شماره build روزانه را هم که خطا در آن دیده شده به برنامه‌نویس اعلام کند، برنامه‌نویس می‌تواند تاریخ کدی که باگ را fix کرده بوده با تاریخ build باگ دار مقایسه کرده و از صحت fix اطمینان حاصل کند.
به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

برنامه‌ها یا فرزندان دیجیتالی برنامه‌نویسان

با برنامه‌نویسان مختلفی در دنیای واقعی و مجازی آشنا شدم که در یک چیز مشترک هستند: تعصب بر روی کد!

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

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

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

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

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

راهکارهایی برای افزایش زمان مفید در تیم‌های نرم‌افزاری

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


هیرو ناکامورا در سریال هیروز، می‌توانست بر زمان کنترل داشته باشد و در زمان سفر کند،
اما ما که نمی‌توانیم باید به دنبال راه دیگری باشیم!

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

راهکارهای سازمانی

  • محدودیت استفاده از شبکه‌های اجتماعی در شبکه سازمان: می‌توانید این‌طور در نظر بگیرید که یا کلاً شبکه‌های اجتماعی رو در ساعات اداری غیرقابل استفاده کنید یا حداقل اطلاعات دسترسی کاربران به این شبکه‌ها رو لاگ کنید و کسانی که زمان بیشتری به حضور یا فعالیت در این شبکه‌ها اختصاص می‌دهند را به شکل مقتضی اعمال قانون کنید!
  • محدودیت در استفاده از سایت‌های خبری و RSS خوان‌ها: بلای جان وقت تیم‌ها! خواندن اخبار هست حالا چه اخبار ورزشی باشد چه سیاسی چه حوادث و چه هر نوع خبر و مطلب دیگر. دلیلش هم کاملاً روشن است، همه سایت‌های خبری وقتی شما یک خبر را می‌خوانید در گوشه و کنار به شما مطالعه اخبار وسوسه کننده دیگری را پیشنهاد می‌کنند. ما یک تجربه موفق در این زمینه داشتیم: قرار گذاشتیم تا مطالعه سایت‌های خبری فقط در زمان ناهار باشد و هر شخصی که مایل بود با گوشی‌ و از طریق اینترنت بیسیم به سایت خبری دلخواه متصل شده و البته دیگران را هم در جریان اخبار بگذارد! این‌طوری زمان بررسی و تحلیل اخبار را با زمان ناهار ترکیب کردیم و زمان تلف شده به خاطر مطالعه اخبار را به حداقل رساندیم.
  • استفاده از مدل زمان‌بندی اسکرام حتی اگر از اسکرام استفاده نمی‌کنید: حتی اگر از اسکرام استفاده نمی‌کنید، استفاده از section های زمانی کوتاه (مثلاً 2 هفته‌ای) که مشابه زمان‌های اسپرینت‌های اسکرام هستند برای زمان‌بندی کارا خیلی بهتر از زمان‌بندی‌های گانت چارتی چند ماهه هست. واقعیت این است که در زمان‌بندی‌های بلندمدت شما همیشه با عوامل غیرقابل پیش‌بینی مواجه هستید که زمان‌بندی شما را به شدت تحت تاثیر قرار می‌دهند. پس از اتمام سری‌نوشته‌های فعلی، مباحث دیگری از جمله اسکرام را در قالب سری نوشته‌هایی با شما مطرح خواهم کرد.
    فعلاً صرفنظر از اینکه روش شما برای زمان‌بندی کارهایتان چیست، در نظر داشته باشید که با برنامه‌ریزی برای دوره‌های زمانی کوتاهتر شانس fail را کاهش داده و البته برنامه‌ریزی را کاراتر خواهید کرد.
  • کنترل بحث‌های حاشیه‌ای: ما اسمش را گذاشته‌ایم طرح کتابخانه. در طرح کتابخانه شما فرض می‌کنید وقتی به محل کارتان می‌آیید به یک کتابخانه قدم گذاشته‌اید. شما در کتابخانه بلند بلند با دیگران صحبت نمی‌کنید. برای اینکه با یک نفر صحبت کنید، از پشت میزتان وی را صدا نمی‌کنید بلکه بلند می‌شوید و به پشت میز وی می‌روید. با تلفن همراه صحبت نمی‌کنید. وقتی یک نفر سرگرم مطالعه است، با شروع یک مکالمه درباره بازی فوتبال دیشب یا صحبت‌های فلان مقام در تلویزیون حواسش را پرت نمی‌کنید و ... برای افزایش زمان مفید، لازم است تمرکز افراد را بر روی کارشان افزایش بدهیم. یکی از راهکارهای خیلی خوب در این رابطه فراهم کردن یک محیط آرام برای کار کردن است.
     

راهکارهای شخصی

  • محدودیت برای چک کردن ایمیل‌های داخلی و اینترنتی: شخصاً از آن آدم‌هایی بودم که همیشه ایمیل داخلی و جیمیل و ایمیل شرکتی‌ام باز بود و به محض دریافت یک notification درباره ایمیل جدید آن را مطالعه و در موارد بسیاری به آن پاسخ می‌دادم. این کار قاتل تمرکز است و باعث می‌شود زمان مفیدی که برای کارها اختصاص می‌دهید کاهش یابد. با کنترل و محدود کردن چک کردن ایمیل‌ها به افزایش راندمان کاری خودتان کمک کنید.
    مساله فوق در خصوص پیامک‌ها هم صدق می‌کند!
  • کنترل وقفه‌ها: در نوشته مربوط به قسمت سوم مهارت‌های کار تیمی نرم‌افزار توضیح دادم که چطور احترام به وقت دیگران باعث افزایش موفقیت تیم می‌شود. اگر به هر دلیل با وقفه‌های فراوانی در کارتان روبرو هستید، سعی کنید آن‌ها را مدیریت کنید. یعنی فرهنگی را ایجاد کنید که دیگران فقط برای کارهای ضروری (force) به شما مراجعه کنند و برای سایر موارد ایمیل بزنند. ساعات مشخصی در روز (مثلاً ظهر که میانه ساعت کاری است) را برای پاسخگویی به درخواست‌های دیگران در نظر بگیرید و از آن‌ها بخواهید موارد غیرضروری که امکان ایمیل‌شان نیست یا سوالات شخصی را در آن ساعات از شما بپرسند.
  • پایبندی به برنامه‌ریزی انجام شده: اولویت کارتان را در اجرای کارها طبق زمان‌بندی قرار دهید. اگر به زمان‌بندی‌ها پایبند نباشید زمان از دستتان در می‌رود و به تبع آن زمان تلف شده‌تان بدون آنکه بدانید افزایش پیدا می‌کند.
  • تهیه لیست کارهای روز و هفته: صرفنظر از زمان‌بندی انجام شده، یک لیست از کارهایی که در هفته باید انجام بدهید درست کنید و یک لیست روزانه هم از کارهای آن روز. هر کار جدیدی که وارد می‌شود (کارهای غیر زمان‌بندی شده مثل پاسخگویی به یک ایمیل یا اعلام نظر در خصوص یک جلسه کاری و ...) را به انتهای لیست اضافه کنید تا در زمان مقتضی برای آن‌ها برنامه ریزی داشته باشید. 
     

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

ساختار تیم‌های مدرن نرم‌افزار قسمت دوم: نیروی انسانی و ابزارهای مدیریت آن

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

در قسمت قبل اشاره کردم که صنعت نرم‌افزار متکی به نیروی انسانی و فکر و کار آن است و مهم‌ترین دارایی شرکت‌ها یا تیم‌های نرم‌افزاری، نیروی انسانی آن‌ها هستند. اما مدیریت و استفاده از این منبع در تولید نرم‌افزار به شکلی انجام می‌شود؟

نقش برنامه‌نویسان نینجا در تیم‌های مدرن

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

اما یک تفاوت دیگر هم در ایجاد و مدیریت تیم‌های نرم‌افزاری مدرن وجود دارد، آن هم کنترل تخصص‌های موجود در تیم است. در گذشته اگر شما می‌خواستید یک نرم‌افزار تحت وب تولید بکنید و مثلاً یک تیم 20 نفره داشتید، کارهایی که برنامه‌نویسان انجام می‌دادند شامل گستره وسیعی از مهارت‌ها می‌شد. برای همین است که اگر رزومه من و هم نسل‌های من را نگاه کنید می‌بینید همه ما دارای مهارت‌های مختلفی در توسعه نرم‌افزارهای تحت وب هستیم مثلاً تسلط کامل به html یا css یا jQuery و یک یا چند فناوری برای تولید صفحات پویا از قبیل ASP یا PHP یا ASP.NET MVC و ...
امروز اما برای نتیجه‌گیری بهتر، توسعه‌دهنده‌ها تشویق می‌شوند که در حوزه‌های خاصی مهارت‌های خودشان را گسترش بدهند، بنابراین همان 20 نفری که مثال زدم به جای اینکه 20 نفر همه کاره (حالا با سطح بالا و پایین) باشند، ممکن است ترکیبی از 3 تیم مختلف 6 یا 7 نفره باشند که هر تیم، به صورت تخصصی روی بخشی از پروژه کار می‌کند. یک تیم مثلاً روی رابط کاربری کار می‌کند و مثلاً برنامه‌نویسی کلاینت را انجام می‌هد، تیم دیگر برنامه‌نویسی سرور و پیاده‌سازی لایه‌های کار با داده را انجام می‌دهد و تیم سوم هم مثلاً ترکیبی از معماران و تست‌کننده‌ها و نویسندگان فنی است. البته درباره نقش‌های مختف مورد نیاز در تیم‌های نرم‌افزاری بیشتر خواهم نوشت.

ابزارهای مدیریت برای نیروی انسانی

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

وقتی در قسمت اول از تست جوئل درباره source contol می‌گفتم اشاره کردم که TFS را ترجیح می‌دهم و گفتم این انتخاب دلایل دیگری نیز دارد. در TFS فقط مساله source control نیست، ضمن اینکه اگر از source control مایکروسافت خوشتان نمی‌آید می‌توانید در نسخه‌های جدید از git‌ استفاده کنید.
TFS علاوه بر source control یک محیط یکپارچه برای تولید نرم‌افزار در اختیار تیم‌های نرم‌افزاری قرار می‌دهد. با استفاده از مفاهیم اسکرام می‌توانید تولید خود را برنامه‌ریزی کنید یعنی backlog های خود را وارد کنید و برنامه‌ریزی sprint ها را انجام دهید. TFS با Visual Studio کاملاً یکپارچه است و از داخل خود Visual Studio می‌توانید bug یا task ایجاد کنید و یا درخواست code review داشته باشید. علاوه بر مواردی که مربوط به کد یا برنامه‌ریزی است، می‌توانید build ها را تعریف و مدیریت کنید و شکست یا موفقیت در تولید build را مشاهده کنید.
برای ذخیره مستندات مربوط به پروژه می‌توانید از یکپارچگی که با شیرپوینت دارد استفاده کنید و در نهایت با کمک Microsoft Test Manager و یکپارچگی که با TFS دارد، می‌توانید تست پلن‌ها و تست کیس‌های خود را که می‌تواند تست اتوماتیک یا تست انسانی باشد را تعریف و مدیریت کنید.

این نوشته ادامه دارد. 

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

مهارت‌های کار تیمی نرم‌افزار قسمت چهارم: دریافت و استفاده از فیدبک کاربران

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

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

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

بررسی یک مثال: فیدبک‌های Visual Studio

تیم Visual Studio از سرویس سایت UserVoice برای دریافت فیدبک‌ها استفاده می‌کنه. در این سایت کاربران تا این لحظه بیش از 6600 ایده برای اضافه شدن به امکانات Visual Studio ارائه دادند. آیا تیم Visual Studio همه این ایده‌ها را خوانده‌اند؟ آیا همه را اجرا کرده‌اند؟ آیا قصد برنامه‌ریزی برای اجرای همه این ایده‌ها را دارند؟ پاسخ به تمام سوالات قبلی منفی است.
تیم Visual Studio بعضی از مواردی که بیشترین رای را می‌آورند در دستور کار توسعه نرم‌افزارشان قرار می‌دهند. 

همانطور که اشاره کردم در پاسخ به توییت رضا، از عبارت جنگ فیدبک‌ها استفاده کردم. واقعیت این است که سلیقه کاربران با هم متفاوت است و گاهی این سلیقه متفاوت باعث می‌شود که یک کاربر یک ایده داشته باشد که کاربر دیگر با همان ایده کاملاً مخالف باشد!
مثلاً در تیم ما یک نرم‌افزار کوچک دیکشنری برای شیرپوینت ایجاد شده که یکی از قابلیت‌های آن ارائه کلمات مشابه هست. کاربران مختلف این نرم‌افزار تا کنون فیدبک‌های مختلفی درباره این قابلیت به خصوص داشتند، مثلاً یکی از آن‌ها انتظار داشت که نرم‌افزار کوچک و ارزانی مانند این، مثل پیشنهاد کلمه گوگل هنگام جستجو باشه! یعنی اگر کلمه رو با املا اشتباه جستجو کنی کلمه درست رو بهت پیشنهاد میده (و بر اساس الگوریتم‌های پیچیده از نتیجه میلیون‌ها جستجو بدست آمده) یا مشتری دیگری چیزی مشابه Typeahead مد نظرش بود و ...
هدفم از گفتن مثال دیکشنری این بود که بدونید بعضی اوقات کاربرها سر امکاناتی که از نرم‌افزار انتظار دارند با هم یک صدا نیستند. برای این که مجبور نباشید به ساز همه برقصید، امکانی فراهم کنید که کاربران بتوانند در خصوص نظراتشان با هم بحث کنند. آدم‌ها به صورت ذاتی به بحث و در موارد اظهار فضل تمایل دارند، از این میل ذاتی می‌توانید برای بهبود نرم‌افزارتان استفاده کنید و ایده‌هایی را دریافت کنید که شاید خودتان هیچ وقت به آن‌ها فکر نکرده بودید!
خوبی دریافت فیدبک از کاربران به این روش این است که شما نه ایده‌هایی که یک باره و بر اساس یک نیاز آنی و در شرایطی خاص به ذهن یک نفر رسیده بلکه ایده‌ها و فیدبک‌ها و نیازهایی که کاربران زیادی آن را از شما طلب می‌کنند و بعد از بحث و سبک و سنگین کردن درباره‌اش به نتیجه می‌رسند را پیش رویتان خواهید داشت.

* از عبارت پست امروز استفاده کردم. در این سایت از ابتدا تا امروز هر روز نوشته‌ای داشتم. چند مورد استثنا البته پیدا می‌شود که یا به دلیل باقی ماندن نوشته در جمع نوشته‌های پیش‌نویس یا به دلیل انتشار در دقایقی بعد از نیمه شب بوده!
تلاشم این است که تا جای ممکن هر زمان کاربری به سایت مراجعه می‌کند مطلب جدیدی برای خواندن وجود داشته باشد. فیدبک‌هایی هم از دوستان برای بهتر شدن سایت دریافت کردم که آن‌ها را به تدریج اجرایی خواهم کرد.
این‌ توضیح را نوشتم تا فقط تشکر کنم از همراهی هر روزه شما. 

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی