Tim memperkirakan poin cerita, bisnis menginginkan waktu aktual


15

Saya yakin ini bukan tema yang tidak biasa. Kami memiliki dua tim scrum yang melakukan pekerjaan yang baik untuk memperkirakan cerita pengguna menggunakan poin cerita (rasi tim saat ini baru berusia sekitar 8 bulan, meskipun anggota tim memiliki pengalaman scrum beberapa tahun). Tetapi sulit bagi bagian bisnis perusahaan untuk berhubungan dengan cerita pengguna; mereka menginginkan unit waktu aktual (atau "formula untuk mengonversi poin cerita menjadi jam") sehingga mereka dapat membuat rencana kapan hal-hal akan siap ( "kita perlu tahu kapan kita bisa memberi tahu pelanggan bahwa Fitur X akan dalam produksi " ).

Saya, dan pendahulu scrum master saya, tentu saja telah menjelaskan bahwa "tidak ada hubungan yang pasti antara poin cerita dan waktu aktual" dan bahwa "poin cerita digunakan untuk menentukan berapa banyak tim dapat ditampung dalam sprint", dan saya yakin Anda bisa menebak seberapa puas mereka dengan jawaban itu. Mereka masih ingin tahu, dalam waktu kalender, kapan kita akan sampai ke cerita pengguna ke-27 di backlog.

Bagaimanapun, saya telah mengumpulkan beberapa statistik, dan perkiraan SP kami menerjemahkan ke dalam hasil aktual yang dihabiskan waktu yang sangat berbeda (seperti yang diukur oleh perangkat lunak scrum board kami, yang melacak berapa banyak waktu yang dihabiskan tiket di kolom "bekerja pada" ). Untuk cerita pengguna 1-SP, tentu saja ada bias berat menuju rentang waktu yang sangat singkat (dengan ledakan sesekali), tetapi terutama untuk cerita 2-SP, mereka ada di semua tempat: ada faktor 20 antara penyelesaian "tercepat" dan "paling lambat". Untuk 3, 5, dan 8-SP cerita, penyebarannya juga lebih dari faktor 2.

Ini menunjukkan bahwa (a) tim perlu lebih konsisten dalam memperkirakan cerita pengguna dari (apa yang seharusnya) kompleksitas yang sama, dan (b) tim perlu meningkatkan akurasi mereka dalam pelaporan waktu (mis. Mengingat untuk memindahkan tiket keluar dari "bekerja" saat mereka sedang rapat, saat makan siang, atau bermain bola basket).

Saya memiliki rencana untuk meningkatkan (a) dan (b) tetapi saya merasa itu tidak cukup, bahwa bisnis mengharapkan "lebih konkret" daripada apa yang akan dihasilkan oleh inisiatif ini.

Apa sajakah strategi yang baik dalam memenuhi tuntutan sisi bisnis , sehingga mereka tidak akan terlalu banyak mengganggu dalam cara kita bekerja (mis. Dengan memaksakan penggunaan pelacakan waktu terpisah, yang IMHO akan menjadi bodoh karena dalam hal apa pun akan kurang akurat daripada pelacakan "otomatis" saat ini), sementara pada saat yang sama memungkinkan mereka untuk mendapatkan ukuran konkret untuk kapan cerita akan dilakukan?

(Secara historis, selama perencanaan kami memang memecah cerita pengguna menjadi item pekerjaan yang kemudian secara individual diperkirakan dalam waktu kerja yang sebenarnya , tetapi yang saya bicarakan di sini adalah cerita pengguna di log belakang yang tidak akan memiliki tingkat detail atau istirahat -turun.)

Pembaruan: Manajer saya memiliki firasat bahwa ada semacam distribusi kurva lonceng dari jam-menghabiskan-per-cerita-point, tetapi data yang saya kumpulkan dan grafik yang dibuatnya benar-benar melumpuhkan dia dari gagasan itu. :-)


1
Saya sebenarnya penasaran tentang ini juga, karena tim saya sudah hampir melompat ke SP. Mengapa 2-SP begitu fluktuatif? Tidakkah Anda menetapkannya 2-SP karena Anda memperkirakan tugasnya sebagai quickie? Jika demikian, volatilitas akan tetap ada meskipun Anda menghitung dengan waktu sebagai gantinya. Kecuali Anda mungkin terlihat menghabiskan dua minggu untuk tiket di mana Anda pikir akan memakan waktu 3 hari. Ini volatilitas yang sama di kedua pengukuran, kan?
Alec

3
Jika Anda sudah memiliki 27 cerita berikutnya yang diprioritaskan dan diperkirakan, maka Anda dapat menceritakan di mana sprint kisah ke-27 seharusnya pergi bukan? Dan itu akan memberikan perkiraan tanggal pengiriman. Tentu saja Anda akan terbukti salah tetapi itu adalah perkiraan Anda saat ini. Apa yang saya lewatkan?
Berhentilah melukai Monica

4
Itu sebabnya mereka menyebutnya perkiraan dan bukan prediksi yang akurat. Teknik standar untuk membantu menyelamatkan pantat Anda ketika Anda harus memberikan perkiraan berlaku. Dan jika Anda menerapkan koreksi berdasarkan bukti objektif bahwa estimasi Anda memiliki ketidakpastian tinggi dan bias sistematis, itu bahkan tidak dianggap sebagai kecurangan.
Berhentilah melukai Monica

3
Mungkin item ke-27 perlu dipindahkan ke prioritas tertinggi?
Andy

1
@LewisPringle Katakanlah saya ingin membuat prediksi, tentang lokasi Chuck Norris. Saya bisa mengatakan "1600 Pennsylvania Avenue" dan jika dia berada di Whitehouse, itu akan menjadi prediksi yang cukup akurat dan tepat. Namun, jika tidak, maka itu masih tepat, tetapi tidak akurat. Saya bisa mengatakan, "benua AS". Jauh kurang tepat tetapi lebih mungkin pada saat tertentu untuk menjadi kenyataan. Atau saya bisa mengatakan "di bumi" yang sangat mungkin akurat tetapi sangat tidak tepat sehingga tidak berguna secara efektif. Hasilnya adalah kita perlu mengetahui ketepatan estimasi untuk mengevaluasi akurasinya.
JimmyJames

Jawaban:


16

Anda benar, tidak ada rumus untuk mengonversi poin cerita menjadi jam. Anda bisa mendapatkan konversi meter ke kaki yang sangat mudah, dan sebaliknya, tetapi Anda tidak bisa mengatakan bahwa cerita 3 poin akan memakan waktu X jam, sehingga cerita 5 poin akan memakan waktu Y jam (pecahkan untuk Y).

HorusKol menyentuh bagian selanjutnya ini. Kecepatan sprint Anda sebagai sebuah tim dapat membantu dengan hasil jangka panjang. Katakanlah tim Anda 50 poin per sprint, dan setiap sprint adalah 2 minggu. Jadi 50 poin per sprint dikalikan 50 minggu dalam setahun (dengan asumsi orang mengambil libur 2 minggu untuk liburan) maka tim Anda saat ini dapat melakukan maksimal 2.500 poin dalam 12 bulan.

Jadi bisnis datang kepada Anda dengan 170 poin cerita dan epik. Bagilah dengan kecepatan historis tim sebesar 50 poin (rata-rata setiap sprint sejauh ini) dan Anda mendapatkan 3,4 sprint. Karena kami melakukan perkiraan, bulatkan hingga 4 sprint: 8 minggu. Dua bulan, pada dasarnya. Saya juga suka mengambil 3-4 sprint terakhir dan mengambil perkiraan lain. Katakanlah tim Anda dalam 3 sprint terakhir masing-masing menghasilkan 53, 67, dan 55 poin. Itu bekerja hingga 58-ish poin, yang pada tingkat itu adalah 2,9 sprint - jadi pada dasarnya 3 sprint. Sepertinya garis waktu Anda untuk 170 poin itu tampak seperti 6 hingga 8 minggu.

Katakan bisnis 2 bulan. Jangan beri tahu mereka 6-8 minggu, karena mereka hanya akan mendengar "6 minggu." Bahkan tidak memberi tahu mereka 8 minggu, karena sebagian besar bulan memiliki sekitar 4,5 minggu di dalamnya, dan ketika orang mendengar "4 minggu" mereka langsung berpikir "1 bulan." Setelah perkiraan mencapai sekitar 4 minggu, itu menjadi 1 bulan. Kemudian hanya bekerja berbulan-bulan. Jika Anda mencapai satu tahun atau lebih maka jujur ​​saja jangan memperkirakan pekerjaan itu. Tidak ada gunanya. Terlalu banyak yang bisa berubah dalam setahun.

Saya telah menemukan ini sebagai cara yang cukup akurat untuk mengkonversi poin cerita ke jam ... waktu yang baik, bagaimanapun.

Anda akan mendapatkan variasi dalam jumlah waktu yang dibutuhkan untuk menyelesaikan setiap cerita. Beberapa pengembang bekerja lebih cepat daripada yang lain. Menempatkan semua titik cerita ke dalam mangkuk dan menyalakan blender untuk bekerja dengan rata-rata membantu mengurangi ketidakkonsistenan tersebut.

Oh, dan jangan lupa bagian terpenting:

Pembulatan. Selalu.


Alangkah baiknya jika Anda bisa menggunakan beberapa pengetahuan statistik untuk menentukan interval kepercayaan 90%, 95%, dan 99% Anda. Ini harus bekerja lebih baik daripada kecepatan rata-rata, terutama ketika data historis tidak banyak dan variansinya besar.
Hosam Aly

8

Anda mungkin sudah memiliki beberapa konversi bawaan dari titik cerita ke perkiraan waktu - bagaimana Anda memutuskan bahwa Anda telah mengambil cukup banyak pekerjaan untuk sprint Anda? Anda mungkin mengatakan sesuatu seperti "tim dapat menangani 20 (atau 40 atau apa pun) poin seminggu". Setelah beberapa sprint, Anda harus dapat merevisinya berdasarkan penyelesaian - jadi sekarang 15 atau 25 (atau 35 atau 50 atau ...) menunjukkan sprint - ini adalah kecepatan tim Anda .

Untuk cerita pengguna 1-SP, tentu saja ada bias berat menuju rentang waktu yang sangat singkat (dengan ledakan sesekali), tetapi terutama untuk cerita 2-SP, mereka ada di semua tempat: ada faktor 20 antara penyelesaian "tercepat" dan "paling lambat". Untuk 3, 5, dan 8-SP cerita, penyebarannya juga lebih dari faktor 2.

Beberapa variasi waktu untuk menyelesaikan cerita tertentu baik-baik saja dalam nilai poin - kecepatan memperhatikan ketidakpastian itu dengan menjadi rata-rata dalam sejarah baru-baru ini.

Namun, Anda mungkin perlu mencermati bagaimana Anda menetapkan poin, terutama 2-pointer jika Anda mendapatkan fluktuasi yang begitu besar. Tugas titik yang lebih tinggi seharusnya tidak pasti (dan harus dipecah) - tetapi tugas sekecil 2-pointer harus cukup konsisten.

Karena semua tugas yang diberi nilai poin yang sama harus membutuhkan upaya yang sama, tidak masuk akal bahwa ada rentang waktu yang harus diselesaikan.

Jadi, lihat 2-pointer yang paling lama dalam retrospeksi Anda. Mengapa sesuatu yang mungkin seharusnya berubah menjadi slog 10 hari di pagi hari? Mungkinkah sesuatu telah ditandai pada pagi pertama itu untuk mengatakan "ini perlu menjadi dan epik dan dipecah menjadi tugas yang lebih kecil"? Begitu itu terjadi, tentu saja, pekerjaan ekstra yang diperlukan harus dimasukkan ke dalam tumpukan dan tidak mengganggu sisa sprint.

Juga, coba dan lihat bagaimana tim meremehkan item itu - dapatkah Anda melakukan lebih baik pada item yang akan datang setelah memeriksanya?

Ya, tanggal pengiriman akan didorong sesuai, atau daftar fitur untuk pembaruan dapat direvisi sehingga pengiriman tidak terpengaruh. Tetapi tujuannya adalah untuk meningkatkan estimasi titik masa depan, dan juga untuk mendapatkan garis waktu yang lebih akurat.


Ya ada yang salah dengan tugas 2-SP tersebut. Saya akan mengatakan bahwa pengembang meletakkan estimasi tersebut ketika mereka melihat beberapa tugas yang sulit diprediksi. Tapi mengapa menebak jika Anda dapat melihat tugas-tugas itu dan mencari tahu alasannya
max630

3

Ini seperti ramalan cuaca: semakin jauh, semakin tidak dapat diandalkan. Itu adalah analogi yang semua orang akan mengerti. Kesalahan dalam estimasi bertambah.

Penjualan harus belajar berbicara dalam istilah Scrum kepada pelanggan. Scrum tidak masuk akal secara terpisah, itu seharusnya diterapkan secara vertikal di seluruh perusahaan dan lebih disukai meluas ke ranah klien.

Anda sebagai tim pengembang harus tegas dalam hal ini. Anda dapat memberi mereka harapan dan tebakan tetapi jangan biarkan itu menjadi komitmen yang memperpanjang sprint tunggal.


5
"Penjualan harus belajar berbicara dalam istilah Scrum kepada pelanggan. Scrum tidak masuk akal secara terpisah, itu seharusnya diterapkan secara vertikal di seluruh perusahaan dan lebih disukai meluas ke ranah klien." Itu terdengar bagus, dan tidak diragukan lagi akan membuat pengembangan lebih mudah, tetapi klien kadang-kadang memiliki kendala asli yang mengikat mereka ke kalender. Mereka mungkin memerlukan waktu peluncuran untuk konferensi penting, atau mungkin ada persyaratan legislatif untuk memiliki sistem yang diamanatkan pada tanggal tertentu.
Charles E. Grant

2
@ Charles: Jadi? Yang terbaik yang dapat Anda lakukan dalam pengaturan Scrum adalah menempatkan (set) fitur tersebut dalam sprint sebelum batas waktu mereka. Tidak masuk akal untuk mengatakan "Ya, kami melakukan scrum, tetapi hanya selama tidak ada yang peduli".
Martin Maat

Apakah tujuan untuk memenuhi persyaratan klien atau untuk setia mematuhi metodologi pengembangan? Di setiap perusahaan tempat saya bekerja untuk Scrum adalah alat untuk mencapai tujuan, bukan tujuan itu sendiri.
Charles E. Grant

1
@Charles Apakah Anda menyarankan kesempatan untuk mengirim tepat waktu akan membaik dengan tidak memberi label apa yang Anda lakukan Scrum? Bagaimanapun sekelompok orang berkomitmen untuk suatu tugas. Satu-satunya perbedaan adalah bahwa dibutuhkan waktu lebih lama untuk mengenali dan berkomunikasi Anda tidak akan memenuhi tenggat waktu klien Anda, jika itu adalah hasilnya.
Martin Maat

1
@ Charles - Batas waktu kalender yang keras adalah salah satu komponen yang perlu dipertimbangkan oleh Pemilik Produk dalam prioritas jaminan simpanan. Jika ada tanggal mati, tergantung pada PO untuk memasukkan fitur itu ke dalam tumpukan di posisi di mana ada beberapa kepastian itu bisa mengenai, atau mendorong kembali pada persyaratan itu.
Dan Ray

3

Saya melakukan beberapa hal ketika mendapat pertanyaan seperti ini.

Pertama, saya menjawab pertanyaan tentang masa depan dengan menggambarkan masa lalu. Saya akan mengatakan sesuatu seperti Kami melewati sekitar dua cerita ini per minggu. Jadi, jika tidak ada yang berubah, kami berharap bisa menyelesaikan cerita 27 dalam waktu sekitar 14 minggu.

Kedua, saya ingin pelanggan menghadapi orang untuk bertanggung jawab atas jadwal perdagangan vs risiko. Saya akan mengatakan sesuatu seperti Ingat, tim teknik bekerja berdasarkan perkiraan 50/50. Jika tidak ada yang berubah, ada kemungkinan 50/50 kemungkinan fitur 27 siap dalam 14 minggu. Mungkin Anda tidak ingin melaporkan sesuatu dengan tingkat risiko seperti itu kepada pelanggan. Apakah Anda ingin saya menghitung perkiraan yang kami miliki, katakanlah, kepercayaannya 90%? Anda kemudian perlu meninjau bukti historis Anda dan mengatakan sesuatu seperti: Ada kemungkinan 90% bahwa cerita 27 akan dilakukan dalam 25 minggu .

Terakhir, ingatkan kolega Anda bahwa begitu dia membuat komitmen eksternal, perusahaan ditembaki. Membuat janji eksternal tentang kisah nomor 27 menghilangkan semua kelincahan perusahaan. Anda kemudian akan berkomitmen untuk tindakan tertentu. Setiap kali seseorang datang kepada Anda dengan permintaan perubahan, Anda sekarang perlu menjawab Kami telah berkomitmen untuk menyelesaikan cerita 27 sebelum x date. Saya hanya dapat melakukan perubahan ini jika Anda menghubungi pelanggan dan memberi tahu mereka bahwa komitmen kami tidak lagi valid. Pada dasarnya, membuat komitmen khusus untuk bekerja lebih dari sebulan atau lebih di masa depan datang dengan banyak masalah.


"Membuat janji eksternal [...] menghilangkan semua kelincahan perusahaan" - Ya, kami telah beberapa kali dihantam oleh para penjual yang menjual sesuatu yang mereka tahu tidak bisa kami lakukan, dan harus berjuang keras untuk mencapainya. Tidak sepenuhnya ideal.
KlaymenDK

Dalam situasi itu, kuncinya adalah membuat sebab dan akibat jelas. Katakan kepada orang-orang: Kami tidak dapat mengerjakan tugas X atau memperbaiki bug Y karena kami berkomitmen untuk memenuhi tenggat waktu penjualan . Jika penjualan cukup berharga, maka berebut tim adalah keputusan yang tepat. Jika penjualan kurang bernilai dibandingkan pekerjaan lain, jelaskan mengapa pekerjaan yang lebih bernilai tidak dilakukan.
John_C

3

Anda telah memiliki konversi (sangat kasar):
Sprint scrum (biasanya) adalah dua minggu.
Anda tahu Anda bisa menyelesaikan, katakanlah, sekitar 20 poin poin fitur dalam dua minggu itu (atau bagaimana lagi Anda menentukan apa & berapa banyak fitur dimasukkan ke dalam satu sprint?) Dan sprint sebelumnya mengkonfirmasi perkiraan itu (katakanlah Anda menyelesaikan fitur poin poin 18, 21, 23, 19 dan 20 dalam lima sprint terakhir).

Katakanlah fitur X (dan semua dependensinya) telah diperkirakan sebagai 47 poin cerita.
Jadi Anda dapat memperkirakan bahwa jika Anda menerapkan itu pada prioritas tertinggi Anda harus mengambil sekitar 3 sprint, yaitu 6 minggu (tetapi pastikan bahwa perkiraan Anda memperhitungkan siapa yang dapat melakukan apa - jika 35 dari titik-titik itu adalah pekerjaan DB dan Anda hanya memiliki pada pria DB Anda perlu merevisi perkiraan kecepatan Anda untuk memperhitungkannya).

Yang mengatakan - tegas berkomunikasi bahwa itu adalah perkiraan kasar - ada alasan mengapa sprint adalah dua minggu dan bukan enam. Semakin banyak hal yang perlu dicakup oleh perkiraan Anda, semakin banyak ketidakpastian dan kesalahan yang menyelinap masuk. Juga dengan tegas mengomunikasikan biayanya - yaitu bahwa ini berarti menempatkan tugas di prioritas utama, artinya tidak ada tugas lain yang dikerjakan. Kalau tidak, Anda mungkin mengalami skenario:

"Kapan fitur Y dilakukan?"
"Jika kita fokus pada itu selanjutnya ... 12 minggu"
" 12 minggu?!? Kamu bilang akan butuh 4."
"Ya, tetapi kamu mengatakan kepada kami untuk memprioritaskan fitur X , yang kami katakan akan mengikat semua sumber daya kami dan memakan waktu 8 minggu."
"Tidak bisakah kamu bekerja pada fitur X dan fitur Y pada saat yang sama?"
" erangan "


Alih-alih "mengeluh": "Tentu, kita bisa. X akan memakan waktu 16 minggu dan Y akan memakan waktu 8 minggu".
gnasher729

1

Sprint adalah waktu yang ditentukan, katakanlah 2 minggu. Anda tidak dapat memprediksi beberapa cerita akan dilakukan lebih dari 2 sprint, seperti Anda memiliki sprint Anda saat ini dan sprint berikutnya. Saya berasumsi Anda telah menyiapkan cerita yang dibahas dengan tim untuk sprint berikutnya dan diprioritaskan oleh bisnis. Jadi yang terbaik yang bisa Anda katakan pasti adalah 4 minggu ke depan kerja.

Semuanya lebih dari 4 minggu dapat berubah dan bisnis dapat membuat peta jalan yang tidak ditetapkan dalam jam. Itu harus direncanakan per sprint, katakanlah beberapa epik1 (epik seperti dalam jira banyak cerita yang dikelompokkan) dan epik2 harus dilakukan dalam sprint 47 dan 48 dan epic3 harus dilakukan dalam sprint 49. Epik saya memperkirakan kira-kira dalam hitungan jam sendiri untuk lihat apakah satu atau dua akan muat dalam sprint, toh timeline akan tergelincir. Jika fitur tidak berfungsi, bisnis harus memotong ruang lingkup atau menerima solusi yang tidak sempurna yang dapat diperbaiki nanti sesuai kebutuhan (yang harus gesit, merangkul kenyataan alih-alih mengikuti rencana).

Anda dapat membuat bagan Gantt yang bagus (seperti itulah bisnis) dengan sprint masa depan dan topik / epos utama untuk mereka.

Saya suka membuat rilis setiap sprint dan kemudian saya mempersiapkan rilis dengan apa yang selesai dalam sprint (atau hal-hal yang ditandatangani untuk dirilis oleh bisnis meskipun tidak sempurna), hal-hal yang belum selesai pergi ke sprint berikutnya. Dengan cara ini saya memiliki pengiriman yang dapat diprediksi dalam waktu sekitar 2-3 minggu (satu minggu untuk perbaikan pada kandidat rilis).

Itulah pengalaman saya dengan tim kecil, jumlah kecil ketergantungan luar dan apa yang saya yakini bisnis yang masuk akal. Jarak Anda mungkin beragam.


0

Untuk fitur baru, hampir tidak mungkin memperkirakan waktu yang diperlukan.

Pengalaman dengan pengembangan perangkat lunak menunjukkan bahwa dalam kebanyakan kasus ada detail yang tidak dapat Anda lihat sebelum benar-benar memulai pengembangan. Dalam kasus terbaik, deteils tersebut mungkin memerlukan waktu tambahan, tetapi dalam kasus terburuk proyek juga dapat gagal. Alasan untuk itu adalah kompleksitas pengembangan perangkat lunak itu sendiri.

Ini adalah alasan mengapa SCRUM hanya memperkirakan kompleksitas masalah (poin cerita), tetapi bukan waktu. Satu-satunya peluang yang Anda miliki adalah memisahkan fitur dengan kompleksitas tinggi menjadi lebih kecil. Dengan cara ini Anda bisa meminimalkan risiko.

Karena perkiraan waktu hampir tidak mungkin, tidak ada rumus yang mengubah poin cerita menjadi perkiraan waktu. Kecepatan hanya bisa menjadi perkiraan yang sangat kasar, tidak lebih.

Di SCRUM, pemilik produk dapat mengubah prioritas item backlog sebelum setiap sprint. Oleh karena itu master SCRUM tidak dapat memberikan perkiraan apa pun untuk lebih dari satu sprint. Dia tidak tahu item backlog mana yang mungkin menjadi penting dalam sprint berikutnya.

SCRUM bukanlah metode untuk melakukan hal-hal yang tidak mungkin (rencanakan yang tidak dapat direncanakan) atau membuat pengembangan lebih cepat. Ini adalah sistem peringatan dini jika pembangunan kehabisan waktu. Ini memungkinkan untuk bereaksi dengan cepat pada persyaratan baru.

Ke pos awal:

Anda sudah sangat baik jika Anda mengelola pemisahan sebagian besar tugas Anda menjadi 1 SP hingga 5 cerita SP. Perkiraan kecepatan mungkin lebih baik jika tugasnya serupa dan tim Anda menjadi lebih berpengalaman. Tetapi jika selalu ada bagian yang baru dan tidak layak dalam item baru, Anda harus hidup dengan ketidaktepatan tersebut.

Karena biasanya pengembang Anda menghabiskan waktu dengan pekerjaan non-pengembangan (mis. Rapat), Anda tidak boleh merencanakan dengan 8 jam pengembangan untuk setiap hari, tetapi lebih sedikit, misalnya 6 jam. Kemudian Anda mendapatkan cadangan untuk tugas-tugas lain atau untuk item pekerjaan yang membutuhkan lebih banyak waktu.

Jika kolega bisnis Anda ingin memiliki perkiraan yang akurat (yang merupakan kontradiksi dalam dirinya sendiri), jelaskan kepada mereka masalah bawaan pengembangan perangkat lunak. Kemudian tunjukkan pada mereka keuntungan dari metode tangkas.

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.