KATA PENGANTAR

Era Digitalisasi pada Industri 4.0 di Indonesia saat ini dihadapkan pada tantangan hadirnya
permintaan dan penawaran talenta digital dalam mendukung perkembangan ekosistem industri teknologi.
Tantangan tersebut perlu dihadapi salah satunya melalui kegiatan inovasi dan inisiasi dari berbagai pihak
dalam memajukan talenta digital Indonesia, baik dari pemerintah maupun mitra kerja pemerintah yang
dapat menyiapkan angkatan kerja muda sebagai talenta digital Indonesia. Kementerian Komunikasi dan
Informatika melalui Badan Penelitian dan Pengembangan Sumber Daya Manusia sejak tahun 2018-2019,
telah menginisiasi Program Digital Talent Scholarship yang telah berhasil dianugerahkan kepada 26.000
penerima pelatihan di bidang teknologi informasi dan komunikasi. Program Digital Talent Scholarship ini
ditujukan untuk memberikan pelatihan dan sertifikasi tema-tema bidang teknologi informasi dan
komunikasi, diharapkan menjadi bagian untuk memenuhi permintaan dan penawaran talenta digital
Indonesia.

Tahun ini, Program Digital Talent Scholarship menargetkan pelatihan peningkatan kompetensi
bagi 60.000 peserta yang bertujuan untuk meningkatkan keterampilan dan daya saing SDM bidang
teknologi informasi dan komunikasi sebagai bagian dari program pembangunan prioritas nasional.
Program pelatihan DTS 2021 ditujukan untuk meningkatkan keterampilan, keahlian angkatan kerja muda
Indonesia, masyarakat umum dan aparatur sipil negara di bidang teknologi informasi dan komunikasi
sehingga dapat meningkatkan produktivitas dan daya saing bangsa di era Industri 4.0.

Program DTS 2021 secara garis besar dibagi menjadi Tujuh akademi, yaitu: Fresh Graduate
Academy (FGA), Program pelatihan berbasis kompetensi bersama GlobalTech yang ditujukan kepada
peserta pelatihan bagi lulusan S1 bidang TIK dan MIPA, dan terbuka bagi penyandang disabilitas; Vocational
School Graduate Academy (VSGA), Program pelatihan berbasis kompetensi nasional yang ditujukan kepada
peserta pelatihan bagi lulusan SMK dan Pendidikan Vokasi bidang TI, Telekomunikasi, Desain, dan
Multimedia; Coding Teacher Academy (CTA), Program pelatihan merupakan program pelatihan
pengembangan sumberdaya manusia yang ditujukan kepada peserta pelatihan bagi Guru setingkat
SMA/SMK/MA/SMP/SD di bidang pemrograman. Online Academy (OA), Program pelatihan OA merupakan
program pelatihan Online di bidang Teknologi Informasi yang ditujukan kepada peserta pelatihan bagi
Masyarakat umum, ASN, mahasiswa, dan pelaku industri; Thematic Academy (TA), Program pelatihan TA
merupakan program pelatihan multisektor bagi pengembangan sumberdaya manusia yang ditujukan
kepada peserta pelatihan dari jenjang dan multidisiplin yang berbeda; Regional Development Academy
(RDA), Program pelatihan RDA merupakan program pelatihan pengembangan sumberdaya manusia yang
ditujukan untuk meningkatkan kompetensi ASN di Kawasan Prioritas Pariwisata dan 122 Kabupaten
Prioritas Pembangunan. Digital Entrepreneurship Academy (DEA), Program pelatihan DEA merupakan
program pelatihan pengembangan sumberdaya manusia yang ditujukan kepada talenta digital di bidang
Usaha Mikro, Kecil, dan Menengah (UMKM).

Selamat mengikuti Pelatihan Digital Talent Scholarship, mari persiapkan diri kita menjadi talenta digital
Indonesia.

Jakarta, 24 Februari 2021

Kepala Badan Penelitian dan Pengembangan Sumber Daya Manusia
Kementerian Komunikasi dan Informatika Republik Indonesia
Dr. Hary Budiarto, [Link]

Pendahuluan

Unit kompetensi ini berhubungan dengan …

Unit kompetensi ini berhubungan dengan pengetahuan dan keterampilan dasar yang
dibutuhkan untuk menjadi software engineering.

A. Tujuan Umum
Setelah mempelajari modul ini peserta latih diharapkan mampu memahami dasar dari
software engineering secara umum.

B. Tujuan Khusus
Adapun tujuan mempelajari unit kompetensi melalui buku informasi Pelatihan
Introduction to Software Engineering adalah memahami proses dari pencarian
masalah, memecahkan masalah, siklus pengembangan perangkat lunak, serta
versioning yang nantinya dapat digunakan untuk berkolaborasi saat proses pembuatan
perangkat lunak.

Latar belakang

Dalam pembuatan sebuah perangkat lunak, kita harus memahami bagaimana proses
pembuatan perangkat lunak dilakukan, agar perangkat lunak yang kita buat memang
memecahkan masalah yang ada. Untuk itu perlu dipahami bagaimana sebuah proses
mulai dari pencarian sebuah masalah, sampai dengan pencarian solusi dari
permasalahan tersebut. Setelah mendapatkan ide untuk pemecahan sebuah masalah,
saat proses pembuatan perangkat lunak, kita juga harus memahami bagaimana siklus
pembuatan perangkat lunak, agar proses pembuatan perangkat lunak tersebut dapat
dikerjakan dengan mudah. Salah satu siklus pembuatan perangkat lunak yang cukup
terkenal adalah SCRUM.

Selain itu dalam pembuatan perangkat lunak, umumnya tidak dikerjakan dengan satu
orang. Sehingga diperlukan pemahaman bagaimana untuk dapat membuat perangkat
lunak yang dikerjakan bersama-sama. Sehingga perlu pemahaman tentang git, agar
pembuatan perangkat lunak tersebut dapat dikerjakan bersama-sama secara
asynchronous atau paralel.

Deskripsi Pelatihan

Materi ini berisi penjelasan dari bagaimana kita memecahkan masalah sampai dengan
mencari solusi untuk permasalahan tersebut dengan Design Thinking, Alur pembuatan
perangkat lunak dengan mempelajari siklus hidup perangkat lunak SCRUM, dan
pembuatan perangkat lunak bersama-sama dengan menggunakan git.
 Tujuan Pembelajaran

A. Tujuan Umum
Setelah mempelajari modul ini peserta latih diharapkan mampu memahami
dasar dari software engineering secara umum.

B. Tujuan Khusus
Adapun tujuan mempelajari unit kompetensi melalui buku informasi Pelatihan
Introduction to Software Engineering adalah memahami proses dari pencarian
masalah, memecahkan masalah, siklus pengembangan perangkat lunak, serta
versioning yang nantinya dapat digunakan untuk berkolaborasi saat proses
pembuatan perangkat lunak.

Kompetensi Dasar

Mampu mencari masalah untuk diselesaikan dengan solusi pembuatan perangkat lunak
dengan metode design thinking
Mampu memanajemen proyek, dengan menggunakan metode SCRUM
Mampu memahami versioning control dengan git
Mampu bekerja bersama dalam pembuatan perangkat lunak dengan menggunakan git

Indikator Hasil Belajar

Dapat memahami manajemen proyek pembuatan perangkat lunak dimulai dari

pencarian masalah, pencarian solusi dari permasalahan, dan bekerja bersama-sama
dengan menggunakan git.

INFORMASI PELATIHAN

Akademi Thematic Academy

Mitra Pelatihan Rakamin Academy

Tema Pelatihan IT PERBANKAN DIGITAL TALENT SCHOLARSHIP 2021

Sertifikasi

Persyaratan Sarana Peserta/spesifikasi device Laptop dengan spesifikasi:

Tools/media ajar yang akan digunakan 1. RAM minimal 4 GB (disarankan 8 GB)
2. Laptop dengan 64-bit processor
3. Laptop dengan Operating System Windows 10
(WSL ubuntu 18 / 20 ) / MacOS / Linux
4. Laptop dengan konektivitas WiFi dan memiliki
Webcam
 5. Akses Internet Dedicated minimal 126 kbps per
peserta per perangkat .
6. Memiliki akun Trello

Aplikasi yang akan di gunakan selamat pelatihan 1. Zoom

2. Trello

Tim Penyusun ● Adam Sulthoni Akbar

INFORMASI PEMBELAJARAN

Unit Kompetensi Materi Kegiatan Durasi Rasio Sumber

pembelajaran pembelajaran Pelatihan Praktek : Teori pembelajaran
Design Thinking 1. Pengenalan Daring / Online 2 40% Teori,
Implementation Design Thinking 60% Praktik
2. Implementasi
Design Thinking

SDLC and Scrum for 1. Pengenalan SDLC Daring / Online 2 60% Teori,
Managing Project dan 40% Praktik
jenis-jenisnya
2. Penjelasan Detail
SDLC metode
Scrum

Basic Git Penjelasan dan Daring / Online 2 20% Teori,

pengenalan 80% Praktik
mengenai git

Collaborating Using Bagaimana Daring / Online 2 20% Teori,

Git penggunaan git 80% Praktik
untuk bekerja
bersama-sama

Materi Pokok

1. Design Thinking Implementation

2. SDLC and Scrum For Managing Project
3. Basic Git
4. Collaborating Using Git

Sub Materi Pokok

 MATERI PELATIHAN

1. Design Thinking
Pendekatan ini awalnya diperkenalkan oleh Stanford University, namun yang
menggunakan penyebutan serta melakukan standarisasi terhadap proses dan
bagaimana pendekatan ini dipergunakan dalam sebuah organisasi atau
perusahaan adalah IDEO, dan dilakukan oleh David Kelley & Tim Brown sejak
1990. Secara umum design thinking merupakan salah satu pendekatan human
centered, yang digunakan untuk menemukan sebuah solusi atau merumuskan
suatu inovasi.

fig 1. Irisan ide yang dibuat dari desirability, viability, dan feasibility (1)

Seperti dijelaskan dalam gambar fig 1 dimana pendekatan ini akan membantu
proses perumusan suatu solusi yang benar-benar dibutuhkan dan diinginkan
oleh konsumen. namun tetap mungkin tercapai bila dilihat dari sisi teknologi dan
ekonomi.

- Desirability, apa yang diinginkan oleh konsumen?

- Viability, apa yang dapat memberikan keberlanjutan pada business model
yang ada?
 - Feasibility, apa yang mampu untuk dicapai dengan teknologi yang ada saat
ini?

1.1 Mengapa Design Thinking

Mengapa memerlukan pendekatan lain saat metodologi lainnya seperti User
Centered Design atau Human Centered sudah cukup mature secara usia dan
metodologi. Melalui proses yang dilalui design thinking akan mencoba menggali
permasalahan ataupun kebutuhan dari konsumen dan menggunakannya sebagai
dasar selama proses brainstorming untuk merumuskan sebuah produk maupun
solusi. Kegiatan tersebut akan membangun empati serta memenuhi aspek
desirability. Namun juga tetap memberikan ruang pada business objective
sehingga solusi yang dihasilkan tetap sustainable dari segi business model=nya.
Bila disimpulkan pendekatan ini juga memiliki beberapa kelebihan, diantaranya:

- Merupakan proses yang human centered, sehingga dokumentasi serta data

yang diperoleh benar-benar berasal dari konsumen.
- Melalui proses brainstorming yang dilakukan keterlibatan tim dari
berbagai bagian dapat dicapai, sehingga seluruh pihak dapat memiliki
pemahaman yang sama. Terhadap permasalahan dan solusinya
- Mendorong inovasi dengan melihat permasalahan dari berbagai sisi.

1.2 Proses Design Thinking

Sebelum masuk kedalam tahapan-tahapan pada design thinking terdapat 3
mindset yang perlu untuk diperhatikan selama menerapkan pendekatan ini.
Mindset tersebut antara lain:

- Human Centeredness, hal ini menjadi fundamental karena pendekatan ini

berasal dari Human Centered Design. Dimana nantinya perhatian akan
diberikan penuh kepada permasalahan yang dialami konsumen beserta
seluruh tahapan yang dilakukan dari sudut pandang manusia pada
umumnya.
 - Abductive Reasoning, karena data yang diperoleh nantinya merupakan
data kualitatif, perlu dicatat bahwasanya tidak akan pernah tercapai
kebenaran yang absolut. Oleh karena itu abductive reasoning akan
men-drive solusi berdasarkan observasi, kreativitas, serta penjelasan yang
cukup. Sehingga setiap solusi yang dimiliki wajib untuk diuji.
- Learning by Falling, proses pengujian ide atau solusi merupakan proses
pembelajaran. Semakin cepat ide dapat diujikan maka semakin cepat pula
kesalahan akan ditemukan dan permasalahan dapat segera diselesaikan.

Berdasarkan ke-3 mindset tersebut design thinking akan banyak berputar pada
kegiatan “memahami konsumen”, “rapid prototyping”, dan “brainstorming”.

fig 2. Tahapan tahapan design thinking

Seperti dijelaskan pada fig 2 proses design thinking akan terbagi menjadi 6
tahapan. Secara deskriptif proses ini terlihat linear, namun pada penerapannya
sangat diperbolehkan untuk kembali ke tahapan sebelumnya serta melakukan
keseluruhan secara iteratif.

1.3 Frame a Question

Tahapan pertama dari pendekatan ini adalah memberikan pemahaman kepada

tim atas target konsumen yang akan dituju. Dari perbedaan latar belakang setiap
anggota tim tentunya pendapat yang diberikan akan berasal dari sudut pandang
yang berbeda. Sehingga dapat muncul pertanyaan yang beragam guna
memperoleh pemahaman yang lebih mendalam terhadap target konsumen yang
dituju. Salah satu cara untuk memberikan pemahaman kepada tim yaitu melalui
User Persona.

Secara singkat user persona merupakan sebuah gambaran fiktif namun tetap
realistis dari target konsumen yang dituju. Umumnya persona akan atas
beberapa bagian seperti data demografis, kebutuhan konsumen, permasalahan
yang dialami, dan tujuan yang ingin dicapai seperti dijelaskan dalam gambar fig
3.

fig 3. Template User Persona

Dalam gambar fig 3 terdapat beberapa bagian yang tidak ditandai seperti
behavioral consideration serta task. Bagian ini tidak wajib untuk didefinisikan
namun dalam penerapannya akan sangat membantu tim untuk memperoleh
pemahaman terkait dengan target konsumen yang akan dituju.

1.3.1 Tips Membuat Persona

Dikarenakan user persona merupakan langkah awal dari tahapan design thinking
dan digunakan sebagai salah satu guideline pada tahapan-tahapan selanjutnya
berikut beberapa hal yang dapat diperhatikan, diantaranya:
 - Prosesnya lebih baik jika dilakukan bersamaan dengan anggota tim
lainnya (brainstorming).
- Mulai proses pembuatan persona dengan mengelompokkan karakteristik
dari konsumen yang dituju (data demografis)
- Untuk data demografis jangan gunakan identitas yang didasarkan pada
teman atau orang yang dikenal. (fiktif tapi tetap realistis)
- Jelaskan latar belakang dengan realistis, seperti apa pekerjaan yang
dilakukan serta bagaimana kegiatan sehari-harinya.
- Berikan keterangan terkait pemahaman konsumen terhadap produk atau
solusi yang sedang dikembangkan (tech savviness)
- Berikan konteks kapan produk atau solusi anda digunakan, seberapa
sering, dan bagaimana “itu” (solusi) akan digunakan.
- (opsional) Tambahkan personal quotes untuk menyimpulkan attitude atau
sifat yang dimiliki oleh konsumen.
eg. “Tidak ada yang salah, yang ada hanya kebenaran yang tertunda”

Sebagai catatan tujuan dari dibuatnya persona adalah untuk memperoleh

pemahaman terkait dengan target konsumen melalui sebuah karakter fiktif yang
terasa hidup dan dapat dipercaya. Maka hindari menambahkan informasi yang
tidak ada hubungannya dengan solusi atau produk yang sedang dikembangkan.

1.4 Gather Inspiration

Tahapan selanjutnya adalah saat inspirasi dikumpulkan melalui observasi.

Observasi dapat dilakukan dimana saja, dalam format desk research dengan studi
pada kompetitor atau report penelitian yang telah ada, maupun secara langsung
kepada target konsumen. User Persona yang sebelumnya dibuat dapat digunakan
sebagai acuan untuk menentukan kompetitor maupun calon partisipan yang
akan dituju. Dari beragamnya kegiatan yang dapat dilakukan tentunya
diperlukan sebuah acuan, hal ini diperlukan agar tujuan untuk memperoleh
inspirasi terkait dengan produk yang akan dikembangkan dapat tercapai.
Sebelum menuju kegiatan observasi hal pertama yang dapat dipersiapkan adalah
Research Plan.
Research Plan merupakan dokumen yang dapat membantu menjelaskan objective
dari proses penelitian yang akan dilakukan untuk mengumpulkan inspirasi. Dari
pemahaman ini nantinya dapat ditentukan kegiatan observasi mana yang cocok
untuk dilakukan berkaitan dengan tujuan dan hasil yang akan dicapai. Berikut
template yang dapat digunakan untuk membuat Research Plan . Saat menentukan
objective dari proses penelitian yang akan dilakukan dapat digunakan
pendekatan seperti yang dijelaskan dalam gambar fig 4, yang mana secara umum
tujuan yang harus dicapai adalah mencari tahu bagaimana interaksi users dalam
konteks saat ini adalah konsumen dengan tujuan serta lingkungan mereka.

fig 4. Diagram Vein Pendekatan Desk Research

1.4.1 Desk Research

Desk Research merupakan sebutan lain dari secondary research. Seperti namanya
pada bagian ini proses pengumpulan inspirasi akan dilakukan menggunakan
sumber ke-2 seperti berita, jurnal penelitian, report penelitian perusahaan yang
telah dilakukan sebelumnya, juga kompetitor. Sebagai konteks desk research
dapat dilakukan untuk mencapai tujuan penelitian seperti yang dijelaskan dalam
gambar fig 4 sebelumnya. Berdasarkan gambar tersebut beberapa bagian yang
dapat dipenuhi melalui proses ini antara lain:
 - Users & Environments, interaksi user (konsumen) dengan lingkungan. Pada
bagian ini jangan membatasi cakupan hanya pada domain permasalahan
yang coba diselesaikan, namun coba juga cari tahu dari sudut pandang
lainnya.
- Environments & Goals, hal ini akan mencakup bagian-bagian yang akan
diakomodasi oleh solusi yang sedang dikembangkan beserta peranannya
dalam mencapai tujuan namun tidak melibatkan pengguna secara
langsung.
eg. Kemungkinan penerapan data analytics, customer care, dll

1.4.2 In Depth Interview

Bagian ini merupakan salah satu pendekatan dari Primary Research, dimana akan
meng-cover proses untuk memahami irisan pada bagian Users dan Goals-nya,
seperti dijelaskan dalam gambar fig 4. Sehingga dalam beberapa kasus metode
ini tidak akan relevan untuk diterapkan. Bila melihat penjelasan deskriptif dari
metode In Depth Interview, metode ini merupakan bentuk riset kualitatif yang
dilakukan melalui obrolan atau wawancara secara mendalam pada sekelompok
kecil partisipan, dengan catatan dilakukan satu per satu. Melalui obrolan yang
intim, metode ini dapat digunakan untuk menjawab pertanyaan why dan how,
seperti mencari tahu pengalaman dari partisipan, proses yang biasa dilakukan,
dan berbagai hal personal lainnya.

Secara garis besar in depth interview memang memungkinkan untuk

memperoleh insights yang mendalam terkait dengan perilaku, sudut pandang,
maupun permasalahan yang sedang dihadapi oleh konsumen. Namun dalam
penerapannya perlu untuk memperhatikan beberapa hal seperti:

- Data yang diperoleh bukanlah data yang dapat digunakan untuk

membenarkan suatu hal. Namun digunakan sebagai acuan atau penguat
sebuah argumen.
- Data yang diperoleh tidak akan menggambarkan kondisi dari seluruh
target konsumen yang dituju. Melainkan hanya menggambarkan sebagian
kecil dari kondisi sebelumnya (abductive reasoning)
 - Perlu memperhatikan kesesuaian pertanyaan yang diajukan dengan
Research Guideline yang telah dibuat.

1.5 Generate Idea

Pada tahapan ini kegiatan yang dilakukan akan banyak berpusat pada proses
menyatukan data-data yang telah diperoleh dari tahapan sebelumnya untuk
membentuk suatu solusi. Oleh karena itu apabila memungkinkan diharapkan
seluruh bagian dari tim dapat terlibat dalam proses brainstorming pada tahapan
ini. Tentunya bertukar ide tanpa ada suatu guideline tertentu tidak akan efektif,
oleh karena itu terdapat beberapa tools yang dapat dimanfaatkan seperti:

- User Journey Map

- Affinity Diagram
- Crazy-8
- Storyboard

1.5.1 User Journey Map

fig 5. Template User Journey Map

Sebagai salah satu contoh tools yang dapat digunakan selama proses
brainstorming, user journey map dapat membantu tim untuk memperoleh garis
besar perjalan konsumen dalam mencapai tujuan saat berinteraksi dengan
produk. Dalam proses perancangannya terdapat 5 komponen utama yang harus
di akomodasi dalam user journey map seperti dijelaskan dalam gambar fig 5,
antara lain:

1. Aktor, aktor akan menjelaskan siapakah pihak yang akan mengalami

skenario yang telah didefinisikan pada journey map. Aktor akan
disesuaikan dengan persona maupun data yang telah diperoleh pada
proses penggalian kebutuhan.
2. Skenario dan tujuan, skenario akan mendeskripsikan situasi yang
digambarkan oleh journey map dengan tujuan, kebutuhan, serta
ekspektasi pengguna. Skenario dapat berupa apapun, baik flow dari
produk yang telah ada maupun rancangan.
3. Journey phases, journey phases akan memberikan gambaran umum
terkait dengan skenario pengguna. Journey phases akan memberikan
format pada informasi yang nantinya akan ditampilkan pada journey map
seperti aksi, pertimbangan, dan emosi.
4. Aksi, pertimbangan, dan emosi. Aksi akan meliputi perilaku dan setiap
tahapan yang akan dilalui oleh pengguna. Pertimbangan yang dimaksud
pada bagian ini adalah sesuatu yang berhubungan dengan pikiran
pengguna seperti pertanyaan, motivasi, dan informasi yang kemungkinan
akan diperlukan oleh pengguna untuk mencapai tujuan. Emosi akan
menggambarkan fluktuasi dari mood yang dimiliki oleh pengguna dalam
menyelesaikan tugas-tugas yang ada.
5. Opportunities, merupakan temuan yang diperoleh dari proses
perancangan journey map. Hal ini akan menggambarkan bagaimana suatu
journey yang dialami oleh pengguna dapat dikembangkan lebih baik lagi.
Dalam artian possibility dari solusi yang dapat diterapkan.

1.6 Make Ideas Tangible

Setelah diperoleh pemahaman terkait dengan target konsumen, permasalahan
yang sedang, serta kemungkinan solusi yang dapat diterapkan. Tahapan
selanjutnya adalah mengembangakan prototype untuk melihat seberapa jauh ide
yang telah dirumuskan dapat diterapkan. Dalam konteks prototype terdapat
beberapa model yang dapat digunakan dan disesuaikan dengan kondisi yang
sedang dihadapi. Beberapa model tersebut antara lain:

- Low Fidelity Prototype, prototype pada tahapan ini merupakan bagian

paling dasar yang dapat dilakukan dengan sketsa produk pada kertas.

eg. paper prototyping

- Medium Fidelity Prototype, prototype pada tahapan ini merupakan bentuk

sketsa yang telah melalui proses digitalisasi dalam bentuk clickable
 wireframe.

eg. medium fidelity prototype

- High Fidelity Prototype, prototype pada tahapan ini telah berbentuk

tampilan antarmuka yang lebih interaktif. Format penyajiannya pun
beragam, mulai dari clickable prototype seperti yang dihasilkan
menggunakan program figma, hingga tampilan static dari kode program.

eg high fidelity prototype

1.7 Test to Learn

Perlu diingat solusi yang dihasilkan dari proses pemikiran dengan pendekatan
abductive reasoning tidak sepenuhnya benar. Terlebih data yang diperoleh dari
proses In Depth Interview juga tidak dapat memberikan gambaran menyeluruh
dari target konsumen yang dituju. Oleh karena ini tahapan ini harus dilakukan
sesegera mungkin. Semakin dini dan semakin sering dilakukan tentunya akan
membantu tim untuk segera belajar dan mengetahui kesalahan-kesalahan yang
terjadi. Sehingga proses perumusan solusi baru dapat segera dilakukan.

1.7.1 Usability Testing

Untuk melakukan pengujian terdapat berbagai metode yang dapat diterapkan,

namun metode Usability Testing merupakan metode yang memungkinkan proses
pengujian dilakukan secara langsung kepada target konsumen. Melalui kegiatan
ini bias yang muncul dapat benar-benar di eliminasi menggunakan data yang
diperoleh dari hasil observasi yang diperoleh dari target konsumen secara
langsung.

Secara umum Usability Testing dapat dilakukan dengan mempersiapkan

beberapa hal, seperti:

- Skenario tugas, hal ini menjadi penting dikarenakan partisipan pengujian

yang terlibat akan diobservasi berdasarkan performanya dalam
menyelesaikan tugas yang diberikan.
- Pertanyaan lanjutan, selain observasi yang dilakukan pada behaviour
partisipan saat menyelesaikan tugas pertanyaan lanjutan akan membantu
untuk memahami proses berfikir, maupun tanggapan partisipan terhadap
solusi yang sedang dikembangkan.

1.8 Share The Story

Seperti namanya, tahapan ini menjadi bagian terakhir dari pendekatan design
thinking. Nantinya hasil dari penggalian permasalahan, hingga solusi yang
diajukan akan dipresentasikan kepada stakeholder-stakeholder terkait, dengan
harapan memperoleh feedback dari kegiatan yang dilakukan serta hasil yang
telah diperoleh.
Software Development Life Cycle (SDLC)

Dalam proses pengembangan perangkat lunak tentunya banyak hal yang harus
diperhatikan seperti sumber daya manusia, costing, timeline, visibilitas produk,
dan lain sebagainya. Apabila melihat produk yang dihasilkan nantinya tidak
memiliki wujud fisik, hal ini tidak membuat proses pengembangan perangkat
lunak menjadi pekerjaan yang mudah untuk dilakukan. Berdasarkan penelitian
yang sempat dilakukan oleh Standish Group dari 8380 proyek yang dilakukan
hanya 16% yang berhasil selesai tepat waktu dan tidak over budget, sedangkan
31% lainnya gagal, dan 53% sisanya melewati batasan waktu dan budget yang
telah didefinisikan.

fig 6. Standish Group - Tingkat penyelesaian produk

Tentunya banyak sekali faktor yang menyebabkan terjadinya hal tersebut. Mulai
dari scoping proyek yang tidak jelas, sumberdaya yang tidak memenuhi, hingga
proses pendekatan yang kurang tepat. Berbicara seputar pendekatan dalam
pengerjaan proyek perangkat lunak dikenal istilah yang dinamakan dengan
Software Development Life Cycle (SDLC). SDLC sendiri merupakan serangkaian
proses yang harus dipenuhi untuk menyelesaikan suatu produk, umumnya akan
dimulai dengan penggalian kebutuhan hingga proses rilis dan maintenance.
Pemilihan SDLC yang tepat menyesuaikan dengan karakteristik produk yang
akan dikembangkan menjadi langkah pertama yang harus diperhatikan. Dimana
karakteristik ini akan terbagi menjadi 4 seperti dijelaskan dalam antara lain:
 fig 7. Kuadran karakteristik perangkat lunak

- Q1 Produk yang memiliki solusi dan tujuan yang jelas. Untuk produk pada
kuadran ini akan cocok menggunakan SDLC linear seperti waterfall
- Q2 Produk dengan tujuan yang jelas namun belum memiliki solusi yang
jelas. Pada kuadran ini akan cocok menggunakan SDLC incremental
- Q3 Produk dengan tujuan serta solusi yang belum jelas. Pada kuadran ini
akan cocok menggunakan SDLC dengan pendekatan ekstrim seperti
Extreme Programming
- Q4 Produk dengan solusi yang jelas namun tujuannya belum jelas. Untuk
ini akan cocok menggunakan SDLC dengan pendekatan yang adaptif
seperti agile.

Pada kesempatan kali ini hal yang akan banyak dibahas berada pada kuadran
ke-4. Dimana suatu produk telah memiliki solusi yang terdefinisi dengan tujuan
yang berubah-ubah. Seperti proses yang banyak terjadi pada pengembangan
perusahaan rintisan, dimana produk akan banyak menyesuaikan dengan
kebutuhan pengguna, visibilitas pengembangan, serta perubahan dari business
direction yang telah disepakati.

2. Scrum
Scrum merupakan sebuah kerangka kerja yang membantu tim untuk
menyelesaikan suatu permasalahan atau mengembangkan produk dengan
kompleksitas yang tinggi, melalui pendekatan yang adaptif. Secara umum Scrum
memiliki beberapa sifat seperti ringan, sederhana untuk dipahami, dan sulit
untuk dikuasai. Perlu dicatat bila scrum bukanlah sebuah metodologi, proses,
ataupun teknik, melainkan sebuah kerangka kerja. Sehingga dalam penerapannya
sangat dimungkinkan untuk menerapkan berbagai teknik maupun proses
lainnya. Dalam penerapannya Scrum akan mengekspos ketidakefektifan proses
manajemen produk yang sudah berjalan, sehingga seiring berjalannya waktu hal
ini dapat segera diselesaikan.

Meskipun Scrum cukup fleksibel dalam penerapannya namun ada beberapa hal
yang sangat diatur, terlebih hubungan-hubungan yang terjadi seperti pembagian
role dalam team, events yang akan terjadi seiring dijalankannya Scrum, dan
artefak atau dokumen yang akan dihasilkan pada tiap event-nya.

2.1 Mengapa Scrum

Scrum merupakan sebuah kerangka kerja yang telah dikembangkan dan

digunakan sejak tahun 1990. Sejak awal penerapannya hingga saat ini efektifitas
Scrum telah terbukti oleh penerapannya dalam berbagai bidang dengan tingkat
kompleksitas permasalahan yang semakin tinggi. Sebagai sebuah kerangka kerja
Scrum memiliki nilai lebih dibanding metode maupun teknik lainnya, beberapa
diantaranya seperti:

- Adaptif, sebagai kerangka kerja Scrum tidak hanya dapat digunakan untuk
kegiatan pengembangan produk berbasis teknologi. Melainkan Scrum
juga dapat digunakan untuk menyelesaikan permasalahan pada domain
lain seperti pendidikan, layanan masyarakat, hingga proses manajemen
sumber daya manusia
- Ringan, salah satu yang menjadi esensi dari Scrum adalah tim-tim kecil
yang terdiri dari beberapa orang. Melalui Scrum nantinya tim-tim kecil ini
akan bertanggung jawab atas bagian kecil dan berkolaborasi serta
berinteraksi untuk menyelesaikan bagian besarnya.
 - Efektif, dari tim-tim kecil yang terlibat hal ini memungkinkan adanya
proses transfer knowledge yang berkelanjutan dan spesifik.

Berdasarkan nilai lebih yang telah dijabarkan beberapa permasalahan maupun

jenis pekerjaan yang umum untuk diselesaikan dengan kerangka Scrum antara
lain:

- Meneliti dan menggali potensi pasar, teknologi, dan kemampuan produk.

- Pengembangan produk.
- Pemeliharaan basis operasional produk yang dikembangkan seperti cloud
infrastructure, security, dan sebagainya.
- Mengelola dan pemeliharaan produk yang telah dikembangkan.

2.2 Scrum Team

Dalam susunan tim kecil yang telah disebutkan sebelumnya setiap orang yang
terlibat nantinya akan terbagi menjadi 3 peran diantaranya Product Owner,
Development Team, dan Scrum Master. Tim ini nantinya akan bergerak secara
pilot dan bersifat lintas fungsi. Pilot disini berarti tim memiliki otonomi
tersendiri untuk memilih jalan yang dianggap baik, dibandingkan dengan
memperoleh arahan dari luar tim. Sedangkan yang dimaksud dengan lintas
fungsi yaitu setiap tim kecil ini diharapkan telah memiliki memiliki setiap
keahlian esensial yang diperlukan dalam pengembangan sebuah produk,
sehingga tidak perlu untuk bergantung pada orang maupun tim lain.

Bentuk tim yang telah disesuaikan untuk mengoptimalkan fleksibilitas,

kreativitas, dan produktivitas, telah terbukti menjadikan tim semakin efektif
untuk menyelesaikan berbagai tipe pekerjaan. Dalam kerangka kerja Scrum
setiap produk nantinya akan dikembangkan melalui proses yang iteratif dan
bertahap. Hal ini untuk memastikan ketersediaan produk yang dapat digunakan
guna memastikan diperolehnya umpan balik sesegera mungkin.

A. Product Owner
 Secara garis besar product owner merupakan peran bertanggung jawab
untuk memaksimalkan potensi bisnis dari produk yang sedang
dikembangkan. Peran ini nantinya akan diambil oleh individu tertentu.
Peran ini merupakan satu-satunya peran yang memiliki tanggung jawab
untuk mengelola Product Backlog. Kegiatan pengelolaan ini akan
termasuk:

- Menyampaikan kepada tim isi dari product backlog secara rinci dan
jelas, serta memastikan tim mengetahui langkah apa yang harus
diambil selanjutnya.
- Mengurutkan product backlog sesuai dengan tujuan yang akan
dicapai
- Mengoptimalkan nilai bisnis dari produk yang sedang
dikembangkan

Sebagai catatan product owner merupakan satu individu bukan kelompok

maupun komite. Product owner mungkin dapat mengakomodasi maupun
mewakili keinginan dari komite, namun hak penuh untuk merubah
product backlog yang telah didefinisikan sebelumnya hanya ada pada
product owner.

Agar peran ini dapat berhasil seluruh pihak dalam tim harus menghargai
serta bekerjasama pada keputusan yang telah diambil oleh product owner.
Sebagai contoh backlog yang telah didefinisikan, terkait dengan hal ini
tidak ada siapapun baik didalam maupun diluar tim yang dapat memaksa
tim untuk mengerjakan hal diluar dari backlog yang telah didefinisikan.

B. Development Team

Seperti penyebutannya development tim adalah seluruh anggota tim yang

tergabung dan bekerja untuk mengembangkan produk pada tiap sprint
yang akan dijalankan. Secara umum tidak ada ketentuan khusus terkait
dengan keahlian yang harus dikuasai oleh masing-masing anggota tim,
menyesuaikan dengan domain produk yang sedang dikembangkan.
 Meskipun terdapat beberapa hal yang perlu diperhatikan, dan menjadi
tanggung jawab dari tim development, seperti:

- Membuat perencanaan terkait pelaksanaan sprint (sprint backlog).

- Memperhatikan kualitas pada setiap sprint yang diselesaikan.
- Melakukan perubahan yang bersifat adaptif pada perencanaan
yang telah ditentukan sebelumnya.
- Berkomitmen untuk bersikap profesional antara satu dengan
lainnya.
C. Scrum Master

Seperti penyebutannya Scrum Master bertanggung jawab untuk

memastikan jalannya Scrum pada suatu tim maupun organisasi. Hal ini
dilakukan dengan membantu setiap orang yang terlibat untuk memahami
teori dan penerapan dari kerangka Scrum. Selain itu Scrum Master juga
bertanggung jawab untuk memastikan kenaikan efektivitas dan
produktivitas dari sebuah tim melalui proses evaluasi dari penerapan
kerangka Scrum.

Untuk tim dalam organisasi Scrum Master akan memberikan bantuan

seperti:

- Memberikan pelatihan kepada anggota terkait dengan self

management dan bekerja mandiri (pilot)
- Membantu tim untuk fokus pada pengembangan produk secara
inkremental dengan hasil yang signifikan dan memenuhi target
yang telah didefinisikan.
- Memastikan segala tahapan dalam Scrum berjalan efektif dalam
lingkungan yang positif serta berada dalam timeline yang telah
didefinisikan.

Sedangkan untuk organisasi yang menerapkan Scrum secara keseluruhan,

Scrum Master akan memberikan bantuan seperti:

- Memimpin dan membimbing organisasi dalam penggunaan Scrum.

- Merencanakan implementasi Scrum di dalam organisasi.
 - Membantu anggota organisasi dan stakeholder untuk memahami
penggunaan Scrum dan pengembangan produk secara
inkremental.
- Menginisiasi perubahan dalam organisasi untuk meningkatkan
produktivitas tim.

Dan untuk product owner, Scrum Master akan memberikan bantuan

seperti:

- Membantu product owner untuk menemukan suatu pendekatan

lain untuk meningkatkan efektifitas proses penentuan tujuan dan
manajemen product backlog.
- Membantu product owner memberikan pemahaman kepada tim
terkait dengan product backlog yang telah didefinisikan.
- Membantu anggota organisasi lainnya serta stakeholder untuk
memahami bila produk akan dikembangkan secara inkremental.
- Membantu proses komunikasi antara stakeholder dengan tim.

2.3 Scrum Events

Setiap fase pengembangan produk dalam Scrum akan dikenal dengan sebutan
Sprint, dimana setiap Sprint akan kembali dibagi menjadi beberapa event yang
lebih kecil. Event-event ini sengaja dirancang untuk memastikan adanya
transparansi pada setiap proses pengerjaan serta hasil yang diperoleh.
Konsekuensi dari Scrum Event yang tidak berjalan dengan baik akan
menghilangkan kesempatan tim untuk belajar dan beradaptasi dari kesalahan
yang dibuat. Selain untuk memastikan adanya transparansi event ini akan
membentuk suatu habit positif diantara anggota tim dan mengurangi meeting
yang tidak efektif. Berikut dijelaskan dalam gambar fig 6 kerangka dari event
yang terlibat dalam Scrum.
 fig 8. Kerangka Kerja Scrum

A. Sprint

Sprint merupakan detak jantung dari jalannya kerangka Scrum, disini

dimana proses kreatif dan usaha diberikan untuk mengembangkan
produk. Untuk memastikan Sprint dapat berjalan dengan baik dari segi
durasi akan ditentukan dengan lama yang akan selalu sama, untuk
menjaga adanya konsistensi. Durasi dari Sprint yang didefinisikan akan
berbeda antara satu organisasi dengan organisasi lainnya, namun
umumnya akan berada pada rentang 1 bulan. Setiap Sprint akan dianggap
selesai setelah memenuhi tujuan yang telah ditetapkan.

Segala hal yang diperlukan untuk mencapai tujuan seperti pembuatan

Sprint backlog, Sprint planning, Daily scrums, Sprint review, hingga
retrospective akan dilaksanakan dalam Sprint. Selama menjalankan Sprint
terdapat beberapa hal yang harus diperhatikan, diantaranya:

- Tidak ada perubahan major yang berdampak pada berubahnya

tujuan dari sprint yang telah didefinisikan sebelumnya.
- Tidak ada penurunan kualitas dari produk yang dikembangkan.
- Apabila diperlukan penyesuaian dapat diterapkan pada product
backlog.
 - Besaran lingkup dari produk yang dikembangkan dapat dirubah
dengan berkomunikasi dengan product owner selama sprint
dijalankan (Sebagai bentuk pembelajaran).

Seperti yang telah dijelaskan sebelumnya bila durasi maksimal dari

sebuah sprint adalah satu bulan. Lebih dari itu maka tujuan yang akan
dicapai sebelumnya dapat meningkat beriringan dari kompleksitas
produknya. Semakin cepat durasi sprint maka anggota tim dapat belajar
lebih cepat sehingga dari sisi resiko dan cost dapat ditekan hingga titik
paling minimal.

Pembatalan Sprint yang sedang berjalan bukanlah hal yang umum

dilakukan. Namun hal ini tetap dimungkinkan apabila tujuan yang ingin
dicapai telah berubah ataupun kadaluarsa. Berkenaan dengan hal ini
hanya product owner yang memiliki otoritas untuk melakukan
pembatalan sprint.

B. Sprint Planning

Seperti namanya tahapan ini merupakan bagian paling awal dari sprint
dimana akan menjadi event yang meng-inisiasi jalannya sprint. Sprint
planning haruslah dilakukan secara kolaboratif dengan melibatkan
seluruh tim scrum yang terlihat. Untuk memastikan sprint planning dapat
berjalan dengan efektif maka, product owner harus memastikan setiap
pihak yang hadir telah memahami product backlog yang telah
didefinisikan. Serta bagaimana memberikan prioritas pada item yang
paling penting, dan meng-incorporate item tersebut pada tujuan
pengembangan produk.

Secara garis besar perencanaan yang dibuat haruslah memuat beberapa

hal, seperti :

- Mengapa sprint ini harus dijalankan?

- Apa saja yang dapat dilakukan pada sprint kali ini?
- Bagaimana menyelesaikan hal yang telah didefinisikan dalam
sprint?
 Tidak terkecuali didefinisikan juga sprint goal. Sprint goal merupakan
tujuan dari dijalankannya sprint dimana nantinya akan didefinisikan pada
tahapan sprint planning dengan mempertimbangkan product backlog.

C. Daily Scrum

Daily scrum merupakan kegiatan yang dilakukan secara periodik selama

15 menit setiap harinya oleh development team. Pada kegiatan ini kurang
lebih sama dengan sprint planning namun lingkupnya lebih kecil, dimana
nantinya masing-masing anggota yang terlibat akan menjabarkan hal yang
akan dilakukan selama sehari kedepan, menyampaikan pencapaian yang
berhasil diraih pada hari sebelumnya, dan kendala yang dialami. Kegiatan
ini akan membantu tim untuk mengetahui lebih dini permasalahan yang
mungkin terjadi dan memberikan penangan lebih cepat untuk mencegah
terjadinya hal yang tidak diinginkan.

D. Sprint Review

Sprint review dilakukan di akhir sprint untuk mengetahui bagaimana hasil

dari sprint yang telah dilakukan dan mengetahui apakah perlu untuk
melakukan penyesuaian pada product backlog yang telah didefinisikan.
Kegiatan ini dilakukan dengan mempresentasikan hasil yang telah dicapai
pada key stakeholder dan tentunya berdiskusi terkait dengan langkah
selanjutnya untuk memenuhi goals yang ingin dicapai.

Dikarenakan kegiatan ini masih berada dalam lingkup pekerjaan dalam

pelaksanaannya seharusnya tidak membatasi agenda hanya pada sesi
presentasi saja. Untuk durasi dari kegiatan ini maksimal 4 jam untuk
sprint dengan durasi 1 bulan, dan akan lebih cepat bila durasi sprint yang
dijalankan jauh lebih pendek.

E. Sprint Retrospective

Kegiatan ini kurang lebih sama dengan sprint review, yang membedakan
ada pada aspek yang disoroti. Pada sprint retrospective tim akan lebih
banyak mendiskusikan bagaimana tim menjalankan scrum, dan
 bagaimana mencapai proses kerja yang lebih efektif guna meningkatkan
kualitas dari sprint yang akan dijalankan kedepannya.

2.3.1 Scrum Artifacts

Scrum Artifact akan merepresentasikan pekerjaan yang akan dilakukan atau

manfaat yang akan diraih. Artifacts ini dibuat dan dirancang dengan tujuan
memberikan transparansi informasi kepada tim. Terdapat 3 artifacts yang
didefinisikan bersamaan dengan komitmennya. Hal tersebut diperlukan untuk
memastikan artifacts yang ada dapat memberikan informasi serta menentukan
tujuan, terhadap pencapaian maupun proses yang dijalani kedepannay. Ke-3
artifacts tersebut antara lain

A. Product Backlog

Bagian ini merupakan list dari apa yang harus dilakukan dalam proses
pengembangan suatu produk. Bagian ini juga yang akan menjadi
satu-satunya sumber informasi terkait dengan pekerjaan yang harus
diselesaikan oleh tim. Dalam pembuatannya product backlog tidak akan
pernah selesai. Hal tersebut dapat tercapai atas dasar pembaharuan yang
diperoleh dari setiap sprint yang telah dilakukan.

Berdasarkan artifact ini product owner akan membantu development tim

untuk memilih dan menyusun item-item yang kemudian akan dibawa ke
dalam sebuah sprint. Melalui pemberian pemahaman terkait dengan
sumber daya yang dimiliki, timeline yang sedang dijalani, serta
konsekuensi yang akan dihadapi.

Komitmen pada artifact ini disebut dengan “product goal”. Product goal
akan mendefinisikan kondisi di masa yang akan datang dengan asumsi
produk yang dikembangkan akan sesuai dengan tujuan yang dicapai. Masa
depan yang dimaksud dalam bagian ini merupakan rencana jangka
panjang. Secara tidak langsung Product Goals akan ada pada tiap item
yang didefinisikan ada Product Backlog (the what).
B. Sprint Backlog

Sprint backlog merupakan sebuah kesatuan dari sprint goal (the why),
item yang diambil dari product backlog, serta rencana yang disusun untuk
mencapai tujuan tersebut (the how). Berbeda dengan artifact sebelumnya
sprint planning akan didefinisikan oleh development teams untuk mereka
sendiri. Meninjau dari tingkat pemahaman masing-masing anggota tim
yang terlibat sehingga perencanaan dapat dibuat lebih realistis dengan
effort yang lebih terukur.

Komitmen pada artifact ini disebut dengan “sprint goal”. Sprint goal
merupakan tujuan yang haru dicapai dalam sebuah pelaksanaan sprint
yang juga didefinisikan oleh development team. Bagian ini juga
didefinisikan dalam kegiatan sprint planning, dimana nantinya akan
menjadi guideline bagi tim pengembang selama menjalankan suatu sprint.

C. Increment

Increment bila diibaratkan seperti milestone yang haru dicapai untuk

memenuhi product goal. Setiap increment yang berhasil diselesaikan akan
menjadi pendukung untuk increment yang akan diselesaikan kedepannya.
Masing-masing increment akan berupa bagian kecil dari produk akhir
yang dituju, dengan catatan tiap increment yang dikembangkan pada
setiap sprint diharuskan untuk dapat digunakan.

Dalam pelaksanaan sebuah sprint dapat dimungkinkan untuk

mengembangkan beberapa increment. Akumulasi dari increment yang
telah selesai dikembangkan akan menjadi representasi dari tahapan
scrum yang dilakukan secara inkremental.

Komitmen pada artifact ini adalah “definition of done”. Dikarenakan

increment merupakan bagian kecil dari produk final yang dikembangkan
maka perlu sebuah format yang menyatakan sebuah increment selesai
dikembangkan. Hal ini akan membantu tim untuk memberikan batasan
sehingga sprint tidak berjalan terlalu lama.
 [Link]

Git adalah salah satu dari yang sistem yang disebut dengan version control system
atau yang biasa disebut dengan VCS. VCS memungkinkan kita untuk melacak sejarah
dari perubahan yang sudah kita lakukan. Kita dapat menggunakan VCS sebagai individu
atau sebagai tim untuk berkolaborasi mengerjakan sebuah proyek. Dengan
menggunakan VCS, kita dapat melihat :

1. Perubahan apa yang dilakukan ?

2. Siapa yang merubah ?
3. Kapan perubahan tersebut dilakukan ?
4. Kenapa perubahan tersebut dilakukan ?

Git lebih spesifik lagi merupakan contoh dari distributed version control system
(DVCS). DVCS banyak dipakai pada project sumber terbuka, dan perangkat lunak
komersial. selain DVCS, ada juga yang biasa disebut dengan centralized version control
system. Penggunaan versi sentral ini tidak dimintai banyak programmer karena
mengharuskan kita untuk selalu terhubung ke repository pusat secara terus menerus.
Sedangkan dengan versi distribusi, programmer tidak harus terhubung ke repository
pusat. sehingga memungkingkan programmer untuk bekerja dari mana saja, dan
berkolaborasi dari banyak zona waktu.

3.1 Mengapa Git

Berdasarkan survey dari website stackoverflow, lebih dari 70% programmer

menggunakan git. Menjadikan git adalah VCS yang paling sering digunakan. Ini
dikarenakan Git memiliki benefit yang sangat banyak untuk individu, tim maupun untuk
bisnis.
1. Git memungkinkan developer untuk melihat semua timeline perubahan, dan
progress dari sebuah project dalam satu tempat. Ketika developer melihat
history sebuah project, maka sebuah developer dapat memahami konteks yang
mereka butuhkan untuk memahami project tersebut dan mulai berkontribusi
2. Developers dapat bekerja dari zona waktu yang berbeda, dan dimana saja tanpa
perlu terkoneksi dengan internet secara terus menerus. dengan adanya fitur
branches, developer dapat membuat perubahan yang aman untuk masing-masing
fitur yang diakerjakan
3.2 Repository
Repository adalah istilah untuk project yang menggunakan git. Sehingga
merupakan kumpulan dari koleksi folder atau file, termasuk setiap perubahan yang
terjadi pada sebuah file. Untuk menjelajah setiap perubahan yang ada, kita perlu
berpindah commit. Commit akan menyimpan setiap perubahan yang sudah dilakukan
oleh developer. Setiap commit dapat dikelompokan dan dipecah dengan menggunakan
branches. Dengan menggunakan branch kita dapat memecah sebuah commit menjadi
beberapa cabang, sehingga developers dapat fokus hanya pada fitur yang diakerjakan.

Dengan repository, developer tidak perlu bingung untuk mengerjakan project,

karna repository membuat project menjadi terorganisir dan aman. Developer dengan
cukup mudah untuk memperbaiki bugs, atau membuat fitur baru tanpa perlu
memikirkan apakah akan merusak alur development.

3.3 Basic Git Command

Untuk menggunakan git, developer dapat menggunakan beberapa command
yang cukup umum untuk digunakan. Git command ini dapat dijalan langsung di terminal
apabila sudah menginstall git sebelumnya. atau dapat menggunakan github desktop
atau gitkraken.

● git Init
git init digunakan untuk menginisialisasi git repository pada sebuah
folder. Dengan menggunakan git init, akan terdapat satu subfolder yang
tersembunyi. folder ini digunakan untuk menyimpan data structure yang
digunakan untuk version control
● git Clone
Git clone digunakan untuk membuat local copy dari sebuah project yang
telah ada di server. dengan menggunakan git clone, semua project file, history dan
branch akan ter-copy.
● git add
Menambahkan file atau folder yang nantinya ingin kita simpan dengan
command git commit
● git status
Menampilkan perubahan file atau folder yang belum ditambahkan,
dirubah atau yang sudah ditambahkan
● git branch
menampilkan branch saat ini
● git merge
Menggabungkan kedua branch menjadi satu branch, berdasarkan commit
terakhir dari suatu branch.
 ● git pull
mensinkronkan atau memperbarui repository lokal sesuai dengan
repository remote

● git push
update remote repository dengan commit yang sudah ada pada local.
● git stash
git stash dapat digunakan jika anda ingin berpindah branch tetapi
masih ada file yang belum di-commit karena belum selesai misalnya), anda
dapat menyimpan perubahan yang Anda buat dan membuat folder kerja Anda
bersih.

3.4 Instalasi dan Konfigurasi awal git

Untuk instalasi pada linux, cukup memasang git melalui package
manager. command yang dapat dijalankan apabila menggunakan distro
keluarga debian maka :
sudo apt-get install git
Sedangkan pada fedora kita dapat menggunakan :
yum install git

Instalasi pada windows agak berbeda. karena kita harus

mendownload dulu software git yang nantinya akan membantu kita untuk
melakukan instalasi git . Software tersebut dapat didownload pada url
[Link]. Pada windows juga disarankan memasang windows terminal
untuk mempermudah penggunaan git pada terminal. Sedangkan pada Mac,
biasanya git sudah terinstall. namun apabila belum, maka dapat melakukan
pemasangan menggunakan brew.

Apabila sudah terpasang maka kita dapat melakukan command git

pada terminal. Berikut adalah contoh git yang berhasil terpasang pada
komputer.
 Langkah selanjutnya adalah melakukan konfigurasi akun. Ini
bertujuan agar ketika membuat commit, maka akan tercatat siapa user
yang melakukan perubahan.

3.5 Repository Management

Untuk bekerja sama dengan menggunakan git, maka developer wajib

memiliki remote repository. Remote repository ini gunanya untuk menyimpan
keseluruhan repository, yang nantinya digunakan untuk developer lain untuk
melakukan sync. Umumnya, penggabungan branch seperti diagram diatas, tidak
dilakukan pada local machine melainkan dilakukan pada remote repository.
Remote repository management ada beberapa macam, seperti github, gitlab,
bitbucket dsb. Secara umum untuk sebuah project sumber terbuka, mereka
menggunakan github sebagai remote repository management. Banyak sekali
fitur-fitur pada remote repository management seperti github yang dapat kita
gunakan, seperti, membuat issue, pull request (merge request pada gitlab),
github action untuk CI/CD dan masih banyak lagi.
4. Collaborative Using Git
Git memungkinkan kita untuk membuat sebuah versi pada sebuah aplikasi
kita. Namun kita juga dapat menggunakan git untuk bekerja bersama dengan
banyak developer. Terlebih karena git bertipe distributed, yang mana tidak
mengharuskan developer untuk terkoneksi ke remote repository. memungkinkan
untuk bekerja secara paralel, tanpa perlu takut mengganggu proses flow developer
yang lain. Lebih jauh lagi, dengan menggunakan git, kita juga dapat membuat
implementasi devops. Nantinya materi devops akan diberikan pada akhir dari
pelatihan ini.

4.1 Branch And Commit Naming Conventions

Saat membuat branch dan commit, ada baiknya menggunakan standard yang
dapat disetujui oleh semua developer. Dengan menggunakan standard yang sama,
maka developer akan lebih mudah untuk memahami dan berkolaborasi. Standard
yang digunakan bisa berbeda-beda tergantung dari perusahaan atau bahkan
repository masing - masing. Maka biasanya terdapat juga file dengan nama
README, dengan extension .md. File ini umumnya berisikan tentang penjelasan
code dari sebuah repository. namun ada beberapa repository yang memberikan
penjelasan tentang how to contribute pada file ini.

4.1.1 Commit Message

Commit message yang baik, haruslah menggambarkan
keseluruhan perubahan yang terjadi. Selain itu ditambahkan pula
jenis perubahan yang dilakukan. Misal feature, bugfix, refactor dll.
Salah satu contoh dari penggunaan :
● fix: correct minor typos in code
● feat: allow provided config object to extend other
configs
● refactor: drop support for Node
● Feat (feature) harus ada perubahan untuk menambahkan
fitur atau pustaka baru.
● Fix adalah perubahan yang membenahi sebuah bug.
● Refactor adalah perubahan yang tidak menambah fitur dan
tidak memperbaiki bug, melainkan hanya merubah struktur
dari kode atau update dependency.

4.1.2 Branch Naming

Untuk penamaan branch, terdapat berbagai macam jenis.
Seperti yang dijelaskan di awal, biasanya memang tergantung
dari kebijakan masing-masing repository. berikut ada beberapa
contoh dari penamaan branch:
 ● [Nama]/[commit message]
adam/add-comment-section
● [type]/[commit message]
feature/correct-minor-typos
● [type]/[domain]/[commit message]
fix/home/correct-minor-typos
● [domain]/[type]/[commit message]
admin-page/hotFix/add-comment-section
4.2 Git Flow

Git Flow adalah model percabangan untuk Git, dibuat oleh Vincent Driessen.
Model ini cukup menarik banyak perhatian karena sangat cocok untuk kolaborasi
dan scaling tim developer. Git Flow memiliki beberapa kelebihan :

1. Parallel Development
Salah satu kelebihan dari Git Flow adalah membuat pengembangan
paralel menjadi sangat mudah, dengan memisahkan pengembangan fitur
yang baru dari pekerjaan yang sudah selesai. Pengembangan baru (seperti
fitur dan perbaikan hotfixes) dilakukan di branch feature, dan hanya
digabungkan kembali ke branch master ketika developer puas bahwa kode
siap untuk dirilis. Ketika kita diminta untuk mengerjakan tugas yang lainnya
secara mendadak, yang perlu kita lakukan hanyalah melakukan perubahan
dan kemudian membuat branch feature baru untuk tugas baru tersebut.
Ketika tugas itu selesai, cukup periksa cabang fitur asli Anda dan Anda dapat
melanjutkan di mana Anda terakhir mengerjakannya.

2. Collaboration
Branch feature juga memudahkan dua atau lebih developer untuk
berkolaborasi pada fitur yang sama, karena setiap branch feature adalah
sandbox di mana satu-satunya perubahan adalah perubahan yang diperlukan
agar fitur baru berfungsi. Hal ini membuatnya lebih mudah untuk melihat dan
mengikuti apa yang dilakukan setiap kolaborator.

3. Release Staging Area

Saat pengembangan baru selesai, kode tersebut akan digabung
kembali ke branch develop, yang merupakan area staging untuk semua fitur
lengkap yang belum dirilis. Jadi ketika rilis berikutnya bercabang dari
pengembangan, secara otomatis akan berisi semua hal baru yang telah
selesai.

4. Support for Emergency Fixes

Git Flow mendukung branch hotfix atau branch yang dibuat dari rilis
 yang diberi tag. Kita dapat menggunakan branch ini untuk membuat
perubahan darurat yang aman dalam artian bahwa perbaikan terbaru hanya
akan berisi perbaikan darurat. Tidak ada risiko secara tidak sengaja kode
tersebut bergabung dalam pengembangan baru pada saat yang bersamaan.

4.3 Cara kerja

Untuk dapat bekerja bersama dengan git, developer akan memanfaatkan
branch. dengan menggunakan branch, kita dapat membagi bagi branch menjadi
seperti pada diagram berikut.

fig 7. Diagram git

Dapat dilihat pada figure 7, master merupakan branch utama pada repository
tersebut. branch master biasanya merupakan versi release dari sebuah project.
Selanjutnya adalah branch hotfixes. Branch hotfixes digunakan untuk memperbaiki
bugs yang terdapat pada branch master.
 fig 7.1 Diagram git

Branch feature branches adalah percabangan dari branch develop, pada

branch tersebut kita menambahkan fitur baru dan fitur serta perbaikan yang telah
selesai digabungkan kembali ke branch develop saat siap dirilis.
 fig 7.2 Diagram git

Ketika saatnya untuk membuat rilis, kita akan membuat satu branch baru
yaitu release branch dimana branch tersebut merupakan salah satu cabang dari
branch develop.
 fig 7.3 Diagram git

Kode di branch release akan di deploy pada test environment (staging),

kemudian diuji dan masalah apa pun yang terlihat pada staging akan diperbaiki
langsung di branch release. Deploy -> Test -> Fix -> Redeploy -> Tes Ulang, siklus
ini akan berlanjut hingga kita puas bahwa rilis tersebut cukup baik untuk dirilis ke
user.

Saat rilis selesai, cabang rilis digabungkan ke master dan ke develop juga,
untuk memastikan bahwa setiap perubahan yang dibuat di cabang rilis tidak hilang
secara tidak sengaja oleh pengembangan baru.
 fig 7.4 Diagram git

Branch master hanya digunakan untuk melacak kode yang sudah dirilis.
Satu-satunya commit yang diperbolehkan untuk branch master adalah gabungan
dari branch release dan branch hotfix. Cabang hotfix digunakan untuk membuat
perbaikan darurat.
Cabang-cabang pada figure diatas adalah percabangan langsung dari release
tag di branch master, dan ketika selesai digabungkan kembali ke master dan
develop untuk memastikan bahwa perbaikan terbaru tidak hilang secara tidak
sengaja saat rilis reguler berikutnya terjadi.

4.4 Pull Request

Pull request / Merge request adalah fitur dari repository management yang
digunakan untuk menggabungkan dua branch menjadi satu. Namun dengan fitur ini,
kita bisa melakukan review terhadap branch yang akan digabung. Kita dapat
meng-assign orang untuk melakukan review dan berdiskusi. Reviewer dapat
 menyetujui perubahan dan melakukan penggabungan ataupun menolak dan
meminta perubahan pada kode. Dalam memberikan komentar, komentar tidak
terbatas pada satu pull request saja, tapi juga bisa dilakukan pada setiap baris kode.
Kita juga dapat melihat perbedaan code kedua branch pada pull request. Lebih
lanjut lagi, kita juga bisa melakukan unit test dengan menggunakan fitur CI, sehingga
apabila kode belum lulus test, meskipun sudah disetujui oleh reviewer, kode tidak
dapat digabung karena masih memiliki test yang salah.

Tugas Dan Proyek Pelatihan

1. Design Thinking
Berdasarkan persona dibawah ini

a. Tentukan permasalahan yang akan diselesaikan.

 b. Buat research guideline untuk memperoleh pemahaman terkait dengan permasalahan tersebut.
c. Lakukan desk research berkaitan dengan solusi yang telah ada.
d. Rumuskan solusi yang akan dikembangkan dan buat 8 sketsa low fidelity.

Link Referensi Modul Pertama

1. Design Thinking – IDEO U

2. Design Thinking 101 ([Link])
3. Design thinking for innovation: Composition, consequence, and contingency
4. Abductive Reasoning. Yoel Sumitro | Medium
5. Personas Make Users Memorable for Product Team Members ([Link])
6. Desk research: the what, why and how ([Link])
7. CONDUCTING IN-DEPTH INTERVIEWS: A Guide for Designing and Conducting In-Depth
Interviews for Evaluation Input ([Link])
8. Journey Mapping 101 ([Link])
9. What is Scrum
10. Scrum framework
11. [Link]
12. Guide to do the Scrum Planning
13. Scrum Artifacts

Link Pertanyaan Modul Petama

Bahan Tayang

Link room Pelatihan dan Jadwal live sesi bersama instruktur

Penilaian

Target Penyelesaian Modul Pertama

14 July 2021