Selama menjadi pembelajar di Apple Developer Academy @ BINUS, saya berkesempatan menjadi Project dan Product Manager selama 4 bulan terakhir, dalam membangun KOBAR, aplikasi edukasi gamifikasi.

Mendukung tim saya sebagai Manajer Proyek dan Produk, Manajemen Proyek memiliki banyak alat yang dapat digunakan, baik dalam metodologi kerja maupun dalam perangkat lunaknya sendiri. Selama 4 bulan, tim saya telah menggunakan metodologi SCRUM yang sudah menjadi rutinitas bagi tim untuk mengadakan sprint meeting, daily scrum, sprint review dan sprint retrospective.

• Sprint mengontrol mekanisme seret yang membatasi kelebihan aliran masuk,
• Perencanaan sprint memungkinkan penilaian diri dari setiap tugas yang memulai kejernihan dan pertumbuhan sehubungan dengan DoD (Definition of Done).
• Pengembangan Scrum harian meningkatkan koordinasi antar tim untuk menunjukkan dan mengekspresikan ide-ide mereka.
• Tinjauan sprint mencakup tim scrum bersama dengan pemegang saham lainnya. Yang menerima umpan balik dari tim scrum dan juga pemeriksaan telah dilakukan di sini.
• Sprint retrospektif memberikan kesempatan untuk memeriksa rintangan untuk saat ini dan menerima tambahan untuk sprint yang akan datang.

Kami menggunakan bantuan JIRA untuk manajemen proyek karena dalam perangkat lunak ini, kami dibantu untuk dapat mendelegasikan tugas dengan mudah kepada setiap individu, dibantu jika akan ada masalah anak di backlog.

“Mereka yang merencanakan lebih baik daripada mereka yang tidak merencanakan, meskipun mereka jarang berpegang pada rencana mereka.” —Winston Churchill

Pada awal periode proyek, semua backlog masih dapat diselesaikan sesuai dengan waktu yang telah ditentukan. Pembagian tugas, jelas dan terstruktur sesuai dengan timeline yang diinginkan. Namun ketika sudah memasuki masa pengembangan banyak sekali yang harus disesuaikan sehingga sedikit membebani tim dalam menyelesaikan tugas yang diberikan.

Di sinilah masalah muncul, seringkali ketika tugas seharusnya sudah selesai dan memulai sprint berikutnya, tim belum bisa menyelesaikannya. Awalnya kami bingung kenapa? apakah waktu yang diberikan tidak cukup?

Namun diketahui bahwa masalah utamanya adalah,

ada terlalu banyak backlog dalam satu sprint, di mana kita tidak bisa menyelaraskan harapan dengan kenyataan.

Lalu mengapa masalah ini terjadi?

• Kami melebih-lebihkan apa yang bisa kami selesaikan dalam satu iterasi.
• Salah satu item pekerjaan jauh lebih besar dari yang kami perkirakan.
• Injeksi layanan/pekerjaan yang tidak direncanakan masuk ke dalam iterasi.

Pahami akar penyebabnya dan temukan cara menghindarinya. Tim saya menggunakan retrospektif sprint untuk mengevaluasi penyebabnya dan belajar darinya. Setiap orang dalam tim berbagi perspektif mereka dan cara mengatasinya.

Diskusikan masa depan setiap backlog

• Jika backlog memiliki prioritas tinggi, memindahkan backlog yang sama ke sprint berikutnya akan sangat membantu . Mungkin waktu yang diberikan tidak cukup dengan ukuran item pekerjaan jadi masih oke
• Jika backlog memiliki prioritas rendah, tentukan apakah backlog dapat dipecah dan pindahkan pekerjaan yang tertunda ke dalam product backlog.

Semua itu berdasarkan pengalaman saya dan didukung oleh narasumber dari:

Umpan balik apa pun sangat dihargai! tolong pukul aku di sini !

© 2022 Nathania Joyce Irene. Seluruh hak cipta.