🤾 🥂 ⛹️ JIRA: aturan untuk persiapan tepat waktu perangkat lunak lezat. TLDR 2: manajemen persyaratan 📑 🌻 ⛄️

Sebelumnya dalam artikel “ JIRA: aturan persiapan tepat waktu untuk perangkat lunak yang lezat. TLDR 1: batas-batas kemungkinan ”suatu upaya dilakukan untuk menyatukan persyaratan umum untuk penggunaan JIRA dalam hal pengelolaan beberapa proyek untuk pengembangan perangkat lunak khusus di salah satu departemen perusahaan kami . Mengembangkan topik, artikel ini akan dikhususkan untuk fitur utama pendaftaran, klarifikasi dan pemantauan implementasi persyaratan pelanggan dalam kerangka model yang diusulkan sebelumnya . Setiap kritik diterima.

Sumber

Setiap produk jadi ditentukan terutama oleh kualitas bahan asli, dan perangkat lunak tidak terkecuali ( Garbage In - Garbage Out ). Jika bahan-bahan asli sedikit busuk atau beberapa di antaranya hilang begitu saja, Anda tidak mungkin bisa menyelamatkan situasi dengan bantuan oven super atau wajan yang luar biasa. Dalam hal perangkat lunak, komponen awal adalah niat baik (mimpi) pelanggan tentang masa depan yang cerah (ketika " robot bekerja keras, seseorang bahagia ").

Salah satu paradoks dari kontrak pemerintah modern adalah bahwa kontraktor sering memiliki pengaruh yang lemah pada proses pembentukan persyaratan, yaitu proses analisis persyaratan nyatapada proyek dimulai setelah persetujuan dari daftar persyaratan ini. Fakta bahwa rekomendasi tim proyek mengenai kata-kata dari persyaratan tidak mempengaruhi teks kontrak dengan cara apa pun, manajer proyek biasanya belajar dari perwakilan bersemangat dari departemen kontrak, yang, dengan rasa utang lengkap, melaporkan bahwa tender yang ditunggu-tunggu akhirnya telah dimenangkan dan kesepakatan Tetap kecil. Pada saat yang sama, di satu sisi, pelanggan dengan segala cara menghambat perubahan persyaratan dalam dokumen yang disetujui (mimpi adalah sakral), dan di sisi lain, ia dapat dengan mudah menafsirkan persyaratan yang sama secara berbeda tergantung pada situasinya.

Dalam kondisi ini, diinginkan untuk memastikan bahwa semua persyaratan pelanggan disimpan di "dapur digital" Anda sedemikian rupa sehingga, pada tahap pengiriman proyek, menghindari kekecewaan parah dari semua pemangku kepentingan proyek.

Untuk mengatasi masalah ini, dalam kerangka pendekatan yang diusulkan sebelumnya , jenis tugas khusus dirancang - "persyaratan". Daftar persyaratan tugas ini dibentuk oleh apa yang disebut jaminan proyek. Dalam versi JIRA yang lebih baru, analog dari jenis tugas ini adalah jenis tugas "epik". Namun, seperti yang akan kita lihat nanti, jenis tugas "persyaratan" dalam proyek kami tidak hanya memperbaiki bentuk-bentuk pemikiran konseptual pelanggan, tetapi tugas-tugas yang mencirikan hasil kegiatan manajer proyek dan analis pada manajemen persyaratan .

Aturan untuk persyaratan pemotongan

Jika pelanggan menerima daftar persyaratan untuk penyempurnaan perangkat lunak (misalnya, kerangka acuan yang disetujui), semua aktivitas untuk pendaftaran dan pemeliharaan daftar persyaratan di JIRA dapat dikurangi menjadi dua skenario perbatasan.

Dalam kasus pertama, manajer proyek hanya meneruskan surat dengan persyaratan pelanggan kepada analis dengan catatan "Daftarkan persyaratan mengenai garis singgung dengan JIRA dan pastikan implementasinya". Setelah itu, manajer proyek dapat "memalu" pada proyek sampai dimulainya tes pendahuluan (satu-satunya hal adalah untuk memastikan bahwa semua persyaratan menemukan pelaksana yang bertanggung jawab mereka di JIRA). Jika tim proyek Anda terdiri dari analis yang waras, programmer yang cerdik, penguji workaholic dan penulis graphomaniac teknis, hasil dari pendekatan ini tidak akan berbeda dari yang kedua, pilihan yang lebih merepotkan.

Dalam kasus kedua, pekerjaan manajemen persyaratan dibagi menjadi beberapa tahap.

Sumber

Mulai. Pendaftaran dokumen sumber untuk pengembangan / modifikasi perangkat lunak di JIRA. Materi yang diterima diunggah ke repositori dengan jumlah tugas yang sesuai ditunjukkan dalam komentar komit.

1. Berdasarkan dokumen sumber terdaftar, pertemuan direncanakan, yang tujuannya adalah untuk menentukan batas-batas tanggung jawab untuk memenuhi persyaratan, mengidentifikasi persyaratan "bintik putih" dan "esoteris". Perencanaan pertemuan dilaksanakan langsung di JIRA (untuk ini, tugas dari jenis "implementasi" terdaftar, orang yang bertanggung jawab atas tugas tersebut adalah manajer proyek, peserta terdaftar sebagai pengamat, item agenda dicatat dalam deskripsi). Waktu yang dihabiskan untuk analisis awal persyaratan secara independen ditentukan oleh analis dalam bentuk subtugas untuk pertemuan yang direncanakan. Jika pertanyaan muncul selama analisis, mereka tercermin dalam komentar pada agenda rapat.

Selama pertemuan, keputusan dibuat tentang penunjukan mereka yang bertanggung jawab atas "titik putih". Risiko sehubungan dengan persyaratan "esoterik" dievaluasi dan cara untuk mengatasinya diusulkan. Versi pertama “peta jalan” sedang disusun, yang menurutnya pekerjaan akan diorganisasikan (dengan mempertimbangkan prioritas dan pekerjaan saat ini dari tim proyek).

2. Setelah analis ditunjuk untuk bertanggung jawab atas implementasi persyaratan, ia mendaftarkan setiap persyaratan dengan JIRA sebagai tugas terpisah terkait dengan dokumen sumber (tautan “pelengkap”). Status awal klaim adalah "peringkat" .

Salah satu aturan dasar - setiap kebutuhan pelanggan harus didaftarkan sebagai tugas yang terpisahdi JIRA. Pendekatan ini, pada gilirannya, memungkinkan untuk menilai status proyek dari sudut pandang penerapan setiap persyaratan pelanggan, dan bukan dari sudut pandang jumlah tugas yang dilakukan atau investasi tenaga kerja. Kata-kata dari persyaratan dicatat dalam kolom "Deskripsi" kata demi kata seperti dalam dokumen pelanggan.

Juga, registrasi persyaratan "atomik" selanjutnya memungkinkan untuk secara otomatis menghasilkan dokumentasi pelaporan ketika rilis atau pembaruan dikeluarkan (protokol komposisi fungsional dan pengujian).

3. Mengingat roadmap yang dikembangkan untuk masing-masing persyaratan pada tahap awal pelaksanaannya, masalah-masalah berikut harus diselesaikan oleh analis yang bertanggung jawab:

klarifikasi konten semantik dari persyaratan;
klarifikasi batas-batas implementasi.

Pada saat klarifikasi, persyaratan dapat ditransfer ke status "tertunda" , menunjukkan alasan yang sesuai.
Semua bahan untuk klarifikasi (interpretasi) persyaratan dilampirkan pada tugas yang sesuai (diunggah ke repositori dokumentasi). Bahan yang dihasilkan harus berasal dari pelanggan dan harus memungkinkan jawaban yang jelas untuk pertanyaan di atas. Dianjurkan agar ini menjadi protokol pertemuan untuk mengklarifikasi persyaratan, setidaknya email dari korespondensi.
Setelah menghilangkan "bintik putih", persyaratan dapat ditransfer ke status "ditugaskan" .

4. Dalam kerangka implementasi satu area fungsional (satu use case utama - use case) analis yang bertanggung jawab harus merumuskan tugas dari jenis "analisis" yang terkait dengan persyaratan yang relevan.

5. Jika perlu, analis yang bertanggung jawab melakukan survei informasi tentang objek otomasi.

6. Setelah mengumpulkan data awal yang diperlukan untuk desain, analis yang bertanggung jawab membentuk keputusan desain.

7. Berdasarkan hasil keputusan desain, analis harus membentuk / memperjelas daftar komponen yang dapat dikembangkan / dimodifikasi.

8. Solusi desain yang dikembangkan adalah kondisi yang diperlukan dan cukup untuk membuat tugas-tugas untuk pengembangan, pengujian dan dokumentasi dan memperkirakan kompleksitas implementasi mereka.

Di sinilah sering batu sandungan utama antara manajer dan pengembang berada. Satu dariPendekatan yang digunakan untuk mengurangi ketidakpastian dalam menyelesaikan masalah ini adalah dengan mengevaluasi tugas yang diusulkan oleh pengembang yang bertanggung jawab, asalkan total kompleksitas tugas individu tidak boleh melebihi 16 jam. Alexei Kataev dalam laporannya secara meyakinkan menunjukkan bahwa jika biaya tenaga kerja untuk pelaksanaan tugas melebihi 12 jam, keandalan ramalan kompleksitas tugas tersebut menjadi sama dengan keandalan ramalan kemenangan judi. Oleh karena itu, untuk memastikan kualitas perencanaan yang diperlukan, disarankan untuk menguraikan tugas.

Di sisi lain, dari sudut pandang manajemen, saya ingin mencapai hasil yang signifikan dari sudut pandang pelanggan selama pelaksanaan tugas pengembangan, yang tidak selalu dapat dicapai dalam 16 jam kerja.

Dalam kasus kami, diputuskan bahwa jika kompleksitas tugas melebihi 8 jam, penulis tugas harus memecahnya menjadi tahapan yang terpisah (yang tidak selalu berarti subtugas). Selain itu, daftar formal hasil tertentu untuk masing-masing tahap ditentukan. Selain itu, kalkulator online dibuat untuk meningkatkan objektifitas perkiraan berdasarkan daftar ini menggunakan metode PERT .penentuan kerumitan total untuk tugas-tugas dari jenis yang berbeda (deskripsi yang lebih rinci tentang bekerja dengan alat-alat ini seharusnya diberikan selama publikasi artikel berikut) Tetapi pada saat yang sama, sebuah batasan ditetapkan bahwa kompleksitas maksimum yang diproyeksikan dari satu tugas JIRA tidak boleh melebihi 32 jam. Jika kontraktor tidak setuju dengan kompleksitas tugasnya yang diproyeksikan, sebagai argumen, ia harus menyerahkan perhitungan kompleksitasnya, dilakukan dengan menggunakan alat yang sama. Arbiter dalam menyelesaikan perselisihan antara analis yang bertanggung jawab untuk pelaksanaan persyaratan dan pelaksana adalah manajer proyek (pemimpin tim).

9. Segera setelah pendaftaran persyaratan yang terkait dengan persyaratan untuk pengembangan, pengujian dan dokumentasi, manajer proyek harus menentukan prioritas dan waktu pelaksanaan persyaratan ini (dengan mempertimbangkan total biaya tenaga kerja dari tugas terkait, prioritas dan waktu yang diperlukan untuk pelaksanaan tugas-tugas lain dari proyek). Dengan adanya klarifikasi ini, pada gilirannya, analis yang bertanggung jawab dapat menyesuaikan waktu tugas untuk pengembangan, pengujian dan dokumentasi.

10. Implementasi solusi desain dilakukan dalam kerangka tugas jenis "pengembangan".
Setelah tugas pertama yang terkait dengan persyaratan untuk pengembangan perangkat lunak berfungsi, persyaratan tersebut harus ditransfer ke status "sedang bekerja" (ini dapat dilakukan dengan menggunakan plugin Automation for Jira ).

11. Berdasarkan tenggat waktu implementasi yang ditentukan, keputusan dibuat untuk memasukkan implementasi persyaratan dalam satu atau beberapa rilis perangkat lunak lain. Pelanggan harus diberitahu tentang setiap perubahan dalam komposisi atau waktu pengiriman rilis.

12. Sejalan dengan proses pengembangan, versi dokumentasi pengguna dibentuk berdasarkan keputusan desain.

13. Setelah menyelesaikan tugas pengembangan, programmer harus mengklarifikasi daftar komponen yang telah dikembangkan / dimodifikasi.

14. Klarifikasi ulang dokumentasi pengguna harus dilakukan sebagai bagian dari pengujian offline. Pemenuhan semua persyaratan yang terkait dengan persyaratan untuk pengembangan, dokumentasi, dan pengujian merupakan sinyal untuk menerjemahkan persyaratan ini ke dalam status "selesai" dan dimasukkan dalam rilis.

15. Revisi tersebut termasuk dalam rilis perangkat lunak sesuai dengan keputusan pengiriman yang dibuat oleh manajer proyek.

16. Sebelum pengujian dilakukan, pengujian integrasi berulang dari persyaratan yang diterapkan termasuk dalam rilis dilakukan.

17. Konfirmasi kebenaran dari persyaratan yang diterapkan dapat dilakukan selama pengujian perangkat lunak (pendahuluan, operasi percobaan, penerimaan). Hasil tes dicatat dalam JIRA sebagai bagian dari tugas tipe "implementasi".
Setelah dokumen diterima dari pelanggan tentang implementasi persyaratan yang benar, dokumen tersebut dapat ditransfer ke status "tertutup" . Dalam hal komentar diterima dari pelanggan mengenai persyaratan, maka akan dikembalikan ke status "yang ditentukan"(pada tahap nomor 8). Pada saat yang sama, komentar itu sendiri dapat diperbaiki di JIRA sebagai persyaratan terpisah terkait dengan persyaratan utama menggunakan jenis komunikasi "Relates" .

Biarkan saya mengingatkan Anda bahwa skema yang diuraikan tidak mencerminkan alur kerja dari tugas yang terpisah di JIRA, tetapi melibatkan penciptaan serangkaian tugas yang saling terkait dari berbagai jenis (yang tercermin dalam skema dengan warna yang sesuai). Urutan yang diberikan memberikan gambaran umum tentang prosedur standar untuk menerapkan persyaratan pelanggan baru. Pada saat yang sama, skema ini tidak mengecualikan kemungkinan penyimpangan darinya, misalnya, dalam kasus prototyping awal sebelum keputusan desain. Namun, dalam proyek kami, pengecualian seperti itu harus disetujui oleh manajer proyek.

Selama pengujian atau operasi komersial, komentar pelanggan pada perangkat lunak yang dibuat pasti akan terungkap. Kata-kata ini dapat dibagi secara kondisional ke dalam kelompok-kelompok berikut:

persyaratan baru;
klarifikasi tentang implementasi;
cacat;
kesalahan.

Terlepas dari kenyataan bahwa, sesuai dengan pendekatan yang diusulkan pada awalnya , komentar dicatat dalam JIRA serta persyaratan untuk penyempurnaan perangkat lunak (sebagai tugas dari jenis "persyaratan"), proses eliminasi mereka layak mendapatkan pertimbangan terpisah.

Aturan untuk mewarnai kecoak

Orang yang tidak melakukan apa pun tidak salah.
Theodore Roosevelt

Tidak ada perangkat lunak tanpa kesalahan. Benar. Bahkan jika tidak ada kesalahan dalam kode, pengguna yang canggih akan menemukannya dalam dokumentasi atau hanya membuatnya. Dengan satu atau lain cara, saya belum melihat proyek di mana tidak ada insiden perangkat lunak. Analisis Pemeliharaan Perangkat Lunak oleh American Institute of Software Engineering ( SEI) di awal 90-an, menunjukkan bahwa koefisien korelasi antara jumlah kesalahan yang terdeteksi selama pengujian modul individu dan jumlah kesalahan yang ditemukan oleh pengguna dalam produk jadi adalah 0,91. Sederhananya, jika 10 kesalahan terdeteksi pada tahap pengujian, 9 kesalahan lainnya akan muncul selama operasi uji coba. Pencapaian kualitas yang diperlukan dalam pengembangan perangkat lunak untuk stasiun ruang angkasa dicapai, khususnya, karena keunggulan sepuluh kali lipat dari staf pengujian atas staf pengembangan, tidak termasuk penggunaan teknik-teknik canggih, misalnya, pengujian unit atau otomatisasi pengujian GUI.. Menurut pendapat saya, keandalan perangkat lunak tersebut tercapai karena keterlibatan minimum yang mungkin dari pengguna langsung dalam pekerjaannya. Tentu saja, sangat keren ketika tim kontrol kualitas profesional bekerja di proyek . Namun, dalam banyak proyek perangkat lunak tidak mungkin menerapkan semua rekomendasi ini karena berbagai alasan obyektif dan subyektif.

Oleh karena itu, jika manajer proyek tidak mengelola aliran insiden yang masuk, maka segera utas ini akan mengelola manajer semacam itu (jika ia tidak "tersedak" di utas ini).

Di sisi lain, seperti yang ditunjukkan oleh pengalaman, sebagian besar komentar pelanggan yang awalnya diklasifikasikan olehnya sebagai kesalahan perangkat lunak bukanlah kesalahan. Munculnya komentar semacam ini mungkin karena alasan seperti:

pelanggaran kondisi operasi teknis perangkat lunak ("tangan bengkok" dari administrator sistem pelanggan);
pembatasan hak akses pengguna (hak akses pengguna yang ditetapkan tidak memenuhi harapannya);
ketidakcocokan harapan fungsional pengguna dengan persyaratan yang diterapkan (jika tidak ada yang membantu, mungkin Anda harus membaca instruksi?);
inkonsistensi dalam deskripsi implementasi perangkat lunak (komentar yang agak jarang, karena pengguna dan administrator pelanggan, sebagai aturan, tidak membaca manual setelah kenalan pertama dengan perangkat lunak).

Dalam hal ini, selama korespondensi dengan pelanggan mengenai komentar pada perangkat lunak, disarankan untuk menghindari kata-kata seperti "kesalahan" atau "cacat", setidaknya sampai benar-benar jelas. Sampai pada titik ini, disarankan untuk menggunakan kata-kata "ucapan" atau "kejadian".

Proses terpadu dalam melaksanakan pekerjaan untuk menghilangkan insiden dapat direpresentasikan sebagai urutan langkah-langkah berikut.

Sumber

Mulai. Daftarkan aplikasi resolusi insiden dengan JIRA. Tahap ini untuk proyek yang berbeda dapat diatur dengan caranya sendiri. Anda dapat, misalnya, mendaftarkan aplikasi yang diterima dari pelanggan secara manual dengan JIRA, atau Anda dapat menggunakan kotak surat khusus, yang JIRA akan secara mandiri melihat dan mengkonfigurasi tugas berdasarkan huruf yang masuk. Jika Anda mengembangkan aplikasi web, Anda dapat menggunakan pengumpul tugas JIRA untuk mengumpulkan komentar pengguna . Di bidang bagaimana komentar ternyata terdaftar di JIRA (dalam status "peringkat" ), perlu untuk pra-proses itu.

1. Klarifikasi kondisi kejadian. Sebagai bagian dari tindakan ini, perlu untuk mengumpulkan informasi paling lengkap tentang komentar perangkat lunak:

urutan tindakan selama insiden itu terjadi, kombinasi dari input data;
detail dan wewenang pengguna komentar;
lokasi workstation (server);
tangkapan layar layar pengguna;
protokol pemantauan;
sampel file yang dihasilkan secara tidak benar (laporan).

Seringkali, sebagian besar insiden mengakhiri perjalanan hidup mereka pada tahap ini, karena selama pengumpulan artefak ternyata “kesalahan” yang terdeteksi adalah perilaku standar sistem. Jika JIRA mulai mengakumulasi persyaratan untuk menyelesaikan insiden yang diselesaikan tanpa membuat tugas pengembangan, ada baiknya memperhatikan keramahan pengguna antarmuka pengguna dan relevansi manual pengguna.

2. Perincian insiden menjadi persyaratan "atom". Seringkali, dalam satu surat, perwakilan pelanggan dapat mencerminkan beberapa komentar. Oleh karena itu, jika perlu, pada langkah kedua, berdasarkan surat terdaftar dari pelanggan ke JIRA, tugas persyaratan terpisah dibentuk. Selain itu, masing-masing tugas ini dikaitkan dengan persyaratan induk menggunakan hubungan Cloners . Untuk masing-masing tugas ini, materi yang dikumpulkan pada tahap sebelumnya dilampirkan (sebagian mengenai). Selanjutnya, semua pekerjaan diatur dengan masing-masing persyaratan secara terpisah.

3. Menentukan kerangka kontrak. Setelah menentukan cacat yang diidentifikasi, ditentukan untuk jenis hubungan kontraktual apa pekerjaan untuk menghilangkannya dapat dikaitkan. Dari sudut pandang organisasi kerja selanjutnya, tahap ini secara fundamental dapat mengubah prioritas tugas selanjutnya. Dalam banyak proyek, operasi uji coba komponen baru yang dikembangkan sebagai bagian dari pengembangan dilakukan dengan memasang komponen ini langsung pada versi saat ini setelah pengujian otonom singkat. Namun, pelanggan mengkorelasikan kesalahan yang muncul dalam kasus ini sudah dengan kontrak untuk dukungan dasar atau garansi, yang menetapkan tenggat waktu yang ketat untuk menghilangkan cacat. Jika, dalam kerangka dukungan dasar, periode kontrak untuk menghilangkan cacat dapat diukur dalam hitungan jam, maka jika cacat diidentifikasi dalam kaitannya dengan fungsi baru,periode untuk menghilangkan cacat yang sama ditentukan oleh tanggal berakhirnya operasi uji coba (hingga beberapa bulan). Jika manajer proyek tidak memperhatikan nuansa "kecil" ini, perusahaan pelaksana memiliki setiap kesempatan untuk mulai membayar denda untuk perangkat lunak sederhana bahkan sebelum dimasukkan ke dalam operasi komersial.

4. Kontrol duplikat. Dalam hal aplikasi bergabung kembali untuk menghilangkan cacat yang terdeteksi sebelumnya, persyaratan ini dikaitkan dengan tugas yang diajukan sebelumnya melalui koneksi "Duplicate» ( Duplicate ).

Berdasarkan hasil analisis awal dari insiden tersebut, perlu untuk memberi tahu pelanggan tentang hasilnya, karena visi pelanggan tentang waktu penghapusan insiden mungkin berkorelasi lemah dengan kewajiban kontrak.

5. Insiden harus diulangi di server uji oleh tim dukungan sebelum mengirimkan permintaan kepada analis tim pengembangan. Pengujian awal dapat direkam dalam JIRA dalam bentuk subtugas dengan persyaratan yang relevan.

6. Jika insiden itu tidak diselesaikan dalam langkah-langkah sebelumnya, persyaratan ditransfer ke status "ditugaskan" dan dipindahkan ke analis tim pengembangan untuk mengidentifikasi alasan terjadinya dan merumuskan tugas untuk eliminasi.

7. Jika perlu, analis harus mengklarifikasi ruang lingkup kontrak dari persyaratan. Jika ada komentar mengenai fungsionalitas baru perangkat lunak, maka analis harus mengaitkan cacat ini dengan persyaratan yang relevan untuk pengembangan / pengembangan / dukungan tambahan (tautan “Tambah”).

8. Analisis juga harus menentukan daftar komponen yang mempengaruhi komentar ini. Selain itu, jika komentar itu benar-benar bug perangkat lunak, itu harus dihasilkan.tipifikasi dari cacat yang terdeteksi.

9. Setelah mengidentifikasi penyebab cacat, analis kelompok pengembangan membentuk tugas pengembangan yang bertujuan menghilangkan kesalahan yang diidentifikasi. Jika perlu, tugas untuk menguji dan mengklarifikasi dokumentasi dibentuk. Sebagai bagian dari tugas-tugas ini, biaya tenaga kerja yang direncanakan ditentukan. Jika beban kerja tugas tertentu melebihi 8 jam, perlu untuk memberikan pembenaran kompleksitas dengan menggunakan alat yang ditentukan pada bagian sebelumnya. Dengan mempertimbangkan prioritas dan beban kerja tim proyek, tanggal yang direncanakan untuk pelaksanaan tugas-tugas ini ditentukan.
Setelah persyaratan pertama terkait dengan pengembangan perangkat lunak mulai berfungsi, insiden tersebut harus ditransfer ke status "sedang bekerja" .

10. Munculnya tugas terkait untuk pengembangan, pengujian dan dokumentasi persyaratan adalah sinyal bagi manajer proyek untuk membuat keputusan tentang versi perangkat lunak mana yang cacat yang diidentifikasi akan diperbaiki. Pada saat yang sama, manajer proyek merencanakan acara untuk implementasi perangkat lunak dengan menghubungkan persyaratan yang sesuai dengan tugas JIRA dari tipe "implementasi".

11. Jika perlu, manajer proyek mengklarifikasi tanggal yang direncanakan untuk pelaksanaan tugas terkait dan memberi tahu pelanggan tentang hal ini.

12. Koreksi cacat dilakukan dalam kerangka tugas jenis "pengembangan".

13. Setelah menghilangkan cacat, pengembang, jika perlu, harus mengklarifikasi jenis cacat yang terdeteksi dan komposisi komponen yang telah diselesaikan.

14. Jika perlu, dokumentasi ditentukan.

15. Spesialis kelompok pendukung melakukan pengujian otonom atas fungsi yang diperbaiki (sebagai bagian dari tugas pengujian yang dibentuk oleh analis kelompok pengembangan).
Juga, seperti dalam kasus implementasi persyaratan baru, dasar untuk mentransfer insiden ke status "selesai" adalah pemenuhan semua tugas yang dibuat berdasarkan (dengan pengecualian tugas jenis "implementasi").

16. Setelah melakukan pengujian offline, perbaikan disertakan dalam pembaruan dan dalam rilis saat ini.

17. Setelah kesiapan semua perbaikan yang direncanakan untuk dimasukkan dalam rilis pengiriman, pengujian integrasi dilakukan. Melakukan pengujian integrasi dapat diperbaiki di JIRA dalam bentuk sub-tugas untuk tugas yang sesuai dari tipe "implementasi".

18. Pembaruan perangkat lunak ditransmisikan ke pelanggan dengan cara yang ditetapkan. Namun, pengalihan tugas dari persyaratan yang relevan ke status "tertutup" hanya mungkin setelah menerima dari dokumenter bukti pelanggan tentang penghapusan insiden tersebut.

Sumber

Setiap pengembang tahu bahwa kesalahan terbesar adalah kesalahan yang tidak terdeteksi secara tepat waktu pada tahap pembentukan / spesifikasi persyaratan.

Ketentuan Pembekuan Persyaratan

Berjalan di atas air dan mengembangkan perangkat lunak sesuai dengan spesifikasi sangat sederhana ketika keduanya dibekukan.
Edward V. Berard

Perlu dicatat bahwa klarifikasi persyaratan yang paling efektif telah membuktikan diri dengan menciptakan situasi di mana pelanggan perlu memberikan jawaban sederhana untuk surat klarifikasi: "Saya setuju". Untuk ini, perlu dirumuskan beberapa kemungkinan jawaban dalam surat itu . Seni membentuk huruf-huruf seperti itu adalah bahwa pilihan yang paling dipilih pelanggan adalah yang paling disukai bagi Anda sebagai pemain.

Sumber

Misalnya, persyaratan "sederhana" "untuk memberikan kemungkinan pengambilan sampel berdasarkan wilayah di semua layar" pada tahap pengiriman dapat menyebabkan banyak masalah, karena tidak menentukan pada layar mana bentuk pengambilan sampel harus disediakan, apakah pengambilan sampel dengan satu nilai parameter atau beberapa bagaimana historisitas perubahan atas nama daerah harus diperhitungkan. Jika Anda hanya meminta untuk mengklarifikasi persyaratan ini, kecil kemungkinan jawabannya akan menyelesaikan masalah yang ditunjukkan.

Dalam hal ini, klarifikasi dapat dibuat menggunakan surat dari konten berikut:

. 4.5.6. : « 1, 2 3 «». , , ».

Salinan surat terlampir pada tugas. Tugas ditransfer ke status "menunggu keputusan" hingga respons dari pelanggan diterima, yang juga selanjutnya dilampirkan pada tugas tersebut. Kata-kata ini tercermin dalam bidang yang sesuai dengan tugas JIRA (lihat di bawah, “Klarifikasi”). Atas dasar itulah keputusan desain terkait, tugas pengembangan dan tugas uji dibentuk.

Idealnya, yang sering dapat dicapai sebagai cakrawala karena alasan obyektif dan subyektif, untuk mentransfer persyaratan untuk pengembangan lebih lanjut, perlu untuk memastikan pemahaman tentang batas-batasnya oleh semua anggota tim proyek. Oleh karena itu, segera setelah tugas jenis "persyaratan" dikaitkan dengan tugas pengembangan, manajer proyek memeriksa apakah ia memenuhi kriteria kualitas yang dijelaskan di bawah ini ( Definisi Siap) Jika kata-kata dasar dari persyaratan tidak memenuhi kriteria ini, pekerjaan perbaikannya harus dilakukan tanpa gagal. Hasil pekerjaan perbaikan harus berupa kata-kata yang diperbarui dari persyaratan, atau keputusan desain (SCF) yang disetujui oleh pelanggan terkait dengan persyaratan ini.

Kriteria untuk menilai kualitas persyaratan pada suatu proyek
Ciri	Penjelasan
Penyelesaian	Persyaratan sepenuhnya ditentukan dalam tugas JIRA, dan semua informasi yang diperlukan ada.
Konsistensi	Persyaratan tidak bertentangan dengan persyaratan lain dan sesuai dengan dokumentasi peraturan.
Atomicity	Persyaratannya adalah "atomik". Artinya, tidak dapat dipecah menjadi sejumlah persyaratan yang lebih rinci tanpa kehilangan kelengkapan.
Relevansi	Persyaratan tidak menjadi usang dari waktu ke waktu.
Kelayakan	Persyaratan dapat diterapkan dalam proyek (dengan mempertimbangkan sumber daya dan jadwal yang tersedia).
Ketidakjelasan	Persyaratan ini didefinisikan secara singkat tanpa menggunakan jargon teknis, akronim, dan frasa tersembunyi lainnya. Satu dan hanya satu interpretasi dimungkinkan. Definisi ini tidak mengandung frasa yang mendua. Kata-kata dari persyaratan (klarifikasi) tidak mengandung pernyataan negatif dan majemuk.

Ketika menghitung biaya tenaga kerja dalam tugas dengan jenis "persyaratan", hanya waktu yang dihabiskan secara langsung untuk penyempurnaannya yang dicatat. Semua biaya tenaga kerja lainnya dicatat dalam tugas dari jenis yang sesuai (atau subtugas mereka).

Selain atribut umum yang dijelaskan dalam artikel sebelumnya , satu set atribut tambahan didefinisikan untuk setiap tugas dari jenis "persyaratan" di JIRA selama proses yang panjang dan menyakitkan.

«»


*	( ).
	: ( , , .. ); ; — ( , , ); ; ( , ); /; (, , , , , ).
	, (, ).
()	. , , ( ).
	– . . . . , . - .
	, : ; ; ; ; ; .
	( - ). , . «» .

	, ( )
	/ ( PSP IBM): ( , ); ; ( , ); ( , , ); ( , -, ); ( , ); ( ); ( , , , , ); ( , ); , .
— , .
	: ; ; ; ; ; ; ; ; ; ; ; — , ; (e-mail).


	/ ( JIRA , [ ].[ ].[() ])

*	Jika alasan untuk mentransfer persyaratan ke status "ditutup" dijelaskan, maka bidang ini harus menunjukkan rincian dokumen yang mengonfirmasikan pengakuan resmi oleh Pelanggan bahwa persyaratan telah dipenuhi atau bahwa persyaratan telah dibatalkan.
Keputusan
Versi perangkat lunak	Nomor versi perangkat lunak tempat penerapan persyaratan

* Fitur mengisi atribut, umum untuk semua jenis tugas.

Mengubah atribut spesifik dari tugas tipe "persyaratan" ketika transisi dari negara ke negara dijelaskan oleh tabel berikut, di mana:

- perubahan atribut dimungkinkan;

- entri data yang diperlukan.

Bersambung

Banyak manajer proyek percaya bahwa jika kerangka acuan disetujui oleh pelanggan, maka ini adalah kebenaran tertinggi, yang tidak mengalami perubahan apa pun. Ini sebagian benar - kata-kata dari persyaratan spesifikasi teknis tidak mungkin diubah sampai penyelesaian proyek. Namun, sudah pada tahap awal proyek (jauh sebelum persetujuan Program dan prosedur pengujian), tidak ada yang mengganggu untuk menjelaskan batas-batas setiap persyaratan dengan pelanggan dan memperbaiki prosedur yang diusulkan untuk verifikasi. Jika pekerjaan tersebut belum dilakukan, maka kemungkinan besar semua "Daftar Keinginan" pelanggan dinyatakan selama implementasi, Anda akan memutuskan dalam anggaran dan waktu proyek yang sama.

Jangan lupa tentang hukum obyektif, yang menarik perhatian Barry Boehm ( Barry W. Boehm ) kembali di akhir 80-an abad terakhir. Jika manajer proyek tidak peduli tentang menghilangkan ketidakpastian dan ketidakakuratan persyaratan pada tahap awal proyek, maka pada tahap penyelesaian proyek ia dijamin memiliki banyak "penemuan" yang tidak menyenangkan.

Namun, pengalaman menunjukkan bahwa sebagian besar ambiguitas tidak dapat diselesaikan dengan hanya mengklarifikasi persyaratan. Selain itu, seringkali tidak mungkin untuk mempertimbangkan persyaratan secara terpisah satu sama lain, karena tujuan demi kepentingan perangkat lunak yang dibuat dapat dicapai hanya dengan penerapan keinginan pelanggan yang terintegrasi.

Dalam kerangka pendekatan yang dijelaskan, koordinasi seperangkat persyaratan yang saling berhubungan, serta interpretasi yang realistis dari fantasi pelanggan yang tercermin dalam kerangka acuan yang disetujui, diusulkan untuk dilakukan ketika menyelesaikan masalah jenis "analisis", fitur-fiturnya yang akan disajikan dalam artikel "JIRA: aturan untuk persiapan tepat waktu perangkat lunak lezat. TLDR 3: Solusi Desain. "

JIRA: aturan untuk persiapan tepat waktu perangkat lunak lezat. TLDR 2: manajemen persyaratan

Aturan untuk persyaratan pemotongan

Aturan untuk mewarnai kecoak

Ketentuan Pembekuan Persyaratan

Bersambung

More articles: