BAB 3

AGILE SOFTWARE DEVELOPMENT

Pengembangan Software Yang Cepat

Perkembangan yang cepat dan pengiriman saat ini adalah kebutuhan yang paling
penting untuk sistem software

Bisnis beroperasi secara cepat, persyaratan berubah dan itu hampir mustahil untuk
menghasilkan satu set persyaratan software yang stabil

Software memiliki perkembangan yang cepat untuk mencerminkan perubahan

kebutuhan bisnis.
Pengembangan plan-driven penting untuk beberapa jenis sistem, tetapi tidak memenuhi
kebutuhan bisnis tersebut.
Metode pengembangan Agile muncul di akhir 1990-an yang bertujuan untuk
mengurangi waktu pengiriman secara radikal untuk kerja sistem software.

Agile Development

Spesifikasi program, desain dan implementasi yang disisipkan.

Sistem ini dikembangkan sebagai serangkaian versi atau bertahap dengan para
pemangku kepentingan yang terlibat dalam spesifikasi dan evaluasi versi
Pengiriman sering menggunakan versi baru untuk evaluasi.
Dukungan alat secara luas (misalnya alat pengujian otomatis) digunakan untuk
mendukung pembangunan.
Minimal dokumentasi - fokus pada kode bekerja

Plan-Driven And Agile Development

Plan-driven

and

agile development

Plan-driven development

plan-driven didorong untuk rekayasa software berbasis di sekitar tahap

perkembangan terpisah dengan output yang akan dihasilkan pada setiap tahap dan
direncanakan terlebih dahulu.

Iterasi terjadi dalam kegiatan.

Agile Development
Spesifikasi, desain, implementasi dan pengujian saling berdaun dan output dari
proses pembangunan yang diputuskan melalui proses negosiasi selama proses
pengembangan software.
Agile Methods

Ketidakpuasan dengan overhead yang terlibat dalam metode desain software dari tahun
1980-an dan 1990-an menyebabkan penciptaan dari metode tangkas. Dengan metode :
Fokus pada kode daripada desain
Didasarkan pada pendekatan iteratif untuk pengembangan software
Dimaksudkan untuk memberikan software bekerja dengan cepat dan berkembang
dengan cepat untuk memenuhi perubahan kebutuhan.
Tujuan dari agile methods adalah untuk mengurangi overhead dalam proses software
(misalnya dengan membatasi dokumentasi) dan untuk dapat merespon dengan cepat
perubahan kebutuhan tanpa ulang berlebihan.

Manifesto Agile

Kami mengungkap cara yang lebih baik untuk mengembangkan software dengan
melakukan hal itu dan membantu orang lain melakukannya. Melalui karya ini kita telah
datang ke nilai:
Individu dan interaksi atas proses dan alat-alat
Softwate bekerja melalui dokumentasi yang komprehensif
Kolaborasi pelanggan lebih bernegosiasi

Menanggapi berubah dari rencana berikut

Penerapan Agile Methods

Pengembangan produk dimana sebuah perusahaan software mengembangkan produk

kecil atau menengah untuk dijual.
Hampir semua produk software dan aplikasi sekarang dikembangkan dengan
menggunakan pendekatan agile
Pengembangan sistem kustom dalam sebuah organisasi, di mana ada komitmen yang
jelas dari pelanggan untuk terlibat dalam proses pembangunan dan di mana ada aturan
eksternal sedikit dan peraturan yang mempengaruhi software.

Extreme programming

Sebuah metode yang sangat berpengaruh, dikembangkan pada akhir 1990-an, yang
memperkenalkan berbagai teknik pengembangan tangkas.
Extreme Programming (XP) mengambil pendekatan 'ekstrim' untuk pengembangan
berulang.

Versi baru dapat dibangun beberapa kali per hari;

Bertahap dikirim ke pelanggan setiap 2 minggu;

Semua tes harus dijalankan untuk setiap membangun dan membangun hanya
diterima jika tes berhasil.

The extreme programming release cycle

XP dan prinsip-prinsip agile

Pembangunan inkremental didukung melalui kecil, sistem rilis sering.

Keterlibatan pelanggan berarti penuh waktu keterlibatan pelanggan dengan tim.

Orang tidak memproses melalui pasangan pemrograman, kepemilikan kolektif dan

proses yang menghindari jam kerja yang panjang.
Perubahan didukung melalui siaran sistem yang teratur.
Mempertahankan kesederhanaan melalui refactoring konstan kode.

Peran Praktek XP

Ekstrim pemrograman memiliki fokus teknis dan tidak mudah untuk mengintegrasikan
dengan praktek manajemen dalam kebanyakan organisasi.
Akibatnya, sementara pengembangan tangkas menggunakan praktek dari XP, metode
sebagai awalnya didefinisikan tidak banyak digunakan.
Point Penting
Cerita pengguna untuk spesifikasi
Refactoring
Pengembangan tes pertama
Pasangan pemrograman

Pengembangan tes pertama

Pengujian merupakan pusat XP dan XP telah mengembangkan pendekatan di mana

program ini diuji setelah setiap perubahan telah dibuat.
Fitur pengujian XP:
Menguji pengembangan -Pertama.
Pengembangan tes tambahan dari skenario.
Keterlibatan pengguna dalam pengembangan tes dan validasi.

Pengembangan test-driven

Menulis tes sebelum kode menjelaskan persyaratan untuk dilaksanakan.

Tes tertulis sebagai program daripada data sehingga mereka dapat dijalankan secara
otomatis. Tes mencakup pemeriksaan yang telah dijalankan dengan benar.
Biasanya bergantung pada kerangka pengujian seperti JUnit.
Semua tes sebelumnya dan baru dijalankan secara otomatis ketika fungsi baru
ditambahkan, sehingga memeriksa bahwa fungsi baru belum diperkenalkan kesalahan.

Keterlibatan Pelanggan

Peran pelanggan dalam proses pengujian adalah untuk membantu mengembangkan tes
penerimaan untuk cerita yang akan dilaksanakan dalam rilis berikutnya dari sistem.
Para pelanggan yang merupakan bagian dari tim menulis tes sebagai hasil
pembangunan. Semua kode baru karena itu divalidasi untuk memastikan bahwa itu
adalah apa yang dibutuhkan pelanggan.
Namun, orang-orang mengadopsi peran pelanggan memiliki waktu terbatas yang
tersedia sehingga tidak dapat bekerja penuh waktu dengan tim pengembangan. Mereka
mungkin merasa bahwa memberikan persyaratan cukup dari kontribusi dan mungkin
enggan untuk terlibat dalam proses pengujian.

Masalah dengan pengembangan tes pertama

Programmer lebih suka memprogram untuk pengujian dan kadang-kadang mereka

mengambil jalan pintas ketika menulis tes. Sebagai contoh, mereka mungkin menulis
tes lengkap yang tidak memeriksa semua pengecualian yang mungkin terjadi.
Beberapa tes bisa sangat sulit untuk menulis secara bertahap. Misalnya, dalam
antarmuka pengguna yang kompleks, seringkali sulit untuk menulis unit test untuk kode
yang mengimplementasikan 'display logika' dan alur kerja antara layar.
Sulit untuk menilai kelengkapan serangkaian tes. Meskipun Anda mungkin memiliki
banyak tes sistem, set tes Anda tidak dapat memberikan cakupan yang lengkap.

Pair programming

Pair programming melibatkan programmer bekerja berpasangan, mengembangkan kode

bersama-sama.
Hal ini membantu mengembangkan kepemilikan umum kode dan menyebar
pengetahuan di seluruh tim.
Ini berfungsi sebagai proses peninjauan informal setiap baris kode yang melihat lebih
dari 1 orang.
Ini mendorong refactoring sebagai seluruh tim bisa mendapatkan keuntungan dari
meningkatkan kode sistem.
Dalam pair programming, programmer duduk bersama di komputer yang sama untuk
mengembangkan software.
Pasangan dibuat secara dinamis sehingga semua anggota tim bekerja dengan satu sama
lain selama proses pembangunan.
Berbagi pengetahuan yang terjadi selama pasangan pemrograman sangat penting karena
mengurangi risiko secara keseluruhan untuk proyek ketika anggota tim meninggalkan.
Pair programming belum tentu efisien dan ada beberapa bukti yang menunjukkan
bahwa pasangan bekerja sama lebih efisien dari 2 programmer bekerja secara terpisah.

Agile project management

Tanggung jawab utama manajer proyek software adalah untuk mengelola proyek
sehingga software tersebut disampaikan tepat waktu dan sesuai anggaran yang
direncanakan untuk proyek tersebut.
Pendekatan standar untuk manajemen proyek adalah plan-driven. Manajer menyusun
rencana untuk proyek menunjukkan apa yang harus disampaikan, ketika harus
disampaikan dan yang akan bekerja pada pengembangan deliverable proyek.
Manajemen proyek Agile membutuhkan pendekatan yang berbeda, yang disesuaikan
dengan perkembangan tambahan dan praktek-praktek yang digunakan dalam agile
method.

Scrum

Scrum adalah agile method yang berfokus pada pengelolaan pembangunan berulang
daripada praktek tangkas tertentu.
Ada tiga fase dalam Scrum.
Tahap awal adalah tahap perencanaan garis besar di mana Anda menetapkan
tujuan umum untuk proyek dan desain arsitektur software.
Ini diikuti dengan serangkaian siklus lari, di mana setiap siklus mengembangkan
kenaikan dari sistem.
Proyek tahap penutupan membungkus proyek, selesai dengan dokumentasi yang
diperlukan seperti sistem bantuan frame dan manual pengguna dan menilai
pelajaran dari proyek.

Scrum sprint cycle

Siklus Sprint

Setelah ini disetujui, tim mengorganisir diri untuk mengembangkan software.

Selama tahap ini tim diisolasi dari pelanggan dan organisasi, dengan semua komunikasi
disalurkan melalui apa yang disebut 'Scrum master.
Peran master Scrum adalah untuk melindungi tim pengembangan dari gangguan
eksternal.
Pada akhir sprint, pekerjaan yang dilakukan ditinjau dan disajikan kepada para
pemangku kepentingan. Siklus sprint berikutnya kemudian dimulai.

Kerja Sama dalam Scrum

The Scrum master adalah fasilitator yang mengatur pertemuan harian, melacak
backlog pekerjaan yang harus dilakukan, mencatat keputusan, mengukur kemajuan
terhadap backlog dan berkomunikasi dengan pelanggan dan manajemen di luar tim.
Seluruh tim menghadiri rapat harian singkat (Scrums) di mana semua anggota tim
berbagi informasi, menggambarkan kemajuan mereka sejak pertemuan terakhir, masalah
yang muncul dan apa yang direncanakan untuk hari berikutnya.
Ini berarti bahwa setiap orang dalam tim tahu apa yang terjadi dan, jika masalah
timbul, dapat kembali rencana kerja jangka pendek untuk mengatasi mereka.

Manfaat Scrum

Produk ini dipecah menjadi satu set potongan dikelola dan dimengerti.
Persyaratan yang tidak stabil tidak tahan kemajuan.
Seluruh tim memiliki visibilitas dari segala sesuatu dan akibatnya komunikasi tim
ditingkatkan.
Pelanggan melihat pengiriman tepat waktu bertahap dan mendapatkan umpan balik
tentang bagaimana produk bekerja.
Kepercayaan antara pelanggan dan pengembang didirikan dan budaya positif dibuat di
mana setiap orang mengharapkan proyek untuk berhasil.

Distributed Scrum

Scaling agile methods

Agile Methods telah terbukti berhasil untuk proyek-proyek kecil dan menengah yang
dapat dikembangkan oleh tim co-terletak kecil.
Hal ini kadang-kadang berpendapat bahwa keberhasilan metode ini datang karena
peningkatan komunikasi yang mungkin ketika semua orang bekerja sama.
Scaling up metode tangkas melibatkan perubahan ini untuk mengatasi lebih besar,
proyek-proyek lagi di mana ada beberapa tim pengembangan, mungkin bekerja di lokasi
yang berbeda.

Scaling out and scaling up

'Scaling up' yang bersangkutan dengan menggunakan metode tangkas untuk

mengembangkan sistem software besar yang tidak dapat dikembangkan oleh tim kecil.
'Scaling out' prihatin dengan bagaimana agile methods dapat diperkenalkan di sebuah
organisasi besar dengan pengalaman bertahun-tahun pengembangan software.
Ketika skala metode tangkas itu importaant untuk mempertahankan fundamental
tangkas:
Perencanaan yang fleksibel, sistem siaran sering, integrasi berkesinambungan,
pengembangan tes-driven dan komunikasi tim yang baik.

Masalah yang terjadi dengan agile methods

Informal pembangunan agile tidak sesuai dengan pendekatan hukum untuk definisi
kontrak yang umum digunakan di perusahaan besar.
Agile methods yang paling tepat untuk pengembangan software baru daripada
perawatan software. Namun mayoritas biaya software di perusahaan besar berasal dari
menjaga sistem software yang ada.
Agile methods dirancang untuk tim co-terletak kecil namun banyak pengembangan
software sekarang melibatkan tim didistribusikan di seluruh dunia.

Agile methods and software maintenance

Sebagian besar organisasi menghabiskan lebih pada mempertahankan software yang ada
daripada yang mereka lakukan pada pengembangan software baru. Jadi, jika agile
methods ingin berhasil, mereka harus mendukung pemeliharaan serta pengembangan
aslinya.
Dua kunci masalah:
Apakah sistem yang dikembangkan menggunakan pendekatan agile, mengingat
penekanan dalam proses pengembangan meminimalkan dokumentasi formal?
Bisakah agile methods digunakan secara efektif untuk perkembangan sistem
dalam menanggapi perubahan permintaan pelanggan?
Masalah mungkin timbul jika tim pengembangan asli tidak dapat dipertahankan.

Agile maintenance

Kunci masalah adalah:

Kurangnya dokumentasi produk
Mempertahankan pelanggan yang terlibat dalam proses pembangunan
Mempertahankan kelangsungan tim pengembangan
Pengembangan agile bergantung pada tim pengembangan mengetahui dan memahami
apa yang harus dilakukan.

Agile and plan-driven methods

Sebagian besar proyek meliputi unsurplan-driven dan agile processes. Menentukan

keseimbangan tergantung pada:
Apakah penting untuk memiliki spesifikasi yang sangat rinci dan desain sebelum pindah ke
implementasi? Jika demikian, Anda mungkin perlu menggunakan pendekatan plandriven.
Apakah strategi pengiriman tambahan, di mana Anda memberikan software untuk pelanggan dan
mendapatkan umpan balik yang cepat dari mereka, realistis? Jika demikian,
pertimbangkan untuk menggunakan metode tangkas.
Berapa besar adalah sistem yang sedang dikembangkan? Agile methods yang paling efektif bila
sistem dapat dikembangkan dengan tim co-terletak kecil yang dapat berkomunikasi
secara informal. Ini mungkin tidak mungkin bagi sistem besar yang memerlukan tim
pengembangan yang lebih besar sehingga pendekatan plan-driven mungkin harus
digunakan.
Agile and plan-based factors

Metode Agile untuk sistem yang besar

Sistem yang besar biasanya pengkoleksiannya terterpisah, berkomunikasi sistem, di

mana tim yang berbeda mengembangkan setiap sistem. Sering, tim ini bekerja di
tempat yang berbeda, kadang-kadang di zona waktu yang berbeda.
Sistem besar yang 'sistem brownfield', yaitu mereka termasuk dan berinteraksi dengan
sejumlah sistem yang ada. Banyak persyaratan sistem prihatin dengan interaksi ini dan
don 't benar-benar meminjamkan diri untuk fleksibilitas dan pengembangan
inkremental.
Di mana beberapa sistem yang terintegrasi untuk menciptakan sebuah sistem, fraksi
yang signifikan dari pengembangan yang bersangkutan dengan konfigurasi sistem
daripada pengembangan kode asli.

Pengembangan system yang besar

Sistem yang besar dan proses pembangunan mereka sering dibatasi oleh aturan
eksternal dan peraturan yang membatasi cara yang mereka dapat dikembangkan.
Sistem yang besar memiliki waktu pengadaan dan pengembangan yang panjang. Sulit
untuk mempertahankan tim yang koheren yang tahu tentang sistem selama periode
sebagai, mau tidak mau, orang beralih ke pekerjaan dan proyek-proyek lainnya.
Sistem yang besar biasanya memiliki satu set beragam pemangku kepentingan. Hal ini
praktis tidak mungkin untuk melibatkan semua pemangku kepentingan yang berbeda
dalam proses pembangunan.

Factors in large systems

IBMs agility at scale model

Scaling up to large systems

Sebuah pendekatan yang sama sekali tambahan untuk rekayasa persyaratan adalah
mustahil.
Ada tidak bisa menjadi pemilik produk atau wakil pelanggan.
Untuk pengembangan sistem yang besar, tidak mungkin untuk fokus hanya pada kode
sistem.
Mekanisme komunikasi lintas-tim harus dirancang dan digunakan.
Integrasi berkesinambungan praktis tidak mungkin. Namun, adalah penting untuk
mempertahankan sistem sering membangun dan rilis reguler dari sistem.

Multi-tim Scrum
Role replication
Product architects
Release alignment

 Scrum of Scrums
Agile methods dalam seluruh organisasi

Manajer proyek yang tidak memiliki pengalaman metode tangkas mungkin enggan
untuk menerima risiko pendekatan baru.
Organisasi besar sering memiliki prosedur mutu dan standar yang semua proyek
diharapkan untuk mengikuti dan, karena sifat birokrasi mereka, ini mungkin tidak sesuai
dengan agile methods.
Agile methods tampaknya bekerja dengan baik ketika anggota tim memiliki tingkat
keterampilan yang relatif tinggi. Namun, dalam organisasi besar, ada kemungkinan
akan berbagai keterampilan dan kemampuan.

Poin penting

Agile methods adalah metode inkremental pembangunan yang fokus pada

pengembangan software yang cepat, sering rilis dari software, mengurangi overhead
proses dengan meminimalkan dokumentasi dan menghasilkan kode berkualitas tinggi.
Praktek-praktek pembangunan Agile mencakup
Cerita pengguna untuk spesifikasi sistem
Rilis sering software,
Perbaikan software terus menerus
Pengembangan tes pertama
Partisipasi pelanggan dalam tim pengembangan.
Scrum adalah agile methods yang menyediakan kerangka kerja manajemen proyek.
Hal ini berpusat putaran satu set sprint, yang periode waktu tetap ketika kenaikan
sistem dikembangkan.
Banyak metode pengembangan praktis adalah campuran dari pengembangan plan-based
dan agile
Scaling agil methods untuk sistem yang besar sulit.
Sistem yang besar perlu muka desain dan beberapa dokumentasi dan praktek
organisasi mungkin bertentangan dengan informalitas pendekatan agile.