Lompat ke konten Lompat ke sidebar Lompat ke footer

Definisi Scrum, Team, Event, Artefact

 

Definisi Scrum, Team, Event, Artefact

Scrum adalah kerangka kerja yang dirancang khusus untuk mengerjakan proyek pengembangan perangkat lunak. Framework ini memiliki proses dan tools yang dapat meningkatkan visibilitas progres serta keluwesan untuk beradaptasi terhadap perubahan yang banyak dibutuhkan pada suatu proyek pengembangan perangkat lunak.

Panduan Scrum bagian 4 ini akan menjelaskan Scrum Artifact untuk Anda. Scrum merupakan kerangka kerja untuk kolaborasi tim yang efektif dalam mengelola produk yang kompleks. Sudah banyak perusahaan yang menggunakan kerangka kerja ini sehingga delivery produk yang dikembangkan dapat dilakukan dengan cepat. 

Kerangka kerja Scrum ini akan dijalankan oleh Scrum Team berisi beberapa anggota dengan peran dan tugasnya masing-masing yaitu :

Tim Developers : merupakan anggota Scrum Team yang berperan untuk menciptakan Increment pada produk yang dikembangkan.

Product Owner : merupakan anggota Scrum Team yang bertanggung jawab untuk memastikan bahwa produk yang dihasilkan memiliki value yang maksimal.

Scrum Master : bertanggung jawab untuk mendukung penggunaan Scrum yang baik di dalam tim.

Selain itu, agar proses pengembangan produk dapat berjalan secara teratur, maka Scrum Events akan diadakan secara rutin. Scrum Event tersebut terdiri dari Sprint, Sprint Planning, Daily Scrum, Sprint Review, dan Sprint Retrospective. Masing-masing events ini perlu dilakukan agar transparansi dapat dilihat oleh semua pihak yang bertanggung jawab di dalamnya.

Apa Itu Scrum Artifact

Scrum Artifact merupakan bagian dari kerangka kerja Scrum untuk merepresentasikan pekerjaan atau nilai bisnis guna terciptanya transparansi informasi. Artefak yang dijabarkan di dalam kerangka kerja Scrum ini dirancang sedemikian rupa untuk memaksimalkan transparansi informasi utama sehingga setiap orang memiliki pemahaman yang sama mengenai artefak tersebut. 

Scrum terdiri dari 3 artifact, yaitu :

Product Backlog : untuk melihat progress untuk mencapai Product Goal

Sprint Backlog : untuk melihat progress dari Sprint Goal

Product Increment : untuk melihat progress yang dicapai menuju definisi “selesai”.

Masing-masing Scrum Artifact tersebut berisi komitmen atau tanggung jawab yang dapat menyediakan transparansi serta membantu tim agar bisa fokus pada kemajuan yang dapat diukur. Informasi yang ada di dalamnya juga dapat digunakan oleh Scrum Team dan para stakeholders untuk mendapatkan suatu pemahaman yang sama dari proses pengembangan produk. Jadi, ketika mereka ingin memeriksa bagaimana kemajuan proyek, mereka dapat melihatnya dari Scrum Artifact ini. Berikut penjelasan untuk masing-masing Scrum Artifact.

Penjelasan 3 Scrum Artifact

1. Product Backlog

Product Backlog adalah daftar berurutan mengenai fitur dan perbaikan apa saja yang dibutuhkan untuk meningkatkan suatu produk. Daftar ini menjadi satu-satunya sumber untuk mengetahui pekerjaan yang akan dilakukan oleh Tim Scrum selama Sprint. Sebagian orang menyebut Product Backlog sebagai “living artifact” atau artefak hidup. Disebut demikian, karena item Product Backlog akan terus diperbarui sesuai dengan kebutuhan stakeholder.

Item Product Backlog yang dapat dikerjakan oleh Scrum Team merupakan item yang dianggap paling penting dan sudah ditetapkan atau dipilih pada saat acara Sprint Planning berlangsung. Transparansi dari item-item Product Backlog biasanya akan diperoleh setelah Product Backlog Refinement. Product Backlog Refinement sendiri berarti tindakan menambahkan detail, estimasi, serta membuat urutan item dalam Product Backlog.

Selain itu, Product Backlog juga akan membantu anggota tim untuk memahami beberapa hal, seperti:

  • memastikan semua anggota Scrum Team memahami apa yang sedang dikerjakan
  • membantu membuat keputusan sesuai dengan prioritas kebutuhan bisnis
  • membantu membuat prediksi seberapa besar pengembangan yang dapat dilakukan dalam kurun waktu tertentu

Komitmen: Product Goal

Product Backlog berkaitan erat dengan Product Goal. Dari Product Goal, tim bisa mendapat gambaran bagaimana kondisi produk yang akan dikembangkan selama Sprint berjalan. Oleh karena itulah, ketika mengerjakan item Product Backlog, Product Goal menjadi target yang ingin dicapai.

Dalam kerangka kerja Scrum, sebuah produk menjadi “kendaraan” yang digunakan untuk menyampaikan value / nilai. Product Goal adalah tujuan jangka panjang. Jadi, Scrum Team harus dapat memenuhi (atau meninggalkan) satu tujuan sebelum mengambil tujuan berikutnya.

2. Sprint Backlog

Scrum Artifact selanjutnya adalah Sprint Backlog. Seperti yang sudah dijelaskan di panduan Scrum part 2, Sprint menjadi “jantung” dalam kerangka kerja Scrum. Untuk mengetahui fitur apa yang harus dikembangkan di setiap Sprint, maka tim dapat memeriksa melalui Sprint Backlog.

Sprint Backlog merupakan to do list untuk mendeskripsikan fungsi apa saja yang harus dikembangkan untuk sebuah produk selama Sprint tertentu. Sprint Backlog berisi Sprint Goal, item Product Backlog yang dipilih untuk dikerjakan dalam Sprint, serta plan yang dapat ditindaklanjuti untuk menghadirkan increment.

Scrum Artifact ini dibuat dan ditujukan untuk tim Developers. Mereka akan memilih item Product Backlog sesuai dengan prioritaskan, kemudian menambahkannya ke dalam Sprint Backlog, dan membaginya menjadi beberapa tugas. Tim Developer kemudian dapat mengerjakan tugas-tugas tersebut sesuai kebutuhan selama Sprint. 

Komitmen: Sprint Goal

Dari Scrum Artifact ini, Developer akan mendapat gambaran secara real time mengenai pekerjaan-pekerjaan yang harus diselesaikan selama Sprint untuk mencapai Sprint Goal. 

Sprint Goal tersebut sebelumnya sudah dibuat ketika Sprint Planning. Sprint Goal kemudian ditambahkan ke dalam Sprint Backlog untuk dijadikan sebagai target yang harus dicapai. Jika terjadi hal-hal diluar ekspektasi terjadi selama Sprint berjalan, maka scope pekerjaan dapat dinegosiasikan kembali dengan Product Owner. Namun perlu diingat perubahan scope pekerjaan yang terjadi tetap tidak boleh mengubah Sprint Goal yang sudah ditetapkan.

3. Product Increment

Product Increment merupakan Scrum Artifact yang penting. Scrum Guide mendeskripsikan Product Increment sebagai batu loncatan untuk mencapai Product Goal. Increment merupakan jumlah dari semua item Product Backlog yang diselesaikan selama Sprint berjalan. Setiap increment akan dikumpulkan dengan increment sebelumnya untuk diverifikasi secara menyeluruh dan dipastikan bahwa semua increment dapat berfungsi bersama. 

Tim Developers menjadi anggota Scrum Team yang bertugas untuk menciptakan aspek-aspek Increment (peningkatan) yang berguna di setiap Sprint. Perlu Anda ingat, Increment yang sudah diciptakan dapat dikatakan memiliki value ketika increment tersebut dapat digunakan. Terlepas apakah Product Owner memutuskan untuk merilisnya atau tidak, Increment yang dihasilka oleh tim Developer harus tetap usable atau dapat digunakan.  

Jumlah increments yang telah dicapai akan disajikan dalam Sprint Review. Meskipun demikian, increment juga memungkinkan untuk dapat dikirim langsung ke tangan stakeholders sebelum Sprint berakhir.

Komitmen: Definisi “Selesai”

Jika Product Backlog digunakan untuk mencapai Product Goal, Sprint Backlog untuk mencapai Sprint Goal, maka Increment ini digunakan oleh tim untuk mencapai definisi “selesai”.

Definisi “selesai” adalah keadaan dimana Increment memenuhi kualitas yang dibutuhkan oleh suatu produk. Ketika item yang ada di Product Backlog dikerjakan dan hasilnya sesuai dengan apa yang diharapkan, maka dapat dikatakan bahwa Increment telah diciptakan. Namun jika item Product Backlog tidak memenuhi Definisi “Selesai”, maka hasil pekerjaan tersebut tidak akan dirilis atau dipresentasikan dalam Sprint Review. 

Jadi, definisi “selesai” juga dapat dikatakan sebagai pemahaman bersama di dalam Scrum Team tentang apa yang diperlukan agar Increment dapat dirilis. Jika definisi “selesai” untuk sebuah Increment ditetapkan sebagai bagian dari standar perusahaan, maka semua Scrum Team harus mengikutinya. Namun jika tidak, maka Scrum Team harus membuat Definisi “selesai” sendiri sesuai dengan produk yang dikembangkan. 

Tim Developer juga harus dipastikan untuk bisa memenuhi definisi tersebut. Ketika ada beberapa anggota tim yang bekerja sama dalam sebuah produk, mereka harus bisa menetapkan dan mematuhi Definisi “selesai” yang sama. 

Definisi Scrum

Scrum pertama kali dikembangkan oleh Jeff Sutherland pada tahun 1993 dan memiliki tujuan untuk menjadi metodologi pengembangan yang mengikuti prinsip-prinsip Agile (Adi & Permana, 2015). Kerangka kerja ini juga diciptakan untuk menjadi rival dari waterfall yang dianggap kurang dinamis dan fleksibel untuk diaplikasikan.

Scrum adalah kerangka kerja responsif tambahan dari pengembangan perangkat lunak untuk proyek perangkat lunak dan mengelola produk atau pengembangan aplikasi yang berfokus pada strategi serta pengembangan produk holistik yang fleksibel, di mana tim pengembang bekerja sebagai unit untuk mencapai tujuan bersama seluruh pihak yang terlibat.

Scrum merupakan kerangka kerja yang membantu memecahkan masalah dalam pembuatan produk dengan sangat fleksibel melalui cara yang mengatasi masalah secara adaptif dengan hasil yang maksimal tanpa banyaknya proses produktivitas yang dijalankan.

Bagaimana caranya? Scrum memiliki tahapan yang mampu meningkatkan kemampuan adaptasi serta kolaborasi tim untuk mencapai tujuan bersama dengan lebih efektif dan efisien. Tahapan-tahapan tersebut terdiri dari project initiation, sprint planning, daily scrum, sprint review, dan sprint retrospective. Selain itu metode scrum juga memiliki building block berupa scrum team, scrum event, dan scrum artefact.

Berikut adalah penjelasan dari tahapan event, susunan tim, dan artifak yang dibutuhkan dalam kerangka kerja Scrum.

Scrum Team

Scrum memiliki komposisi tim yang berbeda dari metode pengembangan proyek perangkat lunak yang lain. Scrum team terdiri dari role yang disederhanakan dan tidak memiliki struktur matriks (tidak ada atasan dan bawahan). Semua anggota tim memiliki kedudukan setara, hanya tugasnya saja yang berbeda.

Di dalam Scrum, pembentukan tim dapat diatur sendiri (selforganizing). Terdapat tiga role dalam scrum team, yaitu product owner, scrum master, dan development team. Scrum team dirancang untuk memastikan setiap role dapat bekerja sesuai dengan tugas yang dibutuhkan sehingga membuat scrum berfungsi secara efisien untuk mencegah terjadinya masalah (Cole & Scotcher, 2015).

1. Product Owner

Product owner adalah seseorang yang bertanggung jawab dalam mengelola ruang lingkup, skala, dan arah proyek yang sedang dibangun. Product owner akan mempresentasikan kebutuhan organisasi dalam user story/product backlog yang diberikan kepada development team.

2. Scrum Master

Scrum master adalah kepala penyelenggara sebuah proyek yang bertugas untuk membagi pekerjaan kepada development team sesuai dengan user story/product backlog yang diinginkan oleh product owner. Selain itu, scrum master juga mengorganisir development team dalam memastikan scrum event berjalan sesuai dengan kebutuhan dan tepat waktu dengan tujuan untuk menghasilkan produk yang diharapkan oleh product owner.

3. Development Team

Development team terdiri dari satu atau lebih professional yang bekerja untuk menyelesaikan user story/product backlog yang diinginkan oleh product owner. Setiap anggota tim memiliki keterampilan invidu yang dibutuhkan juga untuk membantu anggota tim lainnya sehingga pekerjaan selesai dengan tepat waktu. Development team dapat terdiri dari Programmer, System analyst, Quality Control, dsb.

Scrum Event

Scrum event dilakukan untuk memeriksa dan menyesuaikan pekerjaan agar sesuai dengan struktur, rancangan, dan batasan waktu yang telah ditetapkan. Terdapat lima kegiatan dalam scrum event, yaitu project initiation, sprint planning, daily scrum, sprint review, dan sprint retrospective (Cole & Scotcher, 2015).

Project initiation dilaksanakan untuk memastikan kebutuhan user atau product owner benar-benar diketahui, difasilitasi, serta disesuaikan dengan kebutuhan teknis pengerjaan. Terkadang tahapan event ini juga disebut dengan grooming. Analoginya, kita berdandan sebaik mungkin sebelum akhirnya terjun ke lokasi syuting sebenarnya. Selanjutnya, beberapa terminologi dan scrum event lain yang terdapat pada Scrum akan dijelaskan pada pemaparan di bawah ini.

1. Sprint

Sprint adalah pekerjaan yang harus diselesaikan antara satu hingga empat minggu. Pelaksanaan sprint pertama akan dilakukan sesuai dengan rencana yang telah disepakati. Selama sprint berlangsung, tidak diperbolehkan adanya perubahan yang dapat mempengaruhi hasil dari sprint. Setelah sprint selesai, maka akan dilanjutkan ke sprint selanjutnya sesuai dengan perencanaan yang akan kembali dibuat pada event sprint planning.

Jika dibutuhkan perubahan atau terdapat pengerjaan yang kurang tepat, maka perubahan tersebut dapat diserap pada sprint selanjutnya. Inilah salah satu metrik yang menjadi kunci dalam adaptasi perubahan pada Scrum. Perubahan tidak hanya bisa diserap setelah setiap urutan pekerjaan selesai seperti pada waterfall, namun selalu dapat diserap pada setiap sprint yang akan selalu disusun kembali rencananya dalam sprint planning.

2. Sprint Planning

Sprint planning merupakan perencanaan yang dilakukan di setiap sprint baru dan dihadiri oleh seluruh scrum team. Perencanaan ini akan mendiskusikan terkait pembagian pekerjaan selama satu periode sprint sesuai dengan product backlog (fitur yang dibutuhkan) yang telah disepakati oleh scrum team. Sprint planning akan menghasilkan rencana pembagian kerja product backlog item sesuai dengan prioritas pada setiap periode sprint.

3. Daily Scrum

Daily scrum adalah pertemuan kecil yang dilakukan oleh development team dengan waktu tidak lebih dari 15 menit yang dilakukan selama sprint berlangsung. Tujuan dilakukannya meeting ini adalah untuk memastikan anggota tim selaras dengan sprint backlog yang telah ditentukan dalam perencanaan.

Daily scrum, daily meeting, atau disebut juga dengan daily standup ini mengharuskan setiap tim untuk menjelaskan poin-poin  sebagai berikut:

Apa yang telah dikerjakan?

Apa yang akan dikerjakan selanjutnya?

Terdapat masalah apa dalam pengerjaan proyek?

Tidak boleh ada pembahasan lain di luar tiga pertanyaan tersebut. Jika dibutuhkan pembahasan panjang dari beberapa poin tersebut, maka harus dibahas di luar Daily Scrum.

4. Sprint Review

Setelah sprint selesai, maka akan dilakukan sprint review. Sprint review bertujuan untuk memberikan kesempatan bagi development team dalam menunjukkan hasil kerja kepada product owner. Biasanya, dilakukan demonstrasi secara langsung yang dilengkapi laporan tertulis, maupun hanya berupa demo fitur yang telah diselesaikan.

Dari hasil demonstrasi, product owner menentukan pekerjaan dari product backlog sudah benar atau tidak. Selanjutnya product owner dapat memberikan feedback terhadap bagian yang kurang sesuai dengan kebutuhan. Setelah itu, bagian yang kurang dapat dimasukkan dalam sprint planning berikutnya.

5. Sprint Retrospective

Sprint retrospective atau sering disingkat menjadi retro dilakukan setelah sprint review selesai dan sebelum sprint planning. Sprint retrospective adalah tahap evaluasi yang dilakukan development team dalam kurangnya fitur yang belum selesai sehingga dapat meningkatkan performa tim pada sprint selanjutnya.

Scrum Artefact

Scrum artefact adalah barang atau item yang dibutuhkan oleh scrum team untuk melakukan pengerjaan proyek. Terdapat tiga artifak dalam scrum yakni product backlog, sprint backlog, dan increment (Cole & Scotcher, 2015).

1. Product Backlog

Artefact berupa Product Backlog adalah daftar fitur yang dibutuhkan untuk menghasilkan produk akhir. Product backlog tidak hanya berisi fitur saja, namun kebutuhan non-fungsional juga dapat dimasukkan ke dalam product backlog. Selain itu, product backlog juga dapat berubah dan berkembang selama sprint berlangsung.

2. Sprint Backlog

Sprint backlog merupakan daftar yang diprioritaskan dari fitur-fitur berdasarkan kesepakatan oleh scrum team. Sprint backlog biasanya akan menjadi pembahasan utama saat daily scrum berdasarkan tiga pertanyaan utamanya (what has been done, what to do next, problems).

3. Increment

Increment merupakan hasil sementara berupa bagian dari produk yang telah dikerjakan dari product backlog item pada setiap sprint. Increment akan selalu berkembang dari setiap hasil sprint yang telah dikerjakan sehingga produk akan lebih matang atau progres semakin meningkat dari sebelumnya.

User Story

Setelah kebutuhan sistem dikumpulkan dan dianalisis, maka kebutuhan sistem harus dideskripsikan. Salah satu cara mendeskripsikannya yaitu menggunakan user story yaitu dokumentasi dari kebutuhan sistem dalam agile development.

Adapun struktur penulisan user story yaitu:

“As a [aktor]”, “I want to [Saya ingin ..]”, “So that I can [Sehingga dapat …]”.

Contohnya:

“Sebagai Administrator, “Saya ingin dapat mengklik tombol edit di sebelah kanan tabel informasi”, “Sehingga saya dapat mengubah informasi tersebut melalui pop-up form yang muncul ketika tombol edit diklik”

Struktur ini dapat diartikan sebagai deskripsi dari satu fitur atau lebih dalam pengembangan sistem (Mantik, 2019).

Selain itu juga untuk dapat melakukan pembagian dalam pengerjaan fitur-fitur yang telah dijabarkan pada user story maka perlu menambahkan story points. Salah satu cara untuk menentukan story points adalah menggunakan bilangan Fibonacci.

Penentuan story point dilakukan dari angka 1 hingga 100, dimulai dari deskripsi task/fitur tersebut kecil hingga besar (Visual Paradigm, 2021). Misalnya, kita dapat menggunakan story point dimulai dari angka 1 hingga 3. Angka 1 dideskripsikan sebagai pengerjaan task kecil, angka 2 dideskripsikan sebagai pengerjaan task sedang, dan angka 3 dideskripsikan sebagai pengerjaan task besar.

Penentuan story poin melalui T-shirt sizing juga dapat digunakan. Misalnya S untuk task mudah, M untuk task sedang, XL untuk task sulit.

Kelebihan Scrum

Rasanya sudah tidak usah dibahas lagi mengenai berbagai kelebihan dari Scrum. Kelebihan scrum meliputi:

  1. pengerjaan proyek yang lebih efisien dan efektif karena meningkatnya visibilitas progres dari pengerjaan proyek,
  2. alat evaluasi yang kuat untuk membantu membuat keputusan selanjutnya dalam pengerjaan proyek,
  3. tahapan yang cukup sederhana dan mendukung seluruh kebutuhan stakeholder proyek (product owner & development team),
  4. hingga meninggalkan jejak (artifak) yang membantu pengerjaan proyek yang sistematis namun tetap dinamis sehingga mampu meresap perubahan dengan cepat.

Apa yang harus lebih banyak dibahas pada metode scrum justru adalah kelemahannya. Hal ini karena kini,  scrum seakan menjadi satu-satunya kerangka kerja yang viabel tanpa kekurangan apa pun. Oleh karena itu, berikut beberapa uraian mengenai kelemahan atau kekurangan scrum.

Kekurangan Scrum

Dari pemaparan mengenai Scrum di atas, rasanya dapat kita sadari bahwa kerangka kerja ini menggunakan banyak sekali proses dan alat evaluasi yang terlibat. Padahal, metode ini mengibarkan prinsip Agile. Hal itu sangat kontradiktif dari salah satu nilai utama dari Agile, yakni Interaksi dan Individu lebih penting daripada proses dan alat.

Agile seharusnya membuat proses pengembangan perangkat lunak menjadi lebih memanusia baik secara individu, maupun secara sosial. Sayangnya, kerangka kerja scrum tampak kurang menyokongnya dengan baik. Mungkin beberapa tools dan proses yang digunakan dirancang untuk menyokong interaksi, misalnya daily scrum meeting. Namun karena dilakukan setiap hari, ada kemungkinan event ini akan membuat tim jenuh. Belum lagi aturan mainnya yang cukup ketat juga mengurangi keindividuan setiap tim.

Kelemahan terbesar dari Scrum adalah burnout pada anggota tim. Sprint memang tidak harus selalu terpenuhi, namun ketika metrik seperti itu ditetapkan, time box sprint akan terus menempel di kepala pelakunya. Saat setiap sprint gagal dipenuhi (sering terjadi dalam Scrum) mental tim akan turun karena timbulnya rasa bersalah. Hal itu akan membuat ia melakukan segala upaya untuk memenuhinya, sehingga menyebabkan kelelahan. Efek jangka panjangnya adalah meningkatnya tingkat stres pekerjaan.

Tentunya hal tersebut dapat menjadi kelebihan dari Scrum. Bahkan, mungkin hal inilah yang selama ini membuat Scrum berhasil. Dalam keadaan tertekan, tingkat produktivitas tim akan menjadi lebih tinggi. Namun alangkah baiknya jika tekanan itu tetap terkendali dan tidak berlebihan. Seperti video game, jika permainan terlalu mudah maka pemain akan mudah bosan, namun ketika permainan terlalu sulit maka pemain juga akan frustrasi dan berhenti memainkannya.

Banyak yang menganggap bahwa kelemahan ini hanya terjadi ketika Scrum tidak diaplikasikan dengan tepat. Namun, kenyataannya ketidaktepatan pengaplikasian Scrum ini sangatlah sering terjadi. Jika memang Scrum sesempurna itu, seharusnya kerangka kerja ini juga mudah digunakan sehingga tidak sering terjadi kesalahan dalam pengaplikasiannya bukan? Intinya, di dunia ini tidak ada yang sempurna, termasuk Scrum.

Solusi Kekurangan Scrum

Sebetulnya hal ini juga tidak membuat Scrum menjadi kerangka kerja yang buruk. Hanya saja kita harus mewaspadai dampak buruk atau kelemahan dari Scrum. Dalam sebagian kasus, misalnya dalam proyek skala kecil, kemungkinan lebih baik digunakan metode lain yang lebih ringan seperti hanya menggunakan Kanban Board saja (seperti Trello).

Selain itu, modifikasi ringan terhadap Scrum yang disesuaikan dengan keadaan tim akan membuat metode ini lebih efektif serta mengurangi kelemahannya. Misalnya, jika daily meeting tidak bekerja sebagai mana mestinya, maka hapuskan saja, atau kurangi intensitasnya. Cara lainnya adalah dengan membuat suasana meeting lebih kasual. Intinya, cari cara lain untuk memicu interaksi dengan lebih baik dan sesuai dengan keadaan tim.

Perlu dilakukan penelitian lebih lanjut mengenai hal ini. Sayangnya, Scrum saat ini telah menjadi standar industri pengembangan aplikasi. Sehingga banyak pihak yang merasa tidak profesional atau tidak kompeten jika tidak mampu menerapkannya. Padahal keadaan setiap perusahaan dan varian proyek yang dikerjakannya amatlah berbeda.

Belum lagi proses dan tools yang ada di dalamnya dianggap sangat superior dan tidak mungkin salah, sehingga upaya yang selalu dilakukan adalah lagi-lagi memberikan pengarahan dan pelatihan untuk melaksanakannya dengan tepat. Berbagai terminologi Scrum harus dihapalkan, dicermati, dipahami, serta dilakukan dengan tepat. Berbagai hal kompleks tersebut justru hanya akan memberikan beban tambahan dan berpotensi menimbulkan hambatan yang tidak diperlukan.

Dalam bidang pendidikan, sudah sangat lazim dilakukan penelitian yang mencoba untuk melihat tingkat efektivitas suatu metode pembelajaran atau pengajaran. Penelitian mengenai pengembangan atau modifikasi terhadap suatu metode pembelajaran juga menjadi salah satu primadonanya. Hasilnya, pendidik dapat menerapkan metode pembelajaran yang lebih sesuai untuk kebutuhan peserta didik.

Oleh karena itu, tidak ada salahnya jika kita juga mencoba melakukannya pada metode Scrum. Hal tersebut tentunya ditujukan untuk membuat Scrum menjadi lebih aplikatif pada kondisi dan kebutuhan dari masing-masing perusahaan serta tim pengembang perangkat lunak.

Referensi

Adi, P., & Permana, G. (2015). Scrum Method Implementation in a Software Development Project Management. (IJACSA) International Journal of Advanced Computer Science And Applications, 6(9), 198–204.

Cole, R., & Scotcher, E. (2015). Brilliant Agile Project Management. Harlow: Pearson.

Mantik, H. (2019). Mengintip dasar pengembangan sistem informasi dengan metode Agile. Why Agile Rocks? Jurnal Sistem Informasi, 76-82.

Matharu, G. S., Mishra, A., Singh, H., & Upadhyay, P. (2015). Empirical Study of Agile Software Development Methodologies: A Comparative Analysis. ACM SIGSOFT Software Engineering Notes, 40(1), 1–6.

The Standish Group International, I. (2015). CHAOS REPORT 2015. Retrieved from https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf

Visual Paradigm. (2021, Juli 17). What is Planning Poker in Agile? Retrieved from Visual Paradgim: https://www.visual-paradigm.com/scrum/what-is-agileplanning-poker/

Posting Komentar untuk "Definisi Scrum, Team, Event, Artefact"