Mungkin, setelah membaca artikel ini, Anda akan mendapati diri Anda berpikir bahwa saya menulis tentang hal-hal biasa yang diketahui semua orang. Tetapi dalam 10 tahun saya hanya mengubah 3 perusahaan IT, di mana dua di antaranya praktik "dangkal" ini tidak digunakan secara penuh, proses pengembangan perangkat lunak sangat menderita karenanya. Selain pengalaman pribadi saya, saya terinspirasi untuk menulis artikel dari cerita para analis yang saya kenal yang bekerja di bidang IT dan hampir semua orang dihadapkan pada masalah organisasi dan komunikasi yang perlu dan dapat diselesaikan.
Selama 3 tahun terakhir saya telah bekerja sebagai analis sistem di grup perusahaan InfoWatch dan dalam artikel ini saya ingin berbagi dengan Anda praktik bekerja dengan persyaratan yang kami gunakan. Perusahaan mengembangkan produk Perusahaan untuk mengurangi risiko keamanan informasi, melindungi dan menganalisis data perusahaan. Untuk produk semacam itu, persyaratan tinggi diajukan terkait keandalan, kinerja, toleransi kesalahan, serta persyaratan sertifikasi. Karena kekhasan pasar keamanan informasi, solusi kami tidak berbasis cloud, tetapi diinstal di tempat di klien. Oleh karena itu, kami bekerja dalam mode rilis besar beberapa kali dalam setahun. Untuk mencapai tujuan yang ditetapkan dan mempersingkat waktu rilis, kami bekerja sesuai dengan prinsip yang ditetapkan dalam metodologi Agile.Untuk memulai pengembangan, kami tidak menyiapkan persyaratan sistem yang benar-benar mendetail, tetapi mulai dengan deskripsi tingkat tinggi tentang aspek terpenting dari fungsi baru tersebut. Artinya, kami membuat keputusan yang paling mempengaruhi volume dan kompleksitas perbaikan dan memberi tim pengembangan informasi yang diperlukan untuk mulai mengerjakan desain arsitektur dan menulis kode (untuk fitur kecil). Kemudian, dalam proses pengembangan, kami secara bertahap merinci persyaratan dan membawanya ke tingkat detail yang cukup untuk menulis kasus uji yang terperinci. Pendekatan ini memungkinkan Anda untuk tidak menghabiskan banyak waktu untuk mulai bekerja dan mengurangi risiko bahwa persyaratan harus dikerjakan ulang secara signifikan jika ada batasan teknis baru yang terungkap.yang paling mempengaruhi volume dan kompleksitas perbaikan dan memberikan tim pengembangan informasi yang diperlukan untuk mulai mengerjakan desain arsitektur dan pengkodean (untuk fitur-fitur kecil). Kemudian, dalam proses pengembangan, kami secara bertahap merinci persyaratan dan membawanya ke tingkat detail yang cukup untuk menulis kasus uji yang terperinci. Pendekatan ini memungkinkan Anda untuk tidak menghabiskan banyak waktu untuk mulai bekerja dan mengurangi risiko bahwa persyaratan harus dikerjakan ulang secara signifikan jika ada batasan teknis baru yang terungkap.yang paling mempengaruhi volume dan kompleksitas perbaikan dan memberikan tim pengembangan informasi yang diperlukan untuk mulai mengerjakan desain arsitektur dan pengkodean (untuk fitur-fitur kecil). Kemudian, dalam proses pengembangan, kami secara bertahap merinci persyaratan dan membawanya ke tingkat detail yang cukup untuk menulis kasus uji yang terperinci. Pendekatan ini memungkinkan Anda untuk tidak menghabiskan banyak waktu untuk mulai bekerja dan mengurangi risiko bahwa persyaratan harus dikerjakan ulang secara signifikan jika ada batasan teknis baru yang terungkap.cukup untuk menulis kasus uji yang terperinci. Pendekatan ini memungkinkan Anda untuk tidak menghabiskan banyak waktu untuk mulai bekerja dan mengurangi risiko bahwa persyaratan harus dikerjakan ulang secara signifikan jika ada batasan teknis baru yang terungkap.cukup untuk menulis kasus uji yang terperinci. Pendekatan ini memungkinkan Anda untuk tidak menghabiskan banyak waktu untuk mulai bekerja dan mengurangi risiko bahwa persyaratan harus dikerjakan ulang secara signifikan jika ada batasan teknis baru yang terungkap.
Jika proses pengembangan Anda mirip dengan kami, atau Anda ingin beralih ke proses gabungan ini, kemungkinan besar praktik yang dijelaskan di bawah ini cocok untuk Anda. Tetapi bahkan jika Anda memiliki proses yang berbeda, kemungkinan besar praktik yang disajikan akan bermanfaat bagi Anda. Bagaimanapun, saya sarankan Anda membiasakan diri dengan mereka, terutama jika Anda bekerja sebagai analis sistem di perusahaan IT.
Persyaratan untuk produk yang sedang dikembangkan adalah area tanggung jawab utama seorang analis sistem. Praktik yang dijelaskan di bawah ini bertujuan untuk menyederhanakan manajemen persyaratan dan, sebagai hasilnya, menyederhanakan proses pengembangan produk:
- dokumentasi dan pembuatan versi;
- pemberitahuan perubahan;
- ulasan;
- rapat umum / rapat / status;
- diskusi / solusi pertanyaan terbuka;
- logging diskusi;
- validasi fungsionalitas baru;
- presentasi fungsionalitas baru.
Mendokumentasikan dan persyaratan versi
Akan lebih mudah bila deskripsi produk dalam bentuk persyaratan fungsional dan non-fungsional ditetapkan dalam satu dokumen, persyaratan dipecah oleh area fungsional, saling berhubungan dengan pengelompokan, transisi melalui tautan, dll. Ketika ada perubahan dalam kerangka deskripsi fitur atau sebagai akibat dari kerusakan perbaikan yang tercermin dalam versi yang sesuai dari persyaratan.
Persyaratan versi sama seperti untuk produk itu sendiri, yang memungkinkan Anda melihat peningkatan fungsionalitas dengan setiap rilis baru. Dan juga dapatkan akses cepat ke informasi tentang bagaimana fungsi ini bekerja di versi sebelumnya dan untuk alasan apa itu diubah.
Di beberapa perusahaan, perlu menghabiskan banyak waktu untuk mendapatkan informasi tersebut, karena semua tugas yang terkait dengan fungsionalitas tertentu perlu ditinjau, mempelajari deskripsinya, dan melihat komentar. Ngomong-ngomong, cara yang lebih cepat untuk mendapatkan informasi yang Anda butuhkan adalah meminta pengembang untuk melihat perubahan dalam kode, tetapi dalam hal ini tidak hanya akan memakan waktu Anda, tetapi juga waktu pengembang, yang akan membebani perusahaan Anda lebih. Menjelaskan persyaratan di satu tempat memungkinkan Anda tidak hanya untuk menemukan informasi yang menarik, tetapi juga untuk segera memahami konteksnya.
Kami menggunakan Confluence, yang merupakan alat praktis yang dapat Anda sesuaikan sedikit untuk diri Anda sendiri. Seorang kolega saya berbicara tentang pengalaman kami dengan Confluence secara mendetail di artikelnya " Bagaimana Kami Menggunakan Confluence untuk Mengembangkan Persyaratan Produk . " Menariknya, banyak perusahaan IT memiliki alat ini, tetapi tidak semua orang menggunakannya untuk mendokumentasikan persyaratan produk.
Pemberitahuan perubahan persyaratan
Merupakan praktik yang baik untuk memberi tahu semua pemangku kepentingan tentang perubahan persyaratan, yang juga memungkinkan Anda memantau kapan dan untuk alasan apa persyaratan diubah. Jika di atas saya katakan bahwa penting untuk merefleksikan dalam persyaratan semua perubahan sebagai akibat dari memperbaiki cacat, maka di sini kita berbicara tentang memberi tahu tim tentang perubahan ini.
Penting untuk dipahami bahwa persyaratan adalah data yang digunakan tim pengembangan, tim penguji, penulis teknis untuk pekerjaan mereka, dan bahwa setiap perubahan persyaratan harus didukung dalam implementasi, kasus uji, dan dokumentasi.
Kegagalan untuk memberi tahu tim yang terlibat kemungkinan akan menghadapi masalah berikut:
- penerapannya mungkin tidak memenuhi persyaratan;
- ;
- .
Hingga saat ini, tim analis kami memberi tahu semua orang yang tertarik tentang perubahan persyaratan dengan cara berikut: setelah melakukan perubahan pada persyaratan, mereka meninggalkan komentar tentang masalah tersebut, mengirim surat yang berisi tautan ke masalah, tautan ke persyaratan dan penjelasan singkat tentang perubahan tersebut. Pada akhir tahun lalu, kami mengotomatiskan proses ini: kami menyelesaikan pelacak masalah (kami menggunakan JIRA) dan sekarang, setelah melakukan perubahan pada persyaratan, dalam tugas di mana perubahan ini dibuat, kami mengklik tautan "Beri tahu tentang perubahan ", pilih tim yang tertarik dan buat singkat Deskripsi perubahan:
Screenshot # 1
Surat yang secara otomatis dibuat setelah mengklik tombol" Kirim Peringatan "memiliki presentasi berikut dan berisi semua informasi yang diperlukan:
Screenshot 2
Selain surat tersebut, komentar dengan informasi serupa tetap menjadi masalah.
Tinjau persyaratan baru
Persyaratan baru wajib ditinjau oleh pimpinan dari semua tim yang terlibat dalam pengembangan fitur. Kami tidak berbicara tentang perubahan dalam cacat, tetapi tentang fungsionalitas yang benar-benar baru, deskripsi yang Anda buat. Mendapatkan umpan balik sangat berguna, karena pertanyaan yang tepat mungkin muncul yang akan membantu mengungkapkan secara rinci kemungkinan fungsi baru tersebut. Ketika Anda mengembangkan pemikiran ke satu arah untuk waktu yang lama, mengidentifikasi kebutuhan, masalah, mengembangkan konsep yang berbeda, dan menjelaskan solusi dalam kerangka produk, mata mungkin menjadi kabur, dan mungkin tampak ada hal-hal yang jelas terlihat. tidak harus diperbaiki persyaratannya. Tinjauan tersebut membantu, termasuk melalui pertanyaan dari spesialis yang membenamkan diri dalam topik melalui informasi yang mereka terima dalam persyaratan, untuk memahami poin apa yang perlu diklarifikasi atau diungkapkan.Review juga membantu untuk mengasah kejelasan kata-kata, untuk membuat perubahan sehingga dapat diinterpretasikan secara jelas oleh semua orang.
Untuk melakukan ini, kami juga meningkatkan pelacak masalah, menambahkan jenis tugas "Review" yang terpisah, yang diluncurkan oleh analis yang bertanggung jawab untuk setiap fitur di semua pemimpin tim. Manajer secara mandiri atau mendelegasikan kepada bawahannya membuat pemeriksaan persyaratan, mengajukan pertanyaan atau membuat klarifikasi melalui komentar dan menyetujui perubahan yang dibuat.
Tangkapan layar # 3
Demonstrasi / pertemuan / status
Rapat harian tim yang mengerjakan fitur adalah acara yang bagus untuk tim kecil, selama mereka sering menggunakan sprint. Jika tidak, rapat harian akan menyita waktu seluruh tim dan tidak akan berguna. Namun, Anda tidak boleh sepenuhnya meninggalkan rapat, Anda hanya perlu menentukan dengan benar frekuensi penyelenggaraannya. Dan kemudian Anda dapat terus memantau, memahami apakah tim bergerak ke arah yang benar dalam menerapkan konsep yang ada, serta mengidentifikasi pada tahap awal masalah yang dapat dipecahkan atau batasan yang perlu disepakati.
Biasanya, saat mengembangkan persyaratan, Anda perlu berkomunikasi dengan tim, karena Anda dapat mempelajari banyak informasi berguna. Momen penting yang terjadi di suatu tempat di "kotak hitam" dapat sangat memengaruhi konsep fitur produk baru, komunikasi dengan rekan kerja membantu menarik perhatian ke momen yang menarik untuk peran mereka. Misalnya, komunikasi dengan penguji memungkinkan untuk memperhitungkan skenario alternatif yang direncanakan untuk diuji dalam persyaratan, dan penting bahwa skenario tersebut pada awalnya ditetapkan dan diperhitungkan dalam pengembangan, dan tidak ditemukan selama tahap pengujian. .
Diskusi / solusi pertanyaan terbuka
Saya ingin menyoroti komunikasi melalui suara sebagai item terpisah, karena saya menganggap penting untuk melakukan komunikasi langsung, karena dalam realitas baru tidak ada cara untuk membahas masalah secara tatap muka.
Messenger lebih sering digunakan, sangat cocok untuk korespondensi pribadi, di mana Anda dapat menggunakan senyuman, gif, dll. Untuk mengekspresikan emosi Anda. Tetapi untuk aktivitas kerja, hal ini tidak sepenuhnya dapat diterima, dan akibatnya, teks tanpa wajah yang kering tetap ada. Hal ini sulit untuk ditafsirkan oleh penerima, karena persepsi teks ini bergantung pada suasana hati orang tersebut, sikap pribadinya terhadap Anda, keterlibatan dalam dialog, dan faktor-faktor lain yang tidak bergantung pada Anda.
Oleh karena itu, saya lebih suka menyelesaikan masalah dalam diskusi "dengan suara", yaitu menelepon dan berdiskusi, untuk menyepakati sesuatu. Panggilan telepon akan membantu Anda mengetahui apakah Anda memahami konteks dengan benar, segera mengajukan pertanyaan dan mendapatkan jawaban. Suara menyampaikan intonasi, memungkinkan Anda menempatkan aksen yang tepat, memperhatikan apa yang benar-benar penting. Selain itu, komunikasi suara menghemat waktu untuk semua peserta dan memungkinkan Anda berkonsentrasi pada topik tertentu, karena komunikasi suara (dan bukan obrolan) memerlukan partisipasi dan pemahaman untuk menyelesaikan masalah.
Log diskusi
Merupakan kebiasaan dan wajib bagi setiap orang untuk mencatat diskusi keputusan dengan pelanggan dalam bentuk TOR, yang berulang kali dikurangi "langsung ke pokok permasalahan" dan disepakati oleh semua pihak yang berkepentingan. Saya ingin menarik perhatian Anda pada fakta bahwa selain dokumentasi resmi dalam pengembangan perangkat lunak, fiksasi perjanjian tertulis dapat bermanfaat tidak hanya dalam kerangka komunikasi "pengembang-pelanggan", tetapi juga dalam perusahaan / tim.
Kami mempraktikkan komunikasi tim pencatatan saat mendiskusikan konsep solusi dan fungsionalitas sistem. Karena ketika mengerjakan suatu fitur, beberapa solusi mungkin muncul, dari mana perlu memilih satu, tentu saja, pertanyaan muncul untuk tim, yang, sebenarnya, dibahas dalam rapat.
Sebagai aturan, kami menyimpan protokol dalam format tanya jawab. Protokol juga membenarkan mengapa solusi semacam itu dipilih, dicatat siapa yang membuat keputusan ini dan siapa yang mengoordinasikannya. Tetapi penting untuk dipahami bahwa ini adalah dokumen internal kami yang digunakan dalam pekerjaan kami, yang tidak diatur oleh apa pun atau siapa pun. Risalah merekam diskusi tentang topik tertentu dan pada tanggal tertentu, yaitu, diperlukan untuk memahami mengapa keputusan tertentu dibuat atau ditolak, pertanyaan mana yang secara umum muncul dan mana di antara mereka yang ditutup, dan mana yang memerlukan penelitian untuk dapatkan jawaban .... Ini penting karena dalam mode multitasking, sulit untuk menyimpan semua informasi ini di kepala Anda, ditambah lagi, semua anggota tim yang tertarik harus mengetahui dan memiliki akses ke informasi ini. Juga, setelah sekian lama,Anda dapat membaca ulang protokol ini dan menemukan jawaban atas pertanyaan di dalamnya, atau mungkin Anda akan memiliki pemikiran baru berdasarkan jawaban tersebut. Atau Anda akan sekali lagi memastikan kebenaran dari solusi yang dipilih.
Validasi berarti memeriksa fungsionalitas yang diterapkan untuk memenuhi persyaratan bisnis. Sebelum memulai pengujian fungsional, analis yang bertanggung jawab atas fitur tersebut melakukan validasi: ia memeriksa apakah skenario utama telah diterapkan dan apakah perilaku sistem memenuhi harapan. Ini adalah praktik penting yang harus digunakan sebelum transfer fungsionalitas untuk pengujian, karena jika skrip utama tidak dijalankan, maka tidak ada gunanya memeriksa kasus lain. Untuk melakukan validasi, skenario penerimaan ditulis, berisi langkah-langkah yang harus dilakukan dan respons yang diharapkan dari sistem untuk pada akhirnya memecahkan masalah bisnis yang fungsinya dikembangkan. Dalam kerangka validasi, dimungkinkan untuk mengidentifikasi, pertama-tama, kegagalan skenario utama, ketidaknyamanan antarmuka pengguna, serta cacat fungsional yang parah.Jika skenario utama dijalankan, maka fitur tersebut dianggap divalidasi dan dapat diajukan untuk pengujian. Pengujian sudah lebih rinci, sesuai dengan kasus pengujian, ia memeriksa fungsionalitas yang diimplementasikan.
Presentasi fungsionalitas baru
Praktik keren lainnya, menurut saya, adalah presentasi fungsionalitas sebelum menulis kasus uji atau mengeluarkan fitur untuk pengujian. Presentasi dilakukan untuk para pemain yang tidak tenggelam dalam konteks seperti pemimpin mereka, karena mereka tidak berpartisipasi dalam tahapan mencari solusi. Sebagai aturan, ini adalah cerita pendek tentang skenario dasar dan alternatif apa yang diterapkan untuk memecahkan masalah, pengaturan apa dalam produk yang perlu dibuat, fitur teknologi apa yang dimiliki solusi ini dan batasan apa. Akibatnya, pemahaman umum tentang fungsi-fungsi baru produk terbentuk dan sejumlah pertanyaan yang mungkin timbul bagi seseorang yang tidak tenggelam dalam konteks akan dihapus.
Setelah menguji fungsionalitas, sebelum rilis resmi rilis teknis, kami melakukan presentasi dan demonstrasi fungsionalitas baru untuk karyawan departemen yang mengimplementasikan produk di pelanggan. Hal ini memungkinkan untuk mendapatkan umpan balik, fitur dan batasan awal yang ditunjuk, mengumumkan pengembangan lebih lanjut dari fungsionalitas tersebut. Penting agar setiap orang memiliki pemahaman yang sama tentang fungsi baru dan tidak memiliki harapan yang salah.
Di atas, saya menjelaskan daftar kecil praktik yang saya dan kolega saya gunakan dalam pekerjaan kami. Saya merasa mereka berguna, jadi saya membagikannya dan ingin merekomendasikan Anda untuk membangun proses untuk bekerja dengan persyaratan menggunakan praktik ini. Pada artikel berikutnya, kami berencana untuk berbicara tentang bagian substantif dari bekerja dengan persyaratan - secara lebih rinci tentang praktik apa yang kami gunakan untuk mengidentifikasi kebutuhan / masalah pelanggan dan merumuskan solusi yang akan sepenuhnya mencakup mereka.
Jika Anda memiliki pertanyaan atau ingin berbagi pengalaman, silakan tinggalkan komentar Anda.
Penulis: Venera Abbyasova AbbyasovaVenera
* Semua gambar untuk artikel diambil dari akses terbuka di Internet.