Tugas resume TDA Part 3,4

Waterfall vs Agile : Mana yang Tepat untuk Pengembangan Metodologi Proyek Anda ?

Salah satu keputusan pertama yang kita hadapi untuk setiap implementasi proyek kami di Segue adalah " Yang metodologi pengembangan harus kita gunakan? " Ini adalah topik yang mendapat banyak diskusi ( dan sering debat panas ) . Jika hal ini tidak sesuatu yang Anda telah bekerja dengan sebelumnya, definisi metodologi pengembangan adalah dalam rangka , menempatkan sangat sederhana , itu adalah cara mengatur pekerjaan pengembangan perangkat lunak . Untuk menjelaskan lebih lanjut , itu TIDAK gaya manajemen proyek atau pendekatan teknis tertentu , meskipun Anda akan sering mendengar istilah ini semua dilemparkan bersama-sama atau digunakan secara bergantian .

Dua dasar, metodologi yang paling populer adalah :

    waterfall Yang mungkin lebih tepat disebut pendekatan " tradisional " , dan
    Agile ( lebih baru daripada Waterfall , tapi tidak yang baru ) .

Kedua hal ini dapat digunakan , metodologi matang . Setelah terlibat dalam proyek pengembangan perangkat lunak untuk waktu yang lama , di sini adalah pikiran saya pada kekuatan dan kelemahan masing-masing .

Metodologi Waterfall

waterfall adalah pendekatan linier untuk pengembangan perangkat lunak . Dalam metodologi ini , urutan kejadian adalah sesuatu seperti :

    Mengumpulkan dan persyaratan dokumen disain

    Kode dan uji unit

    Melakukan pengujian sistem

    Melakukan pengujian penerimaan pengguna ( UAT )

    Perbaiki masalah apapun

    Memberikan produk jadi

Dalam sebuah proyek pengembangan Waterfall benar, masing-masing mewakili tahap yang berbeda dari pengembangan perangkat lunak , dan setiap tahap umumnya selesai sebelum yang berikutnya dapat dimulai. Ada juga biasanya gerbang tahap antara masing-masing , misalnya , persyaratan harus ditinjau dan disetujui oleh pelanggan sebelum desain dapat dimulai.

Ada hal-hal baik dan buruk tentang pendekatan Waterfall . Di sisi positif :

    Pengembang dan pelanggan setuju pada apa yang akan disampaikan awal dalam siklus pengembangan . Hal ini membuat perencanaan dan perancangan lebih mudah .

    Kemajuan lebih mudah diukur , sebagai lingkup penuh pekerjaan dikenal di muka.
    Sepanjang upaya pengembangan , mungkin untuk berbagai anggota tim yang akan terlibat atau melanjutkan dengan pekerjaan lain , tergantung pada fase aktif proyek. Sebagai contoh , analis bisnis dapat mempelajari dan mendokumentasikan apa yang perlu dilakukan , sedangkan pengembang bekerja pada proyek-proyek lainnya . Penguji dapat mempersiapkan skrip uji dari persyaratan dokumentasi sementara coding sedang berlangsung .

    Kecuali ulasan , persetujuan , status pertemuan , dll , kehadiran pelanggan tidak sepenuhnya diperlukan setelah fase persyaratan .

    Karena desain selesai di awal siklus pengembangan , pendekatan ini cocok untuk proyek-proyek di mana beberapa komponen perangkat lunak harus dirancang (kadang-kadang secara paralel ) untuk integrasi dengan sistem eksternal .

    Akhirnya , perangkat lunak dapat dirancang sepenuhnya dan lebih hati-hati , berdasarkan pemahaman yang lebih lengkap dari semua kiriman perangkat lunak. Ini memberikan desain software yang lebih baik dengan kemungkinan kurang dari " sedikit demi sedikit efek , " sebuah fenomena pembangunan yang dapat terjadi sebagai potongan kode didefinisikan dan kemudian ditambahkan ke aplikasi di mana mereka mungkin atau mungkin tidak cocok dengan baik .

Berikut adalah beberapa masalah yang saya temui menggunakan pendekatan Waterfall murni :

    Salah satu daerah yang hampir selalu jatuh pendek adalah efektivitas persyaratan . Mengumpulkan dan mendokumentasikan persyaratan dalam cara yang berarti bagi pelanggan adalah bagian yang paling sulit dari pengembangan perangkat lunak , menurut pendapat saya . Pelanggan kadang-kadang terintimidasi oleh detail , dan rincian spesifik , yang disediakan di awal proyek , yang diperlukan dengan pendekatan ini . Selain itu, pelanggan tidak selalu mampu memvisualisasikan sebuah aplikasi dari dokumen persyaratan . Wireframes dan maket dapat membantu, tetapi tidak ada pertanyaan bahwa sebagian besar pengguna akhir memiliki beberapa kesulitan menempatkan elemen bersama-sama dengan persyaratan tertulis untuk sampai pada gambaran yang baik tentang apa yang akan mereka dapatkan.
    Kelemahan lain potensi pengembangan Waterfall murni adalah kemungkinan bahwa pelanggan akan puas dengan produk perangkat lunak mereka disampaikan. Karena semua kiriman didasarkan pada persyaratan terdokumentasi , pelanggan mungkin tidak melihat apa yang akan dikirimkan sampai itu hampir selesai . Pada saat itu , perubahan bisa sulit ( dan mahal ) untuk melaksanakan .

Agile Metodologi

Agile adalah iteratif , pendekatan berbasis tim untuk pembangunan. Pendekatan ini menekankan pengiriman cepat aplikasi dalam komponen fungsional yang lengkap . Daripada membuat tugas dan jadwal , sepanjang masa adalah " waktu - kotak " menjadi fase yang disebut " sprint . " Setiap berlari memiliki durasi yang ditetapkan ( biasanya dalam minggu) dengan menjalankan daftar kiriman , direncanakan satu berlari di muka. Kiriman diprioritaskan oleh nilai bisnis yang ditentukan oleh pelanggan . Jika semua pekerjaan yang direncanakan untuk sprint tidak dapat diselesaikan , pekerjaan reprioritized dan informasi yang digunakan untuk perencanaan sprint di masa depan .

Sebagai pekerjaan selesai selama setiap sprint, hal ini terus dievaluasi dan dievaluasi oleh pelanggan , yang dapat dianggap sebagai anggota paling penting dari tim Agile . Akibatnya , Agile bergantung pada tingkat yang sangat tinggi keterlibatan pelanggan di seluruh proyek.

Beberapa keuntungan dari pendekatan Agile mudah untuk melihat :

    Pelanggan telah sering dan awal kesempatan untuk melihat pekerjaan yang sedang disampaikan , dan untuk membuat keputusan dan perubahan di seluruh proyek pembangunan.

    Pelanggan memperoleh rasa kepemilikan yang kuat dengan bekerja secara luas dan langsung dengan tim proyek sepanjang proyek .

    Jika waktu untuk memasarkan untuk aplikasi tertentu adalah kekhawatiran , Agile bisa lebih cepat menghasilkan versi dasar perangkat lunak bekerja .

    Pengembangan sering lebih berfokus pada pengguna , kemungkinan akibat dari lebih dan sering arah dari pelanggan .

    Untuk lebih Agile Pengembangan manfaat , silakan lihat 8 Manfaat Agile Software Development

Dan, tentu saja , ada beberapa kelemahan :

    Tingkat yang sangat tinggi keterlibatan pelanggan, sementara yang besar untuk proyek tersebut , dapat menimbulkan masalah bagi beberapa pelanggan yang hanya mungkin tidak memiliki waktu atau minat untuk jenis partisipasi.

    Agile bekerja paling baik bila anggota tim pembangunan benar-benar didedikasikan untuk proyek.
    Karena Agile berfokus pada waktu pengiriman - kotak dan sering reprioritization , mungkin bahwa beberapa item yang ditetapkan untuk pengiriman tidak akan selesai dalam jangka waktu yang ditentukan. Sprint tambahan ( di luar yang awalnya direncanakan ) mungkin diperlukan , menambah biaya proyek . Selain itu, keterlibatan pelanggan sering menyebabkan fitur tambahan yang diminta sepanjang proyek . Sekali lagi, ini dapat menambah waktu keseluruhan dan biaya pelaksanaan .

    Hubungan kerja yang erat dalam sebuah proyek Agile paling mudah untuk mengelola ketika anggota tim berada dalam ruang fisik yang sama , yang tidak selalu mungkin . Namun , ada berbagai cara untuk menangani masalah ini , seperti webcam , perangkat kolaborasi , dll

    Sifat iteratif pembangunan Agile dapat menyebabkan penurunan kualitas sistem secara keseluruhan , karena ada sedikit penekanan pada pemahaman sistem selesai secara keseluruhan di awal proyek . Hal ini menjadi lebih jelas dalam implementasi skala besar , atau dengan sistem yang mencakup tingkat tinggi integrasi .

Membuat Pilihan Antara Agile dan Waterfall

Jadi , bagaimana kita memilih ? Pertama , kita mengubah permainan sedikit (yang sebagian besar organisasi pengembangan perangkat lunak apa yang ) dengan mendefinisikan proses kita sendiri . Pada Segue , itu disebut Kerangka Proses kami , dan itu adalah variasi pada metodologi Waterfall tradisional. Modifikasi kami meliputi penggunaan prototyping bila memungkinkan untuk memberikan pelanggan pandangan yang lebih baik dari produk jadi mereka di awal siklus desain / pengembangan . Ini membantu untuk meningkatkan pemahaman tim persyaratan dan komunikasi dengan pelanggan . Setelah kerangka utama aplikasi selesai sesuai kebutuhan tingkat tinggi , kami terus mengembangkan dan juga untuk menjangkau pelanggan untuk perbaikan persyaratan . Dengan cara ini , kami berusaha untuk menjadi seperti berulang mungkin tanpa mengorbankan arsitektur sistem secara keseluruhan 

Sumber :

http://www.seguetech.com/blog/2013/07/05/waterfall-vs-agile-right-development-methodology