طرز فکر سریع در مقابل مکانیسم های چابک

https://flic.kr/p/bkcj5q

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

من خودم را تا حدی واجد شرایط برای ارائه این بینش می دانم. من یک تمرین دهنده چابک از روزهایی هستم که توسعه چابک با استفاده از یک پیچ گوشتی درگیر است - برای جدا کردن اطاقک های خود و ایجاد یک برنامه صندلی باز!

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

چگونه توسعه نرم افزار می تواند از https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

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

بنابراین آیا چابک در مورد برنامه های طبقه باز است یا زیاد صحبت می کند؟ اگر حالت ایستاده و رترو داشته باشید می توانید ادعا کنید که چابک هستید؟ Scrum یا TDD کجا جای دارد؟ اغلب مردم بیش از حد به ویژگی های این فرآیند گیر می آورند - Scrum یا Kanban؟ دو هفته یا یک هفته حداکثر سرعت دویدن؟ اگر نظافت زیادی ندارید ، آیا واقعاً چابک هستید؟ با بزرگتر شدن انجام توسعه فعال با استفاده از روش های Agile ، با توسعه دهندگان دیگر به همان اندازه درگیر ، توسعه و تطبیق شیوه ، به من بینش خوبی داده است و این پست شناسایی اصول اساسی است.

چابک بودن قادر است به سرعت نیاز مشتری را برآورده سازد. آیا این بدان معنی است که ما کد را سریعتر می نویسیم؟ جواب منفی. ما نمی توانیم قوانین فیزیک را ضرب و شتم کنیم ، و یک کاربرد چند منظوره جامد برای ساختن زمان نیاز دارد.

کاری که باید انجام دهیم این است

  1. مشکلات اساسی کسب و کار را که می خواهیم با کد حل کنیم ، شناسایی کنید
  2. برای آزمایش فرضیه سریع یک راه حل نظری ارائه دهید
  3. با تغییر نیازها ، متناسب با آنها سازگار شده و یا بیشتر می آموزیم
  4. این کار را با همکاری ، با مشتری قسمت درگیر تیم انجام دهید

همه چیز دیگری که انجام می دهیم این است که 2 و 3 بالاتر را دردناکتر کنیم - این که بدانیم آیا در اسرع وقت نیاز را برآورده می کنیم و اگر قادر به تغییر سریع نیستیم. اگر تصمیم به ساخت (vs خرید) گرفتید ، در حال نوشتن نرم افزارهای سفارشی هستید. این بدان معناست که دارای شرایط و شرایط تخصصی است.

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

در اینجا برخی از مکانیسم های دیگر که برای چابکی ضروری هستند ، آورده شده است

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

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

تست واحد: ما تست های اتوماتیک را در سطوح مختلف انجام داده ایم بنابراین یک شبکه ایمنی برای تغییرات وجود دارد. همچنین باید درمورد آنچه که تست های واحد تست می کنند ، بسیار مهم است. تست های واحد باید منطق را آزمایش کنند. اگر مثال بالا را استفاده می کنید ، با استفاده از یک API متفاوت برای به دست آوردن داده ، در حالت ایده آل ، نیازی به تغییر در تست های واحدها برای API ما که داده ها را به UI ارائه می دهد ، نیست. آزمایشات واحدی وجود دارد که به شما اطمینان می دهد که کد را مجدداً مقاوم کنید ، و این به نوبه خود به شما امکان نوشتن فقط آنچه را که اکنون نیاز دارید ، می دهد و بعداً استراحت دهید تا به هر حال می توانید متریک پوشش 100٪ پوشش تولید نکنید.

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

جدایی نگرانی ها: برای نرم افزاری که به راحتی قابل تغییر است ، یک معماری کاملاً همراه همراه است. سطح سطح یک تغییر را کاهش می دهد. خدمات خرد و ظروف برخی از مکانیسم هایی هستند که برای انجام تفکیک نگرانی ها مورد استفاده قرار می گیرند. یادآوری این نکته حائز اهمیت است و در ساخت API ها ، مؤلفه ها و برنامه ها ، حتماً جدایی نگرانی ها را در نظر داشته باشید.

یاد آوردن
کد خوب به راحتی قابل تغییر است

کد بهتر می تواند به راحتی حذف شود

بهترین کد آن چیزی است که اصلاً نوشته نشده است

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