Agile mexanizmlari va Agile mexanizmlari

https://flic.kr/p/bkcj5q

Men bir necha bor dasturiy ta'minot guruhlari mexanizmlarga etarlicha e'tibor bermayotganliklarini va asosiy printsipni esdan chiqarganlarini payqadim. Bu, ayniqsa, Agile metodologiyasiga tegishli. Scrum kabi usullarning mexanizmlari shunchalik ko'pki, ular chaqqonroq bo'lganlar butunlay yo'q bo'lib ketadilar. Men dastlab buni Agilega bo'lgan qarashimni aniqlashtirish uchun o'z guruhimga elektron pochta orqali yozgan edim, ammo hozirda ko'p odamlarga Skott Xanselmanning maslahatini olib, uni blog yozuviga aylantirmoqdaman.

Men o'zimni bu tushunchani taqdim etishga qodirman deb hisoblayman. Men o'zimning kubiklarni demontaj qilish va ochiq yashash rejasini tuzish uchun tornavida yordamida Agile rivojlanishi bilan shug'ullangan kunlardan boshlab men chaqqon amaliyotchiman.

Ishim boshida men tibbiy dasturlar ishlab chiqaradigan kompaniya bilan ishladim. Biz shifoxonalarda Doktorning ish stoliga o'rnatilgan rasmlarni tekshirish uchun ish stoli dasturini yaratdik. Joylashtirish jarayoni CD-lar bilan boshqa shaharga sayohat qilish va ish stollarini o'rnatish va tasvir serverlarini o'z ichiga oladi. Biz FDA tomonidan tasdiqlanishga majbur bo'ldik, shuning uchun biz FDA-tasdiqlashdan o'tgan xususiyatlarni yaratishimiz kerak edi. Bu yuqoridan pastga, sharsharalar metodologiyasi uchun ideal muhit yaratdi. Barcha spetsifikatsiyalar yozilib, tasdiqlangan, imzolangan va biz faqat o'sha xususiyatlarga va shu xususiyatlarga qurilganmiz. Dev komandasi montaj guruhi bilan sayohat qilishni boshlamaguncha va shifokorlar bizning dasturiy ta'minotimizdan foydalanishni kuzatishganida, biz tsiklning boshida mijoz bilan gaplasha olsak, bundan ham yaxshiroq ishlashimiz mumkinligini angladik. Biz aniq tafsilotlarni kodladik va shunga o'xshash foydali bo'lmagan narsalarni topshirdik. Ushbu grafika mening ba'zi tajribalarimni ko'rsatadi.

Qanday qilib dasturiy ta'minotni ishlab chiqish mumkin https://blogs.perfmissions.com/perfceptsdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Taxminan shu vaqt ichida mening jamoam Agile Manifesti va "Extreme Programming" amaliyoti haqida eshitdilar. Ushbu kitobni biz faol o'qiyotgan soha faxriylari imzolaganini hisobga olsak, Martin Fouller va Kent Bek kabi odamlar ushbu amaliyotga juda ko'p qonuniylikni berishgan. Mening besh kishilik guruhim bizning kubiklarimizni demontaj qilishdi, bizning bosh vazirimizga (mijozlar uchun vakil) bizning yonimizga o'tirishga, indeks kartalari bilan taxtani o'rnatishga va XPni tashkil qilishga kirishishdi. Bizda haftalik rejalashtirish va namoyish qilish tsikllari, ko'plab juftlashtirish va munozara bor edi. Men taxminan 15 yil davomida turli xil iteratsiyalar va o'zgarishlarda, turli kompaniyalarda ishladim. Bir guruh umuman hech qanday metodologiyaga amal qilmayotganday tuyuldi, lekin barcha guruh a'zolari chuqur agressiv muhitda bo'lganligi sababli, iteratsiya va hamkorlik ularning odatiy holati edi va ularga o'rnatilgan jarayon kerak emas edi.

Xo'sh, Agile ochiq qavat rejalari haqidami yoki ko'p gapirishadimi? Agar sizda stendlar va retroslar bo'lsa, siz Agile deb da'vo qila olasizmi? Scrum yoki TDD qaerga mos keladi? Ko'pincha odamlar jarayonning o'ziga xos xususiyatlariga juda ko'p duch kelishadi - Scrum yoki Kanban? Ikki hafta yoki bir haftalik sprintmi? Agar sizda tashqi qiyofangiz bo'lmasa, chindan ham chaqqonmisiz? Agile metodlaridan foydalangan holda faol rivojlanishni boshlaganimda, boshqa ishlab chiquvchilar bilan teng ravishda shug'ullanadigan, ishlab chiqqan va moslashtirganim menga yaxshi tushuncha berdi va bu post asosiy qoidalarni aniqlashdir.

Chaqqon bo'lish mijozlarning ehtiyojlarini tezda qondirishga qodir. Bu biz kodni tezroq yozishni anglatadimi? Yoq. Biz fizika qonunlarini mag'lub eta olmaymiz va ko'p funktsiyali dastur yaratish uchun vaqt talab etiladi.

Biz nima qilishimiz kerak

  1. Kod bilan hal qilmoqchi bo'lgan asosiy biznes muammolarini aniqlang
  2. Gipotezani sinash uchun tezda nazariy echimni topshirish
  3. Iteratsiya qiling va moslashing, ehtiyojlar o'zgarganda, yoki biz ko'proq narsani o'rganamiz
  4. Buni mijoz bilan jamoaning jalb qilingan qismi bilan hamkorlikda bajaring

Qolgan barcha ishlarimiz 2 va 3 yuqorida aytilganlarni engilroq qilishdir - biz imkon qadar tezroq ehtiyojni qondirayotganimizni bilishimiz va tezda o'zgartirishga qodir emasligimizni bilish. Agar siz (vs sotib olishga) qaror qilsangiz, siz maxsus dasturiy ta'minot yozyapsiz. Bu uning ixtisoslashtirilgan talablari va sharoitlariga ega ekanligini anglatadi.

Mijozning oldida imkon qadar tezroq ko'rinadigan narsaga ega bo'lish, garchi bu funktsiyaning kichik bir qismi bo'lsa ham, biz bilan bog'lanishni tezroq olishimizga imkon beradi. Shuning uchun men har doim asosiy xususiyatni, oxiridan oxirigacha va shu bilan ishlab chiqarishgacha borishga harakat qilaman. Aytaylik, siz mijozlaringiz haqidagi barcha ma'lumotlarni ko'rish uchun o'zingizni qo'llab-quvvatlovchilaringiz uchun sahifa yaratmoqdasiz. Butun sahifa uchun ma'lumot manbalarini o'rganishga ko'p vaqt sarflashning o'rniga va avval barcha API-larni yozishdan ko'ra, ishlab chiqarishga qadar sahifada ma'lumotlar to'plamini olishga harakat qiling. O'zingizning integratsiya va tarqatish mexanizmlaringizdan foydalana olasiz, UI doirasi haqida ma'lumot olishni boshlashingiz mumkin, ushbu sahifa sizning arizangizning qolgan qismiga qanday mos keladi va hokazo. Sizda kam miqdordagi kod bo'lsa, bu narsalarni o'zgartirish osonroq bo'ladi, aksincha. butun API doirasini qurganingizda.

Bu erda egiluvchanlik uchun zarur bo'lgan boshqa mexanizmlar mavjud

Sprints: Vaqtni hisobga olgan tsikllarda ishlab chiqish, biz hali ham tegishli xususiyatlar ustida ishlayotganimizni tekshirish uchun doimiy ravishda yangi ma'lumotlarni tekshirish va moslashtirishga imkon beradi. Dastur majburiyatdir. Biz faqat o'zimizga kerak bo'lgan narsani qurib, kerak bo'lganda kerakli narsani qo'sha olishimiz kerak. Binobarin, biz hozirgacha nimani qurganimizni va nimani rejalashtirganimizni muntazam ravishda ko'rib chiqishimiz zarur. Bu ikkinchi nuqtaga olib keladi.

Biz doimo baho berishni va o'zgarishni rejalashtirayotganimizni hisobga olsak, dasturiy ta'minotni o'zgartirish oson bo'lishi kerak. Mijoz dasturni ishlata boshlaganidan so'ng, ba'zi ma'lumotlarning avval ishlab chiqilganidan boshqacha ko'rinishini xohlasa nima bo'ladi? Buni sahifadagi boshqa narsalarga tegmasdan qilsak bo'ladimi? Yoki ma'lumot olish uchun biz boshqa API-ni chaqirishimiz kerak - bu o'zgarishni xavfsiz amalga oshira olamizmi? Bu erda rivojlanishning yaxshi usullari va mexanizmlari keladi

Birlikni sinovdan o'tkazish: Biz turli darajadagi avtomatlashtirilgan sinovlarni o'tkazdik, shuning uchun o'zgarishlar uchun xavfsizlik tarmog'i mavjud. Jihozni sinab ko'rayotgan narsaga e'tibor berish ham muhimdir. Birlik testlari mantiqni sinab ko'rishlari kerak. Agar siz yuqoridagi misolni olsangiz, ma'lumot olish uchun boshqa API-dan foydalansangiz, UI-ga ma'lumotlarni taqdim etadigan bizning API-ning birlik sinovlarida o'zgarish bo'lmasligi kerak. Unit testlari sizga kodni qayta ishlab chiqaruvchiga ishonch hosil qilish uchun mavjud bo'lib, bu o'z navbatida sizga hozir zarur bo'lgan narsalarni yozib berish huquqini beradi va keyinroq 100% qamrovli metrikani yaratishga imkon bermaydi.

CI / CD: Bu bizga etkazib berish va etkazib berish o'rtasidagi masofani qisqartirishga imkon beradi. Bu chaqqonlik uchun zarurdir. O'rnatishdagi to'siqlar olib tashlansa va ishlab chiqarishda kichik o'zgarishlarni amalga oshira olsak, o'zgarish xavfi kamayadi. Agar tarqatish zerikarli bo'lsa, ular kamroq bo'ladi. Kamroq tez-tez joylashtirilishi katta sirt maydoniga tegib, bir tonna o'zgarishga olib keladi va shuning uchun ular xavfli. Agar siz nega dasturiy ta'minotni etkazib berish samaradorligi va uni optimallashtirish uchun qanday metrikadan foydalanish to'g'risida ko'proq ma'lumotga ega bo'lsangiz, men bu kitobni Nicole Forsgren tomonidan tavsiya qilaman.

Xavotirlarni ajratish: O'zgartirish oson bo'lgan dastur uchun bo'shashgan birlashtirilgan arxitektura zarur. Biror o'zgarish yuzasini kamaytiradi. Mikroservislar va konteynerlar tashvishlarni ajratishda ba'zi mexanizmlardir. Buni eslash juda muhim va API, komponentlar va dasturlarni yaratishda tashvishlarni ajratib turishni unutmang.

Eslab qoling
Yaxshi kodni osongina o'zgartirish mumkin

Yaxshi kod osongina o'chirilishi mumkin

Eng yaxshi kod - bu umuman yozilmagan kod

Siz yaratgan bitlar haqiqiy dunyoga imkon qadar tezroq javob berishi juda muhim, shuning uchun yangi bitlar qanday ko'rinishga ega bo'lishi kerakligini bilasiz va keraksiz bitlarni tayyorlashga vaqt sarflamaysiz.