Cara Efektif untuk Memperkenalkan Agile ke Tempat Kerja?

Dalam pengalaman Anda (anekdotal atau lainnya), apa sajakah cara efektif untuk memperkenalkan Agile ke dalam organisasi atau perusahaan non-Agile?

DIPERBARUI: Adakah yang bisa berbicara dengan kasus di mana Anda mencoba memperkenalkan Agile tetapi Anda "ditembak jatuh"? Juga, apakah Anda sekarang memiliki pemahaman retrospektif mengapa Anda "ditembak jatuh"?

INI SULIT TETAPI TIDAK MUNGKIN. Kecuali Anda tinggal di surga. Untuk langkah-langkah spesifik yang dapat Anda ambil, saya dengan sepenuh hati menyarankan untuk mengambil salinan Perubahan Takut

• Pertama dapatkan dukungan manajemen . Jika Anda tidak melakukan apa-apa lagi akan menebus yang ini .. Jika level atas adalah semua 'Tenggatnya kemarin ..', 'Akhir pekan kerja untuk 3 bulan ke depan', 'Mengapa Anda menulis tes padahal seharusnya coding? .. kita bisa tes nanti. ' Dodo tidak akan terbang.
• Lihat apakah budaya organisasi Anda cocok untuk gesit. Ini adalah sesuatu yang saya lewatkan .. Untuk meminjam satu baris dari buku .. Prosesnya akan lebih mudah-lebih cepat jika budaya mendukung dan memelihara ide-ide baru, memberikan waktu bagi orang untuk belajar dan melakukan hal-hal baru, cukup sabar untuk mendukung inovasi dengan manfaat jangka panjang dan tidak menganggap kegagalan sebagai hukuman mati
• People : Identifikasi inovator: pengadopsi awal: mayoritas awal: mayoritas akhir: rasio pengurang. 3 yang pertama adalah target audiens Anda awalnya .. harus sekitar 30-40% .. yang memberi Anda massa kritis untuk bisa bergulir. Masalahnya adalah Agile menyalakan lampu sorot pada gajah di dalam ruangan .. kekurangan dan masalah menjadi mudah terlihat .. jika Anda tinggal di tempat yang memiliki "Bozo Explosion" (mengutip istilah Guy Kawasaki) , perubahannya akan sangat lambat dan menyakitkan .. jika sama sekali. Kami memiliki kecenderungan untuk berasumsi bahwa jika sebuah ide bagus, itu akan diterima. Tidak benar. Banyak alasan sosiologis mengangkat kepala mereka.
• Selanjutnya jangan mencoba terlalu banyak hal sekaligus. Tenang dulu .. tenang saja . Caranya adalah dengan menggunakan pendekatan seperti kode-refactoring-legacy-seperti. Temukan luka-luka kecil di sana-sini dan tempel dengan perban yang gesit. Pastikan bahwa orang-orang memahami praktik dan manfaatnya dan mereka harus mengadopsinya dari waktu ke waktu. Tidak semuanya akan menempel tetapi segera menjadi lebih baik secara keseluruhan. Seberapa cepat tergantung pada sejumlah variabel yang beberapa di antaranya berada di luar kendali Anda.
• Ini merupakan investasi pribadi yang besar untuk mewujudkan hal ini . Periksa kembali apakah Anda bersedia untuk membuat komitmen ini dan melalui pasang surut yang dibawanya. Anda juga mungkin harus menyerahkan tongkat kepada orang lain atau yang lebih tinggi. Bersiaplah untuk melepaskan perubahan kepemilikan demi kebaikan yang lebih besar. Jangan jatuh ke dalam sindrom 'Its my baby'.
• Agile berbeda untuk setiap tim, setiap organisasi .. Tidak semua yang Anda baca / usulkan akan berhasil .. biarkan penerimaan memandu Anda menuju hal-hal yang akan bekerja untuk skenario Anda. Temukan cara lain untuk mengimbangi praktik yang tidak berakar.

Berharap itu masuk akal .. seperti yang Anda duga saya telah di ini selama beberapa waktu :)

Dengarkan tim, manajemen, pemangku kepentingan, dan dengarkan petunjuknya. Mereka mungkin merasa sakit di sejumlah area yang Agile langsung atasi.

Tetap pada saran yang dapat langsung meringankan rasa sakit itu. "Kamu tidak bisa menyembuhkan apa yang tidak bisa kamu rasakan" - begitulah.

Ini membutuhkan waktu yang lama, tetapi membangun kepercayaan sangat penting. Dengan kesuksesan masa lalu dan memiliki kepercayaan dari tim dan manajer Anda, mereka akan melihat Anda ketika tiba saatnya untuk mengambil keputusan.

Saya telah melihatnya terjadi dengan mata kepala saya sendiri, setelah bertahun-tahun frustrasi dalam mencoba membuat orang mengubah cara kami memberikan perangkat lunak. Dan sementara saya mengalami kesuksesan sekarang, saya tidak berada di tempat yang hampir selesai. Ada BANYAK bidang untuk perbaikan, dan saat ini saya paling sukses dengan memperkenalkan perubahan kecil yang secara langsung mengatasi beberapa jenis rasa sakit yang kita rasakan.

Terakhir, saya katakan sangat empati. Saya membuat kesalahan dengan menolak sebagian besar ide sebelum saya benar-benar memikirkannya karena saya tidak membacanya di "XYZ agile book." Mendengarkan tim Anda & mencoba menerapkan beberapa saran mereka akan sangat membantu.

Semoga berhasil!

Melewati teknis, kami telah menemukan bahwa menemukan grup dalam organisasi yang dapat membeli ke metodologi Agile dan memberikan 'test bed' sangat penting. Kami memiliki banyak orang di perusahaan kami yang tidak memahami terminologi Agile yang berbeda, bingung oleh persyaratan dan proses, dan ada ketakutan umum.

Kelompok riset saya sangat tertarik untuk mencoba membuat Scrum berfungsi (bersama dengan beberapa metodologi Agile type lainnya). Minat kami memungkinkan kami untuk membentuk test bed di dalam perusahaan untuk mencoba berbagai elemen. Kami melakukan banyak pengajaran pertama - pembicaraan lorong dengan orang-orang, presentasi untuk eksekutif perusahaan, dll. Kami tidak berusaha keras - kami berpendidikan. Kemudian kami meminta izin untuk mencobanya dengan kelompok kami.

Akan ada banyak jawaban tentang menunjukkan secara empiris bagaimana hal-hal seperti pemrograman pasangan, pengembangan yang didorong oleh ujian, Scrum, dll semuanya dapat menghemat waktu, tetapi pada akhirnya saya merasa bahwa bukti tersebut harus berasal dari dalam perusahaan Anda. Temukan grup yang dapat Anda gunakan sebagai test bed dan buat mereka untuk benar-benar melakukannya. Tidak ada yang akan menghilangkan ketakutan lebih baik daripada menunjukkan bahwa kelompok Anda yang mewujudkannya.

Masukkan ke tenggorokan mereka, tetapi tanpa mereka sadari;)

Saya perlahan-lahan mencoba menerapkan prinsip gesit (terutama scrum) ke tempat kerja saya selama 6 bulan terakhir. Saya pertama kali memperkenalkan stand up harian, yang perlu dibiasakan untuk semua orang, tapi itu berhasil dengan cukup baik. Karena kita semua bekerja pada program yang berbeda yang semuanya merupakan bagian dari satu sistem, agak sulit untuk mengikuti scrum menurut definisi. Langkah saya berikutnya adalah memulai rapat sprint untuk mengikuti setiap rilis kami. Kami sudah menjalani siklus panjang sebulan, jadi panjang sprint tidak menjadi masalah. Saya juga berencana untuk sepenuhnya mengikuti prinsip scrum selama proyek besar kami berikutnya. Saya adalah salah satu dari dua pengembang di tim untuk proyek ini, dan dia semua untuk perbaikan terus menerus. Harapan saya adalah bahwa manajemen akan melihat manfaat dari apa yang saya coba capai.

Saya pikir kuncinya adalah membuatnya lambat. Orang-orang yang telah berada di posisi yang sama selama bertahun-tahun umumnya menentang perubahan yang mengganggu, tetapi jika Anda dapat menyelinapnya sepotong demi sepotong, mereka seharusnya tidak menyadarinya. Mulailah dengan pertemuan kecil yang sering pada awalnya juga. Dengan membuat mereka singkat, manajemen seharusnya tidak melihatnya sebagai pemborosan waktu.

Pengembangan berbasis tes. Menunjukkan bagaimana unit test dapat mempercepat dev Anda. waktu sekaligus membuat kode lebih stabil adalah langkah pertama yang bagus menuju minum Kool-Aid lincah.

Tingkatkan diri Anda terlebih dahulu. Benarkah. Contoh adalah cara yang kuat untuk berbicara tentang gesit. Selain itu, seperti yang telah dikatakan seseorang, hindari definisi teknis dan gunakan istilah yang dapat dipahami oleh manajer dan eksekutif. Dua minggu sebagai gantinya Sprint; Perencanaan, bukannya Perencanaan Sprint atau Game Perencanaan; Manajer Produk, bukan Pemilik Produk dan sebagainya. Michele Sliger melakukan presentasi yang luar biasa tentang Agile in the Waterfall Enterprise . Benar-benar harus melihat video. Anda mungkin juga tertarik dengan video lain tentang adopsi yang gesit .

Di tempat saya bekerja, saya belajar bahwa Scrum adalah cara yang baik untuk mulai gesit karena manajemen memahaminya dengan cepat. Sederhana dan memiliki nama yang bagus. Terakhir, ketika melakukan Retrospektif, Anda dapat menyarankan praktik XP sebagai peningkatan dan akan menjadi sangat mudah yang diterima orang setidaknya mencobanya.

Salam Hormat

Kami memperkenalkannya ke dalam tugas 'Pemeliharaan' kami (bug, perubahan berdampak rendah, dll) sebagai sprint 2 minggu. Jadi pengembang yang bekerja pada proyek jangka panjang tetap seperti itu, tapi kami memiliki sprint Pemeliharaan yang berputar. Jadi semua orang menggunakan grafik burn-down dan estimasi poker tanpa mengganggu proyek-proyek besar.

Kemudian ketika setiap proyek besar berakhir, kami memulai yang berikutnya menggunakan sprint 2 minggu lincah. Seluruh proses ini memakan waktu beberapa bulan sebelum semua orang melakukan sprint, tetapi itu berarti bahwa ada lebih sedikit gangguan & semua orang bisa 'memudahkan' ke dalam proses

Di dalam tim pengembangan, memperkenalkan Agile jauh lebih banyak sesuatu yang Anda miliki pada tingkat kendali tertentu.

Namun saya melihat masalah utama adalah persyaratan Agile untuk meminta umpan balik yang berkelanjutan dari "pelanggan" atau perwakilan pelanggan Anda.

Karena itu, Anda benar-benar perlu fokus pada sisi pendidikan untuk mereka yang berada di luar tim pengembangan langsung Anda, karena mereka cenderung perlu mengubah cara mereka bekerja dalam beberapa cara (yaitu lebih banyak kontak dengan tim pengembangan).

Cara terbaik yang akan saya katakan adalah memusatkan manfaat tidak langsung dari mengambil proses Agile dan menyampaikannya dengan jelas kepada pelanggan Anda. Tentu saja jika Anda memiliki area penjualan / akun di perusahaan Anda, hal yang sama berlaku di sana.

Langkah 1: pastikan proyek Anda memiliki tumpukan besar, dan pastikan itu diprioritaskan

Langkah 2: memperkenalkan praktik-praktik SCRUM (iterasi yang dapat dikelola, standup harian, master scrum, pemilik produk, grafik burndown)

Langkah 3: setiap iterasi menyajikan hasil tim dengan burndown

lalu ...
terapkan TDD / BDD, pemrograman pasangan, ulasan kode (semuanya dengan sangat lembut), dan jika Anda memiliki tim yang cukup bagus buat semua orang berada di tempat yang sama (ruang tim jika mungkin).

Yang terpenting, pahami akan ada resistensi (AKAN MENJADI), jadi bersiaplah untuk mengelola itu.

Hal lain yang perlu diingat adalah bahwa jika Anda adalah bagian dari suatu organisasi (besar atau kecil) yang secara keseluruhan tidak akan mengikuti praktik terbaik ini maka mungkin perlu beberapa saat (jika pernah) untuk merasa seperti Anda membuat kemajuan.

Orang selalu tahan terhadap perubahan, dan pindah ke scrum adalah hal yang cukup besar. Motivasi dan arah adalah kuncinya.

Langkah pertama adalah membuat orang termotivasi untuk memberikan kesempatan kepada scrum. Saya menemukan bahwa Google Tech Talk karya Ken Schwaber sangat berguna untuk membuat orang mengenali manfaat scrum sambil memberikan pengantar yang bagus. Mulailah dengan orang-orang yang Anda rasa akan menerima perubahan apakah mereka pengembang atau manajer, sehingga Anda dapat membangun momentum. Mendapatkan manajer di pihak Anda akan menjadi kebutuhan di beberapa titik, tetapi bagaimana Anda menanganinya tergantung pada lingkungan Anda.

Setelah itu, semua orang perlu dilatih, baik itu membaca buku atau seri kuliah. Kecuali jika orang tahu bagaimana scrum bekerja, Anda tidak dapat mulai mencoba menerapkan proses.

Setelah orang termotivasi dan memiliki gagasan tentang apa yang harus mereka lakukan, Anda perlu mengadakan pertemuan perencanaan pertama Anda dan mengatur bagian-bagian scrum yang diperlukan (scrummaster, rapat harian, dll.).

Saya berharap pertemuan perencanaan pertama tidak akan berjalan lancar, dan akan menjadi pengalaman belajar bagi semua orang. Juga beberapa sprint pertama akan sangat berbatu, dan mungkin terlambat. Bagian kuncinya sekarang adalah disiplin dan ketekunan. Jangan biarkan rapat harian berjalan terlalu lama, pertahankan rapat perencanaan tetap pada tugas, dan pastikan semua orang menjalankan perannya dengan benar.

Saya pikir orang-orang yang paling resisten adalah orang-orang yang telah lama melakukan pengembangan perangkat lunak, atau orang-orang yang merasa bahwa dengan pindah ke scrum, mereka mengakui bahwa mereka melakukan sesuatu yang salah sebelumnya. Ini adalah hambatan yang sulit untuk diatasi, tetapi saya pikir dengan menunjukkan manfaatnya, Anda dapat perlahan meyakinkan mereka. Itu hanya butuh waktu. Dalam pengalaman saya, manajer produk benar-benar tahan karena memaksa mereka untuk lebih jelas tentang persyaratan mereka dan apa yang mereka inginkan. Tetapi begitu mereka melihat bagaimana proses gesit menguntungkan mereka dan membuat hidup mereka lebih mudah, mereka naik dengan cepat.

Semoga berhasil!

• Tunjukkan keberhasilan - lihat jawaban tanda
• Berikan perhatian khusus pada prinsip / teknik yang akan menyebabkan dampak tertinggi di perusahaan
• Ingat ini tentang prinsip gesit, dan bukan daftar proses

Sebelum berpikir untuk memperkenalkan pengembangan lincah, jelajahi dahulu yang mana yang paling cocok untuk organisasi / proyek Anda. Jika misalnya Anda melihat scrum pertimbangkan apakah Anda akan menggunakannya secara ketat atau jika scrum lebih longgar, atau bahkan metode lain sama sekali lebih cocok. Jawaban saya ada pada scrum sebagai metode tangkas Anda.

Scrum sangat bagus untuk proyek yang membutuhkan inovasi, di mana sedikit yang diketahui dan di mana eksperimen diperlukan. Ini bukan yang paling cocok untuk melakukan hal-hal seperti memelihara produk yang sudah ada atau menangani pekerjaan pemeliharaan berulang. Untungnya, scrum adalah kerangka kerja yang longgar dan Anda dapat menggunakannya sebaik mungkin.

Untuk pekerjaan pemeliharaan, Kanban mungkin lebih baik untuk Anda atau Anda bisa mencoba beberapa elemen scrum untuk mengelola sprint dan melakukan hal-hal seperti standup harian. Saya menyebutnya "scrum-but", "ya kami melakukan scrum di perusahaan kami tetapi ...". Tidak apa-apa, jangan merasa bersalah.

Untuk memperkenalkan scrum yang tepat dalam organisasi Anda, Anda perlu keterlibatan pemilik produk dan pemegang saham. Jika Anda adalah perusahaan kecil, orang itu mungkin satu orang, bos, dan yang lebih besar seorang manajer produk dan kepala / bos departemen. Saya akan menyarankan dua rute untuk memperkenalkan scrum:

1) Anda dapat mulai menggunakan scrum dalam bentuk yang sedikit lebih longgar untuk mengelola antrian kerja yang ada dengan segera. Tapi lihat juga Kanban.

2) mulai menggunakan scrum dalam bentuk yang lebih ketat pada beberapa proyek baru yang akan membutuhkan inovasi, umpan balik awal dan di mana banyak yang tidak diketahui. Anda dapat menyarankan kepada bos / pemilik produk bahwa scrum akan ideal untuk proyek baru ini.

Tapi ingat! ini bukan hanya tentang kode, pemilik produk memiliki bagian penting dan harus memahami dan memenuhi perannya. Itu berarti misalnya tidak menulis semua spesifikasi di muka, melainkan mulai dengan minimum, iterasi cepat, mendapatkan umpan balik, belajar dan memberi makan itu kembali dan seterusnya. Cobalah untuk bekerja dengan manajer produk yang ingin memperkenalkan scrum seperti Anda tetapi dari sisi pemilik produk, dan idealnya ia harus cukup tangguh untuk menangkis permintaan manajemen dan melindungi sprint.

Dibutuhkan upaya bersama dari pengembangan dan manajemen produk untuk memperkenalkan scrum.

Pada proyek baru semacam itu, cobalah dan buat tim baru dipindahkan ke ruang terpisah dan gunakan catatan tempel untuk memvisualisasikan pekerjaan di berbagai negara seperti jaminan, dalam proses, dll. Jangan terjebak dalam alat elektronik pada tahap ini , jaga agar sesederhana mungkin. Jangan merasa konyol melakukan perencanaan poker dengan kartu ketika Anda mulai juga, begitu tim Anda mencapai kecepatan Anda mungkin tidak akan menggunakannya, cukup angkanya saja.

Dalam pengalaman saya, lebih mudah untuk memperkenalkan scrum dalam bentuk murni terlebih dahulu kemudian mempermudahnya untuk antrian pekerjaan jenis pemeliharaan. Lebih sulit sebaliknya.

Komentar terakhir saya adalah berhati-hatilah dengan berpikir bahwa scrum adalah obat mujarab pengembangan, bukan. Scrum adalah kerangka kerja yang berguna dan sederhana untuk inovasi produk tetapi jelajahi metode-metode lain yang mengkombinasikan sesuai kebutuhan bisnis Anda dan jangan merasa sedih karenanya.

Beberapa tahun yang lalu, saya adalah konsultan di perusahaan yang sangat besar (hampir 20.000 karyawan) yang menjalankan banyak proyek perangkat lunak perusahaan besar. Saya berada di salah satu dari mereka. Yang cukup kritis.

Kami menghadapi banyak masalah dan tekanan sangat membebani kami, tim pengembangan. Masalah biasa terjadi pada industri perangkat lunak, tetapi manajemen memiliki pengalaman yang lebih berorientasi infrastruktur dan sangat sedikit pengalaman berorientasi perangkat lunak. Jadi semuanya terfokus pada kita. Saya pikir itu akan menjadi ide bagus untuk memberitahu manajemen tentang Scrum.

Saya dihadapkan dengan keengganan yang kuat, jadi saya membatalkan ide untuk sementara waktu. Tetapi masalah terus bertambah sehingga dengan sponsor pemimpin tim, akhirnya kami memutuskan untuk membuat Scrum, oleh diri kami sendiri.

Siapa pun, termasuk saya, punya pengalaman dengan Scrum. Jadi kami menemukan kerangka dengan melakukan ...

Saat ini, Scrum digeneralisasi ke seluruh perusahaan melalui program yang dikelola oleh pelatih bersertifikat. Saya tidak tahu apakah inisiatif kami adalah pemicunya. Yang mengatakan, saya tahu bahwa itu adalah revolusi nyata di perusahaan yang cukup kaku.

Saya pikir untuk memperkenalkan sesuatu ke perusahaan seperti itu, Anda harus menghormati prinsip-prinsip berikut:

• Itu harus berubah diperlukan . Jika tidak ada alasan kuat bahwa perubahan harus dilakukan, tidak ada alasan mengapa tim manajemen mengambil risiko.

• Kita harus fokus pada masalah manajemen dan belum lagi masalah pengembang, kecuali mereka adalah bagian dari masalah manajemen. Dengan kata lain, Anda harus datang dengan solusi untuk mereka, bukan untuk Anda. Tempatkan diri Anda pada posisi manajemen. Apa kekhawatiran mereka?

• Anda sebaiknya tidak mengusulkan untuk mengubah seluruh organisasi sekaligus . Anda harus mengusulkan proyek percontohan yang akan menjadi tanggung jawab Anda. Saya menyarankan Anda untuk memberikan tujuan yang realistis, seperti peningkatan visibilitas yang signifikan tentang apa yang sedang terjadi dalam proyek. Ini, IMHO, kontribusi utama Scrum untuk manajemen perangkat lunak. Ini memungkinkan akal sehat manusia untuk beroperasi dan dengan demikian bergerak maju.

• Akhirnya, sangat penting untuk memastikan bahwa orang yang berpengalaman mengendalikan perkenalan ini. Jangan hanya membaca satu atau dua buku. Anda harus mengikuti pelatihan dan menurut saya perlu menggunakan pelatih yang berpengalaman. Jelas, itu bisa dilakukan tanpa, tetapi akan kesakitan :)

Jika Anda mengikuti prinsip dan datang dengan fakta, itu akan berhasil. Tentang fakta, Anda akan menemukan banyak di buku Perangkat Lunak dalam 30 Hari: Bagaimana Manajer Agile Mengalahkan Peluang, Menyenangkan Pelanggan Mereka, Dan Meninggalkan Pesaing Dalam Debu . Ini buku terbaru pencipta Scrum, Ken Schwaber dan Jeff Sutherland .

Dalam posting blog Ken tentang buku ini, Anda dapat membaca:

Jeff Sutherland dan saya telah melakukannya. Kami menulis buku bersama, tulisan bersama pertama kami sejak publikasi awal Scrum pada tahun 1995. Apa yang mendorong kami? Pertanyaan yang sering kita tanyakan:

Bagaimana kami menjual Scrum kepada manajemen kami?

Saya selalu bingung dengan pertanyaan ini. Mengapa Anda harus menjual lebih banyak prediktabilitas, produktivitas, kualitas, nilai, kendali risiko, pelanggan yang puas, karyawan yang terlibat, dan sedikit pemborosan kepada siapa pun dalam manajemen? Namun, saya berbicara dengan Jeff dan kami menemukan bahwa di mana ada asap, pasti ada api.

Kami menghabiskan paruh terakhir tahun 2011 menulis buku. Manajer mana pun, dari atas ke bawah, dapat dengan mudah mengambil dan membaca buku ini.

[...]

Kami melihatnya sepanjang waktu. (pengungkapan penuh: Saya sedang mengembangkan aplikasi manajemen proyek). Masalahnya adalah bahwa metodologi tangkas memperkenalkan ketegangan yang melekat pada organisasi yang dikelola secara tradisional. Biasanya, manajemen tingkat atas ingin dapat merencanakan ke depan. Mereka menginginkan rencana 3 tahun; mereka ingin proyek yang diperkirakan dengan benar; mereka ingin dapat membuat anggaran untuk merekrut orang baru; mereka ingin dapat berkomitmen untuk tonggak penting ketika datang ke mitra / pelanggan.

Tetapi kemudian departemen R&D memutuskan bahwa ia akan lincah. Ini bukan lagi tentang perencanaan ke depan selama dua bulan sebelum menulis kode. Sprint akan menjadi pendek dan melampaui sprint Anda mendapatkan perkiraan resolusi sangat rendah dari hal-hal yang ada di backlog / roadmap. R&D menyadari bahwa persyaratan terlalu sering berubah agar air terjun klasik menjadi efektif, tetapi manajer produk menginginkan visi yang jernih, matang, dan dianggarkan dengan baik tentang bagaimana produk akan terlihat dalam 12 bulan.

Masalahnya, maka, adalah untuk mendamaikan keduanya. Seperti yang saya katakan, kami melihat ini sepanjang waktu terjadi dengan pelanggan kami. Solusi kami adalah menyatukan alat yang digunakan untuk melakukan sprint dan perencanaan jangka panjang. Oke, sekarang inilah bagian dari sumbat tak tahu malu, jadi silakan bawa dengan sebutir garam. Salah satu fitur unik kami adalah kami menggunakan antarmuka yang dapat diperbesar-pengguna untuk mengelola tugas. Berarti sangat mudah untuk menelusuri beberapa kisah pengguna / tugas dan menguraikannya. (Anda dapat melihat tampilannya di sini ). Sebenarnya tidak ada konsep "proyek" di sistem kami sama sekali. Itu semua tugas yang berisi tugas-tugas lain, menghubungkan ke tugas-tugas lain (fraktal, sungguh). Ini menciptakan kekaburan yang bagus antara cerita pengguna, tugas, proyek, epos, dll.

Dalam praktiknya, apa yang dilakukan oleh banyak pengguna kami yang menggunakan metodologi lincah, adalah membuat rencana teleskopik yang menggabungkan peta jalan jangka panjang (atau jaminan) dengan mengelola sprint jangka pendek (atau iterasi). Manajer masih dapat melihat peta jalan yang bagus, perkiraan fitur utama yang menunggu untuk ditambahkan, dan pengembang hanya memperbesar lebih dalam dan menangani tugas kerja yang sebenarnya. Satu keuntungan yang dimiliki ini adalah mengurangi jumlah "tawar-menawar" yang terjadi ketika manajer meninjau rencana kerja. Alih-alih tim pengembangan hanya memberikan perkiraan yang sangat kasar (yaitu "4-6 minggu!"), Mereka mendapatkan kesempatan untuk memperbesar ke masing-masing cerita pengguna yang bersangkutan dan memecahnya menjadi potongan yang lebih kecil. Ketika Anda melakukan itu tiba-tiba ada sedikit ruang untuk tawar-menawar. Anda menghabiskan 10 menit memecah cerita pengguna 5 minggu menjadi potongan-potongan yang berukuran sekitar 1 hari, dan tiba-tiba argumennya bukan "tidak, Anda bisa melakukannya lebih cepat. tidak, kami tidak bisa. ya Anda bisa." tetapi "inilah yang masuk ke dalam upaya ini, termasuk semua pekerjaan tersembunyi yang tidak dipertimbangkan oleh perkiraan awal. Apa yang Anda sarankan agar kami hilangkan? Jaminan kualitas? Pengujian? Melatih orang baru? Menyiapkan lingkungan pembuatan?".

Pendekatan ini berfungsi selama Anda menggunakan alat yang memungkinkan Anda mengubah rencana secepat Anda menyusunnya. Yang merupakan alasan sebenarnya orang saat ini membenci air terjun. Sebagian besar sistem membuatnya sangat sulit untuk benar-benar mengulangi rencana yang ada dan orang-orang secara rasional menolak membuang-buang waktu untuk kegiatan ini.

Oke, saya merasa ini berubah menjadi promosi penjualan, jadi saya akan berhenti sekarang. :)