Desain dokumen sebagai bagian dari Agile

Di tempat kerja saya, kami menghadapi tantangan karena "gesit" terlalu sering berarti "persyaratan yang tidak jelas, kriteria penerimaan yang buruk, semoga sukses!" Kami mencoba mengatasinya, sebagai upaya peningkatan umum.

Jadi, sebagai bagian dari itu, saya mengusulkan agar kami membuat dokumen desain yang, di atas dan di luar tingkat cerita pengguna, secara akurat mencerminkan hasil investigasi awal dari efek fitur yang diberikan dalam sistem dan termasuk jawaban atas pertanyaan yang kami miliki. tanya bisnis itu.

Apakah ada standar yang efektif untuk ini?

Kami saat ini menghadapi situasi di mana fitur baru dapat berdampak pada banyak area dalam sistem "bola besar lumpur" kami , dan perkiraan mulai naik karena hutang teknis ini. Semoga proses desain yang lebih bijaksana dapat membantu.

"Persyaratan yang tidak jelas, kriteria penerimaan yang buruk, semoga berhasil!"

yup, ini adalah persyaratan yang sama dengan yang Anda dapatkan bahkan jika Anda mencoba untuk menyelesaikannya juga! (sebagai contoh, dokumen persyaratan 10.000 yang membutuhkan klien pemerintah 4 tahun untuk dibuat masih penuh dengan ketidakkonsistenan, ketidakjelasan, dan bahkan pernyataan yang bertentangan secara internal. Jika 4 tahun dokumentasi persyaratan tidak dapat membuat Anda mendapatkan persyaratan yang layak, tepat, perlu dilakukan, Anda pernah berpikir Anda akan bisa mendapatkan sesuatu yang tidak kabur?)

Jadi ... cara lincah diciptakan untuk memahami bahwa ini tidak terjadi dan bekerja dengannya daripada mencoba untuk melawannya.

Anda mulai dengan bertanya "apa yang Anda inginkan" dan pelanggan menjawab dengan "sesuatu yang seperti ini". Anda melakukan beberapa pekerjaan dan kemudian kembali ke pelanggan dan berkata "apakah ini seperti yang Anda inginkan?", Dan pelanggan biasanya mengatakan "ya tapi ..." di mana Anda bertanya "apa yang Anda inginkan".

Akhirnya Anda mendapatkan persis apa yang diinginkan pelanggan, bahkan jika mereka tidak tahu apa itu! (Sial, mereka tidak pernah tahu apa yang mereka inginkan, tidak persis).

Di tim kami, sejak mulai gesit, kami juga telah berusaha mempersempit dan memahami betapa banyak dokumentasi yang sebenarnya diperlukan. Saya dapat membagikan kepada Anda apa yang telah kami pelajari sampai sekarang.

Sebelum ada yang lain, pastikan untuk membaca artikel ini tentang Agile / Lean Documentation . Sangat bagus dibaca.

Kedua, saya akan sangat menyarankan Anda untuk mempertimbangkan kembali memproduksi dokumen desain setelah pekerjaan pendahuluan pada cerita. Kami telah mencobanya sebelumnya dan terbukti sia-sia. Di tengah rilis terakhir kami telah memutuskan untuk memperbarui dokumen desain HANYA SETELAH kode untuk cerita disampaikan. Dan sekarang saya berpikir bahwa itu terlalu cepat.

Anda perlu bertanya pada diri sendiri mengapa Anda ingin melakukan dokumen desain sebelum pengkodean. Bagi kami ini adalah alasannya:

1. Kita sebagai tim perlu memahami bagaimana cerita akan memengaruhi desain.
2. Memiliki dokumen desain terbukti bermanfaat ketika anggota baru (atau sementara) bergabung dengan tim atau ketika kembali ke kode yang belum pernah dikerjakan oleh siapa pun selama lebih dari setahun. Jadi mereka berguna untuk memori organisasi untuk membantu memahami cara kerja kode.
3. Dokumen desain berguna untuk teknisi pemeliharaan yang mungkin perlu memecahkan masalah kode setelah rilis.

Untuk memuaskan (1) Anda tidak perlu membuat dokumen desain yang sebenarnya. Tim Anda masih harus memiliki fase desain sebelum pengkodean, tetapi fase itu dapat sesederhana sesi 15 menit di depan papan tulis atau serbet. Anda tidak perlu membuat dokumen aktual yang akan memakan waktu berjam-jam (jika bukan hari) untuk menulis hanya untuk membahas perubahan desain.

(2) atau (3) tidak diperlukan selama pengembangan cerita saat ini dan lebih dari itu mereka tidak akan diperlukan untuk beberapa iterasi berikutnya.

Juga perlu diingat bahwa setiap kali anggota tim menulis / memperbarui dokumen desain, saat itulah kode tidak ditulis. Ketika Anda menulis dokumen sebelum kode aktual, ada hampir 100% kemungkinan bahwa mereka akan perlu diperbarui karena begitu Anda memulai desain pengkodean selalu berakhir diubah. Dan bahkan jika Anda menulis dokumen desain setelah kode, seperti yang dipelajari oleh tim kami, refactoring dari cerita selanjutnya masih mengubah desain.

Jadi apa yang akan saya rekomendasikan:

1. Awalnya, buat desain / model sementara cukup sehingga tim Anda dapat memiliki percakapan yang cerdas sebelum pengkodean. Jangan berharap menyimpan ini dan jangan buang waktu untuk memformalkannya.
2. Hanya buat dokumentasi desain resmi jika seseorang membutuhkannya (mis. Tim Anda memiliki kebutuhan nyata akan memori organisasi)
3. Hanya menghasilkan dokumentasi desain pada kode yang telah distabilkan. Tidak ada gunanya mencoba mendokumentasikan modul yang terus berubah di setiap iterasi.
4. Menghasilkan dokumen desain yang sepenuhnya menggambarkan modul (atau bagian dari produk). Di masa lalu kami biasa menulis dokumen desain yang mendokumentasikan perubahan yang harus dilakukan. Dokumen-dokumen itu benar-benar tidak berharga segera setelah pembebasan dilakukan.
5. Simpan dokumen dengan sangat tinggi. Jika Anda menulis 20 halaman yang mencakup arsitektur dan desain tingkat tinggi, dokumen itu akan a) benar-benar dibaca oleh orang lain dan b) akan membantu orang mengenal tata letak umum kode Anda. Untuk lebih jelasnya, orang bisa langsung masuk ke kode. Jika Anda menulis 700 halaman dengan spesifikasi terperinci, mereka akan hampir selalu tidak cocok dengan kenyataan, itu terlalu banyak bagi siapa pun untuk membaca dan Anda akhirnya harus memelihara dan memperbarui 700 halaman alih-alih 20 setiap kali perubahan di masa depan dibuat.

"Mantra" Agile tidak dapat dilakukan tanpa dokumentasi sepenuhnya.

Mantra Agile adalah untuk memilih " Bekerja perangkat lunak daripada dokumentasi yang komprehensif ". Tetapi perhatikan bit di bagian bawah manifesto.

Artinya, sementara ada nilai di item di sebelah kanan , kami lebih menghargai item di sebelah kiri. "

Paman Bob memiliki kebijakan yang baik untuk dokumentasi

Tidak menghasilkan dokumen kecuali kebutuhannya mendesak dan signifikan .

Anda benar bahwa beberapa orang menggunakan Agile sebagai alasan untuk tidak membuat dokumentasi, tapi itu Agile buruk. Mengabaikan bit yang saya soroti dalam tanda kutip di atas.

Semua yang dikatakan, ketika Anda mengatakan 'saat ini kami menghadapi situasi di mana fitur baru dapat berdampak pada banyak area dalam sistem "bola besar lumpur" kami, jika Anda ingin menjadi gesit, Anda perlu melakukan sesuatu tentang hal ini.

Ketika Anda memiliki dokumentasi, gunakan untuk memodernisasi kode Anda. Dengan cara itu Anda menghapus kebutuhan jangka panjang untuk mempertahankan dokumentasi (yang tidak akan terjadi) dengan menghapus kebutuhan jangka panjang untuk dokumentasi.

yaitu. Buat kebutuhan segera dan signifikan.

Yang lincah adalah bahwa upaya dokumentasi benar-benar harus didorong oleh tim scrum. Jika pengembang tidak merasa dokumentasi eksternal cukup untuk kebutuhan mereka, cerita pengguna akan diblokir sampai mereka melakukannya. Jika bisnis merasa pengembang tidak menghasilkan dokumentasi yang memadai, pemilik produk bersikeras menjadikannya bagian dari kriteria penerimaan. Karena itu, saya benar-benar menemukan dokumentasi kami lebih fokus dan efektif sejak pindah ke scrum.

Kami menggunakan VersionOne untuk melacak cerita pengguna kami, tetapi saya yakin metode kami berlaku untuk sistem lain. Ini memungkinkan Anda melampirkan file ke cerita pengguna. Kami telah menemukan bahwa menjadi tempat yang sangat berguna untuk meletakkan dokumen desain.

Untuk satu contoh yang bekerja sangat baik bagi kami, kami harus menguji desain papan sirkuit baru secepat mungkin setelah prototipe dibangun. Kami membuat dua kisah pengguna untuk semua yang membutuhkan pengujian: satu untuk merancang tes dan satu untuk melaksanakan tes. Salah satu kriteria penerimaan untuk cerita desain adalah bahwa prosedur tes sepenuhnya didokumentasikan dalam cerita eksekusi.

Ketika kami sampai di bagian pengujian, itu berjalan lebih lancar dari yang pernah saya lihat. Kami baru saja membuka kisah pengguna dan mengikuti prosedur langkah demi langkah. Dokumentasinya persis seperti yang kami butuhkan untuk menyelesaikan cerita, tidak lebih dan tidak kurang.

Kami memiliki cerita lain di tumpukan kami hanya untuk meningkatkan dokumentasi untuk chip yang kami gunakan, agar lebih mudah bagi tim lain untuk mengambilnya untuk produk mereka sendiri.

Singkatnya, jika Anda merasa dokumentasi Anda menderita, solusinya semudah membuat cerita pengguna yang terpisah untuknya, dan / atau menjadikannya bagian dari kriteria penerimaan.

Ketika Anda berbicara tentang persyaratan yang buruk, hal pertama yang terlintas dalam pikiran saya adalah memastikan Anda memiliki kriteria pengujian. Jika memungkinkan, buat beberapa kasus uji otomatis yang dapat digunakan kembali untuk bagian sistem yang ada. Setelah semua orang merasa nyaman dengan itu, maka pindahlah untuk menulis kasus uji sebelum kode ditulis. Kasus uji yang baik dapat melakukan banyak hal untuk mendokumentasikan perilaku suatu sistem.

Mengenai dokumen desain spesifik apa yang akan digunakan, seperti yang telah dikatakan orang lain, dokumen ini sangat tergantung pada kebutuhan tim dan apa tugas selanjutnya yang akan mereka lakukan. Jika mungkin, coba gunakan alat yang dapat menghasilkan dokumen (dari kode) yang akan Anda gunakan, atau hasilkan kode dari dokumen. Pemeliharaan dokumentasi bisa menjadi sangat mahal, jadi pilihlah dengan bijak ketika Anda mempertahankan dokumen desain.

Secara pribadi saya telah sukses dengan diagram kelas yang dihasilkan dari kode dan kasus uji kebugaran. Tim mencetak beberapa diagram kelas, melakukan sesi mark-up dengan pemilik produk dan kemudian merumuskan perkiraan dari sana. Sejauh fitnesse berjalan, saya beruntung bekerja dengan beberapa pemilik produk yang sangat pandai mengekspresikan apa yang mereka inginkan dalam spreadsheet, yang kemudian dikonversi ke tabel untuk fitnesse.