ວິທີເລີ່ມຕົ້ນໃຊ້ ADR

ເພື່ອເລີ່ມຕົ້ນໃຊ້ ADR ໃຫ້ປຶກສາຫາລືກັບເພື່ອນຮ່ວມທີມກ່ຽວກັບຫົວຂໍ້ເຫຼົ່ານີ້.

ການລະບຸການຕັດສິນໃຈ:

• AD ມີຄວາມຮີບດ່ວນ ແລະ ສຳຄັນຫຼາຍປານໃດ?

• ຕ້ອງຕັດສິນໃຈດຽວນີ້ ຫຼື ລໍຖ້າຈົນກວ່າຈະຮູ້ຂໍ້ມູນຫຼາຍກວ່ານີ້ໄດ້?

• ທັງປະສົບການສ່ວນບຸກຄົນ ແລະ ປະສົບການລວມໝູ່ ລວມເຖິງວິທີການ ແລະ ແນວປະຕິບັດດ້ານການອອກແບບທີ່ເປັນທີ່ຍອມຮັບ ສາມາດຊ່ວຍໃນການລະບຸການຕັດສິນໃຈໄດ້.

• ໃນທາງທີ່ດີ ຄວນຮັກສາລາຍການສິ່ງທີ່ຕ້ອງຕັດສິນໃຈ ເພື່ອເສີມລາຍການສິ່ງທີ່ຕ້ອງເຮັດຂອງຜະລິດຕະພັນ.

ການຕັດສິນໃຈ:

• ມີເຕັກນິກການຕັດສິນໃຈຫຼາຍຢ່າງ ທັງແບບທົ່ວໄປ ແລະ ແບບສະເພາະດ້ານສະຖາປັດຕະຍະກຳຊອບແວ ເຊັ່ນ ການສ້າງແຜນທີ່ການສົນທະນາ (dialogue mapping).

• ການຕັດສິນໃຈເປັນກຸ່ມແມ່ນຫົວຂໍ້ຄົ້ນຄວ້າທີ່ກຳລັງຢູ່ໃນຄວາມສົນໃຈ.

ການບັງຄັບໃຊ້ ແລະ ການຮັບປະກັນການຕັດສິນໃຈ:

• AD ຖືກນຳໃຊ້ໃນການອອກແບບຊອບແວ; ດັ່ງນັ້ນຕ້ອງສື່ສານໃຫ້ຜູ້ມີສ່ວນໄດ້ສ່ວນເສຍຂອງລະບົບທີ່ສະໜອງທຶນ, ພັດທະນາ ແລະ ດຳເນີນງານລະບົບນັ້ນຮັບຮູ້ ແລະ ຍອມຮັບ.

• ຮູບແບບການຂຽນໂຄ້ດທີ່ເຫັນສະຖາປັດຕະຍະກຳໄດ້ຊັດເຈນ ແລະ ການທົບທວນໂຄ້ດທີ່ເນັ້ນຄວາມກັງວົນ ແລະ ການຕັດສິນໃຈດ້ານສະຖາປັດຕະຍະກຳ ແມ່ນສອງແນວປະຕິບັດທີ່ກ່ຽວຂ້ອງກັນ.

• AD ຍັງຕ້ອງໄດ້ຮັບການພິຈາລະນາ (ຄືນໃໝ່) ເມື່ອປັບປຸງລະບົບຊອບແວໃຫ້ທັນສະໄໝໃນການພັດທະນາຕໍ່ເນື່ອງຂອງຊອບແວ.

ການແບ່ງປັນການຕັດສິນໃຈ (ທາງເລືອກ):

• AD ຫຼາຍຢ່າງເກີດຂຶ້ນຊ້ຳໆໃນຫຼາຍໂຄງການ.

• ດັ່ງນັ້ນ ປະສົບການກ່ຽວກັບການຕັດສິນໃຈໃນອະດີດ ທັງດີ ແລະ ບໍ່ດີ ສາມາດເປັນຊັບສິນທີ່ນຳກັບມາໃຊ້ໃໝ່ໄດ້ຢ່າງມີຄຸນຄ່າ ເມື່ອໃຊ້ຍຸດທະສາດການຄຸ້ມຄອງຄວາມຮູ້ຢ່າງຊັດເຈນ.

ການບັນທຶກເອກະສານການຕັດສິນໃຈ:

• ມີແມ່ແບບ ແລະ ເຄື່ອງມືຫຼາຍຢ່າງສຳລັບການບັນທຶກການຕັດສິນໃຈ.

• ເບິ່ງຊຸມຊົນ agile ເຊັ່ນ ADR ຂອງ M. Nygard.

• ເບິ່ງຂະບວນການວິສະວະກຳຊອບແວ ແລະ ການອອກແບບສະຖາປັດຕະຍະກຳແບບດັ້ງເດີມ ເຊັ່ນ ຮູບແບບຕາຕະລາງທີ່ IBM UMF ແລະ Tyree ກັບ Akerman ຈາກ CapitalOne ແນະນຳ.

ເພື່ອຂໍ້ມູນເພີ່ມເຕີມ:

• ຂັ້ນຕອນຂ້າງເທິງນີ້ຖືກນຳມາຈາກບົດຄວາມ Wikipedia ເລື່ອງ Architectural Decision