Bisakah Agile diselesaikan tanpa keterlibatan klien?

Saya tidak bisa menulis buku tentang Agile. Saya telah bekerja di beberapa toko yang menyebut proses mereka Agile. Salah satu poin utama pengembangan Agile adalah keterlibatan klien secara teratur. Setelah sprint, karya dapat didemonstrasikan ke klien untuk mendapatkan umpan balik mereka. Bilas dan ulangi.

Masalah yang saya temui adalah banyak klien yang tidak ingin terlibat. Mereka lebih suka pendekatan air terjun. Kumpulkan persyaratan di muka, lalu kembali ketika Anda selesai. Menurut pengalaman saya, air terjun tidak berfungsi. Klien tidak tahu apa yang mereka inginkan sampai mereka melihatnya. Dilema air terjun selanjutnya diperbanyak oleh komunitas besar pengembang yang ingin memiliki semua persyaratan di muka. Dengan cara ini mereka tahu apa yang sedang mereka bangun, mereka dapat membuat arsitek yang sesuai, dan klien yang harus disalahkan karena mereka "menandatangani" persyaratan tersebut.

Apakah saya salah? Bisakah Agile bekerja tanpa keterlibatan klien? Jika demikian, bagaimana dan bagaimana Anda mengatasi masalah yang saya diskusikan?

Bagaimana mungkin? Sifat dasar dari teknik ini menentukan semacam lingkaran umpan balik antara pelanggan dan pengembang.

Namun, beberapa bagian dari tim Anda dapat bertindak sebagai pelanggan "proxy" (proses serupa dengan "makan makanan anjing Anda sendiri") sehingga Anda dapat "berpura-pura" gesit, meskipun itu tidak akan memuaskan seperti mendapatkan pelanggan yang sebenarnya. umpan balik.

Suka atau tidak, pelanggan akan terlibat dalam proses desain; itu hanya masalah berapa banyak mereka ingin biaya pengerjaan ulang (semakin lama ditunda, semakin mahal itu).

Karena pelanggan menginginkan "Desain Besar di Depan," bantu mereka memahami bahwa akan lebih banyak waktu dan usaha di muka mereka untuk mendapatkan desain yang benar pertama kali.

Jawaban singkat untuk pertanyaan Anda adalah 'tidak'. Berikut adalah komentar pada beberapa bagian dari pertanyaan Anda. Agar akurat, sebagian besar jawaban didasarkan pada pengalaman dan pengamatan pribadi saya.

Menurut pengalaman saya, air terjun tidak berfungsi.

Waterfall adalah metodologi yang kuat untuk menghadirkan sistem dengan kompleksitas yang beragam. Sangat disayangkan bahwa itu tidak disajikan dengan baik atau dipahami. Salah satu alasannya adalah karena tidak menghasilkan uang yang cukup bersaing dengan metodologi hari itu yang terus bermunculan. Anda mungkin terkejut mengetahui bahwa banyak sistem perbankan, asuransi dan manufaktur dibangun hanya dengan menggunakan pendekatan Waterfall dan banyak dari mereka yang masih dalam produksi hari ini. Sangat menyedihkan bahwa industri perangkat lunak didasarkan pada hype lebih dari sains.

Klien tidak tahu apa yang mereka inginkan sampai mereka melihatnya.

Ini hanya mitos. Yang besar juga. Ini mungkin terjadi dalam desain / tata letak halaman web tetapi untuk pemrosesan data bisnis, sebagian besar pengguna menginginkan sesuatu yang berfungsi. Beberapa dari pengguna tersebut masih menggunakan layar AS / 400 dan 3270 monitor CICS dengan RGB dan mereka dapat menyelesaikan urusan mereka dengan alat-alat itu. Juga, para pengguna yang sama menerima sistem ERP SAP dan ORACLE tanpa memiliki suara dalam desain antarmuka (dan beberapa kali dalam fungsi). Sebagian besar pengguna bisnis bahkan akan menyesuaikan kebiasaan dan aliran kerja mereka jika sistem menghasilkan fungsi yang benar. Stres di sini adalah pada fungsi tidak terlihat. Pelaku bisnis mengerti bagaimana mereka melakukan pekerjaan mereka dengan sangat baik 90% dari waktu.

Dilema air terjun selanjutnya diperbanyak oleh komunitas besar pengembang yang ingin memiliki semua persyaratan di muka. Dengan cara ini mereka tahu apa yang sedang mereka bangun, mereka dapat membuat arsitek yang sesuai, dan klien yang harus disalahkan karena mereka "menandatangani" persyaratan tersebut.

Anda tidak dapat menyalahkan pengembang karena ingin tahu apa yang mereka bangun karena para pengembang ingin pulang memasak makan malam dan menekan baju mereka untuk latihan lain setelah mereka menghabiskan 3 jam atau lebih mempelajari teknologi berikutnya. yang akan menggantikan keahlian mereka saat ini! Permainan menyalahkan membuat tidak ada yang menjadi pemenang. Pikirkan dalam hal peran dan tanggung jawab masing-masing pihak dan gambarannya akan sangat jelas.

Sebagai kesimpulan, manajer proyek, Programmer, dan Desainer Web tidak ada pengganti untuk Analis Bisnis yang harus tahu cara mengumpulkan persyaratan dari pengguna akhir terlepas dari metodologi.

Mereka tidak ingin memasukkan waktu dan jika diberi pilihan mereka lebih suka mendapatkan perangkat lunak secara gratis, tetapi Anda masih akan membebankan biaya, kan? Ini menjadi kabur jika Anda mengembangkan perangkat lunak secara internal untuk perusahaan Anda. Mereka pikir Departemen TI telah dibeli dan dibayar (karyawan yang digaji), sehingga mereka mungkin mendapatkan sebanyak mungkin pekerjaan Anda.

Anda dapat berpotensi gesit. Dapatkan semua spesifikasi dan mulai koding. Setelah klien menyela pekerjaan karena mereka hanya berpikir tentang soomething dan Anda harus membuat perubahan dan pengerjaan ulang, Anda menjadi sedikit lebih gesit. Anda juga bisa melakukan persetujuan dalam tim Anda. Mintalah salah satu tim Anda mengenakan jas dan dasi dan berpura-pura menjadi pelanggan.

Membuat komitmen waktu yang besar di depan mungkin membuat mereka takut. Sarankan melakukan sprint untuk mencobanya. Kemudian beri mereka kesempatan untuk memilih keluar. Anda selalu dapat beralih ke air terjun selama sisa proyek. Juga menyarankan bahwa orang yang berbeda di tim mereka dapat melakukan peninjauan dan menyetujui jika waktu menjadi kendala bagi orang yang menulis cek.

Pada titik tertentu, Anda harus memberi tahu mereka bahwa Anda tidak berpikir air terjun akan berfungsi. Tanyakan kepada mereka apakah mereka puas dengan pendekatan ini dan jika demikian, mengapa mereka tidak memiliki orang terakhir yang melakukan proyek ini?

Tidak ada metodologi yang dapat bekerja tanpa keterlibatan klien. Keluar dari persyaratan bisa menjadi tidak berarti ketika saya menyaksikan dalam proyek yang saya ikuti. Masalah Anda melampaui kemampuan Agile, Anda perlu mendidik klien Anda dan memastikan mereka memahami betapa pentingnya bagi mereka untuk berpartisipasi.

Saya pikir salah satu manfaat utama Agile adalah kemampuan untuk mendapatkan persyaratan yang lebih terperinci untuk setiap fitur secara keseluruhan. Ketika klien memberikan semua persyaratan mereka dimuka, setiap fitur cenderung menjadi ide yang samar, dengan sedikit fungsionalitas yang ditentukan. Pasukan Agile klien untuk meninjau kembali setiap fitur dan fokus pada apa yang mereka inginkan dan bagaimana fitur tersebut akan masuk ke dalam gambaran yang lebih besar. Untuk mendapatkan jumlah detail yang sama (detail yang cukup untuk mengimplementasikan fitur-fitur) ke dalam spesifikasi, air terjun benar-benar mengharuskan Anda melakukan salah satu dari dua hal berikut:

1. Kira. Terapkan sampai Anda menemukan sesuatu yang tidak jelas, lalu buat penilaian tentang bagaimana Anda merasa fitur tersebut paling baik diimplementasikan. Ini jelas tidak ideal, karena mengarah ke "Tunggu, bukan itu yang saya minta!" skenario.

2. Berikan jauh lebih banyak penekanan pada desain dimuka. Pada dasarnya, ketika klien melempar spek setengah matang mereka pada Anda pada hari pertama, rencanakan untuk memeriksa setiap detail setiap menit sebelum menerapkan apa pun. Minta klien untuk mengklarifikasi semuanya ad nauseum ke titik di mana Anda tahu setiap detail implementasi untuk seluruh proyek. Meskipun tidak sempurna, ini lebih baik daripada opsi 1. Anda mungkin masih mengalami detail yang belum Anda antisipasi, dan bahkan mungkin mengirim klien berlari ke bukit, tetapi jika mereka benar-benar tidak ingin berkomunikasi selama pengembangan dan Anda bukan psikis, ini suatu keharusan. Ini pada dasarnya adalah air terjun, dan ia datang dengan semua kelemahan yang terkait, termasuk menjadi sangat sulit untuk dieksekusi dengan baik.

3. Ambil spek setengah matang, tetapi mintalah klarifikasi saat Anda melanjutkan. Bekerja sampai Anda mencapai bagian yang tidak jelas dari spesifikasi, lalu minta klien untuk mengklarifikasi. Tentu saja, ini bukan yang diminta klien, tetapi jika mereka tidak ingin aplikasi keruh seperti spesifikasi dan menolak untuk menentukan spesifikasi di muka, ini adalah satu-satunya pilihan yang tersisa. Ini tidak memiliki semua manfaat Agile (seperti persetujuan klien reguler untuk memastikan semua orang ada di halaman yang sama), namun, itu memungkinkan Anda untuk mendapatkan informasi yang Anda butuhkan untuk dikembangkan. Karena opsi 1 mungkin akan meninggalkan Anda dengan produk sub-par, opsi 2 boros dan membuat frustrasi klien (Anda mungkin perlu menghabiskan setidaknya dua kali lebih banyak waktu untuk desain dan pengumpulan spec keseluruhan jika Anda melakukannya sepenuhnya di depan), ini benar-benar bukan pilihan yang buruk. Kuncinya di sini adalah untuk rajin memodifikasi garis waktu dan harga dengan setiap perubahan yang muncul. Jika Anda melakukannya dengan benar, Anda mungkin menemukan bahwa sebagian besar praktik Agile kompatibel dengan pengaturan ini, bahkan jika klien tidak mengetahuinya. IMHO, ini benar-benar sesuai dengan semangat Agile, karena Anda seharusnya menyesuaikan metodologi dengan pengaturan khusus Anda.

Jika klien benar-benar tidak dapat hidup dengan konsekuensi dari salah satu dari ketiga opsi ini atau Agile yang penuh sesak nafas, saya kesulitan membayangkan bagaimana klien ini benar-benar bernilai saat Anda.

Saya pikir itu sulit tetapi masih mungkin. Saya pikir ide proxy Robert bekerja tetapi perlu bagi proxy untuk menghabiskan waktu sebanyak mungkin dengan klien 'nyata' sehingga mereka dapat melihat sesuatu dari sudut pandang mereka. Dengan cara itu proxy dapat memastikan fitur apa yang benar-benar penting dan merasakan pengalaman pengguna yang diinginkan / diinginkan klien.

Tetapi pada titik tertentu Anda harus menunjukkan perangkat lunak kepada klien 'nyata' ...

Dimungkinkan untuk menghindari pelanggan nyata, bahkan kadang-kadang diperlukan untuk regulasi. Biasanya pelanggan perangkat lunak medis tidak terlibat. Dalam kasus tersebut, entitas lain dapat menggantikan peran pelanggan, misalnya tim pemasaran dapat dianggap sebagai pelanggan.

Agile memang membutuhkan loop ketat untuk menggantikan desain besar di muka yang Sulit - Cukup keras tetapi sebenarnya itu bisa dilakukan, gesit bukan satu-satunya cara.

Anda mungkin ingin menemukan salah satu modifikasi Agile - ada banyak dan satu mungkin membahas masalah khusus ini, tetapi jika tidak membuat sendiri jika Anda pikir Anda bisa.

Semua proses ini dibuat oleh orang pintar - dan orang pintar dapat membuat proses apa pun bekerja. Anda tidak berpikir air terjun diciptakan karena tidak pernah berhasil untuk siapa pun, bukan? Itu berevolusi karena beberapa orang dapat membuatnya bekerja, dan yang lain memandang dan berkata, "Saya harus memperbaikinya dan memberinya makan untuk tim SAYA yang tampaknya tidak dapat menghasilkan secara efektif" - pada titik itu mungkin bekerja lebih baik daripada apa yang mereka sedang melakukan, tetapi jika Anda tidak menyadari bahwa tidak setiap programmer dapat menyelesaikan setiap masalah itu benar-benar dapat membingungkan Anda mengapa dua tim menggunakan proses yang sama dapat memiliki hasil yang berbeda.

Masalahnya adalah bahwa banyak proses membutuhkan bakat untuk mengimplementasikannya - kita berbicara tentang bakat yang sama jarangnya dengan pemain olahraga pro dari kumpulan semua orang yang pernah bermain olahraga - kemungkinan besar dari kita belum pernah bertemu seseorang yang mampu membuat proses jelek seperti air terjun bekerja dan itulah mengapa begitu banyak orang berpikir itu tidak bisa berhasil - mereka belum pernah melihatnya bekerja.

Dibutuhkan jauh lebih sedikit bakat untuk membuat Agile bekerja, namun itu membutuhkan beberapa investasi yang sangat spesifik seperti membuat pelanggan melihat apa yang Anda lakukan terus-menerus sehingga kesalahan tidak dapat menyebar, dan hal-hal seperti refactoring yang kejam sehingga Anda tidak membangun hutang teknis yang tim tidak bisa uraikan beberapa bulan ke depan.

Tentukan pelanggan.

Apakah ini perusahaan lain? Individu lain?

Apakah ini tim lain dalam perusahaan Anda?

Apakah itu juara produk di perusahaan Anda?

Apakah itu kamu?

Semua hal di atas dimungkinkan, dan cukup masuk akal tergantung pada keadaan. Anda tidak ingin mengambil satu pandangan ke bawah terowongan tentang apa itu Agile, jadi untuk mengatakan TIDAK pasti akan salah. YA di sisi lain membutuhkan sedikit pemikiran lateral.

Pikirkan kata Agile sejenak. Kelompok orang yang sangat pandai yang menciptakan istilah itu tidak mungkin dapat mengambil metafora yang lebih baik untuk konsep yang mereka coba gambarkan. Ketika Anda mengatakan Agility , apa yang terlintas dalam pikiran Anda? Menjadi armada kaki? Mungkin cepat bereaksi? Cepat beradaptasi?

Sekarang pikirkan tentang semua praktik Agile yang diterima secara umum di luar sana, dan tanyakan pada diri sendiri apa yang sebenarnya mereka bawa ke metode pengembangan perangkat lunak yang dianggap Agile .

Saya adalah pelanggan dari semua maksud dan tujuan untuk proyek solo saya. Saya bahkan terkadang mengenakan topi sungguhan, ketika saya benar-benar ingin membuat perubahan mental yang khas dalam peran pelanggan saya . Ini membuat saya tidak kalah gesit dari saya ketika saya di tempat kerja. Untuk semua yang saya pedulikan, kucing saya bisa menjadi manajer. Dia memastikan saya beristirahat sejenak, dan mengingatkan saya untuk tidak terlalu terobsesi dengan tugas apa pun. Anda mungkin lebih suka menggunakan "Teknik Pomadoro" Anda yang mewah, tapi saya lebih suka Timer "Rascal" !! Masalahnya, saya bekerja dalam proses Agile yang ketat setiap kali saya menulis kode untuk diri saya sendiri. Saya bukan tipe hacker-koboi, yang menjalani kehidupan dengan lonjakan perkembangan tanpa akhir dan tidak menghasilkan apa-apa. Saya suka membuat perangkat lunak, menjadwalkan pengembangan di sekitar pekerjaan dan kehidupan pribadi saya, dan melengkapinya dengan cara yang saya harapkan untuk dilakukan jika saya bekerja untuk pelanggan nyata. Ketika hal-hal mengganggu jadwal saya, saya menyesuaikan dan memprioritaskan pekerjaan proyek saya sesuai. Saya menggunakan semua praktik dan teknik Agile standar yang dapat saya terapkan secara solo, dan saya "memberikan" kode kerja untuk diri sendiri (atau teman atau kolega untuk diuji) sesering yang saya bisa. Jika semua ini bukan Agile, saya bertanya apa itu?

Jadi jawaban saya adalah Ya , Anda bisa menjadi Pengembang Perangkat Lunak Agile, dan Anda bisa menerapkan metodologi Agile, dan Anda tidak perlu pelanggan, atau bahkan manajer. Anda dapat mengerjakan suatu proyek sendirian, dan memakai beberapa topi. Namun, mungkin tidak ideal untuk menyingkirkan peran-peran lain itu, karena sangat membantu untuk bekerja sama dengan orang lain untuk mencapai tujuan. Mereka bertindak sebagai papan pengeras suara untuk ide-ide Anda, dan mereka memberi Anda persyaratan yang Anda mungkin akan menemukan kesulitan untuk menghasilkan sendiri dengan bijaksana. Peran lain yang sangat penting yang dipuaskan oleh pelanggan dan manajer adalah menjaga Anda tetap fokus pada tujuan Anda, tanpa menambahkan fitur tanpa henti dan memperbaiki kode Anda di luar apa yang mungkin sangat diperlukan.

Namun, jika Anda bekerja dengan cara yang disiplin, berpegang teguh pada metodologi pilihan Anda, dan menerapkan praktik Agile, dan jika ketika Anda dilacak, atau Anda berubah pikiran (saat mengenakan topi pelanggan) dan desain atau arahan produk Anda mengambil giliran, jika Anda dapat menyesuaikan jadwal Anda, dan menyesuaikan prioritas Anda seperti yang Anda bayangkan pelanggan Anda harapkan Anda, maka Anda menjadi gesit.