Bisakah Agile diselesaikan tanpa keterlibatan klien?


23

Saya tidak bisa menulis buku tentang Agile. Saya telah bekerja di beberapa toko yang menyebut proses mereka Agile. Salah satu poin utama pengembangan Agile adalah keterlibatan klien secara teratur. Setelah sprint, karya dapat didemonstrasikan ke klien untuk mendapatkan umpan balik mereka. Bilas dan ulangi.

Masalah yang saya temui adalah banyak klien yang tidak ingin terlibat. Mereka lebih suka pendekatan air terjun. Kumpulkan persyaratan di muka, lalu kembali ketika Anda selesai. Menurut pengalaman saya, air terjun tidak berfungsi. Klien tidak tahu apa yang mereka inginkan sampai mereka melihatnya. Dilema air terjun selanjutnya diperbanyak oleh komunitas besar pengembang yang ingin memiliki semua persyaratan di muka. Dengan cara ini mereka tahu apa yang sedang mereka bangun, mereka dapat membuat arsitek yang sesuai, dan klien yang harus disalahkan karena mereka "menandatangani" persyaratan tersebut.

Apakah saya salah? Bisakah Agile bekerja tanpa keterlibatan klien? Jika demikian, bagaimana dan bagaimana Anda mengatasi masalah yang saya diskusikan?


12
Jangan biarkan "gesit" menjadi palu Anda sehingga segala sesuatu yang lain tampak seperti paku yang perlu ditumbuk untuk Anda.
Patrick Hughes

1
Dalam pengalaman saya, preferensi terhadap pendekatan air terjun umumnya karena kurangnya pemahaman bagaimana perangkat lunak atau desain bekerja. Berita baiknya adalah bahwa Agile bukan masalah besar, itu adalah sikap / pemahaman klien. Berita buruknya adalah sikap klien.
Ben Brocka

@ BenBrocka: Itu tidak terlalu mengejutkan, mengingat itulah yang dirancang khusus untuk Waterfall. Penulis ingin menulis makalah tentang seperti apa proses pengembangan yang dibuat oleh seseorang yang tidak mengerti pengembangan perangkat lunak dan mengapa proses seperti itu tidak mungkin berhasil. Jadi, ia secara khusus menemukan Waterfall sebagai contoh proses yang dirancang oleh seseorang yang tidak mengerti pengembangan perangkat lunak dan itu tidak mungkin berhasil. Jelas, itu tidak mengherankan bahwa itu menarik bagi orang-orang yang tidak memahami pengembangan perangkat lunak juga tidak mengejutkan ...
Jörg W Mittag

@ BenBrocka: ... bahwa itu tidak berhasil. Yang mengejutkan adalah mengapa ada orang yang bahkan ingin menggunakan proses yang secara khusus dirancang untuk tidak bekerja. Saya kira tidak ada yang mau benar-benar membaca koran.
Jörg W Mittag

1
@ JörgWMittag Pengadopsian Air Terjun yang sebenarnya (apakah mereka menyadari air terjun atau tidak) sebagian besar hanya karena itu adalah model standar keputusan bisnis; Bos menginginkan sesuatu, bawahan melakukannya, pelanggan senang, bukan? Tentu saja itu tidak berhasil, tetapi ini adalah model sederhana yang bagus untuk pikiran sederhana yang bagus :)
Ben Brocka

Jawaban:


17

Bagaimana mungkin? Sifat dasar dari teknik ini menentukan semacam lingkaran umpan balik antara pelanggan dan pengembang.

Namun, beberapa bagian dari tim Anda dapat bertindak sebagai pelanggan "proxy" (proses serupa dengan "makan makanan anjing Anda sendiri") sehingga Anda dapat "berpura-pura" gesit, meskipun itu tidak akan memuaskan seperti mendapatkan pelanggan yang sebenarnya. umpan balik.

Suka atau tidak, pelanggan akan terlibat dalam proses desain; itu hanya masalah berapa banyak mereka ingin biaya pengerjaan ulang (semakin lama ditunda, semakin mahal itu).

Karena pelanggan menginginkan "Desain Besar di Depan," bantu mereka memahami bahwa akan lebih banyak waktu dan usaha di muka mereka untuk mendapatkan desain yang benar pertama kali.


5
Namun, bagian dari tim Anda dapat bertindak sebagai pelanggan "proxy" - dalam pengalaman saya, penguji membuat "proxy" yang cukup efektif dari jenis yang Anda sebutkan. Ketika saya sendiri seorang tester, saya kadang-kadang juga berpura-pura mengenakan jas pelanggan untuk berbicara. Proxy seperti itu memiliki keterbatasan - misalnya QA pria mengeluh tentang berapa banyak waktu yang diperlukan untuk menginstal produk mungkin hanya merasa seperti itu karena mereka melakukannya setiap hari sementara pelanggan melakukannya sekali atau dua tahun sekali
nyamuk

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).Untuk siapa itu sebenarnya lebih mahal? Sebagian besar klien tidak melihatnya membayar waktu Anda untuk mendapatkan visi mereka saat ini dari solusi yang ada. Terkadang mereka hanya memiliki masalah dan tidak memiliki cara untuk mengetahui apa solusi yang seharusnya sampai Anda memberi tahu mereka apa yang akan terjadi. Pada saat itu jika apa yang Anda katakan tidak benar-benar menyelesaikan masalah mereka, maka itu adalah KESALAHAN ANDA bukan masalah mereka. Bagaimana kesalahan mereka bahwa Anda salah memahami masalah mereka yang sebenarnya? cont ...
maple_shaft

cont ... mengapa mereka harus membayar untuk itu? Hanya untuk menyelamatkan muka dengan pelanggan dan tidak sepenuhnya mengabaikan setiap kesempatan di bisnis yang berulang maka Anda harus berbalik dan melakukan pengerjaan ulang secara gratis karena mereka menuntut kontrak harga tetap di tempat pertama. Ini adalah sikap yang lebih umum dan persis apa yang dialami P.Brian.Mackey. Pelanggan kuat mempersenjatai negosiasi ini dan ketika Anda hanya salah satu dari 100 startup yang mencoba untuk mencetak kontrak maka orang dengan kontrak berbasis Agile realistis dan adil harus menunggu di belakang garis. SULIT di luar sana sekarang.
maple_shaft

@maple_shaft: Jelas Anda telah dibakar oleh ini. Tetapi, seperti halnya dengan semua hal, itu tergantung pada pilihan. Agile ada karena air terjun memiliki masalah dan orang tidak sempurna. Jika klien telah diberitahu tentang risikonya, dan tetap menginginkan air terjun, itulah pilihan mereka. Ini juga pilihan toko perangkat lunak untuk memutuskan apakah layak atau tidak berisiko mengambil air terjun pada klien yang tidak memahami risiko, atau menyangkal validitas risiko tersebut.
Robert Harvey

@RobertHarvey Bahkan klien yang buruk dalam ekonomi yang buruk masihlah seorang klien dan mereka tetap menyalakan lampu selama beberapa bulan lagi. Risiko untuk klien dalam kasus yang saya sebutkan minimal dan terkendali apakah mereka menerima solusi yang dijanjikan tepat waktu. Risiko untuk toko perangkat lunak dalam kasus ini adalah jika klien yang kesakitan di belakang ini akan menyedot kita kering.
maple_shaft

7

Jawaban singkat untuk pertanyaan Anda adalah 'tidak'. Berikut adalah komentar pada beberapa bagian dari pertanyaan Anda. Agar akurat, sebagian besar jawaban didasarkan pada pengalaman dan pengamatan pribadi saya.

Menurut pengalaman saya, air terjun tidak berfungsi.

Waterfall adalah metodologi yang kuat untuk menghadirkan sistem dengan kompleksitas yang beragam. Sangat disayangkan bahwa itu tidak disajikan dengan baik atau dipahami. Salah satu alasannya adalah karena tidak menghasilkan uang yang cukup bersaing dengan metodologi hari itu yang terus bermunculan. Anda mungkin terkejut mengetahui bahwa banyak sistem perbankan, asuransi dan manufaktur dibangun hanya dengan menggunakan pendekatan Waterfall dan banyak dari mereka yang masih dalam produksi hari ini. Sangat menyedihkan bahwa industri perangkat lunak didasarkan pada hype lebih dari sains.

Klien tidak tahu apa yang mereka inginkan sampai mereka melihatnya.

Ini hanya mitos. Yang besar juga. Ini mungkin terjadi dalam desain / tata letak halaman web tetapi untuk pemrosesan data bisnis, sebagian besar pengguna menginginkan sesuatu yang berfungsi. Beberapa dari pengguna tersebut masih menggunakan layar AS / 400 dan 3270 monitor CICS dengan RGB dan mereka dapat menyelesaikan urusan mereka dengan alat-alat itu. Juga, para pengguna yang sama menerima sistem ERP SAP dan ORACLE tanpa memiliki suara dalam desain antarmuka (dan beberapa kali dalam fungsi). Sebagian besar pengguna bisnis bahkan akan menyesuaikan kebiasaan dan aliran kerja mereka jika sistem menghasilkan fungsi yang benar. Stres di sini adalah pada fungsi tidak terlihat. Pelaku bisnis mengerti bagaimana mereka melakukan pekerjaan mereka dengan sangat baik 90% dari waktu.

Dilema air terjun selanjutnya diperbanyak oleh komunitas besar pengembang yang ingin memiliki semua persyaratan di muka. Dengan cara ini mereka tahu apa yang sedang mereka bangun, mereka dapat membuat arsitek yang sesuai, dan klien yang harus disalahkan karena mereka "menandatangani" persyaratan tersebut.

Anda tidak dapat menyalahkan pengembang karena ingin tahu apa yang mereka bangun karena para pengembang ingin pulang memasak makan malam dan menekan baju mereka untuk latihan lain setelah mereka menghabiskan 3 jam atau lebih mempelajari teknologi berikutnya. yang akan menggantikan keahlian mereka saat ini! Permainan menyalahkan membuat tidak ada yang menjadi pemenang. Pikirkan dalam hal peran dan tanggung jawab masing-masing pihak dan gambarannya akan sangat jelas.

Sebagai kesimpulan, manajer proyek, Programmer, dan Desainer Web tidak ada pengganti untuk Analis Bisnis yang harus tahu cara mengumpulkan persyaratan dari pengguna akhir terlepas dari metodologi.


3
+1 - Untuk yang berpendapat "klien tidak tahu". Ini adalah masalah berbagai domain yang memiliki berbagai jenis klien. Inilah sebabnya mengapa agilis tidak dapat memahami air terjun orang. Mereka percaya bahwa Anda hanya bisa mengatakan apa yang Anda inginkan ketika Anda melihatnya. Itu tidak benar, tetapi hanya itu yang mereka lihat dari pelanggan mereka. Sementara pendukung air terjun tidak dapat memahami mengapa Anda tidak bisa memahami sebagian besar persyaratan di muka sehingga desain dapat mempertimbangkan semua masalah. Itu mungkin karena air terjun orang tidak berurusan dengan pelanggan mau tak mau sangat.
Dunk

1
@Dunk, terima kasih atas komentar Anda. Saya suka kata-kata Anda pelanggan yang mau tak mau!
NoChance

2

Mereka tidak ingin memasukkan waktu dan jika diberi pilihan mereka lebih suka mendapatkan perangkat lunak secara gratis, tetapi Anda masih akan membebankan biaya, kan? Ini menjadi kabur jika Anda mengembangkan perangkat lunak secara internal untuk perusahaan Anda. Mereka pikir Departemen TI telah dibeli dan dibayar (karyawan yang digaji), sehingga mereka mungkin mendapatkan sebanyak mungkin pekerjaan Anda.

Anda dapat berpotensi gesit. Dapatkan semua spesifikasi dan mulai koding. Setelah klien menyela pekerjaan karena mereka hanya berpikir tentang soomething dan Anda harus membuat perubahan dan pengerjaan ulang, Anda menjadi sedikit lebih gesit. Anda juga bisa melakukan persetujuan dalam tim Anda. Mintalah salah satu tim Anda mengenakan jas dan dasi dan berpura-pura menjadi pelanggan.

Membuat komitmen waktu yang besar di depan mungkin membuat mereka takut. Sarankan melakukan sprint untuk mencobanya. Kemudian beri mereka kesempatan untuk memilih keluar. Anda selalu dapat beralih ke air terjun selama sisa proyek. Juga menyarankan bahwa orang yang berbeda di tim mereka dapat melakukan peninjauan dan menyetujui jika waktu menjadi kendala bagi orang yang menulis cek.

Pada titik tertentu, Anda harus memberi tahu mereka bahwa Anda tidak berpikir air terjun akan berfungsi. Tanyakan kepada mereka apakah mereka puas dengan pendekatan ini dan jika demikian, mengapa mereka tidak memiliki orang terakhir yang melakukan proyek ini?


2

Tidak ada metodologi yang dapat bekerja tanpa keterlibatan klien. Keluar dari persyaratan bisa menjadi tidak berarti ketika saya menyaksikan dalam proyek yang saya ikuti. Masalah Anda melampaui kemampuan Agile, Anda perlu mendidik klien Anda dan memastikan mereka memahami betapa pentingnya bagi mereka untuk berpartisipasi.


2
Bukankah ini masalah jumlah dan frekuensi partisipasi oleh klien dan bukan masalah semua atau tidak sama sekali?
JeffO

3
Seorang klien yang menolak untuk sering berpartisipasi menurut saya, seorang klien yang membutuhkan pendidikan. Sudah lazim bagi para pakar bisnis klien untuk menempatkan pada posisi di mana mereka harus berinteraksi dengan perusahaan pengembang perangkat lunak dan masih melakukan kegiatan sehari-hari mereka dan yang perlu ditangani dengan berbicara dengan atasan mereka.
Otávio Décio

2

Saya pikir salah satu manfaat utama Agile adalah kemampuan untuk mendapatkan persyaratan yang lebih terperinci untuk setiap fitur secara keseluruhan. Ketika klien memberikan semua persyaratan mereka dimuka, setiap fitur cenderung menjadi ide yang samar, dengan sedikit fungsionalitas yang ditentukan. Pasukan Agile klien untuk meninjau kembali setiap fitur dan fokus pada apa yang mereka inginkan dan bagaimana fitur tersebut akan masuk ke dalam gambaran yang lebih besar. Untuk mendapatkan jumlah detail yang sama (detail yang cukup untuk mengimplementasikan fitur-fitur) ke dalam spesifikasi, air terjun benar-benar mengharuskan Anda melakukan salah satu dari dua hal berikut:

  1. Kira. Terapkan sampai Anda menemukan sesuatu yang tidak jelas, lalu buat penilaian tentang bagaimana Anda merasa fitur tersebut paling baik diimplementasikan. Ini jelas tidak ideal, karena mengarah ke "Tunggu, bukan itu yang saya minta!" skenario.

  2. Berikan jauh lebih banyak penekanan pada desain dimuka. Pada dasarnya, ketika klien melempar spek setengah matang mereka pada Anda pada hari pertama, rencanakan untuk memeriksa setiap detail setiap menit sebelum menerapkan apa pun. Minta klien untuk mengklarifikasi semuanya ad nauseum ke titik di mana Anda tahu setiap detail implementasi untuk seluruh proyek. Meskipun tidak sempurna, ini lebih baik daripada opsi 1. Anda mungkin masih mengalami detail yang belum Anda antisipasi, dan bahkan mungkin mengirim klien berlari ke bukit, tetapi jika mereka benar-benar tidak ingin berkomunikasi selama pengembangan dan Anda bukan psikis, ini suatu keharusan. Ini pada dasarnya adalah air terjun, dan ia datang dengan semua kelemahan yang terkait, termasuk menjadi sangat sulit untuk dieksekusi dengan baik.

  3. Ambil spek setengah matang, tetapi mintalah klarifikasi saat Anda melanjutkan. Bekerja sampai Anda mencapai bagian yang tidak jelas dari spesifikasi, lalu minta klien untuk mengklarifikasi. Tentu saja, ini bukan yang diminta klien, tetapi jika mereka tidak ingin aplikasi keruh seperti spesifikasi dan menolak untuk menentukan spesifikasi di muka, ini adalah satu-satunya pilihan yang tersisa. Ini tidak memiliki semua manfaat Agile (seperti persetujuan klien reguler untuk memastikan semua orang ada di halaman yang sama), namun, itu memungkinkan Anda untuk mendapatkan informasi yang Anda butuhkan untuk dikembangkan. Karena opsi 1 mungkin akan meninggalkan Anda dengan produk sub-par, opsi 2 boros dan membuat frustrasi klien (Anda mungkin perlu menghabiskan setidaknya dua kali lebih banyak waktu untuk desain dan pengumpulan spec keseluruhan jika Anda melakukannya sepenuhnya di depan), ini benar-benar bukan pilihan yang buruk. Kuncinya di sini adalah untuk rajin memodifikasi garis waktu dan harga dengan setiap perubahan yang muncul. Jika Anda melakukannya dengan benar, Anda mungkin menemukan bahwa sebagian besar praktik Agile kompatibel dengan pengaturan ini, bahkan jika klien tidak mengetahuinya. IMHO, ini benar-benar sesuai dengan semangat Agile, karena Anda seharusnya menyesuaikan metodologi dengan pengaturan khusus Anda.

Jika klien benar-benar tidak dapat hidup dengan konsekuensi dari salah satu dari ketiga opsi ini atau Agile yang penuh sesak nafas, saya kesulitan membayangkan bagaimana klien ini benar-benar bernilai saat Anda.


Anda meninggalkan opsi 4. Anda mengambil spesifikasi dengan sebagian besar persyaratan. Lakukan desain (mungkin iteratif) dengan ulasan pelanggan. Terapkan dan uji kodenya (mungkin iteratif). Mengadakan tinjauan program berkala yang menginformasikan pelanggan tentang kemajuan dan keputusan. Mereka memberikan umpan balik, Anda memasukkan komentar mereka dan melanjutkan.
Dunk

Situasi yang Anda jelaskan di atas hanya akan terjadi dengan tim yang tidak tahu bagaimana melakukan air terjun. Ya, sulit untuk mengeksekusi dengan benar. Agile juga sulit dieksekusi dengan baik. Setiap kali seseorang gagal pada gesit, beberapa agilis mengeluarkan aturan baru yang tidak diikuti dan mengklaim itulah alasan kegagalan. Itu bukan kesalahan lincah. Setidaknya pendukung air terjun mengakui bahwa dibutuhkan orang-orang baik dengan keterampilan yang baik untuk membuat air terjun bekerja.
Dunk

Opsi Anda 4 persis seperti yang saya maksudkan pada opsi 3.
Morgan Herlocker

Bagaimana saya bisa membuat jawaban saya lebih baik? Saya tidak tahu apakah Anda setuju atau tidak setuju dengan apa yang saya katakan.
Morgan Herlocker

Anda dapat memperbaikinya dengan mungkin mengeluarkan kata setengah matang untuk pemula. Hapus bagian tentang ini bukan yang diinginkan pelanggan. Hapus bagian spesifikasi yang keruh, dll. Dalam air terjun, bagian penting dari menangkap persyaratan adalah untuk mendapatkan yang signifikan secara arsitektural dan yang harus dilakukan oleh sistem untuk menjadi berguna di depan. Setelah itu, perubahan biasanya bukan masalah besar. Percaya atau tidak, ada dan selalu ada iterasi, baik formal maupun informal dalam pengembangan air terjun. Jauh sebelum lincah datang.
Dunk

1

Saya pikir itu sulit tetapi masih mungkin. Saya pikir ide proxy Robert bekerja tetapi perlu bagi proxy untuk menghabiskan waktu sebanyak mungkin dengan klien 'nyata' sehingga mereka dapat melihat sesuatu dari sudut pandang mereka. Dengan cara itu proxy dapat memastikan fitur apa yang benar-benar penting dan merasakan pengalaman pengguna yang diinginkan / diinginkan klien.

Tetapi pada titik tertentu Anda harus menunjukkan perangkat lunak kepada klien 'nyata' ...


0

Dimungkinkan untuk menghindari pelanggan nyata, bahkan kadang-kadang diperlukan untuk regulasi. Biasanya pelanggan perangkat lunak medis tidak terlibat. Dalam kasus tersebut, entitas lain dapat menggantikan peran pelanggan, misalnya tim pemasaran dapat dianggap sebagai pelanggan.


0

Agile memang membutuhkan loop ketat untuk menggantikan desain besar di muka yang Sulit - Cukup keras tetapi sebenarnya itu bisa dilakukan, gesit bukan satu-satunya cara.

Anda mungkin ingin menemukan salah satu modifikasi Agile - ada banyak dan satu mungkin membahas masalah khusus ini, tetapi jika tidak membuat sendiri jika Anda pikir Anda bisa.

Semua proses ini dibuat oleh orang pintar - dan orang pintar dapat membuat proses apa pun bekerja. Anda tidak berpikir air terjun diciptakan karena tidak pernah berhasil untuk siapa pun, bukan? Itu berevolusi karena beberapa orang dapat membuatnya bekerja, dan yang lain memandang dan berkata, "Saya harus memperbaikinya dan memberinya makan untuk tim SAYA yang tampaknya tidak dapat menghasilkan secara efektif" - pada titik itu mungkin bekerja lebih baik daripada apa yang mereka sedang melakukan, tetapi jika Anda tidak menyadari bahwa tidak setiap programmer dapat menyelesaikan setiap masalah itu benar-benar dapat membingungkan Anda mengapa dua tim menggunakan proses yang sama dapat memiliki hasil yang berbeda.

Masalahnya adalah bahwa banyak proses membutuhkan bakat untuk mengimplementasikannya - kita berbicara tentang bakat yang sama jarangnya dengan pemain olahraga pro dari kumpulan semua orang yang pernah bermain olahraga - kemungkinan besar dari kita belum pernah bertemu seseorang yang mampu membuat proses jelek seperti air terjun bekerja dan itulah mengapa begitu banyak orang berpikir itu tidak bisa berhasil - mereka belum pernah melihatnya bekerja.

Dibutuhkan jauh lebih sedikit bakat untuk membuat Agile bekerja, namun itu membutuhkan beberapa investasi yang sangat spesifik seperti membuat pelanggan melihat apa yang Anda lakukan terus-menerus sehingga kesalahan tidak dapat menyebar, dan hal-hal seperti refactoring yang kejam sehingga Anda tidak membangun hutang teknis yang tim tidak bisa uraikan beberapa bulan ke depan.


0

Tentukan pelanggan.

Apakah ini perusahaan lain? Individu lain?

Apakah ini tim lain dalam perusahaan Anda?

Apakah itu juara produk di perusahaan Anda?

Apakah itu kamu?

Semua hal di atas dimungkinkan, dan cukup masuk akal tergantung pada keadaan. Anda tidak ingin mengambil satu pandangan ke bawah terowongan tentang apa itu Agile, jadi untuk mengatakan TIDAK pasti akan salah. YA di sisi lain membutuhkan sedikit pemikiran lateral.

Pikirkan kata Agile sejenak. Kelompok orang yang sangat pandai yang menciptakan istilah itu tidak mungkin dapat mengambil metafora yang lebih baik untuk konsep yang mereka coba gambarkan. Ketika Anda mengatakan Agility , apa yang terlintas dalam pikiran Anda? Menjadi armada kaki? Mungkin cepat bereaksi? Cepat beradaptasi?

Sekarang pikirkan tentang semua praktik Agile yang diterima secara umum di luar sana, dan tanyakan pada diri sendiri apa yang sebenarnya mereka bawa ke metode pengembangan perangkat lunak yang dianggap Agile .

Saya adalah pelanggan dari semua maksud dan tujuan untuk proyek solo saya. Saya bahkan terkadang mengenakan topi sungguhan, ketika saya benar-benar ingin membuat perubahan mental yang khas dalam peran pelanggan saya . Ini membuat saya tidak kalah gesit dari saya ketika saya di tempat kerja. Untuk semua yang saya pedulikan, kucing saya bisa menjadi manajer. Dia memastikan saya beristirahat sejenak, dan mengingatkan saya untuk tidak terlalu terobsesi dengan tugas apa pun. Anda mungkin lebih suka menggunakan "Teknik Pomadoro" Anda yang mewah, tapi saya lebih suka Timer "Rascal" !! Masalahnya, saya bekerja dalam proses Agile yang ketat setiap kali saya menulis kode untuk diri saya sendiri. Saya bukan tipe hacker-koboi, yang menjalani kehidupan dengan lonjakan perkembangan tanpa akhir dan tidak menghasilkan apa-apa. Saya suka membuat perangkat lunak, menjadwalkan pengembangan di sekitar pekerjaan dan kehidupan pribadi saya, dan melengkapinya dengan cara yang saya harapkan untuk dilakukan jika saya bekerja untuk pelanggan nyata. Ketika hal-hal mengganggu jadwal saya, saya menyesuaikan dan memprioritaskan pekerjaan proyek saya sesuai. Saya menggunakan semua praktik dan teknik Agile standar yang dapat saya terapkan secara solo, dan saya "memberikan" kode kerja untuk diri sendiri (atau teman atau kolega untuk diuji) sesering yang saya bisa. Jika semua ini bukan Agile, saya bertanya apa itu?

Jadi jawaban saya adalah Ya , Anda bisa menjadi Pengembang Perangkat Lunak Agile, dan Anda bisa menerapkan metodologi Agile, dan Anda tidak perlu pelanggan, atau bahkan manajer. Anda dapat mengerjakan suatu proyek sendirian, dan memakai beberapa topi. Namun, mungkin tidak ideal untuk menyingkirkan peran-peran lain itu, karena sangat membantu untuk bekerja sama dengan orang lain untuk mencapai tujuan. Mereka bertindak sebagai papan pengeras suara untuk ide-ide Anda, dan mereka memberi Anda persyaratan yang Anda mungkin akan menemukan kesulitan untuk menghasilkan sendiri dengan bijaksana. Peran lain yang sangat penting yang dipuaskan oleh pelanggan dan manajer adalah menjaga Anda tetap fokus pada tujuan Anda, tanpa menambahkan fitur tanpa henti dan memperbaiki kode Anda di luar apa yang mungkin sangat diperlukan.

Namun, jika Anda bekerja dengan cara yang disiplin, berpegang teguh pada metodologi pilihan Anda, dan menerapkan praktik Agile, dan jika ketika Anda dilacak, atau Anda berubah pikiran (saat mengenakan topi pelanggan) dan desain atau arahan produk Anda mengambil giliran, jika Anda dapat menyesuaikan jadwal Anda, dan menyesuaikan prioritas Anda seperti yang Anda bayangkan pelanggan Anda harapkan Anda, maka Anda menjadi gesit.

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.