JIRA: aturan untuk persiapan tepat waktu perangkat lunak lezat. TLDR 1: Batas Peluang

Sebelumnya dalam artikel " JIRA sebagai obat untuk insomnia dan gangguan saraf ", sebuah opsi diusulkan untuk menggunakan JIRA untuk mengelola proyek pengembangan perangkat lunak demi kepentingan pelanggan negara besar. Namun, penanganan peralatan otomatisasi kontrol yang ceroboh di "dapur digital" tidak hanya dapat merusak produk, tetapi juga menyebabkan banyak cedera. Dalam serangkaian artikel "Aturan untuk persiapan tepat waktu dari perangkat lunak yang lezat" diusulkan untuk mempelajari secara rinci aturan untuk mengatur pekerjaan pada proyek perangkat lunak menggunakan katalis yang disebut JIRA. Setiap kritik diterima.

Sumber

Rahasia Umum

Kecerdasan adalah kemampuan untuk menghindari melakukan pekerjaan, tetapi agar itu dilakukan.
Linus Tordvalds

Setelah publikasi artikel " JIRA sebagai obat untuk insomnia dan gangguan saraf ", beberapa eksekutif menjadi tertarik dengan pengalaman kami dalam menggunakan JIRA dan memutuskan untuk memperkenalkan skema otomatisasi manajemen yang serupa pada proyek-proyek mereka. Karena itu, sebagai hasil dari penulisan esai ini, ia seharusnya secara bersamaan “menangkap beberapa kelinci”:

- secara berurutan mempertimbangkan setiap jenis tugas JIRA sebagai subproses proyek, selama presentasi:

• menyatukan spesifikasi dari subproses ini;
• standarisasi aturan bisnis untuk pekerjaan yang terorganisir;
• untuk menyusun peta "perangkap" khas dan tempat-tempat yang membutuhkan "tempat tidur jerami" di muka;
• menentukan indikator kinerja yang terukur dan dapat dicapai untuk setiap jenis tugas.

- merumuskan pernyataan masalah bagi administrator JIRA untuk menyebarkan proyek-proyek baru sesuai dengan pendekatan yang diusulkan;
- dapatkan regulasi informal, namun demikian, dapat dipahami dan transparan tentang distribusi tanggung jawab semua karyawan tim proyek;
- memformalkan resep terbaik yang ditemukan selama solusi dari situasi masalah ("peretasan kehidupan" dari manajer proyek);
- Mengidentifikasi kelemahan-kelemahan sebelumnya dari pendekatan yang diusulkan selama diskusi tentang rincian penerapannya dengan para pembaca Habr.

Saya ingin segera mencatat: beberapa teknik yang dijelaskan telah membuktikan diri di salah satu dapur digital LANIT untuk manajemen proyek untuk pengembangan dan pemeliharaan perangkat lunak khusus untuk kepentingan pelanggan negara besar. Namun, sama sekali bukan fakta bahwa rekomendasi ini akan sama bermanfaatnya untuk proyek Anda. Di sisi lain, kita memasuki terra incognita. Beberapa pertimbangan yang diungkapkan hanya direncanakan untuk implementasi. Karena itu, jika Anda melihat kelemahan dalam pendekatan yang diusulkan atau ada proposal konstruktif untuk optimasi, selamat datang di diskusi di komentar.

Diasumsikan bahwa setelah penyatuan dilakukan untuk kepentingan pemimpin yang berbeda, teknologi manajemen yang dijelaskan akan berhasil diterapkan pada proyek perangkat lunak dengan orientasi dan skala yang berbeda. Pada gilirannya, penggunaan ruang konseptual tunggal ketika mendaftarkan tugas-tugas JIRA menciptakan prasyarat untuk penilaian otomatis keadaan saat ini dalam kerangka portofolio proyek . Selain itu, diasumsikan bahwa pendekatan terpadu untuk mencatat hasil pekerjaan di JIRA akan menyederhanakan mobilitas karyawan antara beberapa kelompok proyek, yang pada gilirannya juga akan berkontribusi pada peningkatan keberhasilan proyek.

Batas proyek

Tugas sulit apa pun memiliki solusi yang salah, sederhana, mudah dimengerti, dan salah.
Arthur Bloch

Karena algoritma aplikasi JIRA yang diusulkan mulai "menyebar" ke proyek-proyek lain, perlu dipikirkan kembali pertanyaan: "Apa yang sebenarnya menentukan batas-batas proyek perangkat lunak di JIRA?"

Menurut pengikut PMBoK yang tidak bersuara , jawaban atas pertanyaan ini adalah dasar: "Tentu saja, batas-batas proyek ditentukan oleh piagam (paspor) proyek ." Dari sudut pandang ini, untuk setiap kontrak dengan pelanggan, proyek terpisah harus dibentuk di JIRA. Selain itu, seringkali pengembangan satu paket perangkat lunak dapat mencakup beberapa bidang kegiatan, di mana, sebagai suatu peraturan, beberapa kontrak disimpulkan:

• pengembangan - persyaratan di bawah kontrak untuk pembuatan sistem baru (subsistem);
• pengembangan - persyaratan dalam kerangka kontrak yang ditujukan untuk revisi substansial dari subsistem yang ada;
• dukungan yang diperluas - persyaratan kontrak untuk penyelesaian operasional modul sistem individual untuk perubahan saat ini dalam proses bisnis pelanggan;
• dukungan garansi - penghapusan kesalahan perangkat lunak yang diidentifikasi selama masa garansi;
• dukungan dasar - penghapusan kesalahan perangkat lunak yang diidentifikasi setelah akhir masa garansi.

Selain itu, sebagai bagian dari pembuatan perangkat lunak, tim proyek harus menyelesaikan persyaratan yang tidak ditentukan oleh kontrak. Ini adalah persyaratan dari manajer proyek terkait dengan kegiatan pra-proyek, refactoring, presale, penghapusan kesalahan yang diidentifikasi secara independen, pelatihan staf, dll.

Namun, seperti yang telah ditunjukkan oleh praktik, dalam pengembangan aktual produk perangkat lunak jangka panjang, sulit untuk memisahkan pekerjaan pengembangan dan pemeliharaan. Operasi uji coba belum berakhir (kontrak pengembangan belum ditutup), dan pelanggan sudah dalam kekuatan penuh untuk merumuskan persyaratan untuk dukungan tambahan untuk komponen sistem yang belum dimasukkan ke dalam operasi komersial. Pelanggan dapat dipahami, karena dunia berubah lebih cepat dari yang direncanakan dalam kontrak yang disetujui. Pada saat yang sama, identifikasi cacat perangkat lunak baru terus berlanjut. Dan pengguna yang menemukan cacat tidak peduli sama sekali di bawah kontrak apa kesalahan ini harus diperbaiki. Dari sudut pandangnya - itu seharusnya tidak terjadi. Untuk menghubungkan kesalahan yang diidentifikasi dengan satu atau lain kontrak, perlu waktu untuk menganalisisnya, dan jika proyek JIRA dibagi berdasarkan kontrak, dilema muncul: "Dan di mana proyek JIRA mana cacat ini harus didaftarkan?". Selain itu, perlu untuk mengatur transfer tugas dari satu proyek ke proyek lain, jika kesalahan klasifikasi dibuat. Jika Anda menetapkan semua cacat perangkat lunak yang terdeteksi ke proyek terpisah dari kelompok dukungan, risiko masalah muncul ketika menyelesaikan masalah pembayaran untuk pekerjaan pada tahap kontrak pengembangan atau meninjau keluhan tentang ketidakpatuhan dengan perjanjian tingkat layanan ( SLA ).

Di sisi lain, kepala departemen yang cemburu mengusulkan bahwa dalam kerangka proyek, proyek terpisah dibuat untuk tim pendukung, departemen analitis, dan departemen pengembangan dan pengujian. Semua orang ingin menjadi master penuh di keuskupannya dan tidak bertanggung jawab atas "beting" tetangga. Selain itu, fleksibilitas luar biasa dari JIRA memungkinkan Anda untuk membuat koneksi antara tugas-tugas proyek yang berbeda.

Sumber

Menurut pendapat saya, pendekatan di atas untuk mendaftarkan proyek di JIRA mirip dengan mencoba memasak satu sup di beberapa pot berbeda yang terletak di dapur yang berbeda. Tujuan utama dari proyek ini adalah penciptaan produk perangkat lunak dengan kualitas yang tepat waktu. Dari sudut pandang pelanggan, kualitas produk ditentukan oleh serangkaian kemampuan fungsional produk ini, yang dengannya pelanggan dapat dijamin (yaitu andal) memecahkan masalahnya. Dan itu tidak masalah bagi pelanggan fungsional akhir di mana hubungan kontraktual fungsi yang diperlukan dibuat. Sama seperti itu tidak penting bagi pilot untuk mengetahui daftar subkontraktor yang terlibat dalam pembuatan pesawat terbangnya.

Dengan mengingat hal ini, mendefinisikan batas-batas proyek JIRA harus memastikan keharmonisan antara dua pertimbangan berikut.

1. Diperlukan bahwa proyek mencerminkan semua pekerjaan yang dilakukan selama pembuatan / modifikasi produk perangkat lunak (atau subsistemnya). Proyek harus dianggap sebagai satu proses untuk pembuatan satu produk perangkat lunak (satu "pesawat"). Oleh karena itu, prinsip utama: satu produk perangkat lunak - satu proyek JIRA. Penting untuk tidak melupakan apa yang diproduksi oleh perusahaan Anda - “pesawat terbang” atau “mesin pesawat terbang”. Bagaimanapun, pembuat perangkat lunak tidak boleh diasingkan dari konsekuensi keputusan mereka.
   
   Terlepas dari jenis hubungan kontraktual dengan pelanggan, titik masuk ke proses pembuatan produk perangkat lunak adalah persyaratan apa pun untuk modifikasi. Acara terakhir adalah penerimaan konfirmasi pelanggan bahwa persyaratan ini telah diterapkan (atau dinyatakan pailit). Aturan ini adalah yang utama untuk menilai kelengkapan perencanaan dan kelengkapan tugas dalam proyek JIRA.
   
   Dianjurkan agar proyek JIRA juga menemukan tempat untuk pekerjaan tambahan yang dimulai untuk kepentingan memenuhi persyaratan pelanggan. Selama pengembangan perangkat lunak, banyak peristiwa terjadi yang, sebagai suatu peraturan, tetap “tertinggal”: pertemuan rutin untuk memperjelas tenggat waktu, menyebarkan server uji, menyiapkan data uji, menghasilkan instruksi tambahan, dll JIRA dapat sangat membantu dalam mendeteksi lubang yang melaluinya waktu kerja karyawan tim proyek mengalir dengan murah hati dan tidak dapat dibatalkan. Tetapi hanya dengan syarat bahwa karya-karya ini akan didaftarkan dalam proyek JIRA.
2. Dalam hal mengembangkan sistem perangkat lunak yang sangat besar, Anda tidak boleh mendorong semuanya menjadi satu proyek JIRA, secara signifikan meningkatkan risiko gangguan. Dalam kasus tersebut, dalam proyek JIRA yang terpisah, disarankan untuk mengelompokkan fungsi-fungsi perangkat lunak yang memberikan dukungan untuk salah satu proses bisnis pelanggan (sebagai suatu peraturan, fungsi-fungsi tersebut dialokasikan untuk subsistem yang terpisah yang sudah pada tahap desain konseptual).

Sumber: Sergey Arkhipenkov. Evaluasi Proyek: Dukun atau Shamanisme

Perlu dipikirkan tentang pembentukan masing-masing proyek JIRA untuk merekam hasil pekerjaan yang dilakukan secara teratur dalam kerangka beberapa produk perangkat lunak (misalnya, menghitung waktu yang dihabiskan oleh karyawan untuk mempelajari teknologi baru atau pekerjaan yang berkaitan dengan cadangan).

Salah satu batasan pada proyek JIRA mungkin adalah jumlah maksimum karyawan tim proyek. Pengalaman pribadi menyarankan kesimpulan berikut: komposisi maksimum tim pengembangan pada proyek JIRA tunggal mengikuti aturan Miller (dalam tradisi Agile terbaik). Kelompok pengembangan di sini mengacu pada programmer dan analis yang merumuskan tugas untuk mereka. Dan, tentu saja, manajer proyek. (Seperti yang mungkin Anda pikirkan! Ini sakral!) Selain itu, jika anggaran proyek memungkinkan, sisa 80% dari karyawan tim proyek, yang terdiri dari gadis-gadis tim pendukung yang ramah, penguji yang kesal, penulis teknis yang membosankan, dan administrator sistem yang menyenangkan, dapat dimasukkan dengan aman dan harmonis ke dalam proyek JIRA.

Cara menempatkan tugas di rak

Di loteng saya hanya ada alat yang saya butuhkan. Ada banyak dari mereka, tetapi mereka dalam tatanan sempurna dan selalu di tangan.
Sherlock Holmes

Pada proyek apa pun, navigasi karyawan dalam aliran tugas yang harus diselesaikan adalah salah satu komponen penting keberhasilan. Namun, ketika volume proyek bertambah, menjadi semakin sulit untuk memahami aliran ini, yang mungkin menjadi salah satu masalah dalam mengelola proyek besar. Oleh karena itu, definisi sistem koordinat tunggal yang dapat dengan mudah ditavigasi oleh semua peserta kunci adalah bagian integral dari otomatisasi manajemen proyek.

Dasar dari sistem koordinat seperti itu dalam proyek kami adalah pertimbangan berikut: produk perangkat lunak, sebagai suatu peraturan, dapat dibayangkan sebagai kotak hitam yang berkomunikasi dengan dunia luar melalui tiga cara utama:

• melalui antarmuka pengguna ;
• melalui dokumen yang dibentuk untuk dicetak di atas kertas;
• melalui protokol pertukaran data elektronik ( API / EDI ).

Dalam ruang tiga dimensi inilah pengguna akhir melihat perangkat lunak. Di sisi lain, penciptaan perangkat lunak ditujukan tepat pada pembentukan dan pemrosesan aliran data ini.

Sumber

Selain itu, objek basis data utama dan proses bisnis otomatis diadopsi sebagai koordinat tambahan dalam proyek. Untuk bernavigasi dalam ruang koordinat ini, pengklasifikasi yang sesuai telah dibentuk, dukungan yang disediakan oleh manajer proyek dan analis. Setiap elemen dari classifier terdiri dari kode dan definisinya.

Dalam proyek saya, untuk setiap classifier, fitur-fiturnya sendiri secara bertahap terungkap, yang harus diperhitungkan jika Anda memutuskan untuk menerapkan pendekatan yang sama.

• Dalam kasus kami, kode formulir yang dicetak tidak mengulangi penomoran formulir sesuai dengan dokumen pelanggan. Selain itu, formulir individual memiliki beberapa opsi cetak. Jadi, misalnya, sepanjang keberadaan perangkat lunak, bentuk salah satu laporan telah berubah beberapa kali berdasarkan perubahan dalam dokumen peraturan (nama dan esensi laporan tidak berubah). Pada saat yang sama, untuk data lama diharuskan untuk tetap mencetak laporan ini dalam bentuk lama. Pertimbangan yang sama berlaku untuk klasifikasi di bawah konsep protokol untuk pertukaran data elektronik.
• Dalam hierarki formulir, elemen individual dapat mencakup panel navigasi (menu), formulir daftar, kartu objek, tab, panel filter, formulir pemuatan / pembongkaran data, serta bentuk operasi grup yang kompleks.
• Diinginkan untuk "menumbuhkan" pohon-pohon "dari proses teknologi sedemikian rupa sehingga dedaunannya adalah operasi teknologi atom (tidak terbagi), atas dasar itu, pada gilirannya, adalah mungkin untuk memastikan berfungsinya subsistem distribusi akses (subsistem keamanan).
• Karena semua elemen klasifikasi dengan pendekatan ini ditampilkan pada layar JIRA dalam satu bidang, perlu untuk memberikan setidaknya kodifikasi primitif di samping nama komponen untuk membedakan formulir "Pendaftaran Karyawan" dari proses "Pendaftaran Karyawan".

Bagi mereka yang tidak mencari cara mudah, tugas JIRA dapat ditandai berdasarkan pendaftaran kode yang sesuai di bidang "Komponen". Saat mendaftarkan tugas jenis apa pun di JIRA, di bidang "Komponen", Anda hanya perlu menunjukkan daftar kode objek yang tujuan pekerjaan yang direncanakan diubah / dibentuk. Berdasarkan hasil penyelesaian setiap masalah, pelaksana yang bertanggung jawab harus mengklarifikasi komposisi komponen (jika perlu). Klasifikasi komponen itu sendiri kemudian dipelihara di luar JIRA.

Bagi pecinta kenyamanan dalam hal ini, mungkin Subkomponen untuk plugin JIRA dapat banyak membantu.

Perlu dicatat bahwa penggunaan pengklasifikasi yang dikompilasi dengan benar dari komponen perangkat lunak secara tersirat menstandarkan kesadaran kolektif dan bahasa komunikasi dari tim proyek, yang menghasilkan peningkatan tingkat pemahaman umum. Di sisi lain, pendekatan ini adalah salah satu metode paksaan para analis untuk melakukan tugas-tugas yang lebih rinci, yang, pada gilirannya, meningkatkan akurasi memperkirakan waktu pelaksanaan persyaratan pada proyek.

Aturan klasifikasi yang diadopsi untuk tugas tidak hanya mengurangi waktu yang dihabiskan untuk pencarian, tetapi juga menyediakan kemampuan untuk mengotomatisasi:

• perkiraan total input tenaga kerja yang direncanakan (atau biaya tenaga kerja nyata) untuk pekerjaan yang ditujukan untuk implementasi elemen perangkat lunak tertentu,
• penilaian distribusi aktual prioritas - pada beberapa tahap proyek, manajernya mungkin terkejut menemukan bahwa sebagian besar pekerjaan tidak dilakukan dalam kaitannya dengan komponen prioritas,
• analisis kualitas pengembangan dokumentasi ,
• penilaian kualitas manajemen proyek dalam hal perencanaan. Di satu sisi, tidak masuk akal untuk merencanakan tugas di mana komponen tidak terbentuk (dimodifikasi), dan di sisi lain, perencanaan tugas, selama pengembangan yang lusinan objek diubah, menunjukkan bahwa masalah tidak dirumuskan dengan cermat.

Saat mengikat tugas, jangan ikat tangan Anda

Ketika menggambarkan prinsip-prinsip umum model kami , dikatakan tentang hanya menggunakan satu jenis koneksi "alasan" -> "tindakan" (dan dalam kerangka proyek yang dijelaskan, koneksi ini cukup memadai). Namun, keinginan untuk menggunakan mekanisme JIRA yang sama untuk mengotomatisasi manajemen dalam beberapa proyek yang berbeda diperlukan untuk memperluas jumlah jenis hubungan yang digunakan dan menyatukan pendekatan untuk aplikasi mereka.

Sumber

JIRA "out of the box" menawarkan kepada pengguna beberapa jenis koneksi yang berbeda antar tugas, dan penggunaan koneksi yang tidak terkontrol ini dapat menimbulkan konsekuensi yang menyedihkan. Agar tidak membingungkan diri sendiri dan orang lain, kami telah menyetujui aturan dasar berikut untuk pengikatan tugas JIRA.

• Penutupan dari jenis tautan yang sama dalam loop tidak dapat diterima (meskipun JIRA memungkinkan ini).
• Hubungan tambahan "Tergantung" ("alasan" => "tindakan") digunakan hanya untuk menghubungkan tugas dari jenis yang berbeda, dan hanya dalam arah "aliran" model kaskade klasik (air terjun): persyaratan => analisis => pengembangan => pengujian => dokumentasi => implementasi. Menentukan koneksi ini dalam urutan terbalik dan menghubungkan tugas dari jenis yang sama dengan menggunakannya tidak dapat diterima. Jika persyaratan baru lahir selama implementasi, maka ketika persyaratan ini terdaftar dengan JIRA, koneksi antara mereka dan tugas implementasi, di mana mereka muncul, tidak terbentuk.
• Koneksi " Blok " ("blok" => "blok") dapat digunakan dalam salah satu jenis tugas untuk membangun urutan alur kerja (misalnya, untuk membuat skrip pelaksanaan pengujian).
• Hubungan “ Cloners ” (“parent” => “child”) hanya digunakan untuk komunikasi tugas dari jenis “persyaratan”. Mengaitkan dokumen asli pelanggan yang berisi beberapa persyaratan ("induk") dengan tugas yang berisi persyaratan atom "keturunan".
• Hubungan "Suplemen" ("Suplemen" => "ditambah") digunakan hanya untuk hubungan dalam kerangka tugas jenis "kebutuhan". Ini digunakan untuk mendaftarkan hubungan antara tugas persyaratan utama dan tugas di mana kesalahan, komentar, dan klarifikasi yang diidentifikasi selama pengujian dicatat. Bahkan, dengan menggunakan jenis komunikasi ini, registrasi sejarah perubahan persyaratan disediakan.
• Hubungan "Duplikat" ("duplikat" => "duplikat") hanya digunakan untuk komunikasi tugas jenis "persyaratan". Ketika menentukan duplikat, perlu untuk menentukan persyaratan dasar, dalam kerangka kerja yang akan direncanakan pada implementasinya. Sehubungan dengan duplikat, komunikasi dengan tugas implementasi tidak dibuat.

Alur kerja untuk semua kesempatan

Alasan banyak masalah adalah bahwa kita menetapkan banyak tugas yang harus kita selesaikan, dan tidak sebanyak yang bisa kita selesaikan.
Maxim Dorofeev

, JIRA, . , JIRA (workflow). .

. «» . , JIRA . , .

, «» «», «» ( , ).






, .
*

, :

— ;

— ;

— .


« » «» . , . «». , . «» ( ).

BPM ( business process management ), . BPM «» , :

• - ( BPM CBOK );
• ( PM BOK );
• ( ITIL );
• ISO 9000 ;
• ( CMMI SEI );
• , , / 12207-2010 « . . ».

PMP ITIL . , , BPM , , . BPMS . - BPM ( , , Agile ). BPM « » ( , ). «» «» ( ). «»?

BPM . , , , BPM , .

Sumber

JIRA . , JIRA , , . BPM. , JIRA BPMS. Semua saran lebih lanjut untuk menggunakan JIRA untuk mengotomatisasi manajemen proyek perangkat lunak akan dibuat dengan pertimbangan utama ini dalam pikiran.

Salah satu langkah pertama pada tangga CMMI adalah mengidentifikasi, mendokumentasikan, dan menyatukan proses organisasi. Oleh karena itu, sebagai bagian dari seri artikel “JIRA: aturan untuk persiapan tepat waktu dari perangkat lunak yang enak”, ia seharusnya secara konsisten merumuskan spesifikasi untuk semua jenis tugas yang harus diselesaikan dan mencoba merumuskan perangkat kriteria untuk penilaian komprehensif mereka dari sudut pandang pendekatan proses. Artikel selanjutnya akan dikhususkan untuk fitur tugas mendaftar dari jenis "persyaratan" dan proses bisnis untuk implementasi mereka.