Re: [JUG-Indonesia] Agile dan migrasi system
napa harus shippable? hahaha lha dipake sendiri napa mesti shippable? 2010/6/21 Hendry Luk > > > Ini lagi gak nyambung :P. > I dont think ada yg disagree disini kalo increment gak mesti beta. Tapi > increment juga gak mesti shippable. Justru makanya dinamain "potentially > shippable product increment" (di scrum). > > Ada perbedaan tegas antara "potentially shippable" dan "shippable", dan > satu2nya orang yg bisa define the difference adalah product owner. > Op kan dah bilang, product-ownernya cuma mau lu deploy kalo dah fully > migrated, ya itu artinya lu mesti complete migration dulu baru "shippable", > its that simple.. Gak ada hubungan dengan mesti pake waterfall, ato agile, > ato mindset jadul... > > Mang napa kalo namanya release? Mangnya beta bukan release? Selama masih > "potentially" shippable, ya masih alpha/beta/whatever. > > Furthermore, potential-shippable-product sendiri bahkan *bukan *satu2nya > pendekatan increments di agile. Coba cari tau ttg SWTAG, ini dipake di > Electronic Arts.. "potentially-shippable" increment (yg mereka sebut "alpha" > release, aka "A") adalah justru salah satu phase *terakhir *mereka. Di > awal2, tiap increment mereka cuma S (sufficient for feedback). > > Lantas ngapain ada iteration kalo gak dideploy ke prod? > Pertanyaan ini nunjukin (IMHO shortsighted) premise bahwa tiap increment > mesti == production deployment. Tujuan terpenting dari iteration kan justru > buat nuntun customers make up their minds on what they want, sekalian > evaluate whether what we're building will work. > Kalo ternyata product-ownernya doyan ROI & pengen buru2 deploy ke prod, ya > itu happy coincident. Even biarpun gak, at least lu reduce the risk karna > product lu selalu dalam kondisi potentially-shippable at any point. > > QA gak ada sangkut paut... Lu tetep regularly drop ke test envs, no > question about it... cuma ya gak mesti lu deploy ke prod sekalian, tangan lu > gatel ya? > :P > > 2010/6/21 sm96 > >> >> >> yang kayak gini ini mindset jadul. >> incremental deployment bukan berarti beta. biarpun incremental tetap harus >> lolos QA, dan namanya >> tetep release, jadilah incremental release. >> >> 2010/6/16 Hendry Luk >> >>> >>> >>> I think lu might've misunderstood... Tujuan incremental releases tuh buat >>> gather customer's feedback.. bukan buat dideploy dan dipake di production. >>> Incremental delivery != production deployment. >>> Masak barang beta dicemplungin ke production box. >>> >>> Tentang phasing out legacy system... sering dipecah jadi multiple phases >>> (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak >>> berkaitan dengan development methodology apa yg lu subscribe. >>> >>> 2010/6/14 >>> Dear all, Seperti kita yang ketahui, trend project sekarang lebih agile, deploy per cycle lebih cepat. Yang jadi pertanyaan adalah migrasi system, user tidak ingin perpindahan sepotong2, menambah effort karena harus hidup di dua habitat system. User ingin pindah langsung secara total. Apakah pendekatan agile tidak dapat dilakukan, apakah khusus untuk migrasi system harus waterfall? Apa solusi untuk hal ini? Thx, Edwin Powered by Telkomsel BlackBerry® Buktikan Anda peduli pendidikan Indonesia. Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan ke moderator JUG. === Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke jug-indonesia-unsubscr...@yahoogroups.com. Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id Yahoo! Groups Links >>> >> >> >> -- >> syaiful.mukhlis >> gtalk:syaiful.mukh...@gmail.com >> > > > -- syaiful.mukhlis gtalk:syaiful.mukh...@gmail.com
Re: [JUG-Indonesia] Agile dan migrasi system
sorry baru nongol lagi. untuk memperjelas soal Agile Method, mungkin bisa dilihat di Agile Manifesto: http://agilemanifesto.org/principles.html -- salam hangat, Thomas Wiradikusuma Twitter: http://www.twitter.com/wiradikusuma Blog: http://www.jroller.com/wiradikusuma
Re: [JUG-Indonesia] Agile dan migrasi system
Ini lagi gak nyambung :P. I dont think ada yg disagree disini kalo increment gak mesti beta. Tapi increment juga gak mesti shippable. Justru makanya dinamain "potentially shippable product increment" (di scrum). Ada perbedaan tegas antara "potentially shippable" dan "shippable", dan satu2nya orang yg bisa define the difference adalah product owner. Op kan dah bilang, product-ownernya cuma mau lu deploy kalo dah fully migrated, ya itu artinya lu mesti complete migration dulu baru "shippable", its that simple.. Gak ada hubungan dengan mesti pake waterfall, ato agile, ato mindset jadul... Mang napa kalo namanya release? Mangnya beta bukan release? Selama masih "potentially" shippable, ya masih alpha/beta/whatever. Furthermore, potential-shippable-product sendiri bahkan *bukan *satu2nya pendekatan increments di agile. Coba cari tau ttg SWTAG, ini dipake di Electronic Arts.. "potentially-shippable" increment (yg mereka sebut "alpha" release, aka "A") adalah justru salah satu phase *terakhir *mereka. Di awal2, tiap increment mereka cuma S (sufficient for feedback). Lantas ngapain ada iteration kalo gak dideploy ke prod? Pertanyaan ini nunjukin (IMHO shortsighted) premise bahwa tiap increment mesti == production deployment. Tujuan terpenting dari iteration kan justru buat nuntun customers make up their minds on what they want, sekalian evaluate whether what we're building will work. Kalo ternyata product-ownernya doyan ROI & pengen buru2 deploy ke prod, ya itu happy coincident. Even biarpun gak, at least lu reduce the risk karna product lu selalu dalam kondisi potentially-shippable at any point. QA gak ada sangkut paut... Lu tetep regularly drop ke test envs, no question about it... cuma ya gak mesti lu deploy ke prod sekalian, tangan lu gatel ya? :P 2010/6/21 sm96 > > > yang kayak gini ini mindset jadul. > incremental deployment bukan berarti beta. biarpun incremental tetap harus > lolos QA, dan namanya > tetep release, jadilah incremental release. > > 2010/6/16 Hendry Luk > >> >> >> I think lu might've misunderstood... Tujuan incremental releases tuh buat >> gather customer's feedback.. bukan buat dideploy dan dipake di production. >> Incremental delivery != production deployment. >> Masak barang beta dicemplungin ke production box. >> >> Tentang phasing out legacy system... sering dipecah jadi multiple phases >> (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak >> berkaitan dengan development methodology apa yg lu subscribe. >> >> 2010/6/14 >> >>> Dear all, >>> >>> >>> Seperti kita yang ketahui, trend project sekarang lebih agile, deploy per >>> cycle lebih cepat. >>> Yang jadi pertanyaan adalah migrasi system, user tidak ingin perpindahan >>> sepotong2, menambah effort karena harus hidup di dua habitat system. User >>> ingin pindah langsung secara total. >>> Apakah pendekatan agile tidak dapat dilakukan, apakah khusus untuk >>> migrasi system harus waterfall? >>> Apa solusi untuk hal ini? >>> >>> Thx, >>> Edwin >>> >>> Powered by Telkomsel BlackBerry® >>> >>> >>> >>> >>> Buktikan Anda peduli pendidikan Indonesia. >>> Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan >>> ke moderator JUG. >>> === >>> >>> Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke >>> jug-indonesia-unsubscr...@yahoogroups.com. >>> >>> Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >> > > > -- > syaiful.mukhlis > gtalk:syaiful.mukh...@gmail.com > >
Re: [JUG-Indonesia] Agile dan migrasi system
yang kayak gini ini mindset jadul. incremental deployment bukan berarti beta. biarpun incremental tetap harus lolos QA, dan namanya tetep release, jadilah incremental release. 2010/6/16 Hendry Luk > > > I think lu might've misunderstood... Tujuan incremental releases tuh buat > gather customer's feedback.. bukan buat dideploy dan dipake di production. > Incremental delivery != production deployment. > Masak barang beta dicemplungin ke production box. > > Tentang phasing out legacy system... sering dipecah jadi multiple phases > (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak > berkaitan dengan development methodology apa yg lu subscribe. > > 2010/6/14 > >> Dear all, >> >> >> Seperti kita yang ketahui, trend project sekarang lebih agile, deploy per >> cycle lebih cepat. >> Yang jadi pertanyaan adalah migrasi system, user tidak ingin perpindahan >> sepotong2, menambah effort karena harus hidup di dua habitat system. User >> ingin pindah langsung secara total. >> Apakah pendekatan agile tidak dapat dilakukan, apakah khusus untuk migrasi >> system harus waterfall? >> Apa solusi untuk hal ini? >> >> Thx, >> Edwin >> >> Powered by Telkomsel BlackBerry® >> >> >> >> >> Buktikan Anda peduli pendidikan Indonesia. >> Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan ke >> moderator JUG. >> === >> >> Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke >> jug-indonesia-unsubscr...@yahoogroups.com. >> >> Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id >> >> Yahoo! Groups Links >> >> >> >> > > -- syaiful.mukhlis gtalk:syaiful.mukh...@gmail.com
Re: [JUG-Indonesia] Agile dan migrasi system
Jadi kesimpulannya satu cycle itu sampai release version, tapi tidak wajib deploy ke production. Process deploy dapat saja digabungkan beberapa release item. Kurang lebih begitu ya? Thx, Edwin Powered by Telkomsel BlackBerry® -Original Message- From: Hendry Luk Sender: jug-indonesia@yahoogroups.com Date: Thu, 17 Jun 2010 09:53:48 To: Reply-To: jug-indonesia@yahoogroups.com Subject: Re: [JUG-Indonesia] Agile dan migrasi system Lu bisa ajah deploy ke prod kalo mau, tapi itu bukan maksud dari incremental delivery. Gw bukan agile expert.. tapi ini sih software-project common-sense ajah. Project kita dipecah2 jadi 2 weeks iteration.. kita release tiap 2 minggu ke staging server ato dicemplungin ke uat box... yang maksudnya buat dapet feedback dari customer supaya mereka bisa make up their minds tentang requirement buat 2 weeks berikutnya, dan mereka masih bisa ganti2 pikiran sebelom terlambat. . Soalnya sekali iteration berikutnya dah dikick-off, requirementnya dah di freeze.. lu dah gak bisa ganti apa2 sampe 2 weeks itu selesai. Dalem agile, makin cepet lu dapet feedback makin bagus. Sama sekali gak berarti kita ada production deployment tiap 2 minggu. In fact, kita gak release apa2 sampe 9 bulan. That being said, juga gak berarti lu gak bisa deploy ke production tiap 2 minggu (ato tiap 2 jam). What i was saying adalah incremental "production deployment" itu bukan defining factor dari agile methodology.. Kalo emang customernya gak mau deploy ke production sampe "minimum marketable feature" nya kelar, ya gak berarti lu mesti resort ke waterfall... karna emang sama sekali gak berhubungan. :) Di agile juga masih acknowledge keberadaan minimum-marketable-feature.. In this case, customer mau lu migrate semua features di legacy system sebelom lu bisa deploy ke prod... itu sama sekali gak imply lu mesti pake waterfall. Maupun agile, for that matter. Just to contrast, kalo customernya pengen lu market certain subset of core features ke production dulu, sebelom lanjutin lagi next chunk (phase)... ya itu yg dinamain incremental funding (IFM)... Tiap phase itu yang dinamain miminum-marketable-feature. IFM exists baik lu pake waterfall maupun agile. On Wed, Jun 16, 2010 at 6:29 PM, Thomas Wiradikusuma (milis) < wiradikusuma.mi...@gmail.com> wrote: > > > I think you misunderstood :) Incremental Release benar untuk customer > feedback, tapi *memang* di deploy di production. That's why it's > called "release". > > It is true that it comes with the risk of "barang beta dicemplungin ke > production box", but if you want real customer feedback, you have to > do it real. > Pernah denger Imvu.com? (sering ada iklannya di website pas jaman > pilem Avatar) Mereka incremental release ke production sehari bisa > 50x! > > Sometimes people use the word "agile" to indicate process that is not > really agile. Developing something for months (years?) without showing > anything "productionly usable" to users in between is not agile, even > tough they "collect customer feedback" and "do testing" during the > process. > (Waterfall method *does* collect customer feedback and perform testing). > > 2010/6/16 Hendry Luk > > > > I think lu might've misunderstood... Tujuan incremental releases tuh buat > gather customer's feedback.. bukan buat dideploy dan dipake di production. > > Incremental delivery != production deployment. > > Masak barang beta dicemplungin ke production box. > > > > Tentang phasing out legacy system... sering dipecah jadi multiple phases > (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak > berkaitan dengan development methodology apa yg lu subscribe. > > -- > salam hangat, > Thomas Wiradikusuma > Twitter: http://www.twitter.com/wiradikusuma > Blog: http://www.jroller.com/wiradikusuma > >
RE: [JUG-Indonesia] Agile dan migrasi system
G jelas bukan pakar agile... Heheheh Tapi ada yang g pengen Tanya... Gue /kayaknya/ pake agile neh di kantor... Soal nya ada iteration juga neh... Tapi kok iteration nya seminggu doang yah? Plus masi di tambah bureaucracy... Start iteration nya neh... And then by Wednesday product harus udah di cemplugin ke uat box... By thrusday ada feedback... and decision.. go or no go... Friday go live preparation... Saturday go live... Sunday off... system brought down... Senen sanity test of last production promotion... Selasa start iteration... By Wednesday (again) code udah harus di cemplugin ke uat box? Kapan kerja nya booosss Huhuhuhuhuhuh Adelwin Handoyo | Senior Consultant - Wholesale Bank Standard Chartered Bank 7, Changi Business Park Cresent, Level 3. Singapore (486028) T : (65) 659 61395 | E adelwin.adel...@sc.com From: jug-indonesia@yahoogroups.com [mailto:jug-indone...@yahoogroups.com] On Behalf Of Hendry Luk Sent: Thursday, June 17, 2010 7:54 AM To: jug-indonesia@yahoogroups.com Subject: Re: [JUG-Indonesia] Agile dan migrasi system Lu bisa ajah deploy ke prod kalo mau, tapi itu bukan maksud dari incremental delivery. Gw bukan agile expert.. tapi ini sih software-project common-sense ajah. Project kita dipecah2 jadi 2 weeks iteration.. kita release tiap 2 minggu ke staging server ato dicemplungin ke uat box... yang maksudnya buat dapet feedback dari customer supaya mereka bisa make up their minds tentang requirement buat 2 weeks berikutnya, dan mereka masih bisa ganti2 pikiran sebelom terlambat. . Soalnya sekali iteration berikutnya dah dikick-off, requirementnya dah di freeze.. lu dah gak bisa ganti apa2 sampe 2 weeks itu selesai. Dalem agile, makin cepet lu dapet feedback makin bagus. Sama sekali gak berarti kita ada production deployment tiap 2 minggu. In fact, kita gak release apa2 sampe 9 bulan. That being said, juga gak berarti lu gak bisa deploy ke production tiap 2 minggu (ato tiap 2 jam). What i was saying adalah incremental "production deployment" itu bukan defining factor dari agile methodology.. Kalo emang customernya gak mau deploy ke production sampe "minimum marketable feature" nya kelar, ya gak berarti lu mesti resort ke waterfall... karna emang sama sekali gak berhubungan. :) Di agile juga masih acknowledge keberadaan minimum-marketable-feature.. In this case, customer mau lu migrate semua features di legacy system sebelom lu bisa deploy ke prod... itu sama sekali gak imply lu mesti pake waterfall. Maupun agile, for that matter. Just to contrast, kalo customernya pengen lu market certain subset of core features ke production dulu, sebelom lanjutin lagi next chunk (phase)... ya itu yg dinamain incremental funding (IFM)... Tiap phase itu yang dinamain miminum-marketable-feature. IFM exists baik lu pake waterfall maupun agile. On Wed, Jun 16, 2010 at 6:29 PM, Thomas Wiradikusuma (milis) mailto:wiradikusuma.mi...@gmail.com> > wrote: I think you misunderstood :) Incremental Release benar untuk customer feedback, tapi *memang* di deploy di production. That's why it's called "release". It is true that it comes with the risk of "barang beta dicemplungin ke production box", but if you want real customer feedback, you have to do it real. Pernah denger Imvu.com? (sering ada iklannya di website pas jaman pilem Avatar) Mereka incremental release ke production sehari bisa 50x! Sometimes people use the word "agile" to indicate process that is not really agile. Developing something for months (years?) without showing anything "productionly usable" to users in between is not agile, even tough they "collect customer feedback" and "do testing" during the process. (Waterfall method *does* collect customer feedback and perform testing). 2010/6/16 Hendry Luk mailto:hendrymail%40gmail.com> > > I think lu might've misunderstood... Tujuan incremental releases tuh buat gather customer's feedback.. bukan buat dideploy dan dipake di production. > Incremental delivery != production deployment. > Masak barang beta dicemplungin ke production box. > > Tentang phasing out legacy system... sering dipecah jadi multiple phases (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak berkaitan dengan development methodology apa yg lu subscribe. -- salam hangat, Thomas Wiradikusuma Twitter: http://www.twitter.com/wiradikusuma <http://www.twitter.com/wiradikusuma> Blog: http://www.jroller.com/wiradikusuma <http://www.jroller.com/wiradikusuma> This email and any attachments are confidential and may also be privileged. If you are not the addressee, do not disclose, copy, circulate or in any other way use or rely on the information contained in this email or any attachments. If received in error, notify the sender immediately and delete this email and any att
Re: [JUG-Indonesia] Agile dan migrasi system
Lu bisa ajah deploy ke prod kalo mau, tapi itu bukan maksud dari incremental delivery. Gw bukan agile expert.. tapi ini sih software-project common-sense ajah. Project kita dipecah2 jadi 2 weeks iteration.. kita release tiap 2 minggu ke staging server ato dicemplungin ke uat box... yang maksudnya buat dapet feedback dari customer supaya mereka bisa make up their minds tentang requirement buat 2 weeks berikutnya, dan mereka masih bisa ganti2 pikiran sebelom terlambat. . Soalnya sekali iteration berikutnya dah dikick-off, requirementnya dah di freeze.. lu dah gak bisa ganti apa2 sampe 2 weeks itu selesai. Dalem agile, makin cepet lu dapet feedback makin bagus. Sama sekali gak berarti kita ada production deployment tiap 2 minggu. In fact, kita gak release apa2 sampe 9 bulan. That being said, juga gak berarti lu gak bisa deploy ke production tiap 2 minggu (ato tiap 2 jam). What i was saying adalah incremental "production deployment" itu bukan defining factor dari agile methodology.. Kalo emang customernya gak mau deploy ke production sampe "minimum marketable feature" nya kelar, ya gak berarti lu mesti resort ke waterfall... karna emang sama sekali gak berhubungan. :) Di agile juga masih acknowledge keberadaan minimum-marketable-feature.. In this case, customer mau lu migrate semua features di legacy system sebelom lu bisa deploy ke prod... itu sama sekali gak imply lu mesti pake waterfall. Maupun agile, for that matter. Just to contrast, kalo customernya pengen lu market certain subset of core features ke production dulu, sebelom lanjutin lagi next chunk (phase)... ya itu yg dinamain incremental funding (IFM)... Tiap phase itu yang dinamain miminum-marketable-feature. IFM exists baik lu pake waterfall maupun agile. On Wed, Jun 16, 2010 at 6:29 PM, Thomas Wiradikusuma (milis) < wiradikusuma.mi...@gmail.com> wrote: > > > I think you misunderstood :) Incremental Release benar untuk customer > feedback, tapi *memang* di deploy di production. That's why it's > called "release". > > It is true that it comes with the risk of "barang beta dicemplungin ke > production box", but if you want real customer feedback, you have to > do it real. > Pernah denger Imvu.com? (sering ada iklannya di website pas jaman > pilem Avatar) Mereka incremental release ke production sehari bisa > 50x! > > Sometimes people use the word "agile" to indicate process that is not > really agile. Developing something for months (years?) without showing > anything "productionly usable" to users in between is not agile, even > tough they "collect customer feedback" and "do testing" during the > process. > (Waterfall method *does* collect customer feedback and perform testing). > > 2010/6/16 Hendry Luk > > > > I think lu might've misunderstood... Tujuan incremental releases tuh buat > gather customer's feedback.. bukan buat dideploy dan dipake di production. > > Incremental delivery != production deployment. > > Masak barang beta dicemplungin ke production box. > > > > Tentang phasing out legacy system... sering dipecah jadi multiple phases > (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak > berkaitan dengan development methodology apa yg lu subscribe. > > -- > salam hangat, > Thomas Wiradikusuma > Twitter: http://www.twitter.com/wiradikusuma > Blog: http://www.jroller.com/wiradikusuma > >
Re: [JUG-Indonesia] Agile dan migrasi system
Bukankah satu cycle dalam agile, dari requirement gathering sampai dengan barang naik ke production? Thx, Edwin Powered by Telkomsel BlackBerry® -Original Message- From: Hendry Luk Sender: jug-indonesia@yahoogroups.com Date: Wed, 16 Jun 2010 13:58:09 To: Reply-To: jug-indonesia@yahoogroups.com Subject: Re: [JUG-Indonesia] Agile dan migrasi system I think lu might've misunderstood... Tujuan incremental releases tuh buat gather customer's feedback.. bukan buat dideploy dan dipake di production. Incremental delivery != production deployment. Masak barang beta dicemplungin ke production box. Tentang phasing out legacy system... sering dipecah jadi multiple phases (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak berkaitan dengan development methodology apa yg lu subscribe. 2010/6/14 > Dear all, > > Seperti kita yang ketahui, trend project sekarang lebih agile, deploy per > cycle lebih cepat. > Yang jadi pertanyaan adalah migrasi system, user tidak ingin perpindahan > sepotong2, menambah effort karena harus hidup di dua habitat system. User > ingin pindah langsung secara total. > Apakah pendekatan agile tidak dapat dilakukan, apakah khusus untuk migrasi > system harus waterfall? > Apa solusi untuk hal ini? > > Thx, > Edwin > > Powered by Telkomsel BlackBerry® > > > > > Buktikan Anda peduli pendidikan Indonesia. > Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan ke > moderator JUG. > === > > Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke > jug-indonesia-unsubscr...@yahoogroups.com. > > Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id > > Yahoo! Groups Links > > > >
Re: [JUG-Indonesia] Agile dan migrasi system
I think you misunderstood :) Incremental Release benar untuk customer feedback, tapi *memang* di deploy di production. That's why it's called "release". It is true that it comes with the risk of "barang beta dicemplungin ke production box", but if you want real customer feedback, you have to do it real. Pernah denger Imvu.com? (sering ada iklannya di website pas jaman pilem Avatar) Mereka incremental release ke production sehari bisa 50x! Sometimes people use the word "agile" to indicate process that is not really agile. Developing something for months (years?) without showing anything "productionly usable" to users in between is not agile, even tough they "collect customer feedback" and "do testing" during the process. (Waterfall method *does* collect customer feedback and perform testing). 2010/6/16 Hendry Luk > I think lu might've misunderstood... Tujuan incremental releases tuh buat > gather customer's feedback.. bukan buat dideploy dan dipake di production. > Incremental delivery != production deployment. > Masak barang beta dicemplungin ke production box. > > Tentang phasing out legacy system... sering dipecah jadi multiple phases > (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak > berkaitan dengan development methodology apa yg lu subscribe. -- salam hangat, Thomas Wiradikusuma Twitter: http://www.twitter.com/wiradikusuma Blog: http://www.jroller.com/wiradikusuma
Re: [JUG-Indonesia] Agile dan migrasi system
I think lu might've misunderstood... Tujuan incremental releases tuh buat gather customer's feedback.. bukan buat dideploy dan dipake di production. Incremental delivery != production deployment. Masak barang beta dicemplungin ke production box. Tentang phasing out legacy system... sering dipecah jadi multiple phases (e.g. per business sector) buat ngurangin risk, or not... Tapi ini gak berkaitan dengan development methodology apa yg lu subscribe. 2010/6/14 > Dear all, > > Seperti kita yang ketahui, trend project sekarang lebih agile, deploy per > cycle lebih cepat. > Yang jadi pertanyaan adalah migrasi system, user tidak ingin perpindahan > sepotong2, menambah effort karena harus hidup di dua habitat system. User > ingin pindah langsung secara total. > Apakah pendekatan agile tidak dapat dilakukan, apakah khusus untuk migrasi > system harus waterfall? > Apa solusi untuk hal ini? > > Thx, > Edwin > > Powered by Telkomsel BlackBerry® > > > > > Buktikan Anda peduli pendidikan Indonesia. > Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan ke > moderator JUG. > === > > Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke > jug-indonesia-unsubscr...@yahoogroups.com. > > Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id > > Yahoo! Groups Links > > > >
Re: [JUG-Indonesia] Agile dan migrasi system
2010/6/14 : > Dear all, > > Seperti kita yang ketahui, trend project sekarang lebih agile, deploy per > cycle lebih cepat. > Yang jadi pertanyaan adalah migrasi system, user tidak ingin perpindahan > sepotong2, menambah effort karena harus hidup di dua habitat system. User > ingin pindah langsung secara total. > Apakah pendekatan agile tidak dapat dilakukan, apakah khusus untuk migrasi > system harus waterfall? Waterfall itu konteksnya keseluruhan project, yaitu 1. Analisa 2. Design 3. Coding 4. Test 5. Migrasi 6. Live Sedangkan migrasi itu cuma 1 tahap aja, jadi gak bisa dibilang migrasi pakai waterfall. Mungkin maksudnya, migrasi mau keseluruhan modul, gak 1-1. Nah, kalo mau migrasi keseluruhan modul, harus yakin aplikasinya benar2 rock solid. Soalnya kalo ketemu bug showstopper di tengah jalan, migrasinya bubar dan harus diulang lagi. Kalo mau migrasi per modul bisa juga, tapi konsekuensinya harus keluar effort untuk bikin script konverter untuk inject data menggantikan modul yang belum ready. Saran saya sih, lakukan testing yang serius, lalu lakukan migrasi total. Kalo testingnya bener, harusnya migrasinya mulus. -- Endy Muhardin http://endy.artivisi.com Y! : endymuhardin -- life learn contribute --
[JUG-Indonesia] Agile dan migrasi system
Dear all, Seperti kita yang ketahui, trend project sekarang lebih agile, deploy per cycle lebih cepat. Yang jadi pertanyaan adalah migrasi system, user tidak ingin perpindahan sepotong2, menambah effort karena harus hidup di dua habitat system. User ingin pindah langsung secara total. Apakah pendekatan agile tidak dapat dilakukan, apakah khusus untuk migrasi system harus waterfall? Apa solusi untuk hal ini? Thx, Edwin Powered by Telkomsel BlackBerry® Buktikan Anda peduli pendidikan Indonesia. Dukung Kurikulum SMK berJava.. kirimkan surat resmi perusahaan dukungan ke moderator JUG. === Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke jug-indonesia-unsubscr...@yahoogroups.com. Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/jug-indonesia/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/jug-indonesia/join (Yahoo! ID required) <*> To change settings via email: jug-indonesia-dig...@yahoogroups.com jug-indonesia-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: jug-indonesia-unsubscr...@yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
