توسعه

بسیاری از CTOها از پیشینه مهندسی می‌آیند و غرق ساختن و تولید کد بوده‌اند. آن‌ها تکامل پیدا کرده و از رده‌های توسعه بالا آمده‌اند، پروژه‌های بزرگ‌تر و مسئولیت بیشتری گرفته‌اند. هر توسعه‌دهنده روش خودش را برای انجام کارها دارد؛ نشان خودش را که دوست دارد روی چیزی بگذارد. همین است که زندگی توسعه را جذاب می‌کند: آزادی خلاق برای انجام آنچه لازم است. وقتی نوبت ساختن یک تیم یا رشد دادن یک سازمان می‌رسد، باید از آن جهان بیرون آمد و گسترده‌تر فکر کرد؛ بیشتر به شکل جمعی و کمتر به شکل فردی. چیزی که یک روز هوشمندانه و جذاب بود، برای فرد دیگری دردسر نگهداری و سازگار کردن می‌شود.

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

۹.۱ برنامه‌ریزی پروژه

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

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

۹.۱.۱ مدیر پروژه

دو نوع سازمان وجود دارد: آن‌هایی که مدیر پروژه خوب دارند و آن‌هایی که ندارند. دلیل نداشتن مدیر پروژه اختصاصی می‌تواند از نداشتن بودجه برای او، که منطقی است، تا نیاز نداشتن به او چون CTO بلد است پروژه را مدیریت کند، که منطقی نیست، گسترده باشد. دلیل نداشتن هرچه باشد، به محض اینکه گروه مهندسی از حدود پنج نفر بزرگ‌تر شد، مدیر پروژه اختصاصی ضروری است. با کمتر از آن، بیشتر گروه‌ها می‌توانند میان خودشان هماهنگ شوند. برای ادامه بحث، فرض کنیم اسکرام‌مسترها هدف‌هایی مشابه مدیر پروژه دارند. هرچند می‌توان درباره تفاوت‌های ظریف بحث کرد، روح نقششان بسیار شبیه است. مدیر پروژه آنجاست تا با کمک به مدیریت و گزارش وضعیت همه منابع، پیش‌بینی و به‌روزرسانی مداوم زمان‌بندی‌ها بر اساس رخدادهای روزانه، به شما در اجرای چشم‌اندازتان کمک کند. برخلاف باور رایج، مدیر پروژه مأمور وظیفه دادن یا نگه داشتن افراد در برابر پاسخ‌گویی نیست؛ این نقش لیدهاست. اگر ضرب‌الاجلی در خطر لغزش باشد، او خیلی سریع می‌تواند آن را و دلیل لغزش را به شما بگوید و به شما فرصت اقدام اصلاحی، اگر شدنی باشد، بدهد. او جلسه‌های دوره‌ای گوناگون را اجرا می‌کند و چشم نزدیکی بر هر سیستم تیکتینگ نگه می‌دارد تا نبضی نزدیک به بلادرنگ از خروجی گروه داشته باشد. بهترین افراد در این نقش‌ها جریان آزاد اطلاعات، خبر خوب یا بد، را تشویق می‌کنند تا بتوانند زمان‌بندی را درست در دست داشته باشند. افراد این نقش‌ها ژن سازمان‌دهی به ارث برده‌اند، همراه با نگاه عملی به زندگی و رویکرد فرایندی روش‌مند. هرچند ما فناوران خودمان را فریب می‌دهیم که در روز بیش از ۲۴ ساعت وجود دارد، آن‌ها می‌دانند در یک روز کاری معمولی واقعا فقط شش ساعت وجود دارد، با احتساب استراحت، ناهار، رفتن به سرویس، خیال‌پردازی و مانند آن. آن‌ها می‌دانند وقتی کسی از تعطیلات برمی‌گردد زمان لازم دارد تا دوباره به سرعت برسد، در حالی که ما باور داریم همان لحظه‌ای که از یک تعطیلات دو هفته‌ای کنار ساحل و کاملا جدا از هیاهوی محل کار برمی‌گردیم، می‌توانیم بهره‌ور باشیم. مدیریت پروژه علم نیست، هنر است؛ گرفتن منظره‌ای همیشه در حال تغییر، فیلتر کردن نویز و تنظیم مداوم مسیر برای هدف گرفتن نشانه.

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

• به دست گرفتن خروجی هر منبع
• شناسایی مایل‌استون‌ها و اقلام قابل تحویل
• پیش‌بینی و بهبود مداوم دقت ضرب‌الاجل‌ها
• هماهنگ کردن چرخه‌های انتشار
• مدیریت تحویل‌گیری و تحویل‌دهی بین مایل‌استون‌ها و ارتباط با تیم‌های داخلی/خارجی
• ارائه اقدام‌های عملی بر اساس داده، برای کمک به بهبود مدیریت زمان شما
• گزارش وضعیت همه موارد و مطمئن شدن از اینکه هیچ چیز گم نمی‌شود یا از رادار نمی‌افتد

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

سیستم تیکت

دانستن اینکه تیم شما در هر لحظه روی چه چیزی کار می‌کند، از جمله آنچه برایشان برنامه‌ریزی شده، برای اداره گروهی با هر اندازه حیاتی است. فناوران عموما افرادی هستند که عاشق تمام کردن کارها هستند؛ ما فهرست وظایف را دوست داریم، همراه با رضایت علامت زدن یک مورد به عنوان کامل‌شده. با کنار هم گذاشتن این دو چیز، می‌بینید چرا سیستم‌های تیکت روش شماره یک مدیریت وظایف در فناوری هستند، با استاندارد صنعتی Atlassian Jira که تیکت‌ها را به سطحی کاملا تازه می‌برد.

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

۹.۱.۲ تعریف پروژه‌ها

در سطحی بالا، همه می‌توانیم توافق کنیم پروژه چیست: مجموعه‌ای از وظایف، گروه‌بندی‌شده، که پس از تکمیل، یک نتیجه مطلوب را شکل می‌دهد. جایی که بحث‌های جالب شروع می‌شود دامنه پروژه است: یک وظیفه پیش از آنکه پروژه محسوب شود چقدر باید بزرگ باشد؟ پروژه می‌تواند چند روز یا چند سال دامنه داشته باشد. فارغ از طول زمان، پروژه باید هدف تعریف‌شده‌ای داشته باشد؛ دلیل اینکه پروژه اساسا وجود دارد. هدف درباره اینکه چیزی چگونه انجام می‌شود یا حتی تکمیل آن چقدر باید طول بکشد صحبت نمی‌کند. فقط معیار موفقیت را تعریف می‌کند؛ معیاری که وقتی برآورده شود پروژه کامل محسوب می‌شود. خروجی‌های پروژه را با عباراتی بنویسید که افراد بیرون از گروه مهندسی هم بفهمند. این شفافیت و ارتباط را تقویت می‌کند، به‌ویژه با CEO/CFO شما که می‌خواهند بفهمند شما و تیم کجا زمان و پول صرف می‌کنید. نمونه‌ای از یک پروژه با دو تعریف متفاوت چنین است:

• داخلی: ارتقای فرایند پذیرش مشتری، حذف وابستگی به Windows XP و بازنویسی آن با Java در محیط بی‌سرور.
• بیرونی: مدرن‌سازی فرایند پذیرش مشتری، بازنویسی آن برای ابر با انعطاف‌پذیری بیشتر و توان عملیاتی بالاتر.

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

مدل آبشاری

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

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

چابک

اگر مدل آبشاری یعنی همه چیز را پیش از شروع بدانید، سر دیگر طیف چابک است؛ ساختن مسیر در حین حرکت. این جمله کمی سبک‌سرانه است؛ ممکن است همه مشکلات پیش از شروع کاملا فهمیده یا حل نشده باشند. چابک، برگرفته از چابکی، توانایی واکنش به محیطی در حال تغییر است؛ برداشتن گام‌های تدریجی، همه در پی نزدیک‌تر شدن به خروجی نهایی و چابک بودن برای عبور سریع و موفق از هر تغییر. مثلا به پروژه رانندگی به سان‌فرانسیسکو برگردیم: در پروژه چابک، به محض اینکه بدانیم چگونه از فلوریدا خارج می‌شویم، می‌توانیم بگذاریم تیم تا مرز فلوریدا حرکت کند، در حالی که مرحله‌های بعدی برنامه‌ریزی می‌شوند. در واقعیت، چابک مجموعه‌ای از راهنماها و اصول است که بر تحویل پیوسته خروجی‌ها تمرکز دارد و همه ذی‌نفعان پروژه، از جمله مشتری یا کاربر نهایی، در آن درگیرند تا کیفیت بالاتر شود، چون مسائل بسیار زودتر شناسایی و اصلاح می‌شوند. برداشت نادرست رایج درباره چابک این است که مساوی نبود برنامه‌ریزی است، که نمی‌تواند دورتر از حقیقت باشد. پروژه در چابک همچنان به برنامه‌ریزی نیاز دارد، فقط نه با همان جزئیات رویکرد آبشاری. در عوض، مایل‌استون‌ها، یا اپیک‌ها به زبان چابک، شناسایی می‌شوند و سپس به مجموعه‌ای از وظایف آماده اجرا تبدیل می‌شوند. این وظایف بعد در دوره‌های کوتاه کوچک فعالیت، یا اسپرینت‌ها، چیده می‌شوند. این‌ها معمولا یک یا دو هفته طول می‌کشند و پس از آن بازبینی می‌شود که کارها چقدر خوب پیش رفت. معمولا اسپرینت‌ها برای تحویل بخشی از کارکرد طراحی می‌شوند تا اگر ممکن باشد دیگران بتوانند با نتیجه نهایی تعامل کنند. چابک می‌تواند بسیار فرایندمحور باشد، که در آغاز ترسناک است. بیشتر مجموعه‌ای از راهنماهاست تا قوانین سخت و سریع که باید پیروی شوند؛ چارچوبی که تلاش می‌کند برای چالشی مبهم سطحی از نظم و جریان فراهم کند. بعضی سازمان‌ها آن‌قدر درگیر قوانین می‌شوند که همه لذت و انعطاف‌پذیری را از پروژه می‌گیرند. پیدا کردن تعادلی که برای تیم شما کار کند، فلسفه چابک را موفق می‌کند. فرایند اسکرام یکی از نمونه‌های روش چابک است. پروژه چابک می‌تواند تغییرات را بسیار آسان‌تر ایجاد و جذب کند، چون فرصت زیادی برای دیدن اینکه چیزی جواب می‌دهد یا نه وجود دارد، بسیار پیش از آنکه زمان زیادی روی آن هدر برود. انعطاف‌پذیری کلید موفقیت چارچوب چابک است. حوزه‌هایی را شناسایی کنید که با شیوه فعلی کار شما طبیعی‌اند، سپس به‌آرامی در طول زمان نظم بیشتری اضافه کنید و تیم را هم‌زمان با مزایا و موفقیت‌ها گرم کنید. برای مرور عمیق‌تر روش‌های چابک و آبشاری، به این نشانی مراجعه کنید: https://www.guru99.com/waterfall-vs-agile.html.

۹.۲ استانداردهای توسعه

هرچند وسوسه‌انگیز است که بگذارید تیم‌های توسعه کار خودشان را انجام دهند، بدون استاندارد یا راهنما، با رشد شما در آینده مشکل ایجاد خواهد کرد. آخرین چیزی که می‌خواهید، بلوک‌های بزرگ کدی است که برای موفقیت کسب‌وکار حیاتی‌اند اما دست‌نزدنی، شکننده و پیچیده‌اند، و فقط تعداد انگشت‌شماری از افراد آن‌قدر جرئت دارند که از ترس پیامدها تغییری در آن‌ها بدهند. هر شرکت «بلوک‌های کد مقدس» خودش را دارد که در طول سال‌ها اسطوره‌ای از خود پیدا کرده‌اند؛ پیچیدگی‌ای ادراک‌شده. به محض اینکه کسی پیشنهاد بازنویسی آن‌ها را می‌دهد، نفس‌های عمیق و طولانی کشیده می‌شود و سرها تکان می‌خورد، در حالی که بزرگان تیم هر تلاشی برای اصلاح، چه برسد به بازنویسی، را منصرف می‌کنند. همان‌طور که بارها در این کتاب اشاره شد، نقش شما به عنوان رهبر فناوری فقط حل مسائل روز نیست، بلکه گذاشتن پایه برای آینده است. سیستم‌هایی که اکنون توسعه می‌یابند باید سال‌های زیادی در آینده پشتیبانی و گسترش داده شوند، معمولا بسیار فراتر از دوره حضور شما. استانداردها کمک می‌کنند روایت مشترکی درباره اینکه کد چگونه باید ساختار یابد، چیده شود و نوشته شود شکل بگیرد و پرورش پیدا کند. کدنویسی برای مقیاس‌پذیری و خوانایی تلاش می‌خواهد، چون بسیاری از توسعه‌دهندگان باور دارند کدشان دست‌نزدنی است و هیچ نوع بازبینی لازم ندارد. مراقب این نوع افراد باشید، سریع پیدایشان کنید و اگر نمی‌توانید تغییرشان دهید، رهایشان کنید. چون کدنویسی بیشتر هنر است تا علم، افراد می‌توانند در میدان بزرگی از ابهام بازی کنند. چیزی که برای یک توسعه‌دهنده منطقی یا طبیعی است، برای دیگری بیگانه و ناهنجار به نظر می‌رسد. توسعه‌دهندگان عادت بدی دارند که اگر چیزی را نمی‌فهمند، فقط بازنویسی‌اش می‌کنند؛ ضرب‌المثل «از چاله به چاه افتادن» آشناست؟ بنابراین به نفع همه است که کد طوری توسعه یابد که به‌راحتی خوانده و فهمیده شود، با روش‌ها و الگوهای مشترک. خبر خوب این است که این مشکل کمیاب نیست. همه زبان‌های اصلی استانداردهای مختلفی درباره اینکه چیزها چگونه باید ساخته شوند دارند، پس لازم نیست چرخ را دوباره اختراع کنید. پایبندی پایه به استانداردها نسبتا ساده است و با ابزارهای شخص ثالثی که به بیشتر IDEها وصل می‌شوند قابل اعمال است. همچنین می‌توانید به ابزارهایی نگاه کنید که چرخه ساخت کد را تقویت می‌کنند و پیش از استقرار کد آن را بررسی می‌کنند. SonarQube ابزار متن‌باز رایجی است که همه زبان‌های محبوب را پوشش می‌دهد و میان بسیاری موارد دیگر، اعلان‌های متغیر آویزان، دام‌های اشاره‌گر تهی و بن‌بست‌های منطقی، یعنی جاهایی که نمی‌توانید از آن بیرون بیایید، را پیدا می‌کند. استانداردهای کدنویسی فقط قالب‌بندی کد در یک فایل متنی نیستند. می‌توانند الگوهای طراحی مشترک را تعریف کنند؛ مثلا چگونه باید برای تعامل با پایگاه داده آماده شوید یا لاگ خروجی بدهید. مهم‌تر از آن، باید راهنمایی کنند که کد چگونه ساختار یابد، تراکم تابع‌ها و سلسله‌مراتب کلاس چگونه باشد، تا قراردادهای نام‌گذاری. این چیزها می‌توانند کم‌کم و قطعه‌قطعه تکامل یابند و استاندارد تیم شما را بسازند. بازبینی کد باید منظم انجام شود و هیچ‌کس نباید حس کند کدش فراتر از نقد است؛ از جمله کد شما، اگر هنوز با کلاه CTO خود کد مشارکت می‌کنید. کد باید خوانا، قابل نگهداری و بالاتر از همه، تا حد ممکن بدون خطا باشد. استانداردها و بازبینی کد کمک می‌کنند این واقعیت شود.

۹.۳ کنترل نسخه

کنترل نسخه (VC) کتابخانه و خزانه زمان برای همه دارایی‌های دیجیتال شماست که در یک چیز جمع شده‌اند. کنترل نسخه که زمانی فقط توسط تیم‌های توسعه بزرگ استفاده می‌شد، خود را در DNA کدنویسی تنیده و حتی راهش را به حوزه‌های دیگر کسب‌وکار باز کرده است، با چیزهایی مثل Google Docs که هیچ ویرایشی را روی اسناد ساده شبیه Office فراموش نمی‌کند. VC در طول سال‌ها بسیار تکامل یافته است، از CVS تا SVN تا Git، که محبوب‌ترین است؛ GitHub یکی از بزرگ‌ترین مخزن‌های نرم‌افزار متن‌باز است. با این حال اصل راهنما همان است: ممکن کردن توسعه موازی توسط یک یا چند توسعه‌دهنده، به شکلی که متکی به این نباشد که توسعه‌دهندگان محیط‌های توسعه خود را برای نگه داشتن نسخه‌های مختلف به شکل‌های عجیب خم کنند. تصور کنید در میانه توسعه بزرگ یک نسخه تازه هستید و باید باگی را در سیستم تولید فعلی اصلاح کنید. باید کد منبعی را داشته باشید که در تولید اجرا می‌شود، بدون ویژگی‌های تازه، تا بتوانید با اطمینان باگ را اصلاح و کد را منتشر کنید، بی‌آنکه نگران نشت کارهای تازه به جهان بیرون باشید. بعضی تیم‌های توسعه هیچ نوع کنترل نسخه‌ای را نپذیرفته‌اند. گاهی دایرکتوری‌هایی از نسخه‌های منتشرشده نگه می‌دارند یا شاید حتی فایل فایل فشرده گاه‌به‌گاه. همه بهانه‌ها برای وارد نشدن، از اینکه نیاز ندارند، تا اینکه زبان برای ثبت ورود و خروج نسخه مناسب نیست، تا اینکه فقط سرعتشان را کم می‌کند، کاملا بی‌اعتبارند. اصل ماجرا ترس از ناشناخته است.

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

انتخاب دانه‌بندی درست برای مخزن بیشتر هنر است تا علم و هیچ راه‌حل واحدی وجود ندارد که برای همه مناسب باشد. چند نکته برای تصمیم‌گیری درباره مخزن:

• آیا کارکرد یا نقش تعریف‌شده‌ای دارد؟
• آیا مجموعه مهارت متفاوت یا محدودتری برای نگهداری این مؤلفه لازم است؟ این مؤلفه چگونه با مؤلفه‌های دیگر ارتباط دارد؟
• این مؤلفه یا پروژه چگونه منتشر می‌شود؟

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

• Gitflow: دو شاخه اصلی استفاده می‌شود: مستر، که همه کد اینجا قابل استقرار است، و دولوپ. برای هر توسعه‌ای، شاخه ویژگی از دولوپ می‌سازید که سپس بازبینی و دوباره در دولوپ ادغام می‌شود. برای ساختن انتشار، ادغامای از دولوپ به مستر می‌سازید و آن را بیرون می‌دهید. هیچ کدی مستقیم به شاخه مستر یا دولوپ ثبت نمی‌شود.
• GitHub Flow: نسخه ساده‌تر Gitflow، فقط با شاخه اصلی مستر. هر توسعه‌ای با شاخه گرفتن به یک شاخه ویژگی انجام می‌شود که پس از بازبینی و آزمون، در مستر ادغام می‌شود و آماده استقرار است.

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

۹.۴ تضمین کیفیت (QA)

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

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

• آزمون دستی؛ آزمون‌های خودکار

۹.۴.۱ آزمون دستی

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

۹.۴.۲ آزمون‌های خودکار

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

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

۹.۵ CI/CD

ساختن و استقرار نرم‌افزار کار پیچیده‌ای است؛ اجازه ندهید کسی چیز دیگری به شما بگوید. تیم‌ها نیز بزرگ‌تر و توزیع‌شده‌تر می‌شوند، با دست‌های بیشتری در کدبیس در هر زمان و اعضایی که می‌آیند و می‌روند. پس با پیچیدگی بیشتر و سیالیت تیم، چگونه کنترل زیرساخت کد را طوری حفظ می‌کنید که تضمین کند همه بتوانند دقیقا به همان راهکار ساخت کنند؟ خط لوله‌های کد، یا CI/CD، یعنی یکپارچه‌سازی پیوسته/استقرار پیوسته، پاسخ‌اند.

شکست اسکن امنیتی، مثل باقی گذاشتن گذرواژه‌ها یا کلیدهای کدنویسی‌شده به شکل ثابت

• ناهم‌راستایی پایگاه داده

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

۹.۶ بدهی فنی

تصور کنید خودرویی را می‌رانید اما هرگز سرویسش نمی‌کنید، یعنی روغن، فیلترها و تایرها را عوض نمی‌کنید. البته در کوتاه‌مدت کمی پول صرفه‌جویی می‌کنید، اما هر بار که این کارهای نگهداری را رد می‌کنید، کمی «بدهی خودرو» ایجاد می‌کنید. در نقطه‌ای، آن بدهی از ارزش خودرو بیشتر می‌شود و روزی موتور قفل می‌کند یا تایرها در بزرگراه می‌ترکند و هزینه بسیار بزرگ‌تری برای اصلاح به بار می‌آورد. بنابراین ارزان‌تر است که موارد کوچک را به‌موقع انجام دهید تا از قطعی‌ها یا هزینه‌های بزرگ و غیرمنتظره دور بمانید. همین اتفاق در سازمان رخ می‌دهد، اما به جای خودرو، با کد منبع یا سیستم‌ها. هر بار که میان‌بری زده می‌شود، مثل ثابت‌نویسی کردن یک مقدار، انجام حداقل بررسی‌ها روی یک تابع، یا اعمال نکردن وصله امنیتی یا ارتقا، بدهی فنی ایجاد می‌کنید. بدهی فنی به شکل طبیعی در جریان اداره سازمانی پرشتاب رخ می‌دهد. این اشکالی ندارد و برای انجام کار حتی تشویق می‌شود. با این وجود، آن را مثل استفاده از کارت اعتباری ببینید: اشکالی ندارد هزینه کوتاه‌مدت را روی کارت بگذارید، اما مطمئن شوید آخر ماه پرداختش می‌کنید. چقدر زمان باید صرف پرداخت بدهی فنی کنید؟ این تا حد زیادی به نوع سازمان شما بستگی دارد، اما قاعده تجربی خوب این است که بین ۱۰٪ تا ۳۰٪ خروجی تیم شما باید به حذف بدهی اختصاص یابد. اندازه‌گیری مقدار بدهی در کد منبع با ابزارهای درست کیفیت کد در خط لوله شما می‌تواند نسبتا آسان باشد؛ SonarQube باز هم نمونه خوبی است. در بخشی از فرایند بازبینی کد، انتشار و ارتقا، ایده خوبی است بدهی فنی را وقتی می‌بینید علامت‌گذاری کنید و برای بعد به صف کار اضافه کنید. برای مثال، قطعه‌ای از کد ممکن است توسط ابزار تحلیل کد علامت نخورد، چون از نظر نحوی کاملا قانونی است، اما شما می‌دانید اصلاح کوتاه‌مدتی بوده که باید دوباره انجام شود تا کمی جامع‌تر باشد. CTO خوب می‌داند گروهش در هر لحظه چه سطحی از بدهی فنی را حمل می‌کند. نکته خوب، به‌ویژه اگر در اسپرینت کار می‌کنید، این است که بین هر دو یا سه اسپرینت یک دوره استراحت در نظر بگیرید تا زمان پرداختن به بدهی فنی را داشته باشید.

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

بین هر دو یا سه اسپرینت در نظر بگیرید تا زمان پرداخت بدهی فنی را داشته باشید.

۹.۷ انتشار

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

۹.۷.۱ انتشار همراه با قطعی

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

• تعیین کنید چه چیزی باید آفلاین شود: کدام سرورها و مؤلفه‌ها.
• این برای مشتریان نهایی چگونه دیده می‌شود: آیا باید صفحه نگهداری بگذارید؟
• بازه زمانی‌ای محاسبه کنید که شامل موارد زیر باشد:
• زمان خاموش کردن
• زمان به‌روزرسانی نرم‌افزار و سخت‌افزار
• زمان راه‌اندازی دوباره
• زمان آزمون پیش از کاربر
• زمان فعال کردن بازگشت کاربران
• برای هر حوزه، گام‌های دقیق لازم برای موفقیت را شرح دهید.
• برای هر گام یک منبع و فرایند تحویل به گام بعدی اختصاص دهید.
• با کسب‌وکار صحبت کنید تا تاریخ‌های احتمالی انتشار را، ترجیحا در کمترین دوره استفاده، تعیین کنید.
• فهرست افرادی را تعیین کنید که به گزارش پیشرفت نیاز دارند و کسانی را که باید پس از انجام انتشار مطلع شوند. وقتی این را دارید، برنامه انتشار شما برای آینده خواهد بود. برای خراب شدن چیزها زمان بگذارید. برای مثال، اگر کسب‌وکار می‌تواند قطعی آخر هفته را تحمل کند، اما شما فکر می‌کنید فقط ۲ تا ۴ ساعت لازم دارید، آخر هفته را بگیرید. اگر زودتر تمام کردید عالی است، اما اگر چیزی خراب شد، زمان درون برنامه دارید بدون اینکه مجبور شوید بیشتر بخواهید.

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

۹.۷.۲ انتشار آبی-سبز

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

پس از تأیید اینکه همه چیز خوب است، می‌توانید شروع کنید ترافیک را به محیط «انتشار» جدید هدایت کنید، و وقتی همه ترافیک آنجاست، محیط قدیمی را پایین بیاورید و بگذارید محیط جدید همه بار را بگیرد. از سوی دیگر، اگر چیزها کاملا درست نبود، محیط جدید را پایین بیاورید و دوباره تلاش کنید؛ هیچ آسیبی به ترافیک موجود وارد نشده است. این سبک انتشار آبی-سبز نامیده می‌شود و اگر بر آن مسلط شوید، می‌تواند چرخه انتشار بی‌درد و کم‌استرس بسازد. همچنین مزیت اضافه‌ای دارد: اسکریپت‌های ساخت زیرساخت شما را آزمون می‌کند. هرچه معماری شما پیچیده‌تر باشد، مسلط شدن بر این تکنیک سخت‌تر است، اما ناممکن نیست. برای برنامه‌های سبک وب ایده‌آل است. یکی از سخت‌ترین چیزها برای مدیریت در هر انتشار، تغییرات شمای پایگاه داده است. قانون ساده است: همیشه اضافه کن، هرگز حذف نکن. حذف کردن بازگشت را بدون توسل به پشتیبان‌ها ناممکن می‌کند. می‌توانید جدول‌ها، ستون‌ها و ایندکس‌ها را بسیار بعدتر در انتشارهای آینده حذف کنید، وقتی مطمئن شدید انتشار موفق بوده و هرگز لازم نیست برگردد. رسیدن به مرحله‌ای که انتشارها خوب تمرین شده و بی‌درد باشند، فشار و ریسک به‌روزرسانی‌ها را بسیار کم می‌کند و آن‌ها را به رویدادی بی‌دردسر تبدیل می‌کند. فارغ از اینکه کدام راهبرد انتشار را انتخاب می‌کنید، ساختن یادداشت‌های انتشار، سندی از همه چیزهایی که تغییر کرده، عادت خوبی است. این می‌تواند یک فایل متنی ساده، یک wiki یا حتی صفحه Atlassian Confluence باشد. بعضی سیستم‌های تیکتینگ برچسب زدن تیکت‌ها یا اسپرینت‌های مختلف برای یک انتشار مشخص را آسان می‌کنند و عملا یادداشت‌های انتشار را خودکار تولید می‌کنند. این سند بسیار مفیدی است، به‌ویژه اگر کسب‌وکار باید به مشتری نهایی بگوید چه چیزی منتشر شده است. شاید بخواهند این فهرست خام را بگیرند و آن را به زبانی که برای کاربر نهایی معنادارتر است زمینه‌مند کنند.

۹.۸ درخواست‌های مشتری

وقتی یک سازمان بزرگ و موفق را اداره می‌کنید، بی‌تردید درخواست‌های ویژگی از همه سو به سمت شما خواهد آمد. مشتریان بزرگ‌تر احتمالا نفوذ زیادی خواهند داشت و همین‌ها هستند که اگر مدیریتشان نکنید، به بدترین کابوس شما تبدیل می‌شوند. کسب‌وکار مشتاق است بزرگ‌ترین مشتریان خود را راضی نگه دارد و طبیعتا می‌خواهد خواسته‌هایشان را برای ادامه کسب‌وکارشان برآورده کند. اما اگر رها شود، ممکن است خود را در حال تأیید تغییراتی ببینید که فقط برای همان مشتری مشخص‌اند، سربار غیرضروری ایجاد می‌کنند و در نهایت لنگری بر پلتفرم می‌شوند. نمی‌خواهید همیشه «نه» بگویید، پس CTO مدرن چه باید بکند؟ مدام مانع گذاشتن، کسب‌وکار یا مشتریان را به شما علاقه‌مند نمی‌کند. در عوض، باید هر درخواست ویژگی را در این زمینه بررسی کنید که انگار برای همه مشتریان شماست. چیزهایی که باید در نظر بگیرید:

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

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

if (Client == XYZ) {

// کاری مخصوص مشتری انجام بده

}

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

جمع‌بندی

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

چک‌لیست

چند مورد از موارد زیر را می‌توانید ادعا کنید که پوشش داده‌اید؟

• برنامه‌ریزی و مدیریت کار دیگران، اگر مدیر پروژه ندارید
• همه کارهای تیم را از طریق نوعی سیستم تیکت پیگیری کرده‌اید
• ریتم تعریف‌شده‌ای برای چگونگی چیدن و برنامه‌ریزی پروژه‌ها دارید
• استانداردهای توسعه روشنی که تیم شما به آن‌ها پایبند است فهمیده شده‌اند
• فرهنگ قوی کنترل نسخه به کار گرفته‌اید، با درک همه از اهمیت و نقشی که بازی می‌کند
• فرایند ساخت و استقرار تکرارپذیری دارید که به یک فرد یا ماشین وابسته نیست
• مقدار بدهی فنی حمل‌شده را در دست دارید و برنامه‌ای برای پرداخت آن دارید
• محیط آزمون اختصاصی دارید که بیرون از تیم توسعه قرار می‌گیرد
• فرایند انتشاری دارید که در صورت نیاز بازگشت را ممکن می‌کند
• هیچ ساختار از نوع if-client در کدبیس خود ندارید