Metode SCRUM pada Pendekatan Rekayasa Perangkat Lunak AGILE

SCRUM adalah salah satu metode rekayasa perangkat lunak dengan menggunakan prinsip-prinsip pendekatan AGILE, yang bertumpu pada kekuatan kolaborasi tim, incremental product dan proses iterasi untuk mewujudkan hasil akhir.

Scrum sendiri bukan satu-satunya metode yang menggunakan pendekatan AGILE. Mungkin kita juga pernah mendengar metode Extreme Programming (XP) yang juga menggunakan pendekatan AGILE dalam rekayasa perangkat lunak. Masing-masing metode memiliki fokus atau penekanan yang berbeda yang tentu saja dapat dikombinasika untuk menghasilkan proses yang optimal. 

Jika metode XP lebih berfokus kepada framework yang memberikan kerangka mengenai praktek-praktek teknis dalam membangun program menggunakan pendekatan AGILE, seperti para programmer yang diharapkan untuk bekerja pada station yang sama sehingga dapat menggunakan library yang sama dan lain sebagainya. 

Sedangkan metode SCRUM lebih berfokus kepada project management yang memberikan kerangka kerja bagaimana mengelola sebuah proyek yang berbasis AGILE. Metode ini memberikan pola "ceromony" apa saja yang harua dilaksanakan, "role" apa saja yang ada dalam SCRUM termasuk tugas yang harus diperankannya dan masih banyak hal lainnya. Tulisan ini akan mencoba untuk mengupas metode SCRUM ini.

Di dalam setiap iterasi scrum, semua anggota tim saling berkolaborasi untuk menyelesaikan setiap incremental product yang telah direncanakan dan disepakati bersama. Dalam proses, setiap iterasi juga akan melakukan kegiatan analisis, merencanakan desain dan selanjutnya program siap untuk dikembangkan. Setelah program selesai, program juga akan diuji melalui proses testing yang telah direncanakan oleh tim, sehingga akhirnya program tersebut menjadi sebuah incremental product yang siap untuk di-deploy dan di-integrasi-kan dengan semua program yang telah dibuat sebelumnya. 

Semua kegiatan diatas akan dilakukan oleh tim dengan konsep self-organizing, artinya semua anggota tim akan bekerja sama untuk mengelola kerja mereka sesuai dengan kesepakatan mereka. Mereka bertanggung jawab untuk menghasilkan incremental product dengan membagi tugas secara bersama dan berdiskusi tanpa ada hirarki. Seorang yang berpengalaman testing, sangat dimungkinkan untuk berkonstribusi ditahap analisa dan desain. Atau seorang programmer akan membantu aktifitas testing. Secara sederhana, anggota tim akan merencanakan tugas secara bersama dan melakukannya secara bersama sebagai sebuah kolaborasi tim.

ROLE (Fungsi) dalam Scrum

Scrum akan berjalan pada tim dengan jumlah orang yang tidak terlalu banyak, kira-kira berjumlah lebih kurang 7 orang. Setiap orang dalam tim scrum akan memiliki role atau fungsi tertentu. Dan hanya dikenal 3 role atau fungsi dalam menjalankan proyek berbasis scrum :

Product Owner

Product owner adalah orang yang bertanggung jawab terdapat definisi produk yang akan dibuat. Dengan kata lain, product owner adalah tim yang menciptakan "APA" yang harus dimiliki oleh aplikasi. Mereka bertugas untuk menuliskan semua item yang harus dimiliki oleh aplikasi. Item-item tersebut memiliki "story" yang akan disampaikan oleh product owner. 

Product owner, juga bertanggung jawab untuk memberikan prioritas kepada setiap story, sehingga seluruh anggota tim SCRUM mengetahui apa yang sebaiknya harus dibuat pada setiap iterasi. 

Sebagai representatif dari pengguna, product owner akan menjadi kunci apakah hasil dari sebuah iterasi dapat di-deploy atau diimplementasikan.

Scrum Master

Ini adalah seseorang yang akan berperan sebagai fasilitator dalam setiap proses atau ceremony yang ada dalam scrum seperti layaknya seorang project manager. 

Scrum Development Team

Tim inilah yang akan setiap iterasi menghasilkan suatu incremental product yang telah disepakati bersama. Mereka bertanggung jawab untuk membuat program dan menguji program tersebut(testing) sehingga hasil dari setiap iterasi dapat digunakan dan diimplementasikan.

Tim ini harus mengatur dirinya sendiri (self-organized), dari proses analisa, design, coding dan akhirnya diujikan. Mereka harus berkolaborasi bersama sehingga keluaran dari setiap iterasi adalah sebuah program yang benar-benar teruji dan sesuai dengan harapan product owner.

Proses Membangun Incremental Product

Product Backlog Item

Adalah list dari 'user story' untuk menggambarkan fungsi atau feature apa saja yang harus tersedia di dalam aplikasi. Product Owner akan membuat user story untuk selanjutnya dibawa dalam sebuah diskusi bersama untuk melihat lebih detail terkait dengan skala prioritas dan acceptance criteria.

Beberapa contoh user story pada Product Backlog Item

• Jika user mencoba 3 kali password secara salah, maka user akan di lock.
• Menghasilkan report nilai semester mahasiswa.
• Report alokasi ruangan kelas dan mampu memberikan alert sehingga jadwal kuliah tidak konflik dengan jumlah ruangan yang ada.

Seluruh Story Form akan didiskusikan untuk selanjutkan diurutkan sebagai Product Backlog Item, sekaligus sebagai urutan incremental product pada setiap iterasi atau sprint. Di dalam scrum, kita akan lebih sering menggunakan istilah sprint dibandingkan iterasi.

Sprint Backlog

Adalah sebuah hasil diskusi bersama berdasarkan skala prioritas untuk melakukan mapping setiap Product Backlog Item(PBI) ke jadwal sprint. Dengan adanya Sprint Backlog, maka semua member dalam scrum akan mengetahui apa target pada setiap sprint atau setiap iterasi. Sangat dimungkinkan sebuah PBI akan dipecah menjadi 2 bagian atau lebih menjadi item yang lebih kecil sehingga dapat dikerjanan dalam sebuah sprint atau iterasi. Pemecahan ini tetap menjalankan prinsip bahwa item tersebut adalah independent dan testable.

Sprint Tasks

Team akan melakukan identifikasi pada setiap sprint backlog dan berdiskusi bersama tugas-tugas apa saja yang harus dilakukan pada setiap sprint atau iterasi. Misal, telah ditetapkan bahwa kita akan membuat report nilai semester siswa pada sebuah sprint/iterasi tertentu. Selanjutnya kita mulai melakukan identifikasi tugas-tugas yang harus dikerjakan agar kita mampu menyesaikan iterasi tersebut. Contoh tugas-tugas yang harus kita lakukan dalm iterasi tersebut adalah membuat form report, menganalisa database, mendesain bagaimana layar user untuk keperluan input, melakukan testing dan lain-lain.

Aktifitas Scrum

Kita juga dapat menyebut aktifitas scrum ini sebagai Scrum Ceremony. Sebagaimana di awal tulisan ini, scrum berfokus kepada manajemen proyek yang didalamnya terdapat framework tentang bagaimana mengelola dan menjalankan proyek rekayasa perangkat lunak menggunakan prinsip agile.

Gambar di atas, menunjukan bagaimana proses rekayasa perangkat lunak menggunakan metode scrum akan berlangsung. Dimulai dengan kegiatan untuk melakukanidentifikasi backlog (atau user story) dan selanjutnya kegiatan akan bergerak dari satu iterasi ke iterasi selanjutnya guna membangun incremental product. Di dalam setiap iterasi, terdapat juga kegiatan harian yang akan dilakukan oleh semua anggota tim scrum.

Backlog Refinement Meeting

Semua proyek perangkat lunak selalu memiliki item yang akan digunakan untuk membantu pengguna aplikasi dalam menjalankan kesehariannya. Meeting ini digunakan bersama oleh seluruh tim scrum untuk mengetahui feature atau fungsi apa saja yang akan terdapat pada aplikasi yang sedang dikembangkan. Hasil dari meeting adalah sebuah Product Backlog Item. 

Meeting ini harus dilakukan sebelum tim mulai bekerja pada tahapan iterasi atau sprint. Setiap list akan direview apakah scope-nya masih terlalu luas atau perlu di-split atau dibagi-bagi lagi menjadi potongan yang lebih kecil, sehingga dapat dengan mudah untuk di-mapping ke dalam suatu iterasi/sprint. 

Tim juga akan berdiskusi tingkat kesulitan dan prioritas dari masing-masing item, sehingga tim bisa membuat schedule yang tepat untuk melakukan mapping mengenai item yang akan dikerjakan lebih dahulu sehingga tim memiliki perencanaan item apa saja yang akan dikerjakan untuk setiap iterasi.

Dan tentu saja, pada tahap ini tim mencoba untuk menyamakan persepsi mengenai acceptance criteria yaitu kriteria apa saja untuk mengatakan bahwa iterasi dan incremental product yang dihasilkan adalah sesuai harapan.

Sprint Planning Meeting

Meeting ini dijalankan pada hari pertama pada setiap sebuah iterasi akan dimulai. Dengan menggunakan Product Backlog Item yang telah ditetapkan pada saat Backlog Refinement Meeting, maka tim sudah mengetahui feature apa yang akan mereka selesaikan pada iterasi. Dan tim mulai melakukan identifikasi tugas atau task apa saja yang harus dikerjakan guna menyelesaikan feature yang telah ditetapkan pada setiap iterasi atau sprint. Selanjutnya tim mulai membagi tugas atau task tersebut kepada seluruh anggota scrum.

Daily Scrum 

Kini tiba saatnya sebuah iterasi dimulai. Semua anggota tim scrum sudah bersepakat feature apa yang akan dihasilkan pada iterasi ini. Mereka juga sudah memiliki rencana kolaborasi dan setiap anggota tim telah sepakat dengan tugasnya masing-masing. Setiap hari, semua anggota tim akan melakukan meeting lebih kurang 20 menit dan masing-masing anggota harus melaporkan 3 point. Point-point tersebut adalah apa yang telah dilakukan kemarin, apa yang akan dilakukan hari ini dan kendala yang dihadapi untuk menyelesaikan tugas. Meeting ini didesain untuk dilakukan secara singkat, jika ada sesuatu yang detail, anggota tim bisa berdiskusi lebih detail diluar meeting ini dengan orang-orang terkait.

Setiap harinya, sprint backlog akan selalu mereflekasikan status dari semua tugas yang telah ditetapkan pada setiap iterasi. Semua tugas yang telah diidentifikasi, akan dimasukkan ke dalam kolom "Not Started". Selanjutnya tugas-tugas tersebut akan mengalami progress dan didiskusikan dalam daily meeting.

Sprint Review Meeting

Kini tiba saatnya akhir dari sebuah sprint, seluruh tim akan berdiskusi lagi untuk melakukan final review untuk menyatakan apakah mereka telah berhasil memenuhi ekspektasi yang ditetapkan oleh product owner. Product Owner akan menjadi orang kunci yang akan menentukan apakah incremental product yang telah dibuat dalam sprint tersebut dapat diterima atau dinyatakan gagal sehingga perlu adanya diskusi lanjutan untuk menentukan langkah selajutnya. 

Meeting ini tidak lagi berdiskusi mengenai status, incremental product yang telah dikembangkan selama satu periode sprint akan didemokan dan diujikan sebagai final review untuk menyatakan bahwa  sebuah user-story atau sebuah product backlog item telah benar-benar selesai sesuai dengan target sprint yang telah disepakati.

Jika sebuah user story telah dinyatakan gagal di dalam sebuah iterasi, tim bisa saja memutuskan untuk menunda terlebih dahulu user-story ini, untuk selanjutnya akan ditinjau kembali pada iterasi mendatang. Atau tim juga bisa menentukan, jika user-story ini akan dilakukan kembali pada iterasi selanjutnya sehingga jadwal user-story yang telah direncanakan sebelumnya akan ditunda terlebih dahulu, untuk menyelesaikan user-story yang masih belum yang belum berhasil.

Sebagaimana karakteristik dari metode scrum, tim scrum adalah self-organization, sehingga tim yang akan menentukan langkah yang paling tepat bagi mereka.

Sprint Restrospective Meeting

Ini adalah meeting untuk melakukan instropeksi dengan melihat kembali perjalanan selama sprint berlangsung. Diskusi lebih berfokus kepada upaya untuk membangun sebuah timyang efektif dan optimal guna menyelesaikan sprint-sprint berikutnya. Mungkin perlu perbaikan dalam pola komunikasi antar tim, atau terdapat sebuah proses yang mungkin bisa dihilangkan karena justru menyulitkan tim tetapi efek terharap hasil akhir tidak sesuai dengan effort yang dikeluarkan atau banyak hal lainnya.

Dengan adanya meeting ini, diharapkan hubungan antar tim akan semakin baik, kolaborasi menjadi lebih efektif dan optimal serta pengetahuan akan product akan semakin bertambah sehingga memudahkan sprint-sprint berikutnya.

--------

Link:

Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 

Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi

Semoga Bermanfaat

Singapore, Januari 2014

"Dipublish di atas MRT dalam perjalanan pulang dari kantor ke rumah. Ditulis/dipersiapkan kira-kira seminggu lebih, guna mengisi waktu kosong di atas MRT"

Rekayasa Perangkat Lunak Melalui Mendekatan AGILE

Dalam beberapa kasus pengembangan aplikasi perangkat lunak, mungkin kita pernah mengalami situasi sebagai berikut.

Kita berharap user atau calon pengguna aplikasi mampu meng-artikulasikan dan menggambarkan dengan tepat ekspektasi yang dia harapkan dari aplikasi yang sedang dikembangkan. Kemudian orang IT mencoba untuk meng-interpretasikan itu sebagai user requirement dan mulai men-desain. Dalam beberapa kasus, terjadi gap yang lebar antara tim IT dengan kemampuan imajinasi user, sehingga tim IT terkadang menggunakan asumsi berdasarkan pengalaman pribadinya. Akhirnya, desain selesai dan pembuatan program berjalan sesuai desain dan tiba saatnya bagi tim IT untuk menunjukkan hasil kerjanya. Dan yang terjadi, user mendapat banyak hal yang diluar bayangannya dan yang kadang justru menjadi tidak puas dengan hasilnya.

Situasi di atas telah menjadi sesuatu yang sering terjadi saat ini, karena begitu banyaknya pilihan teknologi yang tersedia dan semakin kompleknya proses bisnis di sebuah enterprise. Orang-orang bekerja pada industri IT kini memiliki kesulitan untuk selalu mengejar kecepatan perubahan yang muncul dari kemajuan dan banyaknya pilihan yang tersedia. Sedangkan pengguna teknologi, akan semakin mengalami kesulitan untuk meng-artikulasi dan berimajinasi untuk membuat sebuah user requirement apalagi jika aplikasi yang dibangun adalah sebuah proses dari titik nol.

Kini pada para praktisi rekayasa perangkat lunak mencoba untuk mencari semacam framework (kerangka kerja) yang sesuai untuk mengakomodasi situasi di atas sehingga proyek dapat berjalan dan menghasilkan sesuatu seperti yang diharapkan oleh user dan orang IT dapat menurunkan resiko akan kegagalan sebuah proyek.

Tulisan ini mencoba membuka sedikit wawasan mengenai pendekatan baru dalam rekayasa perangkat lunak. Cerita akan dimulai dengan melihat salah satu pendekatan rekayasa lunak yang sering disebut sebagai waterfall model dan telah digunakan selama cukup lama dalam rekayasa perangkat lunak. Dan kita mencoba melihat beberapa point sehingga waterfall model tidak selamanya bisa menjadi "satu obat mujarab untuk semua jenis penyakit". Setelah itu, baru kita mencoba melihat salah satu "obat alternatif" yang dapat kita pergunakan dalam rekayasa perangkat lunak, yang saat ini lebih dikenal dengan metode "AGILE".

Model Rekayasa Perangkat Lunak "Waterfall"

Hampir beberapa dekade, kita telah mengenal dan menerapkan pengembangan atau rekayasa perangkat lunak menggunakan pendekatan warerfall. Pendekatan ini secara sederhana membagi proses rekayasa perangkat lunak menjadi lebih kurang 5 tahapan inti.

• Analisis, adalah tahapan dimana tim IT berdiskusi dengan user untuk mendapatkan kebutuhan user dan ekspektasi user terhadap aplikasi yang akan dibuat. Secara ringkat, tahapan ini akan menghasilkan sebuah dokumen yang bisa kita sebut sebagai User Requirement.
• Desain, adalah tahapan dimana tim IT mulai menterjemahkan user requirement yang telah diserahkan atau disetujui oleh user. Biasanya, proses ini akan menghasilkan dokumen yang dapat kita sebut sebagai Technical Design. Kalo kita sedang merencanakan pembuatan rumah, tahap ini lebih kurang sama dengan proses pembuatan dokumen arsitek.
• Coding, pada saat ini pengembangan yang sesungguhnya dari aplikasi dimulai. Program-program mulai dikerjakan, tentu saya programmer yang bertugas membuat software akan selalu mengacu kepada dokumen Technical Design. Tahap ini dinyatakan selesai jika semua program telah selesai dibuat dan/atau di-'package'. Aplikasi telah selesai dan disiap untuk dilakukan proses pengujian.
• Testing, kini tiba waktunya untuk melakukan testing apakah aplikasi yang dibuat telah sesuai dengan yang sudah dituangkan dalam user requirement. Biasanya keluaran dari tahapan ini adalah dokumen pernyataan tentang "User Acceptance Test".
• Deploy, setelah tahapan testing selesai, kini tiba waktunya untuk menginstall program tersebut dan aplikasi mulai dioperasikan serta bekerja sesuai fungsinya.

Kini kita mencoba melihat berbagai kondisi nyata dalam proyek rekayasa perangkat lunak, sehingga terkadang metode waterfall ini tidak bisa menjadi obat mujarab untuk semua proyek rekayasa perangkat lunak. Ini tidak berarti bahwa waterfall tidak relevan lagi, tapi lebih tepatnya adalah kita harus melihat kenyataan bahwa warerfall bukan satu-satunya pendekatan yang harus dijalankan dalam setiap proyek rekayasa perangkat lunak.

Pendekatan Waterfall jarang sekali terjadi kolaborasi yang cukup kuat dan konsisten antara satu tim dengan tim lainnya. Pada setiap stage atau tahapan diatas, sangat mungkin tim yang bertanggung jawab terhadap tahapan tersebut menggunakan asumsi-asumsi yang berbeda dengan tim yang bertanggung jawab pada proses sebelumnya yang bisa disebabkan karena berbagai alasan seperti perbedaan domain knowledge, pengalaman industri dan lain sebagai. Orang- orang yang bertanggung jawab membuat user requirement, umumnya domain knowledgenya adalah business process pada industri tertentu. Pada saat orang desain mulai melakukan technical design, sangat dimungkinkan dia memiliki pengetahuan business process yang sama levelnya dengan tim yang membuat user requirement, sehingga dia bisa menggunakan asumsi yang mungkin berbeda pada saat user requirement dibuat. 

Apa yang dihasilkan oleh satu tahapan, merupakan "kontrak kerja untuk tahapan selanjutnya, umumnya dilegitimasi dengan istilah sign-off. Jadi jika User Requirement telah di sign-off pada tahap analisis, dokumen ini menjadi kontrak kerja bagi tahapan desain untuk menghasilkan technical design. Programmer yang bekerja pada saat coding, akan menggunakan techinal design yang telah mendapatkan sign-off sebagai kontrak kerja. Beberapa kemungkinan masalah yang dapat muncul kemudian adalah:

• Kesalahan atau kekurangan yang terjadi pada tahap awal akan mengakibatkan kesalahan berantai ditahap-tahap selanjutnya.
• Karena testing (UAT) baru mulai dilakukan setelah semua program selesai, respon terhadap kesalahan akan sangat terlambat sehingga proses perbaikan akan jauh lebih lama.
• Proses ini cenderung lambat untuk "time-to-market", sehingga pada saat aplikasi selesai dan siap beroperasi, lingkungan bisnis telah berubah sehingga aplikasi tersebut tidak bisa menggali pasar yang diharapkan sebelum aplikasi dibuat.

Perangkat input dari aplikasi berkembang pesat seperi card reader, scanner, kamera dan lainnya. Perangakat outputnya, juga semakin beragam, mulai dari tampilan grafis, resolusi warna, video dan lain sebagainya. Jika dulu, Sistem Informasi Manajemen (SIM), umumnya tampil dalam bentuk 'text mode' dengan 'menu driven'-nya. Pada saat itu, para user dan tim IT dapat dengan mudah untuk berdiskusi tentang User Requirement. Kini pilihan yang teknologi semakin banyak ditambah bisnis proses yang semakin komplek, user mengalami kesulitan untuk membuat sebuah user requirement yang menyeluruh dan tim IT juga harus memahami juga pilihan IT yang ada.

Banyak sekali proyek IT yang cenderung gagal karena hasilnya tidak sesuai ekspektasi atau waktu yang berjalan molor. Para praktisi rekayasa perangkat lunak melihat bahwa pendekatan waterfall sangat cocok, jika user dan tim IT sangat tahu persis tentang proses bisnis dan pilihan teknologi yang akan digunakan. Kondisi ini akan menghasilkan user requirement dan technical design yang komprehensif dan terstruktur dengan baik.

Waterfall model akan mengalami kesulitan pada saat user dan tim IT berada pada situasi yang komplek untuk membuat user requirement dan technical design karena minimnya pengalaman terhadap aplikasi yang sedang dibuat. Praktisi rekayasa perangkat lunak mencoba mencari merode lain, dimana aplikasi dikembangkan secara bertahap, berkolaborasi secara total dan adanya learning curve selama proyek berjalan. Pada bagian selanjunya kita akan melihat model alternatif yang mungkin dapat kita gunakan dalam proyek rekayasa perangkat lunak kita. Pendekatan ini kemudian sering kita kenal sebagai pendekatan AGILE.

Model Rekayasa Perangkat Lunak "AGILE"

Rekayasa perangkat lunak menggunakan AGILE sering juga disebut sebagai "iterative method" dan dapat juga disebut sebagai "incremental product development". Pada saat, tim IT dan tim user mengalami kesulitan untuk mendefinisikan kebutuhan mereka secara komprehensif, kemungkinanan cara ini akan lebih efektif. 

Proses pengembangan berjalan secara 'incremental', artinya aplikasi tidak harus diselesaikan secara sekaligus, melainkan bertahap. Disaat yang saman, 'incremental' ini juga terkain dengan kegiatan yang berulang-ulang ('iterative'). Dan hal yang terpenting adalah kolaborasi penuh antara semua personal proyek.

Mari kita lihat sebuah ilustrasi sederhana rekayasa perangkat lunak menggunakan AGILE :

• Tim agile tidak menuntut jumlah personal yang banyak, secara efektif sekitar 7 orang. Mereka terdiri dari orang bisnis (sering disebut sebagai product owner), orang-orang IT dan fasilitator AGILE.
• Mereka kemudian menetapkan waktu iterasi, jika kita menggunakan Scrum, iterasi ini disebut juga sebagai sprint (Scrum adalah salah satu metode implementasi AGILE. Selain agile ada juga Extreme Programming - mungkin pada topik mendatang saya akan mencoba untuk melihat lebih detail mengenai hal ini). 
• Sprint ini adalah waktu yang pendek, mungkin sekitar 2 minggu. 
• Pada saat tim agile menetapkan sprint atau iterasi selama 2 minggu, tim ini kemudian menetapkan 'incremental product'.
• Misal, iterasi pertama (2 minggu pertama), tim menetapkan untuk membuat 'screen untuk input data pegawai', iterasi kedua kemudian tim menetapkan incremental kedua dan seteruskan.
• Selama 2 minggu ini, tim Agile berkolaborasi secara terus menerus dan mereka memiliki meeting harian lebih kurang 15 menit. 
• Pada tim agile, semuanya bertanggung jawab terhadap incremental product. Mereka adalah satu kesatuan sebagai tim (orang bisnis, orang IT dan fasilitator). Selama 2 minggu itu, mereka berdiskusi, mendesain, membuat program dan testing secara bekerja sama sehingga incremental product itu siap untuk di deploy. 
• Umumnya, konsep ini akan berjalan sangat baik jika semua anggota agile berada pada lokasi yang sama. Mereka harus berdiskusi tiap hari lebih kurang 15 menit dengan 3 agenda utama (apa yang telah dikerjakan kemaren, apa yang akan dikerjakan hari ini dan kendala apa yang bisa menghambat progress).

Pada pendekatan waterfall, seolah-olah terdapat kontrak kerja antara pihak User dan IT yang dituangkan dalam user requirement. Pada metode Agile, User dan IT berkolaborasi bersama. Mereka menetapkan secara bersama apa yang ingin dibangun pada setiap iterasi, mereka sama-sama melakukan testing dan mereka bersama-sama belajar dari satu iterasi ke iterasi berikutnya. Setiap iterasi mereka selalu menghasilkan incremental produk yang tentu saya workable, tested dan membangun integrasi dari satu iterasi ke iterasi berikutnya.

Mari kita lihat beberapa kelebihan yang ditawarkan oleh pendekatan ini.

• Selalu terdapat RUNNING version. Sejak dari  iterasi pertama selesai, kita telah memilki versi yang sudah berjalan dan dapat kita manfaatkan. Misal, kita telah memiliki fungsi untuk memasukkan data.
• Error dapat lebih mudah untuk diidentifikasi. Karena tim bekerja secara kolaborasi dan incremental, error akan mudah terdeteksi lebih awal dan perbaikan dan dikerjakan secara cepat. 
• Respon terhadap error menjadi lebih cepat karena tim user dan IT saling berkolaborasi sebagai satu tim tanpa ada sekat. Sehingga proses perbaikan menjadi lebih cepat dan tepat.
• Agile juga menjadikan aplikasi "time-to-market". Respon terhadap kebutuhan pun menjadi lebih cepat. Karena prioritas incremental item pada setiap iterasi dapat menyesuaikan kebutuhan di market dan tim dapat memberikan respon yang cepat.

Summary 

AGILE sangat cocok digunakan pada tim IT dan user berada pada kondisi "uncertain requirement combined with unpredictable technology". User dan IT berkolaborasi bersama untuk memcoba menggali solusi secara bertahap dan terdapat proses pembelajaran dati setiap iterasi.

Jika user mampu untuk menggambarkan user requirement secara terstruktur dan menyeruh, serta diikuti oleh tim IT yang sagat familiar dengan proses bisnis dari aplikasi yang sedang dikembangkan, waterfall model akan memberikan solusi yang effisien. Hal ini karena, tim IT dan user dapat memprediksi hasil akhir jauh lebih terstruktur dan bisa mempersiapkan solusi yang cepat dan tepat guna menyelesaikan aplikasi tersebut.

NEXT

Semoga tulisan ini dapat memberikan gambaran tentang adanya pendekatan rekayasa perangkat lunak AGILE sebagai alternatif pendekatan Waterfall yang sudah kita kenal luas. Selanjutnya, saya akan mencoba untuk mempersiapkan tulisan berikutnya untuk memberikan gambaran yang lebih detail dan beberapa metode yang dapat digunakan untuk mengimplementasikan AGILE.

• Karakteristik dari pengembangan AGILE, apa saja prinsip pokok dari sebuah implementasi AGILE dan manisfesto AGILE
• Agile Menggunakan Extreme Programming (XP), metode ini berfokus pada programming practices
• Agile Menggunakan Scrum, metode ini, metode ini berfokus pada project management
• Lean Development dan Kanban, metode ini mencoba mengadapsi proses manufaktur yang diperkenalkan oleh TOYOTA dalam rekayasa perangkat lunak.

--------

Link:

Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 

Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi

Semoga Bermanfaat

Singapore, Januari 2014
"Dipersiapkan selama perjalanan rumah-kantor di atas MRT (pengguna setia MRT)"

CMMI - Software Quality Assurance (SQA)

Di dalam framework CMMI, untuk sebuah organisasi yang ingin mendapatkan maturity level 2 disyaratkan untuk memiliki sebuah tim yang dikenal dengan nama SQA atau Software Quality Assurance. Istilah ini terkadang menimbulkan persepsi yang membingungkan dengan istilah Quality Control atau User Acceptance Test yang umumnya sudah berjalan di banyak organisasi IT baik yang sudah mendapatkan sertifikat CMMI atau belum.

Dalam pengertian CMMI, istilah Software Quality Assurance tidak berhubungan secara langsung dengan produk IT yang sedang dikembangkan. Aktifitas SQA tidak secara langsung mencoba untuk melakukan verifikasi atau validasi apakah produk IT atau aplikasi atau software yang dihasilkan telah sesuai dengan requirement atau spesifikasi yang telah ditetapkan.
 

Jadi Apakah aktifitas SQA ?

Aktifitas SQA, jika kita mengacu pada framework CMMI lebih kurang memiliki tujuan untuk melihat bagaimana proses berjalan selama proyek pengembangan produk IT atau aplikasi. SQA bertugas untuk meyakinkan bahwa proyek ini memiliki requirement yang telah disetujui user atau apakah proses testing telah dilaksanakan secara standard dan mendapatkan sign-off dan lain sebagainya berkaitan dengan proses yang berjalan selama proyek berlangsung.

Secara umum, aktifitas SQA melingkupi hal-hal sebagai berikut :

- Secara objektif melakukan analisa apakah proses yang berjalan yang berjalan selama proyek, dokumentasi dari setiap aktifitas dari proyek dan juga hasil-hasil dari proyek telah sesuai dengan standard dan prosedur yang sudah ditetapkan oleh organisasi.

- Melakukan identifikasi dan dokumentasi jika terdapat hal-hal yang tidak sesuai dengan standard atau prosedur proses yang telah ditetapkan oleh organisasi.

- Memberikan feedback kepada tim atau manajer yang terlibat di dalam proyek mengenai hasil yang telah ditemukan selama proses SQA.

- Meyakinkan bahwa semua issue yang telah ditemukan selama proses SQA, telah tercatat dan mendapat tanggapan untuk segera diselesaikan sesuai dengan standard dan prosedur yang telah ditetapkan oleh organisasi.

Intinya proses SQA adalah sebuah aktifitas untuk mendukung agar proyek dapat menghasilkan sebuah produk yang berkualitas yang memantau proses yang berlangsung selama proyek dan memberikan feedback jika terdapat ada issue yang tidak sesuai dengan standard atau prosedur yang berlaku untuk selanjutnya diselesaikan dan ini berlangsung secara reguler selama proyek berlangsung dari awal sampai akhir.

SQA layaknya sebagai POLISI dalam Proyek

Seperti layaknya jika kita melihat Polisi ditengah-tengah lingkungan kita, dia bisa menjadi sesuatu yang menakutkan atau justru menjadi sesuatu yang melindungi dan sangat diharapkan keberadaannya. Pada saat Polisi melihat sesuatu yang tidak sesuai dengan aturan (misalkan melanggar lampu merah), kita akan merasa was-was pada saat kita melakukannya dan Polisi mendekati kita. Sementara itu, orang yang lain akan merasa nyaman dan aman karena Polisi telah memberikan peringatan kepada orang yang melanggar lampu merah sehingga keamanan bagi pengendara yang lain tetap terjaga dan lalu lintas akan menjadi lancar jika semua orang mematuhi aturan yang ada.

Itulah yang dilakukan oleh tim SQA di dalam sebuah sebuah proyek yang dijalankan dengan menggunakan framework CMMI. Tim SQA selalu mengacu kepada standard dan prosedur proses yang telah ditetapkan oleh organisasi untuk menjamin semua proyek berjalan sesuai dengan standard proses yang berkualitas. Dan aktifitas SQA mengacu kepada konsep bahwa, produk yang berkualitas akan dapat dihasilkan oleh proses yang berkualitas.

Produk yang berkualitas akan dihasilkan dari proses yang berkualias

Ingat, bahwa kualitas proyek IT tidak dapat terlihat secara langsung dengan melihat hasil akhir. Pada saat kita membeli sebuah motor, kita dapat melihat bentuk fisik dari motor, mendengarkan bagaimana suara yang dihasilkan oleh mesin motor dan mencoba mengendarai motor tersebut selama beberapa menit. Dengan melakukan aktifitas ini terhadap motor, kita dapat menentukan apakah motor ini telah sesuai dengan keinginan kita dan kita siap untuk membelinya.

Mari kita lihat, pada saat proyek manager IT mengatakan kepada kita, "Pak, proyek telah selesai dan aplikasi ini saya serahkan kepada bapak untuk dipergunakan". Apa yang ada di kepala kita pada saat penyerahan produk IT tersebut kepada kita. Tentu saja, kita akan merasa sulit untuk melihat apakah produk yang diberikan oleh manajer IT tersebut telah sesuai dengan yang kita harapkan. Itulah tantangannya, maka kita sering mendengar bahwa jika kita tahu bahwa proses pengembangan IT tersebut telah berjalan dengan kualitas yang baik, maka produk yang dihasilkan kemungkinan juga berkualitas. Jika seluruh proses requirement telah berjalan sesuai standar, proses pengembangannya berjalan sesuai guidelline sampai akhirnya proses testing dan user acceptance test berlangsung sesuai dengan standar kualitas yang telah ditetapkan, maka pada saat penyerahan produk kita memiliki rasa percaya diri yang tinggi bahwa produk ini telah sesuai dengan keinginan kita.

Sama dengan aktifitas kita dalam berkebun, jika kita selalu memberi pupuk dan merawat kebun sesuai dengan standar dan prosedur yang telah ditetapkan (untuk mencapai sebuah kualitas tertentu), maka kita dapat berharap dan percaya bahwa produk yang dihasilkan akan juga berkualitas.

SQA dan SQC

Secara umum, bagi organisasi IT yang belum menjalankan CMMI, mereka jarang sekali mendengar istilah SQA. Dan pada saat CMMI diperkenalkan, istilah SQA terkadang dipersepsikan sebagai kegiatan testing terhadap produk IT. Padahal SQA lebih terfokus kepada proses pengembangan mulai dari tahap persiapan sampai akhirnya proyek dinyatakan selesai.

Sedangkan proses untuk menguji apakah sebuah produk (aplikasi IT) telah sesuai dengan requirement atau spesifikasi yang disepakati, kita dapat menyebutnya sebagai Quality Control atau Software Quality Control (SQC). Sehari-hari mungkin kita sering dengar juga istilah UAT atau QA, yang lebih kurang sama dengan SQC yaitu melakukan verifikasi dan validasi apakah produk sesuai dengan requirement dan dapat bekerja atau beroperasi dengan baik.

Jika mengacu kepada CMMI, kegiatan SQA berkaitan dengan proses area (proses inti) "PROCESS AND PRODUCT QUALITY ASSURANCE". Dan kegiatan SQC, berkaitan dengan proses area (proses inti) "VERIFICATION" dan "VALIDATION".

--------

Link:

Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 

Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi

Membangun Kualitas IT dengan CMMI

Saat kita membeli sebuah meja baru, kita dapat mengamati dan menilai secara kasat mata mutu dari meja tersebut, apakah terdapat defect yang sangat mengganggu dan juga dapat menilai apakah design serta hasil akhir dari meja yang kita amati sesuai dengan keinginan kita.

Mari kita bayangkan saat membeli sebuah aplikasi atau pada saat penyedia IT menyampaikan hasil pengembangannya kepada kita. Apa yang harus kita lakukan untuk melihat apakah aplikasi tersebut benar-benar telah sesuai dengan keinginan kita, dapatkah kita melihat defect yang terdapat pada aplikasi tersebut secara kasat mata, karena memang aplikasi tidak berbentuk sebuah fisik. Pertanyaan yang muncul adalah, bagaimana kita bisa meyakinkan bahwa kualitas aplikasi yang kita dapatkan telah sesuai dengan harapan kita ?

Di sisi pengembang IT, kita sering melihat para programmer yang mengeluh karena design yang sering berubah-ubah dan penambahan fungsi baru yang tidak terdokumentasi dengan baik sehigga programmer terlalu sering untuk melakukan 'rework' karena tidak adanya kontrol yang baik terhadap dokumentasi design dan fungsi antara pihak pengembang IT dan pihak End-User. Ini dapat mengakibatkan kualitas program yang rendah, keterlambatan dan juga memunculkan biaya baru. Ini adalah sebuah gejala dari tidak adanya proses standar dan baku dalam organisasi IT.

Fenomena Pengembangan Aplikasi

Mari kita lihat beberapa permyataan yang cukup sering kita dengar dalam menjalankan proyek pengembangan aplikasi.

• Seorang manajer pengembangan aplikasi, "Yang penting aplikasinya diimplementasikan terlebih dahulu. Kesalahan atau defect adalah hal yang biasa dan kita bisa perbaiki di versi berikutnya. Itu lebih baik daripada kita menunda sehingga jadwal implementasi menjadi terlambat".
• Seorang manajer proyek, "Kunci dari keberhasilan saya adalah schedule. Jika saya tidak dapat menyelesaikan pekerjaan saya tepat waktu, artinya saya telah gagal menjalankan proyek ini."

Itu adalah beberapa pernyataan yang sering menurunkan tingkat kualitas aplikasi yang sedang kita kembangkan. Disisi lain, Deming dan Humprey mengatakan bahwa "Kualitas sebuah produk sangat ditentukan oleh kualitas dari proses yang digunakan mulai dari perencanaan, design, pengembangan hingga akhirnya perawatan".

Jika kita mampu menjalan sebuah proses yang berkualitas, maka secara umum kita akan menghasilkan produk yang berkualitas. Deming dan Humpey mengembangkan sebuah framework yang kita kenal dengan nama Capability Maturity Model (CMM). Dan kini framework ini telah berkembang menjadi Capability Maturity Model Integration (CMMI).

Apa itu CMMI

Mungkin kita sering mendengar bahwa organisasi IT menyatakan bahwa mereka telah menjalankan CMMI level 3 dan sementara di organisasi yang lain telah mendapatkan CMMI level 4. Dan kita juga mungkin melihat ada organisasi yang sedang memulai untuk mengimplementasikan CMMI di dalam proses pengembangan produk IT.

CMMI adalah sebuah model yang terstruktur untuk menggambarkan level dari proses secara menyeluruh pada sebuah organisasi. CMMI direpresentasikan atau digambarkan dalam 2 bentuk yaitu

• Proses digambarkan sebagai Continous Representation untuk menunjukkan Capability Level
• Proses digambarkan sebagai Staged Representation untuk menunjukkan Maturity Level.

CMMI dapat memberikan gambaran bagaimana kualitas semua proses yang dijalankan berdasarkan representasi 'Continous' dan ' Staged'. Kita juga dapat membandingkan organisasi yang telah memiliki dan menjalankan proses yang terstruktur berdasarkan Capability Level dan Maturity Level.

Proses Inti Dalam CMMI

Trdapat beberapa proses inti yang menjadi acuan dalam pelaksaan CMMI bagi sebuah organisasi. Di bawah ini adalah proses inti yang dimiliki oleh CMMI.

Process Management

Organizational Process Focus

Organizational Process Definition

Organizational Training

Organizational Process Performance

Organizational Innovation and Deployment

Project Management

Project Planning

Project Monitoring and Control

Supplier Agreement Management

Risk Management

Intergrated Teaming

Integrated Supplier Management

Quantitative Project Management

Engineering

Requirement Management

Requirement Development

Technical Solution

Product Integration

Verification

Validation

Support

Configuration Management

Process and Product Quality Assurance

Measurement and Analysis

Decision Analysis and Resolution

Organizational Environment for Integration

Causal Analysis and Resolution

Continous Representation atau Capability Level

Capability Level adalah sebuah model untuk menggambarkan bagaimana setiap proses inti berjalan di dalam sebuah organisasi. CMMI memiliki 6 level untuk setiap proses inti:

• Level 0:   Incomplete
• Level 1:   Performed
• Level 2:   Managed
• Level 3:   Defined
• Level 4:   Quantitatively Managed
• Level 5:   Optimizing

Setiap organisasi tentu bisa memiliki satu atau dua proses inti yang menurut mereka sangat penting dan berada pada level 4 atau 5, sementara di organisasi berbeda dapat memiliki level berbeda-beda untuk setiap proses inti.

CMMI memiliki panduan dan tim yang dapat menilai atau mereview untuk melihat capability level untuk setiap proses inti di dalam sebuah organisasi. Secara singkat, penjelasan capability level adalah sebagai berikut.

Capability Level 0: Incomplete
Sebuah proses area dapat dikategorikan berada pada level ini, jika proses tersebut memang tidak dimiliki oleh organisasi yang bersangkutan atau berjalan secara partial.

Capability Level 1: Performed
Proses area tersebut sudah menjadi bagian dari sesuatu yang wajib dalam menjalankan kegiatan. Walaupun masih terdapat kekurangan dalam pelaksanaannya baik disisi kualitas maupun schedule. Prinsipnya proses sudah berjalan dan menjadi sesuatu yang wajib sebagai titik awal.

Capability Level 2: Managed
Sebuah proses berada pada level ini, jika proses ini selalu direncanakan, dilakukan, dimonitor dan berjalan pada setiap aktifitas pengembangan. Ini berarti bahwa, organisasi ini selalu menjalankan proses ini di setiap proyek pengembangannya. Terdapat fungsi perencanaan dan kontrol.

Capability Level 3: Defined
Sebuah proses berada pada level ini, jika proses itu didefinikan secara menyeluruh di dalam sebuah organisasi. Pada level 2 ("Managed"), sangat dimungkinkan proyek A dan B menjalankan proses requirement analysis, tetapi mereka melakukannya dengan cara yang berbeda. Sehingga team di proyek A, sangat sulit untuk memahami proses dan dokumentasi dari requirement analysis di proyek B. Pada level 3 ("Defined"), semua proses telah didefinisikan secara baku sehingga semua orang di dalam organisasi ini memiliki cara yang sama untuk melakukan sebuah proses tertentu.

Capability Level 4: Quantitatively Managed
Di level ini, sebuah proses akan dimonitor  menggunakan pendekatan kuantitatif untuk mengukur apakah sebuah proyek benar-benar menjalankan proses secara tepat.

Capability Level 5: Optimizing
Sebuah proses berapa pada level ini di dalam sebuah organisasi, jika terdapat sebuah aktifitas atau tim yang fokus untum mempelajari atau mereview. Ini adalah sebuah pengembangan dari level 4.

Melalui proses review dan analisa dengan metode tertentu, sebuah organisasi IT dapat memiliki Continous Representation atau Capability Level untuk semua proses inti yang telah didefinisikan oleh CMMI. Kita dapat merepresentasikan melalui sebuah grafik atau menggunakan tabel. Mari kita liat contoh berikut :

• Requirement Management (REQM): level 3
• Project Planning (PP): level 3
• Project Monitoring and Control (PMC): level 2
• Supplier Agreement Management (SAM): level 2

 

Staged Representation atau Maturity Level

Jika kita mendengar sebuah organisasi telah menjalankan CMMI level 3, ini menunjukkan bahwa organisasi ini berkaitan dengan "Staged Representation" atau "Maturity Level". Artinya organisasi ini telah mendapatkan sertifikat Maturity Level 3 dalam implementasi CMMI.

Pada Continous Representation atau Capability Level, kita melihat satu persatu proses inti yang ada dan mencoba untuk mengkaji dan mereview sampai sejauh mana implementasi proses inti tersebut di dalam organisasi.

CMMI juga dikenal dengan satu model dengan 2 representasi. Sekarang kita melihat representasi kedua dari CMMI yang sering disebut sebagai "Staged Representation" dan menggunakan "Maturity Level" sebagai tolak ukurnya. Dalam Maturity Level, kita melihat sejauh mana organisasi telah menjalankan seluruh proses inti yang terdapat pada CMMI. Maturity Level akan melihat semua proses tersebut untuk menggambarkan "Staged Representasi".

Terdapat 5 Maturity Level dalam CMMI

Level 1:   Initial

Level 2:   Managed

Level 3:   Defined

Level 4:   Quantitatively Managed

Level 5:   Optimizing

Secara sederhana, makna dari level tersebut adalah sebagai berikut :

Maturity Level 1: Initial
Secara umum, organisasi yang berapa pada level 1 adalah organisasi yang belum menjalankan CMMI. Tidak terdapatnya proses yang standar dalam pengembangan IT, banyak perubahan yang bersifat ad-hoc (begitu terdapat defect, langsung di coba diperbaiki tanpa melihat penyebab utama secara menyeleruh) dan sangat sedikit kontrol. Organisasi semacam ini umumnya sangat tergantung terhadap 'orang', tidak tergantung kepada 'sistem'. Jika terdapat satu orang yang 'cerdas', dia akan menangani semuanya sebagai 'hero' dan pada saat 'orang' ini tidak ada, maka proyek akan bergoyang.

Maturity Level 2: Managed
Organisasi ini telah memiliki beberapa proses yang sering digunakan salam setiap proyek pengembangan, tetapi tidak terdapat keseragaman secara menyeluruh. Proses sudah mulai berjalan secara konsisten, tetapi tidak menyeluruh di semua lini organisasi.

Maturity Level 3: Defined
Ini adalah level yang paling umum disasar oleh hampir seluruh organisasi pada saat mereka mengimplementasikan CMMI. Pada level ini, semua lini organisasi menjalankan proses yang sudah didefinisikan pada level organisasi dan semua tim paham bagaimana proses seharusnya berjalan.

Maturity Level 4: Quantitatively Managed
Pada level ini, organisasi seudah semakin advance. Mereka mulai menerapkan konsep kuantifikasi pada setiap proses,  selalu diawasi dan dikontrol.

Maturity Level 5: Optimizing
Ini adalah level puncak dalam CMMI, dimana innovasi dan optimasi proses senantiasa dipantau dan dianalisa.

Mapping Proses Inti dan Maturity Level(Staged Representation)

Disamping penjelasan sederhana diatas, CMMI juga memiliki mapping antara Maturity Level dan Proses Inti yang harus terdapat pada level tersebut. Mapping tersebut adalah sebagai berikut :

Maturity Level 2:

Project Planning

Project Monitoring and Control

Supplier Agreement Management

Requirement Management

Configuration Management

Process & Product Quality Assurance

Measurement and Analysis

Maturity Level 3:

Organizational Process Focus

Organizational Process Definition

Organizational Training

Integrated Project Management

Risk Management

Requirement Development

Technical Solution

Product Integration.

Verification

Validation

Decision Analysis and Resolution

Maturity Level 4:

Organizational Process Performance

Quantitative Project Management

Maturity Level 5:

Organizational Innovation and Deployment

Causal Analysis and Resolution.

Penutup

CMMI adalah sebuah model dengan menggunakan 2 macam representasi untuk menunjukkan bagaimana sebuah organisasi me-manage semua proses dalam setiap proyek pengembangan untuk mencapai produk IT yang berkualitas.

--------

Link:

Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 

Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi

Semoga Bermanfaat.
Tampines (Singapore)