Bagaimana mengizinkan inovasi dalam Metodologi Agile [tertutup]

Adalah satu hal untuk mengatakan bahwa metodologi gesit baik dalam pengaturan di mana persyaratan kurang dipahami, atau bahwa kebaruan signifikan terlibat. Tetapi haruskah itu diterapkan di mana inovasi langsung diperlukan? Jika ya, bagaimana?

Jika apa yang Anda renungkan tidak dikenal di industri ini, atau bahkan dianggap tidak mungkin, mungkin sulit untuk memahami kisah pengguna dan tugas terkait. Sebagai contoh, apakah akan menguntungkan Albert Einstein (atau perusahaan hipotetis yang ia laporkan) untuk menyusun teori relativitas umum dengan memecahnya menjadi epos, sprint, dan tugas? Jika jawabannya "ya," maka akomodasi khusus apa yang seharusnya dimasukkan untuk membantu pendekatan gesit bekerja paling baik dengan cara Einstein dalam mencapai wawasan revolusioner?

Untuk memberikan contoh perangkat lunak tertentu, bayangkan tahun ini 2008 dan Anda ingin menggunakan WCF untuk memberikan kapabilitas tipe COMET atau " polling panjang ". Semua penelitian Anda tentang "pekerjaan sebelumnya" tidak menghasilkan apa-apa, dan Anda bahkan membaca blogger MSDN mengatakan itu tidak mungkin.

Sekali lagi, penyesuaian atau "rasa" apa yang bisa dibawa ke cerita pengguna dan tugas untuk mengakomodasi daya cipta (atau keberanian?) Dari endeaver ini? Atau akankah lebih baik untuk menyimpulkan bahwa upaya ini sangat inovatif (pada 2008), lebih baik dibiarkan sebagai latihan think-tank yang tidak diarahkan?

Inovator yang beroperasi di bawah sprint dua minggu tentu tidak ingin ditembak mati setiap kali ia meninggalkan tugas buntu dan mulai mengerjakan tugas yang baru ditemukan yang tidak dibayangkan ketika sprint ditentukan. Demikian juga, ketika sprint berakhir dan tidak ada kode kerja atau pendekatan kerja yang disampaikan, inovator tidak boleh ditembak jatuh oleh manajemen. Perlu ada cara untuk menyebut upaya tersebut sebagai "sukses" bahkan dalam situasi seperti ini. Dalam mungkin satu atau tiga sprint lagi dari jenis "jalan buntu" semacam ini, inovator akhirnya mungkin menemukan sesuatu yang berhasil.

Bagaimana tangkas memungkinkan manajemen tahu bahwa setiap sprint "ok" meskipun ada kemunduran inovatif? Bagaimana ini dikelola sehingga bagan burn-down tidak terlihat tidak masuk akal?

Pertanyaan judul, di mana inovasi mengacu pada kemajuan kreatif skala kecil di tim yang sudah berjalan baik di Agile.

Jawaban terbaik dirangkum dalam artikel ini tentang "Hari Kartu Emas" .

Ringkasan (diparafrasekan, dan dengan interpretasi saya sendiri yang mungkin tidak mencerminkan maksud penulis) :

• Pengembang dapat mengidentifikasi tujuan yang menarik (merangsang secara intelektual) yang terkait dengan pekerjaan yang ingin mereka garap.
• Tujuan yang meluas ini, setelah disetujui oleh tim (termasuk pemilik produk), menjadi "kartu emas".
• Tim didorong untuk mengambil satu hari untuk mengerjakan "kartu emas" ini.
  • Biasanya ini terjadi pada hari Jumat, sehingga menjadi "Hari Kartu Emas".
• Sehubungan dengan Scrum, Kartu Emas dijadwalkan dan dilacak sama seperti item jaminan lainnya; tim perlu menunjukkan hasil mereka.

Ada beberapa poin lain (tidak ada dalam artikel itu) sehubungan dengan penerapan "kartu emas":

• Jangan biarkan seorang anggota tim tunggal bersenang-senang. Setiap anggota tim harus didorong untuk menghabiskan waktu kreatif dengan mengambil "hari kartu emas" sesekali.
• Sejalan dengan itu, cobalah membuat "kartu emas" sebagai upaya tim (bukan tugas solo), dan manfaatkan tugas itu sebagai momen bersosialisasi (membangun tim).

Pertanyaan mendasar, di mana inovasi mengacu pada penelitian (berbulan-bulan hingga bertahun-tahun dengan pekerjaan mengerikan) yang memiliki risiko nyata tidak menemukan solusi yang berguna.

Pertanyaan sebelumnya, Teknik pemrograman ekstrem manakah yang cocok untuk digunakan dalam lingkungan penelitian? mencakup banyak dasar dari pertanyaan ini.

(Penafian: Saya menulis salah satu jawaban untuk pertanyaan itu, meskipun bukan yang dipilih.)

Ringkasannya adalah bahwa pekerjaan penelitian perangkat lunak dapat berjalan cepat; itu membutuhkan pesertanya untuk memprioritaskan berdasarkan informasi baru (dengan menyerap ide yang ditemukan / dipelajari dan mensintesis yang baru). Ia memberi kesan "lambat" hanya karena "lambat untuk menunjukkan buah keberhasilan, dan hanya jika berhasil."

Pertanyaan ini tentang Manajemen Proyek Beta - Apa pro dan kontra dari memasukkan manajer proyek ke dalam tim peneliti? - Juga mencakup alasan yang sama.

Dalam semangat, ya.

Seperti yang ditunjukkan dalam jawaban mouviciel , semangat riset perangkat lunak sejalan dengan semangat Agile Manifesto. Apa yang akan saya perdebatkan selanjutnya adalah apakah penelitian berisiko tinggi dapat masuk ke Agile sebagai metodologi organisasi atau manajemen ("Agile in practice").

Dalam praktiknya, Anda harus menjawab beberapa pertanyaan.
Daftar ini tidak lengkap ...

Kita harus melacak kembali sedikit tentang bagaimana Agile Metodologi muncul.

Metodologi Agile biasanya digunakan ketika ada sponsor proyek. Selain itu, kesediaan sponsor untuk mendanai proyek terbatas; ia mengharapkan untuk melihat beberapa perangkat lunak yang dapat digunakan (berpotensi dapat dikirim) kualitas dikirimkan secara teratur setelah mendanai proyek untuk beberapa waktu.

Jenis pekerjaan penelitian dalam pertanyaan ini mengacu pada "upaya yang berpotensi tidak dapat dipecahkan". Dengan kata lain, sifat dasar dari jenis pekerjaan ini melibatkan risiko yang pada akhirnya dapat gagal, terlepas dari semua niat dan ketekunan dari orang-orang yang terlibat.

Ini bukan daftar periksa gaya ScrumButt.
Ini lebih merupakan daftar periksa preflight yang memprediksi apakah seseorang lebih baik "Que Sera, Sera"

1. Transparansi di muka. Apakah sponsor proyek diberitahu kebenaran tentang sifat berisiko proyek?

2. Kesediaan sponsor. Apakah sponsor mengetahui risiko dan bersedia melanjutkan pendanaan?

Sponsor perlu memiliki penerimaan risiko yang lebih tinggi daripada proyek bisnis biasa, atau proyek Software / IT / Agile tipikal. Tidak setiap sponsor cocok dengan kriteria ini. Jika tidak cocok, akan baik bagi profesional untuk mundur dari proyek.

3. Transparansi di seluruh proyek. Apakah sponsor diberitahu tentang status sebenarnya dari proyek secara teratur?

Ini untuk menggagalkan upaya untuk menyembunyikan kemunduran atau menjulang kegagalan dalam proyek dengan menyalahgunakan selang waktu antara pembaruan status.

4. Partisipasi aktif dari sponsor. Apakah sponsor tertarik untuk mengetahui detail seluk beluk, naik turun, janji dan keterbatasan dari setiap upaya?

Masalah dengan penelitian perangkat lunak adalah bahwa mungkin ada banyak petunjuk palsu - baik positif palsu (percaya bahwa suatu pendekatan akan berhasil tetapi akhirnya tidak berhasil), dan negatif palsu (mengklaim sesuatu tidak mungkin, hanya dibantah oleh orang lain) .

Proyek tangkas memungkinkan tim (termasuk sponsor dan pemangku kepentingan) untuk mengambil risiko yang diperhitungkan. "Dihitung" berarti bahwa pengambil risiko sepenuhnya diinformasikan. Jika sponsor tidak mau mempelajari detail seluk beluk proyek, maka sponsor tidak akan memiliki informasi lengkap untuk menghitung (menilai) risiko sendiri.

Bahkan jika sponsor bersedia mengambil risiko keuangan, jika tidak mau juga mengambil risiko pengambilan keputusan (dan menerima konsekuensi atas pilihannya sendiri) maka sponsor juga tidak layak untuk proyek-proyek penelitian berisiko tinggi tersebut.

5. Bisakah tim peneliti menunjukkan (menunjukkan) kemajuan mereka dalam bentuk menjalankan perangkat lunak, yang bertentangan dengan slide presentasi?

Pertanyaan ini sesuai untuk proyek penelitian di mana hasil akhir diharapkan untuk menjalankan perangkat lunak. Slide presentasi bisa berguna untuk menjelaskan teori CS, tetapi bisa juga disalahgunakan untuk menyembunyikan kemunduran dalam implementasi perangkat lunak (atau tidak adanya sama sekali). Demo perangkat lunak dimaksudkan untuk menggagalkan penyalahgunaan tersebut.

6. Bisakah tim peneliti memberikan produk perangkat lunak yang bernilai sebagian, bahkan jika sponsor memutuskan untuk menghentikan pendanaan kapan saja dalam proyek?

Pertanyaan ini hanya relevan berdasarkan kasus per kasus. Beberapa proyek penelitian bersifat inkremental; mereka mungkin memiliki banyak tonggak dan hasil. Untuk itu diperlukan tim peneliti untuk memprioritaskan pendekatan mereka untuk memilih "buah dengan harga terendah lebih dulu", atau "pendekatan biaya terendah untuk menunjukkan kelayakan".

Beberapa proyek penelitian tidak bersifat tambahan: untuk menghasilkan terobosan teknologi tunggal yang sangat spesifik. Itu hit atau miss. Untuk jenis proyek ini, satu-satunya hasil tambahan adalah pekerjaan penelitian dan pembuatan prototipe, dan mungkin publikasi akademis. Hasil tambahan yang “tidak dapat dikonsumsi” ini tetap bernilai bagi beberapa jenis sponsor - yaitu, universitas, lembaga pendanaan penelitian, dan perusahaan besar yang berharap untuk membangun itikad baik akademik.

Namun, proyek penelitian yang memiliki karakteristik seperti itu mungkin juga mendukung pendekatan "Pengodean Koboi", seperti yang dibahas lebih lanjut di bawah ini. Ini disebut "peretasan", dan memang terjadi di dunia akademis.

Karena skala waktu dari sebagian besar penelitian akademik, dana penelitian gaya akademik biasanya diberikan dengan komitmen satu tahun atau lebih; pendanaan penelitian medis (akademik dan komersial) dapat dilakukan untuk periode yang lebih lama. Di sisi lain, penelitian tipikal yang didanai secara komersial dapat dihentikan tanpa pemberitahuan, atau sumber daya (tenaga kerja) mereka sepenuhnya dipindahkan ke proyek lain.

7. Bagaimana tim peneliti mengukur skala silo vs lintas fungsional?

Beberapa jenis tim peneliti sangat diam. Seringkali, ini terjadi dalam proyek "multi-disiplin" - tepatnya satu anggota dari setiap disiplin ilmu terlibat. Akibatnya, tidak ada satu anggota pun yang dapat mengambil alih tugas anggota lain, bahkan yang sangat kecil, karena pengetahuan dan keterampilan mereka tidak tumpang tindih. Kesulitan juga akan meluas ke komunikasi dan definisi tugas.

Tim yang sangat tertutup masih akan mendapat manfaat dari beberapa ritual Scrum seperti pertemuan sehari-hari, tetapi selain dari "ritual" mungkin tidak ada banyak interaksi yang terjadi. Dibutuhkan seorang pelatih lincah yang sangat bersosialisasi untuk membuat tim berbicara dan membangun kepercayaan.

8. Jika seorang pelatih lincah hadir, apakah pelatih meresepkan siklus iterasi pendek, tinju waktu, dan memberikan perkiraan waktu?

Setiap praktik lincah ini menimbulkan kesulitan untuk jenis proyek penelitian tertentu. Namun demikian, dilaporkan bahwa beberapa kelompok penelitian yang memiliki keahlian mampu menerapkan praktik ini dalam penelitian lanjutan . Karena tidak ada detail tentang bagaimana pelatihan tangkas terjadi dalam tim ahli ini, kami mungkin tidak dapat mengetahui bagaimana masing-masing kesulitan ini dapat diatasi.

9. Apakah tim peneliti dengan suara bulat memilih untuk mengadopsi gaya pengembangan Solo daripada metodologi lainnya?

Diedit: versi sebelumnya menggunakan frasa "koboi pengkodean", yang menyinggung kurangnya profesionalisme. Namun, ada perbedaan antara pengembangan solo dan pengkodean koboi, dan keadaan dalam item daftar periksa ini dapat membuat pengembangan solo menjadi pilihan yang sah.

Pertanyaan ini menunjukkan bahwa ada programmer yang lebih memilih untuk memiliki sebagian besar pengembangan. Jika tim peneliti sebagian besar terdiri dari pemrogram jenis ini, mengingat bahwa keahlian anggota tim tidak tergantikan (mengacu pada poin silo keterampilan sebelumnya), maka anggota tim mungkin harus diberikan apa yang mereka inginkan, sebagai gantinya untuk keterampilan dan tenaga mereka.

Perbedaan utama antara pengembangan solo dan koboi pengkodean adalah bahwa dalam pengembangan solo, seseorang dapat mengadopsi praktik yang tercantum dalam The Joel Test: 12 Steps to Better Code , seperti penggunaan kontrol versi, otomatisasi pembuatan, dan memperbaiki bug sebelum menambahkan fitur baru .

Beberapa keadaan akan mendukung setiap anggota melakukan pengembangan solo, sedangkan beberapa keadaan akan mendukung pengkodean koboi.

Pengodean koboi lebih disukai jika tujuan akhirnya adalah "membuat suatu poin", dengan menunjukkan bahwa ada sesuatu yang secara teknologi memungkinkan. Tidak ada persyaratan untuk pengiriman - atau kualitas - selain dari presentasi yang baik pada DEF CON® berikutnya .

Pertanyaan terakhir. Jika keadaan tidak memungkinkan tim Agile untuk melakukan penelitian inovatif, lalu bagaimana mereka menggunakan teknologi inovatif?

Bisnis seperti biasa. Biarkan perusahaan lain (atau akademisi, individu atau tim peretas , startup, dll.) Mengatasi masalah sulit terlebih dahulu, dan kemudian membeli / melisensikan teknologi dari mereka. Industri perangkat lunak telah menjalankan prinsip-prinsip ini selama beberapa dekade.

Penekanan pada menunjukkan prototipe kerja awal dalam metodologi Agile memaksa tim untuk mencari solusi yang ada terlebih dahulu, yang merupakan hal yang baik karena dapat menyelamatkan tim dari beberapa pekerjaan yang berlebihan.

Kembali ke Agile Manifesto :

1. Individu dan interaksi atas proses dan alat
2. Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif
3. Kolaborasi pelanggan atas negosiasi kontrak
4. Menanggapi perubahan setelah mengikuti rencana

Tidak ada dalam nilai-nilai ini yang melarang inovasi. Sebenarnya, inovasi memiliki sarang yang lebih baik dengan Agile daripada dengan Waterfall.

Namun demikian, dapat terjadi bahwa implementasi Agile yang biasa menempatkan beberapa kendala pada proyek perangkat lunak yang membatasi inovasi, seperti tenggat waktu (jangka waktu sprint adalah tenggat waktu) atau biaya. Tapi ini bukan masalah dengan Agile, ini adalah masalah dengan organisasi kerja saat ini.

Saya rasa tidak. Agile adalah tentang memakan gajah coklat - mengambil tugas besar dan memecahnya menjadi potongan-potongan yang dapat dikelola yang tidak hanya dapat dikirim, tetapi juga dikirimkan secara teratur.

Jenis proyek penelitian tidak cocok dengan ini - kecuali jika proyek Anda dapat dipecah menjadi potongan-potongan kecil yang dapat ditunjukkan setiap dua minggu (atau lebih lama - mana kata Agile 2 minggu adalah waktu yang harus diambil oleh sprint Anda, proyek tangkas terbaik yang pernah saya miliki dikerjakan memiliki sprint 6 minggu)

Saya tidak akan mencobanya. Saya akan mengambil sedikit alat tangkas yang menurut Anda akan bekerja untuk Anda, dan mengabaikan yang tidak. Terlalu banyak orang berpikir Agile berarti "Anda harus melakukan semua yang menurut scrum tutorial harus Anda lakukan dan tidak boleh ada kebijaksanaan", pendekatan itu sangat tidak tangkas.