Penuhi tenggat waktu Anda: metode yang digunakan developer untuk memperkirakan upaya

Halo semuanya! Ada sejumlah besar teori yang perlu Anda ketahui untuk memulai pengembangan perangkat lunak. Beberapa spesialis (misalnya, pengembang backend yang menggunakan Java dan bahasa lain) mengetahuinya lebih banyak, sementara yang lain (misalnya, pengembang frontend yang menggunakan JavaScript dan React Native) mungkin mengetahuinya sedikit. Yang mengatakan, kedua kelompok harus memiliki tubuh besar tidak hanya teknis, tetapi juga "organisasi" pengetahuan. Pengetahuan "organisasi" ini merupakan satu area yang tumpang tindih untuk pengembang frontend dan backend. Hari ini saya ingin berbicara tentang aspek pengetahuan non-teknis dan organisasional ini. Hari ini kita akan berbicara tentang perkiraan usaha . Karena saya hanya punya pengalaman menggunakan metodologi Agile(yang dianggap paling populer), lebih khusus kerangka Scrum, saya akan mempertimbangkan estimasi upaya dalam konteks Scrum . Sejak awal, saya harus mengatakan bahwa estimasi upaya itu sulit. Bagi saya, ini adalah salah satu aspek pekerjaan saya yang paling menantang/tidak menyenangkan sebagai developer. Ada banyak faktor berbeda yang perlu dipertimbangkan yang dapat memengaruhi perkiraan upaya yang diperlukan untuk suatu tugas. Selain itu, rencana pengembangan masa depan akan didasarkan pada perkiraan Anda.

Bagaimana jika Anda memberikan perkiraan yang buruk?

Jika pengembang memperkirakan jauh lebih banyak jam untuk suatu tugas daripada yang akhirnya dihabiskan untuk tugas itu, keahlian mereka mungkin diragukan karena perkiraan itu sangat tidak akurat. Dengan kata lain, itu adalah tebakan liar. Pada saat yang sama, jika pengembang tidak menyelesaikan pekerjaan dalam waktu yang diperkirakan, dia membahayakan rencana pelanggan untuk merilis produk atau fitur baru. Ini adalah bisnis, dan bisnis adalah uang. Beberapa pelanggan akan senang dengan slip seperti itu. Faktanya, itulah mengapa saya tidak suka estimasi — karena terkadang sangat sulit untuk secara akurat menentukan waktu yang dibutuhkan untuk menyelesaikan suatu tugas.

Cara membuat estimasi waktu

Sebagai aturan, perkiraan dibuat dalam jam atau poin cerita. Preferensi pribadi saya adalah melakukan proses estimasi menggunakan poin cerita . Sulit untuk membuat kesalahan tentang objek fisik yang konkret, tetapi poin ceritanya sedikit lebih abstrak. Tim pengembangan perangkat lunak biasanya memberikan perkiraan jumlah waktu: jam, hari, minggu, bulan. Perkiraan waktu ini didasarkan terutama pada pengalaman pribadi, tebakan, dan/atau intuisi. Dalam hal ini, pengembang hanya melihat tugas dan menyatakan asumsi mereka tentang berapa lama waktu yang dibutuhkan. Akibatnya, estimasi tersebut sangat jarang akurat, karena terlalu banyak faktor yang dapat mempengaruhi durasi pekerjaan. Itu sebabnya banyak tim yang menggunakan metodologi Agile juga menggunakan poin cerita. Ayo selami!

Apa itu poin cerita?

Titik cerita adalah unit pengukuran untuk mengungkapkan perkiraan upaya total yang diperlukan untuk mengimplementasikan fungsi tertentu sepenuhnya. Artinya, kita berbicara tentang relatifkompleksitas. Tim menetapkan perkiraan poin cerita berdasarkan kompleksitas pekerjaan, volume pekerjaan, dan risiko atau ketidakpastian. Nilai-nilai ini biasanya ditugaskan untuk membagi pekerjaan menjadi bagian-bagian yang lebih kecil secara lebih efisien, sehingga menghilangkan ambiguitas. Seiring waktu, ini membantu tim memahami apa yang dapat mereka capai dalam periode waktu tertentu dan membantu mereka merencanakan bagian pekerjaan berikutnya dengan lebih akurat. Ini mungkin terdengar sangat berlawanan dengan intuisi Anda, tetapi abstraksi ini memang berguna: mendorong tim untuk membuat keputusan sulit tentang kerumitan pekerjaan. Mari kita lihat beberapa alasan untuk menggunakan poin cerita saat merencanakan:

• Anda dapat menghindari perkiraan waktu yang tidak akurat.
• Tidak seperti perkiraan yang dibuat dalam satuan waktu, poin cerita memungkinkan Anda memperhitungkan biaya overhead: komunikasi antara anggota tim dan pelanggan, berbagai diskusi tim dan aktivitas perencanaan, serta situasi yang tidak terduga.
• Setiap tim akan memperkirakan pekerjaannya dengan menggunakan skala yang berbeda-beda, artinya kapasitas mereka (diukur dengan poin) akan berbeda.
• Dengan menentukan skala untuk menetapkan setiap poin cerita, Anda dapat mengalokasikan poin dengan cepat tanpa banyak kontroversi.

Bagaimana TIDAK menggunakan poin cerita

Sayangnya, poin cerita sering disalahgunakan. Poin cerita bisa menyesatkan saat digunakan untuk menilai orang, menentukan tenggat waktu dan sumber daya yang terperinci, dan saat disalahartikan sebagai ukuran kinerja. Sebaliknya, tim harus menggunakannya untuk memahami ruang lingkup/kompleksitas setiap tugas dan menetapkan prioritas. Mungkin bagian-bagian yang dianggap lebih sulit harus ditangani terlebih dahulu, sehingga bisa diselesaikan sebelum sprint berakhir , mungkin mengalihkan tugas yang lebih mudah ke nanti. Izinkan saya mengingatkan Anda apa itu sprint dalam konteks metodologi Scrum : Lamanya periode waktu ini ditentukan saat pengembangan dimulai dan disepakati antara tim dan pelanggan. Ini bisa menjadi periode dua minggu atau sebulan, atau periode lainnya. Sebagai aturan, perkiraan upaya dibuat di awal setiap sprint untuk merencanakan pekerjaan yang dapat diselesaikan pada akhir sprint, saat pekerjaan yang telah selesai dikirim ke pelanggan. Demo membantu Anda melihat kemajuan Anda dalam mengembangkan produk, menerima umpan balik dari pelanggan, dan menyesuaikan lintasan proyek sesuai dengan visi pelanggan. Tapi kami ngelantur sedikit. Mari kita kembali ke perkiraan. Akan terlalu subyektif jika hanya satu pengembang yang memberikan perkiraan untuk semua tugas. Jadi proses ini biasanya merupakan upaya tim. Ada beberapa teknik yang dapat digunakan tim untuk menghasilkan perkiraan. Hari ini kita akan melihat teknik yang paling populer: scrum poker . Teknik ini membutuhkan seorang manajer yang akan bertindak sebagai moderator untuk scrum poker . Ini bisa seseorang yang merupakan master scrum atau mungkin seorang PM .

Apa itu scrum poker?

Scrum poker , atau poker perencanaan, adalah teknik estimasi yang didasarkan pada pencapaian kesepakatan. Ini terutama digunakan untuk memperkirakan kompleksitas pekerjaan di depan atau ukuran relatif dari tugas pengembangan perangkat lunak. Saya akan langsung mengatakan scrum poker ituadalah praktik pengembangan perangkat lunak yang umum, dan Anda perlu tahu tentang semua itu. Biasanya melibatkan aplikasi atau situs web untuk memfasilitasi pembuatan estimasi kolaboratif tim untuk tugas tertentu. Bagaimana ini bisa terjadi? Tim mengambil sesuatu dari backlog (tugas baru, beberapa fungsi) dan secara singkat membahas kemungkinan jebakan dan nuansa lain yang terkait dengannya. Kemudian setiap peserta memilih kartu dengan nomor yang mencerminkan perkiraan kerumitannya. Oh, satu lagi, saat membuat perkiraan ini, kami menggunakan angka deret Fibonacci daripada angka biasa. Angka Fibonacci populer di scrum poker, karena ada celah yang semakin lebar di antara keduanya (menyerupai tingkatan piramida). Beberapa tugas akan menjadi sangat rumit, dan kami tidak akan dapat lolos dengan sejumlah kecil poin cerita. Ada beberapa kartu yang tidak biasa yang memiliki arti sebagai berikut:

Jumlah titik akhir tidak diketahui

Tugas yang sangat panjang

Butuh istirahat

Metode estimasi yang kurang umum digunakan:

• Ukuran kaos — S, M, L, XL
• Trah anjing — chihuahua, pug, dachshund, bulldog, dan sebagainya (secara pribadi, menurut saya ini adalah satuan ukuran yang paling aneh untuk estimasi usaha =D)

Tim kemudian membandingkan perkiraan yang diberikan oleh pengembang yang berbeda untuk tugas yang sama. Jika mereka setuju, maka hebat! Jika tidak, maka alasan (argumen) untuk perkiraan yang berbeda perlu didiskusikan. Setelah itu, tim bekerja sama untuk membentuk perkiraan tunggal yang diterima semua orang, kurang lebih. Jadi mengapa poker bahkan digunakan untuk merencanakan proyek perangkat lunak yang serius? Anda harus mengakui bahwa ini aneh. Faktanya adalah gamifikasi semacam ini mendorong anggota tim untuk berpikir secara mandiri, mengundang mereka untuk mengungkapkan perkiraan mereka pada saat yang sama dengan rekan satu tim mereka. Ini, pada gilirannya, menghindari terciptanya situasi di mana beberapa anggota tim bergantung pada pendapat orang lain. Jika tidak dilakukan dengan cara ini, pengembang yang kurang berpengalaman akan melihat dan fokus pada estimasi yang diberikan oleh anggota tim yang lebih berpengalaman, dan itu akan membuat perkiraan mereka sendiri menjadi kurang berguna. Tetapi secara bersamaan menunjukkan perkiraan membuat hal ini pada dasarnya tidak mungkin. Penawaran Atlassianaplikasi scrum poker untuk digunakan dalam proses perencanaan.

Contoh estimasi upaya

Misalkan tim Anda menetapkan skala berikut untuk menetapkan poin cerita ke perkiraan: Scrum poker dimainkan untuk setiap tugas, dan Anda memberikan perkiraan sebagai berikut:

• Anda belum pernah menerapkan fungsi serupa sebelumnya: +3
• Fungsionalitas berukuran rata-rata: +2
• Implementasinya akan sangat kompleks: +3
• Tes penulisan untuk fungsionalitas akan sangat kompleks: +3

Menjumlahkan setiap komponen, Anda mendapatkan total 11 poin cerita, tetapi tidak ada kartu seperti itu, jadi Anda menyarankan 13. Seorang rekan kerja mengajukan perkiraan berikut untuk tugas tersebut:

• Dia telah bekerja dengan tugas serupa sebelumnya: +1
• Fungsionalitas berukuran rata-rata: +2
• Implementasinya akan menjadi kompleksitas rata-rata: +2
• Tes penulisan untuk fungsionalitas akan memiliki kompleksitas rata-rata: +2

Hasil perantaranya adalah 7 poin cerita, tetapi angka itu tidak ada dalam deret Fibonacci, jadi dia menyerahkan kartu dengan angka perkiraan paling banyak — 8. Anggota tim lain juga membuat perkiraan berdasarkan pandangan subjektif mereka. Kemudian semua orang menunjukkan kartu mereka dan Anda menemukan bahwa hampir semua rekan kerja Anda memberikan perkiraan 13, kecuali satu pengembang yang menyarankan 8. Dalam hal ini, dia diizinkan berbicara untuk memberikan alasan perkiraannya yang lebih rendah. Misalkan dia menawarkan pembenaran ini: dia sebelumnya mengerjakan tugas yang sama, dan itu tidak sesulit kelihatannya. Pada akhirnya, dia meyakinkan anggota tim lainnya untuk berubah pikiran dari 13 menjadi 8 poin cerita, dengan mengatakan bahwa dia akan membantu siapa pun yang akhirnya mengambil tugas ini. Atau mungkin dia akan melakukannya sendiri. Bagaimanapun, itu tidak Tidak masalah apakah yang lain menerima argumennya atau tidak, karena dengan satu atau lain cara, perkiraan akan diberikan untuk tugas tersebut, dan tim akan melanjutkan untuk mempertimbangkan yang berikutnya. Awalnya, perkiraan akan menjadi tidak akurat, begitu pula perkiraan jumlah pekerjaan yang Anda rencanakan untuk diselesaikan pada periode waktu berikutnya (sprint). Lagi pula, perkiraan ini dibuat dengan menggunakan perkiraan. Setelah beberapa waktu, mungkin tiga bulan kemudian, tim akan mulai memperkirakan waktu yang dibutuhkan untuk tugas dengan lebih akurat, dan jumlah rata-rata pekerjaan yang mampu dilakukan tim dalam sprint akan terlihat. Tapi ini adalah proses untuk membuat rencana umum untuk ruang lingkup pekerjaan. Ini berfokus terutama pada waktu, tetapi dalam hal ini mungkin ada banyak faktor relevan yang berbeda. Misalnya, seorang pengembang pergi berlibur selama dua minggu. Anda perlu memotong sejumlah pekerjaan terencana (fungsionalitas terencana). Atau misalkan pengembang baru telah bergabung dengan tim, tetapi belum sepenuhnya siap, jadi Anda perlu memberinya waktu untuk membiasakan diri dengan proyek melaluiproses orientasi . Ini bisa dua minggu, kurang lebih seminggu, tergantung pada kompleksitas proyek. Itu saja untuk hari ini! Saya harap saya sedikit meningkatkan pengetahuan Anda tentang perkiraan upaya, aspek non-teknis yang diperlukan dari pengembangan perangkat lunak. Jika Anda ingin mendalami topik ini lebih dalam, dan detail scrum, saya sangat menyarankan Anda membaca buku "SCRUM" oleh Jeff Sutherland. Saya tidak bisa berjanji apa-apa tentang konsekuensinya, karena setelah membacanya Anda akan memiliki keinginan yang mengganggu untuk menjadi master scrum =D