Learn Scrum: ya. Jika hanya untuk mempelajarinya untuk menambah keahlian umum Anda. (tapi rasanya "Larangan Scrum" mungkin adalah yang Anda cari ...)
Scrum adalah kerangka kerja yang bagus, tetapi prinsip inti adalah "Iterasi (Sprint) akan diperbaiki durasinya" Saya belum pernah melihat pekerjaan ini dalam tim yang sangat kecil yang lebih didorong oleh interupsi daripada tidak. Jika Anda benar-benar dapat mendaftar dan berkomitmen untuk bekerja dalam kotak waktu tetap (1 minggu?) Maka Scrum adalah kerangka kerja yang keren. Jika Anda tidak bisa ... maka Scrum menyenangkan untuk dipelajari karena ia memiliki beberapa konsep bagus yang menerjemahkan dengan baik untuk hal-hal lain ... seperti ....
Backlog - Scrum atau tidak, simpan daftar prioritas hal-hal yang perlu Anda lakukan. Saya suka Excel (atau Google Doc Spreadsheet ...) Anda mungkin menyukai yang lain. Saya akan menyimpan alat yang sangat kecil jika Anda adalah tim yang sangat kecil. (Spreadsheet >> Pengolah kata karena Anda dapat mengurutkan dengan mudah.)
Pemisahan perencanaan dan komitmen - Rencanakan dalam notasi abstrak (poin) dan konsisten (8pts adalah sekitar 2x cerita 4pt dan 4x cerita 2 poin) Ketika waktu untuk "melakukan pekerjaan" lihat kembali masalah dan buat sketsa keluar dalam hitungan jam. Jangan mengubah poin.
Komitmen - dapat dilihat oleh orang lain saat Anda berkomitmen, dan memenuhi komitmen Anda
Retrospektif - setelah Anda melahirkan, renungkan apa yang bisa dilakukan dengan lebih baik.
dll.
Scrum cukup mudah untuk dipahami bahwa itu mungkin merupakan titik awal yang baik. Jika Anda suka, saya akan mempertimbangkan menggunakan varian "Scrum-larangan" - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Tidak ada hal lain yang menurut saya "sangat terdokumentasi dengan baik" dengan komunitas yang cukup aktif untuk mendukungnya.
Saya ingin juga merekomendasikan metodologi Crystal Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer dan http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Kecil / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), tetapi melibatkan cara membaca dan menggali lebih banyak.
Hal-hal seperti XP memberikan detail lebih lanjut tentang praktik tertentu, jadi saya juga mengatakan membaca buku: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= buku & ie = UTF8 & qid = 1304359834 & sr = 1-1
Saran bacaan terakhir: Selama Anda setuju dengan manifesto Agile, dan ikuti prinsip-prinsip: http://agilemanifesto.org/principles.html Anda harus dalam kondisi yang layak.
Rekomendasi pribadi: Adopsi TDD (tidak dapat dinegosiasikan, IMHO) Pertahankan jaminan simpanan (sesuai Scrum) Selalu pertahankan ukurannya dan urutkan berdasarkan prioritas. Segerakan hal-hal "terlalu besar untuk dilakukan di antara interupsi" ke dalam potongan-potongan kecil. Buat orang lain menetapkan / meninjau prioritas (tidak ada dua item mendapatkan prioritas yang sama. ever.) Membuat lingkungan build Anda dapat membangun / menguji / menyebarkan (ke lab env) dalam 5-10 menit Tunjukkan kepada pelanggan Anda (internal dan eksternal) hasil penyelesaian sebuah cerita. Cerita tidak selesai sampai pelanggan Anda setuju. Tarik Cerita dari atas tumpukan dan kerjakan saat Anda menyelesaikan cerita saat ini. Jangan biarkan lebih dari 2 hal terbuka sekaligus. Selesaikan satu gangguan sebelum memulai yang lain.
semoga ini membantu