Estimasi Biaya Perangkat Lunak Dalam Manajemen Proyek Agile

pengantar

Salah satu hal tersulit yang harus dilakukan dalam pengembangan perangkat lunak adalah menentukan berapa lama dan berapa banyak waktu yang dibutuhkan untuk mengirimkan produk perangkat lunak baru. Haruskah begitu sulit? Jawabannya tidak langsung.

Estimasi biaya perangkat lunak pada dasarnya sulit, dan manusia sangat buruk dalam memprediksi hasil absolut. Tidak ada dua proyek yang sama; masing-masing unik dalam apa yang ingin dicapai dan unik dalam berbagai parameter yang membentuk keberadaannya. Seringkali, apa yang tampak sebagai masalah sederhana di permukaan jauh lebih sulit atau secara teknis menantang untuk diterapkan dalam kenyataan. Dan, tidak diragukan lagi, akan ada 'yang tidak diketahui' dengan proyek yang hanya dapat diidentifikasi ketika mereka muncul.

Selain itu, tidak ada dua orang yang sama, baik Anda pelanggan, pengembang, atau pengguna. Kami datang dengan seperangkat pengetahuan, pengalaman, nilai, harapan, sikap terhadap risiko, dan kemampuan untuk beradaptasi.

Menulis perangkat lunak berkualitas baik adalah roti dan mentega untuk insinyur senior; membuat produk perangkat lunak yang luar biasa bisa menjadi usaha yang jauh lebih sulit, untuk semua yang terlibat.

Tetapi ketika berbicara tentang perangkat lunak, memahami durasi dan biaya adalah kunci dalam membuat keputusan bisnis strategis dan ini benar apakah Anda membuat startup, mewujudkan peluang bisnis baru, atau memungkinkan bisnis Anda berkinerja lebih baik. Waktu, laba atas investasi, dan manfaat yang diberikan dapat membuat, mengguncang, atau menghancurkan bisnis Anda. Anda akan bertanya pada diri sendiri: Apa yang kita dapatkan dari uang kita? Bisakah kita memprediksi biaya kita? Berapa biaya untuk membuat produk yang kita inginkan? Kapan kita bisa meluncurkan? Akankah kita mendapatkan produk yang berkualitas untuk investasi kita? Apakah itu akan tumbuh dengan bisnis kita? Apakah itu akan memberikan nilai bisnis?

Jadi, bagaimana Anda memperkirakan ukuran, durasi, dan biaya proyek? Mari jelajahi estimasi proyek Agile dan biaya pengembangan perangkat lunak, dan bagaimana kami melakukannya di Toptal.

Penetapan Harga dan Estimasi Kontrak Tradisional

Secara tradisional, menggunakan praktik non-Agile, proyek perangkat lunak telah berusaha untuk memperbaiki fungsionalitas atau ruang lingkup dan membiarkan waktu dan biaya menjadi variabel. Ini menyebabkan masalah:

1. Bagaimana Anda tahu bahwa fungsi yang Anda perbaiki di awal proyek benar-benar merupakan fungsi yang paling baik melayani bisnis atau pelanggan Anda? Lebih sering daripada tidak, fungsionalitas atau ruang lingkup akan berubah, itulah sebabnya kami mendengar tentang 'scope creep', hasil dari kebutuhan yang diinginkan diidentifikasi melalui siklus hidup suatu proyek dan ditentukan sebagai perlu atau wajib

2. Ketika biaya menjadi variabel, kita kehilangan kendali atas laba atas investasi (ROI) yang ingin kita capai. Peningkatan biaya sering kali merupakan produk dari risiko yang tidak teridentifikasi atau persyaratan yang berubah, yang berarti kita harus menambah anggota tim untuk melakukan lebih banyak pekerjaan dalam kerangka waktu yang sama atau mempertahankan anggota tim lebih lama. Keduanya tidak diinginkan

3. Ketika waktu adalah variabel, kita kehilangan kendali atas posisi di pasar kita. Mungkin kita melewatkan tanggal industri yang penting atau pesaing kita mengeluarkan produk mereka sebelum kita, sehingga kehilangan keunggulan kompetitif yang mungkin dimiliki proyek kita.

Ada banyak hasil lain dari variabel waktu dan biaya, yang seringkali negatif dan tidak diinginkan.

Tentu saja, banyak pelanggan dan organisasi berusaha memperbaiki ketiga komponen 'segitiga ajaib' ini. Sayangnya, itu hampir mustahil untuk dicapai secara realistis. Ada terlalu banyak elemen yang berkonspirasi untuk menggoyahkan cita-cita ini, yang pada akhirnya berakhir dengan produk yang tidak memenuhi kebutuhan, terlalu lama untuk menguntungkan pelanggannya, atau terlalu mahal untuk mewujudkan nilai bisnis.

Kontrak Agile untuk Proyek Perangkat Lunak

Biaya adalah produk dari waktu dan orang (anggota tim). Tambahkan lebih banyak waktu, dan Anda menambahkan biaya untuk mempekerjakan orang lebih lama. Tambahkan lebih banyak anggota tim, dan Anda meningkatkan biaya untuk memberikan nilai bisnis yang sama. Hal-hal yang sangat ingin kita hindari. Inilah sebabnya mengapa prinsip Agile percaya pada pengaturan waktu dan anggota tim dan memungkinkan ruang lingkup menjadi komponen variabel.

Mana yang terdengar lebih baik dan meningkatkan kepercayaan pemangku kepentingan, biaya tetap atau biaya variabel?

Tentu saja, penting bahwa suatu produk memenuhi janji dan kebutuhan pelanggannya. Tidak ada gunanya menghabiskan jumlah waktu dan uang yang tepat jika, pada akhirnya, Anda memiliki produk yang tidak diinginkan atau dapat digunakan secara efektif oleh siapa pun.

Jadi kontrak Agile fokus pada hal berikut:

• Paket pekerjaan harga tetap - Seluruh proyek dipecah menjadi rilis 'mini' logis yang berkontribusi pada hasil produk penuh. Setiap rilis adalah paket kerja yang diberi harga yang sesuai. Setelah paket pekerjaan selesai, paket pekerjaan masa depan diperkirakan ulang berdasarkan apa yang telah kita pelajari dari yang sebelumnya. Ini menghindari kemungkinan yang tidak perlu dan memungkinkan tingkat prioritas ulang dan fitur baru/revisi ditentukan oleh pelanggan.

• Pengakhiran dini - Ini memungkinkan pelanggan untuk berusaha mengakhiri proyek lebih awal jika cukup banyak produk telah dikirimkan dan tidak ada ROI lebih lanjut yang harus dicapai dengan mempertahankan tim proyek yang hanya akan terus memberikan keuntungan marjinal. Klausul ini biasanya diperbolehkan kapan saja dan berlaku selama tim proyek dan pelanggan telah memelihara hubungan kerja sama yang kuat, saling percaya, dan erat. Manfaat bagi pelanggan adalah bahwa proyek akan selesai lebih awal, setelah memberikan semua fitur berharga yang diperlukan untuk membuat produk layak. Sebagai imbalannya, pemasok dibayar 20 persen dari nilai kontrak yang tersisa dan mengimbangi risiko mempertahankan staf.

• Perubahan fleksibel - Perubahan adalah tema yang berjalan kuat melalui pembuluh darah pengiriman perangkat lunak Agile. Kami berharap untuk tidak mengetahui semua yang kami butuhkan untuk membuat produk sukses sejak awal. Jadi, kami mempromosikan perubahan, berdasarkan data dan umpan balik yang relevan, untuk memastikan bahwa produk yang tepat dikirimkan. Di akhir iterasi, perubahan dapat ditukar dengan fitur lama yang tidak lagi dianggap perlu atau prioritas. Selama perubahan itu bernilai sama, tidak ada biaya lebih lanjut. Jika perubahan bernilai lebih rendah, pekerjaan tambahan dapat diidentifikasi atau ditarik dari sisa simpanan. Klausul ini berlaku selama tim proyek dan pelanggan telah memelihara hubungan kerja sama yang kuat, saling percaya, dan erat selama proyek berlangsung.

• Pekerjaan tambahan - Selama masa proyek, lebih banyak fitur dapat diidentifikasi yang tidak dapat dicapai berdasarkan kontrak harga tetap yang ada. Untuk skenario ini, paket pekerjaan baru dengan harga baru dapat ditambahkan ke akhir proyek atau kembali ke waktu dan bahan.

• Perkiraan berkisar - Ada dua cara agar perkiraan dapat berkisar dalam kontrak proyek Agile: rentang durasi atau rentang fitur. Rentang durasi memungkinkan perkiraan untuk mengatakan bahwa proyek atau paket pekerjaan akan memakan waktu 12 hingga 16 minggu untuk serangkaian ruang lingkup tertentu. Namun, menambahkan durasi menambah biaya saat Anda mempertahankan anggota tim proyek lebih lama, atau itu berarti mereka tidak dapat dilepaskan untuk mengerjakan proyek pengembangan lainnya. Di Toptal, kami lebih memilih untuk membuat rentang fitur di berbagai titik cerita, menjaga ruang lingkup sebagai variabel tetapi menjanjikan untuk memberikan tingkat nilai minimum kepada pelanggan dalam kerangka waktu tetap dari paket pekerjaan atau proyek keseluruhan.

Perlu diingat bahwa Anda selalu dapat menambahkan lebih banyak cakupan nanti. Mungkin Anda sudah mulai memperoleh pendapatan, Anda telah meningkatkan pengguna atau mengurangi biaya. Either way, jauh lebih mudah untuk meminta lebih banyak uang dan waktu jika Anda telah menunjukkan pengembalian atau peningkatan dan memberikan nilai bisnis.

Pendekatan kami terhadap biaya dan harga perangkat lunak

Di Toptal kami bekerja sama dengan pelanggan dan insinyur kami untuk menggunakan teknik yang meningkatkan kepercayaan pemangku kepentingan dalam durasi dan biaya proyek. Kami bekerja untuk terus mengelaborasi dan mengadaptasi perencanaan dari tingkat awal yang tinggi hingga ke detail yang lebih terperinci bila diperlukan dan tepat untuk menghindari pemborosan dan memungkinkan perubahan yang terkelola.

Langkah-langkah berikut diambil dalam mengelaborasi proyek perkiraan dan harga tetap:

1. Cakupan tingkat tinggi awal

Pada awal proyek, kita paling tidak tahu tentang hasil akhirnya. Adalah bodoh untuk membayangkan mengetahui secara pasti fitur apa yang dibutuhkan pelanggan dan pengguna kami sejak awal.

Jadi, kita mulai dengan piagam proyek dan serangkaian fitur "epik" tingkat tinggi yang memandu arah proyek, berdasarkan visi dan tujuan yang baik.

Sebuah. Pengaturan Visi dan Tujuan Apa yang perlu kita bangun? Apa yang perlu Anda capai dan apa tujuan bisnis Anda? Memahami pertanyaan-pertanyaan ini memungkinkan kita untuk mengatur skala proyek. Apakah Anda memerlukan prototipe untuk menguji ide, konsep, atau teknologi awal? Sudahkah Anda mengidentifikasi proposisi yang jelas yang telah diuji dengan pasar Anda dan apakah Anda siap untuk membangun Minimal Viable Product (MVP) pertama Anda? Atau, apakah Anda menskalakan bisnis atau produk Anda yang sudah ada untuk membawanya ke tingkat berikutnya?

B. Fitur "epik" tingkat tinggi Tanpa terlalu detail, Anda pasti ingin menentukan fitur yang dimiliki produk Anda untuk memenuhi kebutuhan pelanggan Anda. Ini adalah "daftar belanja" terstruktur yang menggambarkan tulang telanjang produk Anda; sering ini disebut sebagai "Kisah Pengguna" atau epos

C. Analisis MoSCoW Analisis MoSCoW adalah teknik yang, secara sederhana, membantu mengidentifikasi apa yang benar-benar diperlukan untuk membuat produk layak dan apa yang bagus untuk dimiliki. Mereka yang diidentifikasi sebagai "Harus" memenuhi apa yang akan mendorong pengguna untuk terlibat dan mengadopsi produk Anda. Fitur-fitur yang diidentifikasi sebagai "Seharusnya" akan mengejutkan dan menyenangkan pelanggan Anda, tetapi dapat dibangun nanti. Item "Bisa" sering kali tidak menambah nilai bisnis yang signifikan, mungkin tidak meningkatkan pengembalian dan merupakan prioritas terendah Anda. Fitur "Tidak Akan" bisa menjadi penting suatu hari nanti tetapi berada di luar cakupan untuk iterasi proyek ini. Namun, mengidentifikasi ini sekarang dapat membantu untuk mengingat potensi skala dan ukuran produk untuk masa depan.

2. Usulan

Untuk membuat keputusan apakah akan melanjutkan proyek, keputusan itu perlu didasarkan pada data yang terinformasi dengan baik: biaya dan durasi. Ini adalah minimum yang perlu Anda tanyakan pada diri sendiri: Apa yang diperlukan untuk membuat produk yang kita inginkan? Kapan kita bisa meluncurkan? Apakah ini sejalan dengan strategi bisnis dan keuangan kita?

Dengan rincian di atas, kami siap untuk memberikan proposal. Teknisi kami dipilih sendiri untuk persyaratan proyek tertentu dan bekerja sama dengan manajer proyek untuk mendapatkan setidaknya satu solusi teknis, perkiraan durasi yang memberikan cakupan yang diketahui, dan perkiraan biaya untuk menyelesaikan proyek.

Seperti yang kami sebutkan sebelumnya, pada awal proyek, kami paling tidak tahu tentang apa yang akan disampaikan. Kami sengaja merahasiakan fitur dan cakupannya, karena untuk melakukan sebaliknya menunjukkan bahwa kami tahu persis apa yang diperlukan. Perkiraan pada tahap ini akan menjadi yang paling tidak akurat tetapi memberikan panduan tentang apakah proyek layak dilanjutkan.

Proposal adalah alat pertama dalam mengelaborasi durasi dan biaya proyek. Setelah proposal diterima, kami dapat bergerak maju untuk memberikan penawaran harga tetap.

3. Perencanaan Rilis

Tingkat elaborasi perkiraan berikutnya adalah membuat rencana rilis yang akan memberikan berbagai fitur dalam jangka waktu tertentu. Kami memperoleh ini dari daftar fitur, ukuran proyek, seberapa cepat tim kami dapat mengembangkan perangkat lunak berkualitas yang memenuhi harapan pelanggan dan teknik untuk mengelola risiko ketidakpastian.

Sebuah. Product Backlog Product backlog hanyalah daftar "Epik" atau "Kisah Pengguna" yang diurutkan yang mewakili fitur yang diperlukan untuk suatu produk. Daftar ini mulai hidup sebagai epos yang dibahas sebelumnya, tetapi antara tim proyek yang ditugaskan, manajer proyek, dan pelanggan, kami sekarang memecahnya menjadi item yang lebih bermakna. Setiap item mewakili sebagian dari nilai bisnis kepada pelanggan. Kami tidak masuk ke lebih detail pada tahap ini, kami tidak perlu mengetahui kriteria penerimaan, kami tidak perlu tahu apakah tombol berwarna biru atau hijau, kami hanya perlu tahu ada tombol yang memungkinkan beberapa tugas untuk dilakukan.

B. Estimasi Sekarang setelah kami memiliki daftar fitur yang digambarkan sebagai cerita pengguna, tim memperkirakan item fitur terpisah ini menggunakan teknik yang disebut “Perencanaan Poker.” Ini adalah teknik berguna yang memastikan hasil yang cepat dan andal berdasarkan pendapat ahli dan ukuran analog. Perencanaan Poker memberikan nomor yang disepakati untuk setiap item yang mewakili ukuran dan kompleksitasnya. Ini disebut titik cerita. Teknik dan ukuran estimasi Agile lainnya, seperti 'hari ideal', tersedia.

Akhir dari proses ini akan menentukan ukuran proyek dan ketergantungan antar fitur. Ukuran ditentukan dengan menjumlahkan semua poin cerita dari item dalam backlog produk. Jika angka itu sama dengan 120, maka ukuran proyek kita adalah 120 poin cerita.

C. Prioritas Sekarang kami memiliki backlog dan ukuran untuk proyek, kami berada dalam posisi untuk memprioritaskannya dengan pelanggan. Ini benar-benar tentang mengidentifikasi apa yang paling berharga bagi pelanggan untuk mencapai hasil yang diinginkan. Item di bagian atas daftar dianggap paling penting, item kedua kurang penting dari yang pertama, dan seterusnya melalui daftar. Tidak ada dua item yang bisa sepenting yang lain, prioritas setiap item relatif penting atau bernilai untuk masing-masing item lainnya.

Pendekatan prioritas ini merupakan tonggak penting dalam perencanaan proyek perangkat lunak. Kami sekarang tahu apa yang penting bagi pelanggan dan dalam rangka untuk menyelesaikan pekerjaan, menjaga ketergantungan, untuk memberikan produk yang memenuhi harapan.

D. Perencanaan Rilis Sampai saat ini, kami telah menentukan produk apa yang kami yakini dan seberapa besar itu.

Sekarang, kami menentukan berapa lama waktu yang dibutuhkan untuk mengirimkan produk yang dapat dirilis. Pelanggan dan tim, termasuk desainer, insinyur, penguji, master scrum, dan manajer proyek, bekerja sama untuk mengidentifikasi apa yang dapat dicapai dan seberapa cepat pekerjaan dapat dilakukan untuk membuat rencana rilis.

Rencana rilis juga memberikan wawasan tentang bagaimana proyek akan selaras dengan rencana strategis pelanggan.

Dan akhirnya, rencana ini memastikan tim proyek memiliki cahaya penuntun yang memimpin dan menentukan titik akhir yang logis untuk pengembangan.

Sebelum memulai, kami memastikan bahwa kami memahami definisi "selesai" yang disepakati. Ini adalah serangkaian kriteria tertentu yang akan diterima pelanggan sebagai lengkap dan juga memenuhi semua persyaratan teknik untuk dianggap dapat dirilis.

Untuk mengambil skenario dasar, kami mengambil jumlah total poin cerita yang kami dapatkan dari mengukur backlog kami dan membaginya dengan kecepatan yang diantisipasi tim kami. (Kecepatan NB biasanya dinyatakan sebagai rentang, tetapi untuk kesederhanaan, kami akan menggunakan satu angka di sini.) Kami bekerja dalam iterasi dua minggu sehingga kecepatan kami akan tercermin oleh seberapa banyak yang dapat kami selesaikan dalam siklus dua minggu dengan yang tersedia kapasitas tim. Jika poin cerita kami berjumlah 120 dan kami mengantisipasi menyelesaikan 20 poin per iterasi, total durasi pengembangan adalah 12 minggu atau 6 iterasi. Kami menambahkan sprint 0 dari 2 minggu dan sprint persiapan rilis dua minggu. Secara total, panjang proyek kami adalah 16 minggu. Ada beberapa teknik yang dapat kita gunakan yang akan membantu membangun penyangga risiko yang sesuai ke dalam perencanaan kita, yang akan kita bahas nanti. Tapi singkatnya, kami menggunakan buffer untuk mengelola risiko ketidakpastian dan mencapai kesepakatan minimum poin cerita yang diharapkan untuk disampaikan. Hasilnya mungkin berkisar antara 90 hingga 150 poin cerita yang disampaikan, 90 adalah jumlah minimum yang dapat diterima untuk membuat produk yang layak.

Alternatifnya, jika proyek harus diselesaikan pada tanggal tertentu, katakanlah 10 minggu, tim akan menentukan berapa banyak backlog yang dapat diselesaikan dalam waktu tersebut. Jika kami mengantisipasi 20 poin cerita per sprint, ditambah Sprint 0 dan rilis sprint, kami akan menargetkan 60 poin selesai pada akhir proyek. Sekali lagi, kami akan berupaya mengelola risiko dengan menambahkan buffer yang sesuai, yang mungkin menghasilkan target 45 hingga 75 poin cerita yang diselesaikan dan siap untuk dirilis. 45 poin cerita akan selaras dengan minimum yang dapat diterima untuk menghasilkan produk yang layak dan berharga. Ini adalah salah satu skenario di mana Anda mungkin berharap untuk menambahkan anggota tim untuk meningkatkan kecepatan, jika sesuai.

Tentu saja, semua hal di atas didukung oleh komunikasi dan kolaborasi yang berkualitas antara semua pihak untuk mendapatkan rencana rilis yang dapat dicapai, realistis, dan dapat diterima oleh pelanggan.

4. Kontrak Harga Tetap

Setelah rencana rilis disetujui, kami dapat membuat penawaran untuk kontrak proyek dengan harga tetap. Seperti disebutkan sebelumnya, disarankan untuk menjaga durasi proyek dan tim tetap dan variabel ruang lingkup.

Penawaran untuk kontrak harga tetap disampaikan bersama dengan pernyataan kerja dan jadwal pembayaran yang disepakati.

Selama ada kepercayaan, komunikasi, kolaborasi, dan kesiapan untuk masuk ke dalam semangat proyek perangkat lunak Agile, semua langkah di atas memungkinkan kami untuk memberikan penawaran dengan tingkat keyakinan yang realistis bahwa proyek akan selesai tepat waktu dan pada anggaran. Tentu saja, akan ada saat-saat di mana sebuah proyek dikirimkan lebih awal atau terlambat dan kami menangani variasi ini dengan sangat transparan.

Teknik Estimasi

Perencanaan dan estimasi yang gesit didukung oleh sejumlah teknik yang dapat digunakan tim pengembangan untuk mendapatkan kepercayaan diri dalam ukuran, upaya, durasi, dan biaya mereka. Berikut adalah beberapa yang digunakan tim kami untuk memperkirakan ukuran dan biaya proyek perangkat lunak.

Memperkirakan Ukuran

Ukuran proyek benar-benar merupakan apresiasi dari ruang lingkup, kompleksitas, dimensi, risiko, dan besarnya. Untuk menggunakan analogi, ini tentang memahami jika kita sedang membangun Menara Eiffel atau Tembok Besar China. Menara Eiffel adalah tinggi, berat, struktur kompleks yang dibangun di lingkungan perkotaan yang ketat. Tembok Besar China adalah struktur yang relatif sederhana, tetapi panjang dan kokoh yang membentang bermil-mil medan bergelombang.

Meskipun keduanya akan menjadi proyek besar untuk dilaksanakan, cakupan, kompleksitas, dimensi, besaran, dan oleh karena itu ukurannya berbeda.

Sangat penting untuk mengelola ekspektasi dengan estimasi. Mereka tidak pernah prediksi, komitmen atau jaminan. Saat mendiskusikan ukuran total, total durasi, dan total biaya, kami selalu bekerja dalam rentang, untuk mengurangi risiko, ketidakpastian, dan hal yang tidak diketahui.

Cerita yang mewakili fitur produk Anda berukuran individual dan diperkirakan menggunakan poin cerita atau hari yang ideal. Jumlah total unit ini menentukan ukuran total proyek.

Poin Cerita

Poin cerita adalah unit ukuran yang mengekspresikan ukuran keseluruhan cerita pengguna. Ukuran sebuah cerita, bila diperkirakan, mencakup semua aspek desain, teknik, pengujian, tinjauan kode, integrasi, dll.

Setiap ukuran cerita relatif terhadap cerita lain. Jadi misalnya, Cerita A dapat berukuran satu titik, Cerita B sebagai dua titik dan Cerita C sebagai tiga titik. Di sini, Cerita C setidaknya tiga kali lebih besar dari Cerita A dan setidaknya setengah lebih besar dari cerita B.

Jika cerita berikut dalam backlog produk kami memiliki ukuran terkait:

Ukuran total proyek adalah 12 poin cerita.

Hari Ideal

Ini adalah ukuran ukuran yang dinyatakan dalam hari. Ini menghilangkan konsep overhead seperti interupsi, aktivitas perencanaan tangkas, membaca email, dan aktivitas non-proyek lainnya. Ini hanya berkonsentrasi pada berapa lama waktu yang dibutuhkan jika Anda mengerjakan sesuatu terus menerus tanpa gangguan, daripada waktu yang berlalu dari awal hingga selesai.

Biasanya, ketika memperkirakan pada tingkat tinggi ketika kita tahu paling sedikit tentang suatu proyek, kita akan memperkirakan pada hari-hari yang ideal karena ini adalah konsep yang lebih mudah untuk dikorelasikan dengan sejarah dan pengalaman masa lalu daripada angka abstrak seperti titik cerita. Terutama ketika cerita pada level tinggi lebih bersifat epik dengan sedikit detail dan mungkin mengandung elemen tambahan ketika dirinci di kemudian hari.

Ketika memperkirakan pada tingkat yang lebih terperinci, katakanlah sebuah cerita dalam jaminan simpanan produk yang sudah mapan, salah satu pendekatan dapat digunakan dan akan diputuskan oleh tim teknik. Ada manfaat untuk kedua pendekatan dan setiap tim akan memiliki preferensinya sendiri.

Teknik untuk Memperkirakan

Estimasi Bersama Estimasi tidak dilakukan secara terpisah. Mereka dilakukan secara kolaboratif oleh seluruh tim teknik bersama-sama dan mencakup desain, database, server, UI front-end, QA, dan pakar lintas fungsi lainnya. Ini menghindari masalah tidak mempertimbangkan semua aspek pekerjaan yang terlibat untuk menyelesaikan fitur dan memastikan bahwa tidak ada orang yang memiliki beban atau kemalangan atas atau meremehkan ukuran fitur. Tim gabungan semua akan memiliki pandangan yang dapat didiskusikan dan disepakati.

Estimasi Analog Di sinilah kita mempertimbangkan dua fitur diskrit dan memutuskan bahwa yang satu relatif lebih kecil atau lebih besar dari yang lain. Kita dapat melihat cerita yang diberikan dan setuju bahwa itu berukuran kecil, dan jika menggunakan poin cerita, kita mungkin memberikan ukuran dua. Cerita berikutnya mungkin dianggap lebih besar dibandingkan dengan yang pertama, dan kami akan memberikan ukuran lima. Ini menunjukkan bahwa besar setidaknya dua kali ukuran fitur kecil.

Kami akan melanjutkan latihan ini dengan semua cerita. Setelah selesai, kami kemudian dapat meletakkan semua lantai kecil, sedang, besar, dan ekstra besar berdampingan dan memeriksa ukuran kami untuk memastikan ada tingkat keseragaman dalam perkiraan kami.

Perencanaan Poker Banyak yang telah ditulis tentang Perencanaan Poker; Saya juga menyebutkannya di blog saya sebelumnya. Salah satu sumber terbaik untuk memahaminya ada di sini.

Intinya, menggabungkan pendapat ahli, analogi, dan kolaborasi tim menjadi satu proses yang mudah, cepat, dan andal.

Ini menyatukan beberapa pakar yang paling cocok untuk membuat perkiraan berdasarkan pengalaman teknis dan domain, dialog yang hidup, dan pembenaran yang masuk akal.

Kecepatan

Velocity adalah ukuran kapasitas tim untuk menyelesaikan pekerjaan dalam iterasi (atau sprint) tertentu.

Ini dinyatakan sebagai rentang, misalnya, 23 hingga 32 poin cerita per sprint, terutama di awal kehidupan proyek. Umumnya, ini karena kecuali tim yang sama telah bekerja sebelumnya pada masalah yang sama, sulit untuk menggambarkan dengan tepat apa kecepatan tim nantinya. Perhatikan, kami mengacu pada kecepatan tim dan bukan kecepatan individu!

Kami menggunakan kecepatan untuk merencanakan rilis kami dan menyesuaikan rencana dan paket kerja kami saat kami maju melalui sebuah proyek, sehingga memungkinkan kami untuk menyesuaikan perkiraan kami untuk penyelesaian secara teratur dan akurat melalui eksekusi.

Ketika kami memulai, kami dipaksa untuk menentukan rentang kecepatan dengan data yang sangat sedikit. Kita dapat menggunakan nilai historis jika tim dan ruang masalah sama, yang seringkali paling kecil kemungkinannya. Kita dapat menjalankan iterasi untuk mendapatkan gambaran kecepatan dari tim yang benar-benar mengerjakan proyek, tetapi ini mahal dan tidak berhasil jika keputusan masih harus dibuat untuk menyetujui memulai proyek. Atau, kita bisa membuat ramalan.

Peramalan kecepatan melibatkan pengambilan cerita senilai sprint dan membaginya menjadi tugas-tugas yang dilakukan untuk menyelesaikan cerita. Kami akan memperkirakan jumlah jam yang dibutuhkan setiap tugas, yang mencakup desain, pengembangan, pengujian, dan sebagainya, dan menilai berapa banyak kapasitas yang akan dimiliki tim dalam sprint tertentu. Kapasitas 70 persen untuk tim yang tidak terbebani adalah dasar yang baik. Jadi, dalam situasi sederhana, jika total jam yang tersedia untuk tim adalah:

• 4 anggota tim * dua minggu * 40 jam per minggu = 320 jam
• Dikalikan dengan kapasitas 70 persen kami = 224 jam
• Tambahkan semua tugas fitur dan berhenti menghitung di 224
• Ambil semua fitur yang sudah selesai, tambahkan poin cerita mereka dan Anda mendapatkan kecepatan Anda, katakanlah 36
• Terapkan 20 persen di kedua sisi untuk mendapatkan kisaran terendah dan tertinggi, untuk sampai pada perkiraan kecepatan 29 hingga 43 titik cerita.

Kecepatan biasanya bervariasi dalam dua hingga empat iterasi pertama dan kemudian stabil dalam rentang titik yang kecil. Jadi, di mana rentang awal kami sebelum sprint satu adalah 29 hingga 43, pada sprint empat, mungkin akan naik dari 34 menjadi 38. Ini kemudian memberi kami kepercayaan diri yang lebih besar dalam memperkirakan tanggal penyelesaian akhir kami.

Rencana Penyangga untuk Risiko & Ketidakpastian

Semua proyek perangkat lunak datang dengan tingkat ketidakpastian. Ketidakpastian itu menjadi berkurang seiring kemajuan kami melalui proyek dan lebih banyak yang diketahui tentang teknologi, lingkungan, kinerja, dan kebutuhan pelanggan dan pengguna kami.

Kami mengurangi ketidakpastian atau risiko ini dengan buffer dalam jadwal, yang memperhitungkan margin kesalahan dalam estimasi kami dan hal yang tidak diketahui yang tidak dapat kami tentukan sebelum pengembangan dimulai.

Biasanya, ada dua jenis buffer: Fitur dan Jadwal. Karena kami sering menentukan harga tetap untuk tanggal pengiriman tetap, lebih baik menggunakan buffer Fitur.

Pendekatan ini memberi kami strategi mitigasi risiko yang kredibel dan memberikan kepercayaan kepada pelanggan tentang apa yang harus mereka harapkan sebagai hasil ketika proyek selesai.

Buffer Fitur

Dengan buffer fitur, kami memperkirakan bahwa kami akan memberikan serangkaian fitur tertentu tetapi idealnya akan menyelesaikan serangkaian fitur lebih lanjut. Ini harus mencerminkan setidaknya set fitur minimum yang dianggap perlu oleh pelanggan untuk meluncurkan produk yang layak, tetapi lebih banyak yang dapat dikirimkan dalam kerangka waktu jika semua pengaruh internal dan eksternal memungkinkannya.

Jadi, pelanggan dapat memutuskan bahwa fitur prioritas tertinggi dari backlog produk, menambahkan hingga 100 poin cerita, adalah yang paling penting. Mereka kemudian dapat mempertimbangkan fitur tambahan yang menambahkan hingga 30 poin cerita lebih lanjut. Oleh karena itu, tim akan merencanakan berdasarkan pengiriman 130 poin cerita, dengan minimal 100 poin diselesaikan pada akhir tanggal penyelesaian yang dijadwalkan untuk kontrak harga tetap yang diberikan.

Beberapa pemikiran penutup

Agile bisa menjadi konsep yang sangat sulit untuk dipahami dan diadopsi sepenuhnya. Hal ini juga berlaku saat mengelola topik sensitif seperti harga, cakupan, dan durasi. Sayangnya, saya tahu secara langsung bahwa klien yang menuntut ingin semua hal diperbaiki di muka dan ingin sekali menyalahkan pemasok ketika semuanya mulai terurai. Demikian pula, saya menyadari vendor yang menggali tumit mereka, menjadi tidak responsif dan gagal menanggapi kebutuhan pelanggan. Mengambil jalur Agile pada dasarnya dibangun di atas kepercayaan, hubungan baik, dan komunikasi yang luar biasa. Ini harus menjadi nilai-nilai yang dipegang oleh kedua belah pihak untuk mempertahankan proyek yang sehat untuk manfaat, kepuasan, dan kesuksesan yang sama bagi semua yang terlibat. Menjaga pikiran terbuka dan sikap konstruktif terhadap kolaborasi dan negosiasi adalah cara terbaik untuk menghindari hubungan menjadi buruk.

Saya telah bekerja dengan klien yang merasa sulit untuk merangkul sifat adaptif Agile dan melepaskan sikap perintah-dan-kontrol. Sulit untuk melepaskan dan menaruh semua keyakinan dan kepercayaan Anda pada tim yang tidak Anda kenal. Seringkali, klien mungkin ingin membuat semua persyaratan di muka sebagai spesifikasi dari apa yang akan dikirimkan. Ini memberi mereka perasaan percaya diri bahwa ruang lingkup proyek didefinisikan dengan baik. Tetapi pada akhirnya, ini gagal terwujud sebagai pendekatan yang berhasil. Jika kita terkunci pada ruang lingkup dan tuntutan yang tidak realistis dalam kontrak, masalah muncul dengan sangat cepat.

Kami tahu, ketika mengambil pendekatan ini dalam metode tradisional, ruang lingkup berubah, hal yang tidak diketahui terungkap atau apa yang kami pikir diinginkan pelanggan tidak lagi benar atau jauh dari sasaran. Mengambil pendekatan adaptif untuk penetapan harga, perencanaan, dan ruang lingkup memungkinkan pelanggan untuk benar-benar mengidentifikasi produk mereka sesuai dengan kebutuhan pasar mereka. Hal ini memungkinkan vendor untuk menjadi responsif, imajinatif dan efisien juga. Memanfaatkan kolaborasi antara pelanggan dan vendor melalui negosiasi kontrak adalah kuncinya.

Vendor harus jujur ​​dan pelanggan harus realistis tentang apa yang dapat dicapai sejak awal. Vendor yang menjanjikan target yang tidak realistis dan kemudian meningkatkan biaya dapat memenangkan kontrak awal, tetapi akan segera kehilangan dukungan dari pelanggan yang tidak puas. Terlalu sering, hubungan rusak karena kurangnya kepercayaan atau kepercayaan di antara pihak-pihak. Kepercayaan harus dibangun sejak awal dan dipertahankan selama proyek berlangsung. Vendor harus fleksibel dan bekerja sama dengan perubahan kebutuhan. Pelanggan selalu menginginkan lebih; itu adalah konsekuensi alami dari melakukan bisnis. Harus ada pertukaran nilai yang setara dan menguntungkan antara kedua belah pihak. Bagi pelanggan, mereka ingin menciptakan nilai bagi bisnis mereka. Untuk vendor, mereka harus mencari cara untuk menciptakan nilai dengan membentuk hubungan jangka panjang dengan pelanggan. Mematuhi nilai-nilai dan prinsip panduan Agile Manifesto adalah dasar yang kuat untuk membentuk hubungan yang kuat, seimbang, dan panjang.

Ringkasan

Saya harap ini memberi Anda beberapa wawasan tentang perencanaan, perkiraan, dan penetapan harga untuk proyek perangkat lunak Agile. Semua pendekatan dan teknik di atas dirancang untuk membangun kepercayaan dalam tim dan untuk membangun kepercayaan di benak pelanggan tentang berapa lama dan berapa banyak waktu yang dibutuhkan untuk membangun produk perangkat lunak. Dan pada akhirnya, untuk membangun kepercayaan diri dalam mengambil keputusan untuk melanjutkan.

Ikuti panduan ini dan Anda pasti akan menemukan rute yang memuaskan untuk menghidupkan produk perangkat lunak Anda.