Apa yang Anda gambarkan adalah - setidaknya dalam pengalaman saya - pola tim yang muncul cukup umum yang mencoba "menjadi Agile". Sangat terbuka untuk diperdebatkan apakah ini sebenarnya bagian dari Agile itu sendiri atau kesalahan penerapannya, bertentangan dengan manifest / prinsip lincah atau konsekuensi yang melekat padanya, dan sebagainya. Hanya dari sudut pandang empiris dan hanya berdasarkan pada sekelompok kecil sampel pengalaman saya sendiri (dan orang-orang yang saya ajak bicara), jika sebuah tim gesit tampaknya memiliki peluang lebih tinggi daripada rata-rata untuk menjalankan pola ini. Kita tinggalkan saja itu dan fokus pada contoh konkret Anda.
Ada dua aspek terpisah dari apa yang Anda gambarkan:
- Tidak ada kesepahaman / visi dan karenanya tidak efisien
- Bagaimana mengukur keberhasilan / kemajuan dan total biaya
Turun jalan yang salah atau berjalan dalam lingkaran
Dalam pengalaman saya, alasan utama untuk ini terjadi adalah bahwa dalam upaya untuk menghasilkan kode dengan cepat, tim secara aktif menyingkirkan kasus penggunaan atau persyaratan yang sudah mereka ketahui atau dapat dengan mudah mengetahuinya. Pikirkan seperti ini: 10-20 tahun yang lalu, orang mencoba untuk menulis spesifikasi raksasa dan memikirkan segalanya sebelumnya dan sering gagal. Mereka mengambil terlalu lama atau mengabaikan sesuatu. Salah satu pembelajaran di masa lalu adalah bahwa dalam pengembangan perangkat lunak ada hal-hal yang tidak dapat Anda ketahui dan banyak hal berubah, maka ide untuk beralih dengan cepat dan menghasilkan beberapa keluaran yang masuk akal dengan cepat. Prinsip yang sangat bagus. Tetapi hari ini, kita berada di ujung lain: "Saya tidak peduli tentang ini karena ini adalah bagian dari sprint berikutnya" atau "Saya tidak mengajukan bug itu, saya mengatasinya ketika muncul lagi".
- Kumpulkan semua kasus penggunaan tingkat tinggi , persyaratan, dependensi, dan batasan yang dapat Anda temukan. Masukkan ke dalam wiki sehingga semua pemangku kepentingan dan pengembang dapat melihatnya. Tambahkan kepada mereka ketika sesuatu yang baru muncul. Bicaralah dengan pemegang saham & pengguna Anda. Gunakan ini sebagai daftar periksa sambil mengembangkan untuk mencegah penerapan hal-hal yang tidak berkontribusi pada produk akhir atau solusi / peretasan yang memecahkan satu masalah tetapi menyebabkan tiga yang baru.
- Merumuskan konsep tingkat tinggi . Saya tidak berbicara tentang mendesain antarmuka atau kelas, tetapi secara kasar menggambarkan domain masalah. Apa elemen utama, mekanisme dan interaksi dalam solusi akhir? Dalam kasus Anda, itu harus membuatnya jelas ketika menggunakan bantuan jquery-penyelesaian sebagai langkah menengah dan ketika itu hanya menyebabkan pekerjaan tambahan.
- Validasi konsep Anda menggunakan daftar yang Anda kumpulkan. Apakah ada masalah yang jelas di dalamnya? Apakah masuk akal? Apakah ada cara yang lebih efisien untuk mencapai nilai pengguna yang sama tanpa menyebabkan hutang teknologi lama?
Jangan berlebihan. Anda hanya perlu sesuatu sehingga semua orang dalam tim (termasuk non-devs) memiliki pemahaman yang sama tentang jalan terbaik menuju MVP Anda. Setiap orang harus setuju bahwa tidak ada kekeliruan yang jelas dan itu bisa berhasil. Ini secara umum membantu mencegah jalan buntu atau harus mengulangi hal yang sama beberapa kali. Agile dapat membantu Anda menghadapi hal-hal yang tidak terduga dengan lebih baik, tidak ada argumen untuk mengabaikan apa yang diketahui.
Waspadai kekeliruan biaya-sunk : jika Anda mulai dengan satu tipe arsitektur atau database, kebanyakan orang ragu untuk mengubahnya di tengah proyek. Jadi adalah ide yang baik untuk menginvestasikan waktu untuk memiliki "tebakan terbaik yang berpendidikan" sebelum mulai menerapkan hal-hal. Pengembang memiliki kecenderungan untuk ingin menulis kode dengan cepat. Tetapi sering memiliki beberapa ejekan, prototipe langsung, tangkapan layar, gambar rangka, dll memungkinkan iterasi lebih cepat daripada menulis kode. Perlu diketahui bahwa setiap baris kode yang ditulis atau bahkan unit test mempersulit Anda untuk mengubah konsep keseluruhan Anda lagi.
Mengukur Keberhasilan
Aspek yang sepenuhnya terpisah adalah bagaimana Anda mengukur kemajuan. Katakanlah tujuan proyek Anda adalah membangun menara setinggi 1m menggunakan benda-benda yang tergeletak di sekitar. Membangun rumah kartu bisa menjadi solusi yang benar-benar valid jika misalnya waktu memasarkan lebih penting daripada stabilitas. Jika tujuan Anda adalah untuk membangun sesuatu yang tahan lama, menggunakan Lego akan lebih baik. Intinya adalah: apa yang dianggap sebagai retasan dan apa solusi elegan bergantung sepenuhnya pada bagaimana kesuksesan proyek diukur .
Contoh "memuat" Anda cukup bagus. Saya memiliki hal-hal seperti ini di masa lalu di mana semua orang (termasuk penjualan, PO, pengguna) setuju itu menjengkelkan. Tapi itu tidak berdampak pada kesuksesan produk dan tidak menyebabkan hutang jangka panjang. Jadi kami membatalkannya karena ada lebih banyak hal berharga yang harus dilakukan dengan sumber daya dev.
Saran saya di sini adalah:
- Simpan semuanya, bahkan bug kecil, sebagai tiket di sistem tiket Anda . Buat keputusan aktif apa yang ada dalam ruang lingkup proyek dan apa yang tidak. Buat tonggak sejarah atau filter backlog Anda sehingga Anda selalu memiliki daftar "lengkap" dari semua yang masih perlu dilakukan.
- Memiliki urutan kepentingan yang ketat dan titik potong yang jelas di mana proyek dapat dianggap sukses. Tingkat stabilitas / kualitas kode / dokumentasi apa yang dibutuhkan produk akhir? Cobalah untuk menghabiskan setiap hari kerja sebaik mungkin dengan memilih dari atas. Ketika mengerjakan satu tiket, cobalah menyelesaikannya sepenuhnya tanpa memperkenalkan tiket baru (kecuali masuk akal untuk menunda hal-hal karena prioritas yang lebih rendah). Setiap komit harus membawa Anda ke depan menuju tujuan akhir Anda, bukan ke samping atau ke belakang. Tetapi untuk menekankan lagi: kadang-kadang peretasan yang menghasilkan pekerjaan tambahan di kemudian hari masih bisa menjadi positif bersih untuk proyek!
- Gunakan PO / pengguna Anda untuk mengetahui nilai pengguna tetapi juga minta dev Anda untuk mengetahui biaya teknologi . Non-dev biasanya tidak dapat menilai apa biaya jangka panjang sebenarnya (bukan hanya biaya implementasi!), Jadi bantu mereka. Waspadai masalah katak mendidih: banyak masalah kecil yang tidak relevan dari waktu ke waktu dapat membawa tim untuk bertahan. Cobalah untuk mengukur seberapa efisien tim Anda dapat bekerja.
- Mengawasi tujuan / biaya keseluruhan. Alih-alih berpikir dari sprint ke sprint, lebih baik menjaga pola pikir "bisakah kita sebagai tim melakukan semua yang diperlukan sampai akhir proyek" . Sprint hanyalah cara untuk memecah masalah dan memiliki check point.
- Alih-alih ingin menunjukkan sesuatu sejak dini, plot kursus Anda di jalur tercepat ke produk minimum yang layak yang dapat diberikan kepada pengguna. Namun, strategi keseluruhan Anda harus memungkinkan hasil yang dapat diverifikasi di antaranya.
Jadi, ketika seseorang melakukan sesuatu yang tidak sesuai dengan tujuan implementasi akhir Anda, idealnya jangan menganggap cerita itu selesai. Jika bermanfaat untuk menutup cerita (mis. Untuk mendapatkan umpan balik dari pelanggan), segera buka cerita / bug baru untuk mengatasi kedatangan singkat. Jadikan transparan bahwa mengambil jalan pintas tidak mengurangi biaya, itu hanya menyembunyikan atau menunda mereka!
Kuncinya di sini adalah untuk berdebat dengan total biaya proyek: jika misalnya PO mendorong untuk mengambil jalan pintas untuk membuat tenggat waktu, menghitung jumlah pekerjaan yang harus dilakukan setelah itu untuk mempertimbangkan proyek selesai!
Waspadalah juga terhadap pengoptimalan berbasis kriteria : jika tim Anda diukur dengan jumlah cerita yang dapat mereka tunjukkan pada ulasan sprint, cara terbaik untuk mencapai "skor" yang baik adalah dengan memotong setiap cerita menjadi sepuluh cerita kecil. Jika diukur dengan jumlah unit tes yang ditulis, itu akan cenderung menulis banyak yang tidak perlu. Jangan menghitung cerita, melainkan mengukur seberapa banyak fungsionalitas pengguna yang dibutuhkan bekerja, seberapa besar biaya hutang teknologi yang harus diselesaikan dalam lingkup proyek, dll.
Ringkasan
Untuk mendidihkannya: Melaju cepat dan minimal adalah pendekatan yang baik. T dia masalah adalah dalam menafsirkan "cepat" dan "minim". Orang harus selalu mempertimbangkan biaya jangka panjang (kecuali jika Anda memiliki proyek di mana ini tidak relevan). Menggunakan jalan pintas yang hanya membutuhkan waktu 1 hari tetapi menghasilkan utang teknologi 1 bulan setelah tanggal pengiriman membuat perusahaan Anda lebih dari solusi yang memakan waktu 1 minggu. Segera mulai menulis tes tampaknya cepat, tetapi tidak jika konsep Anda cacat dan mereka memperkuat pendekatan yang salah.
Dan perlu diingat apa arti "jangka panjang" dalam kasus Anda: Saya tahu lebih dari satu perusahaan yang bangkrut dengan mencoba menulis kode yang bagus dan karena itu dikirim terlambat. Arsitektur yang baik atau kode yang bersih - dari sudut pandang perusahaan - hanya bernilai jika biaya untuk mencapainya lebih rendah daripada biaya tidak memilikinya.
Semoga itu bisa membantu!