Buku “Agile Murni. Dasar-Dasar Fleksibilitas

Halo, habrozhiteli! Kami telah menyerahkan ke rumah cetak hal baru lainnya! Hampir dua puluh tahun telah berlalu sejak Agile Manifesto muncul. Robert Martin yang legendaris (Paman Bob) menyadari bahwa sudah waktunya untuk menghilangkan debu dari prinsip-prinsip Agile, dan sekali lagi untuk menceritakan tentang pendekatan fleksibel tidak hanya untuk generasi baru programmer, tetapi juga untuk spesialis dari industri lain. Penulis buku "Kode Bersih", "Programmer Ideal", "Arsitektur Bersih", yang dicintai oleh orang-orang IT, adalah asal-usul Agile. Pure Agile menghilangkan kesalahpahaman dan kebingungan bahwa, selama bertahun-tahun keberadaan Agile, membuatnya lebih sulit untuk digunakan daripada rencana semula. Intinya, Agile hanyalah sejumlah kecil metode dan alat yang membantu tim kecil programmer mengelola proyek-proyek kecil, ... tetapi mengarah pada hasil yang luar biasa,karena setiap proyek besar terdiri dari sejumlah besar batu bata. Lima dekade bekerja dengan proyek dari semua jenis dan ukuran yang dibayangkan memungkinkan Paman Bob untuk menunjukkan bagaimana Agile seharusnya bekerja. Jika Anda ingin memahami manfaat Agile, jangan mencari cara mudah - Anda harus menggunakan Agile dengan benar. Pure Agile memberi tahu Anda cara melakukan ini untuk pengembang, penguji, manajer, manajer proyek, dan pelanggan.

Kutipan. Hal pertama yang harus diketahui

Apa hal pertama yang perlu Anda ketahui tentang proyek ini? Sebelum Anda mengetahui nama proyek atau persyaratan untuknya, sebelum Anda melakukan gerakan apa pun, Anda perlu mendapatkan informasi lebih lanjut. Tentu saja, ini tenggat waktunya. Setelah tanggal dipilih, mereka harus diperbaiki. Tidak ada gunanya mendiskusikan ketentuan-ketentuan tersebut, karena ketentuan-ketentuan itu dibuat sehubungan dengan alasan bisnis yang objektif. Jika September jatuh tempo, bukan hanya itu. Mungkin pada bulan September beberapa jenis pameran atau rapat pemegang saham direncanakan, atau mungkin dana akan habis. Apa pun alasannya, ia memiliki latar belakang yang penting. Dan alasannya tidak akan berubah hanya karena untuk beberapa pengembang volume tugas tampaknya luar biasa.

Pada saat yang sama, persyaratan dapat berubah dalam aliran berkelanjutan yang tidak dapat diperbaiki.

Dan ada juga alasan untuk ini - pelanggan sering tidak tahu apa yang sebenarnya mereka inginkan. Mereka tampaknya tahu masalah apa yang perlu mereka selesaikan, tetapi menerjemahkan pengetahuan seperti itu ke dalam persyaratan proyek selalu sulit. Oleh karena itu, ada penilaian ulang yang konstan dan memikirkan kembali persyaratan. Fitur baru ditambahkan.

Beberapa yang lama menghilang. Antarmuka pengguna berubah dengan cepat - dalam beberapa minggu, jika tidak beberapa hari.

Seperti inilah dunia pengembangan perangkat lunak. Di dunia ini, tenggat waktu ditetapkan, dan persyaratan terus berubah. Dan entah bagaimana, dalam konteks semua ini, pengembang harus berhasil menyelesaikan proyek.

Koleksi

Model berjenjang menubuatkan kepada kita cara untuk memotong tugas ini. Untuk menjelaskan betapa menggoda dan tidak efektifnya itu pada saat yang sama, saya akan mengutip satu pertemuan sebagai contoh.

Itu adalah yang pertama bulan Mei. Bos besar memanggil bawahan ke ruang konferensi.

Bos mulai: “Kami memiliki proyek baru. Diperlukan untuk menyelesaikannya pada tanggal 1 November. Kami belum memiliki persyaratan. Mereka akan diumumkan kepada kita dalam beberapa minggu ke depan. Berapa lama untuk menganalisis proyek? "

Kami mulai saling bertanya satu sama lain. Semua orang diam, takut untuk bicara terlalu banyak. Tidak ada yang tahu harus menjawab apa. Seseorang bergumam: "Jadi kita tidak memiliki persyaratan, kita harus mulai dari mana?"

"Bayangkan mereka itu! Teriak bos. "Kamu tahu bagaimana semuanya bekerja." Anda ahli! Saya tidak perlu tanggal pasti. Saya hanya perlu mengisi jadwal entah bagaimana. Ingatlah bahwa jika dibutuhkan lebih dari dua bulan, Anda dapat dengan percaya diri melupakan proyek tersebut. ”

Seseorang bergumam bertanya, "Dua bulan?" Bos menganggapnya menyetujui persyaratan: “Hebat! Apa yang saya pikirkan. Sekarang beri tahu saya berapa banyak desainnya? ”

Dan sekali lagi semua orang membeku dalam kebingungan, ruangan itu dipenuhi dengan kesunyian. Kita menghitung. Dan kami menyadari bahwa hingga November pertama hanya enam bulan. Kesimpulannya menunjukkan itu sendiri. "Dua bulan?" - Anda bertanya.

"Betul! - bos besar tersenyum cerah. - Seperti yang saya pikirkan. Dan kami memiliki dua bulan tersisa untuk implementasi. Terima kasih untuk semuanya, kamu bebas! "
Banyak pembaca mungkin ingat bahwa hal seperti itu sudah terjadi pada mereka. Siapa yang tidak punya ini, yah, kamu beruntung!

Tahap analisis

Jadi, misalkan kita meninggalkan ruang konferensi dan bertebaran di sekitar kantor. Apa yang harus dilakukan selanjutnya? Fase analisis dimulai - itu artinya Anda perlu menganalisis sesuatu. Tapi apa sebenarnya yang kita sebut analisis?

Jika Anda membaca buku tentang topik analisis dalam pengembangan perangkat lunak, Anda akan menemukan bahwa setiap penulis memberikan definisi sendiri. Tidak ada konsensus tentang apa analisis itu. Ini dapat berupa dekomposisi struktural dari persyaratan. Atau mungkin - deteksi dan spesifikasi persyaratan. Mungkin penciptaan model atau objek data fundamental, dan sebagainya ... Definisi analisis terbaik adalah ini: itulah yang dilakukan analis.

Tentu saja, ada beberapa hal yang jelas. Kita perlu mengevaluasi ukuran proyek, untuk memperkirakan indikator sumber daya teknis, ekonomi, dan manusia yang utama. Anda perlu memastikan bahwa jadwal kerja itu layak. Ini adalah yang terkecil yang diharapkan perusahaan dari kami. Apa pun yang disebut analisis, inilah yang akan kami lakukan dalam dua bulan ke depan.

Ini adalah semacam fase proyek yang menguntungkan. Semua orang dengan tenang menjelajahi Internet, melakukan transaksi kecil, bertemu dengan pelanggan dan pengguna, menggambar grafik yang indah, sederhananya, bersenang-senang.

Lalu yang pertama dari Juli terjadi keajaiban. Analisisnya lengkap.

Kenapa kita berpikir begitu? Karena ini sudah tanggal 1 Juli. Jika, sesuai dengan jadwal, tahap analisis harus diselesaikan pada tanggal 1 Juli, maka tahap ini selesai pada 1 Juli. Kami tidak terlambat, kan? Oleh karena itu, kami akan mengatur pesta kecil dengan balon dan pidato berapi-api, merayakan transisi kami dari tahap analisis ke tahap desain.

Fase desain

Apa yang harus dilakukan sekarang? Tentu saja, kami akan mendesain. Tapi apa itu desain ?

Kami tahu lebih banyak tentang fase desain perangkat lunak. Pada tahap ini, kami memecah proyek menjadi modul terpisah dan merancang antarmuka antara modul-modul ini. Pada tahap ini, kita juga mengasumsikan berapa banyak tim yang akan kita butuhkan dan bagaimana tim-tim ini akan saling berhubungan. Secara umum, jadwal kerja perlu diklarifikasi untuk menyusun rencana implementasi yang layak dan masuk akal.

Tentu saja, pada tahap ini, sesuatu tiba-tiba berubah. Fitur baru ditambahkan. Fungsi lama hilang atau disesuaikan. Dan akan menyenangkan untuk melihat kembali dan menganalisis perubahan lagi, tetapi waktu adalah uang. Oleh karena itu, kami berusaha dengan segala cara untuk membuat perubahan pada desain.

Dan kemudian keajaiban baru terjadi. Pada tanggal 1 September kami tiba-tiba menyelesaikan desain. Dan mengapa? Ya karena. Yang pertama September. Menurut jadwal kerja, kita seharusnya sudah selesai. Tidak perlu ragu.

Jadi satu pesta lagi. Balon dan pidato. Dan kami menerobos ke tahap berikutnya - implementasi.

Akan sangat bagus untuk menghidupkan kembali skema semacam itu sekali lagi. Oh, jika dengan cara yang sama akan mungkin untuk menyelesaikan fase implementasi! Tapi itu tidak akan berhasil seperti itu. Karena setelah selesainya implementasi, diperlukan untuk menyelesaikan seluruh proyek. Analisis dan desain tidak menghasilkan buah dalam bentuk biner. Mereka tidak memiliki kriteria lengkap untuk kelengkapan.

Tidak ada cara obyektif untuk mengetahui apakah semua itu ada dalam kenyataan. Karena itu, ternyata menyelesaikan tahap-tahap ini tepat waktu.

Tahap implementasi

Tetapi implementasinya hanya memiliki kriteria berbeda untuk kelengkapan. Di sini tidak lagi mungkin untuk bermain-main dengan akurat, memberikan hasil imajiner yang valid.
Pada tahap implementasi, ambiguitas tugas sama sekali tidak ada. Kami hanya menulis kodenya. Dan kita harus menulis kode dengan tergesa-gesa, menjulurkan lidah kita, karena empat bulan dibuang begitu saja.

Sementara itu, persyaratan proyek terus berubah. Fitur baru ditambahkan. Fungsi lama hilang atau disesuaikan. Kami harus kembali, melakukan analisis baru dan membuat perubahan pada desain, tetapi ... hanya tinggal dua minggu lagi. Dan pada kecepatan yang dipercepat, kami mengarahkan semua perubahan ini ke dalam kode.

Ketika kita melihat kode dan membandingkannya dengan hasil desain, kita menyadari bahwa kita pasti sudah tidak pada tahap desain, karena kode itu sendiri tidak ada hubungannya dengan apa yang awalnya digambarkan pada grafik yang indah. Tetapi tidak ada waktu untuk berpikir, karena jam terus berdetak, dan lembur menjadi lebih dan lebih.

Sekitar 15 Oktober, seseorang berkata, "Hei, tanggal berapa hari ini?" Kapan mengambilnya? " Dan di sini kita mengerti bahwa hanya ada dua minggu lagi dan pada November pertama kita tidak akan pernah selesai. Dan tiba-tiba, untuk pertama kalinya, pelanggan kami mengetahui bahwa ada beberapa masalah dengan proyek tersebut.

Bayangkan kemarahan mereka. “Dan pada tahap analisis, tidak mungkin untuk mengatakan tentang ini? Bukankah saat itu Anda seharusnya memperkirakan ukuran proyek dan dengan hati-hati menghitung jadwal kerja? Dan mengapa mereka tidak mengatakan pada tahap desain? Bukankah itu perlu untuk membagi proyek menjadi modul, mendistribusikan pekerjaan di seluruh tim dan menghitung sumber daya manusia? Mengapa kita mengetahui semuanya dua minggu sebelum batas waktu? "

Dan mereka benar, bukan?

Maraton survival

Dan maraton penyelamatan dimulai. Pelanggan marah. Stakeholder telah mencapai titik ekstrim. Tekanan meningkat. Kami bekerja lembur. Seseorang meninggalkan proyek. Persetan!

Dan sudah sekitar bulan Maret, kami bersedih hati dengan hasil yang hanya setengahnya memenuhi persyaratan pelanggan. Semua orang kesal. Semua orang menyerah. Dan kami bersumpah pada diri kami bahwa waktu berikutnya ini tidak akan terjadi. Lain kali kita akan melakukan semuanya dengan bijak. Lain kali analisis dan desain akan dilakukan dengan itikad baik.

Saya menyebutnya proses kembung di luar kendali. Kami akan bekerja lebih baik lagi lain kali menggunakan metode yang tidak berfungsi.

»Anda dapat memesan di muka di situs web penerbit.

Setelah pembayaran versi kertas buku, pdf dikirim ke emaildengan 105 halaman pertama buku.