Penutupan Proyek di Scrum


11

Dalam lingkungan pengembangan perangkat lunak yang khas, penutupan proyek menandai akhir suatu proyek.

  1. Catatan proyek selesai dan diarsipkan,
  2. sumber daya dirilis,
  3. masalah dan pelajaran didokumentasikan, dan
  4. makan malam formal / pesta yang diadakan untuk perayaan.

Langkah terakhir adalah opsional, meskipun sangat memotivasi peserta. :-)

Bandingkan ini dengan Scrum. Saya tahu scrum dijalankan berdasarkan cerita dari jaminan simpanan . Jadi, secara teknis, setiap iterasi menutup cerita-cerita tertentu. Jadi, ada dua pertanyaan di sini.

  1. Untuk grup yang bekerja pada banyak proyek simultan , bagaimana penutupan proyek cocok?
  2. Untuk proyek yang melibatkan banyak kelompok , bagaimana konsep ini berlaku?

Atau, apakah istilah penutupan proyek tidak berlaku untuk proyek T&M sama sekali?

Jawaban:


7

Untuk grup yang bekerja pada banyak proyek simultan, bagaimana penutupan proyek cocok?

Pertama, "beberapa proyek simultan" dianggap ide yang sangat buruk. Inti dari scrum adalah lari cepat dan dikerjakan. Berpindah proyek untuk memulai sprint lain mengganggu. Melakukan dua proyek sekaligus bukanlah sprint. Ini berantakan.

Namun, Scrum tidak berbeda dari metode non-lincah (air terjun). Ketika backlog dikurangi menjadi sekitar nol, Anda masih selesai. Sama seperti dilakukan seolah-olah Anda memiliki pendekatan air terjun, bukan pendekatan gesit.

Kadang-kadang jaminan tidak nol, tetapi pelanggan senang dan tidak mau lagi. Jadi, Anda sudah selesai. Biasanya dilakukan lebih awal dan lebih murah daripada air terjun (yang harus membangun segalanya, bahkan ide-ide yang ternyata tidak berguna.)

Untuk proyek yang melibatkan banyak kelompok, bagaimana konsep ini berlaku?

Sama seperti proyek non-scrum dengan banyak grup. Tidak ada yang berubah tentang orang-orang. Mereka masih suka pesta yang bagus.

Atau, apakah istilah penutupan proyek tidak berlaku untuk proyek T&M sama sekali?

Mengapa penagihan akan mengubah apa pun tentang sifat pekerjaan atau upacara pada akhirnya?


+1 - Semua poin tepat dan menghargai menyebutkan pesta.
JeffO

Skenario: Satu proyek -> x # cerita. Tim A mendapat x1, tim B mendapat x2 cerita. (x1 + x2 = x) Tim A selesai x1 satu bulan sebelum Tim B. Tim A dibongkar. Tim B selesai, memberikan. Penutupan proyek dilakukan hanya dengan tim B.
CMR

1
@ CMR: Mengapa Scrum berbeda dari proyek lain? Skenario yang sama akan berlaku dalam proyek air terjun dua tim di mana satu tim terlambat satu bulan. Baik?
S.Lott

Setuju. Tidak ada perbedaan. Kira saya tidak perlu fokus pada pemetaan proyek ke cerita.
CMR

@ CMR: Mengapa pemetaan cerita begitu penting? Apa yang membingungkan tentang itu? Bisakah Anda mengklarifikasi apa yang tampaknya membingungkan? Akan membantu pertanyaan untuk menjelaskan mengapa ini tampak membingungkan atau penting atau berbeda.
S.Lott

1

Saya biasanya melihat metode gesit seperti praktik scrum dalam kerangka kerja manajemen proyek yang lebih terstruktur. Ini sama sekali bukan kontradiksi. Agile bekerja untuk pengiriman, tujuannya adalah untuk memberikan perangkat lunak yang tepat lebih cepat. Ini membantu dengan interaksi antara pengembang dan pemegang saham. Ini dapat digunakan sebagai bagian dari program periode tetap atau untuk perangkat tambahan terbuka.

Maka dengan itu dalam pikiran, tidak ada alasan mengapa sisa manajemen proyek tidak dapat dikelola dengan cara tradisional, dengan seorang PM mengelola timeline, biaya dan dependensi lainnya. Setelah selesai, Anda memiliki acara penutupan seperti biasa.

Saya bekerja di bidang keuangan, kadang-kadang peraturan baru terjadi, atau pertukaran baru muncul dan kami memiliki tanggal go live untuk apa yang ditetapkan. Kami masih menggunakan metode Agile untuk pengiriman tetapi dalam kerangka kerja manajer proyek yang lebih tradisional sehingga kami mendapatkannya tepat waktu.

Estimasi unit kerja dan memilih solusi yang dapat dicapai dalam kerangka waktu yang tersedia adalah apa yang membuat kami pengembang yang baik (Salah satu hal yang harus saya katakan).


+1 untuk memunculkan proyek yang tanggalnya benar-benar 'diatur'.
CMR

1

Di Scrum, seperti dalam semua teknik Agile, proyek adalah hal-hal kecil yang datang dan pergi, sementara tim tetap bersama. Jadi tidak ada ritual "proyek-clojure" seperti itu. Melainkan pada proyek berkurang sementara lilin lainnya. Aliran item backlog secara bertahap bergeser dari satu ke yang lain. Tim hampir tidak tahu bedanya.

Memang, tim dapat mengerjakan dua atau tiga proyek berbeda secara bersamaan. Sekali lagi, mereka nyaris tidak tahu bedanya. Item backlog masuk ke tim pada awal setiap sprint, dan tim mengimplementasikannya. Mereka semua mungkin menjadi bagian dari satu proyek, atau mereka dapat dibagi secara merata di antara beberapa proyek. Tim tidak peduli. Tim hanya mengimplementasikan item jaminan yang diberikan.

Jika bisnis perlu mengubah prioritas proyek, mereka hanya mengubah aliran item simpanan ke dalam tim.


+1, ini adalah bagaimana tim saya saat ini melakukan sesuatu. Saya melihat tidak ada masalah dengan pendekatan ini; Saya setuju, semua konsep proyek tradisional mungkin tidak benar-benar berlaku.
CMR

0

Beberapa hal yang Anda diskusikan di sini akan digolongkan oleh sebagian besar proses lincah, dengan hal-hal seperti dokumentasi dan rilis yang sering terjadi sebagai hal yang biasa, alih-alih menunggu beberapa pemicu eksternal. Tentu saja, itu tidak selalu menjadi masalah, tergantung pada jenis pelanggan apa yang Anda miliki dan jenis bisnis apa yang Anda jalani. Misalnya, jika Anda membuat satu bagian dari sistem yang lebih besar yang dimiliki oleh entitas eksternal, biasanya ada tanggal yang mendorong proses, dan tanggal itu akan menjadi waktu yang tepat untuk melakukan pembersihan tambahan dan, tentu saja, pesta. Di lain waktu, bahkan ketika pelanggan adalah pelanggan internal, bisnis mungkin masih mengakui penyelesaian tonggak bisnis / pengiriman utama / lainnya yang lagi-lagi menyerukan akhir dari pembukuan / pesta proyek Anda. Jika perusahaan Anda terlibat dalam perencanaan rilis, itu akan memberi Anda breakpoint alami, tetapi bahkan jika Anda tidak melakukannya, sangat tepat untuk memiliki ukuran keberhasilan yang digerakkan oleh bisnis. Artinya, proyek mungkin tidak lagi menjadi fitur dari proses rekayasa Anda, tetapi mereka tentu bisa menjadi bagian dari bisnis Anda dan merayakan / berurusan dengan mereka dapat dan masih harus menjadi bagian dari budaya perusahaan Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.