Хөгжүүлэлтийн Agile хандлага

Agile software development

Мэдээллийн технологийн хувьд дээр үе гэж яригдах 70-90-ээд оны үед компьютерчлэл нилээд өргөн хүрээтэй явагдаж эхэлсэн бөгөөд үүний үрээр програм хангамжын том жижиг төслүүд олон тоогоор хэрэгжиж эхэлжээ. Компьютерчлэл гэдэг маань янз бүрийн салбарт хүний үйл ажиллагааг компьютерийн тусламжтайгаар бүрэн болон хагас автоматжуулж хөдөлмөрийг хөнгөвчлөх үйл явц юм. Тэр үед хэрэгжиж байсан олон тооны төслүүдийн ихэнх хувь нь ямар нэг шалтгаанаар зорилгодоо хүрч чадалгүй унтарч байсан байх юм. Учир юунд байв гэвээс уламжлалт системийн хөгжүүлэлтийн загварт зарим нэг сул талууд байгаа юм. Уламжлалт хөгжүүлэлтийн загвар буюу хүрхрээ(waterfall) загвар нь:

Шинжилгээ → Загварчлал → Кодчилол → Тест → Суурилуулалт

-гэсэн хатуу заагдсан дараалалтай үйлдлүүдээр системийг байгуулдаг. Зарим уламжлалт загваруудад эдгээрээс ч олон үе шатууд байна. Гэхдээ гол зарчим нь хатуу заагдсан үе шатуудыг дэс дараалан дамжих ба үе шат болгоны төгсгөлд хийж дуусгасан байх баримтуудыг гүйцээж байж дараагийн шат руу ордог. Код бичих үе шат нийт хугацааны 20-25 хувийг, заримдаа түүнээс ч бага хувийг эзэлдэг. Хэрвээ аль нэг шат дамжлага дээр алдаа илэрвэл түүнийг засахын тулд өмнөх бүх үе шатууд дээр очиж засах шаардлагатай болдог. Энэ нь төслийн төлөвлөгөө зардалыг асар ихээр сунжруулах шалтгаан болдог байна. За тэгээд хэрэв төслийн хамгийн сүүлчийн Суурилуулалтын шатанд ямар нэг ноцтой алдаа илэрвэл засахад хэтэрхий оройтсон байх ба түүнийг засаж залруулахад маш их хугацаа, нөөц шаардлагатай болж үүнээс үүдээд төсөл амжилтгүй болох нь ч бий. Ингэхээр хөгжүүлэлтийн уламжлалт загвараар бол төслийн эхэн үед хийсэн алдаа дараа дараагийн үе рүүгээ цасан уруй мэт томрон бөмбөрч ирдэг гол дутагдал байдаг байх нь.

Одоо 90-ээд оноос хойш эрчимтэй хөгжиж байгаа хөгжүүлэлтийн agile хандлагын талаар ярья. Agile хандлагад уламжлалт аргаас ялгарах гол хэдэн онцлог бий:

Програмыг богинохон хугацааны мөчлөгөтэйгээр үйлдвэрлэж рискийг багасгадаг. Уламжлалт аргаар бол програм маань хамгийн сүүлийн үе шатанд хийгддэг учраас хэрэв алдаа доголдол байвал засахад хэтэрхий оройтсон байдаг гэсэн билээ. Харин agile аргаар бол програмыг маш богинохон хугацааны мөчлөгтэйгээр хийх учраас алдаа дутагдал эрт илэрдэг, ингэснээрээ уламжлалт хандлага дээр байдаг гол рискийг зайлуулж байна. Нүүр нүүрээ харалцсан бодит яриа хөөрөөг харилцаа холбооны гол хэлбэрээ болгодог. Өөд өөдөөсөө харж суугаад санаа бодлоо шууд солилцох нь хамгийн үр дүнтэй харилцаа холбооны хэлбэр байдаг. Уламжлалт хандлагаар бол баримт бичгийг харилцаа холбооны хэрэгсэлээ болгодог. Баримт бичгээр харилцахад нэг нь бичих гэж цаг авах нөгөө нь унших гэж цаг авахаас гадна, нэгнийхээ бичсэн зүйлийг нөгөө нь бүрэн ойлгох баталгаагүй байдаг.

Agile багт системийг хийхэд шаардлагатай байгаа бүх хүнийг оруулахыг эрмэлздэг. Өөрөөр хэлбэл зөвхөн хөгжүүлэгчид, мэдээллийн технологийн мэргэжилтнүүдээс гадна захиалагч талын төлөөлөгч, тест хийгч гэх мэт хүмүүс бүгд нэг баг болон хамт суугаад ажилладаг. Угаасаа аман яриан дээр харилцаа холбоо түшиглэж байгаа нөхцөлд захиалагчыг хажуудаа байлгахгүй бол ажил урагшлахгүй нь мэдээж юм.

Төслийн явцыг үнэлэх гол шинжүүр нь ажиллаж байгаа систем юм. Уламжлалт хандлагаар бол төслийн явцыг үе шат болгон дээр хийгдэх ёстой баримт бичгүүд буюу гарцуудаар үнэлдэг. Гэтэл шинжилгээ, зохиомж, код, тэстийн шатуудад хийгдээд байгаа олон баримтууд маань үнэхээр үр ашгаа өгч байгаа эсэх, зөв эсэх, нэг үгээр хэлбэл бүх юм зөв яваад байгааг үнэмшихэд хэцүү юм. Бодит байдал дээр бол код буюу ажиллахуйц системийг хийх нь л зорилго билээ. Кодгүй бол тэр олон баримтуудыг хийх зэрэг нь утгагүй тийм ч учраас agile хандлагад код байхгүй бол юу ч байхгүй гэж үздэг. Гэтэл уламжлалт төслийн явц 70% байхад нэг ч мөр код бичигдээгүй байж болдог.

Баримт бичгийг маш бага хийдэг. Системийг хэрхэн ажиллуулах, кодоо яаж бичих дээр л гол хүчээ зарцуулна. Бичиг баримтыг зайлшгүй нөхцөлд л хийнэ.

Уламжлалт хандлагыг predictive гэдэг, харин Agile хандлагуудыг adaptive гэдэг байна. Уламжлалт хандлага бол бүгдийг урьдчилан төлөвлөж хийдэг шинж чанартай бол Agile хандлагын арга барилууд өөрчлөлтийг хүлээж авахад хэзээд бэлэн байдаг уян хатан чанартай. Аdaptive ба Predictive шинж чанаруудыг аль альнаас нь хуваалцсан арга барилуудыг Iterative гэдэг. Хөгжүүлэлтийн прототайп загвар iterative аргад орно. Iterative аргууд нь уламжлалт загварт хийгддэг баримт бичгүүд болон төлөвлөлтийг хийх боловч эдгээрийг тойргоор хэд хэдэн удаа давтаж, давталт болгон дээрээ ажиллахуйц системийг гаргадаг учраас аль алинийх нь шинж чанаруудыг агуулж байгаа юм.

Эдгээр арга хандлагуудыг хэрхэн сонгож хэрэглэх вэ? гэсэн асуудал гарч ирж байна. Agile аргаар хөгжүүлэхэд 10-аас олонгүй хүнтэй нэг дор байрласан баг хамгийн тохиромжтой гэж үздэг. Харин 20-иос дээш хүнтэй, тархсан байрлалтай, асар том хэмжээтэй, тохиолдлуудад амжилттай хэрэгжүүлнэ гэхэд маргаантай байдаг.

Ерөнхийдөө дараах шинжүүдийг тооцож үздэг.

  • Agile
  • Уламжлалт
  • Low criticality
  • High criticality
  • Senior developers
  • Junior developers
  • High requirements change
  • Low requirements change
  • Small number of developers
  • Large number of developers
  • Culture that thrives on chaos
  • Culture that demands order

Өндөр зэрэглэлийн осолтой системийг хөгжүүлэхэд уламжлалт аргыг хэрэглэдэг. Цэрэг дайны зориулалттай гэх мэт хүний амь настай холбогдож болох системүүдийг уламжлалт аргаар хийдэг. Иймэрхүү системийг хийхийн тулд олон жилийн нарийн төвөгтэй судалгаа шинжилгээ шаарддаг учраас уламжлалт арга барил тохиромжтой.

Хөгжүүлэгчдийн ур чадварын хувьд agile аргууд цөөн тооны чадварлаг хүмүүс дээр тулгуурлаж явдаг бол уламжлалт төсөлд шинэ залуу хөгжүүлэгчид байхад гэмгүй. Учир нь уламжлалт аргад шийдвэр болон шийдлийг ахлагчид болон дээд албан тушаалын хүмүүс гаргаад бусад нь хэрэгжүүлэхэд л хангалттай байдаг. Харин agile багын гишүүд харьцангуй чөлөөтэй, өөрсдөө шийдэл гаргаж хэрэгжүүлэх эрхтэй, түүнийхээ хариуцлагыг хүлээх чадвартай байдаг.

Шаардлагын өөрчлөлт гарч ирэхэд agile баг түүнийг тэр даруй хүлээж аваад хэрэгжүүлж эхэлдэг бол уламжлалт төсөлд энэ нь тун хэцүү асуудал, шүдний өвчин болдог. Учир нь agile хөгжүүлэлтийн арга бол угаас өөрчлөлтөд найзархаг байхаар бий болсон байхад уламжлалт арга бол төлөвлөгөөнд суурилж хэрэгждэг билээ.

Agile хандлагын хамгийн гол шинж чанар ухагдахуунуудыг шингээсэн Extreme Programming(XP) аргын үндсэн ойлголтуудыг авч үзье.

XP-ийн гол зүйлс нь:

Харилцаа холбоо. Аман яриан дээр тулгуурлаж харилцаа өрнөнө. Дизайны бичиг баримтыг хөгжүүлэгч ч, захиалагч ч ойлгохоор маш энгийн хийх нь мөн амжилттай ойлголцох суурь болдог. Хөгжүүлэгчид болон захиалагчид нягт хамтран ажиллаж аль аль талаасаа байнга feedback авч өөрчлөгдөж байгаа шаардлагыг хэрэгжүүлдэг.

Энгийн байдал. Аливаа шийдлийг хамгийн энгийн байдлаар хийх. Хэн ч ойлгохоор энгийн хийх нь чухал. Шинэ шаардлага нэмэгдлээ гэхэд өмнө хийсэн энгийн зүйлийг язгуурчлаад(refactoring) шинэ зүйлсийг нэмэхэд амар байдаг. Мөн кодоо энгийн байлгахын тулд зөвхөн өнөөдрийн шаардлагыг хангахуйцаар хийхэд л хангалттай. Уламжлалт хандлагаар аль болох ерөнхий, ирээдүйг харсан зүйл хийхийг шаарддаг боловч ирээдүйд өөрчлөгдөж болох шаардлагын орчинд бол ингэх нь илүүц юм.

Эргэх холбоо(Feedback). Гурван зүйлээс эргэх холбоог авч хийх ажилдаа тусгаж явдаг. Эхнийх нь хийж буй системээс авах. Системийн дэд хэсгүүдээс unit test-ээр дамжуулан үр дүнг авч код маань санаснаар болж байна уу гэдэгийг шалгана. Мөн дэд хэсгүүд нийлэмжтэй ажиллаж байгааг integration test-ээр шалгана. Дараагийнх нь хэрэглэгчээс acceptance test-ээр дамжуулан feedback авна. Эцэст нь захиалагчид шинэ шаардлагын хүсэлтдээ хөгжүүлэлтийн багаас байнга feedback авч байдаг. Гэхдээ эдгээр эргэх холбоосуудыг бодит цаг хугацаанд тэр дор нь авахгүй бол эргэх холбооны мөн чанар, давуу тал алдагдана гэдгийг анхаарах хэрэгтэй. Гол нь realtime. Бас “өөдрөг үзэл бол програмчлалд аюул занал авчирдаг, харин feedback-аар түүнийг эмчилдэг” гэсэн үг байдаг.(Optimism is an occupational hazard of programming, feedback is the treatment.) Жишээ нь програм бичиж явцдаа нэг жижигхэн асуудлыг амархан юм чинь болох л байлгүй гэж өөдрөг үзэл гаргаад өнгөрөхөд дараа нь тэр жижигхэн асуудал маань дэндүү том болчихсон шийдэхэд хэт хэцүү болсон байх нь бий. Гэтэл эртхэн систем жижигхэн байх тэр үед өөдрөг үзэл гаргаж орхилгүй шийдсэн бол амархан байх байсан шүү дээ. Тэгэхээр дээрх өгүүлбэр нь код доторх үйлдэл, функциональ болгоныг unit test хийж feedback аван шийдэж явах нь иймэрхүү асуудлаас сэргийлэх арга гэсэн үг юм уу даа. Мөн үүнтэй ойролцоо нэг зарчим байдаг нь код доторх бүх хорхойгоо(bug) түүж байж шинэ юм нэмэх, цааш үргэлжлүүлэх.

Зориг зүрх(Courage). Шаардлага гарвал кодоо зоригтойгоор өөрчлөх. Өөрөөр хэлбэл refactoring хйих. Ингэж хэрэгцээтэй үед нь зоригтой өөрчлөлт хийж чадахгүй хуучин код дээрээ энд тэнд нь хэсэг бусаг код шавж наасаар нөхөөстэй шуудай шиг болгож орхих юм бол хэзээ нэг цагт задрах нь ойлгомжтой. Иймд хэрэгтэй үед нь язгуурчлах нь зүйтэй. Мөн өмнө хэрэглэгдэж байсан системийн функционал хасагдах үед хэдэн өдрөөр хийсэн кодоо авч хаях сэтгэлийн тэнхээтэй байх, хэцүү асуудлыг хэдэн өдрөөр ч болсон сууж байгаад шийдэх тэвчээртэй байх нь чухал.

Хүндэтгэл(Respect). Бусдыгаа болон бусдынхаа хөдөлмөрийг хүндэтгэх. Өөрийн бичсэн кодоо төв код руу хадгалахаасаа өмнө сайн шалгах хэрэгтэй. Өөрийн чинь компьютер дээр зүгээр байсан код бусдынх дээр очоод асуудал үүсгэх вий, алдаа гарах вий, үл нийцэх асуудал ургах вий сайн магадлах хэрэгтэй. Өөрийн чинь жижиг алдаа, хайхрамжгүй байдлаас болж багийн чинь гишүүд хайран цагаа үрэх ёсгүй.

Дээрх таван гол зүйл дээрээсээ ургуулаад зарчмуудыг(principles) гаргадаг. Жишээ нь :

  • Эргэх холбоо ойр ойрхон байх тусамаа өгөөжтэй.
  • Энгийн байдлыг зүгээр энгийн бус маш энгийн байлгах гэж ойлго.
  • Олон өөрчлөлтийг нэгэн зэрэг бүү хий. Дараалан нэг нэгээр хий.
  • Өөрчлөлтийг эерэгээр хүлээж ав, тэр дор нь тэврээд ав.

-гэх мэтээр үндсэн зарчмуудыг тулгуур таван зүйлээсээ ургуулан гаргана.

XP багын өдөр тутам үндсэн 4-н үйл ажиллагаа(Activities) явуулдаг.

Код бичих. Мэдээж, кодгүй бол юу ч гүй шүү дээ, код бичих үйлгүйгээр кодгүй. Код бичих гэснээс код гэж юуг хэлэх вэ гэхээр: програмын компайл хийгдэх соорс кодыг хэлэхээс гадна, код гаргаж авч болох диаграм(дөрөв дэх үеийн хэлүүд диаграм зураад програмаа гаргаж авдаг болсон гэж байгаа), ажиллуулж болох скрипт юм. Хөгжүүлэгчид өөрсдийн шийдлийг кодоор харуулах, түүн дээр нь бусад хөгжүүлэгч кодоор санаагаа оруулах зэргээр код бичих үйлдлийг харилцаанд ашиглаж болно. Кодоор шийдэл гаргаж харуулна гэдэг бол тухайн шийдлийг батлах хамгийн найдвартай арга юм. Зураг диаграм зураад ийм протоколоор харьцана, ийм алгоритмаар ажиллана гээд ярилцах бол нэг өөр, тэр зурган шийдэл маань амьдрал дээр ажиллах эсэх бол нэг өөр.

Тест хийх. Бид код бичлээ гэхэд түүнийг тестлэлгүйгээр үнэхээр ажиллах эсэх нь тодорхойгүй байх болно. Иймд бичсэн код санаснаар ажиллаж байна уу?(Unit test-ээр) Ажиллах ёстойгоорооо ажиллаж чадаж байна уу? (Acceptance test-ээр) гэдэгийг тестийг ойр ойрхон хийж үнэмжшинэ. Ингэснээрээ цааш итгэлтэй алхах болно.

Захиалагчийг сонсох. Захиалагчийг ямар ч үед анхааралтай сонсох. Түүнээс гадна захиалагчын бизнесийг ойлгохыг хичээх хэрэгтэй. Захиалагчийн бизнес шаардлагыг ойллголгүйгээр системийг амжилттай хийнэ гэдэг эргэлзээтэй.

Дизайн хийх. XP маань agile учраас бичиг баримт хийхгүй гэж ойлгож болохгүй. Эхний үед бичиг баримт хийлгүй яваад байж болох авч хэсэг хугацааны дараа систем маань орооцолдсон төмөр утас шиг болчихвол үзүүр нь олдохгүй хэцүүднэ. Тэгэхээр дизайныг энгийн ойлгомжтой минимал түвшинд ерөнхий архитектур байдлаар хийх л хэрэгтэй.

Эцэст XP хөгжүүлэлтийн шалгарсан туршлагууд буюу практикууд хуримтлагдсаныг дор жагсаая. Энэ жагсаалтад байгаа зарим сайн туршлагуудыг дараа нарийвчлан бичихээр үлдээе.

Шалгарсан туршлагууд

  • Fine scale feedback
    • Pair Programming
    • Planning Game
    • Test Driven Development
    • Whole Team
  • Continuous process
    • Continuous Integration
    • Design Improvement
    • Small Releases
  • Shared understanding
    • Coding Standard
    • Collective Code Ownership
    • Simple Design
    • System Metaphor
  • Programmer welfare
    • Sustainable Pace

Холбоосууд