Apakah saya boleh memiliki orang dengan banyak peran dalam tim Scrum?

Saya mengevaluasi beberapa metodologi Agile-style untuk kemungkinan pengenalan ke tim saya. Dengan Scrum, dapatkah orang yang sama melakukan beberapa peran? Kami memiliki tim kecil yang terdiri dari empat pengembang dan desainer web; kami tidak benar-benar memiliki petunjuk (saya memenuhi peran ini), penguji QA atau analis bisnis, dan semua tugas pengembangan kami berasal dari CIO. Pengujian otomatis dipandang sebagai pemborosan waktu total, dan semuanya berfokus pada kecepatan dan bukan kualitas.

Apa yang akan terjadi adalah CIO akan datang dengan tugas pengembangan (apakah fitur atau bug) dan memberikannya kepada pengembang (bukan untuk seluruh tim, kepada individu, sering secara pribadi atau tiba-tiba) yang kemudian diharapkan menyelesaikannya. CIO tidak mengumpulkan persyaratan di luar gagasan awal (dan ini telah menggigit kami sebelumnya karena kami akan menerapkan sesuatu hanya untuk mengetahui bahwa tidak ada pengguna akhir yang dapat menggunakan fitur ini, karena mereka tidak berkonsultasi atau bahkan diberitahu tentang hal itu. sebelum kita mengembangkannya, dan dalam kepanikan kita akan diberitahu untuk mengembalikan perubahan) tetapi mengharuskan untuk mengatakan / menyetujui semua yang kita lakukan.

Hal pertama yang pertama, apakah gaya Scrum perlu dipertimbangkan untuk memperkenalkan beberapa standar dan praktik? Dari membaca, Scrum tampaknya mengandalkan sedikit lebih banyak kepercayaan dan komunikasi dan lebih fokus pada manajemen proyek daripada pada pengembangan, yang merupakan sesuatu yang sama sekali tidak kita miliki karena kita tidak memiliki kemiripan manajemen proyek saat ini.

Kedua, jika itu bisa berhasil, apakah itu tidak masuk akal untuk seseorang, katakanlah pada diri saya sendiri, untuk bertindak sebagai ScrumMaster dan pengembang? Atau untuk pengembang yang juga menjadi Pemilik Produk (meskipun kemungkinan ini adalah CIO, yang bukan pengembang)? Saya menyadari Scrum Master dan Pemilik Produk harus menjadi orang yang berbeda tetapi pada saat yang sama saya tidak berpikir kita memiliki seseorang yang memiliki kualitas seorang Pemilik Produk (kemungkinan itu akan berubah menjadi "Saya butuh semua cerita ini, saya tidak peduli bagaimana tetapi menyelesaikannya "jenis kesepakatan dan / atau pembekuan apa pun akan dibekukan karena iseng).

Sepertinya saya bahwa saya mungkin perlu mengambil dan memilih potongan-potongan Scrum / XP / Lean untuk mengimbangi bagaimana hal-hal dilakukan saat ini, karena sangat tidak mungkin bahwa mentalitas dapat diubah; misalnya Pemrograman Pair tidak akan pernah terbang (dilihat sebagai pemborosan, Anda mendapatkan setengah dari tugas yang dilakukan jika Anda membutuhkan dua orang untuk semuanya), TDD akan menjadi penjualan yang sulit, tetapi siklus pendek akan disambut.

Scrum, Kanban atau metodologi Agile lainnya terutama adalah metodologi yang berfokus pada proyek pengembangan perangkat lunak . Dengan kata lain, ini adalah praktik manajemen proyek pada dasarnya.

Sebanyak Anda sangat ingin Anda dan tim Anda untuk melakukan pekerjaan proyek, Anda akan menemukan bahwa Agile hanya tidak akan bekerja di organisasi Anda karena fakta bahwa Anda benar-benar tidak melakukan pekerjaan "proyek" atau mengabdikan diri Anda sebagai sebuah tim untuk sebuah "komitmen proyek".

Anda dapat mengatur proyek mini di sekitar fitur yang kompleks, tetapi pada kenyataannya Anda tidak memiliki koneksi ke analis bisnis atau pengguna akhir, jadi bagaimana Anda dapat memverifikasi bahwa Anda menyampaikan Cerita Pengguna ketika Anda tidak memiliki cara untuk benar-benar mengetahui apa itu pengguna mau?

Satu-satunya pemangku kepentingan Anda adalah bos Anda, dan dia pada dasarnya memastikan bahwa tim Anda tidak ada untuk melayani pemangku kepentingan lain dari proyek, Anda ada sebagai tim untuk melayani dia dan kebutuhannya terlepas bagaimana hal ini memengaruhi pemangku kepentingan lainnya.

Di atas semua itu, ia memberikan tugas individu kepada individu dan mungkin memprioritaskan hal-hal segera ketika ia memutuskan bahwa mereka harus pergi. Anda tidak dapat berfungsi dalam metodologi proyek Agile jika sumber daya proyek individu akan diprioritaskan kembali pada saat pemberitahuan, atau jika sprint akan ditahan.

Seharusnya tidak bekerja seperti itu

Sprint adalah komitmen oleh seluruh tim untuk mengirimkan sebagian cerita pengguna pada tanggal yang ditentukan. Setelah dimulai, sprint harus diselesaikan sampai selesai sebelum reprioritization atau perubahan terjadi. Bagaimana sebuah proyek seharusnya dikelola ketika dijalankan dalam lingkungan ad-hoc yang semrawut itu?

Anda tidak bekerja di lingkungan yang kondusif untuk metodologi manajemen proyek Agile. Anda bahkan tidak bekerja di lingkungan yang kondusif untuk metodologi Waterfall. Anda bekerja di monarki dan Anda hanyalah raja-raja yang melakukan perintahnya dan memadamkan api.

Ini bukan pembuatan tim proyek pengembangan perangkat lunak.

Jadi dengan cara yang sangat tidak jelas saya menjawab pertanyaan Anda dengan mengatakan bahwa dalam situasi Anda itu benar-benar tidak masalah jika individu memainkan banyak peran. Anda memiliki masalah yang jauh lebih besar di tangan Anda. Anda bertanya bagaimana cara menghilangkan noda air dari karpet di rumah tanpa atap.

Seperti yang saya catat di sini , jika Scrum Master atau Pemilik Produk memiliki tugas yang dapat ditindaklanjuti, mereka juga anggota Tim.

Yang mengatakan, Anda akan memiliki masalah serius menjadi Agile kecuali Anda benar-benar menerima dari kedua CIO Anda dan pelanggan Anda. Apakah CIO Anda bersedia mematuhi kenyataan bahwa ia tidak dapat menambahkan item kerja mid-sprint, tetapi harus menunggu sampai yang berikutnya? Apakah dia mau memprioritaskan barang yang akan dikembangkan? Dari apa yang Anda tulis, sepertinya dia memiliki apa yang Anda lakukan, dan karenanya harus menjadi Pemilik Produk. Jika dia tidak mau, Anda tidak akan berhasil lebih dari yang Anda lakukan saat ini.

Scrum bisa menjadi solusi yang bagus untuk masalah Anda dalam penugasan CIO kepada pengembang ad hoc, tetapi hanya jika CIO akan menyetujui proses tersebut. Saya menduga bahwa CIO Anda tidak akan suka diambil tugas langsung. Tetapi jika Anda bisa mendapatkan CIO untuk menyetujui dia menulis cerita pengguna dan kemudian memprioritaskannya, ia bisa menemukannya sebagai cara yang sangat efektif untuk mengelola. Tapi itu akan dimulai dengan Anda meyakinkan CIO Anda untuk tetap berpegang pada proses.

Scrum adalah sesuatu yang perlu dipertimbangkan, tentu saja. Namun, ada sesuatu yang bisa dikatakan untuk melibatkan semua yang terlibat di halaman yang sama dan menerima beberapa perubahan pada struktur bersama dengan mendapatkan setidaknya beberapa sprint untuk menyelesaikan berbagai masalah awal dalam menggunakan metodologi ini.

Pemilik Produk harus berada di luar tim pengembangan karena jika tidak akan ada konflik kepentingan yang buruk yang disajikan di sini. Scrum Master mungkin merupakan pengembang meskipun tidak ada konflik yang buruk dalam kasus ini.