Tata kelola pengembangan bersama

Membangun kerangka kerja tata kelola pengembangan bersama yang efektif adalah bagian penting untuk memastikan konsistensi dan pengulangan dalam proyek yang ditentukan pembuat dan tim gabungan. Artikel ini menjelaskan pendekatan untuk mendefinisikan diagram alur tata kelola.

Menentukan proses end-to-end

Anda dapat menggunakan proses berikut sebagai contoh dan menyesuaikannya dengan praktik terbaik organisasi Anda. Setiap langkah tidak perlu diselesaikan, asalkan Anda mencapai hasil yang diperlukan.

Proses sampel secara end-to-end

Menambahkan fitur ke backlog

Backlog memungkinkan Anda merencanakan proyek dengan menambahkan fitur yang akan meningkatkan pengalaman secara keseluruhan. Backlog juga memberikan peta jalan secara keseluruhan yang akan dilaksanakan tim.

Saat menambahkan fitur baru ke backlog, sasarannya adalah untuk mendeskripsikan cakupan umum. Setiap fitur kemudian menentukan nilai bisnis, draf judul kisah, cakupan, dan perubahan model data yang akan meningkatkan upaya pengembangan kode.

Selain itu, saat menambahkan fitur penting bisnis, Anda sebaiknya mengidentifikasi skenario penting untuk mengotomatisasi pengujian Anda. Setelah menambahkan fitur, Anda dapat menjadwalkan Rapat Penyelarasan Cakupan.

Rapat Penyelarasan Cakupan

Fokus rapat ini harus terbatas pada meninjau setiap fitur baru yang diajukan, kemudian memeriksa aplikasi, skenario, atau model data yang sudah ada yang telah menyediakan fungsi ini untuk menghindari duplikasi upaya. Rapat ini juga memberikan peluang untuk mendiskusikan dampak pada aplikasi lain. Terakhir, Anda harus memeriksa apakah fitur ini memerlukan Tinjauan Pengalaman.

Menambahkan kisah dan papan cerita ke backlog

Setelah rapat perataan cakupan, setiap draf judul kisah pengguna dapat ditambahkan dalam fitur. Pada titik ini, rincian tidak diperlukan, dan status kisah pengguna adalah "Baru". Anda dapat melihat kisah di backlog atau tampilan papan.

Gambar berikut menampilkan contoh kisah pengguna yang ditambahkan ke backlog.

Contoh kisah pengguna yang ditambahkan ke backlog

Pada titik ini, penting untuk mempertahankan kualitas dengan mengatur pekerjaan melalui aliran kerja dan aplikasi. Pendekatan ini akan membantu mengumpulkan item kerja terkait dan memungkinkan pakar di setiap aliran kerja mengembangkan dan mempertahankan pemahaman yang mendalam tentang fungsi dan penggunaan data dalam setiap aplikasi.

Tinjauan Pengalaman

Tinjauan Pengalaman harus berfokus pada pengalaman pengguna akhir dan memastikan tim Anda mengikuti praktik terbaik organisasional. Konsistensi ini memastikan bahwa semua aplikasi memberikan pengalaman yang dapat andal dan dapat berulang bagi pengguna akhir dan tim dukungan.

Tambahkan detail cerita

Menambahkan kisah pengguna biasa dapat menggunakan informasi berikut:

  1. Judul: Sebagai <persona>, saya dapat <do something> sehingga <impact/priority/value>
  2. Deskripsi: Deskripsi mencakup (meskipun tidak terbatas pada) rincian kunci tertentu, seperti:
    • Deskripsi ringkas tentang skenario yang meringkas hasil yang diinginkan
    • Narasi - menjelaskan tindakan yang akan diperlukan pengguna untuk menavigasi dan mencapai skenario
    • Alternatif kisah parasut - menjelaskan cara lain agar pengguna dapat mencapai hasil yang sama
    • Catatan Desain – merekam entitas, bidang, tampilan, layar maket, dan aturan bisnis yang terkait dengan kisah pengguna
    • Peran Keamanan Berpengaruh - daftarkan semua peran keamanan yang mempengaruhi atau yang relevan dengan kisah pengguna.

Setelah menambahkan semua rincian ini, Anda akan mengubah status kisah pengguna menjadi "Siap Diperiksa". Di kebanyakan kasus, tim fitur dan tim bisnis (jika berlaku) akan meninjau kisah pengguna.

Tinjauan kisah

Tinjauan Kisah biasanya dilakukan dalam tim gabungan untuk memastikan bahwa semua rinciannya dipanggil dalam kisah dan tidak ada ambiguitas. Setelah selesai semua tinjauan, rekomendasi adalah menetapkan kisah pengguna ke anggota tim. Memastikan bahwa tim Anda tetap selaras selama proses pengembangan sangat penting untuk mencapai tujuan Anda secara keseluruhan.

Menambahkan tugas dan menguji kasus

Setelah meninjau kisah, anggota tim membuat tugas di Azure DevOps. Proses keseluruhan untuk menambahkan tugas dan kasus pengujian adalah sebagai berikut:

  1. Buka backlog sprint. Atau, buat sprint baru.
  2. Tambahkan item kerja yang ada ke sprint. Jika Anda telah menambahkan item kerja yang tidak muncul dalam sprint, maka Anda harus memeriksa area dan jalur iterasi. Ingatlah untuk menetapkan tugas yang tidak berinduuk ke item kerja yang relevan.
  3. Menambahkan tugas ke item backlog. Jika Anda tidak memiliki item backlog yang ditetapkan ke sprint, maka lakukan sekarang. Juga atur tanggal mulai dan berakhir sprint.
  4. Isi formulir tugas. Sebagai aturan praktis, tugas harus berlangsung tidak lebih dari sehari untuk diselesaikan. Tugas yang lebih besar dari skala waktu ini harus dibagi.
  5. Lacak atau integrasikan tugas yang berinduk. Anda dapat melacak tugas yang tidak berinduk sama seperti tugas lain atau menariknya ke item backlog yang ada untuk induk mereka.

Setelah menambahkan tugas dan menguji kasus, maka Anda dapat selanjutnya menetapkan kapasitas sprint.

Untuk informasi lebih lanjut tentang menambahkan tugas, lihat Menambahkan tugas ke item backlog untuk mendukung perencanaan sprint.

Menyiapkan solusi

Aspek penting untuk keberhasilan pengembangan bersama adalah proses manajemen rilis terstruktur. Solusi adalah mekanisme penerapan manajemen siklus hidup aplikasi (ALM); Anda menggunakannya solusi untuk mendistribusikan komponen di seluruh lingkungan melalui ekspor dan impor. Komponen mewakili artefak yang digunakan di aplikasi dan sesuatu yang berpotensi dapat Anda sesuaikan. Apa pun yang dapat tercakup dalam solusi adalah komponen, seperti tabel, kolom, kanas, dan aplikasi yang diarahkan model, aliran Power Automate, bot obrolan, entitas, bidang, diagram, dan plug-in.

Penting

Selama perencanaan rilis, tentukan strategi untuk mengelola solusi dalam proyek Anda. Gunakan solusi untuk mengelola proyek dan menemukan komponen yang telah Anda buat dengan mudah untuk kemudian didistribusikan ke lingkungan lain.

Penyebaran

Komponen dapat mengambil beberapa langkah cepat untuk diselesaikan, tergantung pada kompleksitas dan kecepatan tim. Komponen harus ditambahkan ke solusi dalam lingkungan pengembangan saat tugas diselesaikan. Solusi kemudian diimpor ke lingkungan produksi setelah diuji. Sebaiknya Anda juga memelihara satu lingkungan pengujian untuk melakukan pengujian end-to-end dan mencoba penyebaran solusi sebelum melakukan produksi.

Lingkungan Power Platform

Lingkungan adalah ruang untuk menyimpan, mengelola, dan berbagi data bisnis, aplikasi, dan alur proses bisnis Anda. Lingkungan juga berfungsi sebagai wadah untuk memisahkan aplikasi yang mungkin memiliki peran, persyaratan keamanan, atau audiens target yang berbeda.

Jika organisasi Anda memiliki konfigurasi multi-tim campuran yang akan membuat setiap tim mengembangkan solusinya sendiri, maka durasi peluncuran dan pelepasan harus dikoordinasikan. Jalur cepat tidak harus memiliki panjang yang konsisten di sepanjang timeline proyek dan dapat berbeda dalam durasi antar tim, sesuai dengan preferensi grup masing-masing. Namun, irama rilis tidak dapat kurang dari durasi sprint tersingkat di seluruh tim.

Kontrol sumber

Pertimbangkan mengadopsi sistem kontrol kode sumber seperti Azure DevOps. Azure DevOps menyediakan layanan pengembang untuk mendukung tim agar merencanakan pekerjaan, berkolaborasi dalam pengembangan kode, serta membangun dan menyebarkan aplikasi.

Ekspor solusi dari lingkungan pengembangan yang berisi aplikasi dan penyesuaian, bongkar kemasan solusi, dan Simpan komponen di sistem kontrol sumber.

Topik lanjutan: tinjauan permintaan Tarik (PR)

Anda hanya boleh membuat PR untuk kisah yang aktif dan telah memiliki fitur yang ditinjau dan disetujui. Anda harus memastikan bahwa versi solusi akurat, mengikuti panduan lengkap dan dev yang ditetapkan dalam Menerapkan praktik Scrum untuk tim Anda dalam Papan Azure. Hasil uji dari PR dapat berupa tangkapan layar atau video yang menunjukkan fungsi yang sedang dibangun.

Mengotomatisasi proses tata kelola PR akan membantu memastikan kualitas kode tanpa memerlukan tinjauan manual pemeriksaan dasar seperti versi solusi.

Catatan

Gunakan alat pemeriksa PR untuk mengotomatisasi proses pemeriksaan permintaan tarik.

Template dan standardisasi

Template dan standarisasi memberikan efisiensi dengan membantu meningkatkan konsistensi dalam tim. Semua aspek operasi— tim, baik itu tugas orientasi, presentasi ulasan cerita, atau templat item kerja yang membantu menghemat waktu dan memberikan panduan kepada tim saat menentukan cerita, fitur, bug, atau tugas— pengguna, mendapat manfaat dari standardisasi dan penyederhanaan.

Menerapkan model dukungan yang efektif

Model dukungan yang efektif sangat penting untuk keberhasilan aplikasi jangka panjang setelah penyebarannya, seperti yang menjadi sorotan pada bagian sebelumnya tentang cara menghasilkan matriks dukungan. Bug dan pemadaman tidak dapat dielakkan, jadi sangat penting bagi tim memiliki pendekatan terstruktur untuk menangani kejadian ini, dan matriks dukungan memberikan kerangka kerja yang diperlukan.

Membuat perjanjian tingkat layanan

Faktor utama dalam model dukungan mana pun adalah definisi SLA (Perjanjian Tingkat Layanan). SLA harus merupakan dokumen resmi yang dibuat tim yang berisi bagian yang mencakup item berikut:

  • Pemadaman tingkat pemadaman layanan yang diterima, siapa yang menginformasikan, tindakan yang akan diambil, konfirmasi dimulainya kembali layanan, dan tindakan untuk mencegah pengulangan. Prosedur pengujian otomatis yang digunakan tim harus sesuai dengan toleransi pemadaman yang diharapkan dan SLA yang berlaku.
  • Bug – yang dapat memberitahukan, penetapan tingkat kesulitan, pengelompokan, tindakan pada deteksi, orang yang bertanggung jawab untuk mengatasi dan mengesahkan.
  • Eskalasi – tingkat eskalasi, penetapan staf ke tingkat, tanggung jawab di setiap tingkat, daftar distribusi untuk setiap tingkat, dan sebagainya.

SLA harus disimpan di portal dokumentasi tim dan diperbarui jika diperlukan.

Pemberian Dukungan Aplikasi

Pendekatan terbaik untuk memberikan dukungan aplikasi yang ditentukan dalam SLA adalah untuk tim yang membuat solusi juga bertanggung jawab untuk mendukungnya. Keunggulan sistem ini adalah:

  1. Hal ini akan meningkatkan pengembangan kualitas yang lebih baik, karena mereka yang membuat aplikasi tahu bahwa mereka harus mendukungnya.
  2. Pembuat konten akan dapat menemukan dan memperbaiki bug lebih cepat daripada tim pihak ketiga, karena mereka lebih mengenal aplikasi tersebut.
  3. Mendelegasikan perbaikan perangkat lunak yang berpotensi penting bagi grup lain dapat mendemoralisasi dan memakan waktu untuk grup tersebut. Sama seperti fase pembuatan, pengembangan, dan penyebaran aplikasi lainnya, tim gabungan harus bekerja sama dengan IT untuk bantuan bila diperlukan.

Memantau kepuasan dan kegunaan aplikasi

Bagian terakhir dari upaya dukungan adalah memantau dan menilai kepuasan dan kegunaan aplikasi yang disebarkan. Metrik berguna di sini, dengan metode yang lebih tradisional, seperti poling dan kuesioner. Untuk informasi lebih lanjut tentang memantau penggunaan aplikasi, lihat Analitik Admin untuk Power Apps

Pada akhirnya, jika pelanggan tidak menggunakan aplikasi yang dipublikasikan, maka aplikasi tersebut tidak memenuhi tujuannya. Pertemuan tinjauan rutin dapat memeriksa metrik kepuasan dan kegunaan ini untuk membuat loop tanggapan positif yang dapat mengubah atau menambahkan kisah ke backlog untuk membuat dan kemudian menyebarkan versi aplikasi yang diperbarui.

RINGKASAN

Pengembangan alat tanpa kode dan kode rendah seperti Power Apps telah memperluas pilihan bagi pakar teknologi bisnis atau pembuat untuk membuat, mengembangkan, dan menyebarkan aplikasi. Pengembangan ini berfungsi terbaik dalam lingkungan tim gabungan, yang terdiri dari pemilik produk, pakar domain, profesional dev, dan administrator, dengan tim ini mendatangkan sumber daya lain sebagaimana diperlukan.

Mengintegrasikan pendekatan pengembangan tangkas dan scrum dalam tim gabungan akan menghasilkan pengembangan aplikasi yang lebih cepat dan probabilitas keberhasilan penyebaran yang lebih tinggi dengan rangkaian fitur yang memberikan perbedaan berarti bagi bisnis. Dengan menerapkan praktik terbaik, panduan, dan rekomendasi ini, tim gabungan Anda akan dapat menggunakan Power Apps untuk mengatasi masalah transformasi digital organisasi Anda.