JIRA sebagai obat untuk insomnia dan gangguan saraf

Bagaimana membangun proses manajemen proyek yang efektif dalam kondisi ketika "benar" dan "apa yang lebih baik" tidak dapat dilakukan, tetapi masih perlu dilakukan? Artikel ini memberikan gambaran umum tentang penggunaan JIRA untuk mengelola proyek pengembangan perangkat lunak demi kepentingan pelanggan besar pemerintah. Saya akan senang jika pendekatan yang dijelaskan akan membantu Anda secara pribadi meningkatkan efektivitas tim Anda dan mengurangi ketegangan pada proyek. Setiap kritik diterima.

Sumber

Anak kesalahan yang sulit

Dilihat oleh sejumlah besar artikel model di Internet tentang cara menerapkan sistem manajemen proyek dengan benar dalam pengembangan perangkat lunak, ini adalah bisnis yang sederhana dan berterima kasih. Namun, sebenarnya penggunaan sistem kontrol otomatis dalam proyek-proyek di mana saya memiliki kesempatan untuk berpartisipasi tidak "semarak" seperti yang diharapkan. Ada beberapa kasus khas yang ditemukan dalam praktik.

Opsi terbaik datang ke penggunaan oleh tim proyek dari salah satu dari banyak sistem pelacakan bug. Struktur tugas dan proses bisnis suatu proyek biasanya dikembangkan "out of the box". Sistem ini digunakan terutama oleh tim programmer dan penguji. Organisasi pengembangan seperti itu membuahkan hasil yang baik pada proyek-proyek kecil dengan pelanggan pribadi, atau jika tugas para pelaku hanya mencakup dukungan garansi untuk produk perangkat lunak (memperbaiki kesalahan yang terdeteksi). Namun, dengan pertumbuhan persyaratan baru, pendekatan ini mulai tergelincir. Ini dimanifestasikan dalam peningkatan dalam waktu yang dihabiskan membandingkan persyaratan pelanggan dan informasi yang disimpan dalam bugtracker (dan secara manual menyusun laporan terintegrasi), serta dalam membagi tim menjadi dua kubu (pemrogram "baik" dan analis "buruk").

Situasi lain bermuara pada inspirasi kepemimpinan yang "brilian", ketika, dengan menggunakan tuas administratif, metodologi pengembangan perangkat lunak terbaik "diperkenalkan" ke dalam kegiatan tim proyek. Benar, para pemimpin ini percaya bahwa tindakan mereka hanya terbatas pada proses menemukan "peluru perak" ini. Mereka tidak peduli dengan konsep seperti " sprint ", " diagram pembakaran tugas " atau " diagram alur kumulatif ". Dan bahkan jika mereka terganggu, dokumen pelaporan yang perlu dibentuk tentang keadaan proyek (sekali lagi secara manual) secara longgar terhubung dengan metodologi terbaik ini. Upaya untuk memperkenalkan kepada pelanggan metode-metode ini mengarah pada fakta bahwa kondisi proyek tidak berubah, dan pada laporan-laporan lama juga diperlukan untuk menghasilkan laporan tambahan baru (sesuai dengan metode baru). Kontradiksi semacam itu terutama diucapkan pada proyek kontrak pemerintah, kondisi organisasi yang secara langsung bertentangan dengan keberhasilan penerapan Agile , RUP atau PMBOK .

Pendewaan otomasi manajemen adalah proyek untuk memperbaiki sistem informasi tingkat federal untuk kepentingan satu pelanggan negara besar. Sebagai bagian dari proyek ini, pelanggan sendiri menggunakan HP Service Manager dan JIRA . HP Service Manager digunakan untuk mengumpulkan dan menganalisis kesalahan perangkat lunak. Dengan bantuan JIRA, pelanggan merencanakan kegiatan karyawannya terkait dengan koreksi kesalahan ini dan pengembangan sistem lebih lanjut. Daftar status tugas dalam sistem ini menyediakan berbagai opsi yang mungkin untuk pemrosesan mereka. Prosedur terperinci untuk mendukung tugas-tugas ini, dibentuk oleh kantor proyek pelanggan (yaitu, orang-orang yang tidak bertanggung jawab atas pemeliharaan dan pengembangan), diposting di platform Confluence . Karyawan kontraktor diizinkan untuk kedua sistem, dan mereka dipercayakan dengan tanggung jawab mendukung insiden dan persyaratan (dengan pedoman sementara untuk tugas-tugas pemrosesan dan skala denda yang progresif). Selain itu, salinan JIRA disebarkan di lokasi kontraktor, dengan bantuan yang kegiatan tim proyek direncanakan. Sinkronisasi kegiatan ketiga sistem dilakukan secara manual (untuk ini saya harus menyimpan "sheet" di Excel, di mana hubungan tugas dan keadaan saat ini dicatat). Selain itu, laporan yang dihasilkan JIRA tidak sesuai dengan manajemen, dan oleh karena itu tim proyek harus memberikan laporan per jam tentang kegiatan mereka, yang juga mereka buat secara manual di Excel. Situasi ini tidak jarang terjadi ketika kepala tim pengembangan atau kepala kelompok pendukung "menutup telepon" sampai larut malam, menghasilkan laporan ringkasan tentang keadaan proyek berdasarkan hasil dari tim proyek. Proyek ini berhasil diselesaikan tepat waktu dan diingat, kecuali untuk rekor produktivitas yang rendah, peningkatan jumlah gangguan saraf, kelelahan profesional yang cepat dan, dilihat dari bonus karyawan yang "selamat", margin yang tidak terduga rendah. Setelah proyek semacam itu, pemikiran itu menghantui kita untuk waktu yang lama: "Jika kita menciptakan alat yang sangat memudahkan kehidupan pelanggan, lalu mengapa, karena alat seperti itu, apakah kita begitu canggih memperburuk kehidupan kita?"

Fitur pembangunan nasional

Meringkas pengalaman, kita dapat menyimpulkan bahwa masalah terbesar dengan otomatisasi manajemen pengembangan perangkat lunak terjadi pada proyek untuk pesanan negara.

Sumber

Selain itu, upaya berulang untuk memecahkan masalah ini sesuai dengan praktik terbaik pengembangan perangkat lunak mengarah pada kesimpulan: ini bukan masalah, tetapi kondisi yang tak terelakkan untuk implementasi proyek bagi pelanggan negara. Analisis beberapa proyek memungkinkan kami untuk mengidentifikasi fitur karakteristik umum berikut dari kondisi tersebut:

• seringkali persyaratan awal dari spesifikasi teknis diformulasikan secara samar, pelanggan menempatkan makna baru dalam persyaratan ini ketika proyek berkembang (yang terkait, antara lain, dengan perubahan dalam kerangka peraturan saat ini yang mengatur proses bisnis otomatis);
• rentang persyaratan yang dicatat dalam kerangka acuan berkisar dari "perbaiki prasasti" hingga "menerapkan subsistem untuk pemantauan dan analisis semua proses", sementara semua persyaratan harus diterapkan tanpa syarat (sebagai suatu peraturan, proposal untuk memperbaiki susunan kata tidak diterima, Anda hanya dapat memengaruhi beberapa batasan pada metode implementasi);
• kadang-kadang pelanggan, yang tidak tahu bagaimana menyelesaikan masalah, "mendorong" masalah-masalah ini ke kontraktor, termasuk persyaratan yang, dengan kata lain, "esoterik" (sesuatu seperti "... subsistem harus menyediakan perkiraan untuk nilai tukar mata uang utama untuk jangka pendek, menengah dan panjang ... ");
• dalam hal kontrak terkait dengan penyempurnaan sistem yang ada, pelanggan memerlukan pengenalan komponen individu sebelum operasi uji coba dengan jaminan operasi yang tidak terputus dari seluruh sistem (dapat dibandingkan dengan penyelesaian mesin mobil saat bepergian)
• pelanggan diwakili oleh beberapa unit (organisasi), persyaratan yang seringkali bertentangan;
• anggaran dan tenggat waktu untuk proyek tetap tidak berubah, meskipun ada perubahan dan penambahan persyaratan;
• pelanggan tidak mencari kerja sama dengan pengembang (kerja sama didasarkan pada prinsip "Anda melakukannya dulu, baru kita lihat"); perwakilan pelanggan menghindari tanggung jawab untuk membuat keputusan mengenai spesifikasi persyaratan, waktu koordinasi masalah yang bermasalah diabaikan, tidak ada gunanya memerlukan koordinasi sebelum pengembangan dimulai, karena fakta bahwa tim tidak memenuhi tenggat waktu tidak menjadi perhatian pelanggan (mis. ini adalah masalah kami sebagai pemain);
• di satu sisi, pelanggan membutuhkan kepatuhan yang tepat dari seluruh paket dokumentasi dengan persyaratan formal GOST, di sisi lain, pengembangan instruksi tambahan untuk menggunakan produk dalam menyelesaikan masalah tertentu.

Sebagai aturan, semua faktor ini memicu kemarahan tim proyek mengenai "pelanggan yang tidak memadai" dan "manajemen proyek yang salah." Namun, mengingat obyektivitas dan pengulangan kondisi di atas, keluhan dari tim proyek tentang "kompleksitas" pelanggan negara sama dengan keluhan dari tim kapal tentang dingin dan gelapnya malam kutub, setelah perusahaan pengiriman memenangkan tender besar untuk transportasi di sepanjang Jalur Laut Utara .

Selain kondisi eksternal, ternyata, fitur karakteristik umum dimiliki oleh tim karyawan yang terlibat dalam proyek perangkat lunak.

• Inti dari tim proyek dapat terdiri dari 5-12 karyawan: manajer proyek, analis, penguji, penulis teknis, programmer. Terlepas dari kenyataan bahwa beberapa karyawan kadang-kadang dapat melakukan beberapa peran, sebagai suatu peraturan, tim proyek ini dicirikan oleh “ faktor bus ” yang rendah. Ini dengan sendirinya juga memberlakukan batasan pada penggunaan metode Agile (misalnya, menggunakan penjadwalan poker dalam kondisi seperti itu tidak mungkin berguna).
• Tim proyek, bersama dengan proses pengembangan perangkat lunak, harus secara bersamaan memberikan dukungan garansi (memperbaiki kesalahan perangkat lunak) dan dukungan tambahan (penyelesaian operasional modul sistem individual untuk perubahan saat ini dalam proses bisnis pelanggan).
• Sebagai bagian dari kinerja tugas individu, karyawan dari divisi yang berdekatan dari perusahaan terlibat, serta subkontraktor (perusahaan eksternal yang dipaksakan oleh pelanggan), yang tugas-tugas proyek biasanya menjadi prioritas sekunder.

Kemenangan harapan

Pernikahan kedua adalah kemenangan harapan atas pengalaman hidup.
Samuel Johnson

Dua tahun lalu, saya diundang sebagai analis terkemuka ke proyek yang dilakukan oleh LANIT atas perintah pemerintah. Tim proyek dibentuk sebelumnya, proyek terdiri dari penyempurnaan substansial sistem otomatis yang telah ada selama lebih dari satu dekade. Secara umum, kondisi proyek seperti dijelaskan di atas. Pada saat itu, tim pengembangan tidak menggunakan sistem manajemen proyek yang ada dalam pekerjaan mereka (meskipun hampir semua karyawan berpartisipasi dalam proyek-proyek di mana sistem tersebut digunakan dan memiliki pendapat yang agak skeptis tentang perlunya mengotomatisasi manajemen). Namun, situasi awal saat ini memberikan kesempatan untuk menguji otomatisasi manajemen proyek "dari awal".

JIRA terpilih sebagai platform otomatisasi. Kombinasi dari faktor-faktor berikut berkontribusi pada pilihan ini:

• kemampuan untuk merekam hubungan antara banyak-ke-banyak tugas;
• fleksibilitas pengaturan untuk versi kotak;
• menyimpan sejarah semua perubahan dalam proyek;
• sebagian arsitektur terbuka, kemungkinan penyempurnaan untuk kebutuhan Anda sendiri;
• kemampuan untuk berinteraksi dengan sistem eksternal yang telah digunakan oleh tim proyek (SharePoint, Git, SVN, dll.);
• kemampuan untuk digunakan di server Anda (untuk proyek tertutup);
• kehadiran di unit karyawan yang memiliki pengalaman signifikan dalam mengelola sistem ini dan tertarik untuk menyatukan aplikasi.

Secara historis, JIRA versi 6.4 diambil untuk digunakan dalam pekerjaan, namun, elemen individual dari solusi yang diterapkan pada versi ini dalam proyek kami sebagian muncul di versi JIRA baru di luar kotak (yang secara tidak langsung mengkonfirmasi kebenaran keputusan yang dibuat).

Otomatisasi manajemen proyek awalnya mengejar tujuan-tujuan berikut:

• meningkatkan kualitas tidur karyawan tim proyek (seperti yang Anda tahu, orang yang beristirahat bekerja jauh lebih efisien);
• memastikan distribusi tanggung jawab yang transparan untuk pelaksanaan tugas-tugas proyek;
• menyediakan "multithreading" dari tim proyek, mis. memparalelkan pekerjaan sedapat mungkin;
• untuk menyediakan formasi otomatis dari keadaan saat ini mengenai implementasi dari masing-masing persyaratan pelanggan;
• menyediakan pemantauan keadaan proyek saat ini, memungkinkan untuk mengidentifikasi masalah dan risiko proyek pada tahap awal;
• untuk membentuk pendekatan umum untuk akuntansi, metode untuk menilai dan membandingkan status berbagai proyek pengembangan perangkat lunak (mirip dengan layanan Google Analytics atau Yandex.Metrica , yang memungkinkan Anda untuk mengevaluasi situs mana pun dengan indikator yang sama);
• untuk meningkatkan akurasi memperkirakan waktu tugas, berdasarkan statistik yang dikumpulkan.

Untuk menghindari "otomatisasi untuk otomatisasi", pertimbangan (batasan) berikut ini juga dipertimbangkan ketika merancang model akuntansi data di JIRA:

Otomatisasi manajemen proyek tidak boleh mengganggu tim proyek. Mempertimbangkan pengalaman negatif sebelumnya dalam otomatisasi manajemen proyek, salah satu faktor implementasi utama adalah penciptaan kondisi sedemikian rupa sehingga setiap karyawan tim proyek memandang JIRA bukan sebagai beban tambahan di kapal proyek, tetapi sebagai sistem navigasi kolektif yang akan memberi tahu tim secara tepat waktu tentang bahaya yang akan terjadi dan membantu mencapai tujuan. memproyeksikan dengan cara terpendek dan teraman. Selain itu, penggunaan sistem navigasi ini harus memfasilitasi kehidupan semua anggota tim, dan bukan hanya manajemen proyek. Untuk melakukan ini, awalnya prosedur untuk bekerja dengan JIRA direncanakan dengan mempertimbangkan minimalisasi jumlah data yang direkam oleh programmer, penguji dan penulis teknis. Di sisi lain, tujuannya adalah untuk menciptakan lingkungan kerja yang nyaman di JIRA untuk semua karyawan proyek, yang akan membantu mereka memastikan perencanaan yang efektif untuk hari kerja mereka.

Jaminan kontinuitas. Salah satu tujuan otomatisasi manajemen proyek adalah untuk memastikan kesinambungan sehingga setiap karyawan yang memenuhi syarat dapat "mengambil" tanggung jawab anggota tim pensiunan tanpa "masa percobaan" dan dengan sakit kepala minimum, sehingga "pasukan tidak melihat kehilangan seorang pejuang." Dalam hal ini, saya mengingat suatu kasus yang dikatakan salah seorang pelanggan kepada saya. Begitu ia tinggal untuk bos, yang, setelah pergi berlibur, memberi tahu dia kata sandi dari komputernya dengan replika: "Ya, semuanya sudah jelas di sana, Anda akan mengetahuinya jika terjadi sesuatu ...". Karyawan ini menghabiskan beberapa malam tanpa tidur untuk memahami isi beberapa folder dengan nama "xxxxx1", "xxxxx11" dan "xxxxx111" (nama-nama folder telah diubah untuk kepentingan kesopanan). Pencegahan situasi semacam itu membutuhkan pendaftaran hasil pekerjaan semua karyawan tim proyek, termasuk manajer proyek, dengan JIRA.

Minimalisme Tujuan otomatisasi manajemen proyek bukanlah untuk menghitung, dalam satu menit, berapa banyak karyawan tertentu menghabiskan waktu bekerja untuk menyelesaikan tugas-tugas yang diberikan kepadanya, tetapi untuk memastikan bahwa tugas-tugas dengan kualitas yang diberikan diselesaikan dalam waktu yang diperlukan. Oleh karena itu, ketika menggunakan proyek di JIRA, prinsip meminimalkan data yang direkam dalam sistem diadopsi. Yaitu set parameter yang dicatat dalam sistem kontrol seminimal mungkin diperlukan untuk membuat keputusan berdasarkan informasi (" Kesempurnaan dicapai bukan ketika tidak ada yang ditambahkan, tetapi ketika tidak ada yang dihapus "). Dapat dipahami bahwa model otomatisasi manajemen proyek yang diadopsi harus bekerja dalam kondisi ketidakpastian dan inkonsistensi yang tinggi (misalnya, Anda dapat mengetahui tanggal dokumen, tetapi tidak tahu nomornya dan sebaliknya). Saat mengetik informasi yang direkam, kami menggunakan, jika memungkinkan, aturan Miller , yang menyatakan bahwa jumlah tipe (status) yang optimal harus berada di dalam "tujuh plus atau minus dua" (yang sangat menyederhanakan pemahaman kerja sistem oleh karyawan). Jadi, misalnya, ketika merancang siklus hidup tugas (alur kerja), pada awalnya diasumsikan bahwa jumlah negara harus mematuhi aturan ini.

Konsistensi. Otomatisasi manajemen proyek harus berkontribusi pada koherensi dan koherensi tindakan semua karyawan tim proyek (mencegah situasi "angsa, kanker, dan tombak").

Dalam salah satu proyek di mana saya kebetulan berpartisipasi, tim analis mengembangkan model aktivitas otomatis dalam notasi IDEF0 dalam waktu satu bulan. Tampaknya penggunaan metodologi yang dibuat oleh Angkatan Udara AS (!) Menjamin keberhasilan pendekatan ini. Namun, ketika kepala departemen pemrograman mempelajari laporan analitis multi-halaman, pertanyaan pertamanya adalah: "Jadi, apa sebenarnya yang perlu dilakukan?". Model yang dihasilkan ternyata tidak cocok untuk digunakan sebagai deskripsi pernyataan masalah untuk programmer. Perwakilan pelanggan beberapa kali dikagumi, berhemat melalui banyak skema, tetapi juga tidak menemukan aplikasi model ini untuk mengoptimalkan kegiatan mereka. Pada akhirnya, skema ini menghiasi deskripsi proses teknologi, memberikan dokumen ini ketebalan dan soliditas yang belum pernah terjadi sebelumnya, tetapi efek positif dari analisis telah habis pada ini. Hasil bulan kerja beberapa analis hampir tidak diklaim oleh proyek.

Mengingat pengalaman ini, ketika mengotomatisasi manajemen proyek, ia seharusnya membuat konveyor tugas tunggal yang akan memastikan konversi terkoordinasi dari persyaratan pelanggan menjadi produk perangkat lunak akhir dengan cara sesingkat mungkin dan dengan biaya minimal. Selain itu, berdasarkan pemantauan parameter yang tersedia dari konveyor ini, ia seharusnya mengidentifikasi, mengukur, dan mengembangkan sifat-sifat yang muncul dari tim proyek, yang memungkinkan untuk menilai keadaan proyek pada semua tahapannya.

Papan kanban dalam ke luar

Menurut pendapat saya, keberhasilan otomatisasi kontrol sebagian besar tergantung pada seberapa akurat objek kontrol dimodelkan dalam sistem otomatis.Karena seharusnya mengotomatisasi pengelolaan proses pembuatan perangkat lunak, analisis proses ini dilakukan. Menurut pendapat saya, proses membuat modul perangkat lunak yang terpisah selalu mewakili siklus air terjun terjun klasik. Pertama, daftar persyaratan untuk produk yang dibuat muncul. Persyaratan dapat berasal dari sumber yang berbeda dan memiliki berbagai tingkat detail. Beberapa persyaratan saling berhubungan, bagian lain relatif independen. Untuk persyaratan individual, Anda dapat segera merumuskan tugas pengembangan, sementara yang lain memerlukan klarifikasi dan konkretisasi. Yaituselalu ada pekerjaan yang berkaitan dengan pengumpulan, pemilahan dan klarifikasi persyaratan pelanggan (sementara kata-kata dari persyaratan individu mungkin ambigu hingga akhir proyek). Setelah persyaratan sespesifik mungkin, sebagai aturan, apa yang disebut definisi tugas dibentuk untuk kelompok persyaratan yang saling terkait, yang merinci spesifikasi pelaksanaan persyaratan ini dan merupakan bahan sumber bagi pemrogram untuk mulai bekerja. Setelah pemrograman, modul yang dibuat diuji secara mandiri, diintegrasikan ke dalam sistem, dan diuji ulang. Menurut pembaruan perangkat lunak yang selesai, perubahan yang sesuai dilakukan pada desain dan dokumentasi operasional, setelah itu sejumlah kegiatan dilakukan,bertujuan untuk mengenali penyelesaian yang dibuat oleh aspirasi (persyaratan) pelanggan dan implementasi selanjutnya dari fungsi yang dikembangkan dalam operasi komersial.

Sumber

Perbedaan utama antara kehidupan nyata dan skema air terjun yang indah adalah keacakannya (semuanya terjadi tidak secara bertahap dan tidak konsisten). Pada kenyataannya, transisi dari satu fase pengembangan ke fase lainnya tidak harus terjadi hanya setelah penyelesaian fase sebelumnya yang lengkap dan berhasil. Air terjun yang sesungguhnya memiliki bendungan kontradiksi, bendungan dan dangkal ketidakpeduliannya sendiri, rawa-rawa bertele-tele, jeram dan pusaran ambiguitas, jeram dan batu-batu licin dari imajinasi yang tak terkendali, dan seringkali air mancur dan bahkan geyser dari persyaratan baru. Tidak dimungkinkan untuk membuat kembali elemen ini dalam kerangka kerja proyek, seperti halnya tidak mungkin bagi tim kapal untuk membuat kembali sungai di mana perlu untuk memastikan pengiriman kargo pelanggan.

Untuk transparansi distribusi tanggung jawab dalam otomatisasi manajemen proyek, prinsip "1 tugas - 1 pelaksana" diterapkan. Yaituproses menyelesaikan tugas jelas tidak menyiratkan transfernya ke pemain lain. Prinsip ini memungkinkan untuk menerapkan proses bisnis yang sama untuk semua jenis tugas, karena status pekerjaan ditentukan terutama dari sudut pandang pelaku tugas ini. Alur kerja JIRA standar telah sedikit dimodifikasi. Perubahan utama adalah penggantian status "ditemukan kembali" dengan status "tertunda", yaitu. menyatakan saat mengerjakan tugas ditangguhkan karena alasan apa pun. Untuk mendaftarkan tugas yang ditemukan kembali, bidang pengguna "Penghitung penemuan kembali" telah digunakan. Pada saat yang sama, jenis alasan untuk pengalihan tugas dalam mengantisipasi solusi dirinci:

• koordinasi dengan pelanggan;
• meminta informasi tambahan dari pelanggan;
• menunggu solusi dari tugas / subtugas terkait;
• klarifikasi pernyataan masalah diperlukan.

Perlu dicatat bahwa pengenalan status "ditahan" sebenarnya menerapkan " tombol penghenti konveyor " untuk karyawan tim proyek , yang pada gilirannya memastikan identifikasi kolektif masalah pada tahap awal proyek.

Sebagai hasil dari analisis, model berikut untuk mendaftarkan informasi proyek dengan JIRA diimplementasikan. Pendekatan pembagian tugas standar yang diwakili JIRA tidak digunakan dalam proyek. Enam jenis tugas telah dibuat, yang intinya berhubungan dengan tahapan utama pengembangan perangkat lunak:

1. “Persyaratan” - jenis tugas untuk mendaftarkan persyaratan pelanggan (serupa dengan versi baru JIRA - epik);
2. «» – , ( ) ( ) ( JIRA – story);
3. «» – ;
4. «» – , ;
5. «» – , ;
6. "Implementasi" adalah jenis tugas untuk merekam hasil pekerjaan yang bertujuan memperkenalkan perangkat lunak yang dikembangkan ke dalam kegiatan pelanggan (melakukan tes, demonstrasi, merilis rilis / patch / perbaikan data, menyebarkan perangkat lunak di server pelanggan, melatih pengguna, dll.).

Subtasks digunakan untuk memecahkan masalah tertentu (waktu yang tidak melebihi dua jam) selama pelaksanaan tugas utama (misalnya, untuk mengoordinasikan keputusan desain dengan programmer atau manajer proyek, melakukan tinjauan kode, menyiapkan data uji, dll.).

Sesuai dengan aturan yang ditetapkan pada proyek, pendaftaran persyaratan merupakan dasar wajib untuk merencanakan tugas-tugas lain. Setelah pendaftaran persyaratan dan klarifikasi dengan pelanggan (jika perlu), jenis tugas lain dibentuk, yang bertujuan untuk mengimplementasikan persyaratan ini. Dengan kata lain, dalam kerangka model yang diadopsi, tugas-tugas lain harus selalu dikaitkan dengan persyaratan untuk kepentingan yang mereka dipenuhi (menggunakan jenis koneksi "penyebab" -> "tindakan"). Untuk kepentingan penerapan satu persyaratan, beberapa tugas pengembangan dapat dibuat, di sisi lain, satu tugas (untuk analisis, pengembangan, pengujian, dokumentasi, implementasi) dapat dibuat untuk kepentingan beberapa persyaratan (berbeda dengan pendekatan JIRA standar, ketika diasumsikanbahwa tugas hanya dapat dikaitkan dengan satu tugas tipe epik). Dalam kerangka model yang diusulkan, juga dimungkinkan untuk menghubungkan tugas-tugas dependen lainnya. Di satu sisi, pendekatan ini memastikan konsistensi keputusan yang diambil, di sisi lain, memberikan kemungkinan refleksi yang cukup akurat dari keadaan sebenarnya dari proyek. Dalam hal ini, berbagai pilihan untuk mengatur pekerjaan dimungkinkan, untuk memahami kebingungan yang tampaknya sangat sulit.


Metode untuk merefleksikan tugas-tugas yang ditemukan di JIRA tidak memberikan pandangan yang nyaman tentang keadaan proyek secara keseluruhan (mengingat berbagai plug-in, mungkin kita hanya tidak punya cukup waktu untuk menemukan yang diperlukan). Oleh karena itu, untuk menyederhanakan pekerjaan dengan model yang diusulkan untuk mendaftarkan tugas, dasbor kami dibuat (pada akhirnya, pembuat sepatu harus dapat menjahit sepatu bot untuk dirinya sendiri). Dasbor yang dibuat memungkinkan untuk menampilkan status tugas pada proyek dari sudut pandang penerapan setiap persyaratan secara terpisah.

Dasbor yang dibuat, pada pandangan pertama, sedikit berbeda dari papan Kanban klasikNamun, dalam kasus kami, kolom tidak berarti status tugas, tetapi jenisnya. Di dasbor ini, garis terpisah dibentuk untuk setiap persyaratan, di mana semua tugas yang terkait dengan persyaratan ini dikelompokkan berdasarkan aktivitas (dalam urutan klasik air terjun). Jika tugas itu dibuat untuk memenuhi beberapa persyaratan, maka kartu tugas ini diulangi di setiap baris persyaratan terkait. Status tugas tercermin di dasbor ini dengan warna yang menciptakan "dimensi ketiga". Tingkat kesiapan persyaratan ditentukan dalam hal ini oleh kesiapan semua tugas yang terkait dengan persyaratan ini. Ternyata seperti papan Kanban terbalik. Di sisi lain, dari posisi PMBOK,dasbor yang dihasilkan adalah versi yang disempurnakan dari Matriks Ketertelusuran Persyaratan klasik.


Untuk menampilkan status tugas, skema warna berikut diadopsi:

• biru - tugas dimasukkan dalam rencana kerja;
• biru - tugas sedang berlangsung;
• pink - tugas tidak memiliki eksekutor;
• kuning - tugas tertunda, membutuhkan solusi;
• abu-abu - tugas ditutup (Anda bisa melupakannya);
• oranye - tenggat waktu untuk menyelesaikan tugas terganggu.

Munculnya prasasti merah dan tanda pada kartu tugas menandakan perlunya tindakan segera dalam kaitannya dengan tugas (misalnya, prasasti ditampilkan dalam warna merah jika tenggat waktu belum ditetapkan).

Selain warna, seiring proyek berkembang, kartu tugas di dasbor dikelilingi oleh tag tambahan yang memungkinkan Anda untuk menilai sekilas status pekerjaan proyek tersebut.

Label prioritas:

- Normal;

- penting;

- kritis;

- memblokir.

Label tentang kerangka persyaratan:

- pengembangan (persyaratan dalam kerangka proyek yang ditujukan untuk revisi substansial sistem yang ada);

- dukungan tambahan (persyaratan untuk penyelesaian operasional modul sistem individu untuk perubahan saat ini dalam proses bisnis pelanggan);

- dukungan garansi (kesalahan perangkat lunak terdeteksi);

- kegiatan non-proyek (persyaratan manajer proyek terkait dengan kegiatan pra-proyek, refactoring , presale , pengembangan teknologi baru, pelatihan staf, dll.).

Label alasan untuk harapan:

- permintaan informasi tambahan dari pelanggan;

- koordinasi dengan pelanggan;

- menunggu solusi tugas / subtugas terkait;

- klarifikasi formulasi diperlukan.

Tag khusus:

- database telah diselesaikan dalam tugas;

- jumlah persyaratan yang terkait dengan tugas (semakin banyak persyaratan terkait, semakin penting tugas tersebut);

- jumlah subtugas yang belum terselesaikan;

- tugas ditemukan kembali.

Bahkan, dasbor ini telah menjadi alat utama untuk setiap hari menerima jawaban atas pertanyaan manajemen proyek: "Apa yang paling penting saat ini?", Yang pada gilirannya memungkinkan kita untuk merespons masalah secara tepat waktu. Dari perspektif model yang diusulkan, untuk mencegah masalah pada proyek, perlu untuk memastikan pengurangan harian dalam jumlah merah, oranye dan kuning di dasbor yang diusulkan. Di sisi lain, penyebab kekhawatiran juga adalah kurangnya tugas terkait untuk persyaratan (yaitu, situasi ketika persyaratan direncanakan dan tidak ada pekerjaan untuk mengimplementasikannya).

Menggunakan filter untuk dasbor yang dibuat memungkinkan di kompleks untuk mencerminkan keadaan sesuai dengan daftar persyaratan yang dipilih. Dengan bantuannya, dimungkinkan untuk dengan cepat mengoordinasikan tindakan seluruh tim proyek, memfokuskan upaya pada bidang yang paling bermasalah, sementara tidak kehilangan gambaran holistik proyek.

Air Terjun Tidak Bisa Agile

Untuk kepentingan mencatat hasil pekerjaan pada semua jenis tugas, dua repositori ditempatkan (untuk dokumentasi proyek dan untuk kode perangkat lunak). Menambahkan (mengubah) materi dalam repositori ini secara otomatis tercermin dalam tugas terkait JIRA dan merupakan jenis utama pelaporan oleh pelaku.

Organisasi kerja menggunakan pendekatan yang diusulkan untuk mendaftarkan tugas di JIRA dikurangi menjadi skema berikut.

1. JIRA ( ) . (, ) . (/), . , ( , ), , ( ) . ( ) . .
2. , . , , , . () .
3. , , . , , ( ), () , , , ( ).
4. ( ) , , . . , . «» , ( ).
5. Idealnya, tugas pengujian harus dibentuk sebelum mendaftarkan tugas pengembangan (yang menentukan tujuan pemrogram). Selama pengujian, penguji yang bertanggung jawab tidak hanya menyimpan catatan kesalahan yang terdeteksi, tetapi juga memperbaiki ketidakakuratan yang terdeteksi dalam tugas pengujian dan panduan pengguna.
6. Menurut persyaratan, berdasarkan daftar pekerjaan yang direncanakan, tugas implementasi dibentuk (selama pendaftaran yang prioritas dan tenggat waktu untuk implementasi persyaratan ditentukan lagi dalam JIRA).
7. Setelah pengiriman ke pelanggan, permintaan dapat ditransfer ke status "tertutup" dengan indikasi wajib dari rincian dokumen penerimaan.

Perlu dicatat bahwa pembentukan tugas dari semua jenis untuk pelaksanaan persyaratan tunggal bukanlah prasyarat untuk perencanaan yang sukses. Misalnya, persyaratan sederhana seperti "memperbaiki kesalahan dalam nama bidang" dapat diberikan langsung ke programmer. Pada saat yang sama, selama pelaksanaan proyek, dicatat bahwa bagian terbesar dari komentar selama tes pendahuluan dan operasi uji coba menyumbang persyaratan di mana keputusan desain tidak dibentuk.

Dalam kerangka pendekatan yang diusulkan, perencanaan kerja menggunakan metode Rolling Wave Planning telah membuktikan dirinya dengan baik. Pada saat yang sama, sebagian karena dashboard yang dijelaskan di atas, adalah mungkin untuk menghindari fragmentasi dan ketidakkonsistenan dari pekerjaan yang direncanakan. Pada tahap awal pendaftaran, pemilihan sesuai dengan persyaratan menyerupai payung merah , ketika untuk sebagian besar persyaratan tanggal ketersediaan dan eksekutif yang bertanggung jawab tidak ditentukan, dan pekerjaan direncanakan hanya untuk sebagian kecil dari mereka. Namun, dashboard persyaratan secara bertahap berubah menjadi karpet biru-hijau. Bintik-bintik merah dan oranye yang muncul di karpet ini memaksa kami untuk melakukan penyesuaian harian terhadap tugas yang dimaksud, yang membantu mengurangi risiko proyek.

Model organisasi data yang diusulkan menunjukkan skalabilitas yang baik. Awalnya, hanya tiga karyawan dari tim proyek (satu analis dan dua programmer) yang menggunakan JIRA dalam pekerjaan mereka, sementara persyaratan untuk masing-masing subsistem dicatat. Namun, pada akhir proyek, 100% persyaratan pengembangan dan dukungan tambahan didaftarkan dan dipantau di JIRA dengan partisipasi semua karyawan tim proyek.

Terlepas dari kenyataan bahwa gagasan otomatisasi manajemen proyek didasarkan pada model pengembangan kaskade (air terjun), ternyata dalam kerangka pendekatan yang diusulkan, jika diinginkan, elemen Agile dapat digunakan tanpa rasa sakit. Dan siapa, secara umum, yang mengatakan bahwa air terjun itu tidak fleksibel? Misalnya, untuk menerapkan Scrum , dalam kerangka model yang diusulkan, cukup untuk memastikan keteraturan acara (tugas) untuk implementasi perangkat lunak, dan kemudian, oleh karena itu, semua pekerjaan yang terkait dengan acara ini akan "dipaksa" untuk mematuhi aturan sprint yang ditetapkan dengan cara ini.

Selain itu, metode yang diusulkan untuk mendaftarkan tugas tidak membatasi manajer proyek dalam menerapkan pendekatan Kanban dan menggunakan seluruh variasi Agile dashboard yang ditawarkan JIRA “out of the box”.

Untuk dilanjutkan

Apa hasilnya? Perangkat lunak yang dikembangkan telah dimasukkan ke dalam operasi komersial. Selama tes pendahuluan, operasi uji coba dan tes penerimaan, pelanggan mencatat banyak komentar pada produk perangkat lunak yang diimplementasikan. Namun, kemudian, berdasarkan bahan untuk mengklarifikasi persyaratan yang disimpan di JIRA, pelanggan dipaksa untuk mengenali 25% dari komentar sebagai persyaratan baru yang melampaui ruang lingkup proyek (kompleksitas yang direncanakan untuk memenuhi persyaratan ini sepadan dengan tugas teknis yang diselesaikan). Masalah-masalah yang terkait dengan pelaksanaan kontrak untuk pesanan negara tidak hilang, namun, pemantauan kepatuhan terhadap persyaratan menggunakan JIRA memungkinkan untuk mengidentifikasi risiko gangguan pada tahap inisiasi dan untuk meresponsnya dengan cepat. Ini, pada gilirannya, memastikan dinamika positif proyek di semua tahapannya, meskipun ada kekhasan pengembangan perangkat lunak nasional. Tercatat bahwa jika persyaratan pelanggan didaftarkan pada JIRA dan tugas untuk analisis, pengembangan dan pengujian dibentuk atas mereka, maka ada jauh lebih sedikit ketidaksepakatan dan perselisihan mengenai persyaratan tersebut.

Pada tahap saat ini (tahap pemeliharaan), semua persyaratan tercermin dalam JIRA. Semua karyawan tim proyek dengan satu atau lain cara menggunakan JIRA dalam pekerjaan mereka. Biaya programmer untuk mendaftarkan hasil pekerjaan mereka di JIRA membutuhkan waktu kurang dari 1% dari waktu kerja mereka. Untuk analis, sebaliknya, JIRA telah menjadi salah satu alat kerja utama. Menemukan serangkaian informasi lengkap untuk semua persyaratan pelanggan kurang dari satu menit. Dokumen pelaporan berdasarkan hasil pekerjaan yang dilakukan dihasilkan secara otomatis berdasarkan data yang terkandung dalam JIRA. Juga, berdasarkan data ini, dokumentasi yang menyertai untuk rilis terbentuk (daftar perubahan dan program uji rilis).

Dua tahun pengalaman menerapkan JIRA di bawah aturan baru telah mengkonfirmasi kebenaran lama:

• JIRA tidak menggantikan manajemen proyek, tetapi membantu untuk dengan cepat menavigasi aliran tugas yang beragam;
• JIRA akan membantu Anda memfokuskan proyek Anda di tempat yang tepat pada waktu yang tepat, tetapi itu tidak akan melakukannya untuk Anda;
• JIRA tidak akan menyelesaikan masalah proyek untuk Anda, tetapi akan membantu untuk mengidentifikasi mereka sudah pada tahap awal (pada saat yang sama, itu akan mengidentifikasi masalah-masalah yang ingin Anda sembunyikan);
• seperti sistem otomatis apa pun, JIRA akan membantu Anda dengan cepat mengimplementasikan salah satu keputusan Anda, terlepas dari apakah itu baik atau buruk;
• JIRA tidak menggantikan komunikasi karyawan tim proyek, tetapi akan membantu menyelesaikan perselisihan tanpa rasa sakit;
• JIRA tidak akan menyelamatkan karyawan dari pemecatan, tetapi akan membantu orang lain, yang telah menggantikan posisi pensiunan, dengan cepat mengetahui;
• JIRA akan membantu membuat dokumen pelaporan proyek, tetapi hanya berdasarkan informasi yang Anda berikan registrasi.

Dan yang paling penting - JIRA tidak akan memutuskan untuk Anda apakah Anda akan menggunakan bantuannya atau tidak.

Pekerjaan LANIT untuk tertarik