Bagaimana Anda mendemonstrasikan perangkat lunak dengan Tidak Ada UI di Tinjauan Sprint?

Kami melakukan pengembangan perangkat lunak tangkas, pada dasarnya mengikuti Scrum. Kami mencoba melakukan ulasan sprint tetapi sulit. Perangkat lunak kami melakukan banyak pemrosesan data dan cerita sering kali tentang mengubah berbagai aturan di sekitar ini.

Apa sajakah pilihan untuk mendemokan perubahan yang terjadi dalam sprint ketika tidak ada perubahan alur kerja UI atau terlihat, tetapi perubahan itu adalah aturan bisnis halus pada pekerjaan pemrosesan yang dapat memakan waktu 10 detik atau bahkan beberapa jam ?

Selama sprint Anda menciptakan nilai. Selalu ada beberapa perbedaan antara apa yang Anda miliki di awal dan akhir sprint. Biasanya bahkan dengan cara yang terlihat oleh klien. Jadi tunjukkan saja perbedaannya.

dalam beberapa kasus sprint berkaitan dengan penemuan atau penataan ulang internal yang mungkin terdengar halus, masih Anda harus dapat menunjukkan perbedaan dan menjelaskan kepada publik mengapa Anda menganggapnya baik dan apa manfaat dari semua upaya yang dilakukan. (? Dalam kasing sudut Anda dapat merujuk ke Edison yang pertama kali menemukan lebih dari seribu cara bagaimana TIDAK mungkin membuat bola lampu yang berfungsi.)

Jika pemrosesan nyata membutuhkan waktu lama, tidak apa-apa untuk menampilkan video dengan zip waktu atau hanya tabel angka. Atau hasil keluaran yang dikumpulkan sebelumnya.

Preferensi pribadi saya sendiri untuk hal-hal yang melakukan pekerjaan back-end adalah untuk menemukan perubahan pengguna akhir. Jika data yang Anda proses akhirnya berakhir di laporan, tunjukkan perbedaan sebelum / sesudah dalam laporan.

Saya berasumsi bahwa keinginan untuk perubahan datang dari kebutuhan. Apa masalah yang memicu perlunya melakukan cerita? 'Formulir suara' cerita pengguna Anda harus menunjukkan kepada Anda bagaimana Anda dapat memperagakan masalah dengan bertindak sebagai pengguna dalam cerita Anda (yaitu Sebagai Joanne, saya perlu melihat laporan tanpa pengguna yang berada di Eropa).

Selain itu, Anda dapat mengunjungi tim pengujian untuk membantu Anda dalam kasus ini. Pasti ada beberapa cara yang tim uji dapat memverifikasi bahwa cerita itu Selesai. bagaimana bisa mereka melakukan hal ini? Apakah Anda dapat menunjukkan proses itu dalam demo?

Bagaimana Anda tahu bahwa fitur berfungsi sendiri? Ketika Anda menyebarkannya bagaimana Anda memastikan itu benar-benar berfungsi?

Jika Anda tidak dapat menjawab pertanyaan-pertanyaan itu maka Anda memiliki masalah yang lebih besar daripada Tinjauan Sprint. Anda harus dapat menunjukkannya di demo Anda.

Di Scrum, selama demo, Pemilik Produk meninjau setiap kisah yang sedang dikembangkan dan menerimanya atau mengembalikannya ke pengembangan. Anda harus dapat membuktikan bahwa suatu fitur berfungsi; ini biasanya paling baik dilakukan dengan tes otomatis. Bisakah Anda memilih tes otomatis yang sesuai dengan tes penerimaan dan menyoroti perubahan utama?

Pemilik Produk Anda juga harus dapat membantu; mereka harus memiliki pemahaman rinci tentang produk yang sedang dikembangkan. Mereka tidak perlu memahami detail implementasi penuh tetapi mereka harus memahaminya dengan cukup baik untuk dapat menjelaskan tujuan (atau nilai bisnis) dari setiap fitur. Bagaimanapun, Pemilik Produk adalah orang yang meminta Anda untuk mengimplementasikan cerita di tempat pertama!

Satu opsi yang saya temukan berpotensi memuaskan untuk bisnis (BSA, BA, manajer, dan sejenisnya) adalah memberikan presentasi slide lima hingga sepuluh tentang apa yang diharapkan, dan apa yang dicapai. Dan kemudian jika ada metode yang berarti untuk menampilkan hasil pekerjaan yang dilakukan, seperti dump data, atau hasil query SQL, dan waktu untuk menjelaskannya, maka saya menemukan para pemangku kepentingan sering puas.

Seringkali sulit untuk memberikan demo yang bermakna untuk non-programer / staf non-teknis pada sistem tipe back-end. Saya telah mencoba hal di atas beberapa kali, dan merasa bahwa para pemangku kepentingan lebih puas dengan tanggapan mereka, daripada ketika saya hanya menjalankan perangkat lunak dan menunjukkan hasilnya kepada mereka.

Meskipun demikian, ini mungkin lebih berhasil daripada nilainya bagi Anda. Anda harus mempertimbangkan manfaatnya dan pekerjaan yang diperlukan untuk mewujudkannya.

Anda dapat menggunakan powerpoint atau sesuatu yang grafis untuk menyampaikan perubahan. Misalnya, jika ada aturan bisnis yang ditambahkan yang bergantung pada nilai dalam sel pada spreadsheet, Anda bisa menunjukkan sel mana dan menjelaskan bagaimana itu diubah.

Jika ada banyak perubahan backend, tidak ada perubahan UI, maka Anda bisa langsung menjelaskan daftar itu dan menunjukkan perubahan keseluruhan. Jika Anda dapat membuat bagan atau grafik yang menyoroti perbedaan, itu mungkin cukup. Flash beberapa perubahan kode atau daftar perubahan / komit yang dikerjakan dalam sprint.

Jika perubahan Anda adalah "back end" kemungkinan ada beberapa Antarmuka Pengguna akhir di mana perubahan itu memanifestasikan dirinya. Anda bisa menunjukkannya. Tim saya tidak suka melakukan itu karena mereka tidak "memiliki" sistem itu, tetapi pada akhirnya, jika itu cara pelanggan Anda berinteraksi dengan perubahan Anda, Anda perlu mengetahui UI itu dan mengetahuinya dengan baik. cukup untuk menunjukkan produk jadi.