Dari penerjemah: ini adalah Panduan DIB: Mendeteksi Agile BS (versi 0.4) , yang diterbitkan oleh Komite Inovasi Pertahanan Departemen AS (DIB) secara publik pada tanggal 9 Oktober 2018.

Agile adalah kata kunci dalam pengembangan perangkat lunak, sehingga semua proyek perangkat lunak Kementerian Pertahanan sekarang hampir "fleksibel" secara default. Dokumen ini akan membantu manajer program dan spesialis Kementerian Pertahanan membedakan proyek perangkat lunak dengan metodologi yang benar-benar fleksibel dari proyek yang hanya menggunakan "air terjun" atau "spiral" ("agile-scrum-fall") dengan kedok Agile.

Prinsip, Nilai, dan Alat

Para pakar dan penggemar tangkas mengidentifikasi metrik kunci yang menjadi ciri budaya ini dan pendekatan untuk pengembangan tangkas. Dalam pekerjaannya, DIB telah mengembangkan pedomannya sendiri yang secara kasar mencerminkan nilai-nilai Agile yang sebenarnya:

Nilai Agile	Prinsip DIB
Individu dan interaksi lebih penting daripada proses dan alat	“Kompetensi lebih penting daripada proses”
Menjalankan perangkat lunak lebih penting daripada dokumentasi lengkap	“Kurangi waktu dari awal proyek hingga penyebaran fungsi dasar yang paling sederhana”
Kolaborasi dengan klien untuk menyetujui kontrak	“Implementasi budaya DevSecOps untuk sistem perangkat lunak”
Menanggapi perubahan rencana	“Program-program harus dimulai dari yang kecil, berulang-ulang, dan membangun kesuksesan - atau mereka dengan cepat dibatalkan.”

Tanda-tanda utama bahwa proyek ini tidak terlalu fleksibel:

• Tidak ada tim pengembangan yang berkomunikasi dengan pengguna atau melacak perangkat lunak yang sedang beraksi; kami maksudkan pengguna nyata dari kode nyata . (Departemen evaluasi program tidak dianggap pengguna nyata, seperti petugas senior, kecuali ia menggunakan program itu dalam pekerjaannya). Alternatif yang dapat diterima untuk komunikasi dengan pengguna: memantau pekerjaan mereka, memberikan prototipe kepada mereka untuk umpan balik dan metode penelitian lain yang tidak melibatkan banyak komunikasi verbal.
• Tidak ada umpan balik konstan dari pengguna untuk tim pengembangan (laporan bug, peringkat). Tidak cukup hanya berbicara sekali di awal proyek untuk memeriksa persyaratan!
• Kepatuhan dianggap lebih penting daripada mendapatkan hasil yang paling tidak berguna secepat mungkin.
• Stakeholder (pengembangan, pengujian, DevOps, keamanan, kontraktor, pengguna akhir, dll) beroperasi kurang lebih secara mandiri (misalnya, "ini bukan bisnis saya").
• Pengguna akhir tidak terlibat dalam pengembangan; minimal, mereka harus hadir selama perencanaan rilis dan pengujian penerimaan.
• Tidak ada cukup budaya DevSecOps ketika proses yang dapat dan harus otomatis dijalankan secara manual (misalnya, pengujian, integrasi berkelanjutan, pengiriman berkelanjutan).

Beberapa alat pengembangan tangkas khas (mereka berubah sebagai
penampilan yang terbaik):

• Git, ClearCase, atau Subversion adalah sistem kontrol versi untuk melacak perubahan dalam kode sumber. Git adalah standar de facto dalam perkembangan modern.
• BitBucket atau GitHub - hosting repositori. Ini juga melacak tiket, memiliki "aplikasi" untuk integrasi berkelanjutan dan alat-alat lain untuk meningkatkan produktivitas. Banyak digunakan oleh komunitas open source.
• Jenkins, Circle CI atau Travis CI adalah layanan integrasi berkelanjutan untuk membangun dan menguji proyek Bitbucket dan GitHub.
• Chef, Ansible or Puppet - perangkat lunak untuk membuat "resep" untuk konfigurasi dan menyiarkan tugas konfigurasi dan dukungan ke sejumlah server.
• Docker adalah program komputer yang melakukan virtualisasi di tingkat sistem operasi, juga dikenal sebagai containerisasi.
• Kubernetes atau Docker Swarm untuk orkestrasi wadah.
• Jira atau Pivotal Tracker - tiket, pemantauan dan manajemen.

Versi grafis:

Pertanyaan untuk pengembang

• Bagaimana Anda menguji kode? (Jawaban salah: "Kami memiliki organisasi khusus untuk pengujian", "Departemen pengujian dan evaluasi produk bertanggung jawab untuk pengujian")
  
  • Versi lanjutan: seperangkat alat apa yang Anda gunakan untuk pengujian unit, pengujian regresi, tes fungsional, pemindaian keamanan, dan sertifikasi penempatan?
• Seberapa otomatis jaringan pengembangan, pengujian, keamanan, dan penyebaran?
  
  • Versi lanjutan: seperangkat alat apa yang Anda gunakan untuk integrasi berkelanjutan (CI), pengiriman berkelanjutan (CD), pengujian regresi, dokumentasi program; Apakah infrastruktur Anda digerakkan oleh kode?
• Siapa pengguna Anda dan bagaimana Anda berinteraksi dengan mereka?
  
  • Versi lanjutan: mekanisme apa yang Anda gunakan untuk mendapatkan umpan balik langsung dari pengguna? Perangkat apa yang Anda gunakan untuk membuat laporan bug dan melacak tiket? Bagaimana Anda mendistribusikan pekerjaan perbaikan bug antar tim? Bagaimana Anda memberi tahu pengguna bahwa masalah mereka sedang diselesaikan dan / atau sudah diselesaikan?
• Apa batas waktu untuk siklus rilis saat ini dan masa depan?
  
  • Versi lanjutan: platform perangkat lunak apa yang Anda dukung? Apakah Anda menggunakan wadah? Apa alat manajemen konfigurasi Anda?

Pertanyaan untuk manajer proyek

• Berapa banyak programmer yang merupakan bagian dari organisasi yang mengalokasikan anggaran, dan apa tahapan utama program? (Jawaban salah: "Kami tidak tahu", "Nol", "Itu tergantung pada definisi seorang programmer")
• Apa itu metrik manajemen untuk pengembangan dan operasi; bagaimana mereka digunakan untuk mengomunikasikan prioritas, mengidentifikasi masalah; seberapa sering mereka melihat dan menggunakan manual?
• Apa yang telah Anda pelajari dalam tiga sprint terakhir dan bagaimana menerapkan pengetahuan baru? (Jawaban yang salah: "Apa itu sprint?", "Kami sedang menunggu persetujuan dari kepemimpinan")
• Siapa pengguna yang mendapat manfaat dari setiap siklus sprint? Bisakah saya berbicara dengan mereka? (Jawaban salah: "Kami tidak menyebarkan kode secara langsung untuk pengguna")

Pertanyaan untuk pelanggan dan pengguna

• Bagaimana Anda berkomunikasi dengan pengembang? Apakah mereka mengawasi pekerjaan Anda dan mengajukan pertanyaan yang relevan yang menunjukkan pemahaman mendalam tentang kebutuhan Anda? Kapan terakhir kali mereka duduk di dekatnya dan mendiskusikan fitur yang ingin Anda lihat?
• Bagaimana cara mengirim saran untuk fitur baru atau melaporkan masalah atau bug dalam kode? Umpan balik apa yang Anda terima untuk pertanyaan / laporan Anda? Pernahkah Anda diminta untuk mencoba prototipe fitur perangkat lunak baru dan telah menyaksikan bagaimana Anda menggunakannya?
• Berapa lama untuk mengimplementasikan fungsi yang diminta dalam aplikasi?

Pertanyaan untuk panduan

• Apakah versi perangkat lunak yang berfungsi dikirimkan ke setidaknya sejumlah kecil pengguna nyata di setiap iterasi (termasuk yang pertama) dan apakah ulasan dikumpulkan? (petunjuk: setiap dua minggu)
• Apakah ada piagam produk yang menetapkan misi dan tujuan strategis? Apakah semua anggota tim mengerti keduanya? Apakah mereka melihat bagaimana pekerjaan mereka berkontribusi pada pencapaian tujuan?
• Apakah ulasan pengguna berubah menjadi tugas khusus untuk tim sprint dengan tenggat waktu kurang dari sebulan?
• Apakah tim berwenang untuk mengubah persyaratan berdasarkan umpan balik pengguna?
• Apakah tim memiliki hak untuk mengubah proses mereka berdasarkan apa yang mereka pelajari selama pengembangan?
• Apakah seluruh ekosistem proyek Anda fleksibel? (Jika pengembangan gesit diikuti oleh proses implementasi birokratis yang linier, ini adalah kegagalan.)

Untuk tim Agile, jawaban untuk semua pertanyaan ini harus ya.

Versi grafis:



Informasi yang lebih terperinci tentang beberapa fungsi dari program-program Kementerian Pertahanan terdapat dalam Lampiran A ( Sepuluh Persyaratan Perangkat Lunak ), Lampiran B ( Metrik untuk Pengembangan Perangkat Lunak ) dan Lampiran C (Kesalahan dan Aturan Perangkat Lunak [tautan akan ditambahkan kemudian] )