Ruang lingkup pembangunan di bidang perangkat lunak / IT Orang-orang dan individu yang terkait dengan pengembangan perangkat lunak dan bidang IT ingin menggunakan istilah "pengembangan perangkat lunak" untuk menggambarkan bidang tertentu kerja mereka dan keterlibatan profesional. Istilah "pembangunan" sangat banyak digunakan untuk menggambarkan sejumlah kegiatan katering untuk bidang IT. Hal ini dapat berkisar dari mengembangkan kode untuk aplikasi dan sistem, untuk mengembangkan aplikasi mobile untuk sistem operasi mobile seperti Android, iOS, Symbian, Windows OS, dll (kunjungi http://en.wikipedia.org/wiki/Mobile_operating_system), "manufaktur "software game menggunakan bahasa scripting seperti Ruby, AGSScript, Lua, Marathon markup language, Ada, C ++, C #, D, Lisp, Mercury, Pascal, Perl, Python, Scheme, JavaScript, Java, VBScript, EDL, dll, (kunjungi http://en.wikipedia.org/wiki/List_of_programming_languages) melakukan pengembangan web menggunakan HTML, CSS, PHP, Joomla, DotNetNuke, Jawa, dll, dan bahkan mengembangkan seluruh sistem operasi untuk tablet dan PC (kunjungi http://en.wikipedia.org/wiki/List_of_operating_systems tahu lebih banyak tentang sistem operasi).
Faktanya adalah seperti pada hari ini, terminologi "pengembangan perangkat lunak" secara luas digunakan untuk menyebutkan hampir semua jenis atau kegiatan yang terkait dengan program dan pengembangan "computerizable" kode dari jenis apa pun, dengan cara apapun, atau cara. Ketika metodologi tertentu atau kerangka yang digunakan untuk mengembangkan kode computerizable dan membuat proyek perangkat lunak, penting untuk memastikan apakah ruang lingkup pengembangan termasuk kegiatan tertentu saat ini Anda terlibat atau berhubungan dengan. Pengembangan perangkat lunak dan manajemen proyek kerangka kerja seperti Agile memiliki potensi untuk mengembangkan sukses IT proyek terkait yang melibatkan sebagian besar platform pengembangan dan sistem operasi.
Faktanya adalah seperti pada hari ini, terminologi "pengembangan perangkat lunak" secara luas digunakan untuk menyebutkan hampir semua jenis atau kegiatan yang terkait dengan program dan pengembangan "computerizable" kode dari jenis apa pun, dengan cara apapun, atau cara. Ketika metodologi tertentu atau kerangka yang digunakan untuk mengembangkan kode computerizable dan membuat proyek perangkat lunak, penting untuk memastikan apakah ruang lingkup pengembangan termasuk kegiatan tertentu saat ini Anda terlibat atau berhubungan dengan. Pengembangan perangkat lunak dan manajemen proyek kerangka kerja seperti Agile memiliki potensi untuk mengembangkan sukses IT proyek terkait yang melibatkan sebagian besar platform pengembangan dan sistem operasi.
Apakah kerangka Agile?
Sementara menjelaskan Agile dengan cara sederhana dan mudah, dapat dipahami sebagai kumpulan metodologi pengembangan proyek dan kerangka kerja, yang setiap kerangka kerja atau metodologi dapat digunakan secara sukses untuk mengembangkan proyek-proyek dari hampir semua jenis dan sifat dinamis, termasuk proyek pengembangan perangkat lunak. Kerangka ini didasarkan pada pengembangan iteratif dan inkremental, di mana terorganisir diri dan tim pengembangan diri mengelola mengerti, rencana, dan mengembangkan proyek-proyek di bawah pengawasan seorang pemimpin proyek, dan menawarkan produktivitas dalam bentuk ledakan singkat siklus pengembangan (berulang pembangunan) dikenal sebagai sprint. Sebuah fitur unik dari semua kerangka Agile adalah bahwa pembangunan yang dilakukan oleh tim adalah "shippable" di alam yaitu kode yang dikembangkan selama siklus pengembangan produk independen, diuji, diverifikasi, terdokumentasi, dan siap untuk penyebaran setelah itu ketat diperiksa apapun "manufaktur" cacat.
Kedua, fitur yang sangat penting dari pembangunan Agile adalah bahwa individu "memiliki" proyek sangat erat kaitannya dengan persetujuan pembangunan yang dilakukan oleh tim. Sebuah khusus "kode" atau "sepotong" fungsionalitas diperiksa untuk regresi setelah dikembangkan, dan kemudian disajikan kepada para pemangku kepentingan dan pemilik proyek. Mereka memastikan pembangunan yang dilakukan, dan jelas itu sebagai "OK" untuk integrasi masa depan ke dalam produk yang sebenarnya. Hal ini menyebabkan keberhasilan pengembangan proyek perangkat lunak, karena manajemen selalu sadar tentang apa fungsi saat ini sedang dikembangkan oleh tim, dan sampai sejauh mana itu memenuhi tujuan proyek. Jika pemilik proyek merasa produktivitas yang ditawarkan oleh tim tidak up-to-the-tanda, atau gagal untuk memuaskan mereka dalam hal nilai bisnis (berapa banyak yang penting kode atau fungsi adalah dari sudut pandang pasar, dan berapa banyak itu sangat berharga dari sudut pandang keuangan) yang ditawarkan oleh fungsi tersebut, mereka dapat menolak seluruh fungsi dan menginstruksikan manajer proyek untuk membangun kembali script tertentu atau kode, berdasarkan satu set baru masukan dan persyaratan yang direkomendasikan oleh mereka. Hal ini memastikan bahwa proyek software selalu "mempertahankan" nilai bisnisnya setiap saat, bahkan ketika produk sedang dikembangkan saat ini.
Sebuah fitur penting yang ketiga dari kerangka Agile adalah bahwa semua kegiatan dalam proyek ini adalah "waktu kotak", dan oleh karena itu, harus diselesaikan dalam jangka waktu yang telah ditentukan. Dalam proyek Agile, setiap kegiatan yang terikat waktu. Semua kegiatan yang terkait dengan pembangunan "dikonfigurasi" yang sesuai dengan kebutuhan proyek yang unik, dan durasi "ditempelkan" kepada mereka sehingga mereka dapat diselesaikan dalam waktu yang ditentukan. Hal ini memastikan bahwa proyek tidak "tarik-on" dan memperpanjang tanpa batas. Biaya pengembangan yang terjadi saat proyek sedang dikembangkan dapat benar dan "menguntungkan" dikendalikan, sehingga proyek tidak menjadi "terlalu" mahal dan sulit untuk mampu secara finansial.
Kedua, fitur yang sangat penting dari pembangunan Agile adalah bahwa individu "memiliki" proyek sangat erat kaitannya dengan persetujuan pembangunan yang dilakukan oleh tim. Sebuah khusus "kode" atau "sepotong" fungsionalitas diperiksa untuk regresi setelah dikembangkan, dan kemudian disajikan kepada para pemangku kepentingan dan pemilik proyek. Mereka memastikan pembangunan yang dilakukan, dan jelas itu sebagai "OK" untuk integrasi masa depan ke dalam produk yang sebenarnya. Hal ini menyebabkan keberhasilan pengembangan proyek perangkat lunak, karena manajemen selalu sadar tentang apa fungsi saat ini sedang dikembangkan oleh tim, dan sampai sejauh mana itu memenuhi tujuan proyek. Jika pemilik proyek merasa produktivitas yang ditawarkan oleh tim tidak up-to-the-tanda, atau gagal untuk memuaskan mereka dalam hal nilai bisnis (berapa banyak yang penting kode atau fungsi adalah dari sudut pandang pasar, dan berapa banyak itu sangat berharga dari sudut pandang keuangan) yang ditawarkan oleh fungsi tersebut, mereka dapat menolak seluruh fungsi dan menginstruksikan manajer proyek untuk membangun kembali script tertentu atau kode, berdasarkan satu set baru masukan dan persyaratan yang direkomendasikan oleh mereka. Hal ini memastikan bahwa proyek software selalu "mempertahankan" nilai bisnisnya setiap saat, bahkan ketika produk sedang dikembangkan saat ini.
Sebuah fitur penting yang ketiga dari kerangka Agile adalah bahwa semua kegiatan dalam proyek ini adalah "waktu kotak", dan oleh karena itu, harus diselesaikan dalam jangka waktu yang telah ditentukan. Dalam proyek Agile, setiap kegiatan yang terikat waktu. Semua kegiatan yang terkait dengan pembangunan "dikonfigurasi" yang sesuai dengan kebutuhan proyek yang unik, dan durasi "ditempelkan" kepada mereka sehingga mereka dapat diselesaikan dalam waktu yang ditentukan. Hal ini memastikan bahwa proyek tidak "tarik-on" dan memperpanjang tanpa batas. Biaya pengembangan yang terjadi saat proyek sedang dikembangkan dapat benar dan "menguntungkan" dikendalikan, sehingga proyek tidak menjadi "terlalu" mahal dan sulit untuk mampu secara finansial.
Prinsip Agile dan fitur
Kerangka Agile berbeda drastis bila dibandingkan dengan linear tradisional atau metodologi Waterfall. Dalam Agile, pengembangan proyek dilakukan dalam ledakan singkat kegiatan bukan dalam tahapan yang harus "menyelesaikan" satu demi satu.
Fitur Agile utama meliputi:
Fitur Agile utama meliputi:
- Tim pengembangan lintas-fungsional yang terdiri dari pengembang, programer, penguji, personil QA, penulis teknis, analis sistem, dll semua bekerja sama sebagai tim komposit tunggal melalui upaya kolaboratif, menawarkan dan berbagi ide, dan saling membantu selama proses pembangunan.
- Bekerja pendek, siklus pengembangan serba cepat, dengan tujuan terfokus - pembangunan Iteratif.
- Produktivitas shippable pada akhir siklus pengembangan berulang - pengembangan Incremental. Fungsionalitas terus "tumbuh" melalui siklus pengembangan sampai seluruh aplikasi, sistem, atau produk dikembangkan.
- Komunikasi manusia dan keterlibatan lebih diprioritaskan kewenangan pengelolaan dan delegasi kerja.
- Jumlah transparansi dan visibilitas kemajuan tim untuk proyek pengguna pemilik, stakeholder, dan akhir.
- Umpan balik dan saran membantu untuk mengoreksi diri dan menawarkan cara-cara baru dan sarana untuk melaksanakan lebih cepat, lebih efisien, dan pengembangan dapat diandalkan.
Sebuah fitur penting dari semua kerangka Agile adalah bahwa kerangka independen terhadap sifat proyek yang akan dikembangkan yaitu kerangka tidak tergantung pada platform atau lingkungan digunakan untuk mengembangkan proyek perangkat lunak tertentu. Arsitektur atau desain dapat bervariasi, dan bisa apa saja. Aspek penting adalah bahwa kerangka Agile harus diimplementasikan dalam proyek pertama, dan manfaatnya dicairkan selanjutnya. Silahkan http://en.wikipedia.org/wiki/Agile_software_development.
Apa itu scrum Agile?
Scrum, sebentar, adalah "ringan" kerangka Agile, digunakan secara luas untuk mengembangkan dan memberikan "workable" produk perangkat lunak, sangat sering, dan secara konsisten. Produk perangkat lunak dapat berkisar dari pengembangan proses web baru dan sistem, solusi game, plugin, aplikasi mobile, situs eCommerce, portal perusahaan, pengembangan tema Wordpress, RAD (Rapid Application Development) proyek, OOP (Object Oriented Programming) proyek, CAD / CAM solusi drafting, pelabuhan pemrograman dan konfigurasi utilitas, pengembangan web dan platform interfacing solusi, dll Scrum mematuhi semua prinsip Agile dan fitur yang dibahas di atas, karena kerangka yang "diwariskan" dari Agile sendiri.
Scrum menawarkan baru, dan cara yang lebih baik untuk mengelola proyek perangkat lunak. Ada banyak alasan teknis mengapa Scrum populer dan mengapa banyak Fortune 500 perusahaan lebih memilih untuk menggunakan kerangka kerja untuk tujuan pengembangan proyek mereka. Sementara diperkenalkan kepada Agile Scrum, sebuah pertanyaan yang secara tidak sengaja datang ke pikiran seseorang adalah mengapa Scrum begitu populer? Mengapa ada begitu banyak "hype" tentang Scrum? Apakah Scrum menawarkan formula ajaib, yang dapat bekerja keajaiban untuk proyek Anda dan pengembangan perangkat lunak? Mengapa sebuah organisasi yang telah mengikuti metodologi pengembangan tertentu, dan merasa nyaman melakukannya, harus beralih ke Scrum? Ada artikel terpisah yang berkaitan sepenuhnya dengan mengapa Anda harus memilih untuk Scrum. Intinya adalah, artikel ini fokus pada menjelaskan Scrum untuk individu yang baru untuk topik, dan sama sekali tidak tahu apa kerangka adalah semua tentang, dan apa yang dapat "melakukan" untuk Anda. Upaya telah dilakukan untuk menjelaskan bahwa Agile Scrum berlaku untuk hampir semua jenis pengembangan perangkat lunak, dan memiliki fitur tertentu yang membuat kerangka kerja yang sangat populer serta "kuat".
Scrum menawarkan baru, dan cara yang lebih baik untuk mengelola proyek perangkat lunak. Ada banyak alasan teknis mengapa Scrum populer dan mengapa banyak Fortune 500 perusahaan lebih memilih untuk menggunakan kerangka kerja untuk tujuan pengembangan proyek mereka. Sementara diperkenalkan kepada Agile Scrum, sebuah pertanyaan yang secara tidak sengaja datang ke pikiran seseorang adalah mengapa Scrum begitu populer? Mengapa ada begitu banyak "hype" tentang Scrum? Apakah Scrum menawarkan formula ajaib, yang dapat bekerja keajaiban untuk proyek Anda dan pengembangan perangkat lunak? Mengapa sebuah organisasi yang telah mengikuti metodologi pengembangan tertentu, dan merasa nyaman melakukannya, harus beralih ke Scrum? Ada artikel terpisah yang berkaitan sepenuhnya dengan mengapa Anda harus memilih untuk Scrum. Intinya adalah, artikel ini fokus pada menjelaskan Scrum untuk individu yang baru untuk topik, dan sama sekali tidak tahu apa kerangka adalah semua tentang, dan apa yang dapat "melakukan" untuk Anda. Upaya telah dilakukan untuk menjelaskan bahwa Agile Scrum berlaku untuk hampir semua jenis pengembangan perangkat lunak, dan memiliki fitur tertentu yang membuat kerangka kerja yang sangat populer serta "kuat".
Bagaimana Scrum bekerja?
Proses Scrum sebenarnya dapat membuktikan menjadi sulit dipahami, pada awalnya, untuk Scrum pemula. Meskipun implementasi Scrum tidak sulit, orang perlu memahami dan membiasakan diri tentang apa yang kenaikan produk, dan bagaimana hal itu benar-benar terjadi selama proses Scrum. Aspek kedua adalah untuk mengenal tentang peristiwa Scrum. Pertemuan khusus, yang dikenal sebagai "peristiwa" yang penting untuk memantau kegiatan pembangunan, dan menganalisis keandalan dan efektivitas fungsi yang dikembangkan oleh tim. Mereka juga membantu untuk mengumpulkan umpan balik dari anggota tim serta pemilik proyek sehingga nilai bisnis proyek tidak terpengaruh, dan terus menerus - bahkan ketika produk tersebut sedang dikembangkan. Hal ini bermanfaat untuk mendapatkan "gambaran" dari proses pertama.
1. konsepsi Proyek - Sebuah ide!
Semua proyek, apakah melibatkan pengembangan perangkat lunak, atau sebaliknya, mulai dengan "ide". Proyek dikembangkan dari kebutuhan. Sebuah proyek direncanakan untuk memenuhi persyaratan tertentu atau mencapai tujuan tertentu. Selain itu, setiap hasil proyek menjadi "sesuatu" dalam jangka waktu tertentu - sebuah proyek tidak bisa memperpanjang tanpa batas. Hal ini penting di sini untuk membedakan antara "proyek" dan "program". Program umumnya lama disebut, dan bahkan dapat berlangsung selama bertahun-tahun, tidak seperti proyek-proyek yang memiliki jangka hidup yang relatif singkat dan terakhir untuk periode singkat, mulai dari beberapa bulan bahkan tahun.
Biasanya, seseorang, atau sekelompok individu menyadari akan lebih bermanfaat untuk dimasukkan ke dalam upaya dan sumber daya, dan mengembangkan "sesuatu" sehingga "hal lain" dapat dengan mudah terpenuhi atau dicairkan. The "sesuatu" adalah produk, dan "hal lain" adalah solusi bahwa proyek ini seharusnya memberikan. Tahap pengembangan proyek melibatkan banyak diskusi dan sesi brain storming, dimana produk dibayangkan dan "meskipun lebih".
Scrum tidak mencari selama tahap ini. Namun, visi yang dilihat oleh pemilik proyek, dapat, atau mungkin, mempengaruhi cara di mana Scrum diimplementasikan dalam proyek, di masa depan. Hal ini karena sifat produk yang akan dikembangkan mungkin memerlukan Scrum untuk dikonfigurasi dengan cara tertentu untuk mendapatkan hasil positif dari proyek tersebut.
Biasanya, seseorang, atau sekelompok individu menyadari akan lebih bermanfaat untuk dimasukkan ke dalam upaya dan sumber daya, dan mengembangkan "sesuatu" sehingga "hal lain" dapat dengan mudah terpenuhi atau dicairkan. The "sesuatu" adalah produk, dan "hal lain" adalah solusi bahwa proyek ini seharusnya memberikan. Tahap pengembangan proyek melibatkan banyak diskusi dan sesi brain storming, dimana produk dibayangkan dan "meskipun lebih".
Scrum tidak mencari selama tahap ini. Namun, visi yang dilihat oleh pemilik proyek, dapat, atau mungkin, mempengaruhi cara di mana Scrum diimplementasikan dalam proyek, di masa depan. Hal ini karena sifat produk yang akan dikembangkan mungkin memerlukan Scrum untuk dikonfigurasi dengan cara tertentu untuk mendapatkan hasil positif dari proyek tersebut.
2. rilis Project - Memulai dengan proyek perangkat lunak
Setelah proyek ini "memikirkan" langkah logis selanjutnya adalah untuk bekerja di luar seluk-beluk mengenai dinamika proyek - tujuan proyek, definisi produk, bagaimana proyek idealnya memberikan produk, dengan cara apa, apa yang harus menjadi "kekuatan" dari tim, berapa banyak anggota tim, dll
Proses pembangunan Scrum tidak datang ke dalam gambar bahkan selama tahap ini. Dokumentasi yang berkaitan dengan proyek yang dibuat dan "segala sesuatu" mengenai produk yang akan dikembangkan tersebut selesai - dalam warna hitam dan putih. Scrum tidak mendukung dokumentasi yang ekstensif. Anda tidak harus menyiapkan diagram alir sistem rinci dan struktur desain yang luas untuk memulai dengan pembangunan Scrum. Ide dasar akan cukup, dan Anda hanya harus menghabiskan banyak waktu dan upaya yang bisa Anda "mulai" dengan aktivitas pembangunan yang sebenarnya. Hanya cukup informasi dan spesifikasi untuk mengembangkan beberapa fitur produk yang paling penting.
Rilis proyek dihadiri oleh "Produk Owner" - orang yang berfungsi sebagai manajer proyek dalam proyek Scrum, yang Scrum Guru yang luar negeri yang Scrum diterapkan dengan benar dan diikuti oleh tim sementara proyek sedang dikembangkan, dan para pemangku kepentingan atau pemilik proyek yang benar-benar mensponsori proyek.
Proses pembangunan Scrum tidak datang ke dalam gambar bahkan selama tahap ini. Dokumentasi yang berkaitan dengan proyek yang dibuat dan "segala sesuatu" mengenai produk yang akan dikembangkan tersebut selesai - dalam warna hitam dan putih. Scrum tidak mendukung dokumentasi yang ekstensif. Anda tidak harus menyiapkan diagram alir sistem rinci dan struktur desain yang luas untuk memulai dengan pembangunan Scrum. Ide dasar akan cukup, dan Anda hanya harus menghabiskan banyak waktu dan upaya yang bisa Anda "mulai" dengan aktivitas pembangunan yang sebenarnya. Hanya cukup informasi dan spesifikasi untuk mengembangkan beberapa fitur produk yang paling penting.
Rilis proyek dihadiri oleh "Produk Owner" - orang yang berfungsi sebagai manajer proyek dalam proyek Scrum, yang Scrum Guru yang luar negeri yang Scrum diterapkan dengan benar dan diikuti oleh tim sementara proyek sedang dikembangkan, dan para pemangku kepentingan atau pemilik proyek yang benar-benar mensponsori proyek.
3. Menciptakan product backlog (Fitur Produk Daftar) - Mendefinisikan fitur produk dan fungsi
Proses pembangunan Scrum dimulai dengan penciptaan daftar master yang berisi semua fitur dan fungsi yang dibutuhkan untuk membuat produk dalam totalitas. Secara sederhana, seluruh produk, saat ini ada di atas kertas sebagai "dibayangkan" oleh para pemangku kepentingan dan pemilik proyek, adalah "dipecah" menjadi bagian-bagian penyusunnya, yang terdiri dari setiap fitur dan fungsionalitas. Produk ini serius, dan sistematis, dipecah sedemikian rupa sehingga masing-masing komponen individu dapat secara individual dikembangkan, diuji, dan akhirnya terintegrasi dengan komponen perangkat lunak lain atau fungsi yang dikembangkan oleh tim selama beberapa hari. Individual mengembangkan fitur dan fungsionalitas dapat akhirnya "melahirkan" ke produk bekerja ketika terintegrasi atau dirakit di kemudian hari.
Setiap fitur atau item daftar individu dikenal sebagai "Product Backlog Item" atau "cerita pengguna" dalam bahasa yang sederhana. Oleh karena itu, backlog produk atau daftar induk secara fundamental terdiri dari item backlog produk atau cerita pengguna. Kisah pengguna merupakan fitur produk, dan secara individual dikembangkan oleh anggota tim selama proses pembangunan - sprint sehari-hari. Setiap cerita dapat didefinisikan teliti. Deskripsi, kriteria penerimaan (Poin yang perlu "dipenuhi" atau puas sebelum mana cerita dapat dianggap sebagai berhasil mengembangkan), pentingnya dalam proyek, dan cara di mana itu seharusnya diintegrasikan ke dalam produk akhir, dll disebutkan untuk setiap cerita pengguna.
Setelah daftar fitur dibuat, diatur tergantung pada pentingnya setiap cerita pengguna dalam product backlog. Cerita pengguna Penting disusun dalam "top" bagian dari daftar, cerita kurang penting di tengah, dan fitur paling penting dan fungsi di bagian bawah.
Setiap fitur atau item daftar individu dikenal sebagai "Product Backlog Item" atau "cerita pengguna" dalam bahasa yang sederhana. Oleh karena itu, backlog produk atau daftar induk secara fundamental terdiri dari item backlog produk atau cerita pengguna. Kisah pengguna merupakan fitur produk, dan secara individual dikembangkan oleh anggota tim selama proses pembangunan - sprint sehari-hari. Setiap cerita dapat didefinisikan teliti. Deskripsi, kriteria penerimaan (Poin yang perlu "dipenuhi" atau puas sebelum mana cerita dapat dianggap sebagai berhasil mengembangkan), pentingnya dalam proyek, dan cara di mana itu seharusnya diintegrasikan ke dalam produk akhir, dll disebutkan untuk setiap cerita pengguna.
Setelah daftar fitur dibuat, diatur tergantung pada pentingnya setiap cerita pengguna dalam product backlog. Cerita pengguna Penting disusun dalam "top" bagian dari daftar, cerita kurang penting di tengah, dan fitur paling penting dan fungsi di bagian bawah.
4. rapat perencanaan Sprint - Perencanaan bagaimana mengembangkan fitur produk
Fungsi backlog produk sebagai utama "tulang punggung" dari semua kegiatan pembangunan yang terkait di Scrum. Setelah itu "dikembangkan" oleh pemilik produk dan para pemangku kepentingan, kegiatan pembangunan yang sebenarnya dapat dimulai. Pertemuan khusus yang dikenal sebagai "Perencanaan Sprint" Pertemuan diadakan untuk memulai kegiatan pembangunan. Pertemuan ini dihadiri oleh seluruh tim pengembangan, selain pemilik produk "PO" dan master scrum "SM".
Pertemuan ini diadakan dalam dua bagian. Pada bagian pertama, pemilik produk memilih beberapa yang paling penting pengguna cerita atau fitur produk dari bagian atas jaminan produk, dan transfer mereka ke daftar sementara yang dikenal sebagai "Sprint Backlog" untuk tujuan pembangunan. Dalam pertemuan tersebut, pemilik produk mengambil kesempatan untuk menjelaskan setiap cerita pengguna dalam rincian untuk anggota tim - bagaimana cerita pengguna idealnya dikembangkan secara, dan kegiatan apa yang tim harus melaksanakan sehingga setiap cerita dapat ditandai sebagai berhasil diselesaikan.
Selama paruh kedua pertemuan, tim pengembangan analisis sprint backlog dan mendistribusikan setiap cerita kepada anggota tim masing-masing. Dalam prakteknya, para anggota tim dengan suara bulat memutuskan siapa yang harus mengambil yang cerita tergantung pada pengembangan keterampilan dan tingkat pengalaman. Sederhana dan mudah barang dapat dikembangkan diberikan cerita yang kurang berpengalaman atau "segar" sementara sulit, atau lebih kompleks diambil untuk pengembangan oleh programmer yang lebih berpengalaman dan senior atau pengembang.
Pertemuan ini diadakan dalam dua bagian. Pada bagian pertama, pemilik produk memilih beberapa yang paling penting pengguna cerita atau fitur produk dari bagian atas jaminan produk, dan transfer mereka ke daftar sementara yang dikenal sebagai "Sprint Backlog" untuk tujuan pembangunan. Dalam pertemuan tersebut, pemilik produk mengambil kesempatan untuk menjelaskan setiap cerita pengguna dalam rincian untuk anggota tim - bagaimana cerita pengguna idealnya dikembangkan secara, dan kegiatan apa yang tim harus melaksanakan sehingga setiap cerita dapat ditandai sebagai berhasil diselesaikan.
Selama paruh kedua pertemuan, tim pengembangan analisis sprint backlog dan mendistribusikan setiap cerita kepada anggota tim masing-masing. Dalam prakteknya, para anggota tim dengan suara bulat memutuskan siapa yang harus mengambil yang cerita tergantung pada pengembangan keterampilan dan tingkat pengalaman. Sederhana dan mudah barang dapat dikembangkan diberikan cerita yang kurang berpengalaman atau "segar" sementara sulit, atau lebih kompleks diambil untuk pengembangan oleh programmer yang lebih berpengalaman dan senior atau pengembang.
5. sprint harian - Mengembangkan fitur produk
Ini adalah wilayah utama aktivitas di Scrum. Seluruh produk yang dikembangkan dalam "bit" dan "potongan" melalui siklus lari sehari-hari. Siklus berlari hanyalah kumpulan bekerja atau "pembangunan" hari dimana anggota tim benar-benar duduk di depan PC dan mengembangkan fungsi atau fitur produk. Siklus sprint waktu kemas dan tidak harus memperpanjang batas waktu tersebut.
Setiap item yang termasuk dalam sprint backlog selama rapat perencanaan sprint harus dikembangkan sedangkan sprint saat ini sedang berlangsung. Sebuah pertemuan singkat dikenal sebagai "Pertemuan Scrum Harian" diadakan untuk maksimal 15 menit setiap hari sebelum anggota tim mulai dengan pekerjaan mereka. Tujuan dari pertemuan ini adalah untuk mendapatkan ide tentang berapa banyak pekerjaan yang telah diselesaikan oleh masing-masing anggota sehari sebelumnya, dan apa yang masing-masing anggota mengusulkan untuk melakukan "hari ini". Jika anggota tim menghadapi masalah atau masalah, dapat disebutkan selama pertemuan, dan master scrum akan memastikan bahwa masalah tersebut cepat diselesaikan.
Dalam Scrum, sprint harian biasanya dapat berlangsung dari 2 minggu hingga maksimal satu bulan. Durasi sprint diputuskan selama tahap kedua - rilis proyek - dan seharusnya tidak diperpanjang dalam keadaan apapun - bahkan jika salah satu cerita pengguna dalam sprint backlog belum dikembangkan, atau yang perkembangannya tidak lengkap.
6. Sprint Ulasan - Memeriksa dan memverifikasi produktivitas (Apakah pengembangan OK?)
Setiap item yang termasuk dalam sprint backlog selama rapat perencanaan sprint harus dikembangkan sedangkan sprint saat ini sedang berlangsung. Sebuah pertemuan singkat dikenal sebagai "Pertemuan Scrum Harian" diadakan untuk maksimal 15 menit setiap hari sebelum anggota tim mulai dengan pekerjaan mereka. Tujuan dari pertemuan ini adalah untuk mendapatkan ide tentang berapa banyak pekerjaan yang telah diselesaikan oleh masing-masing anggota sehari sebelumnya, dan apa yang masing-masing anggota mengusulkan untuk melakukan "hari ini". Jika anggota tim menghadapi masalah atau masalah, dapat disebutkan selama pertemuan, dan master scrum akan memastikan bahwa masalah tersebut cepat diselesaikan.
Dalam Scrum, sprint harian biasanya dapat berlangsung dari 2 minggu hingga maksimal satu bulan. Durasi sprint diputuskan selama tahap kedua - rilis proyek - dan seharusnya tidak diperpanjang dalam keadaan apapun - bahkan jika salah satu cerita pengguna dalam sprint backlog belum dikembangkan, atau yang perkembangannya tidak lengkap.
6. Sprint Ulasan - Memeriksa dan memverifikasi produktivitas (Apakah pengembangan OK?)
Scrum menekankan pada pengembangan "shippable" fungsionalitas pada akhir siklus lari setiap hari. Setiap cerita pengguna dikembangkan selama sprint harian diperiksa oleh pemilik produk dan diverifikasi untuk kehandalan, tingkat penerimaan, dan apakah itu "bug gratis". Dalam Scrum, sangat penting untuk memberikan fitur bebas dari kesalahan - setiap cerita pengguna harus benar diuji untuk regresi apapun, dan apakah memenuhi kriteria penerimaan dikaitkan dengan perkembangannya.
Hanya setelah siklus lari harian berakhir, pertemuan segera diselenggarakan untuk mempelajari pengembangan yang dilakukan oleh tim. Hal ini penting untuk membedakan antara sprint harian dan siklus lari. Sprint harian adalah kegiatan pembangunan yang dilakukan oleh seluruh tim pada satu hari kerja tertentu. Banyak "sprint harian" seperti bergabung untuk membentuk "Harian Sprint Cycle", juga dikenal sebagai "produk tambahan siklus" di Agile. Pertemuan diadakan pada akhir siklus tambahan produk - siklus berlari setiap hari. Hal ini terutama dihadiri oleh pemilik produk, master scrum, dan anggota tim. Hal ini tidak wajib bagi para pemangku kepentingan untuk menghadiri pertemuan ini. Mereka dapat memilih untuk menghadiri jika mereka menginginkannya.
Tujuan utama dari acara ini, atau lebih tepatnya pertemuan itu, adalah untuk memeriksa apakah fitur telah dikembangkan oleh tim sesuai rencana produksi, dan jika fungsi tersebut mempunyai "manufaktur" cacat. Setiap fitur harus sepenuhnya diuji untuk setiap kelemahan tim sebelum menyajikannya dalam pertemuan ini. Pemilik produk memverifikasi jika fitur tersebut bebas dari kesalahan dan memeriksa jika memenuhi kriteria penerimaan terkait dengan itu. Ini adalah semacam "akhir" cek dilakukan sebelum menyajikan pembangunan kepada para pemangku kepentingan dan pemilik proyek dalam pertemuan kilas balik sprint berikutnya. Dalam pertemuan tersebut, pemilik produk menginstruksikan tim bagaimana bisa meningkatkan kerjanya dan menawarkan produktivitas lebih baik dengan menggunakan praktek pemrograman lebih efisien dan standar.
7. Sprint retrospektif - Menyelesaikan fungsionalitas produk dan merenungkan tentang perbaikan lebih lanjut
Hanya setelah siklus lari harian berakhir, pertemuan segera diselenggarakan untuk mempelajari pengembangan yang dilakukan oleh tim. Hal ini penting untuk membedakan antara sprint harian dan siklus lari. Sprint harian adalah kegiatan pembangunan yang dilakukan oleh seluruh tim pada satu hari kerja tertentu. Banyak "sprint harian" seperti bergabung untuk membentuk "Harian Sprint Cycle", juga dikenal sebagai "produk tambahan siklus" di Agile. Pertemuan diadakan pada akhir siklus tambahan produk - siklus berlari setiap hari. Hal ini terutama dihadiri oleh pemilik produk, master scrum, dan anggota tim. Hal ini tidak wajib bagi para pemangku kepentingan untuk menghadiri pertemuan ini. Mereka dapat memilih untuk menghadiri jika mereka menginginkannya.
Tujuan utama dari acara ini, atau lebih tepatnya pertemuan itu, adalah untuk memeriksa apakah fitur telah dikembangkan oleh tim sesuai rencana produksi, dan jika fungsi tersebut mempunyai "manufaktur" cacat. Setiap fitur harus sepenuhnya diuji untuk setiap kelemahan tim sebelum menyajikannya dalam pertemuan ini. Pemilik produk memverifikasi jika fitur tersebut bebas dari kesalahan dan memeriksa jika memenuhi kriteria penerimaan terkait dengan itu. Ini adalah semacam "akhir" cek dilakukan sebelum menyajikan pembangunan kepada para pemangku kepentingan dan pemilik proyek dalam pertemuan kilas balik sprint berikutnya. Dalam pertemuan tersebut, pemilik produk menginstruksikan tim bagaimana bisa meningkatkan kerjanya dan menawarkan produktivitas lebih baik dengan menggunakan praktek pemrograman lebih efisien dan standar.
7. Sprint retrospektif - Menyelesaikan fungsionalitas produk dan merenungkan tentang perbaikan lebih lanjut
Agile Scrum pendukung partisipasi klien. Klien adalah entitas yang sangat penting dalam Scrum, dan memiliki kata akhir sejauh pengembangan fitur produk yang bersangkutan. Manifesto Agile terutama menekankan pada partisipasi dan pengiriman terikat waktu kenaikan produk klien karena dua aspek ini sangat penting untuk mengembangkan proyek-proyek yang sukses. A "puas" klien sering "datang kembali" untuk mengembangkan lebih banyak proyek karena proyek yang berhasil membantu klien untuk mendapatkan margin keuntungan yang lebih tinggi.
Retrospektif ini memberikan kesempatan bagi seluruh tim untuk menunjukkan produktivitasnya di depan para pemangku kepentingan dan klien. Selain pemilik produk, scrum master, tim pengembangan, pertemuan juga dihadiri oleh pengguna akhir, personel staf teknis, vendor, distributor, dan karyawan bahkan lainnya karena tujuan utama dari pertemuan ini adalah untuk memanfaatkan umpan balik dari individu dan entitas terkait erat dengan pasar, dan yang memiliki pengetahuan tentang apa produk fitur cenderung untuk "mencetak" di pasar setelah produk diluncurkan, dan apa yang dapat membantu produk dalam "menjual".
Retrospektif ini juga menawarkan kesempatan bagi seluruh tim serta klien untuk merenungkan proses pembangunan, dan menemukan apa lagi yang bisa dilakukan untuk membuat produk yang lebih baik. Diskusi dilakukan untuk memastikan tingkat di mana cerita pengguna saat ini sedang dikembangkan oleh tim, dan apa proses baru atau metode perlu diperkenalkan untuk mempercepat proses.
Retrospektif ini memberikan kesempatan bagi seluruh tim untuk menunjukkan produktivitasnya di depan para pemangku kepentingan dan klien. Selain pemilik produk, scrum master, tim pengembangan, pertemuan juga dihadiri oleh pengguna akhir, personel staf teknis, vendor, distributor, dan karyawan bahkan lainnya karena tujuan utama dari pertemuan ini adalah untuk memanfaatkan umpan balik dari individu dan entitas terkait erat dengan pasar, dan yang memiliki pengetahuan tentang apa produk fitur cenderung untuk "mencetak" di pasar setelah produk diluncurkan, dan apa yang dapat membantu produk dalam "menjual".
Retrospektif ini juga menawarkan kesempatan bagi seluruh tim serta klien untuk merenungkan proses pembangunan, dan menemukan apa lagi yang bisa dilakukan untuk membuat produk yang lebih baik. Diskusi dilakukan untuk memastikan tingkat di mana cerita pengguna saat ini sedang dikembangkan oleh tim, dan apa proses baru atau metode perlu diperkenalkan untuk mempercepat proses.
Berlangganan versi gratis permanen Quickscrum alat manajemen proyek untuk mendapatkan ide tentang bagaimana alat bekerja dan apa yang ditawarkan. Bagi individu baru untuk proses scrum mungkin akan sulit untuk memahami bagaimana Agile kerangka diimplementasikan dalam proyek hidup. Jika Anda ingin tahu lebih banyak tentang scrum dan implementasinya, dan keinginan untuk mengembangkan proyek-proyek perangkat lunak yang dinamis dan hemat biaya, silahkan kirim email pada kami di support@quickscrum.com - kami dapat mengirimkan Scrum dokumentasi pelatihan untuk membantu Anda tahu lebih banyak tentang scrum .
No comments:
Post a Comment