Saya memiliki masalah dengan direktur senior yang tidak memahami pengembangan berulang (apalagi Agile). Dia bersikeras bahwa spesifikasi desain perangkat lunak (SDS) kami harus lengkap sebelum baris kode apa pun ditulis. Lengkap, baginya, berarti semua detail fungsional ada di sana. Juga, sebagai mantan programmer Cobol, dia ingin melihat "modul" dan diagram alur. Ini adalah aplikasi web Java untuk menangis dengan suara keras!

Ngomong-ngomong, saya mencoba mencari tempat sederhana untuk dengan lembut menunjuknya untuk menunjukkan bahwa SDS tidak perlu 100% lengkap sebelum kita mulai coding (juga tidak bisa lengkap). Ada saran?

Terima kasih!

Sebagai seorang konsultan, saya memahami satu aturan konsultasi sederhana:

• Anda tidak dapat membantu orang yang tidak ingin ditolong.

Anda tidak dapat membuat orang melakukan apa pun yang tidak ingin mereka lakukan kecuali dengan kekuatan otoritas, yang tidak Anda miliki.

Sebagai seorang pelatih, saya memperkenalkan Agile dengan tiga aturan:

1. Tidak mungkin mengumpulkan semua persyaratan di awal proyek.

2. Apapun kebutuhan Anda lakukan berkumpul dijamin untuk perubahan.

3. Akan selalu ada lebih banyak yang harus dilakukan daripada waktu dan uang memungkinkan.

dan satu tujuan:

• Kirim sesuatu yang bernilai setiap minggu.

Itu saja yang Anda butuhkan untuk memulai.

Meyakinkan manajer Anda adalah hal lain.

Anda tidak bisa "membuat" seorang manajer memahami gesit secara berbeda dari yang Anda bisa membuat pengembang memahaminya. Anda perlu mengajukan argumen kepadanya (buku-buku Kent Beck adalah awal yang baik) dan biarkan dia mengambil keputusan sendiri.

Atau, Anda dapat memintanya untuk membiarkan Anda menjalankan percobaan. Ambil proyek kecil dan jalankan dengan pengembangan berulang dan perhatikan waktu, anggaran, masalah kualitas, dan kepuasan tim. Bandingkan dengan proyek sebelumnya (atau rilis) dan lihat apakah itu lebih baik, lebih buruk, atau netral.

Kamu tidak

Pertama-tama, mengapa seorang Direktur Senior bahkan terlibat dalam pemilihan metodologi pengembangan perangkat lunak? Keputusan itu jauh di bawah tingkat gajinya, menampar manajemen mikro, dan berbicara banyak ketidakpercayaan.

Kedua, mengapa dia perlu memahaminya sama sekali? Jika spesifikasi perangkat lunak diperbaiki, maka hanya akan ada satu iterasi. Jika tidak, maka akan ada beberapa iterasi. Ini bukan keputusannya .

Jika dia berpikir itu adalah keputusannya, maka dia merongrong otoritas Manajer TI, manajer proyek, arsitek TI, pimpinan tim, dan tim pengembangan. Jadi dia harus menulis sendiri perangkat lunak @ # $%, atau STFU dan membiarkan para profesional melakukan pekerjaan mereka tanpa terbebani oleh otak dinosaurus.

Aku tidak bercanda. Jika dia tidak bisa mempercayai Anda untuk melakukan pekerjaan Anda, dia harus melakukannya sendiri dan Anda harus lari berteriak .

"Membuat perangkat lunak seperti membuat film, Anda harus melakukan perencanaan di muka tetapi selama pembuatan film Anda perlu melakukan pemotretan ulang, mengunjungi kembali adegan lama dan mengedit produk akhir untuk memastikan hasil yang baik"

Kemudian lagi, dia adalah seorang manajer, jadi dalam kata-katanya:

"Kita perlu memanfaatkan fleksibilitas sinergis kita untuk menghasilkan solusi layanan penuh tepat waktu"

Pepatah lama berlaku: Anda bisa membawa kuda ke air, tetapi Anda tidak bisa membuatnya minum.

Seperti yang telah ditunjukkan oleh orang lain, yang benar-benar penting bagi direktur senior ini adalah nilai bisnis. Anda bisa mencoba memberikan perkiraan cepat berapa banyak waktu yang akan Anda habiskan untuk menyusun diagram alir dan diagram modulnya dan menulis SDS "lengkap" (konsep konyol, tetapi berikan apa yang diinginkannya). Jika saya tahu apa-apa tentang hal-hal ini (dan ketika saya mulai menulis perangkat lunak, begitulah yang dilakukan) maka perkiraan Anda akan dengan mudah beberapa minggu, jika tidak lebih untuk proyek yang cukup besar. Nyatakan angka itu dalam uang.

Lalu tunjukkan padanya berapa banyak fungsionalitas yang dapat Anda berikan dalam waktu yang bersamaan. Berbicaralah dengan beberapa orang di bisnis ini tentang berapa banyak waktu yang akan menyelamatkan mereka untuk memiliki aplikasi web dasar melakukan hal-hal yang dapat Anda berikan dalam waktu yang sama. Kemudian gandakan tabungan ini dengan seberapa sering mereka menggunakan fungsi ini dalam, katakanlah, 3 tahun. Nyatakan itu dalam bentuk uang.

Mungkin ada manfaat bisnis lain yang dapat dinyatakan dalam uang. Favorit saya selalu pencegahan "goofball". Jika perangkat lunak Anda dapat membantu meminimalkan bencana atau menghindarinya sama sekali, maka temukan bencana terbaru dan nyatakan dalam bentuk uang. Kemudian katakan kepada atasan Anda: Jika kami memiliki ini sekarang, kami akan menghemat uang ini.

Dan jika trik uang tidak berhasil, maka mungkin harus menghampirinya dan menyuruhnya untuk berhenti mengelola mikro timnya. Meskipun, dalam pengalaman saya, itu lebih cenderung membuat Anda dipecat daripada yang lain.

Tempat yang sederhana mungkin adalah Manifesto untuk Pengembangan Perangkat Lunak Agile .

Informasi yang Anda temukan di tempat ini adalah tentang inti utama pengembangan perangkat lunak gesit yang ditentukan oleh sekelompok profesional terkenal.

Itu adalah

• Individu dan interaksi atas proses dan alat
• Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif
• Kolaborasi pelanggan atas negosiasi kontrak
• Menanggapi perubahan setelah mengikuti rencana

Tapi tolong lihat halaman secara detail untuk mendapatkan maksud penuh.

Saya akan menyarankan mencoba menunjukkan kepadanya bahwa dengan melakukan "Rapid Prototyping" (alias mulai kode beberapa iterasi pertama) Anda dapat lebih cepat dan akurat menyempurnakan SDS Anda (berarti lebih sedikit pengerjaan ulang nanti) dan mulai memberikan nilai bisnis sebelumnya. Sungguh, nilai bisnis yang paling mungkin adalah yang terpenting bagi direktur ini dan dia telah memutuskan bahwa cara terbaik untuk mencapainya adalah melalui proses berurutan ini. Anda perlu menunjukkan kepadanya dalam istilahnya mengapa pendekatan Anda lebih baik.

Ini mungkin bisa membantu - http://www.youtube.com/watch?v=4u5N00ApR_k

Dalam film ini "Saya ingin menjalankan proyek lincah" kami mengikuti pengalaman dari salah satu pemimpin proyek yang berani, Luke, karena ia memiliki banyak pertemuan yang berbeda di seluruh perusahaan, bekerja untuk membangun dan mengirimkan proyek Agile-nya.