Version Control System

 Pada saat saya minta mengajukan perpindahan AQM dan SSO dari server AWS ke Goocle Cloud, saya harus membuat dokumen pengajuan migrasi AMQ & SSO yang harus di setujui oleh 3 divisi yaitu infra, IT Enablement dan ke atasan pada squad atau tim.

 Pada saat setiap orang sign, saya simpan dokumen tersebut sebagai versi berikutnya saya lakukan berurutan sesuai dengan tanda tangannya. Hal ini saya lakukan untuk bisa nge-track perubahannya, dan sebagai backup jika versi yang terakhir bermasalah saya bisa ambil versi yang sebelumnya. seperti berikut version nya :

1. versi sign 01 - dokument ini sudah saya sign sebagai yang membuat dokumen
2. versi sign 02 - dokumen di sign oleh atasan saya
3. versi sign 03 - dokumen telah di sign oleh infra 
4. versi sign 04 - dokumen telah di sign IT Enablement

 Hampir semua bagian di dalam perusahaan melakukan hal tersebut dan biasanya secara manual.

Saat ini sudah ada Version Control System dari GIT yang bisa kita gunakan untuk case seperti di atas. Version Control adalah sebuah system yang merekam perubahan pada file dari waktu ke waktu, sehingga kita bisa melihat versi sebelumnya jika kita menginginkannya.

Version Control saat ini sangat populer di kalangan programmer, karena programmer selalu membuat code program dalam bentuk kode tulisan. Dengan Version Control programmer bisa merekam semua perubahan yang terjadi. Sehingga jika ada kesalahan programmer bisa dengan mudah kembali ke Versi Sebelumnya.

Version control dapat digunakan untuk file dalam bentuk text namun juga dapat digunakan file lain misal seorang grafik designer dapat menggunakan version control system untuk file PSD, ilustrator dll sehingga designer tidak perlu membackup secara manual.

Secara garis besar, Version Control System ada 3 jenis. yaitu :

1. Local Version Control
• Local version control merupakan version control yang hanya berjalan pada di local computer.
• pendekatan ini bisa digunakan karena sederhana dan tidak butuh server, karena semua riwayat pekerjaan tersimpan di local computer.
• setiap perubahan versi yang tersimpan di file tersimpan di local computer
  
  
2. Centralized Version Control
• masalah yang terjadi pada local version control adalah jika computer rusak maka seluruh data akan hilang
• selain itu, agak sulit berkolaborasi dengan pengguna lain jika file hanya ada pada satu computer
• untuk menangani masalah ini, kita bisa menggunakan Centrlized Version Control
• local version control menyimpan seluruh perubahan data pada server
• pengguna bisa mengakses data ke server untuk melihat perubahan file
• kekurangannya adalah jika pengguna offline mereka tidak bisa melihat semua riwayat file karena semua riwayat hanya ada pada server.
• selain itu, jika server down maka seluruh pengguna tidak bisa melakukan perubahan ataupun melihat perubahan / revisi file.
• contoh Centralized Version Control adalah Subrversion
  
  
3. Distributed Version Control (DVS)
• distributed version control adalah alternatif lain dari centralized version control 
• dalam DVSclient tidak hanya mengambil version terakhir namun seluruh riwayat version control di copy seluruhnya.
• dengan begitu, jika ada masalah pada server. client masih tetap bisa bekerja memanipulasi file, sampai melihata riwayat perubahan.
• bahkan dalam DVS, server bisa lebih dari satu, karena tiap server isinya sama yaitu full backup data.
• contoh DVS adalah GIT, Mercurial, dll

Coaching

Organisasi yang mengalami situasi VUCA (Volatility, Uncertainty, Complexity dan Ambiguity) perlu merepleksikan kembali leadership style-nya, karena leadership style yang dijalankan memungkinkan keberhasilan mendorong timnya untuk menyelesaikan tugas-tugas hingga mencapai target perusahaan.

Dalam situasi ini, tim menginginkan lebih dari sekedar training. Mereka juga ingin membangun budaya mentoring dan pengembangan diri melalui coaching, mereka ingin ada yang mendengarkan dan membantu mereka, mereka ingin mendapatkan feedback dan dukungan tidak hanya datang saat mereka berhasil mencapai target tetapi juga saat mereka gagal.

Menurut ICF (International Coach Federation), coaching adalah bentuk partnership yang terbangun antara coach dan coachee, untuk memaksimalkan potensi pribadi dan profesional coachee melalui proses kreatif guna menstimulasi dan mengeksplorasi pikiran agar dapat memaksimalkan potensi personal serta profesional.

Merujuk pada istilah partnership tersebut, maka ada unsur kesetaraan antara coach dengan coachee. Coach dan coachee berada dalam posisi duduk sama rendah dan berdiri sama tinggi. Dalam konteks partnership itu pula, proses yang terjadi di dalam coaching adalah proses dialog, komunikasi dua arah, dan saling memahami satu sama lain dalam suasana yang produktif.

Self Management

Pada dasarnya manusia adalah self-managing creature. Manusia adalah mahluk yang Otonom yang artinya manusia memiliki kehendak bebas untuk melakukan apa yang menurut dia baik bagi dirinya sesuai dengan kapasitas yang dia miliki. Self-managing adalah kebutuhan dasar manusia sebagai mahluk ciptaan Tuhan yang otonom, hal ini bukanlah sebuah utopia.

Ketika seorang bayi terlahir, dia tidak memiliki pengetahuan sama sekali (sering disebut masih suci). Seorang bayi mendapatkan pengetahuan dari apa yang dia lihat dan dengar tanpa ada yang memerintah dia untuk mempelajari dan mempaktikkan apa yang dia lihat.

Pada dasarnya software developer adalah individu yang baik adanya, kreatif, independent, self managing, dapat berpikir mandiri untuk menyelesaikan masalah yang mereka hadapi.

Lalu apa yang membuat perilaku manusia menjadi tidak self-managing dalam dunia kerja ?

Menurut saya ada dua hal yang mempengaruhi nya yaitu Pendidikan dan system di dunia kerja.

1.      Pendidikan yang pasif

Saya adalah salah satu siswa yang mengalami Pendidikan yang pasif dimana waktu Sekolah Dasar guru menyuruh semua murid di kelas untuk satukan tangan di atas meja bahkan terkadang dilarang untuk bergerak dan mendengarkan guru yang ngoceh di depan. Ketika SMP Pendidikan pasif yang saya alami berubah dimana guru masuk dikelas memberikan buku kemudian menyuruh ketua kelas membacakan dan yang lain menuliskan di buku tulisdan di SMA dan kuliah pun begitu.

System Pendidikan di Indonesia telah berhasil mengembangkan orang-orang yang pasif dan tidak mengerti apa itu self-managing karena selama enam belas tahun terbiasa pasif duduk di kelas mendengarkan dan mengiyakan guru atau dosen yang sedang mengajar.

2.      System di dunia kerja

System di dunia kerja yang tanggung-jawab sepenuh nya menjadi beban seorang manager, sehingga seorang manager merencanakan sedemikian rinci dan memaksa semua orang mengikuti rencana yang manager buat.

Jika ada seorang software developer yang menerapkan self-manage dan melakukan apa yang menurutnya baik, maka cara berpikir seperti ini akan menempatkan software developer tersebut sebagai pribadi yang liar, bebal, tidak bisa di atur, dan memiliki ketergantungan kepada otoritas yang lebih tinggi darinya.

Self-managing bukan hanya perilaku dasar manusia, namun juga perilkau dasar hewan cintaan tuhan lainnya.

Sekumpulan bebek akan mebentuk “V” ketika mereka akan terbang ketempat baru. Ikan makarel akan berkelompok dalam jumlah besar untuk menakuti ikan yang jauh lebih besar. Semut adalah hewan yang paling menarik. Dalam koloni semut, tidak ada satu semut pun yang memimpin koloni dan memerintah anggota koloni lainnya. Semut tahu benar kalau secara kesatuan mereka dapdat melakukan hal yang besar. Semut self managing untuk bekerjasama sebagai satu-kesatuan mencari makanan untuk koloninya dan menyelesaikan pekerjaan-pekerjaan tanpa ada otoritas terpusat sama sekali. Kita sebagai mahluk tuhan yang paling mulia seharusnya bisa memahami self-managing jau lebih baik dari semut.

Sebagai seorang manager, kita harus mengerti bahwa self-managing bukanlah perilaku liar yang tidak dilandasi tanggungjawab. Self-managing adalah sebuah kebebasan dalam sebuah Batasan yang disepakati Bersama. Self-managing adalah sebuah otonomi dalam bekerja dimana seorang software developer dapat menentukan sendiri bagaimana cara yang terbaik untuk mereka menghasilkan tujuan yang diminta.

Software developer membutuhkan otonomi dalam melakukan pekerjaan mereka, karena hanya dengan demikian potensi developer dapat berkembang menjadi seorang Rock-star Developer. Self-management juga mendukung perusahaan untuk bisa menjadi agile. Software developer yang masih harus diperintah tidak akan bergerak lebih cepat karena akan selalu ada lag-time untuk dia menunggu instruksi dari managernya. 

3 Pilar SCRUM

 Scrum memiliki empat acara formal untuk inspeksi dan adaptasi yaitu sprint planning, daily scrum, sprint review dan sprint retrospective dimana keempat acara tersebut di lakukan dalam setiap sprint. Biasanya pada awal sprint berjalan banyak member tim yag berpikir bahwa inspeksi dan adaptasi hanya dilakukan pada sprint retrospective, dan ini selalu saya alami pada setiap tim yang saya coaching.

Inspeksi dan adabtasi tidak hanya di lakukan di acara-acara besar sprint saja (sprint planning, sprint review dan sprint retrospective) tapi juga di lakukan di daily scrum yang dilakukan setiap hari, hal ini berarti bahwa inspeksi dan adabtasi dilakukan setiap hari.

Pada sprint planning kita melakukan inspeksi dan adabtasi kemungkinan goal yang akan di capai pada sprint yang akan berjalan. Pada daily scrum kita inspeksi dan adabtasi kemajuan menuju sprint goal dan menyesuaikan sprint backlog seperlunnya dan menyesuaikan rencana kerja yang akan datang. Sprint review kita melakukan inspeksi dan adabtasi terhadap hasil dari sprint. Dan sprint retrospective kita inspeksi dan adabtasi cara untuk meningkatkan kualitas dan efektivitas.

Namun untuk bisa inspeksi dengan baik, diskusi harus di dasari dengan transparansi. Inspeksi tanpa adanya transparansi hanya akan menutupi masalah dan mengambil keputusan dengan data yang tidak benar hanya akan meningkatkan risiko. Inspeksi tanpa adanya transparansi, menyesatkan dan sia-sia.

Tiga hal tersebut, transparansi, inspeksi dan adabtasi merupakan 3 pilar scrum.

Kolaborasi atau approval ?

 belajar dari kolaborasi dengan user selama ini, ketika user diminta approval (secara psikologi user tersebut akan merefleksikan bahwa dia yang akan bertanggungjawab terhadap kegagalan fitur tersebut).

sehingga untuk menjawabnya user sangat hati-hati bahkan minta approval lagi ke managernya atau ke divisi lain untuk share risiko gagal nya (kalau-kalau misalkan ada kesalahan dia ada temannya yang disalahkan). hal ini yang membuat user lama untuk approve.

kalau kita tarik kebelakang, kenapa sih kita mesti ada approval dari user ?

yaps, untuk memastikan apa yang akan kita buat sesuai dengan kebutuhan user yang akan menggunakan epic yang di develop tersebut. 

kalau tujuannya adalah untuk memastikan detail dari epic yang akan di buat sesuai dengan kebutuhan user, apakah perlu menggunakan kata approve ? 

dimana berdasarkan pengalaman kita sebelum-sebelumnya untuk mendapatkan jawabannya terkadang sampai berminggu-minggu padahal jawabnnya hanya iya atau tidak.

kalau kita lihat arti dari approval adalah menyetujui, sedangkan tujuan dari aktivitas kita adalah memastikan mendapatkan detail kebutuhan user. 

seharusnya yang wajar diminta persetujuan adalah jika usernya tidak terlibat dalam proses development atau tidak berkolaborasi dengan tim development. yang kita lakukan saat ini, kita berkolaborasi dengan stakeholder, user terlibat dengan proses develpment, namun juga user di minta approval. 

approval membuat seolah scrum tim dengan stakehlder adalah dua pihak yang berbeda, sehingga perlu ada approval. untuk bisa agile scrum tim dan stakeholder bekerja secara bersama-sama (berkolaborasi) untuk menghasilkan epic yang dapat meningkatkan value product. 

jadi pembelajaran yang kita ambil adalah "praktikal approval menghambat agility".

"The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency." - scrum guide.

Scrum Values

 

8 Topi Scrum Master

 

Agile Story Point

 Menurut definisi dari Atlasian "Story Point adalah ukuran estimasi untuk mengerjakan sebuah product backlog atau sebuah kerjaan. Estimasi terhadap rumitnya, resikonya, lamanya, banyaknya sebuah pekerjaan". Inti dari story point adalah estimasi ukuran pekerjaan.

contoh ukuran teknik untuk menentukan estimasi ukuran story point :

1. Planning Poker 

teknik estimasi ukuran story point dengan planning poker adalah point nya mengikuti angka Fibonacci yaitu 1,3,5,8,13,21, dst.

2. Ukuran T-Shirt

teknik ini meng-estimasi ukuran pekerjaan dimana nilai point nya mengikuti ukuran baju yaitu XS, S, M, L, XL, XXL

3. Bucket System

teknik pengukuran pekerjaan dengan bucet system adalah mengukur pekerjaan dengan nilai point 0,1,2,3,4,5,8,13,20,30,50,100,200.

4. Dot Voting

titik sebagai tanda estimasi dari setiap tim

5. Affinity Estimation

estimasi dengan mengumpulkan story yang sejenis.

sebenarnya masih banyak teknik untuk melakukan estimasi ukuran pekerjaan, biasanya yang paling sering di pakai adalah Planning Poker yaitu point nya mengikuti nilai Fibonacci.

estimasi ini mempunyai banyak manfaat yaitu mempermudah tim untuk mengukur kemampuan tim dan tugas yang akan di selesaikan dan mempermudah tim dan product owner untuk menentukan seberapa banyak value yang bisa dideliver di setiap sprint.

pendekatan dengan story point ini adalah alternatif pendekatan estimasi man-hour yang biasa digunakan pada project konvensional.

BAGAIMANA KALAU ESTIMASI KITA TERNYATA MELESET?

misal pada awal kita mengestimasikan nilai storynya adalah 3 story point, ternyata ketika eksekusi pekerjaan nya cukup sulit yang setara dengan 5 story point. 

Apa yang mestinya kita lakukan? 

apakah kita perlu mengubah story point nya menjadi 5 atau biarkan saja story point nya tetap 3?

Satu hal yang perlu diingat adalah Story Point dan Velocity bukanlah sesuatu yang dianggap bagian dari Scrum. Sehingga untuk kasus diatas, dikembalikan lagi ke tim, bagaimana sebaiknya mengatur dan menyikapi kasus diatas.

Biasanya ada 2 pendekatan untuk masalah ini :

Pendekatan pertama mengacu kepada estimasi pada dasarnya hanyalah perkiraan, sehingga kalaupun meleset, maka dianggap tidak apa-apa. Tidak perlu untuk mengubah story point yang sudah kita estimasi dari awal. Evaluasi mengenai estimasi yang meleset ini bisa dibahas di sprint Retrospective. Agar nanti bisa diperbaiki di sprint berikutnya. Bisa jadi karena kita tidak memperhitungkan faktor risk dalam penentuan story point, atau story nya tidak detil sehingga kita tidak tepat dalam estimasi story point.

Pendekatan kedua mengacu kepada esensi bahwa sprint haruslah merepresentasikan kapasitas tim dalam melakukan sesuatu. Yang digambarkan dari jumlah story point. Dalam hal ini mengubah story point merupakan salah satu cara untuk mencapai tujuan tersebut. Dan hal ini sah-sah saja karena cukup beralasan.

Kesimpulannya :

Dua pendekatan diatas boleh-boleh saja, tetapi biasanya yang dilakukan adalah pendekatan pertama, dimana story point adalah dianggap sebagai estimasi saja, yang bisa salah dan bisa benar. Tidak perlu mengubah story point yang sekarang. Jadikan kesalahan itu sebagai bahan perbaikan di sprint berikutnya.