Seberapa baik produk perangkat lunak harus ditetapkan sebelum mulai kode?


13

Saya ingin tahu seberapa baik orang pada umumnya mendefinisikan produk perangkat lunak sebelum benar-benar mulai kode dan seberapa baik itu bekerja untuk mereka? Saya mengacu pada mendefinisikan kasus penggunaan, menganalisis risiko, menggambar diagram kelas, dll.

Saya tahu bahwa adalah ide yang baik untuk memiliki ide yang cukup baik tentang apa produk akhir akan dapat menghindari risiko di masa depan, tetapi juga penting untuk tidak mendefinisikan suatu produk dengan baik sehingga sulit untuk beradaptasi dengan perubahan.

Pertanyaan lain yang lebih spesifik mungkin adalah:

  1. Berapa persentase waktu proyek yang biasanya dihabiskan pada tahap perencanaan sebelum pengembangan?

  2. Apakah Anda memiliki kriteria terukur tertentu yang coba Anda penuhi sebelum mulai kode atau lebih merupakan intuisi?

  3. Apakah Anda membuat diagram semua kelas sebelum mulai kode, atau sebagian besar mencoba membuat desain dinamis dari awal dengan harapan hal-hal akan berubah?

Setiap pengalaman yang Anda ingin bagikan akan luar biasa!

Jawaban:


10

Jawaban literal untuk "seberapa baik didefinisikan?" adalah

Cukup jelas sehingga Anda bisa memulai.

Cukup terdefinisi dengan baik sehingga Anda dapat mengidentifikasi ruang lingkup kerja awal (untuk konsep awal). Ini cukup untuk membantu mengidentifikasi perubahan yang pasti akan terjadi.

Cukup jelas sehingga Anda dapat memprioritaskan sprint.

Saya mengacu pada mendefinisikan kasus penggunaan,

Selalu membantu. Tapi tidak semua . Anda harus memprioritaskan dan membahas kasus penggunaan penting terlebih dahulu. Kasus penggunaan lainnya akan dibahas dalam rilis selanjutnya. Beberapa kasus penggunaan akan menjadi prioritas sangat rendah sehingga mereka tidak akan pernah selesai.

menganalisis risiko,

Umumnya buang-buang waktu.

menggambar diagram kelas, dll.

Jika itu membantu.

Berapa persentase waktu proyek yang biasanya dihabiskan pada tahap perencanaan sebelum pengembangan?

Sangat bervariasi. Beli buku yang bagus, seperti Ekonomi Rekayasa Perangkat Lunak untuk mendapatkan angka "resmi".

Apakah Anda memiliki kriteria terukur tertentu yang coba Anda penuhi sebelum mulai kode atau lebih merupakan intuisi?

"terukur". Itu hampir mustahil untuk didefinisikan.

"usus". Kebijakan yang buruk.

Masalahnya adalah "apakah Anda mengerti apa yang Anda lakukan?"

Itu bukan hal yang penting. Itu pertanyaan Ya / Tidak.

Itu tidak "terukur" karena itu hanya pertanyaan ya / tidak.

Dan, lebih lanjut, Anda harus memprioritaskan. Anda tidak melakukan segalanya. Cukup untuk menangani beberapa sprint pertama.

Apakah Anda membuat diagram semua kelas sebelum mulai kode, atau sebagian besar mencoba membuat desain dinamis dari awal dengan harapan hal-hal akan berubah?

Anda tidak dapat mengetahui segalanya sebelumnya.

Jangan coba-coba.


secara pribadi saya menemukan menghabiskan terlalu banyak waktu menulis diagram kelas adalah buang-buang waktu karena model dan kode dengan itu tetap berubah setelah Anda mulai.
AndersK

Saya setuju bahwa Anda tidak dapat mengetahui semuanya terlebih dahulu, tetapi dokumen desain yang baik setidaknya akan membantu Anda mengidentifikasi ruang lingkup dan fitur merayap ketika itu terjadi.
Pos Tim

@Tim Post: Saran bagus. Itu cara untuk mendefinisikan "seberapa baik didefinisikan" dalam pertanyaan. Ini akan "membantu Anda mengidentifikasi cakupan dan fitur creep." Tidak lebih, kan?
S.Lott

@Tim Post: "mengidentifikasi ruang lingkup" menyesatkan. Ini menyiratkan bahwa ada beberapa pengetahuan pasti tentang "ruang lingkup" yang tersedia untuk Anda pada awal proyek, yang tidak benar. Lingkup akan berubah sepanjang siklus proyek karena kebutuhan bisnis berubah, karena tidak ada pasar yang statis.
Rein Henrichs

@Rein Henrichs: Saya sedikit mengubah jawaban untuk memasukkan poin Anda. Cukup definisi ruang lingkup untuk memulai. Saya tergoda untuk menambahkan "dan tidak lebih."
S.Lott

2

Jika klien Anda secara aktif bergabung dengan proyek sebagai anggota tim proyek, yang tersedia untuk pengembang untuk pertanyaan dan membuat keputusan cepat tentang fungsionalitas. Maka specnya bisa kurang detail.

Jika klien Anda jauh dan tidak tersedia untuk umpan balik dalam jangka waktu yang lama, maka spesifikasi Anda harus sangat rinci.

Di perusahaan kami, kami membuat kisah pengguna dan bermain Poker Perencanaan dengan pengembang di proyek tersebut. Itu memberi kami indikasi yang adil tentang jam yang akan dihabiskan untuk cerita pengguna.


"Perwakilan Pelanggan" (peran yang Anda sarankan untuk klien) adalah peran paling vital di seluruh tim. Jika tim Anda tidak bisa mendapatkan jawaban tentang produk dan pertanyaan bisnis, bagaimana mereka seharusnya membuat keputusan yang tepat?
Rein Henrichs

Itu poin yang bagus, terima kasih! Saya tidak mempertimbangkan bagaimana keterlibatan klien dapat secara drastis mengubah apa yang terbaik untuk proyek tertentu. Pasti sesuatu yang harus saya ingat. Juga, saya belum pernah mendengar tentang "Perencanaan Poker" dan sepertinya itu akan sangat berharga.
drewag

2

Seberapa baik proyek yang didefinisikan perlu cukup baik untuk membantu Anda memulai dan tahu ke mana Anda akan pergi untuk dua minggu ke depan.

Sebagai Scrum Master, saya hanya akan mengatakan bahwa Anda perlu mendefinisikan fitur-fitur kotor produk Anda dalam lembar Excel atau di mana pun, hanya untuk melacak fitur-fitur Anda. Membuatnya User Stories banyak membantu memikirkan fitur apa yang Anda butuhkan selanjutnya. Kemudian, prioritaskan mereka: Fitur Paling Penting atau Imperatif ke Atas, dan Paling Tidak ke Bawah.

Setelah Anda mendaftar beberapa fitur yang paling penting, pilih fitur yang Anda pikir dapat Anda kembangkan menjadi status Selesai setelah periode dua minggu, atau periode sebulan jika Anda mau. Kemudian, ledakkan fitur yang dipilih ini sehingga Anda dapat mulai mengkodekan beberapa.

Saat melakukan pengkodean, Anda tentu akan memikirkan elemen lain yang perlu dikembangkan untuk menghadirkan fitur yang Anda pilih dalam status Selesai. Selesai berarti Anda tidak perlu melakukan apa-apa lagi, yaitu, pengujian, pengkodean, perakitan, dokumentasi Selesai!

Kapan saja daftar fitur yang Anda pilih dapat berkembang, selama Anda bertemu dengan tujuan, yaitu, Anda dapat mengembangkan semua yang Anda katakan selama periode tertentu.

Singkatnya, tidak ada yang sempurna. Lemparkan beberapa ide, bagikan dengan rekan Anda dan lihat apakah yang tertulis masuk akal untuk memenuhi persyaratan produk yang diminta. Jika demikian, maka Anda masuk! Untuk memperjelasnya, saya akan menggunakan produk Manajemen Pelanggan yang sederhana. Apa yang dibutuhkan?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

Draf pertama Anda bisa sesederhana itu! Kemudian, kita dapat melihat bahwa keamanan adalah bagian penting dalam sistem kita, apakah cukup penting untuk membuat prioritas utama (Y / T)? Ini akan tergantung pada persyaratan yang harus Anda penuhi. Katakanlah Manajemen Pelanggan adalah hal yang paling penting di sini. Jadi, dalam Sprint berikutnya, kita harus dapat mengelola pelanggan dengan cara dasar tetapi dapat diterima. Apa itu Manajemen Pelanggan?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Ini sudah menggambarkan fungsi yang cukup untuk dapat mulai mengembangkan aplikasi. Jika programmer Anda memerlukan instruksi lebih lanjut, maka mungkin satu pengembang yang merasa nyaman dengan diagram kelas dapat merancang kelas Pelanggan dan properti serta metodenya! Tetapi sejauh yang saya ketahui, dengan sedikit ini saya telah menulis, saya akan memiliki cukup untuk memulai. Beberapa fitur dapat ditambahkan atau diubah di sepanjang jalan. Yang penting adalah fokus pada apa yang Anda katakan akan Selesai. Dalam contoh kami, ini adalah hal Manajemen Pelanggan. Kami tidak perlu peduli dengan otentikasi pengguna seperti sekarang. Ini akan datang nanti di Sprint berikutnya.

Saya harap ini membantu! =)


Terima kasih banyak! Sangat menyenangkan melihat ini dalam skenario yang spesifik. Saya merasa ini adalah kerangka kerja yang baik untuk memiliki sesuatu yang setidaknya dapat diukur berkaitan dengan apa yang Anda definisikan tentang keseluruhan produk tetapi menekankan sub-tujuan dan pendekatan yang berorientasi fitur. Pendekatan ini pasti akan menjadi penting ketika saya memulai proyek baru di masa depan!
drewag

Sama-sama! Saya senang butiran garam saya bisa membantu Anda! =) Penting untuk tidak mendefinisikan terlalu banyak fitur yang mendalam, karena persyaratan produk dapat berubah sepanjang jalan karena klien, ketika dia akan melihat apa yang telah Anda lakukan sejauh ini, mungkin memiliki ide atau perubahan lain untuk membuat apa yang telah Anda lakukan. Selesai Anda harus menyesuaikan produk sehingga memenuhi persyaratan baru. Jadi, jika Anda menyelesaikan semuanya sekaligus di awal proyek, bayangkan kehilangan pekerjaan yang diakibatkannya! Mungkin Anda akan bekerja berjam-jam hanya untuk membuangnya dan memulai kembali dari awal. Biarkan itu berevolusi =)
Will Marcouiller

1

Nah, apa yang bekerja sangat baik bagi saya adalah memiliki fungsionalitas "cukup baik" ditentukan dan arsitektur perangkat lunak hanya sangat longgar.

Agar saya dapat mulai bekerja, saya perlu tahu apa yang sedang saya upayakan. Itu tidak berhasil bagi saya ketika saya hanya memahami kebutuhan pelanggan. Bahkan jika saya menulis alat untuk saya gunakan sendiri, saya menggambar layar, menjelaskan fungsionalitas, apa yang dilakukan setiap tombol, semuanya. Kalau tidak, saya menemukan saya tidak bisa memulai.

Di sisi lain, saya sudah menyerah untuk benar-benar menggambar persis bagaimana saya akan mengembangkan kode. Mungkin ini adalah praktik terburuk, tetapi itu berhasil untuk saya. Saya mungkin mendefinisikan satu set tabel database yang akan saya buat, tetapi tidak kolom apa di masing-masing. Saya mungkin berpikir tentang objek dan kelas apa yang saya butuhkan, tapi saya jelas tidak menggambar diagram.

Sial, kadang-kadang saya bahkan tidak tahu bagaimana melakukannya dengan benar sampai setelah saya melakukan kesalahan. Saya membangunnya sekali, merobohkannya, dan melakukannya lagi, sekarang saya tahu caranya. Pada titik ini saya dapat menggambar peta jalan yang cukup rinci dan memulai kembali.


Terima kasih telah berbagi pengalaman Anda. Tampaknya sejalan dengan konsensus bahwa yang penting adalah Anda, sebagai pengembang, merasa cukup nyaman untuk memulai. Tentu saja Anda akan menemukan hal-hal yang akan Anda ubah jika Anda melakukannya lagi, jika tidak, Anda menghabiskan terlalu banyak waktu untuk merencanakan. Saya tahu perasaan ingin melakukan penulisan ulang lengkap segera setelah produk selesai, dan itulah yang saya coba hindari;) (setidaknya pada tingkat yang masuk akal).
drewag

1

Bahasa dan metodologi apa yang Anda gunakan?

Beberapa bahasa, seperti Java dan C ++, membutuhkan lebih banyak struktur awal daripada bahasa seperti Common Lisp atau Python (C ++ lebih dari Java, karena refactoring lebih mudah di Java). Leo Brodie (saya pikir dalam "Thinking Forth") memberikan dua nasihat tentang kapan memulai coding: lebih cepat daripada Anda merasa nyaman dengan Forth, lebih lambat daripada yang Anda inginkan dalam bahasa lain.

Metodologi air terjun (terutama ketika desain awal dapat disampaikan) akan membutuhkan pekerjaan di muka yang lebih tinggi daripada gesit (meskipun Anda juga tidak ingin mengabaikan perencanaan awal dalam metode tangkas). Memiliki serangkaian tes otomatis yang baik membuatnya lebih aman untuk mengubah hal-hal yang lebih besar, dan karena itu memungkinkan Anda bertahan dengan pekerjaan yang kurang di muka.

Juga, itu tergantung pada individu dan keakraban mereka dengan jenis perangkat lunak yang akan dibuat. Pada satu titik, ketika melakukan terutama aplikasi CRUD, saya bisa menulis seluruh program dimulai dengan beberapa spesifikasi dan selembar kertas kosong 3 "x5". Saya tidak dapat menulis hal-hal yang saya tulis sekarang seperti itu.


Terima kasih atas perspektifnya. Saya belum mempertimbangkan bagaimana bahasa dan platform dapat memengaruhi praktik terbaik dalam hal manajemen proyek. Saya kebetulan berbicara sebagian besar tentang Objective-C, UIKit, dan AppKit. Namun saya juga bekerja di banyak bahasa lain (C, C ++, C #, Java, Python, dll). Itu berarti bahwa saya harus berhati-hati untuk tidak menganggap metode tertentu yang terbaik untuk semua proyek, saya harus menyesuaikan basis metodologi saya pada platform target dan bahasa (dan mungkin memilih bahasa berdasarkan itu jika saya punya pilihan).
drewag

1

Dua istilah yang berguna di sini adalah MVP (Produk yang Layak Minimum) dan MMF (Fitur yang Dapat Dipasarkan Minimum). MMF adalah versi terkecil dari fitur yang memberikan nilai bisnis. MVP adalah MMF paling sedikit yang layak sebagai produk. Saat memulai proyek, hal terbaik yang harus dilakukan adalah mengidentifikasi MMF dan MVP dan mulai dari sana.

Lepaskan produk Anda segera setelah layak, lalu terus tingkatkan secara bertahap.


Itu adalah istilah yang sangat bagus, terima kasih! Sejauh ini yang terbaik di sini untuk datang dengan sesuatu yang terukur. Tentu saja itu tidak sempurna, tetapi sepertinya akan cukup mudah untuk memutuskan apakah suatu fitur dapat dipasarkan dan / atau itu menambah nilai pada produk.
drewag
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.