Q & A Vascomm Webinar : Mengenal Arsitektur Microservice

Q & A Vascomm Webinar : Mengenal Arsitektur Microservice

Diantara berbagai pola dan gaya arsitektur perangkat lunak (software architecture), microservice termasuk dalam kategori pola yang paling banyak dipakai oleh software developer. Microservice banyak diaplikasikan pada organisasi dan bisnis yang perlu kelincahan dan skalabilitas lebih besar. 

Di microservice, setiap fitur dibangun terpisah dan independen dari fitur lainnya. Fitur yang terpisah memungkinkan untuk dikembangkan secara individu tanpa berkaitan dengan seluruh codebase. Komunikasi antar service menggunakan HTTP rest atau message bus.

Pola microservice sekilas terlihat lebih kompleks. Selain itu, developer juga perlu mengeluarkan usaha lebih besar untuk pengembangan software. Berbeda dengan monolith yang tiap fiturnya berkaitan erat dan saling mempengaruhi. Sehingga itu membuatnya lebih beresiko, proses update lebih rumit, integrasi lebih susah, dan peluang munculnya bugs lebih banyak.  

Mengenai mengapa dan bagaimana implementasi microservice untuk kebutuhan bisnis, semua disampaikan pada sesi Vascomm Webinar bertema ‘Trend IT di dunia kerja’. Di akhir sesi webinar, ada beberapa pertanyaan yang diajukan oleh peserta, seperti terangkum di bawah ini: 

[Q1] Untuk service yang menggunakan lumen, mana yang performanya lebih powerfull antara laravel dengan nodejs?

Karena laravel/lumen dibangun menggunakan PHP yang mana merupakan synchronous language, maka NodeJS lebih diunggulkan. Alasannya karena NodeJS berbasis Javascript dengan konsep asynchronous, sehingga membuat performa eksekusi code jadi lebih cepat. Selain itu, NodeJS juga memiliki fokus yang bisa menghandle multithreading dan parallel request.

[Q2] Mending menerapkan microservice di awal pengembangan, atau tunggu sampai users sudah banyak?

Tergantung dari tujuan pengembangan dan kebutuhan aplikasi. Jika memang ada niat menerapkan microservice, akan lebih baik kalau dilakukan di awal. Alasannya karena menghapus kebutuhan modularisasi / refactor di kemudian hari. 

Nah, apa itu refactoring ? Menurut Martin Fowler, dia adalah proses mengganti software system tanpa mengubah behaviour dari kode tersebut, akan tetapi membuat struktur di dalamnya jadi lebih baik.

[Q3] Sampai berapa batasan microservice agar web kita berjalan dengan optimal? Misal kita pecah jadi 100, apakah masih worth it? Apa ada alternatif lain jika overload?

Jawabnya relatif, bergantung dengan resource dan kemampuan dari server. Semua disesuaikan kebutuhan saja. Jika terjadi overload, ya nambah resource boss hehe

Kedua, depend on traffic. Jika dirasa modul kita mengalami penurunan performa karena disebabkan traffic yang sangat tinggi , maka kita harus segera melakukan scale up sekali lagi. Tidak bagus juga kalau kita langsung memberikan resource yang sangat besar akan tetapi trafficnya kecil. Jadinya tidak efektif.

Optimalnya bukan tergantung dari banyaknya microservice, tapi jumlah aktifitas atau lalu lintas request responnya serta cara kita mengatasi massive request bersamaan. Bila overload, Kita bisa enhance di dalam code dengan melakukan optimasi task seperti multithread, chunking proses, dan sebagainya. Selain itu, enhance juga perlu dilakukan dari sisi infrastruktur, caranya dengan menambah jumlah resource untuk memaksimalkan kinerja proses.

[Q4] Saran untuk memprioritaskan kebutuhan infrastruktur atau kebutuhan bisnis?

Keduanya sama-sama penting. Poin utamanya itu yang penting bisnis jalan dan infrastruktur bisa support berlangsungnya bisnis

[Q5] Microservices memungkinkan berbagai macam database pada service berbeda. Bagaimana jika dalam pembuatan service butuh data dari service lain? Bagaimana cara mengambilnya?

Lewat API, komunikasi antar services

[Q6] Apakah kemacetan jaringan berpengaruh pada arsitektur sistem layanan microservice? Bagaimana menghindarinya?

Jelas sih. Solusinya simple, bila arsitektur jaringan diatur dengan baik dan gak terjadi bottleneck, maka layanan aman dari gangguan. Apa itu bottleneck? Dia adalah macetnya proses aliran atau transmisi data sebab alasan tertentu. Biasanya karena perbedaan antara kecepatan kerja suatu komponen dengan kecepatan bus-nya.

Untuk mengatasinya kita bisa pakai load balancing. Yaitu teknik mendistribusikan beban trafik pada dua atau lebih jalur koneksi secara seimbang. Gunanya agar trafik berjalan optimal, memaksimalkan throughput, memperkecil waktu tanggap dan menghindari overload pada salah satu jalur koneksi.

Tim outsource IT terus berkembang, source code aman pembajakan?

Tim outsource IT Terus Berkembang, Source Code Aman Pembajakan?

Saat ini tim IT Vascomm ada dimana-mana, apakah ada kekhawatiran dengan isu pembajakan atau pencurian source code?

Kira-kira seperti itu pertanyaan yang muncul dalam diskusi beberapa waktu lalu. Artikel ini akan menjabarkan beberapa langkah untuk memitigasi pembajakan atau pencurian source code dari para programmer.

Bisa dibilang, source code termasuk aset penting software house alias vendor IT solution. Perusahaan perlu mengamankan source code dari pencurian atau pembajakan untuk menjaga keamanan intelektual dan bisnis software Anda. Berikut beberapa langkah yang bisa Anda implementasikan untuk memitigasi risiko pencurian atau pembajakan source code. 

Langkah pertama, produk/layanan yang dikembangkan harus terintegrasi dengan internet alias berbasis cloud atau SaaS. Biasanya, software yang mudah dibajak itu jika semua fiturnya hanya tersedia offline, seperti game single player.  

Langkah kedua, buat perjanjian kerahasiaan, Non-Disclosure Agreement (NDA). Kesepakatan ini juga sebagai bentuk komitmen programmer untuk menjaga kerahasiaan source code yang sudah dibuat dan tidak menyalahgunakannya demi kepentingan pribadi.

Langkah ketiga, penggunaan sistem pengendalian versi seperti Git. Dia akan membantu software house untuk memantau dan mengendalikan perubahan yang sudah dibuat pada source code. Sistem tadi juga bisa melacak orang yang membuat perubahan pada source code dan memudahkan proses rollback jika diperlukan. 

Continue Reading

Sedang Mencari Tenaga Outsource Pengembang Aplikasi? Lakukan Uji Kelayakan ini Dulu.

Sedang Mencari Tenaga Outsource Pengembang Aplikasi? Lakukan Uji Kelayakan ini Dulu!

Mayoritas sepakat bahwa digitalisasi sudah menjadi kebutuhan wajib setiap individu pun bisnis. Faktanya, efisiensi seringkali cukup sulit dicapai ketika harus melakukan rekrutmen untuk full-time software engineer. Oleh karena itu, outsource akhirnya menjadi pilihan.

Jika perusahaan anda mengambil langkah ini, maka 1 tujuan yang harus dicapai, mencari penyedia outsource pengembang aplikasi terbaik dan tidak rugi karena mereka. Banyak perusahaan yang kini melakukan outsource terhadap tim pengembang aplikasi mereka karena 3 hal umum berikut :

  • Produk akan dikembangkan oleh tim berpengalaman yang sangat memahami teknologi modern
  • Perusahaan akan dapat fokus ke “core” bisnis
  • Anda akan menghemat waktu dan uang (tentunya tidak untuk jangka pendek, tapi untuk jangka panjang terkait quality, efisiensi akan sangat terasa)

Mau tidak mau, anda perlu menyaring sekian banyak penyedia software outsource yang sejalan dengan kebutuhan internal bisnis, dan kualitasnya sesuai ekspektasi anda. Meskipun tugas tadi tidak mudah, anda tetap harus melakukan riset secara dalam. Tapi setidaknya beberapa pengetahuan ini bisa mempermudah anda dalam memilih :

  1. Expertise Harus Menjadi Poin Utama

Tim terpilih harus punya keahlian mendalam terkait hal yang perusahaan anda butuhkan. Alasannya simple, kita jauh lebih mudah bekerja dengan orang yang memang sudah expert di bidangnya. Untuk memastikannya, kita bisa melihat dari sisi teknologi, code, dan pengetahuan menyeluruh soal apa yang menjadi concern bisnis. Terkait expertise, berikut 5 hal yang bisa anda pertimbangkan:

  • Website, bagaimana penampilannya, dan apakah mudah digunakan
  • Portofolio, seberapa berkualitas kliennya?
  • Technology, sejauh mana pengembangan teknologi yang dapat diberikan
  • Team, apakah tim mereka menyediakan full services meliputi design, development, testing, project management, dan support.
  • Blog, bagaimana advancement mereka dalam pengembangan aplikasi
  1. Future Proof as Possible

Penyedia layanan software tidak berkualitas akan memberikan saran pengembangan yang tidak optimal untuk terus mengais uang dari perusahaan anda. Tentunya hal ini harus disadari dan sebisa mungkin dihindari. Pastikan aplikasi telah teruji se future-proof mungkin demi meningkatkan efisiensi perusahaan anda.

  1. Cari Tahu Cara Kerja Mereka

Banyak penyedia layanan software yang mensiasati pengerjaan untuk mengambil keuntungan lebih banyak. Maka dari itu, anda perlu tahu terlebih dahulu seperti apa proses bekerja mereka. Tim yang baik akan melakukan pekerjaannya seefisien mungkin dengan waktu yang tidak terlalu lama. Pastikan juga ada transparansi dalam proses bekerjanya seperti penyediaan dashboard development, penyediaan tools project management, dan hal lainnya.

  1. Pastikan Background Leadernya Baik

Memilih penyedia layanan outsource dengan leader yang menginspirasi dan konsekuen terhadap segala pernyataannya akan membawa perusahaan anda menuju sukses. Ketika timnya melenceng, sang leader nantinya yang akan mengarahkan sehingga tim outsource selalu berada di peak performance mereka dalam mengembangkan aplikasi.

  1. Tes Pola Komunikasi dengan Customer

Salah satu penyebab frustasi dikarenakan pola komunikasi yang tidak terjalin baik. Seperti kurang tanggap terhadap pengaduan konsumen, penyelesaian bug hingga berminggu, dan masih banyak hal lain. Persoalan tadi nantinya akan menghambat proses development yang tentunya anda tidak mau ini terjadi, bukan.

Balik lagi, untuk mengevaluasi dan memilih tim outsource, anda punya kewenangan untuk menentukan kriteria sendiri. Namun, dengan 5 uji kelayakan di atas, harapannya anda mudah menentukan parameter perusahaan dalam memilih tim outsource pengembang aplikasi terbaik.

Sebagai penyedia layanan outsource pengembang aplikasi, Vascomm sangat menjaga hal esensial guna mengoptimalkan kualitas aplikasi yang kami kembangkan dengan harga terbaik. Tidak berhenti di pengembangan aplikasi, kami juga berusaha sekuat tenaga untuk menciptakan “bright solution” sesuai dengan kebutuhan bisnis anda.

Baru-baru ini, Vascomm mengenalkan layanan baru yang fokus pada penyediaan talenta digital. Ada 3 pilihan yang bisa diambil oleh perusahaan, yaitu sistem sharing talent, talent outsource, dan talent squad. Apa dan bagaimana skema dari masing-masing tadi, artikel selengkapnya bisa didapkan dari laman TalentGo

5 Alasan Mengapa Perusahaan Melakukan Software Development Outsourcing

5 Alasan Mengapa Perusahaan Melakukan Software Development Outsourcing

Meskipun teknologi bukan satu satunya faktor, tapi salah satu langkah inovasi terbaik seharusnya dilakukan dengan pengembangan aplikasi atau software. Nyatanya, pengembangan software seringkali jadi kebutuhan kritikal yang harus dipertimbangkan perusahaan untuk menerobos batas digitalisasi. Salah satu cara untuk memenuhi kebutuhan tersebut yaitu dengan menyerahkan pengembangan aplikasi kepada pihak outsource ataupun layanan konsultan.   

Mengutip data dari Statista, di tahun 2019, nilai kontrak ITO (Information Technology Outsourcing) di seluruh penjuru dunia telah mencapai 66.5$ Billion. Hal ini menandakan bahwa banyak perusahaan yang masih menjadikan Software Development Outsourcing (SDO) sebagai pilihan. Lantas mengapa hal ini terjadi ? Berikut 5 alasannya :

Meningkatkan Fleksibilitas

Staff perusahaan tidak perlu mengesampingkan tugas harianya untuk mengembangkan aplikasi. Ketika perusahaan Anda telah melakukan identifikasi kebutuhan, langkah selanjutnya tinggal mengajak tim outsource profesional. Misal, jika internal perusahaan sudah ada tim UX yang qualified, maka anda hanya perlu melakukan outsource tim software engineer untuk menjembatani gap. Jadi, perusahaan akan punya waktu lebih banyak untuk fokus ke hal lain yang jadi spesialis.

SDO memberi perusahaan talent berbakat secara instan 

Bayangkan seberapa besar effort yang diperlukan perusahaan untuk meng hire tim IT. Persoalan tadi bisa teratasi dengan bantuan software engineer profesional yang ditawarkan oleh penyedia layanan outsource. Tim software engineer outsource ini diharapkan akan terintegrasi dengan workflow perusahaan.

Meningkatkan Efisiensi 

SDO dapat mengakselerasi delivery project ke market tanpa mengesampingkan kualitas software. Tim Outsource berkualitas akan menggunakan waktunya untuk menggaris bawahi guideline yang perusahaan berikan dan mengimplementasikan workflow dengan pemanfaatan tools manajemen proyek. Ditambah, tim outsource yang baik mestinya juga menerapkan design thinking dalam pengembangan aplikasinya. ini akan mempertajam value dari aplikasi itu sendiri.

Mitigasi Risiko 

Software outsourcing membantu menyeimbangkan risiko yang ada pada project. Baik developer dan client, keduanya akan memangku tanggung jawab yang sama untuk memastikan software berjalan dengan baik. Tim outsource akan membantu perusahaan anda untuk membuat rencana dengan risiko seminimal mungkin dengan pengalaman yang dimiliki.

Meningkatkan Keamanan 

Berdasarkan data yang diambil dari Norton, data breach atau data exposing menyebabkan perusahaan rata-rata mengalami kerugian sebanyak 3.86$ billion di seluruh dunia. Bekerja dengan tim outsource IT berpengalaman akan meningkatkan keamanan dan menyelamatkan reputasi brand perusahaan anda. Dengan pengalamannya, tim outsource IT akan mempertimbangkan keamanan dari end user hingga ke database untuk menjamin informasi sensitif tersimpan secara aman dengan risiko ancaman seminimal mungkin.

Jadi, apakah anda sudah berencana meng hire tim outsource untuk proyek pengembangan software berikutnya? Atau mungkin anda punya pemikiran lain soal software development outsourcing?

What, why and how to be agile?

What, Why and How to be Agile?

Menyambung artikel sebelumnya tentang salah kaprah soal agile, artikel kali ini akan menjabarkan apa, mengapa, dan bagaimana menjadi agile baik untuk skala individu juga lingkup organisasi. Belakangan kata agile punya prestise tinggi di mata masyarakat, terutama bagi mereka yang berkecimpung di industri teknologi khususnya software developer. 

Sayangnya, sebagian masih salah memahami sekaligus menerapkan nilai dan prinsip agile ke dalam sistem kerja organisasi atau perusahaan. Akibatnya, produk/layanan yang dihasilkan tidak berkualitas dan belum cukup memberikan manfaat bagi masyarakat. Lantas, apa sebenarnya definisi agile? Dan mengapa individu atau perusahaan perlu mengadopsi nilai ini?

Agile sebenarnya revolusi ‘pola pikir’ dan ‘perilaku’. Agile berkembang dengan cakupan luas menjadi sekumpulan metode, prinsip, dan kerangka kerja manajerial mulai dari tim hingga manajemen inovasi. Lean Startup, Scrum, Holacracy, Design Thinking, keempatnya menerapkan konsep agile dalam kerangka kerjanya.

Perusahaan teknologi dunia mengadopsi agile dalam sistem manajemen. Sebut saja Google, raksasa teknologi yang mengolah ide design thinking hingga menciptakan bingkai kerja design sprint. Hasilnya, mereka mampu menemukan desain software yang product-market-fit. 

Contoh lain, agile bicara tentang manajemen operasional internal. Medium.com dan Zappos adalah perusahaan berbasis teknologi yang mengadopsi agile dalam merestrukturisasi organisasi yang lebih cair lewat holacracy. Keduanya tumbuh menjadi organisasi besar yang tetap jauh dari birokrasi, politik, dan gerakan lamban. 

Melansir dari laman agilecampus.org (6/4), penulis menceritakan pengalamannya saat boarding di Changi Airport, Singapura. Penulis terkesan dengan bagaimana Changi terus mempertahankan kualitas lewat optimasi kepuasan pelanggan. Bukan sekedar melakukan data survey, Changi juga mengimbanginya dengan perbaikan nyata yang terus menerus mereka lakukan.

Pihak bandara menyadari kapabilitas dan potensi mereka (self-aware), sehingga bisa terus menemukan ide perbaikan yang akan diterapkan (proactive). Efek penerapan perbaikan pada persepsi pengunjung terus dipantau (empathetic), dan jadi data untuk pengambilan keputusan di iterasi berikutnya kebiasaan bagus dilanjutkan, sementara yang jelek akan segera diganti.

How to be Agile?

Jawabannya mulailah dari hal mendasar, yaitu mindset. Pola pikir menentukan value sekaligus prinsip, lalu dia menggerakkan perilaku. Perilaku yang dilakukan berulang dan kerja keras akan membantu kita menemukan passion. INGAT! mengganti bungkus tanpa mengubah isinya itu BUKAN agile. Move, don’t idle, Be Agile, Just do your best, as best as you can, and the passion will follow you, kata Yusuf Kurniawan.

Melihat perkembangan dunia yang semakin modern dan canggih, kita perlu merevolusi cara berpikir dan kebiasaan agile. Dalam konteks organisasi, terutama abad 21 ini, kita dituntut untuk lebih kreatif dan inovatif. Dan itu didapat dari kecakapan kolaborasi, berpikir kritis, dan komunikasi. 3 soft skill itulah yang diperlukan industri untuk bisa agile dan sustainable di era disruptif ini.

Salah kaprah soal Agile

Salah Kaprah soal Agile

Seiring pertumbuhan bisnis baru di sektor teknologi digital, konsep agile development semakin ramai diperbincangkan. Istilah ini dinilai punya prestise tinggi. Kata agile dibuat sebagai label yang memperlihatkan kualitas individu, organisasi, dan bisnis atau perusahaan. Metodologi agile pun tidak hanya dipakai untuk pengembangan software, namun juga menjadi kerangka atau sistem manajemen sebuah organisasi.

Sayang, kenyataannya sebagian orang masih setengah hati memahami bahkan menerapkan konsep agile. Akibatnya, produk atau layanan kurang berkualitas, dan konsumen pun tidak banyak mendapat manfaat dari produk atau layanan yang diberikan. Joshua Partogi, editor manajemen modern mencontohkan beberapa praktik penerapan agile yang masih salah kaprah. Misalnya anggapan yang menyatakan bahwa sistem bisnisnya agile, tapi faktanya request perubahan terjadi hampir setiap hari. 

Agile seakan dipakai sepihak oleh klien untuk menuruti berbagai requirement yang berubah-ubah, namun nilai proyeknya harus tetap sama. Jika kita kroscek ulang, pemahaman keliru soal agile disini tentu merugikan software developer. Mereka akan mengerjakan tiap permintaan perubahan hingga lembur tidak karuan. Sementara di sisi lain, proyek yang dikerjakannya tidak punya visi jelas dan nilai kontraknya tetap.

Mengutip dari Dave Snowden, Joshua mengelompokkan masalah menjadi 5 tipe. Masing-masing diantaranya simple, complicated, complex, chaotic dan disordered. Jadi, menurutnya proyek yang cenderung berubah-ubah tanpa kejelasan visi mengenai produk dari sisi bisnis itu bukanlah disebut agile, melainkan chaos. Ya chaos diartikan sebagai permasalahan yang tidak punya kepastian. Untuk itu, mulailah berhenti menyebut proyek chaos sebagai agile. Karena itu hanya merugikan tim dan finansial perusahaan. 

Contoh salah kaprah lain soal agile, perusahaan mengklaim sistem kerjanya agile, tapi faktanya pimpinan perusahaan tertutup dengan ide bottom-up collective intelligence. Ini mirip pepatah bos selalu benar. Bisa dibayangkan budaya kerja seperti apa yang tercipta dengan tipe pemimpin yang otoriter dan tidak mau memberdayakan tim?

Jika semua pekerjaan menggunakan model top-down alias selalu didikte oleh atasan, bisa dipastikan tidak ada revolusi berpikir yang diadopsi dari konsep agile. Seperti kita tahu bahwa agile menekankan kolaborasi dan collective intelligence, dan ini bertolak belakang dengan model kerja tradisional yang cenderung political power driven.  Continue Reading

Menguak Kesalahpahaman Populer soal SCRUM part 3

Menguak Kesalahpahaman Populer soal SCRUM Part 3 (Final)

Kita kembali lagi untuk mengungkap dan membongkar kesalahpahaman seputar scrum. Artikel ini masih akan membahas sejumlah kesalahpahaman yang sering muncul dalam praktik scrum. Mari kita lanjut membacanya!

Poin 1: Release increment tidak harus menunggu akhir sprint

Dalam scrum, pengembangan increment seharusnya berjalan sepanjang waktu, dan increment dapat dirilis kapan saja tim dan product owner menganggapnya sudah siap untuk dikirim ke pelanggan atau pengguna akhir. Hal ini memungkinkan nilai tambah untuk diberikan lebih cepat.

Poin 2: Sprint khusus untuk persiapan, release, dan lainnya tidak ada

Sprint dalam scrum adalah periode waktu pengembangan produk yang potensial untuk pengiriman. Tidak ada sprint khusus untuk tugas-tugas tertentu di luar lingkup pengembangan produk. Tugas-tugas seperti persiapan atau release seharusnya terintegrasi dalam sprint biasa.

Poin 3: Komunikasi dengan stakeholder bukan hanya kewenangan product owner

Meski product owner memainkan peran penting dalam menjalin komunikasi dengan pemangku kepentingan, semua anggota tim scrum seharusnya dapat berinteraksi dengan pemangku kepentingan. Komunikasi terbuka dan berkelanjutan dengan pemangku kepentingan membantu memahami kebutuhan dan memastikan produk berkembang sesuai dengan harapan.

Poin 4: Product backlog item bisa diubah selama sprint berlangsung

Ada kesalahpahaman bahwa Product Backlog Item (PBI) tidak boleh diubah ketika sprint berlangsung. Namun, sesuai dengan prinsip adaptasi terhadap perubahan, PBI dapat diubah selama sprint jika diperlukan. Namun, perubahan semacam itu harus dikelola dengan hati-hati dan mempertimbangkan dampaknya pada sprint goal. Pengubahan PBI harus disetujui oleh product owner dan tim pengembangan.

Poin 5: Durasi sprint tidak terkait langsung dengan jumlah product backlog Item yang dikerjakan

Durasi sprint adalah keputusan tim, dan itu biasanya ditentukan secara konsisten, misalnya, 2, 3, atau 4 minggu. Jumlah PBI yang dikerjakan selama sprint harus sesuai dengan kapasitas tim, bukan ditentukan oleh durasi sprint. Tujuan utama adalah memberikan nilai yang konsisten dan berkualitas kepada pemangku kepentingan dalam setiap iterasi.

Scrum adalah kerangka kerja yang dinamis dan fleksibel. Namun, seringkali kesalahpahaman menghalangi implementasi yang efektif. Klarifikasi atas kesalahpahaman ini diharapkan dapat membantu Anda memahami lebih baik bagaimana mengadopsi scrum dengan benar. Teruskan untuk memahami lebih lanjut konsep-konsep penting dalam praktik scrum.

Menguak Kesalahpahaman Populer Tentang SCRUM (1)

Menguak Kesalahpahaman Populer soal SCRUM Part 2

Di artikel sebelumnya, kita sudah membahas beberapa kesalahpahaman yang umum terjadi tentang SCRUM. Sekarang, mari kita lanjutkan kesalahpahaman lain yang perlu diklarifikasi.

Poin 1: Product owner dan scrum master bagian dari tim SCRUM

Sebenarnya, dalam kerangka kerja scrum, keduanya adalah anggota integral dari tim. Mereka berperan penting dalam membantu tim mencapai kesuksesan proyek.

  • Product owner: Bertanggung jawab atas perencanaan dan pengelolaan backlog produk. Mereka adalah pemangku kepentingan utama yang menentukan kebutuhan dan prioritas fitur.
  • Scrum master: Berperan sebagai fasilitator untuk memastikan tim dapat menerapkan scrum dengan baik. Mereka membantu mengatasi hambatan, memfasilitasi event-event scrum, dan menjaga tim fokus pada prinsip-prinsip scrum.

Poin 2: Komunikasi antara anggota tim SCRUM tidak terbatas pada saat event

Scrum memiliki serangkaian event seperti daily scrum, sprint planning, sprint review, dan sprint retrospective. Namun, kesalahpahaman yang umum adalah mengira bahwa komunikasi antara anggota tim scrum hanya terjadi selama event tadi. Sebenarnya, komunikasi yang baik harus terjadi sepanjang sprint. Tim harus saling berkolaborasi dan berkomunikasi secara teratur untuk memecahkan masalah, berbagi pengetahuan, dan menjaga proyek berjalan lancar.

Poin 3: Estimasi waktu dan effort developer bukan komitmen mutlak

Estimasi waktu dan usaha pengembang selama sprint planning harus dianggap sebagai komitmen yang tidak boleh dilanggar. Anggapan itu tidak sepenuhnya benar. Estimasi adalah perkiraan berdasarkan pemahaman saat ini tentang pekerjaan yang harus dilakukan. Disisi lain, penting bagi pengembang untuk berusaha memenuhi estimasi dalam situasi yang berubah atau perencanaannya perlu disesuaikan saat muncul hambatan. Scrum mendorong adaptasi terhadap perubahan.

Poin 4: SCRUM wajib menggunakan scrum board

Meskipun scrum board berguna untuk memvisualisasikan pekerjaan dalam sprint, tools itu bukan jadi keharusan mutlak. Tim bisa menggunakan alat atau metode visualisasi yang sesuai dengan kebutuhan mereka. Hal terpenting, pekerjaan terlihat dan bisa dikelola dengan baik.

Poin 5: Sprint retrospective bukan bagian penting dari SCRUM

Beberapa orang berpikir bahwa sprint retrospective jadi opsional dalam SCRUM. Padahal, retrospektif adalah elemen penting dalam perbaikan terus-menerus. Ini adalah kesempatan bagi tim untuk melihat kembali sprint sebelumnya, mengidentifikasi apa yang berjalan baik dan apa yang perlu diperbaiki. Meskipun retrospektif mungkin tampak opsional, itu adalah alat yang kuat untuk meningkatkan kinerja tim.

SCRUM adalah kerangka kerja yang mempromosikan kolaborasi tim, adaptasi terhadap perubahan, dan perbaikan terus-menerus. Klarifikasi atas kesalahpahaman ini diharapkan dapat membantu Anda dalam menerapkan scrum dengan lebih baik. Jangan lewatkan artikel selanjutnya di seri ini, di mana kita akan terus menjelajahi konsep-konsep scrum yang penting.

Menguak Kesalahpahaman Populer soal SCRUM – part 1

Apakah kamu pernah mendengar tentang SCRUM? Sebagian mungkin sudah sering mendengarnya, terutama jika berkecimpung di dunia pengembangan perangkat lunak. Namun, ada banyak kesalahpahaman tentang SCRUM yang perlu kita klarifikasi. Dalam seri artikel ini, kita akan mengulas beberapa poin penting yang sering di salah pahami soal SCRUM. 

Poin 1: SCRUM bukan Metodologi, Melainkan Framework

Kesalahpahaman yang umum terjadi adalah menganggap SCRUM sebagai metodologi. Padahal, sebenarnya SCRUM adalah sebuah framework. Apa bedanya? Metodologi adalah aturan ketat yang harus diikuti di setiap situasi, sementara framework memberikan kerangka kerja yang lebih fleksibel. Dalam SCRUM, tim punya kebebasan untuk menyesuaikan praktik-praktiknya dengan kebutuhan proyek tertentu.

Poin 2: SCRUM bukan satu-satunya framework agile

Sebenarnya, ada banyak framework agile lain seperti Kanban, Lean, dan Extreme Programming (XP). SCRUM hanyalah salah satu pilihan, dan pemilihan framework bergantung pada karakteristik proyek dan preferensi tim.

Poin 3: Timebox dalam SCRUM itu penting!

Saat berbicara tentang SCRUM, seringkali ada kesalahpahaman bahwa timebox (waktu yang terbatas) dalam setiap kegiatan SCRUM tidak begitu penting. Ini tidak benar. Timebox adalah salah satu elemen kunci dalam SCRUM. Misalnya, dalam sprint, ada batasan waktu yang ketat untuk menyelesaikan pekerjaan. Ini membantu tim untuk tetap fokus dan menghasilkan hasil lebih baik dalam waktu yang telah ditentukan.

Poin 4: Daily SCRUM bukan cuma untuk laporan progress

Daily SCRUM atau stand-up meeting harian sering dianggap hanya sebagai wadah untuk melaporkan progress. Padahal sebenarnya lebih dari itu. Tujuan utama dari daily SCRUM adalah untuk menyinkronkan tim, mengidentifikasi hambatan yang mungkin muncul, dan membuat rencana tindakan yang diperlukan. Ini bukan hanya acara untuk product owner, melainkan seluruh tim.

Poin 5: Sprint harus menghasilkan increment

Anggapan itu bertentangan dengan prinsip utama SCRUM. Dalam setiap sprint, tim harus menghasilkan potongan produk yang berfungsi. Ini memungkinkan pemangku kepentingan untuk mendapatkan nilai tambah setelah setiap sprint selesai.

SCRUM adalah sebuah framework yang memungkinkan tim untuk mengembangkan produk dengan lebih efektif dan responsif terhadap perubahan. Menghindari kesalahpahaman tentang SCRUM adalah langkah pertama menuju penggunaan yang lebih baik. Dalam seri artikel ini, kami akan terus menjelajahi lebih dalam tentang SCRUM dan bagaimana Anda dapat menggunakannya secara efektif dalam pengembangan perangkat lunak. Nantikan kelanjutan pembahasan mengenai scrumb!

Panduan Praktis memaksimalkan potensi ChatGPT

Panduan Praktis memaksimalkan potensi ChatGPT

Sejak pertama kemunculannya, ChatGPT menjadi platform chatbot gratis berbasis teknologi AI paling populer. Meski berteknologi canggih, pengguna perlu tahu beberapa strategi agar penggunaannya lebih optimal. Artikel ini akan membahas beberapa tips dan trik untuk memaksimalkan teknologi dari ChatGPT. 

Berbicara dengan empati

Saat berinteraksi dengan ChatGPT, buatlah percakapan seolah-olah kamu berbicara dengan manusia. Jangan ragu untuk menuliskan perintah atau permintaan lebih rinci jika diperlukan. Konteks tambahan juga akan membantu ChatGPT merespons lebih relevan.

Batasan data hingga tahun 2021

ChatGPT menggunakan data hingga tahun 2021. Penting untuk diingat bahwa mesin ini mungkin tidak punya informasi terkini. Jadi, saat mencari berita atau informasi terbaru, pastikan kamu memverifikasi juga dari sumber lain.

Memiliki kemampuan serbaguna

ChatGPT bukan hanya sekadar asisten percakapan. Kamu bisa memanfaatkannya untuk berbagai keperluan, termasuk:

  1. Menulis konten: ChatGPT bisa membantumu untuk membuat artikel, email, bahkan kode pemrograman. Cukup berikan petunjuk dan panduan yang jelas.
  2. Format kustom: Kamu bisa meminta ChatGPT untuk menghasilkan teks dalam format tertentu, seperti Markdown, tabel, JSON, atau bahkan berbagai bahasa pemrograman. Ini memungkinkan kamu untuk mengotomatisasi tugas-tugas tertentu.
  3. Menggunakan informasi acuan: Kamu bisa memberikan informasi atau referensi tambahan kepada ChatGPT sebagai panduan dalam menjalankan tugas. Ini akan membantu mesin untuk memahami konteks tugas yang kamu berikan.

Kendalikan tone dan mood

Salah satu fitur unik ChatGPT adalah kemampuannya untuk menghasilkan teks dengan berbagai nada dan suasana hati. Kamu dapat menginstruksikan ChatGPT untuk menghasilkan teks dengan tone yang sesuai baik formal, santai, atau bersemangat. Ini akan membuat teks yang dihasilkan terasa lebih alami dan sesuai dengan tujuan kamu.

Dengan memahami dan mengimplementasikan panduan tadi, kamu dapat mengambil manfaat penuh dari ChatGPT. Teruslah berlatih dan eksperimen dengan mesin ini. Kamu akan menyadari jika ChatGPT adalah mitra yang berguna untuk meningkatkan produktivitas dan komunikasi di era digital.