Selain Waterfall, apa metodologi pengembangan perangkat lunak berbasis rencana lainnya?

8

Saya baru saja membaca Balancing Agility dan Disiplin . Mengesampingkan judul yang buruk, itu kontras dengan tim proyek yang digerakkan oleh rencana yang menggunakan PSP / TSP dan tim gesit menggunakan Extreme Programming.

Ketika penulis memberikan contoh metodologi yang digerakkan oleh rencana, mereka menggunakan Proses Perangkat Lunak Pribadi / Proses Perangkat Lunak Tim. Meskipun, out-of-the-box, ini adalah metodologi yang digerakkan oleh rencana, mereka juga dirancang untuk digunakan sebagai kerangka kerja proses dan pada akhirnya hanya menentukan jenis hal apa yang harus dilakukan dan bukan bagaimana melakukannya, yang membuatnya berpotensi berguna bahkan di lingkungan yang gesit. Mungkin gesit dan tetap berpegang pada prinsip-prinsip PSP, dan saya tidak cukup akrab dengan TSP untuk mengatakan dengan pasti, tetapi pemahaman saya adalah bahwa itu sangat mirip.

Pada satu titik dalam buku ini, mereka mendaftar sejumlah metodologi dan peringkat mereka dalam hal kelincahan. Metode seperti Scrum, Lean, Crystal, dan XP ada di atas. Bagian bawah (dari yang paling gesit) terdiri dari Proses Bersatu Rasional, Proses Perangkat Lunak Tim, Pengembangan Berbasis-Fitur, CMMI, Perangkat Lunak CMM, Proses Perangkat Lunak Pribadi, dan Cleanroom.

Watts Humphrey, dalam PSP: Proses Peningkatan-Diri untuk Insinyur Perangkat Lunak , mendedikasikan bab untuk memproses definisi, dan secara khusus memodifikasi Proses Perangkat Lunak Pribadi. Tema umum adalah bahwa proses bersifat preskriptif (mereka mengatakan apa yang harus dilakukan) dan bukan deskriptif (bagaimana melakukannya). Saya menduga bahwa TSP sangat mirip. CMMI juga telah digunakan dalam hubungannya dengan metode gesit, dan SEI memiliki buku tentang itu (yang belum saya baca).

Pengembangan Berbasis Fitur sering disebut-sebut sebagai pendekatan tangkas untuk manajemen proyek, namun penulis memilih untuk memeringkatnya sebagai metodologi yang kurang gesit.

RUP adalah kerangka kerja yang berulang. Meskipun saya tidak terlalu terbiasa dengan hal itu, fakta bahwa itu adalah kerangka kerja yang memungkinkan saya untuk mengelompokkannya dengan SW-CMM, CMMI, dan PSP / TSP sehingga dapat diimplementasikan baik sebagai tangkas atau sebagai metodologi berbasis rencana.

Satu-satunya contoh lain yang disediakan buku itu yang saya setujui adalah Cleanroom Software Engineering . Komponen utama Cleanroom adalah penggunaan metode formal, kontrol kualitas statistik, dan pengujian yang baik secara statistik. Saya tidak melihat mengapa ini tidak dapat digunakan dalam metode lincah (iteratif / incremental), dengan menambahkan waktu dan biaya overhead.

Hanya untuk memperjelas apa yang saya cari, keluarga metode tangkas termasuk implementasi spesifik dari ide abstrak dalam bentuk Scrum dan Extreme Programming. Ini mewujudkan konsep pengembangan berulang dan bertahap, menanggapi perubahan, orang (individu dan tim), seringnya pengiriman perangkat lunak yang berfungsi, berkolaborasi dengan pelanggan, dan sebagainya. Mereka jelas menentukan peran, artefak, pertemuan, kotak waktu, dan praktik lainnya dan untuk "melakukan Scrum" atau "melakukan Pemrograman Ekstrim" berarti mengambil paket. Meski begitu, mereka memungkinkan untuk disesuaikan dan penciptaan proses baru (tapi kemudian Anda tidak "melakukan Scrum" atau "melakukan XP"). Namun, saya belum menemukan "do X"

Jadi, pertanyaan saya: Apa saja contoh metodologi pengembangan perangkat lunak berbasis rencana? Sejumlah kerangka kerja proses (PSP / TSP, SW-CMM, CMMI, RUP) memungkinkan untuk pengembangan yang digerakkan oleh rencana atau tangkas, juga, tetapi tidak ada yang deskriptif. Tetapi apakah ada metodologi yang benar-benar digerakkan oleh rencana, yang, misalnya, mengarahkan mitra ke Scrum dan Pemrograman Ekstrim?

Thomas Owens
sumber
Anda menulis bahwa buku "kontras dengan tim proyek yang digerakkan oleh rencana yang menggunakan PSP / TSP dan tim gesit menggunakan Pemrograman Ekstrim". Saya cukup yakin kami menggunakan banyak perencanaan untuk implementasi XP kami. Saya agak bingung untuk menganggap bahwa XP'ers tidak berencana. Pengalaman saya berbeda. Dua sen saya.
Manfred
@John Plan-driven metodologi dipusatkan pada penerapan teknik teknik tradisional dan bergerak secara sistematis dari persyaratan melalui, pada akhirnya, produk pengiriman, sambil melakukan verifikasi dan validasi pada langkah. Mereka dicirikan oleh dokumentasi yang kuat dan ketertelusuran melalui kehidupan sistem. Ada rencana terperinci, alur kerja, dan produk kerja (yaitu hal-hal lain selain perangkat lunak yang berfungsi).
Thomas Owens

Jawaban:

5

Jujur, saya ragu tentang validitas klaim yang dibuat dalam buku yang membuat Agility dan Disiplin saling bertentangan. Metodologi yang tangkas membutuhkan lebih banyak disiplin, dalam pengalaman saya, daripada jenis pengembangan lainnya.

Artinya, jika Anda akan mengeksploitasi manfaat dari proses Agile, Anda harus mengikuti praktik yang memungkinkan yang menyertainya (lihat artikel Is Design Dead dari Martin Fowler ; ia kebanyakan berbicara tentang XP, tetapi itu berlaku untuk semua Agility, di pendapat saya). Itu membutuhkan banyak disiplin.

Tetapi, untuk menjawab pertanyaan Anda, saya pikir semua metodologi yang benar-benar digerakkan oleh rencana adalah variasi Air Terjun, seperti Spiral , yang membutuhkan pengembangan melalui berbagai tingkat pembuatan prototipe sebelum beralih ke pendekatan Air Terjun, dan Cap Gemini SDM , yaitu Air Terjun dengan sangat fase yang berbeda di mana masing-masing berakhir sebelum yang lain dimulai.

pdr
sumber
1
Saya setuju - saya tidak suka perbandingan antara "gesit" dan "disiplin". "Agile" versus "plan-driven" jauh lebih baik, dan saya telah membaca di beberapa sumber (walaupun saya tidak dapat menyebutkannya dari atas kepala saya) bahwa menjadi gesit membutuhkan tim yang berdedikasi, berpengetahuan, dan bahkan lebih berpengalaman, bahkan lebih dari metode berbasis rencana apa pun. Adapun paragraf terakhir Anda - itu masih kerangka kerja. Ada banyak kerangka kerja yang digerakkan oleh rencana, tetapi tidak ada yang secara eksplisit tentang "ini {masukkan nama di sini}" dengan cara yang sama seperti Anda dapat mengatakan "ini Scrum" atau "ini Pemrograman Ekstrim".
Thomas Owens
1
@ThomasOwens: Spiral adalah metodologi, bukan kerangka kerja. Anda mungkin memiliki poin tentang V-model. Mungkin Cap Gemini SDM adalah contoh yang lebih baik, meskipun selalu sangat mirip dengan Spiral bagi saya. en.wikipedia.org/wiki/System_Development_Methodology
pdr
1
Spiral jauh lebih dekat - jelas mendefinisikan fase dan beberapa dokumen (persyaratan, conops, rencana pengembangan, rencana dan prosedur pengujian) dan output teknis (prototipe, produk akhir). Saya akan mengatakan itu dan Cap Gemini SDM jauh lebih dekat dengan apa yang saya cari (dapatkah Anda menambahkan SDM ke posting Anda?). +1.
Thomas Owens
1
@ThomasOwens: Dilakukan dan diganti model-V.
pdr