JavaRush /Blog Java /Random-MS /Metodologi pembangunan perisian

Metodologi pembangunan perisian

Diterbitkan dalam kumpulan
Hello. Pada dua temu bual terakhir saya ditanya tentang metodologi. Ini bukan soalan yang paling penting atau sukar, tetapi adalah bagus untuk mempunyai helaian tipu untuk jawapannya. Dalam artikel ini saya akan cuba memberi gambaran tentang apa itu metodologi pembangunan dan membandingkan yang saya temui atau ditanya secara peribadi. Metodologi pembangunan perisian - 1Metodologi pembangunan perisian ialah satu proses untuk menerangkan bagaimana sesuatu produk tertentu akan dibangunkan, iaitu salah satu cara untuk mengatur pembangunan pasukan. Terdapat banyak model proses sedemikian, masing-masing menerangkan pendekatannya sendiri, dan tidak boleh dikatakan bahawa di antara mereka ada satu yang harus digunakan dalam setiap projek, semuanya adalah situasional semata-mata. Saya mencadangkan untuk mempertimbangkan tiga daripadanya dengan lebih terperinci.

Air terjun

Air terjun (lata, air terjun) adalah salah satu metodologi tertua dan membayangkan pelaksanaan berurutan yang ketat bagi semua peringkat, setiap satu mesti diselesaikan sebelum yang seterusnya bermula. Iaitu, peralihan ke peringkat seterusnya bermakna penyiapan lengkap kerja pada yang sebelumnya. Gambar menunjukkan bahawa mula-mula kita menganalisis tugasan (mendokumentasikan tugas, membincangkan kesukaran), kemudian reka bentuk berlaku (pada peringkat ini struktur projek terbentuk), kemudian pengekodan dan ujian. Tiada bayaran balik untuk peringkat seterusnya. Adalah disyorkan untuk menggunakan sistem sedemikian dalam projek kecil di mana keperluannya diketahui lebih awal dan terdapat kemungkinan kecil bahawa ia akan berubah. Metodologi pembangunan perisian - 2Kelebihan:
  • Dokumentasi yang lengkap dan konsisten pada setiap peringkat;
  • Kemudahan penggunaan;
  • Keperluan yang stabil.
  • Belanjawan dan tarikh akhir telah ditetapkan
Kelemahan:
  • Sebilangan besar dokumentasi;
  • Bukan sistem yang sangat fleksibel;
  • Pelanggan tidak boleh melihat versi demo produk;
  • Tidak ada cara untuk mundur selangkah.

Scrum

Scrum ialah sistem pembangunan perisian berdasarkan membahagikan keseluruhan proses kepada lelaran, di mana pada akhir setiap daripada mereka pasukan bersedia untuk menyediakan versi demo produk. Gambar menunjukkan bahawa pasukan itu melalui semua peringkat pembangunan secara selari, yang membolehkan kami menyelesaikan bahagian projek pada akhir setiap lelaran. Metodologi pembangunan perisian - 3Saya akan cuba menerangkan secara ringkas dengan kata-kata mudah intipati metodologi, tetapi terdapat banyak istilah di sini. Saya fikir perkara yang paling penting ialah memahami intipati, dan istilah itu akan diingati dengan pengalaman. Semua perkembangan dibahagikan kepada pecut (selalunya 2-3 minggu). Terdapat tunggakan (senarai tugas) untuk keseluruhan tempoh pembangunan dan untuk setiap pecut secara berasingan. Setiap tugasan mempunyai titik cerita sendiri (penilaian kesukaran). Setiap peserta dalam proses mempunyai peranan:
  • Pasukan Scrum ialah pasukan yang bekerja pada projek (pembangun, penguji, pereka bentuk).
  • Master Scrum ialah orang yang memastikan bahawa prinsip Scrum dipatuhi.
  • Pemilik produk - pelanggan.
Oleh kerana dalam sistem ini penekanan adalah pada komunikasi, terdapat sejumlah besar perhimpunan:
  • Stand-up ialah mesyuarat singkat, diadakan setiap hari, semua ahli pasukan mengambil bahagian dan setiap peserta menjawab 3 soalan: apa yang anda lakukan? Apa yang akan dilakukannya? Dan apakah penyekatnya?
  • Perancangan – diadakan pada permulaan larian pecut dan pada mesyuarat ini ditentukan apakah tugasan yang perlu diselesaikan dalam larian pecut seterusnya.
  • Retrospektif diadakan pada akhir pecut dan intipatinya adalah untuk mengetahui apa yang telah dilakukan dengan baik dan apa yang boleh diperbaiki.
Kelebihan:
  • Pelanggan boleh melihat hasilnya semasa proses pembangunan.
  • Kawalan harian ke atas proses pembangunan.
  • Keupayaan untuk membuat pelarasan semasa pembangunan.
  • Komunikasi yang mantap dengan semua ahli pasukan.
  • Jumlah dokumentasi yang kecil.
Kelemahan:
  • Sukar untuk menganggarkan buruh dan kos yang diperlukan untuk pembangunan
  • Sukar untuk menentukan kesesakan terbesar sebelum pembangunan bermula.
  • Keperluan untuk melibatkan semua orang dalam pembangunan ahli pasukan yang lain.

Kanban

Kanban ialah sistem yang dibina berdasarkan gambaran proses menyelesaikan tugasan pasukan. Idea utama dalam sistem ini adalah untuk mengurangkan bilangan tugas yang sedang dijalankan (dalam lajur "sedang berjalan"). Dalam Scrum, pasukan memberi tumpuan untuk berjaya menyelesaikan larian pecut; di Kanban, tugas diutamakan. Baik untuk projek yang berada di peringkat sokongan, di mana fungsi utama telah dibangunkan dan peningkatan minimum serta pembetulan pepijat kekal. Di Kanban, tugasan diserahkan secara individu. Tugas itu, tanpa mengira tugas lain, melalui semua peringkat di papan dan sebaik sahaja ia selesai ia boleh ditunjukkan kepada pelanggan. Papan Kanban terdiri daripada lajur, setiap satunya mewakili proses pembangunan yang berasingan. Sesetengah lajur (contohnya, sedang berjalan) mengenakan sekatan ke atas bilangan tugasan yang boleh ada. Ini membantu mencari kawasan masalah dengan mudah dan cepat dalam pengagihan tugas. Gambar menunjukkan contoh papan yang begitu mudah. Bilangan lajur dan nama mungkin berbeza-beza, tetapi saya akan menamakan yang paling biasa: Metodologi pembangunan perisian - 4
  • To do - senarai tugasan yang perlu dilakukan
  • Sedang dijalankan – tugasan yang sedang diusahakan
  • Semakan kod – tugasan yang telah diselesaikan dan dihantar untuk semakan
  • Dalam ujian – tugasan sedia untuk diuji
  • Selesai – selesai tugasan.
Kelebihan:
  • Kemudahan penggunaan.
  • Visualisasi (membantu dalam mencari kesesakan, memudahkan pemahaman)
  • Penglibatan pasukan yang tinggi dalam proses itu sendiri.
  • Fleksibiliti tinggi dalam pembangunan.
Kelemahan:
  • Senarai tugas yang tidak stabil.
  • Sukar untuk digunakan pada projek jangka panjang.
  • Tiada tarikh akhir yang sukar.

Kesimpulannya tentang metodologi pembangunan perisian

Pada pendapat saya, orang yang memegang jawatan pengurusan atau bercita-cita untuk mereka perlu mempunyai pemahaman yang menyeluruh tentang metodologi pembangunan perisian, tetapi adalah dinasihatkan untuk semua orang memahami sekurang-kurangnya asasnya. Ini adalah sebahagian daripada proses pembangunan dan digunakan bukan sahaja dalam bidang IT. Terima kasih kerana meluangkan masa untuk membaca artikel saya, saya harap anda dapati ia membantu. Saya cuba menerangkan hanya perkara utama dengan jelas dan ringkas yang mungkin, jadi artikel itu tidak lengkap. Saya akan gembira mendengar pendapat anda mengenainya dan menjawab soalan anda. Semua yang terbaik!
Komen
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION