ທ່ານຄຸ້ນເຄີຍກັບການຂຽນໂປລແກລມ, ແຕ່ Extreme Programming (XP ສໍາລັບສັ້ນ) ຍັງເປັນຄວາມລຶກລັບເລັກນ້ອຍສໍາລັບທ່ານ.
ຢ່າປ່ອຍໃຫ້ຊື່ເຮັດໃຫ້ເຈົ້າປິດ, ເຈົ້າມີຄວາມສ່ຽງທີ່ຈະສູນເສຍຂໍ້ມູນທີ່ເປັນປະໂຫຍດ.
ໃນບົດຄວາມນີ້, ພວກເຮົາຈະກວມເອົາທຸກສິ່ງທີ່ທ່ານຈໍາເປັນຕ້ອງຮູ້ກ່ຽວກັບ Extreme Programming ເພື່ອໃຫ້ທ່ານສາມາດນໍາໃຊ້ໄດ້ປະໂຫຍດຂອງທ່ານ.
ການຂຽນໂປລແກລມທີ່ຮຸນແຮງແມ່ນວິທີການພັດທະນາຊອບແວທີ່ເປັນສ່ວນຫນຶ່ງຂອງສິ່ງທີ່ເອີ້ນວ່າວິທີການທີ່ວ່ອງໄວ. XP ຖືກສ້າງຂຶ້ນໃນຄຸນຄ່າ, ຫຼັກການແລະການປະຕິບັດ, ແລະເປົ້າຫມາຍຂອງມັນແມ່ນເພື່ອໃຫ້ທີມງານຂະຫນາດນ້ອຍແລະຂະຫນາດກາງສາມາດຜະລິດຊອບແວທີ່ມີຄຸນນະພາບສູງແລະປັບຕົວເຂົ້າກັບຄວາມຕ້ອງການທີ່ມີການປ່ຽນແປງແລະພັດທະນາຢ່າງຕໍ່ເນື່ອງ.
ສິ່ງທີ່ແຕກຕ່າງ XP ຈາກວິທີການທີ່ວ່ອງໄວອື່ນໆແມ່ນວ່າ XP ເນັ້ນຫນັກເຖິງລັກສະນະດ້ານວິຊາການຂອງການພັດທະນາຊອບແວ. ການຂຽນໂປລແກລມທີ່ຮຸນແຮງແມ່ນມີຄວາມຊັດເຈນກ່ຽວກັບວິທີການເຮັດວຽກຂອງວິສະວະກອນຕາມການປະຕິບັດດ້ານວິສະວະກໍາອະນຸຍາດໃຫ້ທີມງານສົ່ງລະຫັດທີ່ມີຄຸນນະພາບສູງໃນຈັງຫວະທີ່ຍືນຍົງ.
ການຂຽນໂປລແກລມທີ່ຮຸນແຮງແມ່ນ, ສະຫຼຸບແລ້ວ, ການປະຕິບັດທີ່ດີທີ່ປະຕິບັດໄປສູ່ທີ່ສຸດ. ເນື່ອງຈາກໂຄງການຄູ່ແມ່ນດີ, ໃຫ້ເຮັດມັນຕະຫຼອດເວລາ. ເນື່ອງຈາກການທົດສອບລ່ວງຫນ້າແມ່ນດີ, ພວກເຮົາທົດສອບກ່ອນທີ່ລະຫັດການຜະລິດຈະຖືກຂຽນ.
XP, ບໍ່ເຫມືອນກັບວິທີການອື່ນໆ, ແມ່ນອີງໃສ່ຄຸນຄ່າແລະຫຼັກການທີ່ມີຄວາມສໍາຄັນແລະມີຄວາມກ່ຽວຂ້ອງ, ໃນການປະຕິບັດດ້ານວິສະວະກໍາ.
ຄຸນຄ່າສະຫນອງຈຸດປະສົງໃຫ້ກັບທີມງານ. ພວກເຂົາເຮັດຫນ້າທີ່ເປັນ "ດາວເຫນືອ" ເພື່ອນໍາພາການຕັດສິນໃຈຂອງເຈົ້າໃນລະດັບສູງ. ຢ່າງໃດກໍຕາມ, ຄຸນຄ່າແມ່ນບໍ່ມີຕົວຕົນແລະ fuzzy ເກີນໄປສໍາລັບການຊີ້ນໍາສະເພາະ. ຕົວຢ່າງ: ການເວົ້າວ່າທ່ານໃຫ້ຄຸນຄ່າການສື່ສານສາມາດນໍາໄປສູ່ຜົນໄດ້ຮັບທີ່ແຕກຕ່າງກັນຫຼາຍ.
ການປະຕິບັດແມ່ນ, ໃນຄວາມຫມາຍ, ກົງກັນຂ້າມຂອງຄຸນຄ່າ. ພວກມັນເປັນສີມັງ ແລະລົງມາສູ່ໂລກ, defiກໍານົດສະເພາະຂອງສິ່ງທີ່ຕ້ອງເຮັດ. ການປະຕິບັດຊ່ວຍໃຫ້ທີມງານຖືຕົນເອງຮັບຜິດຊອບຕໍ່ຄຸນຄ່າ. ຕົວຢ່າງ, ການປະຕິບັດພື້ນທີ່ເຮັດວຽກຂໍ້ມູນຂ່າວສານສົ່ງເສີມການສື່ສານທີ່ໂປ່ງໃສແລະງ່າຍດາຍ.
ຫຼັກການແມ່ນຄໍາແນະນໍາສະເພາະຂອງໂດເມນທີ່ເຊື່ອມຕໍ່ຊ່ອງຫວ່າງລະຫວ່າງການປະຕິບັດແລະຄຸນຄ່າ.
ຄຸນຄ່າ XP: ການສື່ສານ, ຄວາມງ່າຍດາຍ, ຄໍາຄຶດຄໍາເຫັນ, ຄວາມກ້າຫານແລະຄວາມເຄົາລົບ. ໃຫ້ເບິ່ງຢູ່ໃນແຕ່ລະຂອງພວກເຂົາໃນລາຍລະອຽດເພີ່ມເຕີມ.
ຮ່າງ BlogInnovazione.ມັນຂອງຮູບພາບ alexsoft.com
ການສື່ສານ: ການຂາດການສື່ສານຂັດຂວາງຄວາມຮູ້ຈາກການໄຫຼເຂົ້າຂອງທີມງານ. ເລື້ອຍໆ, ເມື່ອມີບັນຫາ, ບາງຄົນຮູ້ວິທີແກ້ໄຂມັນແລ້ວ. ແຕ່ການຂາດການສື່ສານຂັດຂວາງພວກເຂົາຈາກການຮຽນຮູ້ບັນຫາຫຼືປະກອບສ່ວນເຂົ້າໃນການແກ້ໄຂຂອງມັນ. ດັ່ງນັ້ນ, ບັນຫາດັ່ງກ່າວສິ້ນສຸດລົງເຖິງການແກ້ໄຂສອງຄັ້ງ, ສ້າງສິ່ງເສດເຫຼືອ.
ຄວາມລຽບງ່າຍ: ຄວາມລຽບງ່າຍບອກວ່າເຈົ້າພະຍາຍາມເຮັດສິ່ງທີ່ງ່າຍທີ່ສຸດສະເໝີ. ມັນມັກຈະຖືກເຂົ້າໃຈຜິດແລະຖືເປັນສິ່ງທີ່ງ່າຍດາຍທີ່ສຸດ, ໄລຍະເວລາ, ບໍ່ສົນໃຈສ່ວນ "ທີ່ເຮັດວຽກ".
ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ຈະຕ້ອງຈື່ໄວ້ວ່າຄວາມລຽບງ່າຍແມ່ນມີສະພາບການສູງ. ສິ່ງທີ່ງ່າຍດາຍສໍາລັບທີມງານຫນຶ່ງແມ່ນສະລັບສັບຊ້ອນສໍາລັບຄົນອື່ນແລະທັງຫມົດແມ່ນຂຶ້ນກັບທັກສະ, ປະສົບການແລະຄວາມຮູ້ຂອງແຕ່ລະທີມ.
ຂໍ້ສະເຫນີແນະ: ຄໍາຕິຊົມໃນວິທີການພັດທະນາຊອບແວແບບດັ້ງເດີມ, ເລື້ອຍໆແມ່ນ "ຫນ້ອຍເກີນໄປ, ຊ້າເກີນໄປ".
XP, ແນວໃດກໍ່ຕາມ, ຍອມຮັບການປ່ຽນແປງແລະທີມງານ XP ພະຍາຍາມເພື່ອໃຫ້ທັນເວລາແລະຄໍາຄຶດຄໍາເຫັນຢ່າງຕໍ່ເນື່ອງ. ຖ້າຕ້ອງການການແກ້ໄຂຫຼັກສູດ, XPers ຕ້ອງການຮູ້ໄວເທົ່າທີ່ຈະໄວໄດ້.
ຮ່າງ BlogInnovazione.ມັນຂອງຮູບພາບ alexsoft.com
ຄໍາຕິຊົມມາໃນຫຼາຍຮູບຮ່າງແລະຂະຫນາດ. ໃນເວລາທີ່ທ່ານເປັນຄູ່ຮ່ວມງານໂຄງການ, ຄໍາເຫັນຈາກເພື່ອນຮ່ວມງານຂອງທ່ານແມ່ນຄໍາຄຶດຄໍາເຫັນທີ່ສໍາຄັນ. ດັ່ງນັ້ນຄວາມຄິດເຫັນຂອງສະມາຊິກທີມອື່ນໆກ່ຽວກັບຄວາມຄິດ, ລວມທັງລູກຄ້າທີ່, ໂດຍສະເພາະແມ່ນ, ເປັນສະມາຊິກຂອງທີມງານ.
ການທົດສອບແມ່ນອີກແຫຼ່ງຫນຶ່ງຂອງຄໍາຄິດເຫັນທີ່ມີຄຸນຄ່າທີ່ເກີນກວ່າຜົນການທົດສອບ. ບໍ່ວ່າການທົດສອບການຂຽນແມ່ນງ່າຍຫຼືຍາກ, ດັ່ງນັ້ນຄໍາຄຶດຄໍາເຫັນ. ຖ້າເຈົ້າມີບັນຫາໃນການຂຽນແບບທົດສອບ, ໂຄງການຂອງເຈົ້າອາດຈະສັບສົນເກີນໄປ. ຟັງຄໍາຕິຊົມແລະປັບປຸງການອອກແບບຂອງທ່ານ.
ບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັບຄວາມຄິດທີ່ດີອາດຈະບໍ່ເຮັດວຽກໄດ້ດີໃນການປະຕິບັດ. ເພາະສະນັ້ນ, ລະຫັດສໍາເລັດຮູບຍັງເປັນແຫຼ່ງຂອງຄໍາຄຶດຄໍາເຫັນ, ເຊັ່ນດຽວກັນກັບຜະລິດຕະພັນທີ່ແຈກຢາຍ.
ສຸດທ້າຍ, ຈົ່ງຈື່ໄວ້ວ່າມີຄໍາຄຶດຄໍາເຫັນຫຼາຍເກີນໄປ. ຖ້າທີມງານສ້າງຄໍາຕິຊົມຫຼາຍກວ່າທີ່ມັນສາມາດຈັດການໄດ້, ຄວາມຄິດເຫັນທີ່ສໍາຄັນອາດຈະຫຼຸດລົງຈາກ radar. ສະນັ້ນມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະຊ້າລົງແລະຊອກຫາສິ່ງທີ່ເຮັດໃຫ້ເກີດການຕອບໂຕ້ເກີນແລະແກ້ໄຂມັນ.
ຄວາມກ້າຫານ: Kent Beck defiຄວາມກ້າຫານກາຍເປັນ "ການກະ ທຳ ທີ່ມີປະສິດຕິຜົນໃນການປະເຊີນ ໜ້າ ກັບຄວາມຢ້ານກົວ". ໃນຖານະເປັນວິສະວະກອນຊອບແວ, ທ່ານມີຄວາມຢ້ານກົວຫຼາຍແລະດັ່ງນັ້ນຈຶ່ງມີໂອກາດຫຼາຍທີ່ຈະສະແດງຄວາມກ້າຫານ.
ມັນຕ້ອງມີຄວາມກ້າຫານທີ່ຈະບອກຄວາມຈິງ, ໂດຍສະເພາະສິ່ງທີ່ບໍ່ພໍໃຈ, ເຊັ່ນ: ການຄາດຄະເນທີ່ຊື່ສັດ. ການໃຫ້ແລະການຮັບຄໍາຄຶດຄໍາເຫັນຍັງໃຊ້ຄວາມກ້າຫານ. ແລະມັນຕ້ອງມີຄວາມກ້າຫານເພື່ອຫຼີກເວັ້ນການຕົກຢູ່ໃນການຫຼຸດລົງຂອງຄ່າໃຊ້ຈ່າຍທີ່ຕົກຢູ່ໃນນ້ໍາຕົກແລະຍົກເລີກການແກ້ໄຂທີ່ລົ້ມເຫລວທີ່ໄດ້ຮັບການລົງທຶນຢ່າງຫຼວງຫຼາຍ.
ເຄົາລົບ: ພື້ນຖານພື້ນຖານຂອງ XP ແມ່ນວ່າທຸກຄົນສົນໃຈວຽກງານຂອງເຂົາເຈົ້າ. ບໍ່ມີຈໍານວນທີ່ດີເລີດທາງດ້ານເຕັກນິກສາມາດຊ່ວຍປະຢັດໂຄງການໄດ້ຖ້າບໍ່ມີການດູແລແລະຄວາມເຄົາລົບ.
ທຸກໆຄົນຄວນມີກຽດສັກສີແລະຄວາມເຄົາລົບ, ແລະແນ່ນອນ, ຜູ້ທີ່ມີສ່ວນຮ່ວມໃນໂຄງການພັດທະນາຊອບແວ. ເມື່ອທ່ານແລະສະມາຊິກທີມຂອງທ່ານເຄົາລົບແລະເບິ່ງແຍງເຊິ່ງກັນແລະກັນ, ລູກຄ້າ, ໂຄງການແລະຜູ້ໃຊ້ໃນອະນາຄົດ, ທຸກຄົນໄດ້ຮັບຜົນປະໂຫຍດ
ຫຼັກການໃຫ້ຄໍາແນະນໍາສະເພາະຫຼາຍກ່ວາຄຸນຄ່າ. ພວກເຂົາເປັນຄໍາແນະນໍາທີ່ເຮັດໃຫ້ມີຄຸນຄ່າແລະເຮັດໃຫ້ພວກເຂົາມີຄວາມຊັດເຈນຫຼາຍແລະບໍ່ຊັດເຈນ.
ຮ່າງ BlogInnovazione.ມັນຂອງຮູບພາບ alexsoft.com
ຕົວຢ່າງ, ອີງໃສ່ຄຸນຄ່າຂອງຄວາມກ້າຫານຢ່າງດຽວ, ເຈົ້າອາດຈະສະຫຼຸບວ່າມັນສົມຄວນທີ່ຈະປ່ຽນແປງຕາຕະລາງຂອງເຈົ້າທັນທີ. ຢ່າງໃດກໍ່ຕາມ, ຫຼັກການຂັ້ນຕອນຂອງເດັກນ້ອຍບອກພວກເຮົາວ່າການປ່ຽນແປງອັນໃຫຍ່ຫຼວງແມ່ນມີຄວາມສ່ຽງ. ດັ່ງນັ້ນ, ຕ້ອງການຂະຫນາດນ້ອຍແທນ.
ມະນຸດສະທຳ: ມະນຸດສ້າງຊອບແວສໍາລັບມະນຸດ, ເປັນຄວາມຈິງທີ່ມັກຈະຖືກມອງຂ້າມ. ແຕ່ການພິຈາລະນາຄວາມຕ້ອງການພື້ນຖານຂອງມະນຸດ, ຄວາມເຂັ້ມແຂງແລະຈຸດອ່ອນສ້າງຜະລິດຕະພັນທີ່ມະນຸດຕ້ອງການໃຊ້. ແລະສະພາບແວດລ້ອມການເຮັດວຽກທີ່ສະເຫນີໃຫ້ທ່ານມີໂອກາດສໍາລັບການບັນລຸຜົນແລະການຂະຫຍາຍຕົວ, ຄວາມຮູ້ສຶກຂອງຄວາມເປັນເຈົ້າຂອງແລະຄວາມປອດໄພຂັ້ນພື້ນຖານ, ເປັນສະຖານທີ່ທີ່ທ່ານສາມາດພິຈາລະນາຄວາມຕ້ອງການຂອງຄົນອື່ນໄດ້ຢ່າງງ່າຍດາຍ.
ເສດຖະກິດ: ໃນ XP, ທີມງານສະເຫມີເອົາໃຈໃສ່ກັບຄວາມເປັນຈິງທາງດ້ານເສດຖະກິດຂອງການພັດທະນາຊອບແວ, ສະເຫມີປະເມີນຄວາມສ່ຽງທາງດ້ານເສດຖະກິດແລະຄວາມຕ້ອງການຂອງໂຄງການ.
ຕົວຢ່າງ, ພວກເຂົາຈະປະຕິບັດເລື່ອງຂອງຜູ້ໃຊ້ໂດຍອີງໃສ່ມູນຄ່າທຸລະກິດຂອງເຂົາເຈົ້າແທນທີ່ຈະເປັນຄວາມກັງວົນດ້ານວິຊາການ.
ຜົນປະໂຫຍດຮ່ວມກັນ: ຫຼັງຈາກ XP, ທ່ານຫຼີກລ້ຽງການແກ້ໄຂທີ່ມີປະໂຫຍດຕໍ່ຝ່າຍຫນຶ່ງໂດຍຄ່າໃຊ້ຈ່າຍຂອງຄົນອື່ນ. ຕົວຢ່າງ, ຂໍ້ມູນສະເພາະທີ່ຂະຫຍາຍອອກອາດຈະຊ່ວຍໃຫ້ຄົນອື່ນເຂົ້າໃຈມັນ, ແຕ່ມັນລົບກວນທ່ານຈາກການປະຕິບັດມັນ ແລະເຮັດໃຫ້ຜູ້ໃຊ້ຂອງທ່ານຊັກຊ້າ.
ການແກ້ໄຂທີ່ເປັນປະໂຫຍດເຊິ່ງກັນແລະກັນແມ່ນການນໍາໃຊ້ການທົດສອບການຍອມຮັບອັດຕະໂນມັດ. ໄດ້ຮັບຄໍາຄຶດຄໍາເຫັນທັນທີກ່ຽວກັບການປະຕິບັດຂອງທ່ານ, ມິດສະຫາຍຂອງທ່ານໄດ້ຮັບສະເພາະທີ່ຊັດເຈນໃນລະຫັດ, ແລະຜູ້ໃຊ້ໄດ້ຮັບຄຸນສົມບັດຂອງເຂົາເຈົ້າທໍາອິດ. ນອກຈາກນັ້ນ, ທຸກໆທ່ານຈະມີຕາຫນ່າງຄວາມປອດໄພຕໍ່ກັບການຖົດຖອຍ.
ຜົນປະໂຫຍດ (ຜົນປະໂຫຍດຮ່ວມກັນ): ຖ້າການແກ້ໄຂໃຫ້ເຮັດວຽກຢູ່ໃນລະດັບຫນຶ່ງ, ມັນອາດຈະເຮັດວຽກຢູ່ໃນລະດັບທີ່ສູງກວ່າຫຼືຕ່ໍາ. ຕົວຢ່າງ, ການໄດ້ຮັບຄໍາຕິຊົມໃນຕອນຕົ້ນແລະຄົງທີ່ແມ່ນມີຄວາມສ່ຽງຕໍ່ລະດັບທີ່ແຕກຕ່າງກັນໃນ XP.
ການປັບປຸງ: ອີງຕາມຫຼັກການຂອງການປັບປຸງ, ທີມງານບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອຄວາມສົມບູນແບບໃນການປະຕິບັດເບື້ອງຕົ້ນ, ແຕ່ສໍາລັບການປະຕິບັດທີ່ດີພຽງພໍ, ແລະຫຼັງຈາກນັ້ນສືບຕໍ່ຮຽນຮູ້ແລະປັບປຸງມັນດ້ວຍຄໍາຄຶດຄໍາເຫັນຈາກຜູ້ໃຊ້ຈິງ.
ຄວາມຫຼາກຫຼາຍ: ທ່ານແລະເພື່ອນຮ່ວມງານໄດ້ຮັບຜົນປະໂຫຍດຈາກຄວາມຫຼາກຫຼາຍຂອງທັດສະນະ, ທັກສະແລະທັດສະນະຄະຕິ. ຄວາມຫຼາກຫຼາຍດັ່ງກ່າວມັກຈະເຮັດໃຫ້ເກີດຄວາມຂັດແຍ້ງ, ແຕ່ນັ້ນກໍ່ບໍ່ເປັນຫຍັງ.
ການຂັດແຍ້ງແລະການຂັດແຍ້ງແມ່ນໂອກາດສໍາລັບຄວາມຄິດທີ່ດີກວ່າທີ່ຈະເກີດຂື້ນໃນເວລາທີ່ທຸກຄົນຫຼິ້ນໂດຍຄຸນຄ່າຂອງຄວາມກ້າຫານແລະຄວາມເຄົາລົບ. ມີຄວາມກ້າຫານໃນການສະແດງຄວາມເຫັນທີ່ກົງກັນຂ້າມ, ເຄົາລົບນັບຖືໃນການສະແດງອອກໃນທາງແພ່ງແລະເຫັນອົກເຫັນໃຈ. ແລະທັງຫມົດນີ້ແມ່ນການອອກກໍາລັງກາຍການສື່ສານທີ່ມີປະສິດທິພາບ.
ການສະທ້ອນ: ທີມງານທີ່ຍິ່ງໃຫຍ່ສະທ້ອນໃຫ້ເຫັນໃນການເຮັດວຽກຂອງເຂົາເຈົ້າແລະວິເຄາະວິທີການທີ່ດີກວ່າ. XP ສະເຫນີໂອກາດຫຼາຍຢ່າງສໍາລັບການນີ້. ບໍ່ພຽງແຕ່ຢູ່ໃນຮອບວຽນປະຈໍາອາທິດແລະໄຕມາດຂອງຕົນ, ແຕ່ໃນທຸກໆການປະຕິບັດມັນສົ່ງເສີມ.
ຄວາມຮູ້ສຶກເປັນສິ່ງສໍາຄັນທີ່ຈະພິຈາລະນານອກເຫນືອໄປຈາກການວິເຄາະຢ່າງມີເຫດຜົນ. ລໍາໄສ້ຂອງທ່ານສາມາດແຈ້ງເຈົ້າກ່ອນທີ່ທ່ານຈະສາມາດຫາເຫດຜົນກ່ຽວກັບສິ່ງໃດ. ແລະດັ່ງນັ້ນລາວສາມາດສົນທະນາກັບຄົນທີ່ບໍ່ແມ່ນວິຊາການ, ພວກເຂົາສາມາດຖາມຄໍາຖາມທີ່ເປີດຄວາມເປັນໄປໄດ້ໃຫມ່ຢ່າງສົມບູນ.
ຟລູໂຊ: ວິທີການພັດທະນາຊອບແວແບບດັ້ງເດີມມີໄລຍະທີ່ແຕກຕ່າງກັນ, ເຊິ່ງໃຊ້ເວລາດົນແລະມີໂອກາດຫນ້ອຍສໍາລັບຄໍາຄຶດຄໍາເຫັນແລະການແກ້ໄຂຫຼັກສູດ. ແທນທີ່ຈະ, ການພັດທະນາຊອບແວໃນ XP ເກີດຂື້ນໃນກິດຈະກໍາທີ່ເກີດຂື້ນຢ່າງຕໍ່ເນື່ອງ, ໃນ "ກະແສ" ທີ່ສອດຄ່ອງຂອງມູນຄ່າ.
ໂອກາດ: ບັນຫາແມ່ນບໍ່ສາມາດຫຼີກລ່ຽງໄດ້ໃນການພັດທະນາຊອບແວ. ຢ່າງໃດກໍຕາມ, ທຸກໆບັນຫາແມ່ນໂອກາດສໍາລັບການປັບປຸງ. ຮຽນຮູ້ທີ່ຈະເບິ່ງພວກເຂົາດ້ວຍວິທີນີ້ແລະເຈົ້າມີແນວໂນ້ມທີ່ຈະມາກັບການແກ້ໄຂທີ່ມີຄວາມຄິດສ້າງສັນແລະເປົ້າຫມາຍທີ່ຍັງໃຫ້ບໍລິການເພື່ອປ້ອງກັນບໍ່ໃຫ້ພວກເຂົາເກີດຂຶ້ນອີກ.
ຊ້ຳຊ້ອນ: ຫຼັກການຂອງການຊໍ້າຊ້ອນກ່າວວ່າຖ້າຫາກວ່າບັນຫາໃດຫນຶ່ງແມ່ນສໍາຄັນ, ທ່ານຕ້ອງໃຊ້ກົນລະຍຸດຫຼາຍຢ່າງເພື່ອຕ້ານມັນ.
ເອົາຂໍ້ບົກພ່ອງ. ບໍ່ມີຍຸດທະວິທີດຽວທີ່ສາມາດປ້ອງກັນຄວາມບົກຜ່ອງທັງຫມົດຈາກການຫລົບຫນີການຜະລິດ.
ດັ່ງນັ້ນການແກ້ໄຂຂອງ XP ແມ່ນເພື່ອ stack ຊຸດຂອງມາດຕະການຄຸນນະພາບ. ຄູ່ໂຄງການ, ການທົດສອບ, ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ. ແຕ່ລະເສັ້ນດຽວຂອງການປ້ອງກັນ, ຮ່ວມກັນເປັນກໍາແພງ impenetrable virtually.
ຄວາມລົ້ມເຫຼວ: ຄວາມລົ້ມເຫຼວບໍ່ແມ່ນສິ່ງເສດເຫຼືອເມື່ອມັນແປເປັນຄວາມຮູ້. ການກະ ທຳ ແລະຮຽນຮູ້ສິ່ງທີ່ບໍ່ໄດ້ຜົນໄວແມ່ນມີຜົນດີຫຼາຍກ່ວາການບໍ່ກະຕືລືລົ້ນທີ່ເກີດຈາກຄວາມບໍ່ຕັ້ງໃຈໃນເວລາເລືອກໃນຫຼາຍທາງເລືອກ.
ຄຸນະພາບ: ຄົນເຮົາມັກຈະຄິດວ່າມີອຸປະສັກລະຫວ່າງຄຸນນະພາບ ແລະຄວາມໄວ.
ມັນເປັນວິທີທາງອື່ນ: ການຊຸກຍູ້ການປັບປຸງຄຸນນະພາບແມ່ນສິ່ງທີ່ເຮັດໃຫ້ທ່ານໄວຂຶ້ນ.
ຕົວຢ່າງ, refactoring - ການປ່ຽນແປງໂຄງສ້າງຂອງລະຫັດໂດຍບໍ່ມີການປ່ຽນແປງພຶດຕິກໍາຂອງມັນ - ແມ່ນການປະຕິບັດທີ່ເຮັດໃຫ້ລະຫັດງ່າຍຕໍ່ການເຂົ້າໃຈແລະປ່ຽນແປງ. ດັ່ງນັ້ນ, ທ່ານມີແນວໂນ້ມຫນ້ອຍທີ່ຈະແນະນໍາຂໍ້ບົກພ່ອງຂອງລະຫັດ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດສົ່ງມູນຄ່າຫຼາຍກວ່າທໍາອິດໂດຍບໍ່ຈໍາເປັນຕ້ອງແກ້ໄຂຂໍ້ບົກພ່ອງ.
ຂັ້ນຕອນເລັກນ້ອຍ: ການປ່ຽນແປງໃຫຍ່ແມ່ນມີຄວາມສ່ຽງ. XP ຫຼຸດຜ່ອນຄວາມສ່ຽງດັ່ງກ່າວໂດຍການປ່ຽນແປງໃນຂັ້ນຕອນນ້ອຍໆ, ໃນທຸກລະດັບ.
ຜູ້ຂຽນໂປລແກລມຂຽນລະຫັດໃນຂັ້ນຕອນນ້ອຍໆໂດຍໃຊ້ການພັດທະນາແບບທົດສອບ. ພວກເຂົາເຈົ້າປະສົມປະສານລະຫັດຂອງພວກເຂົາເຂົ້າໄປໃນສາຍຫຼັກຫຼາຍຄັ້ງຕໍ່ມື້, ແທນທີ່ຈະພຽງແຕ່ທຸກໆສອງສາມອາທິດຫຼືແມ້ກະທັ້ງເດືອນ. ໂຄງການຕົວມັນເອງໃຊ້ເວລາສະຖານທີ່ໃນຮອບວຽນສັ້ນແທນທີ່ຈະເປັນໄລຍະທີ່ຍາວນານ.
ຍອມຮັບຄວາມຮັບຜິດຊອບ: ໃນ XP, ຄວາມຮັບຜິດຊອບຄວນໄດ້ຮັບການຍອມຮັບ, ບໍ່ເຄີຍມອບຫມາຍ.
ຄວາມຮັບຜິດຊອບຄວນມາພ້ອມກັບສິດອໍານາດໃນການຕັດສິນໃຈກ່ຽວກັບສິ່ງທີ່ທ່ານຮັບຜິດຊອບ. ກົງກັນຂ້າມຍັງເປັນຄວາມຈິງ. ທ່ານບໍ່ຕ້ອງການໃຫ້ຄົນຕັດສິນໃຈຖ້າພວກເຂົາບໍ່ຈໍາເປັນຕ້ອງອາໄສຢູ່ກັບຜົນສະທ້ອນຂອງພວກເຂົາ.
ການຂຽນໂປລແກລມທີ່ຮຸນແຮງ, ເປັນວິທີການທີ່ວ່ອງໄວ, ສາມາດໄດ້ຮັບການຍອມຮັບແລະເລີ່ມຕົ້ນທີ່ຈະຮັບຮອງເອົາມັນໂດຍບໍ່ມີການປະຕິບັດຕາມແຜນການທີ່ເຄັ່ງຄັດ. ນີ້ແມ່ນການອອກແບບຊ້ໍາແທນທີ່ຈະເປັນໂຄງການເບື້ອງຕົ້ນຂະຫນາດໃຫຍ່.
XP ມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຈາກວິທີການແບບດັ້ງເດີມ, i.e. cascading, ຫຼີກເວັ້ນການໄລຍະເວລາດົນນານ.
XP ແຕກຕ່າງຈາກວິທີການທີ່ວ່ອງໄວອື່ນໆແນວໃດ?
ການຂຽນໂປລແກລມທີ່ຮຸນແຮງ, ໂດຍທໍາມະຊາດຂອງມັນ, ມີຫຼາຍແບບດຽວກັນກັບວິທີການທີ່ວ່ອງໄວອື່ນໆ, ແຕ່ຍັງເປັນເອກະລັກໃນບັນດາພວກມັນ.
ວິທີການພັດທະນາອື່ນໆສ່ວນໃຫຍ່ບໍ່ໄດ້ເວົ້າຫຼາຍ, ຖ້າມີຫຍັງ, ກ່ຽວກັບວິທີເຮັດວຽກໃຫ້ສໍາເລັດ. ໃນທາງກົງກັນຂ້າມ, XP ແມ່ນມີຄວາມຄິດເຫັນຫຼາຍເມື່ອເວົ້າເຖິງເລື່ອງນີ້ແລະເນັ້ນຫນັກເຖິງການປະຕິບັດດ້ານວິສະວະກໍາຊອບແວ.
Scrum ເປັນກອບເພື່ອຊ່ວຍໃຫ້ທີມງານພັດທະນາໂຄງການທີ່ສັບສົນໃນວິທີການປັບຕົວ. Scrum ບໍ່ໄດ້ກໍານົດວິທີການທີ່ນັກພັດທະນາເຮັດວຽກຂອງເຂົາເຈົ້າ. XP, ດັ່ງທີ່ໄດ້ກ່າວມາ, ເນັ້ນຫນັກຫຼາຍກ່ຽວກັບການປະຕິບັດການຂຽນໂປຼແກຼມທີ່ດີ.
ຮ່າງ BlogInnovazione.en ຮູບພາບ ວິທີແກ້ໄຂສຸດທິ
ນອກຈາກນີ້, XP ແມ່ນແນ່ນອນກ່ຽວກັບການດໍາເນີນໂຄງການ. ໃນທາງກົງກັນຂ້າມ, Scrum ສາມາດຖືກນໍາໃຊ້ກັບໂຄງການໃດໆທີ່ໄດ້ຮັບຜົນປະໂຫຍດຈາກວິທີການຊ້ໍາກັນ.
XP ຍອມຮັບການປ່ຽນແປງອົງປະກອບຂອງມັນ. ທີມງານໄດ້ຮັບຄວາມເຂັ້ມແຂງແລະແມ້ກະທັ້ງໄດ້ຮັບການຊຸກຍູ້ໃຫ້ດັດແປງການປະຕິບັດໂດຍອີງໃສ່ຄວາມຕ້ອງການສະເພາະຂອງເຂົາເຈົ້າ. ໃນທາງກົງກັນຂ້າມ, ຄູ່ມື Scrum ແມ່ນຫມັ້ນໃຈວ່າ "ເຖິງແມ່ນວ່າບາງສ່ວນຂອງ Scrum ສາມາດປະຕິບັດໄດ້, ຜົນໄດ້ຮັບບໍ່ແມ່ນ Scrum."
ນອກຈາກນີ້, Scrum ແມ່ນໂຄງຮ່າງການທີ່ຕ້ອງໄດ້ຮັບການປະສົມປະສານກັບວິທີການແລະການປະຕິບັດເພື່ອໃຫ້ວຽກງານສໍາເລັດ.
ນີ້ຫມາຍຄວາມວ່າການເຮັດວຽກໃນການຂຽນໂປລແກລມທີ່ຮຸນແຮງແລະ Scrum ແມ່ນແນະນໍາໃຫ້ສູງ.
ອີງຕາມການ Kent Beck, ທີມງານ XP ຜູ້ໃຫຍ່ບໍ່ຄວນມອບຫມາຍບົດບາດທີ່ເຄັ່ງຄັດ, ແຕ່ຮັບຮູ້ວ່າບົດບາດສາມາດເປັນປະໂຫຍດສໍາລັບທີມງານທີ່ຫຼົບຫຼີກຈົນກ່ວາພວກເຂົາເລີ່ມຊ້າລົງຫຼືເຮັດໃຫ້ການຮ່ວມມືມີຄວາມຫຍຸ້ງຍາກ.
ຂໍໃຫ້ເບິ່ງບາງບົດບາດສໍາຄັນ:
ເຫຼົ່ານີ້ແມ່ນການປະຕິບັດທີ່ໄດ້ຮັບຮອງເອົາໃນ XP. ພວກເຂົາແບ່ງອອກເປັນສາມກຸ່ມຕົ້ນຕໍ: ວິສະວະກໍາຊອບແວ, ສະຖານທີ່ເຮັດວຽກແລະການຄຸ້ມຄອງໂຄງການ.
ຄູ່ໂຄງການ: ໃນ XP, ທ່ານຂຽນລະຫັດເປັນຄູ່ນັ່ງຢູ່ໃນເຄື່ອງ. ເຈົ້າແລະຄູ່ຜົວເມຍຂອງເຈົ້າລົມກັນໃນຂະນະທີ່ເຈົ້າວິເຄາະ, ປະຕິບັດ, ແລະທົດສອບຄຸນສົມບັດທີ່ເຈົ້າກໍາລັງເຮັດວຽກຢູ່. ການຂຽນໂປຼແກຼມຄູ່ແມ່ນດີໂດຍສະເພາະໃນການຜະລິດລະຫັດທີ່ມີຂໍ້ບົກພ່ອງຫນ້ອຍລົງໃນຂະນະທີ່ຍັງມີສ່ວນຮ່ວມ, ມ່ວນ, ແລະເມື່ອຍ.
ຂີດຈຳກັດສິບນາທີ: ຕ້ອງການອະນຸຍາດໃຫ້ໃຊ້ເວລາ 10 ນາທີເພື່ອສ້າງໂຄງການທັງຫມົດ, ລວມທັງການທົດສອບອັດຕະໂນມັດທັງຫມົດ, ໃນສິບນາທີສູງສຸດ. ຂີດຈຳກັດນີ້ແມ່ນເພື່ອຮັກສາການທົດສອບໃຫ້ມີປະສິດທິພາບ ແລະມີປະສິດທິພາບ.
ການທົດສອບກ່ອນທີ່ຈະດໍາເນີນໂຄງການ: ປະຕິບັດຄຸນສົມບັດໂດຍໃຊ້ວິທີການທົດສອບຄັ້ງທໍາອິດ, ເອີ້ນວ່າ ການພັດທະນາແບບທົດສອບ (TDD). TDD ປະກອບດ້ວຍການພັດທະນາໂດຍໃຊ້ຂັ້ນຕອນການເຮັດຊ້ຳແບບງ່າຍໆ:
TDD ເອົາຜົນປະໂຫຍດຫຼາຍຢ່າງ.
ກ່ອນອື່ນ ໝົດ, ຄຳ ຕິຊົມ. ຖ້າມັນຍາກທີ່ຈະຂຽນແບບທົດສອບ, ການອອກແບບທີ່ເຈົ້າກໍາລັງຊອກຫາຫຼືວ່າເຈົ້າໄດ້ຮັບມໍລະດົກແມ່ນອາດຈະສັບສົນເກີນໄປແລະທ່ານຈໍາເປັນຕ້ອງເຮັດໃຫ້ມັນງ່າຍດາຍ.
ອັນທີສອງ, TDD ອະນຸຍາດໃຫ້ນັກຂຽນໂປລແກລມໄວ້ວາງໃຈລະຫັດທີ່ເຂົາເຈົ້າຂຽນແລະສ້າງຈັງຫວະ looping ງາມທີ່ຂັ້ນຕອນຕໍ່ໄປແມ່ນຈະແຈ້ງສະເຫມີ.
ສຸດທ້າຍແຕ່ບໍ່ໄດ້ຢ່າງຫນ້ອຍ, ການນໍາໃຊ້ TDD ຕັ້ງແຕ່ເລີ່ມຕົ້ນຮັບປະກັນການຄຸ້ມຄອງລະຫັດ 100%. ຊຸດການທົດສອບຫຼັງຈາກນັ້ນກາຍເປັນຕາຫນ່າງຄວາມປອດໄພຢ່າງແທ້ຈິງສໍາລັບການປ່ຽນແປງໃນອະນາຄົດ, ຊຸກຍູ້ໃຫ້ມີການປັບປຸງລະຫັດແລະການສ້າງວົງມົນທີ່ມີຄຸນນະພາບ.
ການອອກແບບທີ່ເພີ່ມຂຶ້ນ: ການປະຕິບັດການອອກແບບທີ່ເພີ່ມຂຶ້ນຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງລົງທຶນໃນການອອກແບບຄໍາຮ້ອງສະຫມັກຂອງທ່ານທຸກໆມື້, ຊອກຫາໂອກາດທີ່ຈະເອົາການຊໍ້າຊ້ອນແລະປັບປຸງຂະຫນາດນ້ອຍເພື່ອບັນລຸການອອກແບບທີ່ດີທີ່ສຸດສໍາລັບສິ່ງທີ່ລະບົບຂອງທ່ານຕ້ອງການໃນມື້ນີ້.
ການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ: ໃນ XP, ທ່ານປະສົມປະສານວຽກງານຂອງທ່ານເຂົ້າໄປໃນບ່ອນເກັບມ້ຽນທີ່ແບ່ງປັນຕົ້ນຕໍຫຼາຍຄັ້ງຕໍ່ມື້, ເຮັດໃຫ້ເກີດການສ້າງອັດຕະໂນມັດຂອງລະບົບທັງຫມົດ. ການປະສົມປະສານໄວເທົ່າທີ່ຈະໄວເທົ່າທີ່ຈະໄວໄດ້ຈະຫຼຸດລົງຄ່າໃຊ້ຈ່າຍຂອງການເຊື່ອມໂຍງຢ່າງຫຼວງຫຼາຍຍ້ອນວ່າມັນເຮັດໃຫ້ການລວມຕົວແລະການຂັດແຍ້ງທີ່ມີເຫດຜົນຫນ້ອຍທີ່ຈະເກີດຂຶ້ນ. ມັນຍັງເປີດເຜີຍບັນຫາສິ່ງແວດລ້ອມແລະສິ່ງເສບຕິດ.
ລະຫັດແບ່ງປັນ (ຄວາມເປັນເຈົ້າຂອງລວມ): XP ສົ່ງເສີມລະຫັດຮ່ວມກັນ, ຫຼືການເປັນເຈົ້າຂອງລວມ: ນັກພັດທະນາແຕ່ລະຄົນຮັບຜິດຊອບຕໍ່ລະຫັດທັງຫມົດ. ມັນຊຸກຍູ້ການແລກປ່ຽນຂໍ້ມູນຂ່າວສານ, ຫຼຸດຜ່ອນປັດໃຈລົດເມຂອງທີມງານແລະເພີ່ມຄຸນນະພາບໂດຍລວມຂອງແຕ່ລະໂມດູນຖ້າພວກເຮົາພິຈາລະນາຫຼັກການຂອງຄວາມຫຼາກຫຼາຍ.
CodeBase ດຽວ: ຖານຂໍ້ມູນດຽວແມ່ນເອີ້ນວ່າ "ການພັດທະນາຕາມລໍາຕົ້ນ". ມັນຫມາຍຄວາມວ່າມີພຽງແຕ່ແຫຼ່ງຂອງຄວາມຈິງ. ດັ່ງນັ້ນ, ແທນທີ່ຈະພັດທະນາການຢູ່ໂດດດ່ຽວເປັນເວລາດົນນານ, ລວມການປະກອບສ່ວນຂອງທ່ານເຂົ້າໄປໃນສາຍນ້ໍາດຽວໃນຕອນຕົ້ນແລະເລື້ອຍໆ. ທຸງຄຸນສົມບັດຊ່ວຍຈຳກັດການນຳໃຊ້ຄຸນສົມບັດຂອງທ່ານຈົນກວ່າພວກມັນຈະສຳເລັດ.
ການແຈກຢາຍປະຈໍາວັນ: ການປະຕິບັດການຜະລິດຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງຕໍ່ມື້ເປັນຜົນສະທ້ອນຢ່າງມີເຫດຜົນຂອງການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ:. ໃນຄວາມເປັນຈິງ, ໃນມື້ນີ້, ຫຼາຍທີມໄປຍິ່ງໄປກວ່ານັ້ນແລະປະຕິບັດການປະຕິບັດຢ່າງຕໍ່ເນື່ອງ. ນັ້ນແມ່ນ, ທຸກຄັ້ງທີ່ຜູ້ໃດຜູ້ ໜຶ່ງ ເຂົ້າຮ່ວມສາຍຫຼັກ, ແອັບພລິເຄຊັນຈະຖືກ ນຳ ໃຊ້ເຂົ້າໃນການຜະລິດ.
ລະຫັດແລະການທົດສອບ: ການປະຕິບັດນີ້ຫມາຍຄວາມວ່າລະຫັດແຫຼ່ງ, ລວມທັງການທົດສອບ, ເປັນສິ່ງປະດິດຖາວອນດຽວຂອງໂຄງການຊອບແວ. ການມີສ່ວນຮ່ວມໃນການຜະລິດຂອງປອມປະເພດອື່ນໆ, ລວມທັງເອກະສານ, ມັກຈະເສຍເງິນເພາະວ່າມັນບໍ່ສ້າງມູນຄ່າທີ່ແທ້ຈິງສໍາລັບລູກຄ້າ.
ຖ້າທ່ານຕ້ອງການສິ່ງປະດິດຫຼືເອກະສານອື່ນໆ, ພະຍາຍາມສ້າງພວກມັນຈາກລະຫັດການຜະລິດແລະການທົດສອບ.
ການວິເຄາະສາເຫດຂອງຮາກ: ເມື່ອໃດກໍ່ຕາມຂໍ້ບົກພ່ອງເຂົ້າໄປໃນການຜະລິດ, ຢ່າພຽງແຕ່ແກ້ໄຂຂໍ້ບົກພ່ອງ. ໃຫ້ແນ່ໃຈວ່າທ່ານຊອກຫາສິ່ງທີ່ເຮັດໃຫ້ເກີດມັນໃນຕອນທໍາອິດ, ເປັນຫຍັງທ່ານແລະເພື່ອນຮ່ວມທີມຂອງທ່ານບໍ່ສາມາດປ້ອງກັນການ skid ໄດ້. ຫຼັງຈາກນັ້ນ, ດໍາເນີນຂັ້ນຕອນເພື່ອໃຫ້ແນ່ໃຈວ່າມັນຈະບໍ່ເກີດຂຶ້ນອີກ.
ນັ່ງຮ່ວມກັນ: ໃນ XP, ທີມງານມັກເຮັດວຽກຮ່ວມກັນໃນພື້ນທີ່ເປີດ. ການປະຕິບັດນີ້ສົ່ງເສີມການສື່ສານແລະຄວາມຮູ້ສຶກຂອງທີມງານ.
ທີມງານທັງຫມົດ: ທຸກຄົນທີ່ຕ້ອງການສໍາລັບຄວາມສໍາເລັດຂອງໂຄງການແມ່ນສ່ວນຫນຶ່ງຂອງທີມງານ XP. ນີ້ແມ່ນສະພາບການສູງ – ທີ່ແຕກຕ່າງກັນສໍາລັບແຕ່ລະທີມງານ – ແລະເຄື່ອນໄຫວ, ມັນສາມາດມີການປ່ຽນແປງພາຍໃນທີມ.
ພື້ນທີ່ເຮັດວຽກຂໍ້ມູນຂ່າວສານ: ພື້ນທີ່ເຮັດວຽກຂໍ້ມູນຂ່າວສານໃຊ້ພື້ນທີ່ທາງດ້ານຮ່າງກາຍຂອງທີມງານເພື່ອສະແດງຂໍ້ມູນທີ່ອະນຸຍາດໃຫ້ທຸກຄົນຮູ້, ໃນທັນທີ, ຄວາມຄືບຫນ້າຂອງໂຄງການ. ວິທີການນີ້ເຮັດສາມາດແຕກຕ່າງກັນ, ຈາກບັນທຶກທາງກາຍະພາບແລະກາຟເຖິງພາບຫນ້າຈໍສະແດງໃຫ້ເຫັນກະດານ Kanban ແລະ dashboards ຈາກຊອບແວການຄຸ້ມຄອງໂຄງການ.
ການເຮັດວຽກທີ່ມີພະລັງງານ: ໃນ XP, ທ່ານພຽງແຕ່ເຮັດວຽກເທົ່າທີ່ເຈົ້າສາມາດເຮັດວຽກຢ່າງແຂງແຮງ. ຊົ່ວໂມງເຮັດວຽກຕ້ອງຈໍາກັດ 40 ຕໍ່ອາທິດ, ສູງສຸດ.
Analisi- ຂຽນຄວາມຕ້ອງການຂອງຜູ້ໃຊ້ໃນຮູບແບບທີ່ເອີ້ນວ່າການວິເຄາະຜູ້ໃຊ້. ການວິເຄາະຜູ້ໃຊ້ມີຊື່ຫຍໍ້, ຄໍາອະທິບາຍແລະຍັງຄໍາອະທິບາຍສັ້ນໆກ່ຽວກັບສິ່ງທີ່ຕ້ອງປະຕິບັດ.
slack: ເມື່ອວາງແຜນຮອບວຽນ, ເພີ່ມວຽກງານເລັກນ້ອຍທີ່ທີມງານສາມາດປະຖິ້ມໄດ້ຖ້າຄວາມຕ້ອງການເກີດຂື້ນ. ບົດເລື່ອງເພີ່ມເຕີມສາມາດຖືກເພີ່ມໄດ້ຕະຫຼອດເວລາຖ້າທີມງານສະຫນອງຫຼາຍເກີນໄປ.
ຮອບວຽນ (ລາຍເດືອນ ແລະ ອາທິດ): ການພັດທະນາໃນ XP ເກີດຂຶ້ນໃນສອງວົງຈອນຕົ້ນຕໍ: ຮອບວຽນປະຈໍາອາທິດແລະຮອບວຽນປະຈໍາເດືອນ.
ກອງປະຊຸມ, ຮອບວຽນ, ກໍານົດເວລາອອກ: ການພັດທະນາໃນ XP ເຮັດວຽກຢູ່ໃນສອງວົງຈອນຕົ້ນຕໍ: ຮອບວຽນປະຈໍາອາທິດແລະວົງຈອນປະຈໍາໄຕມາດ. ໃນເບື້ອງຕົ້ນ, Kent Beck ໄດ້ແນະນໍາຮອບວຽນສອງອາທິດ, ແຕ່ໄດ້ປ່ຽນແປງໃນສະບັບທີສອງຂອງປື້ມຂອງລາວ.
ຮອບວຽນອາທິດ: ຮອບວຽນປະຈໍາອາທິດແມ່ນ "ກໍາມະຈອນ" ຂອງໂຄງການ XP. ວົງຈອນເລີ່ມຕົ້ນດ້ວຍກອງປະຊຸມທີ່ລູກຄ້າເລືອກເລື່ອງທີ່ລາວຕ້ອງການສ້າງໃນລະຫວ່າງອາທິດ. ນອກຈາກນັ້ນ, ທີມງານທົບທວນວຽກງານຂອງເຂົາເຈົ້າ, ລວມທັງຄວາມຄືບຫນ້າຂອງອາທິດທີ່ຜ່ານມາ, ແລະຄິດກ່ຽວກັບວິທີທີ່ຈະປັບປຸງຂະບວນການຂອງເຂົາເຈົ້າ.
ຮອບວຽນປະຈໍາເດືອນ: ທຸກໆເດືອນ, ທີມງານສະທ້ອນໃຫ້ເຫັນແລະກໍານົດໂອກາດການປັບປຸງໃນຂະບວນການຂອງພວກເຂົາ. ລູກຄ້າເລືອກຫນຶ່ງຫຼືຫຼາຍຫົວຂໍ້ສໍາລັບເດືອນນັ້ນ, ພ້ອມກັບການວິເຄາະໃນຫົວຂໍ້ເຫຼົ່ານີ້.
ວິທີການເລີ່ມຕົ້ນເຮັດວຽກກັບການຂຽນໂປລແກລມທີ່ຮຸນແຮງ?
ທັກສະດ້ານວິຊາການ ແລະນິໄສ XP ສາມາດຮຽນໄດ້ຍາກ. ບາງການປະຕິບັດອາດຈະເບິ່ງຄືວ່າຕ່າງປະເທດສໍາລັບນັກຂຽນໂປລແກລມບໍ່ໄດ້ໃຊ້ກັບພວກເຂົາ.
Ercole Palmeri
CMA ຂອງອັງກິດໄດ້ອອກຄໍາເຕືອນກ່ຽວກັບພຶດຕິກໍາຂອງ Big Tech ໃນຕະຫຼາດປັນຍາປະດິດ. ຢູ່ທີ່ນັ້ນ…
ດຳລັດ “Case Green” ທີ່ສ້າງຂຶ້ນໂດຍສະຫະພາບເອີລົບ ເພື່ອຍົກສູງປະສິດທິພາບດ້ານພະລັງງານຂອງຕຶກອາຄານ, ໄດ້ສິ້ນສຸດຂະບວນການນິຕິບັນຍັດຂອງຕົນດ້ວຍ…
ບົດລາຍງານປະຈໍາປີຂອງ Casaleggio Associati ກ່ຽວກັບອີຄອມເມີຊໃນອິຕາລີໄດ້ນໍາສະເຫນີ. ບົດລາຍງານຫົວຂໍ້ “AI-Commerce: ຊາຍແດນຂອງອີຄອມເມີຊທີ່ມີປັນຍາປະດິດ”.…
ຜົນຂອງນະວັດຕະກໍາເຕັກໂນໂລຊີຢ່າງຕໍ່ເນື່ອງແລະຄໍາຫມັ້ນສັນຍາກັບສິ່ງແວດລ້ອມແລະສະຫວັດດີການຂອງປະຊາຊົນ. Bandalux ນຳສະເໜີ Airpure®, tent…
