Artikel terakhir saya
Rahasia sukses desain IP (sistem informasi) pada contoh pembangunan rumah sakit kadang-kadang menyebabkan diskusi panas di komentar. Karena itu, saya memutuskan untuk menyatakan sejumlah tesis berdasarkan diskusi ini.
Desain bukan untuk programmer
Sangat sering ketika membahas metode merancang dan menerapkan proyek sistem informasi, Anda mendengar kritik tentang metode ini oleh pengembang (programmer).
Terkadang pengembang tidak melihat bahwa, selain menulis kode, proyek memiliki komponen organisasi yang serius, yaitu untuk mengidentifikasi, merumuskan dan menyetujui persyaratan - tugas yang paling sulit adalah untuk mendidik pengguna dan membangun kembali semua proses - tidak hanya satu hari.
Pemrogram yang terhormat, untuk mengetahui APA yang harus dilakukan sistem, Anda tidak perlu tahu sama sekali C # atau JAVA, tetapi memiliki bidang studi. Untuk merancang sistem logistik, Anda harus menjadi ahli logistik: memiliki pengalaman di bidang ini atau di beberapa bidang serupa yang terkait. Oleh karena itu, ada analis bisnis yang bertugas menentukan penampilan fungsional sistem.
Paling-paling, pelanggan akan memberikan 30-50% dari informasi yang diperlukan, sisanya harus dipikirkan secara mandiri. Dan berpikir sangat kritis. Pada awalnya, pelanggan tidak tahu apa yang dia inginkan! Sebagai aturan, pengembangan bersama model bisnis terjadi, dan hanya kemudian daftar fungsi dikompilasi.
Ini membutuhkan pengetahuan tentang bidang subjek. Singkatnya, kita perlu memahami pelanggan: dia masih memberi tahu ide itu, dan Anda sudah tahu mengapa dia membutuhkannya dan yang paling penting, bagaimana ia dikelola, bagaimana bisnis seperti itu seharusnya bekerja, dan bukan hanya perangkat lunak.
Catatan Agile
Apakah Agile agama baru?
Topik diskusi Agile vs Teknologi desain (kaskade, air terjun, air terjun) lebih seperti perselisihan antara fanatik agama! Artikel itu bukan tentang Agile sama sekali, tetapi semua komentar tentang yang “fleksibel”. Teman-teman! Nah, apakah benar-benar mustahil untuk melihat lebih luas dan melihat bahwa untuk kedua metode itu ada tempat di bawah matahari ?!
Menurut pendapat saya, penolakan tajam Agile adalah reaksi terhadap dorongan yang sangat agresif dari teknologi ini. Mendengarkan "pengkhotbah" teknologi fleksibel, tampaknya sebelum Agile dunia tidak ada, tidak ada pengalaman bertahun-tahun dalam pengembangan perangkat lunak, dan secara umum, semua orang yang bekerja di hadapan kami adalah orang-orang bodoh dan pendosa yang mengerikan, karena Agile tidak tercerahkan. Naif! Pandangan dunia semacam itu khas untuk remaja, tetapi kami ...
Mari kita turunkan derajat dan cobalah untuk secara sadar mengevaluasi pendekatan yang berbeda untuk setiap proyek.
Agile tidak cocok di mana-mana, seperti halnya teknologi desain
Seperti yang ditulis oleh seorang komentator,
“Agile bukan untuk IT, dan bukan tentang IT. Agile untuk bisnis dan bisnis pro .
" Memang, kadang-kadang Anda perlu mendapatkan hasil yang sangat cepat, memasuki pasar dengan setidaknya sesuatu untuk dipertaruhkan tempat dan mencari investor. Atau ada pengembangan teknologi baru, persyaratan yang bermasalah. Ini jelas merupakan ceruk Agile.
Di sisi lain, di mana Anda menemukan cukup banyak pelanggan yang mau mengerjakan teknologi yang fleksibel? 70-80% pesanan di pasar adalah lembaga pemerintah yang menggunakan teknologi desain standar. Apalagi menurut GOST 34. Dan mereka membayar dengan baik untuk ini.
Selain itu, metode ini dapat digabungkan dalam satu pengembangan: inti dibuat menggunakan teknologi desain, dan beberapa bagian diciptakan oleh coba-coba (Agile). Ya, tidak semuanya mungkin untuk dipikirkan terlebih dahulu. Selain itu, ada fleksibilitas dalam teknologi desain: ada yang namanya operasi percobaan, di mana banyak yang bisa berubah.
Agile adalah cara pengembang berpikir
Saya tidak bisa menjamin untuk semua orang, tetapi tampaknya programmer berpikir "fleksibel", Agile memenuhi struktur pemikiran mereka! Bagaimanapun, pemrograman adalah pencarian konstan untuk solusi terbaik. Anda duduk di tugas, Anda masih tidak tahu bagaimana itu harus diselesaikan. Anda tidak dapat memprediksi sebelumnya hasilnya, atau tenggat waktu (ya, Anda melipatgandakan tenggat waktu pengembang dengan 6-10 kali dan ini adalah satu-satunya cara Anda mendapatkan gambaran nyata, karena mereka lupa tentang pengujian dan peningkatan). Ini adalah pemikiran banyak programmer, karena mereka adalah individu yang kreatif. Jadi, Anda tidak perlu memaksa individu kreatif untuk terlibat dalam kebosanan proyek. Untuk melakukan ini, ada analis, manajer proyek.
Kami menyadari bahwa Agile adalah inti dari pengembang pemikiran. Tetapi pelanggan berpikir sebaliknya! Dan pelanggan ingin memahami apa yang dia bayar, "sentuh" hasil masa depan, sebelum pengembangan dimulai. Dan kemudian itu menghasilkan permainan dengan satu tujuan: nyaman bagi pengembang, dan pelanggan tidak tidur di malam hari, pikirkan apakah itu akan berhasil atau tidak, dan jika berhasil, apa yang terjadi ketika itu berhasil dan berapa biayanya. Tetapi untuk programmer Laf, saya bekerja dengan tenang, apa yang akan saya lakukan, maka saya akan melakukannya ketika saya selesai, maka saya akan menyelesaikan sebanyak yang saya minta, mereka akan membayar begitu banyak. Bukan begitu?
Tetapi kadang-kadang pelanggan harus mengatakan demikian: kami melakukan hal-hal baru, oleh karena itu kami tidak siap untuk memprediksi waktu, biaya, atau hasil. Apakah kamu setuju? Lalu kita lakukan. Setidaknya ini jujur.
Selalu nyalakan kepala Anda
Pengembangan perangkat lunak berbeda dari bidang lain dalam hal Anda mempelajari sesuatu sepanjang waktu. Setiap proyek seperti dunia baru. Setiap proyek memiliki persyaratannya sendiri. Karena itu, kepala harus selalu dihidupkan. Jangan terpaku hanya pada satu teknik, satu pendekatan. Saya harus berimprovisasi, hampir selalu.
Untuk mengkritik sesuatu, Anda perlu mempelajarinya.
Ketika mengkritik teknologi desain atau Agile, kritik jarang tahu subjek kemarahan mereka. Ada sangat sedikit yang benar-benar belajar (termasuk standar: GOST, ISO, IEEE) dan mencoba menerapkan teknologi desain secara serius. Tapi kritiknya cukup. Sangat sedikit tim yang benar-benar sukses (sehingga klien puas!) Terapkan Agile, tetapi ada cukup "pengkhotbah".
Dan lagi, jangan bingung Agile dan kekacauan. Jika Anda tidak tahu cara mendesain dan karena itu memilih metode yang fleksibel, maka Anda akan berantakan.
Aplikasi Agile yang sukses mungkin membutuhkan lebih banyak upaya daripada teknologi desain. Koherensi tim yang lebih tinggi, kualifikasi anggotanya, kemampuan untuk menemukan bahasa yang sama dengan pelanggan.
Baca artikel lain oleh penulis: