Bagaimana saya bisa melacak atribut kualitas di Kanban tim saya?

Tim saya menggunakan sistem Kanban untuk melacak kemajuan sehari-hari dan bekerja dengan sangat baik untuk memahami kemajuan fitur (ditangkap sebagai cerita pengguna). Kami telah mengizinkan desain sistem kami muncul saat kami mengembangkan fitur yang bekerja dengan baik hingga saat ini. Dalam dua minggu terakhir kami telah melakukan beberapa diskusi tentang pengorbanan arsitektur yang secara khusus terkait dengan atribut kualitas kinerja dan kemampuan modifikasi.

Saya pikir apa yang terjadi adalah ketika kami menerapkan fitur dan merancang sistem, kami secara implisit membuat keputusan tentang arsitektur tetapi tidak mempertimbangkan keputusan tersebut dalam hal persyaratan atribut kualitas yang diketahui. Akan sangat bagus jika saya bisa melacak / menangkap / menggambarkan secara visual bagaimana keputusan desain penting ini dibuat sehingga anggota tim memiliki kesempatan yang lebih baik untuk tidak menciptakan ketegangan tambahan dengan arsitektur sistem saat ini sedang dilaksanakan. Dan tentu saja, untuk lebih menyulitkan, fitur di papan kami tidak hanya berfungsi dan terkadang menyembunyikan kompleksitas arsitektur!

Bagaimana saya bisa melacak kemajuan atribut kualitas (atau keputusan lain yang relevan secara arsitektur) secara visual di kanban tim saya?

kami secara implisit membuat keputusan tentang arsitektur tetapi tidak mempertimbangkan keputusan tersebut terkait persyaratan atribut kualitas yang diketahui.

Saya pikir Anda dapat memvisualisasikan ini dengan membuat langkah "tinjauan arsitektur" dalam alur kerja Anda. Langkah itu akan diwakili oleh kolom dewan Kanbad dengan batas WIP sendiri. Batas WIP akan tergantung pada berapa banyak arsitek / desainer yang Anda harus berpartisipasi dalam ulasan ini.

Tim pengembang bertanggung jawab atas alur cerita pengguna yang horizontal dan kiri ke kanan. Arsitek akan, dalam kebanyakan kasus, menyentuh cerita hanya ketika mereka berada di kolom tinjauan arsitektur / teknis. Perpotongan kolom dengan garis horizontal menggambarkan pertemuan pengembang dan arsitek.

Salah satu tim tempat saya bekerja memiliki langkah serupa di mana mereka melakukan peninjauan skema basis data dengan arsitek data utama. Mereka tidak menggunakan Kanban, tetapi jika mereka melakukannya, mereka akan sangat mungkin memiliki kolom ini di papan tulis mereka.

Atribut kualitas yang diketahui kemudian dapat direpresentasikan sebagai:

• definisi yang dilakukan untuk langkah tinjauan arsitektur.
• tes penerimaan di sekitar cerita pengguna yang sudah dilakukan yang mewakili persyaratan non-fungsional. Maka definisi yang dilakukan untuk kisah pengguna baru akan mencakup tidak melanggar tes tersebut.

TAMBAH : Langkah alur kerja "tinjauan arsitektural" mungkin mencurigai suatu masalah yang disebut tragedi bersama . Berikut ini adalah posting blog yang bagus tentang bagaimana visualisasi Kanban dapat membantu mengatasinya dan kemungkinan solusinya.

Sebenarnya ada dua bagian untuk pertanyaan ini. Satu bagian adalah: Bagaimana kita tahu kapan arsitektur diubah. Bagian kedua adalah: Bagaimana kita tahu bahwa arsitekturnya masih bagus.

Untuk bagian pertama ini: Bagaimana Anda tahu kapan arsitektur diubah?

Tujuannya di sini adalah untuk mengambil sesuatu yang dilakukan secara implisit dan membuatnya eksplisit

• Saran Alexei adalah satu opsi. Buat kolom di papan untuk tinjauan arsitektur. Kemudian pindahkan kartu ke sana jika akan membutuhkan keputusan arsitektur
• Pilihan lain adalah membuat kebijakan eksplisit tentang cara menangani ini: "Jika kita perlu mengubah arsitektur maka kita harus berpasangan dengan orang lain" adalah contoh dari salah satu kebijakan tersebut. Dalam satu proyek, kami memiliki kebijakan bahwa perubahan kode pada modul khusus tertentu harus dilakukan dengan berpasangan dengan orang-orang tertentu. Ketika seseorang ingin mengubah kode di sana, mereka akan memanggil pasangan dan bergabung. Sisa pekerjaan dilakukan solo. Anda dapat melakukan sesuatu yang mirip dengan arsitekturnya.

Anda mungkin akan pergi dengan yang pertama, jika banyak kartu memerlukan ulasan, atau jika arsitek bukan bagian dari tim dan handoff diperlukan, atau ulasan akan cukup rinci untuk mengambil beberapa waktu yang ingin Anda lacak papan. Yang terakhir adalah pilihan jika hanya sedikit kartu yang menyentuh arsitektur, dan mudah untuk menemukan pasangan sesuai permintaan.

Sekarang sampai pada pertanyaan kedua: Bagaimana kita tahu bahwa arsitekturnya masih bagus?

Saya penggemar visualisasi. Anda dapat memiliki bagan di papan tulis dengan catatan post-it yang menggambarkan komponen dan arsitektur.

Ada juga analisa statis yang akan menganalisis basis kode dan menghasilkan gambar dengan grafik ketergantungan dari berbagai komponen. Anda dapat menjalankannya, mengambil cetakan dan menempelkannya di dinding seminggu sekali atau lebih. Mungkin dua cetakan terbaru bisa ada di dinding, jadi Anda bisa melihat apakah ada yang berubah dalam minggu terakhir.

Yang memungkinkan Anda lakukan adalah membuat arsitektur dan desain Anda terlihat. Anggota tim akan meliriknya sesekali dan mengomentarinya jika ada sesuatu yang dapat diubah atau diolah kembali atau dilakukan dengan cara yang lebih baik.

Saya telah melihat masalah ini juga. Pengambilan keputusan implisit! Jika yang tersirat adalah masalahnya, akankah membuatnya sejelas mungkin menyelesaikan masalah? Apa yang saya sarankan adalah untuk sedikit mengubah proses arsitektur untuk 'mulai menjabarkan' pemikiran implisit yang berkembang menjadi keputusan. Tujuan dari langkah tambahan dalam proses ini adalah untuk membuat anggota tim memahami bahwa semua orang cenderung membuat keputusan arsitektur implisit. Langkah ini hanya akan membuat keputusan implisit keluar jalur.

Menjaga "Menjelaskan keputusan tersirat" sebagai bagian dari kanban untuk masing-masing skenario dapat membantu.

Apa yang akan saya sarankan mungkin tidak praktis. Tetapi jika proses dipetakan ke satu set item kanban dan jika ini dibawa pada papan untuk setiap skenario lengkung, tidak akan membantu Anda melacaknya. Saya sarankan Anda juga bisa memetakannya ke templat skenario enam bagian dan berimprovisasi papan kanban untuk mengakomodasi temuan, QA dapat dilacak.

Vikram.

Ini adalah salah satu risiko menunda keputusan arsitektur pada tim Agile. Jelas hal yang paling bertanggung jawab untuk menjadi gesit adalah menunda keputusan arsitektur sampai saat yang bertanggung jawab terakhir . Tetapi kemungkinan adalah saat bertanggung jawab terakhir yang dapat (atau harus) terjadi sejak dini.

Satu hal yang membantu adalah menggambarkan dengan jelas sejak awal tentang persyaratan mengemudi utama Anda; hal-hal yang secara jelas Anda tahu harus dimiliki (tetapi tidak harus diterapkan saat ini.) Arsitektur Anda yang berkembang (yang berupaya menjadi minimalis dan fleksibel) harus mengakomodasi dukungan yang ada atau yang akan datang untuk persyaratan semacam itu.

Lebih penting lagi, arsitektur Anda yang sedang berkembang TIDAK HARUS mengimplementasikan artefak yang dapat (atau dapat diperoleh) dengan cara mendukung persyaratan penggerak utama tersebut, bahkan jika artefak itu dimaksudkan untuk menyelesaikan kebutuhan saat ini. Kita dapat merujuk pada artefak tersebut sebagai artefak yang mengganggu , artefak yang memberikan nilai nyata (karena mereka mengimplementasikan solusi untuk persyaratan yang ada) tetapi kehadirannya membuat sulit / mahal untuk mengimplementasikan persyaratan penggerak utama di masa depan.

Dalam kasus ketika Anda harus menerapkan artefak yang mengganggu, tugas Anda adalah merencanakan penghapusannya di beberapa titik (sehingga Anda dapat menerapkan persyaratan mengemudi utama yang sedang diganggu.)

Jelas ini semua esoteris tanpa konteks yang nyata dan nyata (seperti proyek nyata). Tetapi kurang lebih model proses pengembangan Anda dan arsitektur Anda yang berkembang harus mempertimbangkan ini.

Persyaratan implisit adalah arsitektur yang mati. Semuanya harus dibuat eksplisit, baik persyaratan penggerak utama maupun persyaratan tambahan. Anda tidak perlu menerapkan persyaratan sejak dini. Anda hanya perlu memperhitungkannya.

PS. Dengan persyaratan, maksud saya persyaratan arsitektur tingkat sistem dan belum tentu persyaratan tingkat aplikasi sesaat yang dapat ditampung tanpa perubahan besar pada arsitektur. Semoga ini bisa membantu.