Dalam kelincahan, bagaimana tugas infrastruktur dasar pada awal proyek direncanakan dan dialokasikan menggunakan kerangka kerja manajemen yang ketat seperti TFS online?

Di sini saya sedang dalam proses pelingkupan dan memperkirakan proyek pengembangan perangkat lunak baru yang relatif kecil. Saya telah melalui cerita pengguna yang disarankan oleh pelanggan dan menempatkan tugas terhadap masing-masing, dengan perkiraan dan beberapa catatan singkat tentang bagaimana tugas akan diselesaikan. Ada kriteria penerimaan. Semua harus baik dengan dunia.

Ketika melihat pekerjaan yang telah saya rencanakan, saya menyadari ada sesuatu yang hilang. Akan ada pengeluaran awal hanya dengan mengatur hal-hal yang dapat kita gunakan fungsi. Hal-hal yang menjadi milik semua cerita pengguna, bukan satu cerita pengguna tertentu.

Misalnya, bagian dari aplikasi ini adalah layanan yang mem-parsing XML. Dari sudut pandang pengguna ada cerita khusus di mana hal-hal yang berbeda perlu dilakukan tergantung pada konten XML. Sebenarnya menulis parser XML - bit yang mencari file, membacanya, dan mengeluarkan data yang relevan sebelum memutuskan apa yang harus dilakukan dengan konten - adalah bagian dari semua cerita itu. Seperti membungkusnya dalam layanan windows dengan installer dll. Ini adalah tugas pengembang-sentris tanpa relevansi langsung kepada pengguna.

Contoh lain yang relevan dari aplikasi khusus ini adalah mengambil dan menulis ulang blok kode warisan yang buruk yang berguna untuk fungsi aplikasi ini. Sekali lagi, ini tidak memiliki hasil langsung bagi pengguna tetapi itu perlu dilakukan. Di mana perencanaan dan pelaksanaan pekerjaan ini "hidup" dalam rencana proyek yang berfokus pada cerita pengguna?

Saya telah melihat orang memecahkan ini dengan menulis cerita pengguna "Sebagai pengembang, saya ingin ..." tetapi seperti yang telah dibahas di tempat lain ini bukan cerita pengguna . Ini adalah pengembang.

Saya mencari jawaban nyata untuk ini, untuk membantu saya (dan lainnya) merencanakan proyek menggunakan kerangka kerja manajemen yang ketat seperti TFS online. Ini cenderung tidak memiliki fungsi untuk membuat "cerita pemangku kepentingan" atau solusi meta-samar lainnya yang disebutkan dalam jawaban untuk Bagaimana tim Scrum bertanggung jawab atas tugas-tugas infrastruktur dalam pertemuan perencanaan?

— Bob Tway
sumber

Jika saya memberi tahu Anda bahwa komputer atau layanan juga dapat diperlakukan seperti "pengguna," apakah itu mengubah analisis Anda?

— Robert Harvey

Kemungkinan duplikat dari Bagaimana tim Scrum memperhitungkan tugas-tugas infrastruktur dalam rapat perencanaan?

— mmathis

@ mmathis saya melihat pertanyaan itu, dan itu mirip dan relevan. Namun, tidak ada jawaban yang menjawab pertanyaan ini. Terutama ketika Anda memfokuskan fokus pada cara melakukannya dalam kerangka kerja yang ada seperti TFS.

— Bob Tway

@RobertHarvey sebagian, ya. Itu akan mencakup layanan dalam hal ini, tetapi bukan kode warisan. Saya bisa memikirkan situasi lain di mana pendekatan itu mungkin tidak mencakup persyaratan. Saya juga tertarik untuk mengetahui seberapa diterima secara luas yaitu: sepertinya perubahan semantik untuk mengatasi masalah "sebagai pengembang".

— Bob Tway

Anda dapat menipu saat memiliki pengguna sistem, dan iterasi0, atau Anda memotong kue secara berbeda. Fitur pertama memberikan beberapa fungsionalitas pengguna dan infrastruktur yang diperlukan untuk membuatnya berfungsi. Kemudian fitur 2 yang akibatnya memunculkan lebih banyak infrastruktur, dengan cara ini Anda tidak membuang waktu untuk menyiapkan infrastruktur yang tidak Anda butuhkan. Jika Anda sekarang berteriak tetapi itu berarti saya perlu merencanakan ulang, maka Anda tidak lincah.

— ctrl-alt-delor

Jawaban:

Saya suka jawaban lain yang mengatakan untuk memasukkan sebanyak mungkin kode "tooling" ke Iteration 0. Namun, kadang-kadang, jenis alat ini muncul setelah proyek sudah dimulai. Mungkin dalam Iteration 3 Anda menyadari bahwa Anda memerlukan widget parser XML umum untuk digunakan pada berbagai cerita ke depan.

Dalam hal itu, Kisah Pengguna pertama yang bergantung pada potongan arsitektur internal ini adalah milik mereka . Jika Anda akan mengerjakan Story # 345, dan itu akan tergantung pada parser XML Anda sebelum dapat dihitung sebagai 'selesai', maka parser yang dapat digunakan kembali akan dilampirkan sebagai pekerjaan agar cerita tersebut selesai.

Tim saya telah menggunakan pendekatan di atas dan tampaknya berhasil bagi kami.

— Graham
sumber

Saya akan menjawab mirip dengan yang ini. Jika sebuah cerita membutuhkan sesuatu, itu adalah bagian dari cerita itu. Beberapa cerita mungkin hanya mendapatkan keuntungan setelah cerita lain yang membangun infrastruktur. Namun, Anda perlu menyimpan semua cerita yang membutuhkannya agar hanya jika cerita diprioritaskan kembali. Anda tidak bisa memastikan apa yang pertama.

— Jay S

+1 Ini menyentuh pada titik yang bagus. Apakah itu disebut iterasi 0, 1 atau apa pun itu adalah bagatelle. Semua kecuali yang paling tidak masuk akal atau tidak mengerti memahami bahwa beberapa dasar diperlukan. Jika Anda melukis, Anda menyiapkan dinding, jika Anda memasak, Anda memotong, jika Anda seorang musisi, Anda berlatih.

— Robbie Dee

Jika infrastrukturnya biasanya dimasukkan ke Iteration Zero. Apa Iterasi Nol? Ini biasanya waktu antara kickoff dan perencanaan sebelum iterasi yang sebenarnya dimulai.

Sebagai contoh, katakanlah kita membutuhkan layanan web baru. Jadi, saya perlu membuat proyek, mengatur integrasi terus-menerus, mengatur repositori kontrol sumber, mengatur skrip build dan penyebaran otomatis, dll. Pengguna tidak terlalu peduli tentang ini, tetapi kami membutuhkannya terlepas dari apa.

Jadi, pekerjaan itu akan dilakukan dalam iterasi 0. Pada saat iterasi 1 dimulai, sudah akan ada shell proyek baru yang akan dikompilasi, memiliki skrip build otomatis, dan akan digunakan. Sekarang, tidak ada fungsi pengguna yang ada di sana, tetapi siap digunakan.

Saya masih akan melacak dan merencanakan pekerjaan ini sebagai bagian dari pekerjaan iterasi 0.

Refactoring ini terdengar seperti kisah teknis yang bisa diulang setiap iterasi.

— Jon Raynor
sumber

+1 karena kami menggunakan ini juga, tetapi pada kenyataannya Interation Zero adalah Iteration One yang baru. Ini hanya iterasi yang tidak dipedulikan oleh pemangku kepentingan bisnis, tetapi perlu untuk mencapai hal-hal yang dipedulikan pemangku kepentingan.

— Greg Burghardt

Anda dapat memiliki iterasi 0 bonafide tetapi itu tidak berarti Anda tidak dapat mulai memberikan nilai mulai hari pertama. Anda tidak perlu membangun server, penempatan otomatis, dan repositori kode sumber untuk mulai memotong kode - ini dapat terjadi kemudian (atau bahkan secara paralel).

— Robbie Dee

Tergantung infrastrukturnya.

Jika infrastruktur sangat signifikan, atau harus mematuhi peraturan kepatuhan yang rumit, maka Anda mungkin memiliki tim infrastruktur terpisah, yang mungkin memiliki jadwal sendiri. Mungkin Agile, mungkin air terjun. Dalam hal ini, pembangunan infrastruktur akan dikelola dalam proyek Anda sebagai ketergantungan eksternal .

Jika infrastruktur akan dikelola oleh tim Anda, dan mengatur hanya sekali, Anda dapat menggunakan teknik iterasi 0 yang dijelaskan Jon.

Jika pengaturan infrastruktur akan membutuhkan beberapa iterasi (mis. Mungkin Anda mengatur server build Anda sekarang tetapi server QA dan preprod akan dibangun sedikit kemudian) maka buildout mereka dapat dikelola sebagai PBI yang tidak berfungsi. PBI fungsional mungkin memiliki dependensi tertentu pada ini, yang dapat Anda kodifikasi dalam TFS menggunakan tautan "pendahulu".

Dan tentu saja Anda dapat mencampur dan mencocokkan semua hal di atas. Misalnya, Anda tidak dapat melakukan banyak hal tanpa membangun server terus-menerus, sehingga Anda dapat memasukkannya dalam iterasi 0. Sementara itu server prabayar Anda mungkin didefinisikan sebagai tugas untuk iterasi 2 dan 3, dan mereka mungkin memiliki dependensi eksternal pada tim DBA Anda ( yang bukan Agile) yang akan mengalokasikan instance DB Anda di pusat data Anda. Atau mungkin Anda harus menunggu sertifikat SSL dikeluarkan untuk fitur tertentu; mereka dapat masuk dalam iterasi 4, dan setiap item fungsional yang bergantung pada sertifikat tersebut harus dikaitkan dengan mereka dengan hubungan pendahulu / penerus.

Dalam semua kasus, ingat:

Selalu tentukan kriteria penerimaan yang jelas. Perangkat keras memiliki kecenderungan yang menjengkelkan untuk berdiri di server dan menyebutnya selesai ketika belum divalidasi sama sekali.
Selama kickoff iterasi tim Anda, tim harus memeriksa dependensi dan ketersediaannya sebelum melakukan PBI atau item pekerjaan apa pun.

— John Wu
sumber

Orang-orang hardware memiliki kecenderungan yang menjengkelkan untuk berdiri di server dan menyebutnya selesai ketika itu belum divalidasi sama sekali Poin bagus - karenanya prevalensi terbaru dari DevOps.

— Robbie Dee