Bagaimana cara kerja tangkas saat mengganti sistem kerja?

Dalam dunia Agile yang ideal, Anda dengan cepat membangun bagian kecil, tetapi berguna dari sistem akhir yang diinginkan, dan memberikannya kepada pengguna. Mereka senang, karena berguna, mereka mulai menggunakannya dan memberikan umpan balik. Anda kemudian mencari tahu apa yang harus ditambahkan ke dalamnya, membangun itu, dan ulangi sampai Anda kehabisan waktu.

Saya memiliki beberapa proyek baru-baru ini yang melibatkan penggantian beberapa jenis sistem kerja. Model di atas tidak berfungsi sama sekali: sampai Anda membangun sistem yang mencakup hampir semua fungsi sistem yang ada, pengguna tidak tertarik sama sekali. Mereka tidak akan menggunakannya.

Bagaimana Anda menerapkan Agile ketika "subset berguna terkecil" adalah "semuanya"?

Solusi tangkas mungkin bukan untuk menggantikan semua dalam satu waktu, tetapi untuk fase penggantian secara bertahap.

Perkenalkan sistem baru secara bertahap, sedikit demi sedikit, menjaga bagian-bagian dari sistem lama berjalan. Sistem lama tidak dimatikan sekaligus, hanya memudar. Bagian-bagian baru menyediakan fungsionalitas baru atau manfaat lainnya, sehingga pengguna senang menggunakannya. Ini juga kurang berisiko, karena Anda memiliki sistem kerja 100% setiap saat.

• Baca lebih lanjut dari Martin Fowler .
• Strategi dalam Michael Feather's Bekerja secara efektif dengan kode lama dapat bermanfaat

Alih-alih menulis ulang sistem yang ada (yang seperti yang Anda sebutkan akan membutuhkan upaya sebelum sistem baru cocok dengan fungsi yang ada), pertimbangkan pendekatan anggur mencekik . Pada dasarnya, Anda menerapkan fungsionalitas baru menggunakan pendekatan baru di atas aplikasi yang ada. Akhirnya, saat Anda mengatasi kekurangan sistem lama untuk mengatasi fungsi baru, kode baru akan sepenuhnya menggantikan yang lama.

Ini membutuhkan lebih banyak ketelitian dan upaya daripada "reboot" dari aplikasi lama. Tetapi Anda mendapatkan waktu yang lebih singkat untuk ROI. Selain itu, melalui proses ini, Anda dapat memasang kait untuk memungkinkan sistem "baru" menjadi lebih mudah dicekik oleh sistem "baru" berikutnya.

Melepaskan kenaikan kecil ke dunia mungkin bekerja untuk proyek-proyek greenfield tetapi meskipun begitu sejumlah kecil fitur mungkin tidak terlalu berguna.

Scrum menganjurkan bahwa setelah setiap sprint bahwa produk "Berpotensi Dapat Dikirim". Tidak harus dikirim tetapi harus memiliki kualitas produk yang dapat dikirim.

Jika Anda ingin memberi pengguna versi aplikasi tambahan maka Anda dapat mengklasifikasikannya sebagai Alpha lalu Beta lalu Lepaskan versi Kandidat sambil tetap menggunakan aplikasi Produksi nyata yang masih digunakan.

Anda mungkin menemukan bahwa fitur baru ditambahkan dan yang lama dibatalkan jika Anda memasukkan umpan balik dari pengguna.

Saya bekerja pada garis besar penggantian aplikasi bisnis untuk jaringan tv kabel nasional besar. Pengembangan sistem baru dilakukan dengan SCRUM, itu adalah proyek pengembangan 18-24 bulan untuk mengimplementasikan kembali hampir semua sub-sistem utama; yang mendekati 10 tahun.

Ada fase perencanaan seperti 6 bulan sebelum pembangunan dimulai, tetapi juga didekati sebagai SCRUM. Di sinilah pemilik produk menulis toko dan epos tingkat tinggi setelah analisis sistem yang ada dan mewawancarai pelanggan.

Sistem yang ada sangat stabil saat masuk ke mode perawatan kritis; hanya menunjukkan masalah stopper yang diperbaiki, semuanya hanya dicatat untuk tujuan historis dan untuk memastikan masalah yang sama tidak muncul di sistem baru.

Sistem baru berevolusi seperti yang dijelaskan dalam proses Agile, itu sangat halus untuk sebagian besar. Ketika sistem penggantian mencapai fitur partity, itu tidak masuk ke produksi, tetapi ke uji coba produksi paralel. Sub-set pekerja yang tidak kritis mulai menggunakan kedua sistem, untuk memvalidasi bahwa sistem baru berperilaku seperti yang lama; dengan bug lama diperbaiki tentu saja.

Ketika sistem baru mencapai hampir 100% fitur baru lengkap, itu diluncurkan untuk menjalankan produksi paralel umum, yang berlangsung beberapa bulan.

Setelah dianggap oleh pelanggan untuk memenuhi kebutuhan mereka, sistem lama didukung, dimatikan dan duduk. Saya berasumsi mereka telah kembali bertujuan perangkat keras sistem lama karena mereka tidak pernah perlu kembali ke sistem lama setelah dipotong.

Saya masih berpikir gesit menambah banyak nilai dalam skenario ini.

Hanya saja Anda memiliki tujuan akhir yang sangat jelas yaitu 'mengganti sistem saat ini.'

Teknik dan proses yang gesit masih bisa membuat Anda sampai di sana dengan lebih efektif.

Contohnya:

Anda masih dapat menjalankan sistem secara iteratif dan dalam sprint kecil.

Anda masih dapat menggunakan teknik lincah untuk memprioritaskan pekerjaan setelah berkomunikasi dengan orang-orang kunci.

Anda masih bisa menggunakan lincah untuk merencanakan berdasarkan kecepatan yang diamati.

Anda masih dapat menggunakan teknik dan filosofi lincah seperti menyebarkan pengetahuan, TDD, pengkodean bersih untuk meningkatkan kualitas dan desain internal proyek.

Jika Anda memiliki orang yang benar-benar 'tidak tertarik' pada proyek dan tidak terlibat dengan proyek sampai mereka memiliki pengganti yang sempurna, Anda memiliki masalah yang lebih besar terlepas dari apakah Anda menggunakan air terjun, gesit, atau memang proses apa pun.

Ini bekerja sama, tetapi pendekatan ini akan lebih sulit untuk menjual kepada pengguna yang sudah ada. Mereka mungkin tidak menginginkan sistem baru dan mereka tidak ingin diinterupsi dengan pengujian berkala. Mereka ingin menunggu selama mungkin dan kemudian mengujinya pada akhirnya. Sebagian besar pengguna merasakan hal ini sampai batas tertentu, tetapi terserah mereka yang bertanggung jawab untuk mendidik mereka. Dalam pikiran mereka, Anda bekerja dengan aplikasi yang sudah ada, jadi Anda harus tahu apa yang seharusnya dilakukan, mengapa repot-repot?

Buat mereka mengerti bahwa Anda tidak ingin melakukannya dengan cara ini karena Anda pikir itu akan menyenangkan dan Anda merasa kesepian menggunakan proses air terjun. Ini akan membuat aplikasi yang lebih baik dalam jangka panjang.

Titik penjualan utama mungkin untuk menerapkan satu perubahan itu selama membangun aplikasi baru yang selalu mereka inginkan, tetapi tidak pernah bisa masuk ke sistem lama.

Jika saya memiliki mobil tua yang sudah rusak yang harus saya kendarai untuk mulai bekerja, dan saya pergi ke dealer untuk membeli mobil baru. Model yang saya inginkan kehabisan stok sehingga mereka harus memesannya dari pabrik dan akan diperlukan beberapa saat sebelum masuk.

Dealer kemudian dengan itikad baik memutuskan untuk memberi Anda blok mesin mobil sampai mobil yang Anda pesan telah masuk. Apa yang harus Anda lakukan dengan mesin mobil? Tentu saya bisa menghubungkan beberapa komponen untuk mengujinya dan membuatnya bekerja, tetapi itu benar-benar tidak membantu saya untuk bekerja besok di mana mobil tua yang berkarat melakukannya.

Memang ada perbedaan yang sangat jauh antara membangun mobil dan membangun perangkat lunak khusus, tetapi mari kita abaikan itu demi argumen. Inti dari cerita ini bukanlah untuk bingung bahwa klien tidak menemukan gunanya untuk perubahan tambahan ketika mereka sudah memiliki perangkat lunak yang cukup baik untuk menyelesaikan pekerjaan sekarang. Itu sudah memenuhi kebutuhan mereka untuk saat ini.

Itu bukan untuk mengatakan bahwa Agile bukan bagian penting dari proses di sini karena memungkinkan umpan balik terus menerus kepada klien tentang status proyek. Mereka dapat memastikan bahwa kemajuan sedang dibuat sebelum tonggak utama dan hasil. Mereka dapat mengidentifikasi potensi masalah dan masalah sebelumnya sebelum menjadi kesalahan yang terlalu mahal untuk diperbaiki.

Mungkin sebagai pelanggan mobil Anda hanya ingin melihat dan mengevaluasi mesin untuk memastikan bahwa Anda memang akan mendapatkan apa yang Anda harapkan. Ups, saya sebenarnya menginginkan mesin 6 silinder, bukan mesin 4 silinder! Bukankah aku sudah memberitahumu sebelumnya? Tidak masalah, mari lakukan perubahan ke pesanan pabrik.

Jual ide kepada klien bahwa adalah kepentingan terbaik mereka untuk menggunakan rilis perangkat lunak baru bukan sebagai pengganti dulu tetapi untuk mengevaluasi dan memastikan bahwa mereka senang dengan setiap langkah di sepanjang jalan.