- Estimasi atau delegasi proyek dimulai dengan mengubah permintaan besar seperti “membuat ini” menjadi daftar tugas yang jelas, dan tiap item harus menunjukkan perubahan yang diinginkan serta kondisi selesai
- Proses pemecahan dilakukan dengan menuliskan langkah-langkah yang diperlukan dari ide, sketsa, atau daftar awal, lalu memecahnya secara rekursif sampai tiap item terdefinisi dengan cukup baik
- Contoh streak tracker untuk aktivitas luar ruangan secara bertahap dipecah menjadi model data, tampilan kalender, pencatatan aktivitas, perhitungan streak, dan streak freeze, sekaligus mengungkap titik-titik yang masih tidak pasti
- “Tugas yang terdefinisi cukup baik” adalah kondisi ketika kita bisa menjawab ya untuk semua hal: perubahan yang diinginkan, bentuk akhirnya saat selesai, semua langkah sampai selesai, dan informasi yang dibutuhkan untuk mulai sekarang juga
- Pemecahan tugas adalah keterampilan yang membutuhkan pattern matching berbasis pengalaman, sehingga tim pemula memerlukan kesempatan latihan yang aman untuk mencoba membuat rencana dan menerima umpan balik
Mengubah proyek besar menjadi daftar tugas
- Pembahasan sebelumnya tentang estimasi proyek mengasumsikan sudah ada daftar tugas yang jelas, tetapi di dunia nyata mungkin perlu terlebih dahulu melakukan tahap sebelumnya, yaitu pemecahan tugas
- Pemecahan tugas adalah proses membagi proyek besar menjadi tugas-tugas penyusunnya; untuk melakukan estimasi atau delegasi, diperlukan unit yang lebih terperinci daripada satu tugas tunggal seperti “membuat gambar ini”
- Untuk proyek pribadi yang dikerjakan sendiri, sketsa saja bisa cukup, tetapi jika ingin menyerahkannya kepada orang lain atau memperkirakan durasinya, tingkat detail perlu ditingkatkan
Contoh: streak tracker pribadi
- Streak tracker pribadi untuk melacak hari-hari ketika melakukan aktivitas luar ruangan digunakan sebagai contoh
- Ingin bentuk yang mirip dengan aplikasi Streaks
- Ingin memasukkan opsi aktivitas luar ruangan seperti lari, bersepeda, dan ski
- Juga ingin menyertakan fitur streak freeze Duolingo
-
Tahap 1: mulai dari sketsa
- Mockup visual adalah titik awal yang baik karena memudahkan pemahaman fitur yang akan dibuat
- Jika proyeknya dibuat sendiri, sketsa seperti ini saja mungkin sudah cukup untuk langsung mulai menulis kode
- Jika tujuannya estimasi atau delegasi, diperlukan daftar tugas yang dipecah lebih kecil daripada “membuat gambar ini”
-
Tahap 2: membagi menjadi unit fitur besar
- Pada pemecahan pertama, proyek dibagi menjadi komponen-komponen kasar
- Pemodelan data
- Tampilan kalender yang menunjukkan tanggal pada minggu berjalan
- Kalender interaktif yang mencatat aktivitas dengan mengeklik ikon dan menandai tanggal tersebut sebagai selesai untuk pelacakan streak
- Menghitung dan menampilkan panjang streak saat ini
- Mengimplementasikan streak freeze
- Untuk menyederhanakan contoh, pekerjaan operasional seperti deployment dan pengaturan database dikecualikan
- Dalam proyek nyata, terutama proyek yang melibatkan banyak orang, lebih tepat memisahkan pekerjaan deployment, frontend, dan backend sebagai item tersendiri
- Tahap ini saja sudah memungkinkan estimasi sampai batas tertentu, tetapi masih ada ketidakpastian seperti cara akumulasi dan pelacakan freeze, catatan historis, serta penambahan atau penghapusan jenis aktivitas
-
Tahap 3: membagi lagi agar kriteria selesai terlihat
- Model data dibagi menjadi jenis aktivitas, aktivitas yang tercatat, freeze, dan streak
- Untuk jenis aktivitas, daftar hardcoded seperti run/bike/ski/climb sudah cukup
- Aktivitas yang tercatat memiliki tanggal dan jenis
- Freeze memiliki tanggal diperoleh dan tanggal digunakan
- Streak memiliki tanggal mulai, tanggal berakhir, dan informasi agregat per jenis aktivitas
- Tampilan kalender statis dibagi menjadi tampilan mingguan, layar utama, tampilan bulanan, navigasi, dan input untuk pindah tanggal
- Untuk pindah tanggal, widget date HTML5 dapat digunakan tanpa input fuzzy date yang rumit
- Kalender mingguan dinamis tidak memasukkan input dinamis ke tampilan bulanan, dan mencatat penyelesaian lewat klik pada jenis aktivitas di tanggal tertentu
- Perhitungan dan tampilan streak dilakukan dengan menelusuri catatan aktivitas untuk menghitung streak, menampilkan streak saat ini di UI, lalu menghitung ulang streak saat aktivitas dicatat lewat UI
- Streak freeze mencakup akumulasi, pencegahan akumulasi ganda, serta penggunaan dan tampilan jumlah tersisa di UI
- Kriteria X hari untuk memperoleh freeze boleh di-hardcode untuk sementara
- Freeze dapat dibawa ke streak berikutnya
- Saat menghitung ulang streak karena aktivitas lama diubah, akumulasi ganda berupa perolehan freeze kembali harus dicegah
Prosedur pemecahan yang diterapkan berulang
- Pemecahan tugas bukan desain yang selesai sekali jalan, melainkan proses berulang
- Mulai dari daftar tugas atau satu proyek besar
- Pikirkan dan tuliskan langkah-langkah yang diperlukan untuk menyelesaikan tugas tersebut
- Periksa apakah tiap langkah sudah terdefinisi cukup baik
- Jika belum cukup, pecah lagi item tersebut
- Tiap iterasi tidak harus lengkap atau akurat; cukup jika sedikit lebih berkembang dibanding daftar sebelumnya
- Ulangi proses yang sama sampai semua tugas terdefinisi cukup baik
Kriteria “tugas” dan “terdefinisi cukup baik”
- Dalam pengembangan perangkat lunak dan estimasi proyek, tugas adalah unit pekerjaan yang terdefinisi cukup baik, lengkap, dan menyampaikan suatu perubahan
- “mengerjakan sesuatu” bukanlah tugas karena tidak memiliki garis besar kebutuhan
- “menebang pohon” bukanlah tugas yang lengkap jika yang dibawa hanya gergaji mesin
- Dalam konteks kerja, sebuah tugas bermakna jika setelah dilakukan ada sesuatu yang berubah
- Apakah sebuah tugas sudah terdefinisi cukup baik dinilai dari apakah pelaksana tugas bisa menjawab “ya” untuk semua pertanyaan berikut
- Apakah memahami perubahan yang diinginkan?
- Apakah memahami seperti apa bentuk “selesai”?
- Apakah dapat mendefinisikan semua langkah yang diperlukan sampai selesai?
- Dengan asumsi tidak ada penghambat atau dependensi, apakah memiliki semua informasi yang dibutuhkan untuk mulai sekarang juga?
- Bergantung konteks organisasi, pengamat seperti project manager, pemangku kepentingan utama, atau auditor mungkin juga harus bisa menjawab “ya” untuk pertanyaan-pertanyaan ini
- Ada juga tugas dengan hal yang belum diketahui yang sulit dipecah lebih lanjut, seperti perbaikan bug
- Dalam kasus seperti ini, teknik seperti timeboxing dapat digunakan
Kepekaan pemecahan yang terbentuk dari pengalaman
- Pemecahan tugas adalah keterampilan yang perlu dilatih, dan wajar jika tidak terasa mudah sejak awal
- Alasan pemodelan data ditempatkan lebih dulu dalam contoh ini bukan algoritme yang jelas, melainkan intuisi berdasarkan pengalaman
- Ada pengalaman bahwa saat membuat alat serupa, pekerjaan berjalan lebih lancar jika model data ditentukan lebih dulu
- Django menyediakan affordance yang lebih cocok dengan alur yang memprioritaskan data model
- Jika belum banyak melihat atau menjalankan berbagai proyek, menentukan titik awal bisa sulit
- Agar tim dapat mengembangkan kemampuan ini, mereka perlu membuat rencana proyek, mencoba memecahnya, dan menerima umpan balik dalam lingkungan yang aman
- Jika rencana awal tidak dihukum meski banyak salah, kesalahan itu menjadi data pengalaman yang akan dipakai untuk pattern matching berikutnya
Hasil estimasi proyek contoh
- Dalam estimasi bonus, setelah tugas dipecah, tiap item diberi kompleksitas, ketidakpastian, jumlah hari perkiraan, dan jumlah hari dalam skenario terburuk
- Total perkiraan dihitung 15,5 hari, dan skenario terburuk 23,5 hari
- Di antara item utama, perhitungan streak dan akumulasi freeze masing-masing memiliki kompleksitas medium dan ketidakpastian moderate, dengan estimasi 3 hari dan skenario terburuk 4,5 hari
- Pencegahan akumulasi ganda freeze memiliki kompleksitas small tetapi ketidakpastian extreme, sehingga diperkirakan 1 hari dan skenario terburuk 5 hari
- Dalam praktiknya, proyek ini selesai dalam sekitar dua belas malam dan satu penerbangan panjang, tetapi desainnya banyak disederhanakan dan algoritme freeze mungkin memiliki bug yang baru akan ditemui nanti
1 komentar
Komentar Hacker News
Pertama, saya hampir tidak pernah benar-benar menjalankan langkah-langkah nyata sampai selesai persis sesuai rencana. Setelah beberapa langkah saja, biasanya ada hal baru yang saya sadari, ada yang terlewat, atau terlihat cara yang lebih mudah, jadi rencana akhirnya tidak lagi diikuti
Kedua, rasanya upaya kreatif untuk memikirkan cara membuatnya terkonsentrasi sepenuhnya di bagian awal, jadi saya tidak suka bekerja dengan cara seperti ini. Sisanya tetap merupakan sebagian besar pekerjaan, tetapi yang tertinggal hanya bagian paling membosankan; mencampurkan kreativitas dan kebosanan secara lebih merata terasa lebih menyenangkan, sehingga lebih cepat dan hasilnya juga lebih baik
Keduanya mungkin saling berkaitan, dan mungkin juga ada kemungkinan saya ADHD
Jika Anda sedang mengeksplorasi atau membuat proyek sendiri dan tidak ada struktur akuntabilitas khusus, maka tidak perlu merencanakannya sedemikian jauh kecuali Anda memang suka perencanaan itu sendiri
Tetapi begitu atasan bertanya, “berapa lama? siapa mengerjakan apa? mulai dari mana?”, maka semacam kerangka jadi diperlukan
Saya juga tidak suka dipaksa menyesuaikan diri dengan sistem yang sewenang-wenang atau terlalu kaku, tetapi sistem seharusnya sederhana dan fleksibel, dan sistem produktivitas dibuat untuk membantu manusia
Sepertinya penulis tidak bermaksud menjadikan ini seperti resep rinci, melainkan ingin menunjukkan pendekatannya agar orang lain bisa mendapatkan ide mereka sendiri
Kadang malah lebih buruk daripada sekadar “rencana tidak pernah berjalan persis sesuai rencana”. Jika Anda terus menambahkan tugas saat eksekusi berjalan, pada akhirnya daftar tugas yang belum selesai hanya akan tersisa berantakan, bercampur antara tugas yang dibuat saat perencanaan dan yang muncul belakangan tetapi sebenarnya tidak lagi perlu
Itu karena tugas-tugas tersebut dibuat tanpa konteks keseluruhan yang baru muncul saat pelaksanaan
Kesenangan dalam pemrograman ada pada sifatnya sebagai kegiatan kreatif yang lentur dan mengalir. Kita membangunnya sambil berjalan dan mengalaminya secara organik
Di lingkungan kerja, pengawasan dan akuntabilitas dibutuhkan, sehingga keorganikan ini sebagian besar dihilangkan
Saat merencanakan pekerjaan yang sama atau mirip di lain waktu, rencana masa depan akan menjadi lebih baik
Para manajer proyek juga punya slogan, “gagal merencanakan berarti merencanakan kegagalan”
Karena saya sering sadar ada begitu banyak hal yang harus diingat dan banyak yang terlewat
Rencana hanyalah cara bagi diri saya di masa lalu untuk mengingatkan diri saya di masa depan tentang hasil ideal yang dulu saya pikirkan, alih-alih terus mengubah rencana dan mengejar kunang-kunang
“Memecah tugas” adalah topik yang begitu besar sampai-sampai bisa menjadi genre buku atau genre podcast tersendiri. Jika melihat buku-buku tentang pengembangan diri atau pengorganisasian, banyak yang menganggap aktivitas memecah tugas sebagai kemampuan manusia yang mendasar dan sudah dimiliki pembacanya
Tetapi dari pengalaman saya maupun cerita yang saya dengar dalam sesi kelompok, memecah tugas itu sangat sulit dan bisa menimbulkan penghindaran atau rasa putus asa
Saran yang paling luas penerapannya yang pernah saya lihat adalah terus pecah lagi sampai tingkat keyakinan bahwa saya bisa menyelesaikan tugas itu dengan sukses mencapai 90%. Tingkat keyakinan ini berbeda menurut kepercayaan diri dan kecenderungan mengambil risiko, jadi ada orang yang mungkin memecahnya sampai probabilitas berhasil sekitar 70%
Waktu yang benar-benar bisa dipakai dalam sehari kira-kira 6 jam, dan ketika seseorang dengan yakin bilang itu bisa selesai dalam “setengah hari”, lalu Anda tunjukkan bahwa itu berarti sekitar 3 jam, mereka tiba-tiba jadi jauh kurang yakin atau malah kesal. Dan tiga hari kemudian mereka masih mengerjakannya
Pendekatan ini ternyata sangat akurat untuk estimasi waktu, tetapi kalau dilihat secara total begitu; estimasi individualnya sering meleset jauh
Pada akhirnya ini semacam estimasi probabilitas. Jika melewati banyak kejadian, hasilnya akan konvergen ke rata-rata
Masalah yang tidak diketahui kebanyakan orang adalah bahwa pengembangan perangkat lunak, lebih dari apa pun, dekat dengan aktivitas kreatif. Tentu ada aspek teknis yang serius, tetapi karena masalahnya sendiri bersifat virtual dan tidak terikat pada batasan dunia nyata seperti teknik sipil, tidak ada satu solusi optimal yang sudah ditentukan
Jika Anda mencoba mendefinisikan solusi sebelum benar-benar memeriksa masalahnya, Anda hanya akan membatasi hasil akhirnya. Sebagian besar eksplorasi justru baru terjadi setelah mulai menulis kode
Dalam perangkat lunak, tidak terlalu penting bahwa hasil akhir dan waktunya tidak terdefinisi dengan jelas, karena tidak ada biaya per unit. Para manajer yang tidak punya latar belakang rekayasa perangkat lunak sering tidak memahami ini
Produk yang bersifat general-purpose bisa dijual ke banyak pelanggan tanpa biaya pengembangan tambahan
Tetapi karena sebagian besar perusahaan beroperasi seperti pabrik, semua proses pada akhirnya menghasilkan produk yang sangat terbatas dan ditujukan pada pelanggan tertentu. Inilah yang dihindari perusahaan teknologi besar
Seluruh industri tampaknya menerima pola ini
Tetapi sejujurnya, saya rasa yang menghambat kebanyakan dari kita justru kurangnya kemampuan untuk tidak melakukan itu. Jika ada sesuatu yang ingin Anda buat, jangan rencanakan semua bagiannya; cukup buat saja hal terkecil yang mungkin punya nilai
Sebagai contoh, Anda bisa mulai dari layar “hari ini” dan empat tombol. Hari ini Anda mungkin bisa membuat tampilan yang menunjukkan empat tombol olahraga untuk ditekan setiap hari. Tidak perlu ada streak, freeze, atau tampilan kalender
Semua ide itu bagus dan nanti juga mungkin akan dibuat, tetapi yang dibutuhkan terlebih dahulu adalah momentum. Beberapa hari kemudian Anda mungkin memutuskan bahwa Anda tidak suka tampilan kalender itu
Lebih banyak proyek membutuhkan dorongan “kerjakan saja, meski kecil”. Selesaikan hari ini, lalu lihat dari titik itu apa pekerjaan berikutnya. Sangat mungkin hasilnya berbeda dari yang dipikirkan pada tahap perencanaan
Tentu ini juga tidak mudah. Menemukan hal yang paling kecil, dan memutuskan untuk merilis tanpa terdistraksi, memerlukan pemikiran dan disiplin. Meski begitu, ini layak dilatih
Ini adalah prinsip bahwa ketika menghadapi ketidakpastian, kita harus fokus pada “hal benar berikutnya yang harus dilakukan” [0]
Ini bukan untuk meremehkan hal tersebut. Menentukan hal benar berikutnya yang harus dilakukan itu sulit, dan dari sudut pandangku, itulah bagian paling bernilai dari perencanaan
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
Misalnya, satu orang membuat metode pembanding untuk pengujian, orang lain mencoba satu pendekatan, orang lain lagi mencoba pendekatan lain, dan orang ketiga mencoba pendekatan lain lagi, lalu semuanya dievaluasi setelah jangka waktu yang ditentukan
Tentu ini hanya masuk akal jika belum ada pendekatan yang lebih disukai atau jelas lebih unggul
Dalam pengembangan nyata, modularisasi bisa menjadi cara untuk paralelisasi. Misalnya, setiap orang atau tim menangani satu komponen
Dalam pekerjaanku, terutama saat masih mencari arah, aku suka bergantian mengerjakan bagian yang berhadapan dengan pengguna dan bagian internal teknis. Jika kita hanya mengembangkan teknologinya tanpa tahu kegunaannya, cara pakainya akan terpaksa mengarah ke arah tertentu; dan merancang antarmuka tanpa memahami teknologinya juga punya jebakan
Namun dalam pekerjaan seperti riset, yang memerlukan eksperimen kreatif dan pembuktian konsep untuk memverifikasi hal-hal yang tidak bisa diketahui sebelumnya, pemecahan tugas itu sendiri runtuh
Karena itu aku jadi terbiasa melakukan sebagian besar pekerjaan pembuktian konsep secara tertutup dan tidak memberi tahu siapa pun
Kalau berhasil, bisa diumumkan. Kalau tidak, kita bisa membuangnya dan lanjut tanpa kehilangan muka atau mendengar orang berkata kita harus tetap membuatnya berhasil padahal sudah jelas tidak seharusnya diteruskan
Katakan saja, “Mari habiskan 3 jam untuk menyelidiki X, 3 jam untuk Y, dan 3 jam untuk Z, lalu adakan rapat perencanaan untuk menentukan apa yang dilakukan setelah itu”
Ada empat kemungkinan hasil. Yang pertama menyelesaikannya, yang kedua menyelesaikannya, yang ketiga menyelesaikannya, atau tidak ada yang menyelesaikannya
Jika itu masalah yang bisa diselesaikan dengan sedikit usaha, peluang untuk menyelesaikannya pada percobaan kedua, yaitu dalam 6 jam, adalah 50%
Dan pada titik tertentu, kita memang harus langsung mengerjakannya
Pemecahan kerja dan estimasi hampir sama saja. Setelah pemecahan selesai, orang dengan pengalaman beberapa tahun biasanya punya estimasi standar untuk tugas-tugas kecil, jadi hanya perlu beberapa menit untuk menempelkan estimasi pada tiap bagian
Dalam kasusku, aku memecah pekerjaan menjadi bagian-bagian yang bisa kuestimasi, dan untuk bagian yang tidak bisa kuestimasi, aku meminta pendapat orang lain
Namun aku tidak menganggap pemecahan kerja sebagai jalan utama menuju kemahiran. Siapa pun bisa membuat skema pemecahan yang buruk
Kemahiran yang sesungguhnya adalah mengenali kapan bukti menunjukkan bahwa pemecahan kerja itu cukup salah sampai menimbulkan masalah, lalu mengomunikasikannya atau mengestimasi ulang [0]
Dan penting juga untuk merasa nyaman bahwa hal seperti itu memang akan terjadi, sehingga kita tidak stres karena harus sejak awal memberikan jadwal yang sangat mungkin berubah
Para manajer biasanya menginginkan roadmap yang akurat sejak awal, tetapi itu berarti meminta hal yang mustahil. Menurutku manajemen yang baik ada pada fleksibilitas, dan pada pemahaman bahwa seiring waktu, saat pengembang belajar, sifat pekerjaan yang semula diperkirakan pun berubah
Contoh kecil di akhir tulisan juga patut dipikirkan. Bahkan jika seseorang telah memberikan estimasi yang akurat, yaitu “selesai dalam beberapa kali makan malam saat perjalanan pesawat”, dia tetap akan menolaknya karena terlalu berisiko
Ini menunjukkan bahwa estimasi bukan sekadar soal akurasi. Ada banyak unsur yang tidak sepenuhnya tertangkap oleh istilah seperti manajemen risiko, manajemen ekspektasi, atau tingkat keakraban terhadap pekerjaan
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - Ada juga tulisan tentang topik ini
Mereka adalah talenta perangkat lunak pemula yang bagus, tetapi karena domainnya baru, kadang mereka benar-benar tidak tahu cara membangun fungsi dasar. Dari pengalamanku, mereka menginginkan tugas yang bisa mereka pelajari dan selesaikan dengan baik, dan itu mendorong pertumbuhan
Hal yang harus selalu diingat adalah bahwa biaya proses itu merupakan suatu spektrum yang perlu disesuaikan dengan tim. Pemain NBA tidak belajar melempar bola melewati rintangan saat pertandingan, tetapi anak kelas 3 SD belajar
Perencanaan dan coaching dalam dua cara itu sama-sama tepat jika sesuai dengan tim masing-masing
Mungkin itu memang kebenaran inti dalam rekayasa perangkat lunak. Bisa jadi versi open source dari aplikasi Streak yang ingin dibuat penulis sudah ada, sehingga ini hanya menemukan kembali roda
Otak tampaknya tidak menyukai daftar tugas. Membuat daftar bisa terasa menyenangkan, tetapi sebagian besar kegiatan startup atau coding adalah eksplorasi
Dan daftar tugas menghambat eksplorasi
Kalau tidak, apa yang berbeda dalam pengembangan perangkat lunak sehingga “saya tidak tahu” menjadi jawaban yang masuk akal dalam profesi kita?
Kadang itu tepat, kadang tidak. “Peta bukanlah wilayahnya”
Untuk memecah pekerjaan menjadi tugas-tugas yang lebih kecil, kita perlu melakukan pekerjaan duplikatif, dan triknya adalah meminimalkan hal itu
Jika kita berusaha sama sekali tidak melakukan pekerjaan yang tidak perlu, pada akhirnya kita harus mengerjakan semuanya sekaligus
Misalnya, anggaplah kita sedang me-refactor program dengan modul A dan B, dan B bergantung pada A. Cara yang paling sedikit pemborosannya adalah me-refactor kedua modul itu sekaligus. Tetapi itu juga yang paling berisiko dan paling sulit diperkirakan
Cara membaginya adalah merefaktor A, lalu menyesuaikan agar B bekerja dengan A yang sudah direfaktor. Setelah itu, jika A direfaktor lagi, muncul risiko bahwa pekerjaan adaptasi yang tadi cepat menjadi sia-sia
Jika ingin membuat pekerjaan yang terbuang menjadi 0, sering kali pekerjaan itu tidak bisa dipecah. Bahkan dengan pengalaman 20 tahun pun saya masih sering ragu melakukan pekerjaan sementara yang nantinya akan dibuang demi membagi pekerjaan
Sebagai gantinya, saya sering mengerjakan tugas yang memakan beberapa minggu dengan pendekatan mencukur habis semuanya tanpa menyisakan satu pun yak hair
Memikirkan masalah yang ingin diselesaikan sebelum mulai itu masuk akal, dan tonggak pencapaian kasar juga penting. Tetapi dalam banyak kasus ada terlalu banyak hal yang belum diketahui, sehingga memecahnya sepenuhnya sama sekali tidak berguna atau bahkan mustahil
Rasanya proyek akan selesai jauh lebih cepat jika waktu yang dipakai untuk memecah proyek justru dipakai untuk mencari atau membuat solusinya. Setidaknya begitulah rasanya
Saya biasanya mendekatinya dengan cara berbeda. Tujuannya adalah memperkirakan upaya yang dibutuhkan untuk menilai sejak awal apakah ini layak dibuat atau tidak. Bisa dibilang alasan pertama adalah membantu penilaian biaya-manfaat
Ini juga bisa sangat bermanfaat bagi tim. Terutama saat bekerja dengan orang yang kurang berpengalaman, pekerjaan bisa lebih banyak dibagi dan diparalelkan
Sepertinya Jacob juga tidak banyak melakukan penguraian seperti ini saat mengimplementasikan aplikasi Streak miliknya, jadi ia tampaknya memberi contoh secara rekursif demi penjelasan
Dalam situasi seperti itu, membaginya menjadi tugas-tugas yang lebih kecil dan menyelesaikannya satu per satu itu berguna. Dengan begitu, bahkan saat sedang buntu atau tidak ingin bekerja, tetap ada kemajuan, dan kemajuan itu menciptakan momentum untuk terus lanjut
Jelas ada nilai dalam kemampuan manajer untuk memperkirakan kecepatan. Hanya saja, begitu mereka terbiasa dengan itu, masalahnya mereka jadi benar-benar tidak memahami kalimat “ini tidak pasti”
Saya juga seorang konsultan, jadi meskipun kami bekerja secara “agile”, sangat penting untuk bisa mengatakan “kami akan mengirimkan ini dalam waktu sekian”