فرآیند تولید نرمافزار: هفت مرحله و خروجی هرکدام
اگر از ده تیم بپرسید نرمافزار چطور ساخته میشود، ده جواب میگیرید که همهشان حول «تحلیل، طراحی، کدنویسی، تست» میچرخند. این جواب غلط نیست، ولی چیزی را پنهان میکند: کدنویسی کوچکترین بخش هزینه است.
هزینهٔ واقعی جای دیگری است — در تصمیمی که مکتوب نشد و شش ماه بعد از نو گرفته شد، در باگی که در تولید کشف شد چون کسی نمیدانست چطور باید تستش کند، در انتشاری که سه ساعت طول کشید چون فقط یک نفر بلد بود انجامش دهد.
این مقاله نقشهٔ کل مسیر است. هفت مرحله، و برای هرکدام یک سؤال: چه چیزی از این مرحله بیرون میآید که بتوان به کسی تحویلش داد؟ اگر جواب «یک جلسهٔ خوب» باشد، آن مرحله انجام نشده.
۱. کشف: تعریف مسئله پیش از تعریف راهحل
بیشتر پروژههایی که شکست میخورند در پیادهسازی شکست نمیخورند. در تعریف شکست میخورند — چیزی ساخته میشود که درست کار میکند و مسئلهٔ کسی را حل نمیکند.
خروجی این مرحله سه چیز است: نقشهٔ فرایند فعلی (کار امروز واقعاً چطور انجام میشود، با اکسل و تلفن و کاغذ)، فهرست نیازمندیهای آزمونپذیر، و — مهمتر از هر دو — فهرست چیزهایی که صراحتاً ساخته نمیشوند.
آن فهرست سوم را کسی دوست ندارد بنویسد، و نبودنش تنها دلیل افزایش خزندهٔ دامنه است. «فرض کردیم این هم هست» جملهای است که در ماه چهارم پروژه گفته میشود و همیشه گران است.
جزئیات این مرحله در کشف و تعریف آمده.
۲. معماری: تصمیمهایی که تغییرشان گران است
معماری یعنی مجموعهٔ تصمیمهایی که بعداً عوض کردنشان هزینه دارد: مدل داده، مرز بین سرویسها، پایگاه داده، مدل دسترسی، و آنچه صنعت «نیازمندیهای غیرکارکردی» مینامد — یعنی سرعت، بار همزمان، دسترسپذیری و محرمانگی.
دو نکته که در عمل بیشترین تفاوت را میسازند:
اول، عدد بنویسید نه صفت. «سامانه باید سریع باشد» یک نیازمندی نیست. «پاسخ جستوجو زیر ۴۰۰ میلیثانیه برای ۹۵ درصد درخواستها، تا ۲۰۰ کاربر همزمان» یک نیازمندی است، چون قابل رد شدن است. این تفکیک را در بودجهٔ کارایی باز کردهایم.
دوم، امنیت اینجا شروع میشود، نه در تست. مدل دسترسی و مرزهای اعتماد تصمیمهای معماریاند؛ اگر تا مرحلهٔ تست عقب بیفتند، آنچه پیدا میکنید نه یک باگ که یک بازنویسی است. مدلسازی تهدید روش ساختاریافتهٔ همین کار است.
هر تصمیم این مرحله باید ثبت شود همراه با گزینههای ردشده. سندی که فقط برنده را مینویسد، همان بحث را شش ماه بعد باز میکند.
۳. طراحی: پیش از آنکه کدی نوشته شود
طراحی رابط، معماری اطلاعات و مسیر کاربر. این مرحله در پروژههای سازمانی بیش از همه حذف میشود و بیش از همه هزینه میسازد، چون تغییر یک صفحه روی کاغذ ارزان است و تغییرش بعد از ساخت بکاند نیست.
خروجی: وایرفریم، طرح نهایی، و تحویل طراحی به تیم فنی که فایل طراحی نیست — مجموعهای از حالتهاست: خالی، در حال بارگذاری، خطا، متن بلند فارسی، عدد بزرگ.
۴. برنامهریزی: تبدیل دامنه به توالی
اینجا معلوم میشود چه چیزی اول ساخته میشود و چرا. سه خروجی: بکلاگ اولویتبندیشده، برآورد با بازهٔ صادقانه نه یک عدد، و تعریف اتمام کار.
آن سومی را جدی بگیرید. تیمی که «تمام شد» را تعریف نکرده، سرعتش قابل اندازهگیری نیست — چون هر بار چیز متفاوتی تمام شده.
۵. ساخت: جایی که همه فکر میکنند کار آنجاست
کدنویسی، یکپارچهسازی، بازبینی. آنچه در این مرحله کیفیت را تعیین میکند بیشتر از خود کد، رویههاست:
- بازبینی کد — که کارش پخش دانش است، نه صرفاً پیدا کردن باگ.
- راهبرد مدیریت خطا — کدی که وقتی میشکند میگوید چرا شکست.
- بازآرایی مستمر بهجای «بازنویسی بزرگ» که هیچوقت زمانش نمیرسد.
- امنیت وابستگیها. بیشتر کد یک سامانهٔ امروزی را خودتان ننوشتهاید؛ زنجیرهٔ تأمین نرمافزار بخشی از سطح حملهٔ شماست.
۶. راستیآزمایی: تست، کارایی، امنیت
تست صد درصدی هدف نیست و هیچوقت نبوده. سؤال درست این است که کدام خرابی برای این کسبوکار گران است و ارزانترین راه گرفتنش کدام است — که استراتژی تست به آن میپردازد.
سه چیز که معمولاً از قلم میافتند:
دادهٔ تست. تیمها استراتژی تست مینویسند و بعد با یک کپی از پایگاه دادهٔ تولید کار میکنند. دادهٔ تست هم مسئلهٔ کیفیت است هم مسئلهٔ حریم خصوصی.
رگرسیون. هر باگی که در تولید پیدا میشود باید یک تست بشود، وگرنه دوباره برمیگردد. چرا و چطور.
بار. تست بار را روز قبل از راهاندازی انجام دادن، یعنی کشف مسئله در گرانترین لحظهٔ ممکن.
۷. انتشار و بهرهبرداری: جایی که نرمافزار زندگی میکند
انتشار باید کسلکننده باشد. اگر شب انتشار پرتنش است، مسئله در آن شب نیست؛ در فرایندی است که به آن رسیده.
- خط لولهٔ ساخت و تحویل و اینکه چطور قابل اعتماد بماند.
- محیطها و پیکربندی — تفاوت واقعی محیط تست با تولید معمولاً همان چیزی است که در انتشار میشکند.
- راهبرد استقرار: آبی‑سبز، قناری، پرچم قابلیت.
- پایش و لاگ و مدیریت رخداد.
و بعد چیزی که مرحلهٔ هشتم نیست بلکه حلقه است: بازخورد. تلمتری محصول دادهای میدهد که بکلاگ بعدی از آن ساخته میشود، و SLO و بودجهٔ خطا تصمیم میگیرد که دور بعد صرف قابلیت جدید شود یا صرف پایداری.
ترتیب اهمیت دارد، مرحلهبندی سفت نه
این هفت مرحله یک آبشار نیست. در یک پروژهٔ واقعی همهشان همزمان در جریاناند: تیم روی قابلیت هفتم کد میزند، قابلیت پنجم در تست است و قابلیت سوم در تولید بازخورد میگیرد.
آنچه ثابت میماند ترتیب برای هر تکه کار است. هیچ تکهای بدون معیار پذیرش وارد ساخت نمیشود و هیچ تکهای بدون تست وارد تولید نمیشود. مرحلهها را برای پروژه اجرا نکنید؛ برای هر قابلیت اجرا کنید.
علائم اینکه یک مرحله واقعاً انجام نمیشود
از تجربهٔ ممیزی پروژههای دیگران، این پنج علامت تقریباً همیشه درستاند:
۱. کسی نمیتواند بگوید نسخهٔ فعلی تولید دقیقاً کدام کد است. ۲. «چرا اینجوری پیاده شده؟» جوابی جز «قبل از من بوده» ندارد. ۳. انتشار در ساعت اداری انجام نمیشود. ۴. باگها از طریق مشتری کشف میشوند، نه از طریق هشدار. ۵. تخمینها همیشه یک عدد است، هیچوقت یک بازه.
هرکدام از اینها یک مرحلهٔ حذفشده را نشان میدهد و همهشان قابل ترمیماند — معمولاً بدون توقف کار.
اگر میخواهید ببینید ما اینها را در عمل چطور اجرا میکنیم، شیوهٔ کار ما همین را قدمبهقدم نوشته، و چرخهٔ تولید خروجی هر گام را جداگانه فهرست میکند.