Bagaimana Anda menghadapi perubahan persyaratan? [Tutup]

Dalam pekerjaan saya saat ini, rasanya kita memiliki banyak perubahan persyaratan. Kami adalah toko "Agile", jadi saya mengerti bahwa kami seharusnya menyesuaikan dan tidak, tetapi kadang-kadang perubahannya besar dan tidak ada yang sepele.

Pertanyaan saya adalah, bagaimana Anda mengkomunikasikan biaya perubahan secara efektif? Karena gesit, jika perubahan cukup besar sesuatu akan turun dari sprint saat ini, tetapi biasanya hanya ditambahkan di waktu berikutnya. Karena model kami adalah SaaS, pelanggan akhir secara efektif adalah bisnis itu sendiri, dan mereka tahu mereka akan mendapatkan fitur pemotongan n minggu kemudian.

Saya kira apa yang saya coba dapatkan adalah penghapusan fitur yang sebenarnya tidak ada hubungannya dengan komunikasi karena hanya ditunda oleh n minggu. Apa cara lain yang Anda miliki untuk membuat bisnis memahami apa yang biaya perubahan?

@ Jo "Kami adalah toko" Agile ", jadi saya mengerti bahwa kita seharusnya menyesuaikan dan tidak, tetapi kadang-kadang perubahannya besar dan tidak ada yang sepele."

Jika proses Anda tidak memungkinkan Anda untuk mengontrol laju perubahan dalam persyaratan, proses Anda tidak gesit, tetapi serampangan. Agile tidak berarti "mengambil apa pun yang datang kepadaku."

Untuk mengontrol perubahan / creep persyaratan, Anda dapat mengadopsi - dalam proses Anda - gagasan bahwa persyaratan tidak berubah (gagasan bahwa itu adalah inti dari Scrum.) Perlakukan perubahan persyaratan sebagai mengganti persyaratan lama dengan yang baru. Anda harus memiliki simpanan persyaratan, dan Anda harus membuat pengguna memilih yang mana yang ingin diimplementasikan.

Anda menginginkan X dan Y dalam dua minggu, tetapi tiba-tiba Anda menginginkan Z. Nah, maka saya dapat memberikan Anda ketiganya dalam 4 minggu. Atau saya dapat memberikan pasangan (X dan Z) atau (X dan Y) atau (Y dan Z) dalam dua minggu dan mengirimkan sisanya. Memilih.

Ini adalah bagaimana Anda bernegosiasi dengan pelanggan. Ini adalah bagaimana Anda mengkomunikasikan biaya perubahan persyaratan. Jika grup Anda tidak memiliki kekuatan itu, Anda tidak berada di toko lincah, dan tidak ada yang dapat Anda lakukan untuk itu. Itu menyebalkan, tapi itu benar.

Jika Anda dapat bernegosiasi, Anda harus melacak (dengan presisi) waktu yang diperlukan untuk menerapkan persyaratan dan perubahan persyaratan. Artinya, Anda harus mengumpulkan data ini dari proyek masa lalu dan sekarang.

Anda mengumpulkan perkiraan waktu asli dan waktu penyelesaian aktual (di samping sumber daya seperti jumlah pengembang) per permintaan (atau modul yang dipengaruhi oleh permintaan N). Lebih baik lagi, perkirakan ukuran permintaan / permintaan berubah (dalam hal garis kode atau titik fungsi dalam proyek dan permintaan sebelumnya).

Katakanlah Anda memiliki metrik yang dapat digunakan untuk berbicara dengan pengguna. Anda tahu bahwa permintaan baru akan mengambil, katakanlah, 1K baris kode, atau 10 halaman web dengan rata-rata masing-masing 5 bidang input (50 titik fungsi).

Kemudian dengan melihat data historis yang spesifik untuk proyek masa lalu Anda (beberapa demi baris kode, beberapa oleh halaman web, beberapa oleh titik fungsi aktual), dan Anda dapat memperkirakan berapa masing-masing biaya ini dalam hal waktu penyelesaian absolut. Bagi mereka yang memiliki data yang cukup, Anda juga dapat mengidentifikasi persyaratan yang melacak jumlah kepala pengembang yang sebenarnya.

Kemudian Anda menggunakannya dan Anda memberi tahu pelanggan Anda bahwa berdasarkan data historis; Anda berpendapat bahwa kegagalan proyek cenderung mengikuti tindak distribusi eksponensial; dan kemudian Anda dipersenjatai dengan argumen berikut untuk pelanggan Anda:

Berdasarkan data dari proyek kami dulu dan sekarang dan sumber daya yang tersedia, persyaratan yang Anda minta akan diambil

1. Jumlah X waktu untuk menyelesaikan dengan probabilitas kegagalan 25% (atau 75% keberhasilan)

2. 1,5 * X jumlah waktu untuk menyelesaikan dengan kegagalan 5% (atau keberhasilan 95%)

3. 0,5 * X jumlah waktu untuk menyelesaikan dengan kegagalan 95% (atau 5% sukses)

Probabilitas kegagalan sebagai fungsi dari jumlah sumber daya waktu biasanya naik 95%, 25% dan 5% (menyerupai distro eksponensial.) Anda menyampaikan pesan bahwa jumlah baseline tertentu memberikan peluang keberhasilan yang agak baik (tetapi dengan risiko nyata ). 1,5 dari yang mungkin memberikan hampir peluang keberhasilan tertentu dengan risiko minimal, tetapi jauh lebih kecil dari itu (0,5 dari jaminan asli kegagalan hampir pasti.)

Anda membiarkan mereka mencernanya. Jika mereka masih melakukan proposisi berisiko ( dilakukan kemarin! ) Setidaknya Anda memiliki secara tertulis bahwa Anda mengatakannya kepada mereka. Jika ada harapan untuk kelompok Anda tidak hanya gesit tetapi seperti rekayasa, maka, pelanggan mungkin mempertimbangkan dengan serius nomor Anda dan menjadwalkan ini dan permintaan masa depan sesuai.

Adalah tugas Anda sebagai insinyur untuk menjelaskan secara teknis, persyaratan yang dapat diverifikasi dan jelas bahwa permintaan perubahan bukanlah makanan gratis.

Dari apa yang Anda jelaskan, Anda tidak memiliki masalah. Mereka meminta perubahan dan bersedia menunggu sampai Anda mengatakan itu dapat dilakukan atau bersedia menunda fitur lain. Tampak seperti keseimbangan antara: waktu, sumber daya, dan persyaratan.

Anda bisa mencoba mengatur usia minimum penambahan / perubahan baru (tidak berlaku untuk perbaikan bug). Misalnya tidak ada perubahan baru yang dapat dikerjakan hingga berumur 3 minggu.

Memiliki usia minimum tugas itu baik karena pada awalnya, setiap tugas sepertinya sangat penting, tetapi jika Anda menunggu beberapa waktu maka itu penting akan sering turun secara signifikan. Tergantung pada interval waktu Anda, itu akan memberi Anda setidaknya jumlah waktu stabilitas dalam tugas yang Anda kerjakan.

Untuk melacak usia Anda akan membiarkan tugas ditambahkan ke beberapa daftar, tetapi mereka tidak akan dianggap sebagai tugas untuk dikerjakan sampai periode itu telah berakhir.

Ini adalah masalah yang sangat umum, tidak peduli seberapa cepat suatu proyek maju dalam hal teknis, klien menganggapnya sebagai jauh lebih lambat dan merasa bebas untuk mengubah persyaratan karena mereka suka berpikir bahwa pengembang tidak boleh melakukan banyak hal.

Persepsi cacat ini berasal dari tiga tugas pengembangan utama yang menghabiskan waktu dan tidak akan pernah diperhitungkan dengan baik oleh klien:

1. Ulasan / pembersihan kode: Kode lama akan membengkak dan kacau dan membutuhkan ulasan dan pembersihan rutin, ini membutuhkan banyak waktu dan klien tidak akan pernah percaya.
2. Audit dan perbaikan keamanan: Terutama jika Anda memiliki anggota tim junior, Anda akan memiliki banyak masalah keamanan terkait kode dan Anda ingin memeriksa semua kode baru yang telah ditulis dan menulis ulang hal-hal yang tidak terlihat baik dari keamanan. perspektif, klien tidak akan pernah tahu atau akun untuk saat ini.
3. Perubahan terkait arsitektur: Basis kode yang berkembang mungkin (dan kemungkinan besar akan) pada banyak titik memerlukan pemikiran ulang dan refactoring struktural ini mungkin melibatkan: A - Perubahan / optimisasi terkait kinerja (Perubahan algoritma, penggantian pustaka, penggantian mesin perpustakaan, mesin cache, ... dll) atau: B - Perubahan / optimisasi terkait produktivitas (keterbacaan, penggunaan kembali kode, kemudahan pemahaman, konvensi pengkodean baru, kerangka kerja baru, ... dll).

Tidak satu pun di atas akan pernah dipahami dan diperhitungkan dengan benar oleh klien akhir.

Pada dasarnya apa pun yang tidak memiliki "tampilan" (elemen GUI) belum dilakukan.

Sebut saja ini teorema projenix, haha ​​tidak hanya bercanda: D