Metodologi pengembangan yang fleksibel adalah ide bagus yang terlalu rumit. Agile Lite adalah upaya untuk menyederhanakan situasi. Anda tidak perlu buku atau seminar untuk menjelaskan Agile Lite. Hanya teks kecil dengan beberapa poin yang dibutuhkan. Ini teksnya.

Agile Lite cukup sederhana. Ini dapat diterapkan pada proyek apa pun, asalkan pekerjaan itu dibagi menjadi tugas yang lebih kecil (masalah). Seperti metodologi tangkas lainnya, ia menggunakan siklus pengembangan pendek - sprint. Tetapi tidak seperti mereka, Agile Lite dengan jelas mengakui prevalensi burnout di industri pengembangan perangkat lunak dan mencoba untuk mengurangi secara langsung dengan memperkenalkan siklus pengembangan tiga minggu / satu minggu istirahat.

Aturan dasar:

• Minggu pertama setiap siklus, manajer proyek, pengembang, dan pemangku kepentingan lainnya menentukan sprint mendatang. Meskipun satu minggu telah dikesampingkan, perencanaan sprint akan memakan waktu tidak lebih dari dua jam, dan dengan organisasi yang tepat, itu akan memakan waktu sekitar 45 menit. Ini adalah minggu yang sengaja mudah: banyak yang bisa berlibur untuk berselancar, melukis, atau yang lainnya.
  
• Sprint berjalan selama tiga minggu tersisa. Selama periode ini, para insinyur mengerjakan tugas-tugas yang dialokasikan untuk mereka selama perencanaan. Karena karyawan dapat jarak jauh dan didistribusikan di seluruh zona waktu, rapat "langsung" jarang terjadi, dan sebagian besar komunikasi dilakukan melalui pelacak (yang berfungsi lebih cepat daripada email). Papan kanban umum seperti Trello baik-baik saja, dan spreadsheet tidak mungkin. Glider harian tidak dianjurkan: pulsa keseluruhan proyek sepenuhnya dilacak oleh pembaruan pelacak.
  
• Setelah sprint dimulai, Anda tidak dapat menambahkan tugas ke sprint, tetapi Anda dapat menghapusnya. Ini mengurangi pengalihan konteks, yang bagus.
  
• Tugas yang belum selesai dipertimbangkan pada sesi perencanaan sprint berikutnya - dan diputuskan untuk memindahkan tugas ke sprint berikutnya, mengembalikannya ke daftar keinginan, atau menugaskannya kembali ke pengembang lain.
  
• Setiap tugas ada di daftar keinginan atau dalam sprint saat ini. Setiap tugas harus diselesaikan selama 4-8 jam.
  
• Seperti telah disebutkan, pengembang disarankan untuk beristirahat selama minggu perencanaan sehingga otak pulih dari sprint sebelumnya. Ini bukan perang salib. Pengembang tidak bekerja di akhir pekan. Semua ini membantu untuk menghindari kejenuhan, yang bermanfaat bagi semua orang.

Meskipun pekerjaan utama dalam sprint dapat direncanakan, terkadang sesuatu yang tidak terduga terjadi. Masalah tak terduga ini disebut Masalah Dukungan.

Selama perencanaan sprint, kami sarankan mengalokasikan waktu untuk menyelesaikan tugas-tugas dukungan yang tidak sesuai dengan perencanaan. Misalnya, "selama sprint berikutnya, Dave diberikan waktu 12 jam untuk menyelesaikan tugas-tugas pendukung (perinciannya akan ditentukan kemudian)." Seringkali berguna untuk mempertahankan rotasi, di mana pengembang yang bertanggung jawab atas masalah dukungan berubah di setiap sprint.

Untuk meningkatkan keakuratan ramalan, pada setiap sesi perencanaan sprint, jumlah pekerjaan dukungan yang sebenarnya dilakukan dalam sprint sebelumnya dianalisis, dan keputusan dibuat tentang apakah diperlukan waktu lebih banyak atau lebih sedikit untuk mendukung sprint berikutnya.

Dalam praktiknya, kelompok yang berbeda memiliki definisi yang berbeda untuk tugas pendukung. Mungkin ini berarti dukungan pelanggan / pelanggan. Mungkin dukungan dari pengembang lain. Terserah Anda untuk memutuskan elemen mana dari metodologi umum ini yang terbaik untuk tim Anda.

Dengan menghilangkan kompleksitas yang tidak perlu, Agile Lite adalah cara terbaik, lebih berkelanjutan untuk mengembangkan perangkat lunak. Ini membantu dalam pengembangan, sambil memastikan tingkat produktivitas yang tinggi secara konsisten.

Agile Lite untuk Pengembang

Jika Anda bukan orang baru di industri ini, maka Anda mungkin mengalami kelelahan. Ini memiliki banyak alasan, tetapi cara termudah untuk menggambarkan kelelahan adalah hasil dari bekerja terlalu keras di bawah terlalu banyak stres terlalu lama.

Semuanya dimulai dengan proyek. Setiap proyek memiliki spesifikasi dan tenggat waktu terperinci. Ketika spesifikasi berubah, batas waktu tidak. Pada akhirnya, tenggat waktu datang, dan spesifikasi telah berubah menjadi sesuatu yang berbeda dari tempat dimulainya. Tentu saja, ini dianggap sebagai kesalahan Anda, dan Anda diminta untuk lembur sampai larut malam atau untuk “meregangkan target.” Akibatnya, Anda bekerja setiap akhir pekan, tetapi apa pun usaha Anda, manajer selalu tidak puas, dan proyek terus-menerus “terlambat”.

Ingin pergi berlibur atau berlibur, Anda akan tampak seperti sepatunya yang tidak mendukung tim. Anda mungkin bekerja di kantor terbuka; semua orang tahu kapan seseorang datang dan pergi, dan semua orang menandatangani kontrak tak terucapkan untuk tidak bekerja lebih sedikit daripada yang lain. Karena itu, orang tahu cara terlihat sibuk. Ketika seseorang bertanya apa kabar, Anda hanya menjawab, “Sibuk! Saya SANGAT sibuk! "

Tetapi pada akhirnya, sesuatu terjadi. Anda dapat berganti pekerjaan, tetapi ini biasanya perusahaan lain di industri perangkat lunak. Mungkin Anda memberikan semua kekuatan Anda untuk menyelesaikan kehancuran, dan kemudian perusahaan melepaskan Anda, karena Anda sudah "tidak cocok dengan budaya." Mungkin Anda berhenti dan mulai berdagang mobil, karena pemrograman terlalu membuat frustrasi. Seperti kata pepatah, jika Anda ingin kehilangan kesenangan hobi, cobalah untuk menghasilkan uang dari itu.

Saya menawarkan solusi. Ini adalah bentuk Agile yang jelas dirancang untuk menghindari kejenuhan: Agile Lite. Tidak ada kerja lembur. Pekerjaan teknik sedang berjalan, dan pengembang memiliki cukup waktu untuk mengisi ulang otak mereka. Overhead manajemen minimal.

Hampir seluruh sistem dijelaskan dalam enam poin di atas. Itu dapat diubah sesuai dengan tujuan Anda. Tapi saya ingin menyoroti satu fitur dari Agile Lite. Di sini kami secara eksplisit mengatakan: "Hei, tim yang fleksibel terbakar dengan cara yang sama seperti dalam metodologi pengembangan lainnya. Mungkin bermanfaat untuk menuliskan aturan eksplisit untuk mencegah overheating mesin, yang merupakan tim teknik. "

Mari kita berhenti memanaskan mesin. Kami punya banyak pekerjaan. Sebenarnya, ini adalah jurang maut. Tetapi hidup ini terlalu singkat untuk sepenuhnya dihabiskan untuk bekerja, stres, dan akhirnya kelelahan.

Agile Lite untuk Manajer

Apakah perusahaan Anda mengalami masalah dengan pengembang? Apakah proyek sering melewati tenggat waktu? Sudahkah Anda bekerja dengan pengembang yang memulai dengan sempurna, kemudian perlahan-lahan menurunkan, dan kemudian menghilang? Mungkin ini adalah programmer berbakat yang telah mengalami kejenuhan.

Burnout sangat umum di industri perangkat lunak dan merupakan alasan utama mengapa banyak proyek perangkat lunak gagal. Burnout dapat digambarkan sebagai gejala gangguan stres pasca-trauma yang terkait dengan proyek atau organisasi tertentu. Sebagai contoh, otak tampaknya mati dan Anda merasakan kecemasan ekstrem hanya dengan menyebutkan proyek tertentu. Ini kelelahan. Seorang pengembang di negara ini, kemungkinan besar, tidak akan dapat terus bekerja pada proyek ini, dan dalam proyek-proyek berikutnya tidak akan dapat bekerja dengan kekuatan penuh. Burnout dapat melumpuhkan karier.

Ini mirip dengan menjalankan mesin mobil pada kecepatan tinggi untuk waktu yang sangat lama tanpa menambahkan oli atau bahan bakar. Pada akhirnya, mesin ini akan rusak dan sulit untuk merakitnya kembali.

Prinsip dasar Agile Lite dijelaskan di atas dan dapat berubah sesuai dengan tujuan Anda.

FAQ + pernyataan umum

Satu-satunya aturan umum dalam dunia pengembangan gesit adalah bahwa setiap orang melakukan kesalahan. @ fwip

Jadi, insinyur mendapat cuti 12 minggu per tahun untuk berselancar dan melukis? Bagaimana ini akan bekerja di dunia di mana bekerja dari 9-00 menjadi 21-00 enam hari seminggu menjadi norma?

Saya pikir pengembang Anda harus beristirahat sebanyak yang mereka butuhkan.

Saya perhatikan bahwa minggu kerja 40 jam itu pernah dianggap sebagai ide radikal. Google memulai dengan 80% dari waktu kerja untuk proyek-proyek besar, sekarang kami memiliki 75%, saya ingin menguranginya hingga 10% (metode Ferris) pada akhir tahun 2020-an.

Sistem 996 (dari jam 9 pagi sampai jam 9 malam, 6 hari seminggu) adalah pendekatan yang berlawanan, yang berupaya memperpanjang 40 jam kerja minggu menjadi 72 jam. Saya melihat ini sebagai kemunduran dan saya pikir kita harus berhenti memfetiskan lembur. Bahkan, itu tidak meningkatkan produktivitas.

Selain itu, Anda memutuskan apa yang harus dilakukan selama "minggu istirahat": pergi berlibur, menetapkan beban kerja yang lebih ringan atau yang lainnya. Jawabannya mungkin tergantung pada minggu tertentu.

Mungkin "minggu mudah" lebih mudah bagi orang daripada "minggu istirahat". Gunakan apa yang lebih nyaman bagi Anda.

Surfing dan melukis sama sekali tidak wajib, mereka diberikan hanya sebagai contoh. Saya sendiri bahkan tidak berselancar dan melukis.

Apakah orang ditugaskan tugas atau mereka sendiri yang memprediksi apa yang akan mereka dapatkan?

Mereka memprediksi. Tidak apa-apa jika perkiraan Anda salah. Ini adalah bagian dari proses, dan semuanya dalam satu tim.

Mungkinkah itu disebut iterasi alih-alih sprint?

Tentu saja! Sprint cocok untuk saya.

Apakah mungkin untuk melakukan iterasi geser dalam gaya kanban, di mana tanggal mulai dan berakhir bervariasi dan tergantung pada keadaan?

Saya sangat menghargai konsep siklus kerja dengan tanggal mulai dan berakhir tertentu, dan ditentukan oleh satu blok tugas. Iterasi geser yang tidak disinkronkan dengan loop tertentu akan merusaknya.

Mengapa tepatnya sprint tiga minggu?

Karena pengembangan plus pemulihan ditempatkan dalam 13 slot per tahun. Ketika siklus selesai, yang baru dimulai. Seminggu "istirahat" memungkinkan Anda melakukan reboot sebelum dimulainya sprint baru. Ini adalah tentang mencapai irama dan interval yang jelas dan konsisten.

Apakah ini berarti bahwa tanggal awal dan akhir sprint sering jatuh di pertengahan bulan kalender?

Ya

Apakah pengembang terlibat dalam perencanaan sprint?

Ya Mereka tidak dilarang menghadiri pertemuan. Itu tidak perlu, terutama jika pelacak tugas berfungsi dengan baik, dan tim mendiskusikan beberapa poin untuk sprint berikutnya selama yang sebelumnya.

Saya lebih sedikit rapat. Hanya sedikit orang yang menyukainya. Jika Anda salah satunya, maka jangan mengandalkan saya.

Apakah perencanaan sprint membutuhkan waktu seminggu?

Tidak, itu intinya. Ini minggu yang mudah.

Apakah stand-up benar-benar masalah?

Dalam pengalaman saya, ya. Biasanya setiap orang berdiri dalam lingkaran, mendengarkan satu orang selama 20 menit. Tentu saja, ini adalah pendekatan yang "salah", tetapi saya belum pernah melihat ada orang yang melakukannya dengan benar, dan lebih memilih untuk meninggalkan glider harian sama sekali. Lebih sulit (atau setidaknya tidak nyaman) untuk melakukannya ketika tim Anda didistribusikan secara geografis. Tetapi jika mereka sangat berharga bagi Anda, jangan biarkan saya menghentikan Anda.

Haruskah kita melakukannya dengan cara ini?

Tidak. Tidak ada yang memaksa Anda melakukan apa pun. Ini adalah rekomendasi, bukan aturan.

Ini bukan agama.

Aturan-aturan ini hanya bersifat politis dalam arti propaganda selama 40 jam seminggu bersifat politis.

Apa yang berhasil bagi Anda mungkin tidak berlaku untuk orang lain. Apakah kamu tahu tentang ini?

Saya yakin akan hal itu!

Klaim yang Sering

Anda tidak perlu membuat prediksi waktu, karena perkiraan tidak mungkin.

Ramalan dianggap sebagai ramalan, bukan kontrak yang ditandatangani dalam darah. Karena itu, jika mereka tidak dihormati, ini normal. Berusaha keras dan mencoba membuat perkiraan sebanyak 4 jam.

Pengembang tidak dapat dipercaya, dan Anda perlu melacak semua waktu mereka, karena itulah cara kerja dilakukan.

Saya benar-benar tidak setuju, tetapi saya tidak bisa dengan cepat menjelaskan alasannya. Kami memiliki perbedaan mendasar dalam pandangan dunia.

Ini bukan Agile.

Tentu saja Agile, dia tepat di judul.

Ini tidak realistis.

Namun itu berhasil.

Anda melakukan kesalahan tangkas.

Sayangnya, masalah dengan Agile adalah tidak bisa dilakukan dengan benar.