Søknadskort
Hvordan kortlegge et tilpasset program uten å skrive en teknisk spesifikasjon.
Forbered et nyttig program kort med brukere, arbeidsflyter, prøveposter, avhengigheter og aksept eksempler, uten å skrive en teknisk spesifikasjon.
En utviklingskort trenger ikke å begynne med et databasediagram. Det må forklare en jobb som noen bør være i stand til å fullføre og resultatet virksomheten din trenger fra det.
Målet med den første kortheten er å gjøre prosjektet diskuterbart. Du kan la tekniske valg åpne mens du er nøyaktig om arbeidet søknaden må støtte.
Begynn med en bruker og en oppgave
\"Bygg en portal\" navn en type programvare. \"La en godkjent kunde sende en tjenesteforespørsel og se dens fremgang\" beskriver en nyttig første arbeidsflyt.
Navngjev brukeren, handlingen og utfallet. Deretter identifisere hvem som håndterer den andre siden av prosessen. I dette eksemplet må et medarbeidermedlem gjennomgå forespørselen og oppdatere sin status. Det betyr at den korte allerede inneholder to forskjellige roller og en delt post.
Unngå å starte med \"en app for alle\". Ulike brukere kan trenge ulike tillatelser, skjermer og informasjon. Bestem hvilken rolle som spiller mest rolle i den første utgivelsen.
Forklar hva som skjer i dag
Beskriv gjeldende trinn i vanlig språk. Kanskje en kunde e-postinformasjon, kopierer et medarbeidermedlem det til et regneark, og en annen person sender en fremgangsoppdatering. State der forvirring eller gjentatt innsats oppstår, uten å anta at programvaren vil løse alle omkringliggende problem.
Et omdelt eksempel på gjeldende skjema eller post kan være mer nyttig enn en polert presentasjon. Fjern personlig informasjon og konfidensielle detaljer før de deler den.
Beskriv en komplett reise
Følg en representativ rekord fra begynnelse til slutt. Hva starter det? Hvilken informasjon er nødvendig? Hvem tar den neste avgjørelsen? Hva markerer det som komplett?
Inkluder ett eller to viktige unntak. En forespørsel kan være ufullstendig, kan en anmelder avvise det eller en bruker måtte korrigere en feil. Disse tilfellene bidrar til å skille et arbeidsprogram fra en demonstrasjon av den ideelle banen.
Du trenger ikke å oppfinne alle sjeldne hendelser på dette stadiet. Konsentrer deg om unntakene som ville hindre den viktigste arbeidsflyten i å være nyttig.
Navn på data og avhengigheter
Liste de viktige postene: brukere, forespørsler, produkter, bookinger, filer eller et annet sett med informasjon. Forklar hvor de kommer fra og hvem som er ansvarlig for å vedlikeholde dem.
For en integrasjon, navngi den andre tjenesten og gi dens dokumentasjon når det er tilgjengelig. \"Koble til vår CRM\" gjør store spørsmål åpne. Den nyttige detaljen er hvilken post bør bevege seg, i hvilken retning og deretter hendelse.
Identifiser om design, produktinnhold, kontotilgang eller forretningsregler allerede er tilgjengelige. Manglende materialer er ikke automatisk blokkerere, men de trenger en eier og en plass i planen.
Definere den første nyttige versjonen
Separat kjernen levering fra senere ideer. En første portal kan støtte å opprette en forespørsel, gjennomgå den og vise status. Meldinger, avansert rapportering og en mobil app kan være senere diskusjoner i stedet for upoken krav til den første bygningen.
Dette er ikke en instruksjon for å bygge noe ufullstendig. Den valgte arbeidsflyten bør fungere fra start til slutt. Grensen er mellom komplette arbeidsflyter, ikke mellom en attraktiv skjerm og logikken den fortsatt trenger.
Skriv et aksepteksempel
Prøv en setning som noen kan teste:
En godkjent kunde kan sende inn en forespørsel, se sin status etter å ha logget inn og kun se sine egne forespørsler. En autorisert medarbeider kan oppdatere statusen, og kunden ser den endringen.
Dette er et illustrativt krav, ikke en beskrivelse av et eksisterende klientprosjekt. Det gjør den forventede oppførselen mye klarere enn \"en moderne, sikker portal\". Det endelige omfanget kan forfine tillatelsene og kantsaker.
Legg til praktiske begrensninger
Oppgi din ønskede timing, enten det er en preferanse eller en fast ekstern dato, og budsjettet hvor kjent. Navn den som kan godkjenne beslutninger og forklare hvordan design eller tilbakemelding vil bli levert.
Beskriv også utgivelses- og overleveringsforventninger. Hvem vil eie hosting og kontoer? Trenger en annen utvikler å motta koden? Disse spørsmålene påvirker leveringen selv når de ikke vises på en skjerm.
En kort stund du kan bruke
Vi vil bygge: søknaden eller arbeidsflyten. Hovedbrukere er: Folk og roller. De må: Hovedoppgaven og fullført resultat. I dag skjer dette gjennom: Den nåværende prosessen. Den første versjonen skal omfatte: Den essensielle komplette arbeidsflyten. Det må kobles til: kjente systemer og dokumentasjon. Vi har allerede: design, innhold, kontoer eller eksempeldata. Fortsatt ubestemt: Spørsmål å løse. Tid, budsjett og beslutningstaker: de praktiske begrensningene.
Bruk noen klare setninger for hver del. Kortet er et utgangspunkt for å definere prosjektet, ikke en test du trenger å passere før du snakker med en utvikler.