ແນວຄຶດຄືແນວ Agile vs ກົນໄກ Agile

https://flic.kr/p/bkcj5q

ຂ້າພະເຈົ້າເຫັນວ່າຊ້ ຳ ອີກວ່າທີມຊອບແວໄດ້ສຸມໃສ່ກົນໄກຫຼາຍເກີນໄປແລະບໍ່ເຫັນຫຼັກການພື້ນຖານ. ນີ້ແມ່ນຄວາມຈິງໂດຍສະເພາະຂອງວິທີການ Agile. ວິທີການຕ່າງໆເຊັ່ນ Scrum ມີກົນໄກຫຼາຍຢ່າງທີ່ເຮັດໃຫ້ຜູ້ທີ່ວ່ອງໄວຈະສູນເສຍໄປ ໝົດ. ໃນເບື້ອງຕົ້ນຂ້ອຍໄດ້ຂຽນອີເມວນີ້ໃຫ້ທີມງານຂອງຂ້ອຍເພື່ອໃຫ້ຄວາມກະຈ່າງແຈ້ງວ່າທັດສະນະຂອງຂ້ອຍກ່ຽວກັບ Agile ແມ່ນຫຍັງແຕ່ຂ້ອຍໄດ້ສົ່ງມັນໄປໃຫ້ຫຼາຍໆຄົນໃນຕອນນີ້, ວ່າການກິນ ຄຳ ແນະ ນຳ ຂອງ Scott Hanselman, ຂ້ອຍ ກຳ ລັງປ່ຽນມັນເຂົ້າໃນບົດຄວາມ blog.

ຂ້ອຍຖືວ່າຕົວເອງມີຄຸນສົມບັດບາງຢ່າງທີ່ຈະສະ ໜອງ ຄວາມເຂົ້າໃຈນີ້. ຂ້ອຍເປັນຜູ້ປະຕິບັດທີ່ວ່ອງໄວຕັ້ງແຕ່ມື້ທີ່ການພັດທະນາ Agile ມີສ່ວນຮ່ວມໂດຍໃຊ້ screwdriver - ເພື່ອມ້າງ cubicles ຂອງເຈົ້າເອງແລະສ້າງແຜນການນັ່ງທີ່ນັ່ງ!

ໃນຕົ້ນອາຊີບຂ້ອຍເຮັດວຽກກັບບໍລິສັດຊອບແວການແພດ. ພວກເຮົາໄດ້ສ້າງໂປແກຼມຄອມພິວເຕີ້ desktop ສຳ ລັບການກວດສອບຮູບພາບເຊິ່ງຖືກຕິດຕັ້ງຢູ່ເທິງ ໜ້າ ຈໍຂອງ Doctor ໃນໂຮງ ໝໍ. ຂະບວນການປະຕິບັດການມີສ່ວນຮ່ວມໃນການເດີນທາງກັບ CDs ໄປເມືອງອື່ນແລະຕິດຕັ້ງ desktop, ແລະ server server. ພວກເຮົາຕ້ອງໄດ້ຮັບການອະນຸມັດຈາກ FDA, ດັ່ງນັ້ນພວກເຮົາຕ້ອງໄດ້ສ້າງຕົວຢ່າງທີ່ໄດ້ຜ່ານການອະນຸມັດຈາກ FDA. ສິ່ງດັ່ງກ່າວໄດ້ສ້າງສະພາບແວດລ້ອມທີ່ ເໝາະ ສົມ ສຳ ລັບວິທີການລົງເທິງ, ລຸ່ມນ້ ຳ ຕົກ. ສະເປັກທັງ ໝົດ ຖືກຂຽນລົງ, ອະນຸມັດ, ລົງນາມແລະພວກເຮົາກໍ່ສ້າງກັບສະເປັກແລະຂໍ້ ກຳ ນົດເຫຼົ່ານັ້ນເທົ່ານັ້ນ. ມັນບໍ່ແມ່ນຈົນກ່ວາທີມ dev ເລີ່ມຕົ້ນເດີນທາງກັບທີມຕິດຕັ້ງ, ແລະເບິ່ງທ່ານ ໝໍ ໃຊ້ຊອບແວຂອງພວກເຮົາ, ພວກເຮົາຮູ້ວ່າພວກເຮົາສາມາດເຮັດໄດ້ດີກວ່າເທົ່ານັ້ນຖ້າພວກເຮົາສາມາດລົມກັບລູກຄ້າກ່ອນໃນຮອບວຽນ. ພວກເຮົາໄດ້ລະຫັດກັບຂໍ້ ກຳ ນົດທີ່ແນ່ນອນ, ແລະຍັງໄດ້ສົ່ງບາງສິ່ງບາງຢ່າງທີ່ບໍ່ເປັນປະໂຫຍດເທົ່າທີ່ມັນສາມາດເປັນໄປໄດ້. ຮູບພາບນີ້ສະແດງໃຫ້ເຫັນບາງປະສົບການຂອງຂ້ອຍ.

ວິທີການພັດທະນາໂປແກຼມສາມາດໄປໄດ້ທີ່ ໜ້າ ງຶດງໍ້ຈາກ https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

ໃນຊ່ວງເວລານີ້ທີມງານຂອງຂ້ອຍໄດ້ຍິນບາງສິ່ງບາງຢ່າງທີ່ເອີ້ນວ່າ Agile Manifesto ແລະການປະຕິບັດທີ່ເອີ້ນວ່າ Extreme Programming. ເນື່ອງຈາກວ່າມັນໄດ້ຖືກເຊັນໂດຍນັກຮົບເກົ່າໃນອຸດສາຫະກໍາທີ່ມີປື້ມທີ່ພວກເຮົາ ກຳ ລັງອ່ານຢ່າງຈິງຈັງ, ຄົນເຊັ່ນ Martin Fowler ແລະ Kent Beck ໄດ້ໃຫ້ເຊົ່າການປະຕິບັດທີ່ຖືກຕ້ອງຕາມກົດ ໝາຍ ຫຼາຍຢ່າງ. ທີມງານຂອງຂ້າພະເຈົ້າທັງ ໝົດ 5 ຍົກເລີກ cubicles ຂອງພວກເຮົາ, ດຶງໃນ PM ຂອງພວກເຮົາ (ຕົວແທນໃຫ້ລູກຄ້າຂອງພວກເຮົາ) ມານັ່ງຢູ່ຂ້າງພວກເຮົາ, ຕັ້ງກະດານທີ່ມີບັດດັດສະນີແລະອອກໄປເຮັດວຽກ, ເຮັດ XP ຂຶ້ນດັ່ງທີ່ພວກເຮົາໄປພ້ອມ. ພວກເຮົາມີຮອບວຽນປະ ຈຳ ອາທິດຂອງການວາງແຜນແລະການວາງສະແດງ, ການຈັບຄູ່ແລະສົນທະນາ. ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກໃນການຕີລາຄາແລະການປ່ຽນແປງຂອງສິ່ງນີ້, ໃນບໍລິສັດທີ່ແຕກຕ່າງກັນປະມານ 15 ປີ. ທີມງານ ໜຶ່ງ ເບິ່ງຄືວ່າບໍ່ປະຕິບັດຕາມວິທີການໃດໆ, ແຕ່ມັນກໍ່ຍ້ອນວ່າສະມາຊິກໃນທີມທັງ ໝົດ ແມ່ນມາຈາກພື້ນຖານທີ່ວ່ອງໄວ, ການຟື້ນຟູແລະການຮ່ວມມືແມ່ນສະພາບການປະຕິບັດງານຂອງພວກເຂົາແລະພວກເຂົາບໍ່ ຈຳ ເປັນຕ້ອງມີຂະບວນການບັງຄັບ.

ສະນັ້ນ Agile ກ່ຽວກັບແຜນການເປີດກວ້າງຫລືເວົ້າຫຼາຍບໍ? ຖ້າທ່ານມີການຢືນແລະຕອບໂຕ້ຄືນທ່ານສາມາດອ້າງວ່າເປັນ Agile ບໍ? Scrum ຫຼື TDD ຢູ່ໃນບ່ອນໃດ? ສ່ວນຫຼາຍຄົນມັກຈະຖືກຈັບສະເພາະເຈາະຈົງໃນຂະບວນການສະເພາະ - Scrum ຫຼື Kanban? ສອງອາທິດຫລື ໜຶ່ງ ອາທິດແມ່ນງອກ? ຖ້າທ່ານບໍ່ມີການແຕ່ງຕົວ, ທ່ານກໍ່ ກຳ ລັງວ່ອງໄວບໍ? ໄດ້ເຕີບໃຫຍ່ຂຶ້ນໃນການພັດທະນາຢ່າງຫ້າວຫັນໂດຍໃຊ້ວິທີການ Agile, ກັບນັກພັດທະນາຄົນອື່ນໆທີ່ມີສ່ວນຮ່ວມ, ພັດທະນາແລະປັບຕົວການປະຕິບັດ, ໄດ້ໃຫ້ຂ້ອຍມີຄວາມເຂົ້າໃຈທີ່ດີແລະໂພດນີ້ແມ່ນເພື່ອ ກຳ ນົດຫຼັກການພື້ນຖານ.

ເປັນ Agile ແມ່ນສາມາດຕອບສະ ໜອງ ຄວາມຕ້ອງການຂອງລູກຄ້າໄດ້ອຍ່າງລວດໄວ. ໝາຍ ຄວາມວ່າພວກເຮົາຂຽນລະຫັດໄວກວ່ານີ້ບໍ? ບໍ່. ພວກເຮົາບໍ່ສາມາດຕີກົດ ໝາຍ ຟີຊິກ, ແລະການ ນຳ ໃຊ້ທີ່ມີປະໂຫຍດຫຼາຍຢ່າງຕ້ອງໃຊ້ເວລາໃນການສ້າງ.

ສິ່ງທີ່ພວກເຮົາຕ້ອງເຮັດແມ່ນ

  1. ກຳ ນົດບັນຫາທຸລະກິດທີ່ ສຳ ຄັນທີ່ພວກເຮົາຕ້ອງການແກ້ໄຂດ້ວຍລະຫັດ
  2. ແຈກຢາຍວິທີແກ້ໄຂທາງທິດສະດີໃຫ້ໄວເພື່ອທົດສອບທິດສະດີ
  3. ປັບຕົວແລະປັບຕົວຕາມຄວາມຕ້ອງການປ່ຽນແປງ, ຫຼືພວກເຮົາຮຽນຮູ້ເພີ່ມເຕີມ
  4. ເຮັດໃນການຮ່ວມມື, ກັບລູກຄ້າເປັນສ່ວນ ໜຶ່ງ ຂອງທີມ

ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາເຮັດແມ່ນເຮັດໃຫ້ 2 ແລະ 3 ຂ້າງເທິງບໍ່ເຈັບປວດຫນ້ອຍ - ເພື່ອຮູ້ວ່າພວກເຮົາ ກຳ ລັງຕອບສະ ໜອງ ຄວາມຕ້ອງການໄດ້ໄວທີ່ສຸດແລະຖ້າບໍ່ສາມາດປ່ຽນແປງໄດ້ໄວ. ຖ້າທ່ານໄດ້ຕັດສິນໃຈສ້າງ (vs ຊື້), ທ່ານ ກຳ ລັງຂຽນໂປແກຼມທີ່ ກຳ ຫນົດເອງ. ນີ້ຫມາຍຄວາມວ່າມັນມີຄວາມຕ້ອງການແລະສະພາບແວດລ້ອມທີ່ຊ່ຽວຊານ.

ການໄດ້ຮັບບາງສິ່ງບາງຢ່າງທີ່ເບິ່ງເຫັນ, ເຖິງແມ່ນວ່າມັນຈະເປັນ ໜ້າ ທີ່ນ້ອຍໆຂອງ ໜ້າ ທີ່, ຢູ່ຕໍ່ ໜ້າ ລູກຄ້າໄວເທົ່າທີ່ຈະເປັນໄປໄດ້ຊ່ວຍໃຫ້ພວກເຮົາໄດ້ຮັບ ຄຳ ຕິຊົມໄວຂຶ້ນ. ນີ້ແມ່ນເຫດຜົນທີ່ຂ້ອຍສະ ໜັບ ສະ ໜູນ ໃຫ້ສຸມໃສ່ການສ້າງຄຸນລັກສະນະນ້ອຍໆ, ຈຸດຈົບແລະສິ້ນສຸດລົງ, ແລະເຮັດທຸກວິທີທາງໃນການຜະລິດ. ເວົ້າວ່າ, ທ່ານ ກຳ ລັງສ້າງ ໜ້າ ສຳ ລັບຕົວແທນສະ ໜັບ ສະ ໜູນ ຂອງທ່ານເພື່ອເບິ່ງຂໍ້ມູນທັງ ໝົດ ກ່ຽວກັບລູກຄ້າ. ແທນທີ່ຈະໃຊ້ເວລາຫລາຍໃນການຄົ້ນຄ້ວາແຫລ່ງຂໍ້ມູນ ສຳ ລັບ ໜ້າ ທັງ ໝົດ ແລະຂຽນ API ທັງ ໝົດ ກ່ອນ, ພະຍາຍາມເອົາຂໍ້ມູນຍ່ອຍລົງໃນ ໜ້າ ທຸກວິທີໃນການຜະລິດ. ທ່ານຈະສາມາດປະຕິບັດກົນໄກການເຊື່ອມໂຍງແລະການປະຕິບັດງານຂອງທ່ານ, ທ່ານສາມາດເລີ່ມຕົ້ນໄດ້ຮັບການຕອບຮັບກ່ຽວກັບກອບ UI, ວິທີທີ່ ໜ້າ ນີ້ ເໝາະ ສົມກັບສ່ວນທີ່ເຫຼືອຂອງທ່ານແລະອື່ນໆ. ເມື່ອທ່ານໄດ້ສ້າງກອບ API ທັງ ໝົດ.

ນີ້ແມ່ນບາງກົນໄກອື່ນໆທີ່ ຈຳ ເປັນຕໍ່ການແຂງຂັນ

Sprints: ການພັດທະນາຮອບວຽນໃນປ່ອງທີ່ໃຊ້ເວລາ, ຊ່ວຍໃຫ້ພວກເຮົາກວດກາແລະປັບຕົວ, ແລະລວມເອົາຂໍ້ມູນ ໃໝ່ ເຂົ້າກັນເປັນປະ ຈຳ ເພື່ອຮັບປະກັນວ່າພວກເຮົາຍັງເຮັດວຽກກ່ຽວກັບຄຸນລັກສະນະທີ່ກ່ຽວຂ້ອງ. ຊອບແວແມ່ນຄວາມຮັບຜິດຊອບ. ພວກເຮົາຄວນສ້າງສິ່ງທີ່ພວກເຮົາຕ້ອງການເທົ່ານັ້ນ, ແລະສາມາດເພີ່ມສິ່ງທີ່ ຈຳ ເປັນ, ເມື່ອ ຈຳ ເປັນ. ສະນັ້ນມັນເປັນສິ່ງ ຈຳ ເປັນທີ່ຈະຕ້ອງໄດ້ເບິ່ງສິ່ງທີ່ພວກເຮົາໄດ້ສ້າງມາຈົນເຖິງປະຈຸບັນແລະບ່ອນທີ່ພວກເຮົາຈະໄປຕໍ່ໄປ. ນີ້ ນຳ ໄປສູ່ຈຸດທີສອງ.

ຍ້ອນວ່າພວກເຮົາ ກຳ ລັງວາງແຜນທີ່ຈະປະເມີນແລະປ່ຽນແປງເລື້ອຍໆ, ຊອບແວຂອງພວກເຮົາຄວນຈະງ່າຍຕໍ່ການປ່ຽນແປງ. ຈະເປັນແນວໃດຖ້າວ່າ, ຫຼັງຈາກລູກຄ້າເລີ່ມຕົ້ນ ນຳ ໃຊ້ໂປແກຼມທີ່ພວກເຂົາຕ້ອງການໃຫ້ຂໍ້ມູນບາງຢ່າງສະແດງອອກທີ່ແຕກຕ່າງຈາກການອອກແບບເດີມ? ພວກເຮົາສາມາດເຮັດສິ່ງນັ້ນໄດ້ໂດຍບໍ່ຕ້ອງ ສຳ ຜັດທຸກຢ່າງໃນ ໜ້າ ນີ້ບໍ? ຫຼືພວກເຮົາຕ້ອງການໂທຫາ API ທີ່ແຕກຕ່າງກັນເພື່ອໃຫ້ໄດ້ຂໍ້ມູນ - ພວກເຮົາສາມາດເຮັດການປ່ຽນແປງນັ້ນໄດ້ຢ່າງປອດໄພບໍ? ນີ້ແມ່ນບ່ອນທີ່ການປະຕິບັດແລະກົນໄກການພັດທະນາທີ່ດີເຂົ້າມາ

ການທົດສອບຫົວ ໜ່ວຍ: ພວກເຮົາມີການທົດສອບອັດຕະໂນມັດໃນລະດັບຕ່າງໆດັ່ງນັ້ນຈຶ່ງມີຕາ ໜ່າງ ຄວາມປອດໄພ ສຳ ລັບການປ່ຽນແປງ. ມັນຍັງມີຄວາມ ສຳ ຄັນທີ່ຈະຕ້ອງເອົາໃຈໃສ່ໃນສິ່ງທີ່ ໜ່ວຍ ງານທົດສອບຕົວຈິງ. ການທົດສອບຫົວ ໜ່ວຍ ຄວນທົດສອບຕາມເຫດຜົນ. ຖ້າທ່ານເອົາຕົວຢ່າງຂ້າງເທິງ, ການ ນຳ ໃຊ້ API ທີ່ແຕກຕ່າງກັນເພື່ອໃຫ້ໄດ້ຂໍ້ມູນ, ໂດຍສະເພາະ, ບໍ່ ຈຳ ເປັນຕ້ອງມີການປ່ຽນແປງໃດໆຕໍ່ການທົດສອບຫົວ ໜ່ວຍ ສຳ ລັບ API ຂອງພວກເຮົາທີ່ໃຫ້ຂໍ້ມູນກັບ UI. ການທົດສອບຫົວ ໜ່ວຍ ມີເພື່ອໃຫ້ທ່ານມີຄວາມ ໝັ້ນ ໃຈໃນການປັບລະຫັດ, ເຊິ່ງໃນນັ້ນຈະໃຫ້ສິດເສລີພາບໃນການຂຽນພຽງແຕ່ສິ່ງທີ່ທ່ານຕ້ອງການດຽວນີ້, ແລະພັກຜ່ອນໃນພາຍຫລັງ, ບໍ່ໃຫ້ຜະລິດແມັດ ຈຳ ນວນປະມານ 100% ເຖິງຢ່າງໃດກໍ່ຕາມທ່ານສາມາດເຮັດໄດ້.

CI / CD: ສິ່ງນີ້ຊ່ວຍໃຫ້ພວກເຮົາຫຼຸດໄລຍະຫ່າງລະຫວ່າງການຜູກມັດແລະການຈັດສົ່ງ. ນີ້ແມ່ນສິ່ງທີ່ ຈຳ ເປັນ ສຳ ລັບການແຂງຂັນ. ເມື່ອສິ່ງກີດຂວາງໃນການ ນຳ ໃຊ້ຖືກຍ້າຍອອກ, ແລະພວກເຮົາສາມາດຍູ້ການປ່ຽນແປງນ້ອຍໆໃນການຜະລິດ, ຄວາມສ່ຽງຈາກການປ່ຽນແປງແມ່ນຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ຖ້າການ ນຳ ໃຊ້ມີຄວາມ ໜ້າ ເບື່ອຫນ່າຍ, ພວກມັນຈະຄ່ອຍໄປເລື້ອຍໆ. ການປະຕິບັດງານເລື້ອຍໆຫນ້ອຍລົງຍູ້ການປ່ຽນແປງອອກ, ແຕະພື້ນທີ່ກ້ວາງໃຫຍ່, ແລະເພາະສະນັ້ນຈຶ່ງມີຄວາມສ່ຽງສູງ. ຖ້າທ່ານຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບວ່າເປັນຫຍັງການປະຕິບັດການຈັດສົ່ງຊອບແວຈຶ່ງມີຄວາມ ສຳ ຄັນ, ແລະມີສິ່ງທີ່ວັດແທກເພື່ອໃຊ້ໃນການເພີ່ມປະສິດທິພາບ, ຂ້ອຍຂໍແນະ ນຳ ປື້ມຫົວນີ້ໂດຍ Nicole Forsgren.

ການແຍກຄວາມກັງວົນ: ສະຖາປັດຕະຍະ ກຳ ບວກກັບທີ່ວ່າງເປັນສິ່ງ ຈຳ ເປັນ ສຳ ລັບຊອບແວທີ່ມີການປ່ຽນແປງງ່າຍ. ມັນຫຼຸດຜ່ອນພື້ນທີ່ ໜ້າ ດິນຂອງການປ່ຽນແປງ. ເຄື່ອງຄອມພິວເຕີ້ແລະພາຊະນະບັນຈຸແມ່ນກົນໄກບາງຢ່າງທີ່ໃຊ້ໃນການອອກ ກຳ ລັງກາຍແຍກຄວາມກັງວົນ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຈື່ຈໍາສິ່ງນີ້, ແລະໃຫ້ແນ່ໃຈວ່າຈະຮັກສາຄວາມກັງວົນແຍກຕ່າງຫາກໄວ້ໃນໃຈ, ເມື່ອສ້າງ API, ສ່ວນປະກອບແລະແອັບພລິເຄຊັນຕ່າງໆ.

ຈືຂໍ້ມູນການ
ລະຫັດດີສາມາດປ່ຽນແປງໄດ້ງ່າຍ

ລະຫັດທີ່ດີກວ່າສາມາດລຶບໄດ້ງ່າຍ

ລະຫັດທີ່ດີທີ່ສຸດແມ່ນສິ່ງທີ່ບໍ່ໄດ້ຖືກຂຽນໄວ້ທັງ ໝົດ

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