Management

Alternatif manajemen proyek populer saat ini selain SCRUM adalan KANBAN.

Perbedaannya dengan SCRUM, Kanban lebih fokus pada aliran kerja yang kontinu, sementara Scrum lebih terstruktur dengan iterasi (sprint) yang terjadwal dan memiliki peran-peran yang lebih terdefinisi untuk memastikan pengiriman nilai secara konsisten.

Walaupun banyak versi aliran yang digunakan namun saya lebih memilih

Backlog – Todo – Doing – Review – Done. Sedangkan warna menunjukkan Prioritas.

Implementasi

1. Setiap project akan dibagi menjadi beberapa modul (sub project), ada yang menyebutnya WORK.
2. Dalam sub project dilist macam-macam pekerjaan dan dimasukkan dalam kelompok BACKLOG .
3. Dari daftar pekerjaan pasda BACKLOG diambillah beberapa pekerjaan prioritas dan orang yg harus mengerjakan dan aliran pekerjaan masuk ke dalam kelompok TODO. Jadi TODO adalah kelompok yang siap dikerjakan.
4. TODO yang mulai dikerjakan masuk de dalam kelompok DOING
5. Pekerjaan yang sudah selesai dipindah dari DOING ke REVIEW untuk dilihat oleh pimpinan project.
6. Apabila project dinyatakan selesai maka dia akan masuk ke DONE. Dan apabila masih ada yang dipernbaiki maka akan dikembalikan ke DOING.

Saya kira alur ini adalag alur yang paling simpel dalam manajemen project. Paling cocok untuk project-project kecil, karena fleksibilitasnya.

Jika diwujudkan dalam bentuk software, mungkin perlu  penambahan properti target waktu, pelaksana, dan catatan-catatan dalam setiap item pekerjaan.

 

Apakah stories harus ada dalam Scrum? Secara umum, stories adalah salah satu alat yang digunakan dalam Scrum untuk mengelola dan mengkomunikasikan kebutuhan pengguna. Namun, tidak selalu harus menggunakan stories secara eksklusif. Ada juga format lain seperti task, bug, atau epic yang dapat digunakan tergantung pada kebutuhan proyek dan preferensi tim. Yang penting adalah untuk memiliki cara yang jelas dan efektif untuk menggambarkan kebutuhan, mengukur pekerjaan, dan mengorganisir backlog sehingga tim dapat bekerja secara terstruktur dan produktif.

Stories memiliki beberapa fungsi utama dalam metodologi Scrum:

1. Menggambarkan Kebutuhan Pengguna: Stories adalah cara untuk menggambarkan kebutuhan atau cerita pengguna dari sudut pandang pengguna. Ini membantu tim pengembangan memahami apa yang sebenarnya diinginkan oleh pengguna akhir dan fokus pada pengembangan solusi yang memenuhi kebutuhan tersebut.
2. Mengukur Pekerjaan: Stories biasanya memiliki estimasi poin (story points) yang mengindikasikan kompleksitas atau ukuran pekerjaan yang diharapkan. Ini membantu tim dalam merencanakan dan mengelola kapasitas kerja mereka dalam setiap Sprint.
3. Mengorganisir Backlog: Stories membantu mengorganisir Product Backlog dengan menyederhanakan kebutuhan pengguna menjadi tugas-tugas yang lebih mudah dipahami dan diukur. Dengan demikian, mempermudah tim dalam menentukan urutan prioritas pekerjaan.
4. Membantu dalam Penyusunan Sprint Backlog: Stories dari Product Backlog dipilih untuk dimasukkan ke dalam Sprint Backlog selama Sprint Planning. Ini membantu tim dalam merencanakan pekerjaan yang akan dilakukan selama Sprint tersebut.
5. Mendorong Keterlibatan Tim: Stories memberikan fokus dan tujuan yang jelas kepada tim pengembangan. Dengan memiliki cerita pengguna yang jelas, tim lebih terlibat dalam memahami konteks pengguna, menemukan solusi yang sesuai, dan menghasilkan produk yang lebih bernilai.
6. Menghasilkan Deliverables yang Bernilai: Dengan memfokuskan pada cerita pengguna, tim dapat menghasilkan inkrement produk yang lebih bernilai dan sesuai dengan harapan pengguna akhir.

Perbedaan antara backlog dan stories adalah sebagai berikut:

1. Backlog:
   • Backlog adalah daftar semua pekerjaan yang harus dilakukan dalam proyek, baik itu fitur, perbaikan, pemeliharaan, atau tugas lainnya.
   • Backlog mencakup semua jenis pekerjaan yang perlu diselesaikan untuk menghasilkan produk atau layanan.
   • Backlog dapat dibagi menjadi beberapa jenis, seperti Product Backlog (untuk semua pekerjaan terkait produk) dan Sprint Backlog (untuk pekerjaan yang akan diselesaikan dalam satu sprint).
   • Backlog berfungsi sebagai kumpulan tugas yang perlu dikerjakan, yang kemudian dipecah menjadi stories atau item pekerjaan lainnya.
2. Stories:
   • Stories adalah elemen individu dalam backlog yang menggambarkan kebutuhan atau cerita pengguna.
   • Stories biasanya ditulis dalam format naratif yang menjelaskan kebutuhan pengguna atau pengalaman pengguna yang diinginkan.
   • Stories adalah cara untuk mengkomunikasikan kebutuhan pengguna kepada tim pengembang dengan cara yang dapat dipahami dan dapat diukur.
   • Setiap story dapat memiliki poin estimasi (story points) untuk mengindikasikan kompleksitas atau ukuran pekerjaan yang diharapkan.

Contoh Perbedaan dengan Studi Kasus:

Backlog:

• Product Backlog:
  • Fitur Login
  • Fitur Tambah Proyek
  • Fitur Tambah Tugas
  • Fitur Tampilkan Daftar Proyek
  • Fitur Tampilkan Detail Proyek
  • Fitur Tampilkan Daftar Tugas
  • Perbaikan Bug pada Fitur Notifikasi

Stories:

1. Story untuk Fitur Login: “Sebagai pengguna, saya ingin dapat login ke aplikasi menggunakan nama pengguna dan kata sandi saya.”
2. Story untuk Fitur Tambah Proyek: “Sebagai pengguna, saya ingin dapat menambahkan proyek baru dengan memberikan nama proyek dan deskripsi singkat.”
3. Story untuk Fitur Tambah Tugas: “Sebagai pengguna, saya ingin dapat menambahkan tugas dalam proyek dengan menentukan judul, deskripsi, dan tenggat waktu.”
4. Story untuk Fitur Tampilkan Daftar Proyek: “Sebagai pengguna, saya ingin melihat daftar semua proyek yang saya miliki beserta detailnya seperti nama, deskripsi, dan status.”
5. Story untuk Fitur Tampilkan Detail Proyek: “Sebagai pengguna, saya ingin melihat detail lengkap dari suatu proyek termasuk daftar tugas yang terkait dengan proyek tersebut.”
6. Story untuk Fitur Tampilkan Daftar Tugas: “Sebagai pengguna, saya ingin melihat daftar semua tugas dalam suatu proyek beserta status dan informasi terkait.”
7. Story untuk Perbaikan Bug pada Fitur Notifikasi: “Sebagai pengguna, saya ingin bug pada fitur notifikasi diperbaiki agar saya dapat menerima notifikasi dengan benar.”

Dalam contoh di atas, backlog adalah kumpulan fitur-fitur dan pekerjaan yang perlu diselesaikan, sementara stories adalah representasi dari kebutuhan pengguna atau tugas-tugas spesifik yang harus dilakukan untuk setiap fitur dalam backlog. Stories membantu dalam menguraikan kebutuhan pengguna menjadi tugas-tugas yang dapat dikerjakan dan diukur oleh tim pengembang.

Scrum board adalah alat visual yang digunakan dalam metodologi Scrum untuk melacak dan mengorganisir pekerjaan yang harus dilakukan oleh tim pengembangan. Ini membantu tim dalam memahami status pekerjaan, memantau kemajuan, dan berkolaborasi secara efektif. Scrum board biasanya terbagi menjadi kolom-kolom yang mewakili tahapan-tahapan proses pengembangan, seperti “To Do”, “In Progress”, dan “Done”.

Berikut adalah contoh praktis penggunaan Scrum board untuk pengembangan aplikasi sederhana:

Scrum Board untuk Pengembangan Aplikasi To-Do List

Kolom Scrum Board:

1. Backlog: Daftar semua item pekerjaan yang harus dilakukan, termasuk stories dari Product Backlog.
2. To Do: Item pekerjaan yang siap untuk dikerjakan pada Sprint ini.
3. In Progress: Item pekerjaan yang sedang dalam proses pengembangan atau pengujian.
4. Testing: Item pekerjaan yang sedang diuji.
5. Review: Item pekerjaan yang selesai dan sedang menunggu review.
6. Done: Item pekerjaan yang sudah selesai dan siap untuk diserahkan.

Contoh Praktis:

1. Sprint Planning (Hari 1):
   • Tim melakukan Sprint Planning Meeting.
   • Item-item dipilih dari Product Backlog dan ditempatkan dalam kolom “To Do” di Scrum board untuk Sprint ini.
2. Daily Stand-up Meeting (Hari 2-9):
   • Setiap hari, tim melakukan pertemuan stand-up.
   • Item-item dipindahkan di Scrum board sesuai dengan kemajuan pekerjaan.
   • Contoh:
     • Story “Tambah Tugas” dipindahkan dari “To Do” ke “In Progress” setelah dikerjakan.
     • Story “Edit Tugas” dipindahkan dari “In Progress” ke “Testing” setelah pengembangan selesai.
3. Sprint Review dan Retrospective (Hari 10):
   • Tim melakukan Sprint Review Meeting untuk memeriksa hasil pekerjaan.
   • Item-item yang selesai dipindahkan ke kolom “Review” untuk proses review.
   • Sprint Retrospective dilakukan untuk mengevaluasi proses sprint ini.
4. Sprint Baru (Hari 11):
   • Item-item baru dipilih untuk Sprint berikutnya.
   • Kolom “To Do” di Scrum board diisi dengan item-item baru yang akan dikerjakan.

Dengan menggunakan Scrum board, tim dapat dengan jelas melihat status pekerjaan, mengidentifikasi hambatan, dan memastikan bahwa pekerjaan berjalan sesuai rencana. Ini juga memfasilitasi komunikasi dan kolaborasi antar anggota tim, serta memungkinkan transparansi dalam pengelolaan proyek.

Baik, mari kita ambil contoh penggunaan Scrum dengan backlog dan time frame yang jelas. Dalam contoh ini, kita akan menggunakan tim pengembangan perangkat lunak untuk mengembangkan aplikasi manajemen proyek sederhana. Tim ini terdiri dari seorang Product Owner (PO), seorang Scrum Master, dan tiga anggota tim pengembang.

Backlog Produk:

1. Fitur Login
2. Tambah Proyek Baru
3. Tambah Tugas dalam Proyek
4. Tampilkan Daftar Proyek
5. Tampilkan Detail Proyek
6. Tampilkan Daftar Tugas dalam Proyek

Time Frame:

Sprint akan berlangsung selama 2 minggu (10 hari kerja).

Sprint Planning Meeting (Hari 1):

• Product Owner dan tim pengembang bertemu untuk merencanakan Sprint pertama.
• Berdasarkan backlog, mereka memilih item-item berikut untuk Sprint pertama:
  • Fitur Login
  • Tambah Proyek Baru
  • Tambah Tugas dalam Proyek

Pelaksanaan Sprint (Hari 2-11):

• Daily Stand-up Meeting (Hari 2-11):
  • Setiap hari, tim melakukan pertemuan singkat untuk membagikan status pekerjaan, mendiskusikan hambatan, dan merencanakan langkah selanjutnya.
• Pengembangan (Hari 2-10):
  • Tim pengembang bekerja pada fitur-fitur yang dipilih untuk Sprint pertama.
• Pengujian dan Integrasi (Hari 9-10):
  • Setelah pengembangan selesai, dilakukan pengujian fitur-fitur yang telah dibuat dan integrasi dengan komponen lain dalam aplikasi.

Sprint Review Meeting (Hari 11):

• Tim mengadakan pertemuan dengan Product Owner untuk memperlihatkan hasil Sprint pertama.
• Product Owner memberikan umpan balik tentang fitur-fitur yang telah dikembangkan.

Sprint Retrospective Meeting (Hari 12):

• Tim melakukan pertemuan retrospective untuk mengevaluasi Sprint pertama.
• Mereka membahas apa yang berjalan baik, apa yang perlu ditingkatkan, dan merencanakan tindakan perbaikan untuk Sprint berikutnya.

Sprint Planning Meeting untuk Sprint Berikutnya (Hari 12):

• Berdasarkan umpan balik dari Sprint pertama, Product Owner dan tim pengembang merencanakan item-item untuk Sprint berikutnya.

Pelaksanaan Sprint Berikutnya (Hari 13-22):

• Proses diulang dengan memilih item-item dari backlog untuk Sprint kedua.
• Daily stand-up, pengembangan, pengujian, dan integrasi dilakukan seperti sebelumnya.

Iterasi Selanjutnya:

Proses ini terus berlanjut dengan setiap Sprint baru, di mana tim terus meningkatkan aplikasi dengan fitur-fitur baru dan menyesuaikan rencana berdasarkan umpan balik yang diberikan oleh Product Owner.

Dengan menggunakan kerangka kerja Scrum, tim dapat mengelola proyek dengan lebih adaptif, memprioritaskan pekerjaan berdasarkan kebutuhan dan umpan balik, serta secara teratur menghasilkan inkrement produk yang bernilai untuk pelanggan.

Scrum adalah salah satu kerangka kerja manajemen proyek yang digunakan dalam pengembangan perangkat lunak dan proyek-proyek yang memerlukan pendekatan iteratif dan inkremental. Scrum didasarkan pada prinsip-prinsip Agile yang mengutamakan kerja tim kolaboratif, adaptasi terhadap perubahan, dan pengiriman produk yang bernilai secara berkala. Dalam Scrum, pekerjaan dipecah menjadi iterasi singkat yang disebut “sprint” yang biasanya berlangsung sekitar 2-4 minggu.

Studi kasus sederhana penggunaan Scrum dapat diilustrasikan dalam konteks pengembangan aplikasi sederhana. Misalkan ada sebuah tim pengembangan yang terdiri dari tiga anggota:

1. Product Owner (PO): Bertanggung jawab atas visi produk, menentukan kebutuhan pelanggan, dan mengelola backlog produk.
2. Scrum Master: Bertanggung jawab memfasilitasi proses Scrum, menghilangkan hambatan, dan memastikan tim menerapkan prinsip-prinsip Scrum dengan benar.
3. Tim Pengembang: Melakukan pekerjaan teknis untuk mengembangkan produk.

Berikut adalah tahapan penggunaan Scrum dalam studi kasus ini:

1. Perencanaan Sprint

• Sprint Planning Meeting: Tim melakukan pertemuan sprint planning untuk merencanakan pekerjaan yang akan dilakukan selama sprint. Product Owner menyediakan backlog produk yang berisi item-item pekerjaan yang diinginkan, dan tim memilih item-item untuk disertakan dalam sprint berikutnya berdasarkan kapasitas dan prioritas.

2. Pelaksanaan Sprint

• Daily Stand-up: Setiap hari, tim melakukan pertemuan singkat (stand-up) untuk berbagi status pekerjaan, mengidentifikasi hambatan, dan merencanakan langkah selanjutnya.
• Development: Tim pengembang bekerja pada item-item backlog yang dipilih selama sprint, melakukan pengujian, dan menghasilkan inkrement produk yang berfungsi.

3. Review dan Retrospektif

• Sprint Review Meeting: Setelah sprint selesai, tim melakukan pertemuan sprint review untuk memperlihatkan hasil kerja kepada Product Owner dan mendapatkan umpan balik. Product Owner dapat mengonfirmasi apakah inkrement produk tersebut memenuhi harapan.
• Sprint Retrospective Meeting: Tim melakukan pertemuan retrospective untuk mengevaluasi proses sprint yang baru saja berlalu. Mereka membahas apa yang berjalan baik, apa yang perlu ditingkatkan, dan merencanakan tindakan perbaikan untuk sprint berikutnya.

Contoh Implementasi dalam Aplikasi Sederhana

Misalkan tim tersebut mengembangkan aplikasi manajemen tugas sederhana. Dalam Sprint pertama, mereka memilih untuk mengimplementasikan fitur login, menambahkan tugas, dan menampilkan daftar tugas. Setelah dua minggu, mereka menyelesaikan tugas-tugas tersebut dan memperlihatkan hasilnya kepada Product Owner dalam Sprint Review. Kemudian, dalam Sprint Retrospective, mereka merencanakan peningkatan dalam manajemen waktu dan komunikasi tim untuk sprint berikutnya.

Dalam sprint berikutnya, tim mungkin memilih untuk menambahkan fitur notifikasi, integrasi dengan kalender, atau fungsionalitas lainnya sesuai dengan kebutuhan pelanggan dan umpan balik dari Sprint Review sebelumnya.

Studi kasus ini mencerminkan bagaimana Scrum dapat digunakan untuk mengelola proyek pengembangan perangkat lunak dengan fokus pada pengiriman nilai secara cepat dan terus-menerus, adaptasi terhadap perubahan kebutuhan, serta penggunaan umpan balik untuk perbaikan kontinu. (oai)