Apakah tenggat waktu Agile?


100

Untuk kejelasan, batas waktu adalah:

Batas waktu atau tenggat waktu adalah bidang waktu yang sempit, atau titik waktu tertentu, di mana tujuan atau tugas harus diselesaikan.

Dari wikipedia

Seluruh karier pengembangan perangkat lunak saya, saya telah melakukan "Agile" yang di mana-mana tampaknya berarti setidaknya praktik berikut dipatuhi:

  • Sprint Mingguan atau Bi-Mingguan
  • Perencanaan Sprint Retrospektif
  • Seorang pemilik produk
  • Scrum
  • Kisah Pengguna

Namun, setiap proyek yang pernah saya ikuti bersikeras untuk menetapkan tenggat waktu. Mengingat bahwa Agile berusaha untuk fokus pada perencanaan adaptif, fleksibilitas, dan perubahan; apakah tenggat waktu Agile?

Pendapat saya sendiri adalah mereka tidak, karena saya melihat tenggat waktu mengarah pada kurangnya fleksibilitas dan kualitas. Sebaliknya, saya pikir itu memberikan nilai lebih untuk fokus pada Sprint dan pengiriman awal. Namun tampaknya, di setiap lingkaran saya telah berada, ini tidak terjadi, dan tenggat waktu dipandang berjalan seiring dengan pengembangan Agile.


36
Bukankah sprint adalah tenggat waktu?
JeffO

12
@JeffO a Sprint adalah komitmen, yang bergeser berdasarkan kecepatan tim Anda. Tenggat waktu adalah IMO, komitmen tanpa kejujuran atau transparansi kepada klien. Mereka tidak memperhitungkan kecepatan akun atau banyak risiko lain yang masuk ke pembuatan proyek perangkat lunak.
stevebot

8
Saya akan mengatakan bahwa pengiriman setiap sprint tidak dapat dinegosiasikan. Anda menilai pekerjaan, Anda meletakkan ukuran kartu di atasnya, dan Anda memuat cukup untuk membuat tim Anda sibuk sampai sprint berakhir (dan sprint harus kecil - apa saja dari seminggu hingga sebulan). "Batas waktu pengiriman" harus didasarkan pada tren historis pekerjaan yang diselesaikan terhadap pekerjaan yang diantisipasi. Agile menambahkan / menghilangkan apa pun dari gagasan kendala "biaya / waktu / ruang" lama, ia hanya menggunakan ruang lingkup sebagai metode yang lebih disukai untuk mengelola selip berdasarkan bahwa prioritas yang lebih baik terhadap ruang lingkup umumnya lebih disukai daripada menghabiskan lebih banyak uang atau waktu.
Calphool

8
Inilah Ron Jeffries '(salah satu penulis asli Agile Manifesto) mengambil tenggat waktu: xprogramming.com/articles/jatmakingthedate
Jules

4
Beberapa tenggat waktu saya terbukti cukup gesit.
psr

Jawaban:


147

Tenggat waktu adalah kenyataan. Sering kali Anda harus memiliki sesuatu pada tanggal tertentu. Itu tidak bisa dihindari. Tanpa tenggat waktu, bahkan proyek yang gesit dapat tunduk pada Hukum Parkinson :

Pekerjaan mengembang untuk mengisi waktu yang tersedia untuk penyelesaiannya.

Dengan kata lain, jika proyek Anda dapat berlangsung selamanya, itu akan berlangsung.

Sehubungan dengan tenggat waktu, Agile mencoba melakukan beberapa hal:

  • Pastikan bahwa setiap orang selalu dapat melihat berapa banyak pekerjaan yang akan dilakukan pada tenggat waktu
  • Pastikan bahwa fitur yang paling penting diselesaikan terlebih dahulu
  • Pastikan bahwa fitur yang selesai dapat digunakan, dalam arti bahwa mereka tidak bergantung pada fitur yang belum selesai
  • Pastikan bahwa pembangunan berlanjut dengan kecepatan yang berkelanjutan

Dengan begitu, ketika hari yang tak terhindarkan datang, Anda tidak memiliki setumpuk kode yang tidak berguna, tetapi produk yang berfungsi dan telah diuji dengan, mudah-mudahan, hanya hal-hal yang paling tidak penting yang belum selesai. Dan tidak ada yang terkejut dengan produk jadi.

Jadi iya. "Agile" dan "deadline" bisa sangat kompatibel.


10
@stevebot Itulah situasi yang mendorong Hukum Parkinson. Saya belum pernah bertemu klien yang tidak bisa memikirkan lebih banyak fitur untuk ditambahkan. Tanpa tenggat waktu, daftar fitur, dan dengan demikian proyek, tidak terbatas.
Eric King

12
@stevebot Saya pikir kami saling memahami, tetapi memiliki arti kata "tenggat waktu" yang berbeda. Bagi saya, "tenggat waktu" adalah tanggal tertentu. Bagi Anda, "tenggat waktu" adalah serangkaian fitur tertentu yang dijanjikan pada tanggal tertentu. Saya percaya definisi saya adalah penggunaan yang lebih umum, dan jawaban saya didasarkan pada definisi itu. Menilai dari jawaban lain yang Anda terima, orang lain setuju dengan saya. Ambillah apa pun yang Anda mau, saya tidak akan tersinggung. :-) Tapi jawaban saya tetap bertahan.
Eric King

5
"Akan selalu ada harapan dan selalu mungkin bahwa kecepatan tim Anda membuat Anda kehilangan fitur paling dasar." Jika Anda menerapkan gesit dengan benar, maka pernyataan itu adalah absurd. Tunggakan Anda HARUS diprioritaskan sesuai dengan nilai pelanggan maksimum. Jika tidak, UNTUK ALASAN APA PUN , maka Anda tidak berlatih gesit. Anda sedang berlatih sesuatu yang lain.
Calphool

7
"Kita harus memiliki sesuatu untuk dikirim pada tanggal 28 Juli." The batas waktu dalam kalimat ini adalah tanggal 28 Juli. Anda dapat memiliki "sesuatu" menjadi seperangkat persyaratan yang telah ditentukan, atau dapat berupa apa pun yang siap. Bagian "sesuatu" bukanlah batas waktu. The tanggal adalah batas waktu.
Eric King

5
@stevebot "(Jawabannya) menyesatkan pembaca untuk percaya bahwa Agile + Tenggat Waktu = baik-baik saja." Itulah intinya. Agile adalah baik-baik saja dengan tenggat waktu. Atau tanpa. Ambil pilihanmu. Mengatakan sebaliknya pada dasarnya mengatakan, "Karena kita memiliki tenggat waktu, kita tidak bisa melakukan proyek ini dengan gesit!" yang omong kosong. Saya telah bekerja di banyak proyek yang keduanya memiliki tenggat waktu dan "gesit". Apakah tenggat waktu cepat? Yah, mereka tidak lincah.
Eric King

24

Tenggat waktu adalah fakta kehidupan. Ada hal-hal yang memiliki tanggal yang sangat tegas.

Kami membutuhkan perangkat lunak oleh Comdex

atau

Permainan harus ada di rak toko oleh Black Friday

dan sejenisnya. Seseorang tidak dapat menunda Comdex atau Black Friday - seluruh dunia tidak berfungsi seperti itu.

Sasaran yang dimiliki Agile adalah bahwa hal-hal yang tidak memenuhi tenggat waktu akan gagal lebih cepat (dan itu adalah hal yang baik), atau cakupannya dapat diperiksa kembali lebih cepat sehingga sumber daya dapat difokuskan pada ROI yang benar dalam suatu lebih tepat waktu.

Batas waktu adalah tanggal yang sulit yang ditetapkan dengan tegas. Agile adalah alat yang memungkinkan seseorang untuk menyadari sebelumnya dalam siklus bahwa perangkat lunak akan memakan waktu dua kali lebih lama untuk berkembang seperti yang diharapkan semula. Penting bagi manajer proyek untuk dapat merealisasikan masalah-masalah ini lebih awal daripada kemudian sehingga sumber daya yang lebih banyak dapat ditambahkan, ruang lingkup berubah, batas waktu disesuaikan (dalam situasi di mana ia merupakan perusahaan daripada tenggat waktu yang padat) atau proyek dibatalkan.

Transparansi yang dicari Agile adalah menunjukkan masalah dan kemajuan di awal siklus. Kegagalan pengiriman air terjun klasik adalah salah satunya Anda menghabiskan waktu berbulan-bulan di balik pintu tertutup dan mengirimkan produk seminggu sebelum tenggat waktu dan diberi tahu bahwa Anda melakukan semuanya salah dan Anda membuang-buang waktu berbulan-bulan (dan sekarang benar-benar telah menghancurkan tenggat waktu) . Kegagalan air terjun klasik lainnya adalah mencari tahu seminggu sebelum tenggat waktu Anda masih punya waktu berbulan-bulan. Agile berusaha membuat masalah ini diketahui sejak awal dalam proses.

Bagian lain yang ingin dilakukan oleh Agile dalam konteks tenggat waktu adalah bahwa meskipun hanya sebagian dari fitur yang disepakati yang lengkap (untuk alasan apa pun), versi perangkat lunak saat ini bermanfaat dan dapat digunakan.

Ok, kami melewatkan semua yang kami inginkan untuk perangkat lunak pajak yang akan digunakan pada 15 April, tapi kami mendapat 75% dan apa yang kami punya bekerja dan telah bekerja sejak kami mulai November lalu. Kami tahu kami tidak akan dapat menggunakan set fitur lengkap sejak pertengahan Desember dan memfokuskan kembali upaya kami pada 80% basis pelanggan.


2
Saya setuju dengan Anda, meskipun saya akan membalik pentingnya pernyataan Anda. # 1. Agile terutama berfokus pada memastikan bahwa versi perangkat lunak saat ini bermanfaat dan dapat digunakan. # 2. Kedua, ini membantu kita menyadari ketika ruang lingkup benar-benar tidak masuk akal sebelumnya sehingga pemilik produk dapat memprioritaskan ulang dan mempertahankan tujuan # 1.
Calphool

2
@ user40980 Ini mengerikan. Ya, ada hal-hal yang berkencan. namun, Anda tidak dapat menghasilkan jumlah pekerjaan yang tak terbatas dalam waktu yang terbatas. Tenggat waktu tidak bisa Agile kecuali bila hanya dihasilkan setelah perkiraan. Itu peringatan yang sangat penting. Itu sebabnya Anda merencanakan sprint - untuk menentukan dengan tepat pekerjaan apa yang dapat diselesaikan. Batas waktu yang keras dan pasti yang dengannya segala sesuatu harus lengkap terlepas dari usaha tidak dapat PERNAH gesit.
EKW

18

Beberapa tenggat waktu harus dipenuhi. Kewajiban kontraktual, konvensi, persyaratan peraturan. Beberapa dipaksakan oleh manajer yang ingin dapat menempatkan pengembangan perangkat lunak dalam bagan yang sama dengan manufaktur pada spreadsheet mereka. Apa pun penyebabnya, kebanyakan orang tidak dapat melepaskan diri dari mereka.

Jika Anda bekerja dalam tim yang berfungsi maka komunikasi antara pengembang dan manajemen / pemangku kepentingan berarti bahwa orang-orang yang perlu mengambil keputusan diberi informasi dengan baik untuk memutuskan apakah melewatkan tenggat waktu atau melanjutkan pengembangan lebih penting.

Bahkan jika Anda mengirimkan cerita pengguna yang telah selesai seminggu sekali, atau dua kali sebulan Anda mungkin masih memiliki tenggat waktu. Ketika seseorang muncul, pastikan pemangku kepentingan Anda tahu apa yang menurut Anda cocok dengan tenggat waktu dan menetapkan harapan.

Jika Anda terus-menerus membangun perangkat lunak terbaik yang dapat Anda lakukan dengan persyaratan yang Anda miliki saat ini di setiap tahap, maka tenggat waktu di akhir setiap sprint seharusnya tidak menjadi masalah. Praktis, ini biasanya tidak terjadi, tetapi kemudian tidak ada tenggat waktu yang muncul dari udara tipis. Tenggat waktu paling penting yang pernah saya berikan dikomunikasikan kepada saya jauh sebelumnya, itu adalah harapan dari kualitas dan fitur yang menjadi masalah.


13

Tenggat waktu sewenang-wenang yang tidak memiliki konsekuensi jika terlewatkan tidak terlalu gesit, tetapi ada situasi di mana karena alasan di luar tenggat waktu kontrol tim pengembang harus ditetapkan dan dipelihara. Untungnya, jika tenggat waktu masuk akal ada banyak cara untuk membalikkan persamaan dan menangani tenggat waktu dengan cara Agile.

Tenggat waktu tidak selalu salah. Seperti yang kita semua pelajari dari Obi-Wan:

"Hanya kesepakatan Sith yang absolut"

Adalah adil untuk mengatakan bahwa dalam kebanyakan kasus tenggat waktu konyol, tidak perlu, dan tentu saja tidak Agile, tetapi akan bodoh untuk mengatakan bahwa ini selalu terjadi. Kasing architypal adalah perangkat lunak yang diperlukan untuk penggunaan yang sensitif terhadap waktu, seperti perangkat lunak pelacakan pemilihan. Jika perangkat lunak tidak siap pada waktunya untuk pemilihan, itu tidak masuk akal atau praktis untuk menunda pemilihan, dan itu tampaknya tidak terlalu berorientasi pelanggan untuk hanya mengatakan 'Maaf, sepertinya kita butuh waktu terlalu lama. Saya tahu perangkat lunak yang Anda bayar ini sama sekali tidak berharga, tetapi tenggat waktu tidak Agile, jadi bagaimana Anda dapat benar-benar menentang kami karena tidak memenuhi mereka? '

Tidak terlalu gesit untuk memberitahu pelanggan Anda untuk mendorongnya karena menginginkan sesuatu yang peka terhadap waktu, dan pada akhirnya seseorang harus membangun barang-barang ini. Jadi bagaimana kita masih bisa membuat pelanggan senang dan masih memberikan solusi yang tampaknya masuk akal untuk hal-hal yang sensitif waktu? Nah, jika mengembangkan perangkat lunak membutuhkan waktu yang tidak pasti, dan tenggat waktunya tidak berubah-ubah, sesuatu yang lain hanya perlu variabel untuk menangani ketidakpastian itu ...

Jika tanggal pengiriman dijaga konstan, beberapa aspek lain menjadi variabel.Seperti yang kita semua tahu, ada banyak ketidakpastian dalam proyek perangkat lunak. Sesuatu harus dibuat variabel dalam menanggapi ketidakpastian ini jika Anda ingin sukses dalam proyek Anda, dan biasanya itu adalah tanggal pengiriman. Sepertinya cukup alami. Tapi itu bukan satu-satunya pilihan Anda. Jika Anda terjebak berkomitmen pada tenggat waktu yang sulit, cara untuk mengatasinya adalah membuat variabel fitur yang Anda kirim menjadi variabel. Prioritaskan daftar fitur, komunikasikan dengan jelas bahwa ada ketidakpastian dalam jumlah fitur yang dapat dikirim pada tanggal tersebut. Bekerja dengan pelanggan untuk memprioritaskan fitur-fitur ini sehingga yang paling penting akan memiliki kemungkinan lebih tinggi untuk dikirim. Kemudian, itu bisnis seperti biasa, hanya ketika tenggat waktu bergulir di sekitar Anda mengirimkan apa pun yang siap dikirim. Dalam model ini,


11

Jika seseorang ingin menetapkan tenggat waktu maka itu baik dan tenggat waktu dapat diperbaiki, tetapi yang harus mereka pahami adalah bahwa jika tenggat waktu ditetapkan, maka ruang lingkup harus tetap fleksibel.

tl; dr

Dalam dunia yang ideal kita tidak akan memiliki tenggat waktu dan hanya mengirimkan barang ketika sudah siap. Kenyataannya adalah bahwa orang membayar untuk hal-hal yang biasanya ingin tahu kapan mereka selesai. Metodologi lincah memang mengenali ini tetapi juga mengakui bahwa tidak semuanya dapat diikat.

Ini memastikan bahwa Anda dapat menjaga kualitas pengiriman pada tingkat yang tepat untuk produk. Jika Anda memperbaiki tenggat waktu dan ruang lingkup (dan anggaran), maka segala sesuatunya menjadi tergesa-gesa dan Anda berakhir kembali di dunia air terjun lama dengan waktu krisis yang gila-gilaan di akhir proyek. Meningkatkan anggaran biasanya bukan jawabannya, karena menambahkan lebih banyak pengembang dan penguji tidak menyelesaikan masalah lebih cepat. Ini adalah pandangan yang terkenal (dan saya setuju dengan itu dari pengalaman), bahwa semakin banyak orang yang Anda tambahkan (masing-masing dengan kelemahan mereka sendiri) semakin banyak waktu yang dibutuhkan.

Sekarang, biasanya (kecuali mereka benar-benar mengerti metode Agile) orang yang membayar perangkat lunak tidak suka diberitahu, kami dapat memenuhi tenggat waktu Anda, tetapi kami tidak dapat melakukan semua yang Anda inginkan. Ini dapat dikelola dengan memprioritaskan fitur yang membentuk perangkat lunak. Diskusi prioritas Anda mungkin seperti:

Tim Pengembang (D): "Bisakah Anda memprioritaskan fitur yang ingin Anda sampaikan, dengan yang terpenting terlebih dahulu?"

Pelanggan (C): "Semuanya adalah prioritas 1 - Saya ingin semuanya selesai pada akhir bulan depan."

D : "Itu mungkin saja, tetapi itu tidak mungkin jika persyaratan berubah atau kami menemukan masalah yang tidak kami harapkan saat menjalani pengembangan."

C: "Nah bagaimana jika saya memberi Anda lebih banyak uang?"

D: " huh ... walaupun dengan lebih banyak sumber daya, mereka butuh satu bulan untuk benar-benar pergi; jadi jika Anda tidak yakin bagaimana memprioritaskan fitur, beri tahu kami yang mana yang ingin Anda lakukan terlebih dahulu."

C: "Ok, saya ingin tombol besar tetapi membuatnya sangat besar, dan kemudian ... dll"

Sekarang Anda dapat mulai bekerja melalui fitur-fitur dalam urutan prioritas. Memang membantu juga melihat ke depan dengan tim Anda ke item-item yang lebih rendah dalam urutan prioritas dan membuat beberapa perkiraan awal, mengetahui bahwa Anda dapat mengubahnya ketika Anda mendapatkan pengembangan ketika Anda memiliki lebih banyak informasi. Ini dapat digunakan untuk mendefinisikan ulang atau membuat peta jalan Anda jika Anda belum memilikinya. Ini kemudian membentuk dasar dari rencana rilis Anda. Peta jalan dapat didiskusikan dengan pelanggan yang mengakui bahwa ruang lingkup dapat berubah tetapi Anda memiliki urutan hal yang harus disampaikan.

Salah satu keuntungan agile adalah bahwa Agile mengakui bahwa segala sesuatu berubah ketika Anda melalui pengembangan dan Anda menyesuaikan diri sebagaimana mereka lakukan. Berlawanan dengan pendekatan yang lebih tradisional, prinsip ini, dalam hubungannya dengan kiriman sprint reguler dan komunikasi berkelanjutan dengan pelanggan, berarti bahwa Anda secara alami dipaksa untuk lebih transparan tentang kemajuan, yang merupakan hal yang baik.

Kadang-kadang pelanggan tidak suka bahwa mereka tidak akan mendapatkan apa yang mereka inginkan pada tanggal tertentu tetapi mereka akan mengerti mengapa dan apa yang mereka dapatkan akan memiliki kualitas yang baik. Dan 6 bulan setelah fitur dikirimkan, pelanggan tidak akan peduli atau ingat bahwa Anda dikirim pada tanggal tertentu, mereka akan mengingat kualitas produk yang masih mereka gunakan.


7
"Jadi, jika seseorang ingin menetapkan tenggat waktu maka itu baik dan tenggat waktu dapat diperbaiki, tetapi yang harus mereka pahami adalah bahwa jika tenggat waktu ditetapkan, maka ruang lingkup harus tetap fleksibel." Benar.
Eric King

Ini mungkin jawaban yang paling lincah di sini. Fakta bahwa ia tidak memiliki banyak suara merupakan bukti seberapa lincahnya disalahpahami.
PostCodeism

10

Tenggat waktu secara tradisional didasarkan pada siklus hidup bisnis. Perangkat lunak pajak harus masuk paling lambat 15 April. Pelaporan untuk tahun fiskal berikutnya mungkin perlu dilakukan pada bulan Juli.

The Agile Manifesto negara:

Individu dan interaksi atas Proses dan alat

Bekerja dengan perangkat lunak melalui dokumentasi Komprehensif

Kolaborasi pelanggan melalui negosiasi Kontrak

Menanggapi perubahan atas Mengikuti rencana

Tenggat waktu adalah kontrak. Mereka adalah rencana. Mereka tidak menanggapi kecepatan tim Anda. Mereka tidak berubah jika Anda kehilangan tiga pengembang terbaik Anda.

Tenggat waktu bukanlah Agile, tetapi Agile dapat memberi kami umpan balik tentang tenggat waktu. Agile beritahu kami jika kecepatan kami tidak akan membiarkan kami membuat tenggat waktu tanpa fitur terpotong. Ini juga memberi tahu kami jika kami perlu menyewa untuk membuat tenggat waktu. Dan dalam beberapa kasus, ini memberi tahu kami bahwa tenggat waktu tidak mungkin, ketika tidak ada fitur yang tersisa untuk dipotong.

Hal terbaik yang bisa dilakukan oleh tim Agile, adalah membiarkan kecepatan mereka dan jaminan simpanan yang diprioritaskan mendorong tenggat waktu. Ini akan memberikan perkiraan tanggal pengiriman. Jika mereka berada di luar batas waktu, maka sudah waktunya untuk pembicaraan serius dengan klien dan menentukan apakah batas waktu itu bisa dilakukan.


1
Kadang-kadang, Anda harus mengirim pada tanggal tertentu, tidak dapat dinegosiasikan (tenggat waktu). Dalam hal itu, hal terbaik yang dapat dilakukan oleh tim Agile adalah membiarkan tenggat waktu mengendalikan simpanan mereka, memberikan perkiraan fitur-fitur pada tenggat waktu. Jika set fitur yang diperkirakan ini gagal memenuhi persyaratan klien, maka sudah waktunya untuk pembicaraan serius dengan klien dan menentukan apakah proyek itu bahkan dapat dilakukan.
Eric King

@EricKing ya, Anda benar, Agile dapat bekerja dengan tenggat waktu, saya pikir saya telah membaca pernyataan Anda sebagai "tenggat waktu Agile" alih-alih "Agile bekerja dengan Tenggat Waktu."
stevebot

Terima kasih atas komentar Anda. Saya pikir kita berdua sudah berbicara melewati satu sama lain untuk sementara waktu, dan mungkin hanya perlu ungkapan tertentu untuk membuat hal-hal klik. Saya belum bermaksud mengatakan "kesepakatan itu gesit", tetapi saya bisa melihat bagaimana hal itu akan terjadi. Maaf soal itu.
Eric King

6

Saya akan mengatakan bahwa pengiriman setiap sprint tidak dapat dinegosiasikan. Anda menilai pekerjaan, Anda meletakkan ukuran kartu di atasnya, dan Anda memuat cukup untuk membuat tim Anda sibuk sampai sprint berakhir (dan sprint harus kecil - apa saja dari seminggu hingga sebulan). "Batas waktu pengiriman" harus didasarkan pada tren historis pekerjaan yang diselesaikan terhadap pekerjaan yang diantisipasi. Agile menambahkan / menghilangkan apa pun dari gagasan kendala "biaya / waktu / ruang" lama, ia hanya menggunakan ruang lingkup sebagai metode yang lebih disukai untuk mengelola selip berdasarkan bahwa prioritas yang lebih baik terhadap ruang lingkup umumnya lebih disukai daripada menghabiskan lebih banyak uang atau waktu.

Beberapa orang tampaknya bingung lincah untuk "barat liar". Agile tidak berarti apa pun berjalan. Agile berarti kita berhenti membohongi diri sendiri tentang seberapa baik orang yang masuk akal bisa memperkirakan. Pada dasarnya kita dapat memperkirakan pengembangan perangkat lunak sekitar 2 - 4 minggu ke depan. Di luar itu, semuanya berbagai tingkat curian dan tebakan. Lebih buruk lagi, biaya menyediakan perkiraan untuk hal-hal lebih jauh dan lebih jauh ke masa depan mendekati biaya hanya melakukan pekerjaan. Untuk alasan apa pun, Manajer Proyek secara historis tidak mau mengakui kebenaran absolut ini kepada pelanggan. Agile hanya menyesuaikan pemikiran itu dengan menyatakan bahwa ada batas seberapa baik kita dapat memprediksi masa depan dalam rekayasa perangkat lunak, dan membuat peralihan halus ke "estimasi berbasis bukti" untuk peramalan jangka panjang.adalah mampu memperkirakan, dan kami dapat memberikan perkiraan yang cukup masuk akal pengiriman masa depan jangka panjang berdasarkan apa yang telah kami memberikan sejauh ini.


BTW, Cal, saya cukup setuju dengan semua yang Anda katakan di sini. dan saya tidak berpikir itu bertentangan dengan apa yang saya tulis.
robert bristow-johnson

5

TL; DR

Apakah tenggat waktu [a] gile? ... [D] eadline dipandang berjalan seiring dengan pengembangan [a] gile.

Banyak jawaban di sini cenderung berfokus pada aspek teknik dari pertanyaan. Sebaliknya, saya akan membahas ini dari perspektif manajemen proyek.

Tenggat waktu menyiratkan banyak perencanaan di muka yang tidak sejalan dengan prinsip tangkas. Alih-alih, model pengembangan berulang mengandalkan kotak waktu, irama, dan rilis siklus yang mencakup perencanaan tepat waktu, tetapi bukan "perencanaan besar, di muka" yang umumnya terkait dengan tenggat waktu manajemen proyek tradisional.

Masih dimungkinkan untuk melakukan perencanaan rilis dengan metodologi lincah, tetapi rencana umumnya didasarkan pada perkiraan jumlah iterasi yang diperlukan untuk memenuhi tujuan daripada target manajemen yang ditetapkan oleh fiat. Itu bukan untuk mengatakan bahwa tanggal pengiriman tidak dapat ditetapkan, atau bahwa tujuan tidak dapat dipenuhi, tetapi cara mereka didefinisikan dan dipenuhi sangat berbeda dari pada metodologi manajemen proyek tradisional.

Pikirkan Time-Boxes, Bukan Tenggat Waktu

Namun, setiap proyek yang pernah saya ikuti bersikeras untuk menetapkan tenggat waktu. Mengingat bahwa Agile berusaha untuk fokus pada perencanaan adaptif, fleksibilitas, dan perubahan; apakah tenggat waktu Agile?

Ini adalah kesalahpahaman umum tentang prinsip gesit. Kerangka kerja yang gesit seperti Scrum dan Kanban tidak berfokus pada tenggat waktu, tetapi pada waktu-tinju dan irama pengiriman yang berkelanjutan.

Di Scrum, misalnya, Sprint bukanlah "tenggat waktu." Ini adalah kotak waktu yang diisi dengan jumlah pekerjaan yang diperkirakan oleh tim akan masuk ke dalam kotak waktu tanpa meluap, dan kemudian "selesai" atau "tidak dilakukan" ketika kotak waktu kedaluwarsa. Setelah pergi, kotak waktu hilang selamanya; pekerjaan apa pun yang tidak dilakukan harus direncanakan ulang dan diperkirakan kembali dalam kotak waktu baru yang sama-sama fana berdasarkan kebutuhan proyek saat itu (daripada sejarah).

Pentingnya time-box adalah bahwa ia menciptakan irama yang dapat diprediksi bagi para pemangku kepentingan untuk meninjau kemajuan, dan kecepatan berkelanjutan bagi tim untuk memberikan peningkatan nilai yang berpotensi dapat dikirim . Pekerjaannya bersifat inkremental, dan mengikuti irama; konsep batas waktu yang besar di muka tidak sejalan dengan prinsip-prinsip lincah.

Perencanaan Rilis Berdasarkan Waktu-Kotak

Mungkin satu area di mana orang-orang paling sulit memetakan proses lincah ke kerangka kerja tradisional adalah perencanaan rilis. Perencanaan rilis seringkali melibatkan kiriman dengan cakupan tetap atau tanggal tetap. Dalam kerangka kerja tangkas, perencanaan rilis biasanya dilakukan melalui proses estimasi di mana ruang lingkup secara eksplisit didefinisikan sebagai variabel yang bisa berubah, sementara tanggal rilis diperkirakan dalam iterasi.

Sebagai contoh, sebuah proyek dapat berkomitmen untuk merilis v1.0 proyek di akhir 20 iterasi; ruang lingkup dari apa yang dirilis dapat berubah sepanjang umur proyek (sebagaimana ruang lingkup, fitur, dan prioritas dapat berubah pada awal setiap Sprint), tetapi tanggal target untuk setiap rilis ditetapkan dalam rencana proyek. Tim berusaha untuk memberikan peningkatan yang berpotensi dapat dikirimkan setiap Sprint, dan Definisi Selesai mencakup pemeriksaan kualitas seperti integrasi berkesinambungan untuk memastikan bahwa proyek berada dalam kondisi yang dapat dirilis di akhir setiap Sprint.

Kadang-kadang, Anda akan melihat proyek gesit di mana ruang lingkup ditetapkan, tetapi karena ruang lingkup adalah variabel yang bisa berubah dalam proyek tangkas, tanggal rilis dapat berubah seiring waktu ketika ruang lingkup setiap iterasi menyesuaikan, mengubah, atau menyesuaikan dengan kebutuhan proyek yang berkembang. . Saya tentu saja tidak merekomendasikan pendekatan lingkup tetap untuk tim tangkas, terutama tim yang tidak berpengalaman, tetapi ada kalanya pendekatan yang tepat.

Lihat juga


... semacam ... tapi seiring waktu tim lebih baik fokus untuk mendapatkan pekerjaan yang sesuai dengan "kotak waktu" dengan baik. Jika Anda hanya menerima bahwa kotak waktu dan pekerjaan Anda selesai tidak terkait, maka Anda melakukan pengkodean koboi, dan itu sama sekali tidak dapat diprediksi. Saya akan mengatakan bahwa mungkin itu dimulai sebagai "kotak waktu" dan seiring waktu itu menjadi tenggat waktu yang agak tidak dapat dinegosiasikan karena tim menjadi lebih baik dalam memprediksi berapa banyak pekerjaan yang dapat mereka tangani dalam sprint. Ini tentang pelatihan mandiri tim untuk menjadi luar biasa dalam estimasi jangka pendek, karena dari situlah prediksi berasal.
Calphool

4

Pikirkan tenggat waktu sebagai komitmen. Fakta bahwa proyek ini gesit bukan berarti Anda tidak harus berkomitmen untuk memberikan fitur yang diberikan untuk tanggal tertentu.

Yang dibawa oleh ketangkasan adalah apa yang terjadi di antaranya. Alih-alih memiliki dokumen spesifikasi persyaratan perangkat lunak yang ketat yang menetapkan bahwa Anda harus memberikan fitur A yang terdiri dari sub-fitur B, C, D, dan E untuk tanggal tertentu, Anda berkomitmen untuk memberikan fitur A untuk tanggal tertentu, mengingat bahwa pada tahap awal, baik Anda maupun pelanggan Anda tidak tahu seperti apa bentuknya, atau apakah sub-fitur B, C, D dan E atau mungkin B dan C, atau selusin sub-fitur lainnya.

Bayangkan sebuah perusahaan yang sebelumnya mengirimkan barang ke perusahaan kecil saja dan baru saja menandatangani kontrak dengan perusahaan besar. Perusahaan besar ini menggunakan EDIFACT, dan tampaknya perangkat lunak akuntansi saat ini yang digunakan oleh perusahaan Anda tidak menangani EDIFACT. Anda diminta untuk membuat sebuah plugin yang melakukan itu, mengingat bahwa kontrak, perusahaan Anda harus siap untuk April 15 th .

Kelincahan akan berarti bahwa langkah perantara akan disampaikan secara progresif, dan didasarkan pada umpan balik yang teratur. Pada dasarnya, Anda akan menunjukkan kemajuan Anda kepada akuntan, dan mereka akan memberi tahu Anda apa yang mereka pikirkan tentang hal itu, apa masalah yang mungkin terjadi, dll. Ini juga berarti bahwa mungkin awalnya, akuntan memiliki ide bagus yang, menurut mereka, dapat meningkatkan secara substansial pengalaman pengguna. Tiga minggu kemudian, tampaknya bukan saja tidak meningkatkan sebanyak itu, tetapi juga akan menghasilkan satu bulan pengembangan tambahan. Berkat Agile, Anda kemudian dapat mengalihkan upaya Anda dari fitur ini ke sesuatu yang lain, memastikan pengiriman tepat waktu.

Anda juga harus memahami sudut pandang pelanggan:

  • Seringkali, bisnis memerlukan tanggal pengiriman tertentu. Misalnya, Anda tidak dapat memberikan layanan streaming online game Olimpiade setelah pertandingan Olimpiade berakhir. Dari segi bisnis, ini hanyalah sebuah kegagalan, dengan konsekuensi negatif yang sangat besar.

  • Tanpa memiliki komitmen, sangat menggoda bagi pengembang atau subkontraktor untuk menjadi perfeksionis atau menjadikan proyek prioritas rendah. Meskipun keteraturan sprint membantu, sprint tidak sepenuhnya mencegah risiko ini.

    Saya tidak suka tenggat waktu untuk itu, terutama karena slip tenggat waktu terjadi dengan sangat mudah, tetapi saya masih mengerti mengapa banyak perusahaan melakukan itu. Tidak selalu mudah untuk melihat bahwa proyek berada di belakang jadwal dengan hanya melihat sprint: tenggat waktu yang terlewat, dalam konteks ini, mungkin menjadi pengingat yang jelas bahwa sesuatu berjalan di luar kendali dan harus ditangani, saat ini.


Terima kasih, tetapi mengapa keteraturan sprint tidak sepenuhnya mencegah risiko ini? Juga, saya suka contoh Anda dari Olimpiade, tetapi saya pikir syarat adalah ruang lingkup dan biaya dan tidak terikat. Jika saya menempatkan satu pengembang pada proyek itu dan diminta untuk memberikan semua fitur, tenggat waktu tidak akan benar-benar membantu dan kemungkinan besar akan mendorong kami untuk memberikan produk berkualitas sangat rendah.
stevebot

Keteraturan sprint tidak mencegah risiko karena relatif mudah bagi manajer untuk menipu para pemangku kepentingan untuk berpikir bahwa proyek berjalan dengan baik. Hal-hal seperti "Kami tidak menerapkan hal ini karena Anda memberi aksen pada dua hal itu selama pertemuan terakhir kami." Atau "Dua pengembang kami sedang berlibur, jadi kami hanya melakukan setengah dari pekerjaan selama sprint ini." sulit untuk diperdebatkan untuk para pemangku kepentingan, dan dalam setiap detail sprint, mereka mungkin kehilangan gambaran keseluruhan proyek.
Arseni Mourzenko

maka Anda memiliki masalah dengan transparansi dan menempatkan tenggat waktu di atas tidak akan membantu. Alasan-alasan itu akan dengan mudah dilemparkan pada tenggat waktu juga dan ini hampir selalu apa yang saya lihat terjadi dalam kehidupan nyata.
stevebot

1

Status Pemrograman eXtreme tentang perencanaan rilis:

Filosofi dasar perencanaan rilis adalah bahwa proyek dapat dikuantifikasi oleh empat variabel: ruang lingkup, sumber daya, waktu, dan kualitas.

Tampaknya adil. Itu juga menyatakan itu

Tidak ada yang bisa mengendalikan semua 4 variabel. Ketika Anda mengubah satu Anda secara tidak sengaja menyebabkan orang lain berubah dalam respons. Perhatikan bahwa menurunkan kualitas menjadi kurang dari sangat baik memiliki dampak yang tidak terduga pada 3 variabel lainnya

Dan seperti yang sudah dicatat oleh br3w5 , meningkatkan sumber daya adalah solusi terbatas. Anda mungkin dapat menambahkan beberapa orang yang sudah menjadi bagian dari tim jika mereka dikirim pada sesuatu yang lain. Tetapi Anda tidak bisa begitu saja meningkatkan ukuran tim dengan cepat dan tanpa batas, setidaknya tidak tanpa pengaturan ulang tim yang membutuhkan banyak waktu.

Jadi, dengan kualitas yang tidak dapat direduksi dan sumber daya tetap: tenggat waktu menjadi batasan waktu, itu berarti Anda perlu menyesuaikan ruang lingkup. Dan menggunakan kelincahan memberi Anda cara untuk memenuhi tenggat waktu dengan ruang lingkup yang paling produktif. Namun, Anda biasanya dapat menjamin bahwa beberapa bagian dari ruang lingkup akan selesai tepat waktu. Ini adalah bagian yang Anda dapat memperkirakan waktunya untuk terikat di bawah batas waktu. Biasanya sesuatu yang benar-benar dekat dengan apa yang telah Anda lakukan beberapa kali dan tidak banyak diketahui.


0

Tujuan dari metode pengembangan perangkat lunak, ketika dipahami dengan benar, adalah untuk membuat kita lebih produktif dengan memfokuskan pikiran kita, dan untuk menyediakan bahasa umum untuk situasi yang khas. Ini tentang inspirasi dan kemampuan, bukan tentang kontrol pikiran dan rasa bersalah.

Mengikuti metode pengembangan perangkat lunak secara harfiah tanpa kompromi apa pun sesuai dengan apa yang disebut radikalisme atau fundamentalisme dalam konteks lain. Bentuk murni penyimpangan ini jarang terlihat dalam praktik karena biasanya mengarah pada kegagalan yang cepat di pasar. Tapi tentu saja ketika pengembang bersaing dalam tugas berat menerapkan metode tertentu, melampaui tanda adalah kejadian alami.

Masalahnya diperburuk oleh fakta bahwa misionaris dan penginjil terutama menargetkan mereka yang masih perlu diyakinkan untuk menggunakan metode ini sama sekali; dan bahkan jika mereka memberitakan moderasi, sifat manusia memastikan bahwa itu kurang diperhatikan.


-1

Tenggat waktu tidak gesit, yaitu:

1) Air Terjun, dan 2) Salah.

Perangkat lunak dan tenggat waktu tidak berfungsi dengan baik dan tidak pernah ada. Dalam banyak hal, metode Agile adalah reaksi terhadap masalah besar tenggat waktu yang terlewat atau perangkat lunak yang ditinggalkan ketika menjadi jelas bahwa tenggat waktu tidak dapat dipenuhi (serta masalah anggaran juga).

Agile berupaya menyuntikkan kenyataan ke dalam situasi dengan mengatakan "Anda tahu tenggat waktu atau fitur akan tergelincir dan / atau berubah, kita tahu itu, jadi mari kita turun dengan kaki kanan dan bahkan tidak berpura-pura".

Kuncinya adalah batas waktu menjadi tanggal rilis untuk versi pertama perangkat lunak. Itu mungkin masih ditulis dalam batu - katakanlah, perangkat lunak ini untuk penggunaan akademis dan HARUS dapat digunakan pada awal semester - tetapi apa yang akan Anda sampaikan tidak. Anda memiliki produk yang layak minimum yang setiap orang sangat yakin dapat dikirim pada saat itu, dan Anda memiliki banyak "ingin kaya". Alih-alih semua orang mengangkat tangan ketika ternyata seluruh daftar tidak akan dikirimkan oleh "tenggat waktu", Anda pastikan Anda mengeluarkan MVP keluar dari pintu dan karena banyak dari "ingin memiliki" sebagai mungkin dan kemudian menilai biaya / manfaat sisanya pada saat itu.

Siapa pun yang pernah bermain game komputer untuk waktu yang lama tahu persis cara kerjanya! Jika rilis pertama hingga standar beta banyak gamer senang, harapan yang begitu rendah dari apa yang "tegas, tenggat waktu nyata" berarti dalam kehidupan nyata.

Jadi tenggat waktu tidak gesit, mereka peninggalan dari hari-hari ketika orang berpikir bahwa perangkat lunak dapat diperlakukan seperti perangkat keras dan teknik baja. Kami telah belajar bahwa ini tidak mungkin dan tidak diinginkan, karena ia membuang kelebihan terbesar yang dimiliki perangkat lunak daripada perangkat keras: lunak.

Agile mencoba untuk mengeksploitasi kelembutan ini dengan memungkinkan tujuan untuk berkembang dan berubah selama proyek dengan cara yang tidak pernah bisa dilakukan oleh desain jembatan.


3
Saya tidak tahu mengapa orang-orang menurunkan Anda. Saya telah melakukan dev aplikasi gesit / xp selama lebih dari 10 tahun di perusahaan Fortune 100 - memperkenalkannya di sini sebagai fakta, dan saya benar-benar melihat tidak ada yang salah dengan apa yang Anda katakan. Saya mengubah Anda kembali ke nol, karena siapa pun yang menurunkan Anda harus menjadi pemula yang gesit masih berpegang teguh pada realitas lama mereka karena Tuhan tahu apa alasannya. Orang-orang terlalu sederhana. Mereka berpikir bahwa "Perangkat lunak dan tenggat waktu tidak bekerja dengan baik bersama" adalah mutlak. Anda bertujuan untuk mencapai SETIAP tenggat waktu sprint. Anda hanya tidak berbohong tentang kemampuan Anda untuk mencapai tanggal perkiraan jangka panjang. Sesederhana itu.
Calphool

7
@Calphool Saya punya masalah dengan mengatakan bahwa tenggat waktu adalah air terjun (mereka ada tidak peduli apa metodologi yang digunakan - mereka bahkan ada untuk koboi coders) dan salah (mereka ada karena kendala eksternal waktu - tidak lebih salah daripada "kita harus memiliki ini kode dijalankan pada perangkat keras itu dengan kinerja minimal "). Ini adalah kendala waktu tentang apa solusi yang dapat diterima. Pengajuan pajak pada tanggal 15 April adalah batas waktu. Memiliki perangkat lunak kepada distributor pada tanggal 1 November sehingga dapat dipastikan pada tanggal 27 November adalah tenggat waktu. Tidak ada yang salah.

4
@MichaelT: Jika Anda belum melakukannya, saya sarankan Anda membaca buku Tom & Mary Poppendiecks "Pengembangan Perangkat Lunak Lean Lean: Hasil Bukanlah Intinya". Dia hanya menyampaikan meme yang cukup populer di kalangan ramping / gesit. Jika Anda dan tim Anda berfokus pada tenggat waktu lebih dari Anda berfokus pada peningkatan berkelanjutan, Anda tidak benar-benar lincah. Anda mungkin melakukan scrum, tetapi tidak hidup gesit. Apakah ada tenggat waktu jangka panjang? Jelas sekali. Apakah mereka fokus pada tim yang gesit? Benar-benar tidak. Tenggat waktu adalah insidental untuk berpikir gesit.
Calphool

4
@MichaelT OP mengacu pada tenggat waktu proyek dan itulah yang saya tanggapi - tenggat waktu jangka panjang yang ditetapkan oleh seorang PM di awal proyek dan bukan sprint. Tentu saja ada tenggat waktu dari semacam lincah, tetapi mereka memiliki sifat yang sangat berbeda dengan apa yang biasanya orang maksud dengan tenggat waktu proyek, tetapi mungkin itu hanya semantik yang menjadi masalah di sini.
Nagora

3
@ Ellesedil: Beri tahu saya fitur Anda yang paling penting, atau set fitur minimum yang dapat dipasarkan, beri saya beberapa minggu hingga beberapa bulan untuk membangun rekam jejak terhadap set fitur yang Anda inginkan (bervariasi tergantung pada seberapa banyak yang Anda minta - butuh lebih banyak waktu untuk memprediksi berapa lama untuk sampai ke bulan vs Pittsburgh). Lalu saya akan memberi tahu Anda, dan karena perkiraan saya dibuat berdasarkan pengiriman aktual perangkat lunak yang berguna , kami akan dapat mengandalkan estimasi tersebut, tidak seperti dongeng yang Anda paksa saya berikan pada Anda sejak awal.
Calphool

-1

Jawab "mungkin tidak"

The Project_management_triangle menyatakan bahwa biaya, waktu dan ruang lingkup (dan juga kualitas) bergantung satu sama lain. ("pilih dua dan dapatkan yang ke-3")

Scrum sprint memilih waktu tetap (yaitu 7 hari = panjang sprint) dan biaya (yaitu anggaran untuk 7 anggota tim) dan memperkirakan ruang lingkup (jumlah cerita yang harus dilakukan dalam sprint)

Jika manajemen atau departemen penjualan mencoba mendefinisikan ketiganya (biaya, waktu, dan ruang lingkup) maka itu tidak tangkas dalam arti scrum karena tim tidak dapat tidak dapat berjanji untuk mencapai tujuan (tanpa melanggar kualitas = definisi yang dilakukan)

Manajemen profesional mencoba mendefinisikan biaya dan waktu dan mengurangi ruang lingkup jika perlu jika ada tanggal tertentu yang harus dipenuhi.


-1

Apakah ini tidak dapat dijawab secara sederhana dan langsung?

Tidak ada tenggat waktu yang tidak gesit.

Intinya adalah untuk membangun apa yang Anda bisa dalam mode belajar berulang dan beradaptasi saat Anda pergi.

Batas waktu adalah "Anda harus mengirimkan x per tahun" yang gagal dalam kedua hal tersebut karena Anda menjanjikan hasil pengiriman tetap dalam skala waktu yang telah ditentukan sebelumnya (di mana agile mengatakan kami tidak yakin apa yang kami coba berikan, dan belajar dari lincah mengajarkan kita bahwa bahkan jika kita tahu sangat sulit untuk memiliki kepastian tentang rentang waktu - atau itu adalah masalah yang diselesaikan dan kita seharusnya tidak melakukannya).

Setelah menetapkan bahwa jawaban untuk pertanyaan adalah "Tidak, tenggat waktu tidak gesit" - maka kita dapat memiliki percakapan yang menarik yang menjawab pertanyaan "bagaimana kita mengatasi tenggat waktu dalam konteks lincah" dan ada banyak hal baik memikirkan hal itu di jawaban yang lain.

Bagi saya, jawaban yang masuk akal bagi yang terakhir adalah bahwa kami akan memberikan peningkatan nilai lebih awal dan sering dan kami akan melihat di mana kami berada pada waktunya - tetapi tidak ada satu ukuran yang cocok untuk semua.


-2

Tingkat kelincahan yang dibutuhkan dalam pekerjaan seseorang berbanding terbalik dengan seberapa tinggi posisi mereka di bagan organisasi.

"Agile" itu baik, apa adanya. Agile "Agile" berarti "berpikiran terbuka ditambah dengan kompetensi yang memadai." Mendengus di bagian bawahlah yang paling gesit.

Jika, pada level manajemen, bos berambut runcing itu cukup gesit untuk memahami bahwa mendorong tenggat waktu satu minggu ke belakang akan menghasilkan produk yang lebih baik, atau akan membuat kode yang lebih bersih, lebih bebas bug, dan lebih dapat diupayakan sehingga perusahaan ( atau pembagian) menghemat dua minggu di masa depan, itu adalah tenggat waktu yang tangkas.

Tetapi seperti kepentingan pribadi yang tercerahkan, itu tidak benar-benar ada.


5
Batas waktu yang dapat dipindahkan bukanlah batas waktu. Itu disebut tanggal kalender. Tenggat waktu adalah hal-hal seperti Black Friday - apakah ada di toko atau tidak. Tetap saja, Agile berarti saya memiliki yang terbaik yang dapat saya miliki dengan tenggat waktu itu.
MSalters

jadi, jika melewati tenggat waktu itu, tetapi ada di toko minggu berikutnya, apakah pabrik selalu mati? melewatkan batas waktu yang dikenakan biaya. tetapi bagaimana jika biaya itu lebih dari sekadar mengganti dengan produk yang lebih baik, yang membuat pelanggan lebih terkesan dengan kesan pertama mereka ( "Anda tidak pernah mendapatkan kesempatan kedua untuk membuat kesan pertama" ) dan memiliki manfaat lain yang melebihi biaya itu? jika manajemen cukup cerdas untuk membuat keputusan taktis untuk menunda pembebasan (itu melewati batas waktu, bukan membuangnya) untuk kepentingan pelanggan dan produsen, bukankah itu "gesit"?
robert bristow-johnson

Pernahkah Anda memiliki tenggat waktu Black Friday dengan Walmart? Perasaan saya adalah bahwa jika Anda mengacaukan tahun ini, Anda tidak akan mendapatkan kesempatan kedua tahun depan. Itu benar-benar "tidak ada kesempatan kedua".
MSalters

3
dengarkan kode saya di area instrumen audio dan musik. tentu saja produk harus keluar pintu untuk menghasilkan uang dengannya. tetapi tenggat waktu benar-benar menyebabkan beberapa omong kosong yang dikembangkan dengan buruk sehingga pelanggan, perusahaan, dan pengembang masa depan terpaksa hidup bersama selama bertahun-tahun setelahnya.
robert bristow-johnson

5
Masalahnya dengan penjualan Black Friday adalah bahwa ini merupakan upaya pemasaran untuk menciptakan kelangkaan waktu dan produk yang keliru untuk membuat orang berperilaku tidak rasional dan membeli barang-barang yang sebenarnya tidak mereka inginkan. Contoh perilaku irasional yang diinduksi ini tampaknya tidak jauh berbeda dengan beberapa pendekatan manajemen proyek perangkat lunak. Dalam berpendapat bahwa menciptakan kelangkaan waktu yang salah dengan perangkat lunak bukanlah ide yang baik, saya tidak mengatakan bahwa kelangkaan waktu yang sebenarnya tidak mungkin karena mereka jelas-jelas berada dalam beberapa konteks (dan sangat penting pada saat itu).
shuttle87
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.