Saya perhatikan. bahwa bekerja dengan pelanggan mana pun sangat mirip dengan aplikasi web. Artikel ini menunjukkan bagaimana Anda dapat menggunakan pengetahuan ini untuk meningkatkan proses.
Tentang siapa pengontrol, dan siapa model di bawah potongan.
Artikel ini mengasumsikan bahwa pembaca tahu apa itu MVC .
Ketika membangun model, saya pergi ke penyederhanaan yang disengaja.
- Semua peserta dalam hubungan adalah orang yang bertanggung jawab dan ingin mencapai hasil tunggal.
- Pertimbangkan pengembangan kustom yang khas.
Aktor
Pelanggan - orang yang memesan produk atau proyek. Ini bisa eksternal dan internal.
Perusahaan (kontraktor) - pihak dalam hubungan kontraktual dengan Pelanggan.
Manajer - orang yang berinteraksi dengan Pelanggan dan pelaksana akhir (programmer). Ia menerima tugas dari Pelanggan sebagai input, menerjemahkan tugas-tugas ini ke Kontraktor dan mengembalikan hasilnya kepada Pelanggan.
Eksekutor utama adalah seorang programmer yang mengimplementasikan tugas. Idealnya, hanya berkomunikasi dengan Manajer.
Prosesnya
Proses pengembangan kustom terlihat seperti ini:
- Pelanggan menetapkan tugas untuk Perusahaan.
- Perusahaan, yang bertindak sebagai router, membawa tugas kepada Manajer.
- Manajer mengklarifikasi detail dengan pelanggan.
- Manajer mengatur tugas ke programmer.
- Programmer melakukan tugas dan mentransfer tugas yang sudah selesai.
- Manajer mengidentifikasi kekurangan dan kembali ke langkah 4.
- Jika tidak ada kekurangan, maka Manajer mentransfer tugas kepada Pelanggan.
- Pelanggan mengidentifikasi kekurangan dan kembali ke paragraf 3.
- Jika tidak ada kekurangan, maka Pelanggan membayar untuk pekerjaan itu.
Poin termanis bagi Perusahaan adalah paragraf 9. Tapi jalan menuju ke sana biasanya panjang dan berduri.
Masalah proses semacam itu
Sepintas, segala sesuatu dalam proses ini benar dan tidak ada yang diperbaiki. Namun, ini tidak benar. Kami menyoroti masalahnya.
Manajer yang sangat buruk hanyalah router tugas. Saya harap Anda beruntung dan tidak bekerja dengan itu manajer router. Saya beruntung. Saat bekerja dengan manajer sungguhan, ada juga masalah.
Manajer mengatur tugas kepada programmer dengan mengucapkannya dalam suaranya atau di ruang obrolan. Klarifikasi masalah tidak dicatat di mana pun. Si programmer sepertinya mengerti pernyataan masalahnya. Tetapi tentu saja saya memahaminya dengan cara saya sendiri, dan tidak seperti yang dijelaskan oleh manajer (dari sudut pandang manajer). Karena pernyataan masalah tidak diperbaiki, masing-masing peserta menafsirkannya dengan caranya sendiri.
Dengan pendekatan ini, banyak iterasi 4-6 dan 3-8 muncul. Manajer yang baik dibedakan dari manajer yang buruk dengan rasio antara jumlah iterasi ini. Manajer yang baik memiliki sejumlah unit upaya untuk menyerahkan tugas kepada pelanggan. Dan percobaan itu, Anda dapat menebaknya, segera berhasil. Pada saat yang sama, iterasi bisa menjadi banyak pekerjaan dengan programmer. Router tidak memeriksa ulang apa pun untuk programmer dan hanya meneruskan tugas kepada pelanggan. Dan jumlah iterasi 3-8 mencapai nilai maksimum dan sama dengan jumlah iterasi 4-6. Dan tentu saja, programmer yang harus disalahkan untuk semuanya, karena dari sudut pandang manajer ia melakukan pekerjaan yang buruk.
Sejumlah besar komunikasi antara Manajer dan Programmer dalam proses melewati tugas mengarah ke peningkatan negatif di antara mereka. Selain itu, tenggat waktu untuk menyelesaikan tugas, pembengkakan biaya, dan sebagainya terganggu. Pada saat yang sama, saya tidak keberatan komunikasi selama spesifikasi persyaratan dan pada tahap pengaturan tugas.
Apa yang harus dilakukan untuk menghindari fenomena yang tidak diinginkan tersebut?
Asosiasi
Mari kita lihat skema kerja dengan Pelanggan yang disederhanakan:
Pengembang yang berpengalaman akan melihat kecocokan lengkap dengan MVC:
Sangat mudah untuk melakukan perbandingan entitas.
- Pelanggan = Pengguna
- Manajer = Pengendali
- Artis = Model
- Hasil Kerja = Lihat
- Perusahaan = Seluruh Aplikasi
Hanya kebetulan? Saya kira tidak. Jika skema interaksi bertepatan, maka Anda dapat mencoba menerapkan pendekatan yang kami gunakan dalam pengembangan untuk proses mengelola pengembangan kustom.
Langkah pertama untuk memperbaikinya
Alat apa yang kita miliki saat kita berkembang?
Kami mendefinisikan lapisan aplikasi. Kami mendefinisikan kontrak interaksi antara lapisan dan memecah aplikasi menjadi modul. Mari kita coba terapkan alat-alat ini di sini.
Layers
Programmer dalam perannya yang biasa tidak berkomunikasi dengan pelanggan. Ia dapat terlibat pada tahap spesifikasi persyaratan sebagai ahli. Dalam kasus lain, hanya manajer yang berkomunikasi dengan pelanggan, sehingga mengisolasi lapisan model dari dampak langsung pelanggan.
Dalam proses meneruskan tugas kepada Pelanggan, programmer yang melakukan tugas tidak boleh dilibatkan. Tidak pernah. Tidak pernah sama sekali.
Dekomposisi
Tugas besar perlu dibagi menjadi tugas kecil. Tugas kecil adalah tugas selama maksimal beberapa hari.
TK
Semua orang tahu ungkapan: Tanpa TK yang jelas - hasil HZ.
Ketika mengklarifikasi persyaratan, artefak seperti Kerangka Acuan harus muncul dengan Pelanggan. Kemudian pernyataan masalah kepada programmer diperkaya dilengkapi dengan TK. Untuk saat ini, kami akan menerima ini sebagai kontrak tidak hanya antara Perusahaan dan Pelanggan, tetapi juga antara manajer dan programmer.
Dalam perusahaan normal mana pun, TK adalah elemen yang sangat diperlukan untuk tugas tersebut. Benar, ini hanya berlaku untuk tugas besar.
Tampaknya TK sangat mirip dengan kontrak dalam konteks pemrograman. Apa yang saya lihat masalah dengan TK:
- Untuk tugas besar akan ada TK halaman 400 atau lebih, yang programmer tidak akan cocok sepenuhnya di kepalanya. Saya mulai tertidur di halaman sepuluh.
- Untuk tugas rata-rata, akan ada tautan ke bagian atau paragraf dalam ToR. Kemudian programmer hanya akan membaca item ini. Maka tentu saja ternyata satu titik kecil di bagian lain dari TOR secara drastis mengubah keseluruhan implementasi
- Untuk tugas kecil yang merupakan bagian dari dukungan, TK tidak akan sama sekali.
- TK tidak selalu ditafsirkan secara jelas oleh para pihak dalam proses pembangunan. Dan semua yang bisa disalahpahami akan benar-benar salah dan disalahpahami.
Dapat dilihat di sini bahwa TK jelas tidak cukup. Pertanyaannya adalah apa yang harus dilakukan?
Kriteria penerimaan
Dalam praktik pengembangan, pengujian dilakukan dengan bangga. Tes telah membuktikan kebutuhan mereka untuk pengembangan kualitas.
Bisakah kita menerapkan tes dalam praktik kita? Ya, jadi kami menguji semuanya dan bahkan dalam deskripsi prosesnya, pembaca yang penuh perhatian akan berkata. Ya, tapi tidak. Saya berbicara sedikit tentang pengujian lain.
Pengujian dalam proses yang dijelaskan di atas terdiri dari memeriksa secara manual kesesuaian hasil dengan TK yang disampaikan. Setiap peserta pengujian semacam itu, setelah membiasakan diri dengan TK, entah bagaimana menafsirkannya dalam gambar mereka sendiri. Masalahnya adalah bahwa setiap orang memiliki gambaran yang berbeda. Manusia adalah penerjemah yang tidak sempurna. Anda perlu mengkompilasi TK ke dalam biner sekali. Jangan menafsirkan berkali-kali dan dengan cara yang berbeda. Dan sekali di "kertas". Akibatnya, satu set artefak tertentu akan muncul. Ini mungkin kasus uji atau kriteria penerimaan.
Kriteria penerimaan harus dikembangkan oleh manajer bersama dengan klien. Kriteria penerimaan tidak bertentangan dengan TK, tetapi hanya menjelaskannya. Kriteria penerimaan dapat atau bahkan harus menjadi dokumen terpisah, yang ditandatangani oleh Pelanggan dan Perusahaan. Kemudian pelanggan akan menerima tugas sesuai dengan kriteria penerimaan yang sama.
Dengan kriteria penerimaan yang dirumuskan dengan benar, Programmer tidak dapat memiliki perbedaan dalam TK dan bahkan meragukan apa yang seharusnya ia lakukan.
Untuk tugas kecil, mungkin tidak ada TK, tetapi kriteria penerimaan harus ada. Kriteria penerimaan mirip dengan tes yang ditulis sebelum implementasi. Apakah ini mengingatkan Anda pada sesuatu?
Untuk menjelaskan kriteria penerimaan, Anda dapat menggunakan bahasa Gherkin yang ditawarkan BDD . Agar mudah untuk memulai, Anda dapat menggambarkannya dalam bahasa Rusia yang biasa.
Keberatan
Saya melihat pertanyaan dari manajer:
Pengembangan kriteria penerimaan membutuhkan waktu ekstra. Di mana mendapatkannya?
Tanpa meluangkan waktu untuk mengembangkan kriteria penerimaan, Anda menyebarkan biaya ini di semua tahap. Dan sangat banyak orang menghabiskan waktu: manajer, programmer, tester, pelanggan.
Tetapi Anda masih mengembangkan kriteria penerimaan. Dan lebih dari sekali. Dalam persiapan Kerangka Acuan, beberapa kriteria penerimaan muncul di kepala analis dan pelanggan. Saat mengatur masalah, hal yang sama terjadi. Programmer membentuknya di kepalanya. Pada saat penyerahan tugas pada tahap apa pun, proses yang sama dilakukan. Tetapi pada tahap tidak ada artefak muncul. Itulah perbedaan keseluruhan.
Jika ada kriteria penerimaan, jumlah iterasi sebelum penerimaan tugas oleh pelanggan berkurang secara signifikan. Jumlah komunikasi negatif berkurang secara alami. Sejalan dengan itu, hubungan dengan Pelanggan ditingkatkan, dimana Perusahaan melewati tugas pertama kali.
Saya berani meyakinkan Anda bahwa pengembangan kriteria penerimaan terbayar dengan baik.
Hasil
Bagaimana proses berubah setelah pengenalan kriteria penerimaan bersama dengan TK?
Programmer melakukan pekerjaannya sesuai dengan kriteria penerimaan. Manajer mengambil pekerjaan itu. Kemudian Pelanggan melakukan hal yang sama. Dan dia tidak punya alasan untuk tidak membayar tugas ini.
Apakah akan selalu berhasil tanpa gangguan? Saya kira tidak. Pertama, akan ada masalah dengan pengembangan, perumusan kriteria penerimaan dan kesepakatan mereka dengan Pelanggan. Dan ini akan menyebabkan pengulangan berulang dengan Programmer dan Pelanggan. Namun jumlah mereka diminimalkan.
Apa yang Anda pikirkan tentang ini?