ທີມງານທີ່ເຕີບໃຫຍ່ຂື້ນດ້ວຍ Agile Scrum

QueryPie Development # 3: ການແນະ ນຳ ຂັ້ນຕອນການພັດທະນາ

한국어: https://medium.com/p/cfaa4b71c263/

ບໍ່ມີລູກປືນເງິນໃນໂລກ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ມະນຸດມີຄວາມສ່ຽງຕໍ່ຄວາມປາຖະ ໜາ ທຸກປະເພດແລະ ກຳ ລັງຊອກຫາກະເປົາເງິນ.

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

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

ເປັນຜົນມາຈາກຄວາມກັງວົນນັ້ນ, ຂ້ອຍພົບ Agile. ສະນັ້ນບັນທຶກຂອງນັກພັດທະນານີ້ຈະອະທິບາຍປະສົບການຂອງຂ້ອຍກັບ Agile Development.

ວ່ອງໄວ: ສືບຕໍ່ປັບປຸງໂດຍຜ່ານການປະນີປະນອມ

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

ສະນັ້ນ, Agile ແມ່ນຫຍັງ?

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

ມີຫຼາຍຂະບວນການພັດທະນາ Agile. Scrum, Kanban, ແລະການຂຽນໂປຼແກຼມທີ່ສຸດ (XP) ແມ່ນມີ ໜ້ອຍ. ແຕ່ລະຄົນມີລັກສະນະແຕກຕ່າງກັນແລະມີຂອບເຂດທີ່ແຕກຕ່າງກັນ, ແຕ່ສາມາດ ນຳ ໃຊ້ປະສົມປະສານກັບກັນແລະກັນ.

ການທົດລອງແລະຄວາມຜິດພາດຂອງ Team Leader ໃໝ່ ກັບ Agile Scrum ທຳ ອິດ

ໃນປີ 2011, ຂ້ອຍໄດ້ກາຍເປັນຫົວ ໜ້າ ທີມນັກພັດທະນາກຸ່ມຂອງຂ້ອຍເອງແລະເລີ່ມຄິດກ່ຽວກັບວິທີທີ່ທີມງານຄວນຈະເຮັດວຽກ. ການສຶກສາວິທີການພັດທະນາຊອບແວເຮັດໃຫ້ມີຄວາມສົນໃຈໃນ Agile. ຂ້າພະເຈົ້າຮູ້ສຶກປະທັບໃຈທີ່ສຸດເມື່ອໄດ້ອ່ານປື້ມ Scrum ແລະ XP ຈາກ Trenches.

Scrum ແລະ XP ຈາກ Trenches, ວິທີທີ່ພວກເຮົາເຮັດ Scrum ໂດຍ Henrik Kniberg

ການໃຊ້ itcr Scrum ແມ່ນ ເໝາະ ສົມແລະ ໜ້າ ສົນໃຈ. ທີມງານຈັດການກັບ ໜ້າ ວຽກເປັນການກັບຄືນ, ວາງແຜນແລະແກ້ໄຂໂດຍອີງໃສ່ວົງຈອນການພັດທະນາແບບສັ້ນໆທີ່ມີຊື່ວ່າ Sprint, ແລະສ້າງການພັດທະນາແລະປັບປຸງຢ່າງຕໍ່ເນື່ອງ.

ຂະບວນການ Scrum (ແຫຼ່ງຂໍ້ມູນ: https://en.wikipedia.org/wiki/Scrum_(software_development))

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

ສະນັ້ນທີມງານຂອງຂ້ອຍໄດ້ກັບຄືນໄປຫາວິທີທີ່ພວກເຮົາເຮັດວຽກກ່ອນ Scrum. ວິທີການເກົ່າຂອງພວກເຮົາເບິ່ງບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

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

ຂ້າພະເຈົ້າແນ່ໃຈວ່າທ່ານຈະບໍ່ແປກໃຈທີ່ໄດ້ຍິນວ່າຜູ້ຕິດຕາມຂອງທີມຂອງຂ້ອຍເຕັມໄປດ້ວຍບັນທຶກຫລັງຈາກນັ້ນ!

(ທີ່ມາ: https://happytango.com/…what-a-post-it-note-was/)

Kanban ແມ່ນງ່າຍດາຍແລະງ່າຍດາຍ, ແຕ່ວ່າມັນຫຼຸດລົງ 2% ທີ່ດີເລີດ

ໃນປີ 2013 ຂ້ອຍໄດ້ປ່ຽນວຽກແລະມີໂອກາດອີກໃນການພິຈາລະນາເຖິງຜົນງານຂອງທີມງານຂອງຂ້ອຍ. ປະມານເວລານັ້ນ, ປື້ມ Kanban ແລະ Scrum: ເຮັດໃຫ້ຫຼາຍທີ່ສຸດຂອງທັງສອງໄດ້ຖືກຈັດພີມມາ. ຂ້ອຍໄດ້ຮຽນຮູ້ຫຼາຍກ່ຽວກັບ Kanban ໂດຍການສຶກສາປື້ມຫົວນີ້.

Kanban ແລະ Scrum: ເຮັດໃຫ້ທັງສອງຂອງທັງສອງໂດຍ Henrik Kniberg ແລະ Mattias Skarin

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

ກະດານຜ້າໃບງ່າຍໆ (ແຫຼ່ງທີ່ມາ: https://en.wikipedia.org/wiki/Scrumban)

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

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

ແຕ່ຂ້ອຍຮູ້ສຶກຜິດຫລາຍຕໍ່ຄວາມລົ້ມເຫລວຂອງ Scrum ທຳ ອິດຂອງຂ້ອຍ. ຂ້ອຍຕ້ອງການເຮັດວຽກແບບທີ່ມີລະບົບຫຼາຍຂຶ້ນດ້ວຍວິທີ Scrum.

ການກັບຄືນສູ່ Agile Scrum ດ້ວຍການເລີ່ມຕົ້ນ ໃໝ່:

ໃນປີ 2015 ເມື່ອຂ້ອຍເຂົ້າຮ່ວມໃນການເລີ່ມຕົ້ນ, ຂ້ອຍຕົກຢູ່ໃນສະຖານະການທີ່ຂ້ອຍຕ້ອງ ນຳ ພາອົງກອນພັດທະນາ ໃໝ່ ໝົດ. ຂ້າພະເຈົ້າຮູ້ວ່ານີ້ແມ່ນເວລາທີ່ດີເລີດທີ່ຈະສົ່ງເຂົ້າ Agile Scrum ເຂົ້າໃນຂະບວນການເຮັດວຽກຂອງຂ້ອຍ.

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

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

ຕາຕະລາງຫຼຸດລົງຂອງ Sprint ທີ 3

ຄວາມໄວຂອງ Scrum: ການປັບປຸງການປະຕິບັດຢ່າງຕໍ່ເນື່ອງ

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

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

ຄວາມໄວ = ຈຸດຂອງເລື່ອງ / ເວລາຕົວຈິງ:

ຕົວຢ່າງ: ຖ້ານັກພັດທະນາ 10 ຄົນເຮັດວຽກຢູ່ໃນເລື່ອງເລົ່າໃນເວລາ 10 ມື້, ແປດຊົ່ວໂມງຕໍ່ມື້, ບ່ອນທີ່ເລື່ອງຕ່າງໆຖືກຈັດຢູ່ໃນລະດັບ 528 ຈຸດແລ້ວຄວາມໄວຈະເປັນ: 528 ຈຸດ / (10 ຄົນ x 10 ວັນ x 8 ຊົ່ວໂມງ) = 66%

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

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

ຄວາມຄືບ ໜ້າ Sprint-Scrum:

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

ວົງຈອນ Scrum sprints (ແຫຼ່ງຂໍ້ມູນ: ການພັດທະນາ Software Agile ກັບ Scrum ໂດຍ Ken Schwaber ແລະ Mike Beedle)

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

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

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

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

ພາບ ໜ້າ ຈໍ: ງອກຂອງກະດານ Scrum ທີ່ມີການເຄື່ອນໄຫວ (ແຫຼ່ງຂໍ້ມູນ: https://support.atlassian.com/jirasoftware-cloud/)

ກະດານໂຄງການປະເພດ Scrum ໃນ Jira ມີຄຸນລັກສະນະການຈັດການ backlog ແລະກະດານ Scrum ພ້ອມດ້ວຍບົດລາຍງານຕ່າງໆ. ເຄື່ອງມືການວັດແທກເຊັ່ນ: ບົດລາຍງານຂອງ Sprint, ຕາຕະລາງການເຜົາຜານ, ຕາຕະລາງ Concentration, ແລະບົດລາຍງານ Version ຊ່ວຍໃຫ້ພວກເຮົາຈັດການປະສິດທິພາບຂອງພວກເຮົາ.

Festa, ເວທີເຫດການທີ່ພັດທະນາຜ່ານ Scrum ທີ່ປະສົບຜົນ ສຳ ເລັດ:

ໃນເດືອນທັນວາຂອງປີ 2017, ຂ້າພະເຈົ້າໄດ້ເຂົ້າຮ່ວມທີມພັດທະນາຂອງເວທີການຂາຍເຫດການຂອງເກົາຫຼີໃຕ້ທີ່ຊື່ວ່າ Festa. ໃນເວລານັ້ນ, Festa ກຳ ລັງກະກຽມ ສຳ ລັບການເປີດຕົວຜະລິດຕະພັນ ທຳ ອິດຫຼັງຈາກທີ່ໄດ້ ສຳ ເລັດຫຼັກຖານຂອງແນວຄິດ (POC). ຜະລິດຕະພັນຕົວມັນເອງແມ່ນເວບໄຊທ໌ທີ່ສະດວກທີ່ຜູ້ໃຊ້ສາມາດຊື້ປີ້ ສຳ ລັບເຫດການໄດ້ໂດຍຜ່ານຂັ້ນຕອນການຈ່າຍເງິນງ່າຍ.

ເພາະວ່າມັນແມ່ນທີມ ໃໝ່, ພວກເຮົາ ຈຳ ເປັນຕ້ອງເວົ້າກ່ຽວກັບຂະບວນການເຮັດວຽກແລະຂະບວນການຂອງພວກເຮົາ. ຂ້ອຍໄດ້ແນະ ນຳ Scrum. ຫຼັງຈາກການສະ ເໜີ ດັ່ງກ່າວໄດ້ຮັບການຍອມຮັບ, ພວກເຮົາໄດ້ຕັດສິນໃຈຜະລິດຕະພັນທີ່ມີຜົນ ກຳ ໄລຂັ້ນຕ່ ຳ ທຳ ອິດ (MVP) ແລະຕັ້ງຄ່າ backlog.

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

ທີມງານ Festa ທີ່ຫາກໍ່ສ້າງ ໃໝ່ ສາມາດເຮັດ ສຳ ເລັດແລະປ່ອຍສິນຄ້າໄດ້ທັນເວລາບໍ?

ເວບໄຊທ໌ Festa (ທີ່ມາ: https://festa.io/)

ນັບຕັ້ງແຕ່ເສັ້ນຕາຍຂອງພວກເຮົາແມ່ນປະມານຫນຶ່ງເດືອນ, ພວກເຮົາໄດ້ຕັດສິນໃຈກ່ຽວກັບຮອບວຽນ Sprint 1 ອາທິດ. ໂດຍການຈັດການກັບ backlog ຢ່າງຊື່ສັດໃນຂະນະທີ່ເຮັດຮອບວຽນ Sprint, ພວກເຮົາສາມາດຄາດເດົາໄດ້ຢ່າງຖືກຕ້ອງເຖິງເວລາທີ່ຈະກະກຽມ ສຳ ລັບການເປີດຕົວຜະລິດຕະພັນຂອງພວກເຮົາ.

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

ບົດລາຍງານ Festa.io scrum ver1.0.0

ທີມງານ Festa ປະຕິບັດໄດ້ດີກັບ Scrum ແລະສາມາດປ່ອຍຜະລິດຕະພັນໄດ້ຢ່າງປະສົບຜົນ ສຳ ເລັດຕາມວັນທີຄາດ ໝາຍ. ຖ້າທ່ານເບິ່ງບົດລາຍງານສະບັບຂ້າງເທິງ, ທ່ານສາມາດເຫັນໄດ້ວ່າຄະແນນເລື່ອງຂອງພວກເຮົາເພີ່ມຂື້ນດ້ວຍຄ້ອຍທີ່ບໍ່ແນ່ນອນ. ນີ້ແມ່ນຫຼັກຖານສະແດງໃຫ້ເຫັນວ່າທີມງານໄດ້ພັດທະນາຜະລິດຕະພັນດັ່ງກ່າວໃຫ້ທັນເວລາດ້ວຍການປະຕິບັດຢ່າງສະ ໝໍ່າ ສະ ເໝີ.

Scrum ທ້າທາຍ ໃໝ່: QueryPie ພັດທະນາໃນ CHECKER

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

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

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

challenge ສິ່ງທ້າທາຍ Scrum ຂອງ CHEQUER ແມ່ນ QueryPie, ເຊິ່ງທ່ານສາມາດຮຽນຮູ້ເພີ່ມເຕີມໃນບົດຄວາມນີ້.

ຂ້ອຍມີປະສົບການຫຼາຍໃນການຈັດການ Scrums ຜ່ານ Jira, ສະນັ້ນຂ້ອຍສາມາດ ນຳ ທີມຂອງຂ້ອຍໃນການປະຕິບັດແຜນການຂອງຂ້ອຍ ສຳ ລັບ Sprint ທຳ ອິດຂອງພວກເຮົາ. ເປົ້າ ໝາຍ ຄວາມເຂັ້ມຂຸ້ນໃນເບື້ອງຕົ້ນຂອງພວກເຮົາຖືກຕັ້ງໃຫ້ເປັນ 64% ໂດຍອີງໃສ່ປະສົບການ (70% ແມ່ນເປົ້າ ໝາຍ ທີ່ ເໝາະ ສົມທີ່ສຸດໃນຈິດໃຈຂອງຂ້ອຍ). ຈຳ ນວນລູກເຮືອທັງ ໝົດ ແມ່ນ 4 ຄົນ, ແລະ Sprint ທຳ ອິດມີພຽງ 8 ມື້ເທົ່ານັ້ນ. ອີງຕາມປັດໃຈດັ່ງກ່າວເປົ້າ ໝາຍ ທີ່ຈະບັນລຸໄດ້ຄື: 4 ຄົນ x 8 ມື້ x 8 ຊົ່ວໂມງຕໍ່ມື້ x 64% ຄວາມເຂັ້ມຂົ້ນ = 164 ຈຸດເລົ່າເລື່ອງ.

ລາຍງານ QueryPie scrum ver1.0.0

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

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

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

ມັນເປັນພຽງດອກໄມ້ສັ້ນ 8 ວັນ, ແຕ່ລູກເຮືອ CHECKER ໄດ້ຮຽນຮູ້ວິທີການເຮັດວຽກຢ່າງເປັນລະບົບແລະມີປະສິດທິພາບ. ໂດຍປະສົບຜົນ ສຳ ເລັດໃນ Sprint ທຳ ອິດ, ພວກເຮົາໄດ້ຮັບຄວາມ ໝັ້ນ ໃຈແລະເພີ່ມທະວີຄວາມຜູກພັນລະຫວ່າງກັນແລະກັນ. ພວກເຮົາໄດ້ເຕີບໃຫຍ່ພ້ອມກັນຕະຫຼອດວິທີການ Scrum, ແລະພວກເຮົາຈະມີການຂະຫຍາຍຕົວຕື່ມອີກໂດຍຜ່ານ Sprints ທີ່ຈະຕາມມາ.

Agile Scrum Journey ຫໍ່ຂຶ້ນ:

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

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

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