Login
en

Sprog

  • en
  • de
  • fr
  • es
  • br
  • ru
  • jp
  • kr

Maskinoversættelse

  • bg
  • cs
  • dk
  • gr
  • hu
  • il
  • it
  • pl
  • se
  • tr

Nem Redmine går Agile

Dato:8 / 21 / 2014
Længde:6 minutter
Del:

Lær at vide, hvordan bruger vi Easy Redmine Agile Board til udvikling af Easy Redmine :-). Hele processen er beskrevet her.

Grundlæggende egenskaber:

  • 2 uger lang sprint
  • sprint er færdig = ny version frigives = næste milepæl i vejkort

let-redmine-går-adræt-køreplan

  • sprint backlog er frosset efter initialisering (ingen flere opgaver er tilføjet), medmindre kritisk fejl kommer
  • bortset fra kritiske fejl → bugfix leveret i næste sprint = maks. 4 uger leveringstid

CTO mandag morgen

  • Giver tid estimater for alle de fejl, der rapporteres i den sidste uge

let-redmine-går-adræt-3

Ledelsesmøde 

  • Kontoforvaltere kommer med nye funktionsanmodninger
  • Diskussion over dem → løsning + tidsoverslag
  • Kontochefen informerer kunden tilbage

Sprint Initial Meeting (1st uge, oprettelse af backlog)

  • Sprint baglog er oprettet
  • fejl (A-klienter, B-klienter) status: estimeret
  • Små og effektive funktionsanmodninger status: kunde godkendt
  • Sprint-volumen kontrolleres i ugen Ressourcehåndtering - forfaldsdato indstilles automatisk, når problemerne placeres i Sprint

let-redmine-går-adræt

Sprint Revision Meeting (2nd uge, revision)

  • Sprint er gennemgået
  • nogle fejl er prioriteret
  • kritiske fejl kan tilføjes

Stand-up møde (hver dag på 10am) Kontoforvaltere → programmører

  • Konti møder programmører for opdateringer
  • Programmører returnerer færdige opgaver på filialer, der kan deles med kunden - dog levering i næste udgave - den gennemsnitlige tid er plads til test og godkendelse
  • kunden kan få bug-fixed version 
  • Konti og programmører driver „sprint-backlog → ny → konsultation → kodevurdering -> færdig" -proces

let-redmine-går-agile-indstillinger

Fejl i praksis

  • Fejl, status:
    • nye -> CTO estimater
    • estimeret -> klar til sprinten
    • realisering -> i sprinten
    • høring -> kontokontrol
    • kode gennemgang, fletningsanmodning -> CTO fusioneres i GIT
    • færdig -> fusioneret i den kommende version
  • Ankommer i systemet (nyt)
    • Support manager vurderer, om fejl er kritisk eller ej
    • Ikke-kritisk → tildelt CTO (eller stedfortræder) til tidsopgørelse
    • Kritisk → ah doc-løsning → skal tilføjes i den løbende sprint
  • Sprint første møde
    • VIP + Hosted clients bugs prioriteres
    • bug er placeret i sprint = bugfix levering i den næste version
    • programmør er tildelt til fejlen 
    • Konto drev bug fixering med programmør på stand-up møde
    • Kontoen kommunikerer med kunden
  • Levering med udgivelsen
    • kunden kan hurtigere få bugfixeret version

Feature anmodninger i praksis

  • Funktionsanmodning, status:
    • ny,
    • anslået,
    • aflyst,
    • godkendt af klienten,
    • annulleret af klienten,
    • erkendelse af,
    • høring
    • kode anmeldelse - sammenføje anmodning
    • færdig
  • konto ledere kommer til ledelsesmøde med nye funktionsanmodninger (nyt)
    • diskussion om løsningen (godkendt, annulleret) + tidsopgørelse fra CTO
    • Account Manager informerer klienten om ja / nej + tidsoverslag
    • Kun "godkendt af kunde" -funktionsanmodninger kan placeres i sprinten
  • Sprint Initialization Meeting
    • feature request er placeret i sprint backlog (i sprint)
    • Klienten er informeret om leveringstid - 2 uger
    • Kontochef driver realisering på stand-up møde 
    • Levering med udgivelsen
    • kunden kan få version med ny funktion tidligere

let-redmine-går-adræt-2

Prøv Easy Redmine i en 30-dages gratis prøveperiode

Fuldt udstyret, SSL-beskyttet, Daglige sikkerhedskopier, i din Geo