Mitä eroa on viitekehyksen ja menetelmän välillä?

Metodologia on joukko periaatteita, työkaluja ja käytäntöjä, joita voidaan käyttää ohjaamaan prosesseja tietyn tavoitteen saavuttamiseksi.

Kehys on löysä mutta epätäydellinen rakenne, joka jättää tilaa muille käytäntöille ja työkaluille, mutta tarjoaa suuren osan tarvittavasta prosessista.

Jos tarkastelemme esimerkiksi ohjelmistovastaavia, joissa sovellukset ovat analogisia menetelmien kanssa: Rails ja Spring on kaksi koodipohjaista kehystä, jotka toimivat mukautetun koodin kanssa sovelluksen tuottamiseksi. GMail on sovellus.

Samalla tavalla Scrumia voidaan pitää kehyksenä, koska se jättää tiimille tilaa valita omat tekniset prosessinsa, kehitystehtävänsä jne. XP voidaan pitää metodologiana, koska se tarjoaa ohjeet kaikille samoille asioille kuin Scrum, sekä asiaankuuluvat tekniset käytännöt. En ole tarpeeksi perehtynyt Prince2: een kommentoimaan, mutta saat kuvan.

Kommentit

• Scrum on a kehys. scrumguides.org/scrum-guide.html
• Scrum ei ole menetelmä tai metodologia, se on kehys, se tarkoittaa sinun on räätälöitävä se vastaamaan omia projektisi tarpeita
• @DavidLeal Scrum, sellaisena kuin se alun perin suunniteltiin, on kehys. Scrum sellaisena kuin se ’ opetti puitteet riippuen siitä, kuka opettaa niitä. On paljon ihmisiä, jotka suorittavat Scrum-kursseja ja tenttejä ja jotka eivät ole ’ antaneet minkäänlaista ohjausta sen räätälöimiseksi, tai parantaa sitä tai jopa kertoa, tarvitaanko räätälöintiä. Kun uudet pk-yritykset puhuvat siitä, miten ” Scrum on pyhä ” ja seuraamalla mallikysymyksiä ilman mukautuksia, sitä ’ ei enää käsitellä kehyksenä.

PMBoK 4. painos, sanasto, sivu 437:

Menetelmä : Järjestelmä käytäntöjä, tekniikoita, menettelyjä ja sääntöjä, joita tieteenalalla työskentelevät käyttävät.

Termiä ”kehys” käytetään yli 20 kertaa PMBoK, mutta ei ole sanastossa. Minusta se on hieman outoa …

Koska meillä ei ole PMBoK-viranomaisviitettä, pidän parempana määritelmää osoitteesta WhatIs.com :

Yleisesti ottaen kehys on todellinen tai käsitteellinen rakenne, joka on tarkoitettu tukena tai oppaana sellaisen rakentamisessa, joka laajentaa rakennetta joksikin hyödyllinen.

Pidän osasta, joka käsittelee ”laajentaa rakennetta hyödylliseksi”.

Kehys on rakenne, looginen tapa luokitella, segmentoida, luokitella tai ylläpitää jotain. Mielestäni se on substantiivi.

Menetelmä on toiminto, tapa tehdä jotain. Se kuvailisi prosessia tai joukkoa menettelyjä, toimintoja ja tuotossarjaa matkan varrella. Tämä on enemmän verbiä.

Kehys saattaa olla jotain jota tavoittelet. Menetelmä vie sinut sinne.

Kommentit

• En ’ t tiedä miksi sait äänestyksen, mielestäni vastauksesi on melko järkevä ja helppo ymmärtää. Ja sisällytä @Undercover Brotherin ’ vastaukseen.

Olen samaa mieltä Lunivoren ja SBWorksin kanssa – heidän panoksensa ovat sekä akateemisesta että ammattimaisesta teollisuuspohjaisesta näkökulmasta – maustettu terveellä järjellä ja ymmärryksellä englannin kielestä

(mikä on melko LOW in Iso-Britannia, Australia, Kanada, Uusi-Seelanti ja Yhdysvallat – näen jatkuvasti maahanmuuttajia, jotka nauravat hyvin paikallisten kielikatastrofien varalta.

Menen sanakirjojen määritelmien kanssa ja soveltaisin näitä määritelmiä Tilanne.

Ongelmana on, että jos yrität tarkastella ”teollisuutta”, sinulla on lähinnä joukko itsestään leviäviä roskia – siinä, että jokainen yritys julkaisee oman versionsa elämästä.

Esim. IBM kutsuu sitä yhtenäistettyyn prosessiin perustuvaksi kehykseksi ”prosessiksi” – Rational Unified Processiksi – joka on itse asiassa kehys sitä tarkasteltaessa. Alan suurelta toimijalta tämä on parhaimmillaan väärää tietoa ja huonoa terminologiaa.

Yritysterminologia: kehykset ja metodologiat, useimpia yrityksiä ja valtion virastoja hoitavat debyytit, joilla on omat määritelmänsä näistä termeistä – luultavasti IBM: n innoittamana.

(anteeksi Ranska!)

Olen nähnyt ainakin yhden ylimmän tason virkamiehen (CIO / CEO / CFO / CTO) katsovan prosessin vuokaaviota ja kutsuvan sitä ”kehykseksi”.

BoK: t ovat tietokokonaisuuksia, jotka kuvaavat elementtejä ja osaamisalueita, joita voidaan käyttää kehyksinä, ja lähestymistapoja rakenteeseen perustuvien mallien / menetelmien rakentamiseksi.

Kehyksen akateemiset määritelmät viittaavat siihen, että ellet niputa standardeja, menettelyt ja prosessit yhdessä yritystasolla, sinulla ei ole kehystä.

Ennen kuin tislaat kehyksen työkaluiksi, menetelmiä ohjaaviksi menetelmiksi ja standardeiksi, jotka toimivat yhdyskäytävinä menettelyssä näiden menetelmien sisällä, ei ole metodologiaa.

Hyvin laajasti viitekehys on ”mihin” yritys pyrkii, tai ”mihin” asiasta – laajimmassa merkityksessä, ja metodologia on ”miten”, joka sisältää menetelmiä, työkaluja jne.

Olen varma, että jokainen osakkeidensa arvoinen yritys olisi siellä molentamassa tätä määritelmää, kunnes se ei ole järkevämpi kuin Yhdysvaltain dollari varantovaluuttana.

Koska olen analyytikko Software Firmissa, yritän selittää se yksinkertaisella reaaliaikaisella esimerkillä, toivottavasti se voi auttaa. Oletetaan, että työskentelet organisaatiossa, josta saat asianmukaiset ilmoitukset ennen kuin asiat pannaan täytäntöön, sähköpostit ja tuki ylemmältä johdolta. Nämä ovat viitemääritteitä viitekehykseksi sanomalla, että organisaatiolla on kypsät prosessit.

Pikemminkin kun menet muodollisella tavalla ja huomaat, että organisaatiosi täyttää tilintarkastajan myöntämän prosessin ylläpitosertifikaatin, on itse asiassa prosessi, joka sanoo, että organisaatiot todella seuraavat prosesseja.

Täten prosessi voi olla muodollisempi määritelmä ja kehys reaaliaikaisena attribuuttina.

Kiitos!

Kommentit

• Hei Rahul Bansal. Kysymys on kehyksen ja metodologian erosta. Unohdit mainita metodologisen osan. Harkitse kysymyksen muokkaamista tai kirjoita tämä kommenteiksi.

tässä on joitain ehdotuksia tottumiseen viitekehys ja metodologia: (Olen ajatellut samaa samaa myös näinä päivinä)

1. havainnoimalla määrittele tila, johon henkilö, yritys, maa tykkää, sen ei tarvitse järkeä yleensä se, mitä näemme, ei ole ”totuus”, vain jonkun ilmentymä omasta elämänversiostaan (kuten peiteväkivalta sanoi)

2. päättää, pidätkö siitä, jos voi hyväksyä sen

3. jos et voi vain lähteä, elämä on liian lyhyt taistelemiseen
4. jos pystyt kuin alkaa ajatella, miten tuo ilmiö tapahtuu, on todennäköistä, että löytää paljon jo kehitettyjä tapoja ja järkevää, ja vain mennä sen mukana

ihanteellinen ei ehkä ole niin kuin luulet, mutta niin kauan kuin voit hyväksyä, kuin olet hyvässä kunnossa paikka.

Scrum: F Ramework tai metodologia?

Määritelmän mukaan Scrum on ketterä kehys. Jotkut pitävät sitä metodologiana. Kuka on oikeassa? Se riippuu todella siitä, miten katsot sitä.

Yritetään ensin selvittää puitteiden ja menetelmien ero. Tässä yhteydessä kehys on väljä ohje, joka määrittelee ohjelmistokehityksen päärakenteen. Se ei kuitenkaan sanele, miten tietyt asiat tehdään. Kehys ei ole vaiheittainen resepti, koska se ei kerro meille, mihin työkaluihin ja prosesseihin voi luottaa.

Kehyksen avulla voimme määritellä tavan, jolla haluamme saavuttaa tavoitteemme. . Nyt meillä on sekä rakenne että joukko standardeja, työkaluja ja käytäntöjä. Tämä on metodologia.

Sinulla on menetelmä, jos täytät kehyksen määrittelemän rakenteen aukot.

Palataan nyt alkuperäiseen kysymykseemme. Onko Scrum kehys vai metodologia? Scrum määrittelee rakenteen varmasti: se kertoo meille, että tarvitsemme Sprints-kehitysohjelmia, Sprint Planning, Daily Scrum, Sprint Review ja Retrospective-kokoukset. Siten Scrum sopii kehyksen määritelmään.

Kerro Scrum meille mitä työkaluja käytämme, kuten Excel suunnittelua varten, Trello edistymisen seurantaa varten tai Microsoft Visio ohjelmistomme suunnittelua varten? Ei!

Joten, Scrum on kehys, ei metodologia, eikö? No, ei niin nopea! Monet ihmiset kokevat Scrumin metodologiana, koska työkalut ja standardit on jo annettu. Aikuisten ohjelmistokehitysyritysten ei tarvitse ottaa käyttöön uusia ohjelmistoja ja prosesseja, vaan vain mukauttaa olemassa olevat Scrumin tarjoamaan rakenteeseen.

Olen nähnyt useita siirtymiä vesiputouksesta ketterään, mikä ei edellyttänyt merkittäviä muutoksia työkaluissa, vaan pikemminkin ihmisten mielissä.