<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های Masoud Yaghouti</title>
        <link>https://virgool.io/feed/@masoudy1369</link>
        <description>من به همراه خدای خودم همه کار می تونم بکنم...</description>
        <language>fa</language>
        <pubDate>2026-04-14 10:47:06</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/28884/avatar/MNvyPP.png?height=120&amp;width=120</url>
            <title>Masoud Yaghouti</title>
            <link>https://virgool.io/@masoudy1369</link>
        </image>

                    <item>
                <title>فرآیند مدیریت موثر باگ‌های بحرانی در محصول</title>
                <link>https://virgool.io/@masoudy1369/critical-bug-management-process-fjidl2nolhcu</link>
                <description>در توسعه محصول نرم‌افزاری، زمانی که یک باگ بحرانی در محیط عملیات و یا حتی در محیط آزمون محصول رخ می‌دهد، رسیدگی سریع و موثر آن ضروری است. برای من همیشه سوال بوده که در زمان‌هایی که باگی اعلام می‌شود که روی عملکرد محصول تاثیر زیادی دارد، چه کاری باید انجام داد تا در سریع‌ترین زمان ممکن بتوانیم به نقطه پایدار برسیم و باگ را رفع کنیم. می‌توانیم جلسه‌ای برگزار کنیم که از قالبی شبیه به رویداد معروف &quot;Sprint Review&quot; استفاده کنیم؛ با این تفاوت که در جلسه بازبینی، کل اسپرینت هدف قرار می‌گیرد ولی در این مورد بخصوص می‌توانیم با برخی تغییرات برای رسیدگی به فوریت و شدت باگ فرآیند مدیریت باگ را تسهیل کنیم.در اینجا ساختار پیشنهادی برای مدیریت باگ‌های بحرانی  آورده شده که حاصل تجربه چند ساله من است:1. اطلاع‌رسانی فوری: به محض کشف مشکل، تیم اسکرام باید سریعاً از آن اطلاع پیدا کند. این تضمین می‌کند که تیم از موضوع آگاه است و می تواند بر اساس آن برنامه‌ریزی کند. (برای این مورد می‌توان از روال‌های تیم مانیتورینگ استفاده کرد یا ساختار یکپارچه‌ای برای بدست آوردن فیدبک کاربران بوجود آورد.)2. برنامه‌ریزی اضطراری: اسکرام مستر باید یک جلسه اضطراری برای بحث در مورد باگ ترتیب دهد. همه اعضاء تیم مربوطه باید شرکت کنند، از جمله توسعه‌دهندگان، تسترها و مالک محصول. جلسه باید در اسرع وقت برنامه‌ریزی شود تا تأثیر باگ در محصول به حداقل برسد.3. توضیحات باگ: در ابتدای جلسه، شخصی که باگ را گزارش یا کشف کرده است، باید شرح مفصلی از مشکل ارائه دهد. این باید شامل علائم، عواقب بالقوه و هر سناریو خاصی باشد که در آن باگ رخ می‌دهد.4. ارزیابی تأثیر: تیم توسعه، با نظرات سایر ذینفعان، باید تأثیر بروز باگ را بر محصول و کاربران آن ارزیابی کند. درک شدت موضوع به اولویت‌بندی مناسب آن کمک می‌کند.5. شناسایی علل بروز باگ: تیم توسعه باید دلایل رخداد باگ را بررسی کند. این ممکن است شامل بررسی تغییرات اخیر در کد، تجزیه و تحلیل گزارش‌ها و در نظر گرفتن هرگونه استقرار یا به‌روزرسانی اخیر باشد.5.1. الگوریتم Divide and Conquer: بسته به پیچیدگی باگ و اندازه تیم، تقسیم به گروه‌های کوچک‌تر برای بررسی علل بالقوه مختلف بطور همزمان ممکن است مفید باشد. این می‌تواند فرآیند رفع باگ را تسریع کند. بعنوان مثال عدم بروزرسانی داده در پلتفرم اندروید محصول را می‌توان بطور موازی در تیم‌های دیتا، سرور و اندروید بررسی کرد. حتی شکستن مشکل به مسائل کوچکتر می‌تواند روند رفع باگ را راحت‌تر نماید.5.2. بررسی تغییرات کد: اگر تغییرات یا استقرار کد اخیرا صورت گرفته است، تیم باید کد و تغییرات مربوط به بخش آسیب دیده را بررسی کند.5.3. چک لیست باگ‌های رایج: داشتن چک لیستی از مسائل رایج و آنتی پترن‌های مربوط به باگ می‌تواند به کاهش سریع علل احتمالی کمک کند.9. اولویت‌بندی: پس از شناسایی علت‌ها، تیم باید براساس احتمال اینکه علت اصلی و تأثیر بالقوه باگ چی میتونه باشه، بررسی آنها را اولویت‌بندی کند. در اولویت‌بندی و بررسی علل رخداد باگ باید زمانی برای تست و مانیتوریگ وضعیت درنظر بگیریم یا بعبارتی نباید تمامی علل رخداد را بطور موازی رفع و تست نماییم.10. رفع، تست، مانیتورینگ وضعیت: پس از شناسایی علت اصلی، تیم توسعه باید روی اجرای یک رفع باگ، کار کند. پس از رفع باگ، باید بطور کامل تست شود تا اطمینان حاصل گردد که باگ را حل کرده و مشکل جدیدی ایجاد نمی‌کند. بعد از انتشار نیز می‌بایست وضعیت مانیتور شده تا از رفع باگ مطمئن شویم.11. تجزیه و تحلیل علت اصلی: تیم باید در بررسی و محدود کردن علل اصلی بروز باگ باهم همکاری مشترک داشته باشند. هدف شناسایی مشکل خاص است تا بتوان یک راه حل مناسب ابداع کرد.12.جلسه Retrospective: پس از رفع باگ و تثبیت وضعیت، ایده خوبی است که یک مرور کوتاه به گذشته انجام دهید تا از تجربه آن یاد بگیرید و ببینید که آیا بهبود فرآیند یا اقدامات پیشگیرانه‌ای وجود دارد که می‌تواند برای جلوگیری از باگ‌های مهم مشابه در کار انجام شود؟ (نوشتن گزارش‌هایی همچون گزارش Post-mortem بعد از اتمام این فرآیند (تشخیص، بررسی و علت‌یابی و رفع باگ)، تاثیر زیادی در کاهش بروز مجدد آن در آینده خواهد داشت.)برای درک بهتر این فرآیند، دیاگرام زیر بخوبی می‌تواند توالی انجام هر مرحله را توضیح دهد:Critical Bug Management Prpcess در طول فرآیند کشف تا رفع باگ، حفظ ارتباط شفاف با همه ذی‌نفعان، از جمله کاربران بسیار مهم است. به‌روزرسانی‌های منظم در مورد پیشرفت و تأثیر بالقوه بر در دسترس بودن محصول باید ارائه شود. به یاد داشته باشیم، کلید مدیریت موثر باگ‌های بحرانی در محصول، پاسخ سریع، همکاری و ارتباط شفاف بین همه اعضاء تیم است.</description>
                <category>Masoud Yaghouti</category>
                <author>Masoud Yaghouti</author>
                <pubDate>Mon, 31 Jul 2023 17:51:08 +0330</pubDate>
            </item>
                    <item>
                <title>5 دشمن کار تیمی</title>
                <link>https://virgool.io/@masoudy1369/5-%D8%AF%D8%B4%D9%85%D9%86-%DA%A9%D8%A7%D8%B1-%D8%AA%DB%8C%D9%85%DB%8C-mba7tb8naa8y</link>
                <description>امروز داشتم به کتابی که دو ماه پیش خونده بودم فکر میکردم و اینکه چقدر مطالب این کتاب در دنیای کاری من به وضوح دیده میشه. کتاب The Five Dysfunctions of a Team (پنج دشمن کار تیمی) نوشته پاتريك لنچيوني که در خصوص کارهای تیم ورک بسیار مفید و با ارزشه.در این کتاب در مورد مشکلات یک شرکت به نام &quot;دی تی&quot; که داراي قوي‌ترين و گران‌ترين كادر مديريت ممكنه، به طوري كه همه سازمان‌هاي تازه كار حسرت چنين شركتي را دارن، اما اين وضعيت مربوط به دو سال قبل بود. شرکت در طی این دوسال برخی از نیروهای کارآمد خودشو از دست میده و با مشکلات زیادی روبرو میشه. تا اینکه هیئت مدیره تصمیم میگیره که مدیرعامل رو به سمت پایین تری تنزل بده و با وجود مخالفت ها ولی این کار انجام میشه. بعد از 3 هفته &quot;کاترین&quot; به عنوان مدیر اجرایی شرکت استخدام میشه. دو هفته پس از شروع كار اين مدير جديد نگراني هاي شركت شروع شد. دلواپسي شركت به خاطر اين بود كه تقريباً او در آن مدت هيچ اقدامي نكرد . همه وقت او صرف ديدار از كارگاه ها، گفت وگو با كادر ستادي و مشاهده و دقت در امور و شركت در جلسات و گفتگو با تك تك كساني كه مستقيماً با او كار مي كردند، ميشد.كاركنان شركت مديران را “ستاد” نامیده بودند و هيچ كس آنها را تيم نمي دانست چرا كه بين آنها تنش و فشار عصبي وجود داشت و توانايي تصميم گيري نداشتند. با اينكه در جمع و به صورت تيمي بسيار نامطلوب بودند، اما به صورت جدا و تك تك انسان هايي معقول و موجه بودند. کارتین پس از بررسي‌هاي مفصل به اين نتيجه میرسه که درد و مشكل واقعي شركت در 5 مورد خلاصه میشه.اولين آسيب نبود اعتماد است.ترس از برخورد و هماهنگی های زورکینبود تعهد و ابهام (نبود برخوردهای سالم)پرهیز از مسئولیت پذیری (نازل بودن معیارها)بی توجهی به هدف (نتیجه کار)فراموش نکنین که كار تيمي اصيل و واقعي در بيشتر سازمان‌ها همچنان گريزپا و دست نيافتنی ست. و سازمان‌ها به اين علت در كار تيمي شكست مي‌خورند كه ناآگاهانه در پنج دام طبيعي اما خطرناك مي‌غلتند.</description>
                <category>Masoud Yaghouti</category>
                <author>Masoud Yaghouti</author>
                <pubDate>Sat, 16 Jan 2021 12:52:21 +0330</pubDate>
            </item>
            </channel>
</rss>