Apakah kita gesit atau gesit?

Apa masalah utama dalam pengembangan perangkat lunak (atau mungkin dalam pekerjaan apa pun)? Ketika saya mengajukan pertanyaan kepada kolega saya, saya menerima jawaban berbeda: perubahan dalam persyaratan, ketidakcocokan harapan, kualitas kode, interaksi dengan tim lain ... menyimpulkan untuk diri saya sendiri - komunikasi adalah salah satu masalah yang paling penting.

Selama komunikasi, semua orang mengerti segalanya dengan caranya sendiri, menafsirkannya secara berbeda dari apa yang dikatakan. Pelanggan menyimpan di kepalanya gambar tertentu yang dia coba konversi menjadi kata-kata dan gambar, pengembang, mendengar kata-kata ini, mengubahnya di kepalanya menjadi semacam gambarnya sendiri. Dan dalam rantai ini bisa ada banyak tautan.

Mencoba memecahkan masalah ini, orang menulis ToR terperinci. Tetapi apakah ini menyelesaikan masalah? Pertanyaan yang sama, seperti yang saya lihat, ditanyakan oleh Bob Martin dan Martin Fowler bersama rekan-rekannya ketika mereka menulis Agile Manifest pada Februari 2001. Mari kita coba mencari tahu bersama tentang masalah ini, dan Agile memanifestasikan dirinya.

Ceritanya

Pada musim dingin tahun 2000 ada pertemuan para pemimpin yang disebut Pemrograman Ekstrim, mereka membahas metodologi pengembangan dan sebagai hasilnya mulai menawarkan beberapa metodologi Cahaya. Hanya sedikit orang yang tertarik (saya tidak ingin menyinggung siapa pun), kemungkinan besar mereka membuat lebih banyak lelucon tentang topik ini. Namun, beberapa orang luar dari pertemuan itu mengorganisir mereka sendiri setahun kemudian. Semuanya dimulai dengan fakta bahwa Bob Martin (ia menulis buku terkenal tentang kualitas kode), membuat buletin kepada para pemimpin pertemuan terakhir - mari kita berkumpul dan berbicara. Sebenarnya tidak ada yang konkret. Untuk beberapa waktu mereka bertengkar tentang tempat dan waktu. Hasilnya, mereka berkumpul pada 11 Februari 2001, di Utah, di sebuah resor ski. 17 orang dari sektor pembangunan, termasuk Bob Martin, Martin Fowler, dan lainnya. Mereka minum, Fowler bermain ski, dan setelah berdiskusi, Agile Manifest muncul.

Pada prinsipnya, semua yang terpenting dapat disampaikan secara literal melalui satu halaman teks, yang dapat dibaca di sini .
Tetapi seperti segala sesuatu yang singkat dan cermat dipikirkan, untuk memahami ini hanya dengan membaca itu tidak mudah bagi saya secara pribadi. Karena itu, mari kita pertimbangkan secara terperinci apa yang dipikirkan orang-orang yang menandatangani manifest Agile.

Prinsip Agile

Artinya, tanpa menyangkal pentingnya apa yang benar,
namun demikian, kami lebih menghargai apa yang ada di sebelah kiri.

Ini adalah aspek yang sangat penting yang harus selalu diingat ketika membaca sebuah manifesto, dan memang setiap hari dalam pekerjaan. Mari kita bahas pernyataan manifes utama.

Orang dan interaksi lebih penting daripada proses dan alat

Pada pandangan pertama, ini mungkin tampak seperti panggilan untuk membuang semua proyek Jira, pelacak bug, pencatat waktu dan alat lainnya dan semua proses yang dikonfigurasi. Apa yang bisa lebih mudah adalah berdiskusi secara lisan dengan rekan kerja tentang apa yang dilakukan seseorang. Kalau saja semua orang senang. Tapi itu terlihat sedikit utopis, bukan?

Prinsip ini menunjukkan bahwa ketika membangun proses pengembangan apa pun, penting untuk diingat mengapa itu dilakukan, untuk siapa dan untuk tujuan apa. Tidak masuk akal untuk menciptakan suatu proses demi proses itu sendiri. Karena pekerjaan pada akhirnya akan dilakukan oleh orang-orang, Anda dan saya. Apa yang akan terjadi jika semua percikan, semua minat di mata kita digantikan oleh tugas di yutrek atau bug di jir? Tidak ada gunanya untuk proses yang terorganisir dengan baik yang memberikan keamanan lengkap sebelum pelanggan, tetapi tidak memecahkan masalah pengembangan nyata. Detail birokrasi (formal) dapat dengan mudah menyebabkan hilangnya orang dalam suatu proyek. Saya cenderung berpikir hal yang sama berlaku untuk perencanaan. Kapan terakhir kali Anda melakukan perencanaan, yang pada akhirnya setidaknya 60-70 persen ternyata akurat?

Menurut pendapat saya, prinsip manifest ini bisa terdengar seperti ini:

Proses untuk orang, bukan orang untuk proses

Bagaimana manifesto menyarankan agar kita lebih dekat menerapkan prinsip ini?

• Para profesional yang termotivasi harus bekerja pada proyek.
• Komunikasi langsung adalah yang paling praktis dan efektif.
• Persyaratan dan solusi arsitektur terbaik datang dari tim yang mengatur sendiri.
• Tim harus terus-menerus menganalisis pekerjaan mereka dan mengoptimalkan proses.

Apa yang dikembangkan tim secara umum? Produk untuk pelanggan.

Produk yang berfungsi lebih penting daripada dokumentasi yang komprehensif

Jika ditafsirkan apa adanya, di dahi, saya pikir banyak yang akan setuju. Tapi apa lagi yang kamu lihat di sini? Secara pribadi, saya melihat di sini bahwa produk yang berfungsi, dan bekerja tepat waktu , lebih penting daripada kode yang ditulis dengan sempurna. Ini adalah kata-kata yang kejam dan menakutkan dalam banyak hal, jadi saya tidak boleh mengatakan itu. Tetapi sepanjang karir saya, belajar dari orang yang berbeda, menjadi semakin yakin akan pemikiran itu - jika saya memilih antara proyek yang ideal dalam hal kode dan arsitektur, dan proyek yang tidak terlalu indah di dalam, tetapi yang menguntungkan dunia, saya akan memilih yang kedua. Dan ya, saya akan meningkatkannya sebaik mungkin dan kemampuan saya.

Dan di sini Anda harus berpikir sejenak. Tetapi apa yang bisa dilakukan untuk membuat masalah ini lebih jarang terjadi? Jadi kita tidak harus memilih antara refactoring modul dan mengembangkan fitur baru?

• Produk yang berfungsi harus dilepaskan sesering mungkin.
• Produk yang berfungsi adalah indikator utama dari kemajuan.
• Perhatian terus-menerus pada keunggulan teknis dan kualitas meningkatkan fleksibilitas proyek.
• Diperlukan kesederhanaan dan minimalisasi.

Perhatikan poin tentang keunggulan teknis. Mempertahankan kode dengan baik (perlu) dan kualitas yang memadai, kami jauh lebih mudah untuk mentolerir perubahan dalam persyaratan dan, dengan demikian, perubahan dalam kode.

Semua prinsip, saya ingatkan, bukan negatif. Satu tidak mengecualikan yang lain. Ini tentang prioritas. Semuanya penting - produk, kualitas kode, dan dokumentasi. Tetapi apa yang harus dipilih, kapan harus memilih? Bekerja dalam keseimbangan tertentu antara kualitas dan produk, produk lebih mudah untuk diprioritaskan, tanpa menyangkal kualitas.

Sebagai contoh dari hidup saya, saya ingat pekerjaan pada proyek perbankan untuk pelanggan Rusia. Pekerjaan itu dilakukan dengan partisipasi analis dan secara ketat pada volumetrik TK. Setiap enam bulan sekali, manajer pergi ke kantor pusat pelanggan dan menunjukkan hasil pekerjaannya. Mudah ditebak bahwa, sebagai suatu peraturan, hasilnya berbeda secara signifikan dari harapan pelanggan. Akuntan pelanggan, yang pertama kali melihat sistem baru, dan umumnya tahu bahwa itu sedang dibuat, berada dalam keadaan ngeri - tidak ada yang seperti proses kerjanya yang biasa dalam sistem baru. Yang membawa kita ke topik selanjutnya.

Kolaborasi dengan pelanggan lebih penting daripada menegosiasikan ketentuan-ketentuan kontrak

Anda harus sangat berhati-hati dengan pernyataan ini. Dan lagi, ingatlah bahwa sisi kanan pernyataan itu tidak ditolak. Sebaliknya, kami katakan bahwa kontrak itu penting. Hanya ketika kita menimbang persyaratan kontrak dan kerja sama, kemitraan jangka panjang yang tepat, maka hubungan akan lebih penting. Tanpa menyangkal yang kedua. Saya menarik perhatian seperti ini karena kita hidup di dunia nyata dan kadang-kadang kita harus bekerja dengan pelanggan yang sangat berbeda. Ada kasus ketika pelanggan untuk tujuan egoisnya sendiri dapat mengambil keuntungan dari kenaifan dan, dengan mengorbankan kontrak, mengalahkan kondisi yang tidak dapat diterima oleh pengembang.

Namun demikian, jika kita berbicara tentang pelanggan baik abstrak tertentu dalam ruang hampa , maka mempertahankan hubungan jangka panjang yang akan mengarah pada proyek baru lebih penting.

Bagaimana cara mencapai pemahaman dan kepatuhan dengan harapan di seluruh proyek?

• Sepanjang proyek, pengembang dan perwakilan bisnis kustom harus bekerja bersama setiap hari.
• Komunikasi langsung adalah yang paling praktis dan efektif.

Pada saat yang sama, orang tentu tidak boleh lupa tentang mengukuhkan perjanjian untuk keselamatan mereka sendiri. Ada omong-omong (untungnya jarang) pelanggan yang umumnya menolak membayar setelah perjanjian.

Apa pun pelanggan, aktivitas dari pengembang selalu bermanfaat.
Saya juga akan menambahkan sendiri bahwa ini harus bekerja dua arah.

Ini membawa kita ke kelanjutan logis - perubahan dalam pekerjaan dan rencana. Hanya sedikit orang yang suka melakukan perubahan, itu sifat alami manusia, jika Anda memikirkannya. Sistem apa pun berusaha mencapai titik keseimbangan dan kekekalan tertentu. Tetapi pembangunanlah yang selalu dikaitkan dengan gerakan dan perubahan.

Kesiapan untuk perubahan lebih penting daripada mengikuti rencana awal.

Keberadaan rencana seperti itu tidak disangkal. Sebaliknya, rencana itu penting. Tetapi lebih penting untuk bersiap untuk mengubahnya, jika pada titik tertentu kami menyadari bahwa rencana ini tidak lagi berfungsi di lingkungan saat ini.

Contoh dari praktik rekan-rekan saya adalah proyek untuk pemeriksaan pajak dari salah satu negara CIS. Proyek negara, pada dasarnya, TK, undang-undang, tidak ada pembicaraan tentang lincah. Tetapi tim harus menunjukkan fleksibilitas pada saat negara bagian di negara pelanggan mengubah undang-undang pajaknya sehingga proyek tidak akan masuk akal sama sekali dalam bentuk yang direncanakan. Saya harus mengubah spesifikasi teknis dan mengulang proyek yang hampir selesai sehingga pelanggan dapat menggunakannya. Kalau tidak, tidak akan ada gunanya dalam pekerjaan, well, kecuali mungkin untuk penghasilan seperti itu.

Mungkin ini bukan contoh yang paling mengungkapkan, karena perubahan dipicu oleh faktor eksternal. Dan di sisi lain, pelanggan dapat, sekali lagi karena faktor-faktor eksternal, hanya sampai pada kebutuhan perubahan persyaratan. Kalau tidak, ia tidak akan mendapatkan keunggulan kompetitif.

Ini semua menyentuh topik yang agak menyakitkan bagi saya. Tetapi bagaimana jika kita melakukan proyek selama satu tahun penuh, dan kemudian setahun kemudian pelanggan berkata - oke, Anda hebat, dan sekarang kami akan meletakkan semua ini di arsip, kami tidak akan menggunakannya dan kami akan memulai proyek baru. Saya agak sakit terhadap hal ini, saya memiliki pengalaman serupa. Tapi sungguh - apa yang terjadi? Pekerjaan yang dilakukan membantu pelanggan untuk memahami bahwa jalur yang dipilih salah. Atau tidak efektif. Untuk mendapatkan keunggulan kompetitif, Anda perlu bekerja secara berbeda, melakukan proyek lain. Dan dia menerima pengetahuan ini dengan bantuan kami.

Aspek apa dari pekerjaan kita yang akan membantu kelancaran sudut-sudut ini dan membuat kelenturannya kurang menakutkan?

• Pengiriman perangkat lunak reguler dan awal.
• Perubahan disambut bahkan di tahap selanjutnya.
• Perubahan membantu memberi pelanggan keunggulan kompetitif.

Pada saat yang sama, kita hidup di dunia nyata, dengan orang-orang nyata, di mana tidak ada penilaian, termasuk ini, harus diangkat ke absolut. Ya, perubahan disambut saat mereka mengarah pada nilai tambah pada produk akhir. Tetapi penting untuk menjaga keseimbangan. Jika kami membuat perubahan tanpa henti, kami tidak akan pernah merilis produk dalam produksi. Oleh karena itu, pada titik tertentu Anda harus mengatakan - berhenti, kami merilis produk, memeriksa semuanya dalam praktik, dan mulai membuat versi dua, yang akan berisi perubahan ini. Setiap kali mengklarifikasi dengan pelanggan - nilai apa yang dilihatnya dalam perubahan ini atau itu.

Saya baru-baru ini membaca frasa di Facebook,

jika Anda tidak malu dengan produk Anda, maka Anda memasuki pasar terlambat

Cukup akurat mencerminkan esensi di atas. Kita perlu mencari titik keseimbangan tertentu, di mana produk akan cukup siap untuk rilis berikutnya dalam hal perubahan, dan di mana kita belum mulai menghabiskan terlalu banyak upaya untuk perubahan kecil.

Alih-alih menyimpulkan

Pencipta manifesto Agile tidak menentukan aturan apa pun, dan bahkan sebaliknya. Tetapi mereka mengangkat masalah penting dalam pekerjaan kami - interaksi orang, pengembang, dan pelanggan, kesiapan untuk perubahan. Prinsip-prinsip ini penting di alam. Dengan pentingnya dokumentasi, kontrak, proses dan perencanaan, interaksi manusia, kesiapan untuk perubahan yang berharga, dan membawa sesuatu yang bermanfaat bagi dunia, semuanya semakin penting.