Redmine for IT-ledelse: Praktisk erfaring omfattende implementering OpenSource-systemer

Liten forhistorie. Som du vet, starter automatisering alltid med noe "muntert". Automatiser deg selv eller din ledelse vi begynner ikke fra et godt liv. Dette skjer vanligvis fordi organisasjonen vokser opp, det blir vanskelig å navigere i en stor mengde innkommende og tilgjengelig informasjon. Så vår organisasjon på et bestemt tidspunkt begynte å vokse raskt, så vi trengte veldig raskt fra kaos for å gjøre noe strukturert, nyttig og praktisk.

Hva betyr kaos i våre systemer? Dette betyr at ikke-bestilte forespørsler som ikke er underlagt analyser og struktureringsforespørsler, kommer fra brukere, og det er ingen prosjektledelse som sådan. Forespørsler fryser et sted i posten, i Word, i lederne av analytikere, programmerere, avdelingsledere - avhengig av hvilken struktur som brukes i organisasjonen.

Vi bestemte oss for å fjerne kaoset ditt ved hjelp av Redmine-programvare. Gjør umiddelbart en reservasjon som vi ikke vil snakke om metodikken. Vi snakker nøyaktig om mulighetene for Redmine, om hvordan vi bruker det. Hvert selskap har sine egne nyanser, ikke ta oss til oss, ikke ta andre. Gjør din analyse, fungere som du tenker riktig og nødvendig for deg. Ikke vær redd for feil, fordi på feil lærer vi.

Fra kaos, som vi hadde, prøver vi å flytte på bestilling. Nå er vi midt på denne måten. Selvfølgelig, ikke alt var og vil være skyløs og glatt, men vi prøver veldig.

Inne i vårt firma, vi allokert tre hovedproblemer:

  • Først trengte vi et system for sporingsfeil, hendelser og innkommende forespørsler, dvs. Vi trengte å automatisere bugsporing;
  • For det andre ønsket vi på en eller annen måte å tildele prosjektledelse. Ikke fullt overvåket av automatisering, som innebærer bruk av metodikker, og i den grad det er nødvendig å bli gjort på utviklingsstadiet og med en eller annen form for fremtid. Deretter ser du hvordan vi bruker Redmine for dette, og hvor vi skal utvikle det videre;
  • For det tredje allokerte vi IT-tjenester kontrollenheten (itsm) i et eget system, men ikke i sin helhet. Vår avdeling gir forskjellige IT-tjenester som må styres.

I tillegg tildelte vi våre private problemer:

  • Dette, jeg gjentar, diverse IT-tjenester, fordi programmerere lever sine liv, systemadministratorer, det er fortsatt en internettmarkedsavdeling og andre;
  • Hver har sin egen struktur og deres ønsker for å administrere avdelingen. I alle avdelinger påfører ulike metoder, tilnærminger, ledere og psykotyper - den avtrykk til valget av systemet. Men det er nødvendig å flytte med alt samtidig, og når et mål - en bestemt rekkefølge i organisasjonen, tilgjengeligheten av informasjon og prognoser;
  • I tillegg er det en annen KPI, som i det hele tatt er beregnet av forskjellige indikatorer;
  • For å utvikle seg videre, trenger vi en ekstra analyse av innkommende informasjon, hva som skjer i avdelingene og hvordan det reflekteres i organisasjonen som helhet;
  • Vi må kontrollere de interne budsjettene, i rammen som vi skriver inn eller oftest, ikke inn i. De må også analysere og administrere dem på en eller annen måte. Det er bedre å gjøre alt dette i et enkelt system - spesielt, det er praktisk for håndboken.

Således allokerte vi tre systemer som jeg vil kombinere i en.

For hvert av disse systemene er det en egen spesialisert programvare. Det er alle de kjente automatiseringsprodukter som har egne fordeler og ulemper, så hvis du velger systemet for deg selv, bør du vurdere alt.

Ikke alle produktene er oppført på lysbildet, det er mye mer av dem, og ikke bare i det russiske markedet, men også på vestlige. Men for oss var en av kravene et russisk-talende grensesnitt, fordi dette produktet ville bli brukt ikke bare programmerere og systemadministratorer som er mer eller mindre forståelige engelsk, men også vanlige brukere.

Hvor skal du gå? Mange produkter. Krav til dem fra ulike avdelinger og kontroller er forskjellige. Vi vil velge.

Som et resultat av analysen og valget, så vel som med innlevering av Alexei Lustin, kom et Redmine-produkt som dekker et bestemt område til oss. La oss finne ut hva slags region det dekker?

Det dekker helt feilsporeren, som vi ønsket å kjøre i selskapet. Dette er sentralisering av mottak av søknader fra brukere og kunder på noe nivå. Det var det mest grunnleggende smertepunktet, som var nødvendig for å automatisk automatisere. Jeg tror at alle har dette problemet, fordi, som jeg allerede har sagt, kommer informasjonen i uorden og bosetter seg på forskjellige steder - i posten, i Word, i Excel eller Heads. Slike opplysninger er ikke underlagt å analysere og få konklusjoner og resultater. Som et resultat viser det seg at:

    • Informasjonskomponenten i kunnskapsbasen, som kan analyseres og forstå hva de skal gjøre neste, er fraværende. Dette bremser reaksjonshastigheten og påvirker uavbruttheten og kvaliteten på arbeidet, hvorfra fortjenesten direkte avhenger av;
    • Øker "dykk" tidspunktet for nye ansatte til å jobbe med bedriftssystemer;
    • Feiltoleranse er også hver av sin egen - noen uten arbeidssystem kan ikke leve to minutter. Derfor spiller Bug Tracker en stor rolle, og på den tiden ble problematikken veldig akutt.

Redmine Project Management dekker halvparten, fordi dette produktet ikke spesialiserer seg på å administrere prosjekter, men det er en viss blokk, som hjelper i dette. Dessverre er dette ikke et ideelt produkt, men på den tiden dekket han kravene vi satte opp til systemet.

Og en veldig liten ITSM-blokk er dekket. Redmine-systemet er ikke ment å administrere IT-tjenester, så det er noen feil i ledende og strukturering av data. Vi har kommet ut av denne situasjonen ved å velge din versjon av ITSM-systemet.

Så, vårt valg er Redmine. Det er ganske tilpasset, skalerbart, fleksibelt og med praktiske innstillinger.

Hvorfor redmin?

  • Dette er det søte ordet "freebie". Redmine er gratis, men med reservasjonen, at det er betalt plugins som du velger for deg selv. I alle fall har du en slags kostnadsprognose, fordi hvis du kjøpte et plugin og ikke endrer Redmine-plattformen, så i en stund kan dette plugin brukes uten ekstra investeringer. Og hvis du for eksempel må oppdatere det, betaler du for denne oppdateringen og bruker den videre. Redmine-plattformen oppdateringen oppstår en eller to per år, og oppdateres eller ikke - dette er ditt ønske.
  • Redmine har et intuitivt grensesnitt. Vi har implementert Redmine ikke bare som et produkt for IT-ledelse, men også som et produkt der applikasjoner fra brukere mottas for ulike avdelinger. For eksempel er en egen gren fremhevet for bruk av administrativ og økonomisk avdeling.
  • Det er mulig å kontrollere prioriteringer i ulike analytiske former, inkludert individuelt i henhold til oppgaver.
  • Ledelse tid og ressurser. Jeg tror dette er hovedenheten for hodet. Det lar deg forstå hvor mye avdelingen er lastet, med hvilke oppgaver hvilke kostnader som er relaterte og hvordan å klassifisere kostnader, men om det nedenfor.
  • Analytics og rapporter i Redmin er svakt uttrykt, men det er en omfattende API. Du kan ta data fra API-databasen, avlaste dem til systemet ditt og få noen rapporter.
  • Fleksible innstillinger, tilpasning og automatisering av manuelle operasjoner med plugins.
  • Integrasjon med GIT er en av de viktige indikatorene. Repositoryet i vår database er koblet til Gitlab, og i en hvilken som helst Redmine-oppgave kan du se logger (relaterte utgaver): hvem, når og hva som har endret seg i henhold til denne oppgaven, med overgangen til Gitlab.

For informasjon: GIT er et distribuert versjonskontrollsystem. Det sporer, reparerer og lagrer informasjon (versjoner) om endringer i noen filer og kataloger, og overvåker også dataintegritet. I vårt tilfelle snakker vi om kildekoden 1c.

Dette er hva listen over relaterte utgaver ser ut som:

  • Oppgaveadministrasjon og feilsporing. Dette er en standard feilsporing, som vi vil bruke.
  • Forvaltning av hendelser, prosjekter, budsjetter. All budsjettformasjon utføres på egen måte. Jeg vil vise hvordan vi automatiserte det på deg selv, og du kan da prøve å automatisere ledelsen av budsjettet i deg selv - jeg tror det vil være enkelt, fordi det er arbeid i Redmine, og du kan også overføre dem til penger også.
  • Wiki i Redmine er ikke veldig godt implementert, så det er bedre å bruke et annet produkt med det formål å skape en kunnskapsbase og samarbeid. For meg selv valgte vi Confluence-systemet fra Atlassian, som er et av de vanligste og enkle å jobbe. Du kan også vurdere systemer: Dokuwiki, MediaWiki og andre.

Hva er Redmine under hetten?

  • Redmine veldig raskt og bare utfolder seg.
  • Det fungerer på de fleste OS.
  • Plattformen som den er implementert på, er rubin på skinner. Hvis du vil tilpasse Redmine under oss selv, må du ha en kompetanse på Ruby på skinner, ellers vil det ikke være veldig praktisk, fordi Ikke alt kan gjøres ferdige plugins.
  • Støtte for ulike DBMS snakker for seg selv.
  • Med RSS eller E-post kan du organisere varsler på eventuelle hendelser.
  • Annonseautentisering er tilgjengelig.
  • Integrasjon med SCM-versjonskontrollsystemer (svn, CVS, GIT, Mercurial, Bazaar og DARC).

Møt Redmine.

Du kan laste ned Redmine, installere den på datamaskinen og "eksperimentere". Eller bruk Cloud-serveren, og "i ett klikk" for å sette deg en forhåndsinstallert versjon av Redmine, som vanligvis er inkludert i hosting-tjenesten.

Eksempler på installasjon for ethvert system, inkludert bruk av Cloud Service, finnes på Internett. Offisiell instruksjon på linken:

Så ser ut som en liste over oppgaver i Redmine.

Det er en standard og flere ekstra grensesnitt. Sann, når du endrer grensesnitt, kan noen funksjoner slutte å jobbe, fordi Tilpassede grensesnitt tar ikke hensyn til pluginene som du vil fungere på - alt er et åpent kildeprodukt. Men dette hindrer ikke ham i å være et praktisk verktøy selv ved hjelp av standardgrensesnittet.

Administrasjonen er allokert i en egen og ganske forståelig struktur.

Listen over moduler som er koblet til din Redmine, kan du alltid se og analysere i den aktuelle administrasjonsseksjonen.

Vi har ikke en "ren" Redmine, fordi Det er ca. 35 plugins. Vi kjøpte noen av dem.

Informasjon om plugins kan bli funnet i søkemotoren med søkeord "plugins for Redmine". For eksempel er det to steder hvor du kan laste ned eller kjøpe gode plugins for å begynne å jobbe med Redmine:

Alle plugins er Russified, du kan kjøpe og bruke. Det viktigste er å velge behagelig. Bare vær oppmerksom på hvilken versjon av Redmine støtter pluginet, fordi hvis den støttede versjonen ikke samsvarer med din, er det en sjanse for at plugin ikke vil fungere.

Litt om automatiseringen av våre behov

Struktur "prosjekter"

Vi bruker Redmine ikke i henhold til standard lederskap. Som et eksempel, innenfor rammen av systemet, er begrepet "prosjekt" en egen gren i strukturens hierarki. Vi bruker "prosjekter" treet som en klassifisering av nivåer. På toppnivået er det en executive-avdeling, han er underlagt departementer, så følges systemene, delsystemene og tjenestene.

En del av treet ser slik ut:

Systemadministrasjonsavdelingen bruker også sin tilnærming til hierarkiet av prosjekter. Arbeidet er bygget på grunnlag av klassifiseringen av tjenester som tilbys - det bidro til å løse problemet med servicekontrollen. Derfor, i ITSM-grenen, er prosjekthierarkiet en forretningstjeneste katalog. For enkelhets skyld er de nummerert.

Opptak av applikasjoner i Redmine

Ifølge eksemplet vil jeg fortelle deg hvordan vi organiserte mottak av applikasjoner i Redmin.

Vår avdeling er delt inn i 3 grupper:

  • Utviklingsteam;
  • En gruppe analyser og akkompagnement - her inkluderer ansatte som produserer nivået på "to og en halv" støtte. De anbefaler, analyserer problemet, om nødvendig, "Les" -koden, kan skrive forespørsler om dataanalyse, samt korrekte feil i koden. Som et resultat, klarer vi å ekskludere distraksjonen av programmerere fra små problemer, så vel som ved hjelp av analytikere, vi adskiller programmerere fra kunder og tilbake, fordi Alt, sannsynligvis, møtte problemene med relasjoner mellom dem.
  • Og gruppe av administratorer av database 1c.

Så mottak av applikasjoner i Redmine med oss ​​utføres gjennom skrivingen av det vanlige bokstaven på den uthevede postkassen. For organisering av individuelle postkasser, vi i hver avdeling og i hver gruppe tildelt sin "prosjekter" struktur, for eksempel:

For hvert av prosjektene konfigureres vi i Helpdesk-plugin postkassen din. Skjermbildet viser innstillingene til Helpdesk-pluginet for et av prosjektene:

Letters som kommer inn i postkassen som er koblet til "Prosjektet", faller inn i vårt system som programmer med en visning av "Brukerforespørsel". Alt dette fører til en reduksjon i lønnskostnadsansatte til den primære klassifiseringen av innkommende forespørsler. (Eksempel i skjermbildet: 1.2 Administratorer 1C, 1.4 TICKET CONCLUENCE, 1.5 Støtte for Yurait DPP)

Hvis det er umulig å produsere et slikt utvalg av strukturen, er det ganske mulig å velge en postkasse, og i treet for å skape underordnede grener, hvor applikasjonene vil bli distribuert til den første støttelinjen etter den primære klassifiseringen (prøveskjermbilde : 1.3 Brukerstøtte).

Som et resultat, passerer applikasjonen syklusen:

  • Først skjer den primære automatiske oppføringen i prosjektet;
  • Da distribuerer analytikeren søknaden, det vil si klassifiserer, kategoriserer og prioriterer det;
  • Deretter overfører analytikeren anvendelsen til den ønskede grenen.

I applikasjonen er det visse klassifikasjonsfelt, noen av dem pretentically, og delen er lagt til av oss. I samsvar med dette utføres den primære nødvendige fyllingen ved hjelp av parametere:

  • Prioritet;
  • Kategori;
  • Kundeavdeling;
  • Stastfelt av ulike typer.

De. Hvis en hendelse oppstår, kan du være sikker på at den ikke vil passere ubemerket.

Et eksempel på mottatte applikasjoner og felt som brukes:

Innstillinger "Prosjekt"

Inne i "prosjektet" kan det være flere typer trackers. Her, for eksempel, ofte brukt trackers:

  • Brukerforespørsel;
  • En oppgave;
  • Feil;
  • Setning;
  • Forretningsprosjekt;
  • Program for forretningsprosjekter, etc.

Trackers kan være et ubegrenset antall - de kan legges manuelt. Hver tracker er fleksibelt konfigurert.

I "Prosjekt" -innstillingene kan vi angi hvilke trackers i den som brukes, så vel som hvilke egendefinerte felt som kan kobles til.

Også de nødvendige modulene og andre innstillinger er også koblet til hver gren. Du finner dette i standard Redmine Documentation.

Etter at du har koblet modulene, trenger du ikke å produsere noen komplekse manipulasjoner, du trenger bare å lagre listen over modulene i det nåværende "prosjektet", og de vil vises i form av faner når du går som du kan gjøre det nødvendige Innstillinger.

I tillegg er Redmine svært fleksibelt konfigurert for å få tilgang til rettighetene til ulike nivåer både til "Prosjektet" og på separate relaterte funksjoner, samt tilgjengeligheten av hvert felt.

På oversiktssiden "Prosjekt" kan du se alle slags trackers og statistikk på dem. Og også når "faller ned" i trackeren, ser du underordnede av dette "prosjektet" av problemer - la oss ringe til dem "kort".

Forretningsprosjekter

Jeg gjentar litt. Siden i begrepet Redmine "-prosjekt" - dette er en gren av strukturen i strukturen, så for vedlikehold av virkelige prosjekter, vi allokert en egen gren med "Business Project" og "Business Project Program" Trackers. Dette gjør at vi kan beholde statusrapporter på våre forretningsprosjekter og formskostnader når det gjelder distribusjonsbaser.

Strukturen i denne grenen er også delt inn i stavemåter på spesifikasjonene: Avdeling, kunde, system, delsystem.

Fordi Vårt forvaltningsselskap, avdelinger sentralt følger alle selskapene som er inkludert i Wiseadvice GK. I denne forbindelse gjennomfører vi prosjekter både individuelt for ethvert selskap og felles for flere selskaper. Som et resultat, for hvert prosjekt og oppgaven er å budsjettere og skrive av kostnadene for avdelinger.

I et forretningsprosjektkort kan du også konfigurere de nødvendige feltene. Et eksempel på feltene vi bruker:

  • Basis distribusjon / kostnad mottaker;
  • Bonus for prosjektet;
  • Evaluering av lønnskostnader;
  • Start / Fullføringsdatoer planlagt;
  • Dagstatusrapport og andre.

Alle oppgaver som er opprettet i prosjektet, er underordnet hovedkortet i forretningsprosjektet.

Statusrapporten overleveres til kunder minst en gang i uken. Hele historien akkumuleres i kortet og sendes til interesserte parter.

Kunden og andre interessenter kan når som helst se følgende opplysninger på forretningsprosjektet:

  • Prosjekt status;
  • Estimerte lønnskostnader;
  • Faktiske lønnskostnader er for tiden i sammenheng med utførelse og ansatte;
  • Prosjektets beredskap;
  • Formulering av et forretningsprosjekt;
  • Hele korrespondens historie;
  • Prosjektets planleggingsdato begynte, hvis han ble utsatt på grunn av prioritering;
  • Den planlagte datoen for gjennomføring av prosjektet.

Faktiske lønnskostnader samles inn fra de underordnede forretningsprosjektoppgavene i tid brukt av de ansatte i avdelingene.

Basert på de dannede oppgavene, kan du bygge et Ganta-diagram, men bare i en informativ versjon. I tillegg er det umulig å bruke det og interaktivt.

Når du arbeider med tidsplanen for kalenderplanlegging, kan du bruke grafiske rapporter. For eksempel:

Vi bruker oppgavesteder for å distribuere oppgaver innen ukentlig planlegging.

Alt dette er implementert gjennom plugin-moduler, som inkluderer muligheten for å gjennomføre Agile eller Kanban-brett.

Som et eksempel:

Med tanke på egenskapene til plugin, viser det seg som Kanban-bordet. Det kan interaktivt overveldes av pakkene - både mellom statusen og mellom utøvere. På tre grensesnitt ble sjekket - det fungerer bare på to. Standardgrensesnittet kjører nøyaktig. Veldig praktisk å vise på en stor TV / skjerm for planeter / rallyer.

Også planlegging kan utføres ved hjelp av versjoner og konverter deretter versjoner i utgivelser.

Som effektiviteten av instituttets effekt, danner vi rapporter i sammenheng med kostnadene for distribusjon av kostnader og faktiske arbeidskostnader for avdelinger.

Standard Arbeidsrapporter kan angis:

Vi bruker tilbøyelighet til rapporten om lønnskostnader:

  • Kostnadsdistribusjonsdatabase - vårt egendefinerte felt;
  • Kostnadsmottaker - vårt stavfelt;
  • Brukeren er et standardfelt.

Dannelsen kan forekomme i sammenheng med perioder:

For våre budsjettering bruker vi bare "måneden". Rapporter eksempel:

Skjermbildet presenterer et eksempel med faktiske lønnskostnader i sammenheng med distribusjonsbasen for august.

I tillegg kan du danne en detaljert rapport for hver deklarert tidsverdi. Om nødvendig konverteres alle rapporter til CSV, slik at ytterligere analyse kan gjøres i Excel.

Og selvfølgelig, som det sanne 1c-kallenavnet, kan vi skrive lossingsinformasjon fra Redmine i 1C for å danne rapporten din i 1C med de nødvendige gruppene og informasjonen.

Et eksempel på en av kostnadsrapporterne:

Litt mer om Redmine-funksjoner

Av de ekstra nyttige funksjonene i Redmin, vil jeg gjerne fremheve:

  • Autentiseringsmodus - enten via annonse, eller ved innlogging og passord;

  • Varsler systemet. Brukeren vil bli varslet om endringer i oppgaven. Du kan konfigurere e-postvarsler og RSS;

  • Kombinere brukere til grupper. Med dette verktøyet kan du danne i bedriftens redmine hierarkiske struktur. Det er plugins på integrering med regnskapssystemet og kloning av strukturen i grupper;
  • Rollemodell rett, med flere installasjoner på flere nivåer;

  • Sette arbeidsflyten (livssyklus) av hver tracker for hver rolle;

  • Tilstedeværelsen av integrasjonsplugger med MS Outlook. For eksempel, en ganske praktisk plugin med mange funksjoner, for eksempel å lage en applikasjon i Redmine direkte fra brevet, kommentere, sporing, etc.; Offisiell side:

https://ru.a.ausoftware.com/

  • Det er også plugins å integrere med direktemeldingssystemer, for eksempel telegram og SMS-gateways. På en hvilken som helst kommunikasjonskanal kan du sende varsler, for eksempel hendelser, overvåkingsinformasjon, etc.;
  • Hvis det er en kompetanse, er det mulig å gjøre noen plugins selv.

Spørsmål og svar:

Spørsmålet fra hallen : Anta at vi har gitt tilgang til kunden, og vi har en viss liste over støttede tjenester for det. For eksempel, som i ditt eksempel, er det tjenester av Sysadminov og kodertjenester. Med en slags kunde jobber vi på begge typer tjenester, og med en slags bare én type. Er det mulig på nivået av rettigheter til å begrense hvilken type tjeneste som er tilgjengelig for kunden?

Svar: Dette varierer bare av en egen gren som er tildelt under kunden - "Project", hvor oppgaver for utvalgte tjenester kan opprettes individuelt for denne kunden. Eller du må gi tilgang til alle oppgaver i grenen - "Project" -støtte for denne tjenesten. Standard evne til å begrense rettighetene på tegnet av tjenesten og kunden i "prosjektet" i Redmine "ut av boksen" er ikke. Du kan se etter et slikt plugin eller skrive det selv. Vi har ingen en slik kompleks struktur, men det er oppgaver som bare skal være tilgjengelige for individuelle store enheter, så de har blitt opprettet for dem.

Spørsmål fra hallen: Det viser seg at hver kunde er et "prosjekt". Og innenfor ett "prosjekt" kan delprosjektene gjøre?

Svar: Ja, så mye du vil. Vi, for eksempel å markere gresk til å skille kundeavdelinger, og gi det der for å bli åpnet av de viktigste ansatte, slik at de ikke ser hele helpdesken forbundet med kunden, og hele strukturen, fordi Hun er ganske stor. Redmine fleksibel i innstillingene, men dessverre, og i fleksibiliteten er det begrensninger som leverer litt ulempe. Selvfølgelig er det mer praktiske høyt spesialiserte løsninger, men de blir betalt.

Spørsmålet fra hallen : Og arbeidskostnadene som er gjort på hver status, oppsummeres? For eksempel, på statusen "i arbeidet", satte jeg arbeidskostnadene 0,3, og deretter på statusen til "analysen" satte jeg noen flere lønnskostnader.

Svar : Store kostnader går generelt for oppgaven. Det er umulig å klassifisere lønnskostnader i henhold til statuser, men lønnskostnader har et felt "aktiviteter", hvis essensen kan gjenspeile prosessen der du skriver av tiden på. Det er også redigerbart. Når du skriver gjennom lønnskostnader, velger en ansatt en type aktivitet som er løst. Deretter, ved hjelp av rapporter, kan du trekke tilbake tiden i sammenheng med prosessene.

Uten en indikasjon på typen aktivitet, kan rapporten bare dannes av den totale tiden i sammenheng med arbeidstaker + dag.

Sammendrag Analytiske data kan ses av rapporter. Direkte i oppgaven er kun kostnaden for den nåværende oppgaven synlig.

Spørsmålet fra hallen : Det viser seg at jeg har den første linjen med teknisk støtte og den andre linjen med teknisk støtte. Hver av dem bruker på samme oppgave i samme status "i arbeidet" på en viss tid. Følgelig, hvordan kan jeg definere faktiske lønnskostnader per person på oppgaven på den første linjen, på den andre linjen, på den tredje linjen?

Svar : Jeg gjentar, kostnadene går generelt på oppgaven, men hvis en person tilbrakte så mange tid, og deretter bruker en annen person tid - dette gjenspeiles her. Delvis ble svaret gitt under det forrige spørsmålet. Deretter kan du se hvilken av dem hvor mye som har brukt, men bare i denne versjonen. Det finnes ingen separate kostnader hvis du legger til egendefinerte felt for å skrive av lønnskostnader eller bruke brukergrupperinger og videreformulere analytiske rapporter.

Spørsmålet fra hallen : Hvordan organiseres brukerinteraksjonen? Via e-post?

Svar : Sende går til et e-poststandardbrev eller skrevet av brukeren, eller en automatisk REDMINE-fold, hvis det er en observatør for denne oppgaven. Også, hvis han er en Redmine-bruker, viser topppanelet hvor mange oppgaver som er utnevnt hvor mange nye og hvor mange endringer. Jeg ser nå at jeg har 20 oppgaver, hvorav en er ny og en endret. Fra brukersiden - bare e-post.

Som beskrevet ovenfor, når du kobler til Plugins, kan du unilaterally varsle brukere ved hjelp av direktemeldingssystemer.

Spørsmålet fra hallen : Er det et webgrensesnitt for innlevering av applikasjoner?

Svar : Ikke. Redmine fungerer på smarttelefoner og tabletter, dvs. har et tilpasset grensesnitt. Men applikasjoner kan sendes enten via e-post, eller gi tilgang til brukeren direkte inn i systemet, og begrense det i rettigheter bare for å skape. Som en ekstra funksjon kan du sette en plugin i Outlook for å lage oppgaver i Redmine.

For tiden er det en trackerhlider-plugin, som du kan begrense tilgangen til sporere i sammenheng med brukere eller roller.

Eksempel: Enhver bruker med "Observer" -rollen i "Prosjektet" er bare tilgjengelige kort med "Brukerforespørsel" Tracker.

Spørsmålet fra hallen : Og funksjonaliteten til å jobbe med e-post er en av boksen eller fra plugins?

Svar :Ja, det er "ute av esken." Med hjelp av plugins, kjøper det bare flere fasiliteter og innstillinger.

Spørsmålet fra hallen : Og er det mulig å konfigurere at varselet om kunden, som vi kom inn i systemet, gikk bare på en viss status. Hvorfor skal han se våre interne ti stadier hvis han trengte varsel om å gå bare når oppgaven er fullført?

Svar :Vi løste denne situasjonen som følger.

1. Først av alt, de deaktiverte for brukere-kunder standard redmin varsler i brukerinnstillinger. Denne innstillingen er global for alle REDMINE for den nåværende brukeren.

2. Videre, for den nødvendige grenen ("Project") koblet til muligheten for å sende bokstaver.

3. Analytiker, eller RP-SHNIK kan sende en e-post ved hjelp av en standardmekanisme: Ved å trykke på "Send et notat" -tegn på kortredigeringsmodus. Om nødvendig kan du spesifisere flere mottakere.

4. Avsenderen kan skrive tekst og legge til de nødvendige vedleggene. Eller bruk tidligere konfigurerte mønstre.

 

For å gjøre dette er det ferdige mønsteret valgt, erstattet i brevet i brevet, og det forblir bare for å fylle, om nødvendig, tilleggsinformasjon.

Etter det må du klikke på "Godta" -knappen, så blir kommentaren lagret og brevet vil bli sendt. Kunden vil motta et varsel i form av et vanlig brev.

Dette er en standard mekanisme, vi rørte ikke noe. Maler for hvert prosjekt er tilpasset individuelle. Dette er en ganske betydelig forenkling av analytikerkonsulenten, fordi hver gang du skriver den samme teksten - er det arbeidskrevende.

Skjul tekst fra kunden, hvis den har tilgang til ham direkte til oppgavekort, er det bare mulig ved bruk av en "privat" kommentar eller ved å slå av tilgangen til denne typen kommentarer.

Det andre alternativet er å bruke et ekstra plugin, fordi Som standard er det ingen slik innstilling.

Spørsmål fra hallen: Er det mulig å binde motparten til oppgaven mottatt? For eksempel har jeg en telefonsamtale med PBX, hvor motpartsnummeret blir scoret, og Redmine tar det ankomne nummeret fra PBX, skaper en oppgave og lærte det til motparten. Har du løst oppgaven til hierarkiet av motparter?

Svar: Nei, vi integrerer ikke Redmine med IP-telefoni, det var ikke vårt mål. Ideen er god, men i våre spesifikasjoner er det ikke nødvendig. På internett kan du finne Redmine Integration med Asterisk.

Spørsmålet fra hallen :Vi har et spørsmål ikke på IP-telefoni, men på hierarkiet av motparter. Vi ønsker at ledere ser det samme hierarkiet av motparter i Redmine som 1c.

Svar : Nei, kontaktstrukturen er flat. Det eneste vi la til, er en lenke til avdelingen. Maksimum som vi bruker er å samle kontakter av avdelinger, vi lager bugsporing for innenlands tjenester, og ikke for eksterne kunder. I Redmine selv er det umulig å organisere et hierarki av motparter, men du kan knytte enheter i Redmine og 1C, og danner denne rapporten ut av 1c.

Spørsmålet fra hallen : Og hvor er dybden av scrum? Vi har betinget sprint - 7 kalenderdager (5 virkedager). Hvor kan jeg se hva er iterasjonen til sprintet? Hva er kalenderen uke, hva er sprintnummeret?

Svar : Scrum dybde kan styres av versjoner. Det er en funksjon av versjoner.

For dette er det en spesiell seksjon "operativ plan" (eller "versjon" avhengig av grensesnittet).

Jeg har for eksempel tre versjoner.

 

Hver versjon kan ha sitt eget navn, status og begrenset til ferdigstillingsdatoen.

For hver versjon er oppgavelister synlige hvis de presenteres, så vel som antall uferdige.

For visualisering kan du danne diagrammer

Versjoner kan grupperes, bryte oppgaver, du kan bygge brett i henhold til dem. Du kan overføre oppgaver mellom sprints - en slik mulighet er i versjonen "Planleggingsversjoner".

Faktisk kan Redmine være et verktøy for å organisere arbeid på omfang eller canbana. Det er imidlertid nødvendig å ta hensyn til at noen ganger ikke er nok sortering og andre små ting for enkelhets skyld. Kanskje det er plugins som støtter den. I det nødvendige volumet av nåværende funksjonalitet er det nok. Her kan du gjøre oppdraget av oppgaver, flytte mellom sprints, se at du ikke hadde tid til å gjøre for den planlagte tiden, etc.

Spørsmålet fra hallen : Hvordan tar vi hensyn til oppgavene som ikke ble oppfylt i den nåværende sprinten? Skal jeg se det i status? Eller de på en eller annen måte automatisk vil jeg vise det at de nå er nødvendig for å bestille en ny versjon?

Svar : Du kan velge oppgaven i henhold til versjonen. For eksempel, for å se på "operasjonsplanen", for hvor mange prosent det er fullført og hvor oppfylt. De. Hvor mange oppgaver er stengt fra sprint og hvor mye er ennå ikke lukket - det vil bli skrevet her. Når du klikker på det tilsvarende elementet, er det åpne en liste over oppgaver som ikke er stengt. Videre, som jeg sa, kan de analyseres og overføres til en annen sprint.

Du kan også danne brett med oppgaver, i henhold til de samme versjonene og i sammenheng med statuser.

Og selvfølgelig bruker standardlisten over oppgaver med det nødvendige valget, som kan lagres og brukes i permanent drift.

Spørsmålet fra hallen : Hvordan kan du overføre oppgaven til en annen sprint - jeg må åpne en liste over oppgaver på en kategori, Kanban-brett på en annen og overføre?

Svar: Kan være slik. Men det er mer praktisk å bruke verktøyplanleggingsverktøyet. Velg fra listen over ufordelt oppgaver eller uferdige oppgaver av en bestemt versjon av ønsket oppgave og kast den inn i den neste versjonen av musen - vis at vi tar denne oppgaven i sprinten.

Spørsmål fra hallen: Og hvordan kan du gi alle ulåste oppgavene? Kanskje tre eller fire versjoner tilbake hadde jeg en slags viktig oppgave der. Jeg registrerte det, hun henger der. Hvordan kan jeg ikke miste henne slik at hun hele tiden ble hengt med meg? Så vidt jeg forsto, nå kan du bare se uoppnådde oppgaver eller oppgaver fra den valgte sprinten. Og hvordan å se alle de ulåste oppgavene med et kumulativt resultat, å forstå, ta dem inn i den nåværende sprinten eller ikke ta?

Svar: Dette kan implementeres ved hjelp av filtrering i oppgaver. Du kan lage utvalgsinnstillinger i statusen "Åpne" med de nødvendige parametrene og lagre.

 

For eksempel kan vi vurdere innstillingen, som kalles "Oppgaver for lukking". Det er oppgaver med statusen "Solved", som ble implementert av avdelingen vår og overført til kunden til produksjonsoperasjon, men ingen tilbakemelding fra kunden har ennå ikke mottatt. De. Dette er et basseng av oppgaver som må kontrolleres for å avklare resultatene av produksjonsutnyttelse og lukke. For eksempel kan du endres i statusfilterverdien "tilsvarer" og skiltet "Ny". Som et resultat vil nye oppgaver bli vist som ennå ikke er tatt for å fungere. Du kan variere status, prioriteringer, kategorier, eventuelle verdier av både standard og tilpassede felt.

For eksempel kan du legge til et spesielt brukerfelt i filteret. Dette er et praktisk verktøy, veldig enkelt. For prosjektet, for oppgaven, for kontakt.

Nytt felt - Angi typen objekt, hvor vi legger til, oftest brukte "oppgaver".

Vi angir feltformatet - opsjoner som er dekket et sted 90% av behovene.

Angi navnet, hvordan vil rollene er tilgjengelige.

Vi angir hvilke prosjekter som sporere brukes på.

Spørsmålet fra hallen : Og egendefinerte felt kan gjøres obligatorisk?

Svar : Selvfølgelig, analogt med ytterligere detaljer i 1c.

Obligatoriske felt er merket med en rød stjerne til høyre for navnet.

Spørsmålet fra hallen : Og hvordan har du rapportert om utført arbeid? I samme oppgave går til en annen bruker - det er en oppgaveinitiator, og det er en utøver.

Svar: Det stemmer, hvis feltet endrer seg - til hvem den er tildelt, så går det i rapporten den endelige verdien.

La meg fortelle deg hvordan vi alle ordnet. Delvis gjenta.

  • Den viktigste tracker for Service Desk er en "brukerforespørsel", som posten demonteres automatisk, og brev blir til "Brukerforespørsler". Hvis brukeren sendte et svarbrev til Melding fra Redmine eller sendte et avklaringsbrev med det samme emnet, legger du på emnet eller ID i emnet automatisk tekst fra et slikt brev til et eksisterende spørsmål - en klassisk limingsfunksjon brukes.
  • Neste - Når for eksempel en forespørsel om rådgivning i KIS-avdelingen kom, demonterer analytikerne konsulenter søknaden og produserer sin primære klassifisering. Bestem at dette er en hendelse, feil eller oppgave. Det kan til og med være en ide til et nytt prosjekt. Derfor er dette også en del av Service Desk. Etter klassifiseringen distribueres alle "brukerforespørsler" til delprosjektene i ITASK-grenen, hvor ytterligere arbeid allerede gjøres med dem.
  • Hvis dette arbeidet degenererer oppgaven for utvikleren, blir den tilhørende underordnede "oppgaven" opprettet på grunnlag av brukerens forespørsel. Det vil si at "brukerforespørsel" Tracker bor i seg selv, og oppgavesporet er også skilt. Vi snakker om små modifikasjoner og feilkorrigeringer som vi har en egen strøm - de vises fra "Brukerforespørsler".
  • Hvis oppgaven gjelder et bestemt forretningsprosjekt og utvikleren ikke gjorde det på grunnlag av "Brukerforespørsel", er den knyttet til det underordnede forretningsprosjektet til blokkene i Kisa-funksjonaliteten, slik at oppgaven senere kunne ses - På hvilken blokk og i forbindelse som vi gjorde - det var "brukerforespørsel" eller et forretningsprosjekt.
  • Separat lever Tracker "Business Project", som vi kommuniserer med virksomheten - ikke med brukere på forespørsel og mindre raffinement, og allerede med virkelige prosjekter som har forretningsverdi. I "forretningsprosjektet" som underordnede oppgaver kan også være deres subtasker og til og med pakker med oppgaver - stor, med underordnet og tilkoblinger. Dette er et slikt minisikkert. Alle disse subtaskene er igjen knyttet til blokkene i funksjonaliteten til KIS.
  • Det spiller ingen rolle hvor oppgaven kom fra - fra Service Desca eller fra et forretningsprosjekt. Men vi binder dem alle til blokkene av funksjonalitet.

Basert på ovenstående gjentar jeg, vi kan se lønnskostnader i konteksten:

  • Blokkene av funksjonalitet av KISA;
  • Prosjekter;
  • Utøvere;
  • Kommunikasjon "Forespørsel - Oppgaver / Business Project - Underordnede Trackers".

Skjermbildet presenterer et eksempel med faktiske lønnskostnader i sammenheng med prosjekter for august i måneden. Ansatte må distribuere sin faktisk brukt tid på oppgavene de utførte. Dette kalles tidsark. Vi har daglige utviklere angi de spesielle postene på "arbeidsrapporter" og distribuerer sin tid - faktum at arbeidet er dannet. Dermed klarer vi i det minste omtrent faktisk budsjettet til prosjektet.

Våre prosjekter har en foreløpig arbeidsplan. Og i hvert prosjekt ser vi, vi overgikk det eller ikke. Redmine oppsummerer automatisk bredden på alle oppgaver underordnet prosjektet. Følgelig vet vi at dette prosjektet er tildelt 700 timer. Vi ser faktumet - 617 timer har blitt utarbeidet. Dette er en av prosjektledelseselementene.

Aktivitetsprosessen til systemet av hendelser kan representeres som følger:

  • Analystrådgiveren gjennomfører en analyse av den forespurte forespørselen, om nødvendig, danner en utviklingsoppgave;
  • Utvikleren implementerer oppgaven og returnerer sin analyse konsulent for å verifisere og videre kommunikasjon;
  • Analystrådgiveren kommuniserer allerede på forespørsel fra brukeren med en beskrivelse av resultatene;
  • Hvis alt er i orden, lukker analytikeren oppgaven - utvikleren er forbudt å lukke oppgavene.

I flere store oppgaver, inkl. Design, prosessen er bygget mer utvidet:

Og selvfølgelig faller alle endringer i arbeidsbasen gjennom utgivelsen av utgivelsen.

Hvis du sender den inn i et mer praktisk alternativ, så har vi vår egen "åtte".

De., Virkelig mange oppgaver overganger mellom ansvarlig, men det er ikke kritisk for oss. Vi vurderer lønnskostnader i sammenheng med ansatte, kostnadene for distribusjon av kostnader, kunder og i sjeldne tilfeller i form av aktiviteter. Alt dette er allerede angitt tidligere.

Spørsmålet fra hallen : Er det mulig å få informasjon om hvilke oppgaver som gjorde en bestemt utvikler, oppfyller?

Svar : Det er. Det er et "arbeidsrapport" verktøy som du kan se hva en ansatt som oppgave hvor mye tid og hvilken dag jeg brukte.

Eller det kan ses av en standardrapport "lønnskostnader" - det kan også dannes i sammenheng med brukere med dekoding.

Spørsmålet fra hallen : Og hvordan å spore dine lønnskostnader?

Svar: En ansatt kontrollerer også sitt arbeid gjennom "arbeidsrapporten". Og fiksering av lønnskostnader i oppgaven gjøres manuelt - enten direkte i oppgaven eller i "arbeidsrapporten". Det er plugins som lar deg holde oversikt over tid. For eksempel ser Redmine Problem Timer Plugin ut som dette:

Når du begynner å jobbe med en oppgave, klikker en ansatt "Play" -knappen, og på slutten - "Pause" -knappen. Når du opprettholder oppgaven, er lønnskostnadene fastsatt i den.

Spørsmålet fra hallen : Spørsmål til tidsstyring og ressurser er Postfactum Management, registrerer allerede, når jeg ser på hvordan mine ansatte er lastet, eller er det mulig å planlegge? Når jeg ser ut i morgen, må programmøren ta opp oppgaven med dette, og dagen etter i morgen dette. Og jeg forstår at det konvensjonelt sett er en kraftig programmerer, og han kan ha rapporter uten problemer for to, tre per dag til rivet, og jeg kan sette en kø av oppgaver i en uke.

Svar :Evnen til å planlegge er, men det er ikke perfekt - gratis produkt gjør nyanser. Det er et felt av "planlagt tid", det er mulig å sette ditt egendefinerte felt hvis du mangler et standardfelt etter planleggingstid - hvor mange timer med timer vil det tilbringe. Det er mulig å spesifisere den planlagte tiden og sammenligne deretter den planlagte og faktiske tiden. Og selvfølgelig kan du bruke Standard Story Points-feltet for pokerplanlegging.

Spørsmålet fra hallen : Du sa at Wiki i Redmine ubehagelig.

Svar :Wiki i Redmine ser unfriendly ut.

 

For å formatere artikler og oppgaver, brukes merkingsproget Markdown. Formatering er ikke "på fly", men indikerer merkingssymbolene.

Søket er - ifølge ordet i teksten og overskriftene. Hvis du skriver inn "Exchange" i søket, vil det gi både temaer og trackers. Det er et utvalg etter type tracker.

Innholdsfortegnelsen er ikke hovedsiden, og når du skriver inn Wiki, vises bare en liste over opprettede artikler.

Innholdsfortegnelsen er som følger:

Og selvfølgelig er Wiki i Redmine ment for bare å lagre artikler. Det kan ikke brukes til å samarbeide.

Historien om endringen av artikler utføres og kan bli funnet når, hvem og som endres produsert.

Spørsmålet fra hallen : Hvordan fyller Wiki?

Svar : Vår prosess er konstruert som følger. Analyse av Service Desk utføres med en viss periodicitet i løpet av den siste perioden. Ved hjelp av en innledende klassifisering som ble gjort av analytikere når vi ber om en forespørsel, prøver vi å oppsummere temaene og identifisere de mest problematiske sonene. Neste - Vi presenterer selvbetjening, dvs. Dokumentere hvordan brukeren selv kan løse sitt problem eller spørsmålet. I tillegg, i løpet av det nåværende arbeidet, kan analytikeren skape artikler etter eget skjønn, i tilfelle et behov uten å vente på den samlede analysen. Også forberedelse av wiki-instruksjonen er innenfor rammen av utviklede forretningsprosjekter eller spesielt dedikerte dokumentasjonsprosjekter. Dette er ikke en sammenlastning, ikke samarbeid. Dette er fra topp til bunn med administrative metoder. Brukere deltar ikke i dette.

Spørsmålet fra hallen : En av kollegaene bruker et veldig interessant system. Jeg likte det, jeg vil implementere det selv. Den første linjen med teknisk støtte er alltid forpliktet til å lukke oppgaven fra Wiki. Og hvis hun ikke finner en artikkel i Wiki, adresserer hun den andre linjen med teknisk støtte. Og allerede den andre linjen skaper en artikkel som må monteres for en oppgave.

Svar :Vi, prøv også, men vi handler iterativt - sete, analysert, laget en rekke hendelser. Men det tar måneder. Så igjen - satte seg, analyserte, tildelte de nødvendige blokkene, gjorde en rekke hendelser.

Spørsmålet fra hallen : Ikke veldig klart - hvordan er gitintegrasjonen med Redmine?

Svar :Når du lagrer endringer i 1C-lagringen (når du beregner), angir beskrivelsen oppgavenummeret med "#" -taggen, for eksempel "# 74516". Dermed kommer vi gjennom regnskap - vi kan se hvilke komiteer i GIT-lagringen som er knyttet til oppgaven. Det var viktig for oss at dette er en stasjonær løsning slik at vi enkelt kan klare dem, og om nødvendig, gå til en annen løsning, fordi alle de samme behovene vokser, og ikke alle redminbehov kan dekkes. Derfor beklager jeg igjen - hvis du velger et produkt, analyser du først at du vil automatisere og som blokkerer "deksel".

Spørsmålet fra hallen : Brukte du mobilprogrammet fra Redmine?

Svar :Mobil applikasjon er, men det er ikke helt komfortabelt. I vår organisasjon er det ikke behov for det. Vi jobber hovedsakelig på en fasttelefon eller bærbar PC. Du kan også bruke plugins med informasjonskapasiteter - for eksempel ved hjelp av SMS eller med telegram.

Spørsmålet fra hallen : Du sa at du laster ut depotet i git, og hva ser du der i git?

Svar : I kommut git er det en lenke til oppgaven. Fra komiteen åpner vi selve oppgaven. Og fra problemet kan vi også åpne en commot forbundet med den. Til hvert prosjekt, uansett hva et hierarki er, kan du koble ditt depot. Selvfølgelig administreres integrasjonen med GIT ikke helt gjennom webgrensesnittet. Håndtak Det må fortsatt klatre, men raskt og enkelt.

Hva vi har til slutt:

Basert på ovenstående, oppsummerer vi de korte resultatene.

Fordeler:

  • Redmine - OpenSource-produkt med et stort og aktivt samfunn;
  • Det er projisert på kostnader, billig, fleksibel, tilpasset, lett integrert og skalerbar;
  • Helt dekker bug tracker, halvprosjektledelse, ganske mye - itsm;
  • Har integrasjon med git;
  • Castomizes "på fluen";
  • Den har et ganske bredt spekter av plugins. I tillegg er det lett å finne spesialister å automatisere sine prosesser;
  • Praktisk regnskapsføring av faktiske lønnskostnader. Muligheten for å planlegge arbeidskostnader og budsjetter.

Minuser:

  • Ubehagelig wiki;
  • Hvis du trenger å automatisere prosessene dine og i fravær av kompetanse på rubin på skinner, er bare bruk av plugins eller søk etter tredjepartsutviklere mulig;
  • Et lite antall analytiske rapporter;
  • Ikke alltid et "vennlig" grensesnitt;
  • Ubehagelige masse klassifikatorer som ønsker å lagre i form av et hierarki.

I ferd med å bruke Redmine-produktet har vi gjort en stor mengde arbeid på analysen, systematisering og automatisering av våre aktiviteter og en nedgang i kaos i våre strukturer. De gjorde en endring og optimalisering av prosesser både innenfor avdelingene og i forretningsprosesser i hele organisasjonen. Optimalisert og forbedret kontroll, analytiske og ledelsesmessige funksjoner i arbeidet med avdelinger og på designaktiviteter.

Ytterligere trinn som vi har tatt er å markere kunnskapsbasen i et mer praktisk konfluenseanlegg, fordi Muligheten for å jobbe sammen er en av hovedmekanismene i utviklingen av organisasjoner, lar deg raskt produsere kommunikasjon, redusere tiden for å overføre informasjon, redusere antall feil og tid for å løse hendelser.

I Redmin-delen vil det være flere trinn for å bygge klarere og kontrollerte forretningsprosesser.

Generelt, velg verktøyet, og la kaoset bli ubemerket.

****************

Denne artikkelen er skrevet på resultatene av rapporten som leses på Infostart Event 2017 Community Conference. Flere artikler finner du her.

I 2020 inviterer vi alle til å delta i 7 regionale tildelinger, samt jubileumet Infostart Event 2020 i Moskva.

Velg hendelse.

Redmin. - Åpne server webapplikasjon for prosjektledelse og oppgaver (inkludert feilsporing). Redmine er skrevet i Ruby og er en applikasjon basert på det kjente webrammen rubin på skinner. Fordelt i henhold til GNU General Public License.

Funksjonalitet

Dette produktet gir følgende funksjoner:

  • opprettholde flere prosjekter;
  • Fleksibelt rollebasert tilgangssystem;
  • feil sporing system;
  • Gantt og kalender diagrammer;
  • Prosjektnyheter, dokumenter og filstyring;
  • varsel om endringer ved hjelp av RSS-strømmer og e-post;
  • wiki for hvert prosjekt;
  • Forum for hvert prosjekt;
  • regnskapsføring av midlertidige kostnader;
  • Tilpassbare vilkårlig felt for hendelser, tidskostnader, prosjekter og brukere;
  • Enkel integrering med versjonskontrollsystemer (svn, CVS, GIT, Mercurial, Bazaar og Darcs);
  • Opprette feilrekorder basert på mottatte bokstaver;
  • Støtte for flere LDAP-godkjenning;
  • evnen til å registrere nye brukere uavhengig av hverandre;
  • flerspråklig grensesnitt (inkludert russisk);
  • Støtte for MySQL DBMS, PostgreSQL, SQLite, Oracle.

Databasestruktur

Brukersystemet

Brukere er et av de sentrale konseptene i fagområdet. Brukermodellen er grunnlaget for å identifisere og godkjenne systemet for personell og kunder, samt å autorisere dem i forskjellige roller, prosjekter, etc.

Rolle

Brukerroller bestemmes av en fleksibel modell for å bestemme brukerrettigheter. Roller inkluderer et sett med privilegier, slik at du kan skille tilgang til ulike systemfunksjoner.

Brukerne er tildelt en rolle i hvert prosjekt der det deltar, for eksempel "Manager i prosjektet for utviklingen av nettstedet A", "utvikler i prosjektet for å opprettholde selskapets intranettfirma" eller "klient i et refactor-prosjekt av informasjonssystemet i firmaet b ". Brukeren kan ha flere roller. Tilordne en rolle for en egen oppgave (problem) er for tiden umulig.

Prosjekter

Prosjektet er et av de grunnleggende konseptene i fagområdet for prosjektstyringssystemer. På grunn av denne enheten er det mulig å organisere samarbeid og planlegge flere prosjekter samtidig med avgrensningen av tilgang til ulike brukere (se ovenfor). Prosjekter innrømmer hierarkisk nesting.

Trackers.

Trackers er hovedklassifiseringen av hvilke oppgaver som er sortert i prosjektet. I seg selv går begrepet "tracker" tilbake til feilsøkingssystemer (ENG. Bugsporingsverktøy ), representert hvert eget prosjekt.

Faktisk er i "Redmin" -sporere en analog av klassen "Oppgave" -klassen og er grunnlaget for polymorfisme av ulike typer oppgaver, slik at forskjellige felt kan bestemmes for hver av dem. Eksempler på trackers er "forbedring", "feil", "dokumentasjon", "støtte",

Oppgaver

Oppgavene er det sentrale konseptet i hele systemet, som beskriver en bestemt oppgave du vil utføre. Hver oppgave har en obligatorisk beskrivelse og forfatteren, på obligatorisk, er oppgaven knyttet til trackeren.

Hver oppgave har status. Statuser er en egen enhet med muligheten for å bestemme rettighetene til å tilordne status for ulike roller (for eksempel statusen "avvist" kan bare tilordnes en leder) eller bestemme relevansen av oppgaven (for eksempel "Åpne", " utnevnt "- relevant, og" lukket "," avvist "- nei).

For hvert prosjekt er et sett med utviklingsstadier og et sett med oppgaverskategorier separat definert. Andre felt er også interessante for den "estimerte tiden", som fungerer som grunnlag for å bygge styringsdiagrammer, samt valgfeltet for observatører for oppgaven (se "Mottaksvarsler"). Oppgavene er i stand til å feste filer (det er en separat enhet "-program").

Verdiene av andre børsnoterte egenskaper (for eksempel prioritet) lagres i et eget felles bord.

Sporing av status for oppgaver

For å spore endringer i oppgaveparametrene av brukere, svarer systemet to enheter: "Opptak av en endringslogg og" Endret parameter ". Logginngangen viser en handling av brukeren for å redigere parametrene til oppgaven og / eller legge til en kommentar til den. Det vil si samtidig som et verktøy for å gjennomføre historien til oppgaven og et verktøy for vedlikehold av en dialog.

Enheten "endret parameter" er knyttet til en egen logginngang og er ment for å lagre den gamle og nye verdien av den bruker-endrede parameteren.

Kommunikasjon mellom oppgaver

Oppgaver kan samles inn: For eksempel er en oppgave en subtask for en annen eller foregå den. Denne informasjonen kan være nyttig i programutviklingsplanleggingen, en egen enhet er ansvarlig for lagring i Redmin.

Regnskap brukt på utkastet tid

Systemet opprettholder regnskapsføring av brukt tid på grunn av essensen av "brukt tid" forbundet med brukere og oppgaven. Essence lar deg lagre tid brukt, type brukeraktivitet (utvikling, design, støtte) og en kort kommentar på jobb. Disse dataene kan for eksempel brukes til å analysere bidraget til hver deltaker i prosjektet eller for å vurdere den faktiske arbeidsintensiteten og kostnaden for utvikling.

Bindende repositorier

Redmine gir integrering med ulike versjoner kontrollsystemer (repositories). Integrasjon er å spore endringer i det eksterne depotet, og fikse dem i databasen, analyse av endringer for å binde til visse oppgaver. I den informologiske strukturen til systemet for integrering med eksterne repositories, er tre enheter ansvarlige: "Repository", "Editors" og "Change". "Repository" er et prosjekt knyttet til et prosjekt som lagrer typen tilkoblet depot, beliggenheten og identifikasjonsdataene til brukeren.

"Editorial" er visningen av redaksjonen i depotet, og i tillegg til informasjonsfelt kan det knyttes til en bestemt oppgave (for dette du vil spesifisere i beskrivelsen av "refs #num" endringer, hvor num er oppgavenummeret), og til forfatteren-forfatter av redaksjonen. Entity "Change" er designet for å lagre listen over endrede (ekstra, eksterne, fordrevne, endrede) filer i hver utgave.

Mottak av varsler

Brukervarsler om endringer som oppstår på nettstedet utføres ved hjelp av essensen av "Observatører" Koble til brukere med objekter av ulike klasser (prosjekter, oppgaver, fora, etc.). I databasen lagres RSS-abonnementstasternøklene, slik at meldinger gjennom denne teknologien tillater meldinger sendes også med e-post.

Noen feil er Redmine

For den nye eldre versjonen må du gjøre det samme.Sjekk nøytralitet.

Diskusjonssiden må ha detaljer.

  • Administrere filer og dokumenter i Redmin er redusert til å legge til, slette og redigere dem. Du kan ikke administrere tilgangsrettigheter til alle filer eller individuelle dokumenter.
  • Det er ingen varsler om endrede dokumenter.
  • I Redmin, kan du ikke administrere tilgangsrettigheter på nivået på individuelle oppgavelementer. For eksempel, for øyeblikket, er det umulig å skjule estimater av arbeidet på et prosjekt eller informasjon om den brukte tiden.
  • I Redmine er alle tilleggsfelt tilgjengelige for alle brukere, alle prosjektdeltakere vil kunne se dem og endre dem. Denne begrensningen kan føre til vanskeligheter i nærvær av en inhomogen kommando når ledere og utviklere, og kunder har tilgang til prosjektet.
  • Redmine har ikke rett til å skille typer overganger i arbeidsflyten. For eksempel, nå er det umulig å indikere at når noen er ferdig med å korrigere feilen, må den velge en ansvarlig tester og bør spesifisere byggenummeret. Også du kan ikke skjule den interne korrespondansen mellom programmerere fra klienten.
  • I Redmin, vises den totale arbeidsintensiteten til oppgavene ikke i oppgavelisten, og i arbeidskrevende rapporter er det umulig å gjøre valg, inkludert i henhold til entreprenøren.

Chiliproject.

Som et resultat av det faktum at visjonen om noen brukere i forhold til prosjektet ble preget av visjonen til utviklernes leder, ble Forma Redmine kalt Chiliproject opprettet.

se også

Litteratur

  • 前田 剛 (gå maeda) 入門 Redmine Linux / Windows 対応. - 秀和 システム. - 226 s. - ISBN 978-4-7980-2137-9.
  • Gunther Popp. KonfigurationsManagement Mit Subversion, Maven und Redmine: Grundlagen für softwarearchitekten und entwickler. - 3. - Dpunkt.Verlag GmbH, 2009. - S. 362. - ISBN 9783898645218

Lenker

Redmin. [ɹɛdmɑɪn] - Åpne server webapplikasjon for prosjektledelse og oppgaver (inkludert feilsporing). Redmine er skrevet i Ruby og er en applikasjon basert på det kjente webrammen rubin på skinner. Fordelt i henhold til GNU General Public License.

Encyclopedic YouTube.

  • 1/4Visninger: 337.

    1.067.

    20 314.

    1 108.

  • Slik installerer du Redmine (Project Management) på Antsle

  • Mit redmin effizient mitarbeiter, projeke und aufgaben verwalten

  • Redmine - Herramienta de gestion de proyectos

  • [KUBE 42] Distribuere REDMINE i Kubernet Cluster

Innhold

Funksjonalitet

Dette produktet gir følgende funksjoner:

  • opprettholde flere prosjekter;
  • Fleksibelt rollebasert tilgangssystem;
  • feil sporing system;
  • Gantt og kalender diagrammer;
  • Prosjektnyheter, dokumenter og filstyring;
  • varsel om endringer ved hjelp av RSS-strømmer og e-post;
  • Forum for hvert prosjekt;
  • regnskapsføring av midlertidige kostnader;
  • Tilpassbare vilkårlig felt for hendelser, tidskostnader, prosjekter og brukere;
  • Enkel integrering med versjonskontrollsystemer (svn, CVS, GIT, Mercurial, Bazaar og Darcs);
  • Opprette feilrekorder basert på mottatte bokstaver;
  • Støtte for flere LDAP-godkjenning;
  • evnen til å registrere nye brukere uavhengig av hverandre;
  • flerspråklig grensesnitt (inkludert russisk);
  • Støtte DBMS MySQL, Microsoft SQL Server [2] , PostgreSQL, SQLite.

Databasestruktur

Brukersystemet

Brukere er et av de sentrale konseptene i fagområdet. Brukermodellen er grunnlaget for å identifisere og godkjenne systemet for personell og kunder, samt å autorisere dem i forskjellige roller, prosjekter, etc.

Rolle

Brukerroller bestemmes av en fleksibel modell for å bestemme brukerrettigheter. Roller inkluderer et sett med privilegier, slik at du kan skille tilgang til ulike systemfunksjoner.

Brukerne er tildelt en rolle i hvert prosjekt der det deltar, for eksempel "Manager i prosjektutviklingsprosjektet", "Utvikler i prosjektet for å opprettholde selskapets intranettfirma" eller "klient i et refactor-prosjekt av informasjonssystemet til Selskapet b ". Brukeren kan ha flere roller. Tilordne en rolle for en egen oppgave (problem) er for tiden umulig.

Prosjekter

Prosjektet er et av de grunnleggende konseptene i fagområdet for prosjektstyringssystemer. På grunn av denne essensen er det mulig å organisere fellesarbeid og planlegge flere prosjekter samtidig med avgrensningen av tilgang til ulike brukere (se ovenfor). Prosjekter tillater hierarkisk nesting.

Trackers.

Trackers er hovedklassifiseringen av hvilke oppgaver som er sortert i prosjektet. I seg selv går begrepet "tracker" tilbake til feilsøkingssystemer (ENG. Bugsporingsverktøy ), representert hvert eget prosjekt.

I hovedsak, i "Redmin", er sporene en analog av klassen "Problem" -klassen og er grunnlaget for en polymorfisme av ulike typer oppgaver, slik at du kan bestemme for hver av deres type ulike felt. Spackers er "forbedring "," Feil "," Dokumentasjon "," Støtte ".

Oppgaver

Oppgavene er det sentrale konseptet i hele systemet, som beskriver en bestemt oppgave du vil utføre. Hver oppgave har en obligatorisk beskrivelse og forfatteren, på obligatorisk, er oppgaven knyttet til trackeren.

Hver oppgave har status. Statuser er en egen enhet med muligheten for å bestemme rettighetene til å tilordne status for ulike roller (for eksempel statusen "avvist" kan bare tilordnes en leder) eller bestemmelse av relevansen av oppgaven (for eksempel "Åpne", "Utnevnt" - relevant, og "lukket", "avvist" - nei).

For hvert prosjekt er et sett med utviklingsstadier og et sett med oppgaverskategorier separat definert. Andre felt er også interessante for den "estimerte tiden", som fungerer som grunnlag for å bygge styringsdiagrammer, samt muligheten for valg av observatører for oppgaven (se "Mottaksvarsler"). Oppgavene er i stand til å feste filer (det er en separat enhet "-program").

Verdiene av andre børsnoterte egenskaper (for eksempel prioritet) lagres i et eget felles bord.

Spor endringen av oppgaveparametere

For å spore endringer i oppgaveparametrene av brukere, svarer to enheter i systemet: "Opptak av en endringslogg" og "byttbar parameter". Logginngangen viser en handling av brukeren for å redigere parametrene til oppgaven og / eller legge til en kommentar til den. Det vil si samtidig som et verktøy for å gjennomføre historien til oppgaven og et verktøy for vedlikehold av en dialog.

Enheten "endret parameter" er knyttet til en egen logginngang og er ment for å lagre den gamle og nye verdien av den bruker-endrede parameteren.

Kommunikasjon mellom oppgaver

Oppgaver kan samles inn: For eksempel er en oppgave en subtask for en annen eller foregå den. Denne informasjonen kan være nyttig i programutviklingsplanleggingen, en egen enhet er ansvarlig for lagring i Redmin.

Regnskap brukt på utkastet tid

Systemet støtter å ta hensyn til tid takket være essensen av "brukt tid" forbundet med brukere og oppgaven. Essence lar deg lagre tid brukt, type brukeraktivitet (utvikling, design, støtte) og en kort kommentar på jobb. Disse dataene kan for eksempel brukes for å analysere bidraget til hver deltaker i prosjektet eller for å vurdere den faktiske tidsbekreftelsen og kostnaden for utvikling.

Bindende repositorier

Redmine gir muligheten til å integrere med ulike versjoner kontrollsystemer (repositorier). Integrasjon er å spore endringer i det eksterne depotet, og fikse dem i databasen, analyse av endringer for å binde til visse oppgaver.

I den informologiske strukturen til systemet for integrering med eksterne repositorier, er tre enheter ansvarlige: depot, redaktører og endring.

  • Repository - Et prosjekt knyttet til enheten som lagrer typen tilkoblet depot, beliggenheten og identifikasjonsdataene til brukeren.
  • Redaksjonell - Vise redaksjonelt kontor i depotet, og i tillegg til informasjonsfelt, kan knyttes til en bestemt oppgave: Dette krever spesifiser i beskrivelsen av "Refs #num" endringer, hvor Num er oppgavenummeret), og til forfatteren forfatter av redaksjonen.
  • Endring - Lagrer en liste over endrede (ekstra, eksterne, fordrevne, modifiserte) filer i hver utgave.

Mottak av varsler

Brukervarsler om endringer som oppstår på nettstedet utføres ved hjelp av essensen av "Observatører" Koble til brukere med objekter av ulike klasser (prosjekter, oppgaver, fora, etc.). Databasen lagrer også tilgangstaster til RSS-abonnementet, slik at du For å motta varsler via denne teknologien, sendes også varsler ved hjelp av e-post.

Noen feil er Redmine

  • Administrere filer og dokumenter i Redmin er redusert til å legge til, slette og redigere dem. Du kan ikke administrere tilgangsrettigheter til alle filer eller individuelle dokumenter.
  • I Redmin, kan du ikke administrere tilgangsrettigheter på nivået på individuelle oppgavelementer. For eksempel, for øyeblikket, er det umulig å skjule estimater av arbeidstid på oppgaven. Men du kan bare gjøre flere felt som er synlige for brukere med definerte roller.
  • I Redmin, vises det generelle arbeidsavtalen på oppgavene ikke i oppgavelisten.
  • Det er ingen mulighet til å gi brukeren en rolle i hele systemet; For eksempel må "Project Office Manager" ha tilgang til alle prosjekter i systemet: for dette må du legge til en bruker med denne rollen til alle prosjekter.
  • Koble til GIT-depotet er kun mulig hvis Redmine, og depotet er på samme server.

Chiliproject.

Som et resultat av det faktum at visjonen om noen brukere i forhold til prosjektet ble preget av visjonen til utviklernes leder, ble Forma Redmine kalt Chiliproject opprettet. For tiden er dette prosjektet stengt.

se også

Notater

Litteratur

  • 前田 剛 (gå maeda). 入門 Redmine Linux / Windows 対応. - 秀和 システム. - 226 s. - ISBN 978-4-7980-2137-9.
  • Gunther Popp. KonfigurationsManagement Mit Subversion, Maven und Redmine: Grundlagen für softwarearchitekten und entwickler. - 3. - Dpunkt.Verlag GmbH, 2009. - P. 362. - ISBN 9783898645218.

Lenker

  • Offisiell side Redmine. (ENG.)
  • Android-klient for Redmine (ENG.)
  • Installere og konfigurere Redmine Bunter med perle, Ruby, Rails, PostgreSQL, Passasjer, Nginx
  • Installere og konfigurere Redmine Bunter med perle, Ruby, Rails, MySQL, Passasjer, Nginx (utilgjengelig link)
  • Opprette plugins for Redmine
  • RedMineApp - iPhone Application for Redmine
  • Redmine PM - Redmine Client for iPhone / iPad
  • Redmine å gå - Windows Phone Client for Redmine
  • Redminup er et sett med gratis og kommersielle plugin-moduler og temaer for Redmine.
  • RMClient er en klient for Windows, Mac, Linux, Commercial.
  • Sette livssyklusoppgavene
  • Løse ytelsesproblemer
  • Operasjonell planlegging i Redmine
  • Plugins Writing Guide
  • Detaljert installasjonsanvisning
  • Easy Redmine - Commercial Option
  • Designer Jetware Installer og virtuelle maskiner med Redmine

Denne siden ble sist redigert 3. mai 2021 kl 13:31.

  • - opprettholde flere prosjekter;
  • - Feilsøkingssystem;
  • - Varsler om endringer via e-post og RSS-feeder;
  • - tilpassbare oppgavestatuser;
  • - tilpassbare vilkårlig felt for oppgaver, tidskostnader, prosjekter og brukere;
  • - Regnskapsføring av tidskostnader (timer);
  • - Ganta diagrammer og kalender;
  • - Wiki for hvert prosjekt;
  • - Prosjektnyhetsstyring, filbehandling og dokumenter;
  • - Forum for hvert prosjekt;
  • - Flerspråklig grensesnitt, inkludert russisk;
  • - Enkel integrering med repositorier (svn, CVS, Git, Mercurial, Bazaar og Darcs);
  • - Tilgangseparasjonssystem basert på roller;
  • - Støtte for flere LDAP-godkjenning;
  • - Evnen til å registrere nye brukere uavhengig
  • - Utvidelse av funksjonaliteten til systemet ved å installere tillegg plugins ;
  • - Støtte DBMS: MySQL, PostgreSQL, SQLite, MS SQL Server (fra versjon 2.3).
  • Tenk på Redmine-systemet mer detaljert. Nedenfor er noen skjermbilder, på den første av dem - en liste over oppgaver i henhold til et av prosjektene.

    Oppgave-fanen lar deg se både de nåværende prosjektoppgavene (som standard) og tidligere lukkede oppgaver - kundeforespørsler er mulige.

    Gud du er min, jeg har konflikter!

    (filtre). Tilpassede spørsmål kan lagres for etterfølgende bruk av alle brukere av systemet.

    (Når du installerer avmerkingsboksen "Public" spørring) eller for bruk av brukeren som opprettet forespørselen. Etter å ha opprettet en forespørsel, kan du konfigurere listen over oppgaver i ett klikk,

    Før eller senere (sannsynligvis allerede under den første oppdateringen til den nye yngre versjonen), møter du konflikter for fusjoner. Under git-rebuasionen bruker det å begå en etter en og stopper hver gang bruken av forpliktelsen skjer med feil. I dette tilfellet, laget

    Å dra nytte av referansen med spørringen med "Lagrede spørringer" på sidepanelet til høyre.

    • Systemet implementerer mekanismene for sporing av oppgaver og abonnementer på oppgaver. For hver oppgave kan observatører tilordnes, etter at når statusen endres, parametrene til oppgaven, legger til nye kommentarer, filer til oppgaven, vil observatørbrukere motta de riktige e-postvarslene.
    • Alle systembrukere kan opprette nye oppgaver. For å legge til en ny oppgave i prosjektet, må du gå til kategorien Ny oppgave,
    • Velg oppgavesporet og fyll ut obligatorisk (*) og tilleggsutstyr (inkludert egendefinerte bruker). I feltet "Theme" er det kort formulert, men informativt betydningen av oppgaven (når du går til et annet felt ved å trykke på Tab-tasten, i tilfelle av en ekstra plugin, kan du søke etter oppføring av tema blant tidligere opprettede oppgaver). I feltet "Beskrivelse" angir feltet et detaljert innhold i oppgaven. For å forbedre lesbarheten av teksten, kan du bruke funksjonene til den innebygde webeditoren.
    • Oppgaven kan vedlegges filer, hvor maksimal størrelse er regulert av systemadministratoren.
    • Observatører kan kobles til oppgaven: For å opprette en oppgave, når du lager måltider til oppgaven, endrer du statusen til oppgaven, observatører vil motta passende meldinger til e-postadressen. Brukere kan også legge seg til som en observatør til en rimelig oppgave, som i oppgavekortet skal følges av "Følg" -lenken.

    Oppgavene i systemet kan sammenhenger: for eksempel er en av dem en subtask for en annen, foregående henne eller disse oppgavene er ganske enkelt relatert til hverandre.

    Git status.

    Redmine-systemet gir en separat enhet kalt "relaterte oppgaver". Beslektede oppgaver kan ha følgende typer lenker:

    Viser problemfiler.

    - "duplikater" - medarbeider oppgavene på en slik måte at lukking av en innebærer lukking av en annen oppgave;

    Sjekk hvilken av forpliktelsene som var en feil, finn ut hvorfor det var ment (meningsfulle forpliktelser vil hjelpe), korrigere filer, kommando

    - "relatert til" er bare en referanse til en annen oppgave. En slik lenke brukes til å demonstrere at disse oppgavene kombineres av ett mål eller andre vanlige attributter; - "Blokker" - viser at denne oppgaven må være ferdig før du starter arbeidet med en annen oppgave. I begge oppgavene kan du uavhengig endre prosentandelen av utførelsen, datoene, statusen, men med ett unntak: den låste oppgaven kan ikke lukkes til blokkeringsoppgaven er stengt. Men i den låste oppgaven er det imidlertid mulig å sette statusen "utført", beredskapen på 100%, selv om beredskapen til blokkeringsoppgaven etterlater mye å være ønsket; - "Precedes" - Angir prosedyren for å utføre oppgaver slik at denne oppgaven skal fullføres for n dager før starten av den tilknyttede. I det tilhørende oppgavekortet vil det ikke bare være en oppføring på binding, men endrer også timingen og slutten av oppgaven. Oppgaveens løpetid vil være lik datoen for det bundet problem, økt med antall dager som er angitt i bunten;

    Git add.

    - "Neste" - Angir prosedyren for å utføre oppgaver på en slik måte at denne oppgaven bare kan utføres etter den tilknyttede. Denne tilkoblingen er omvendt den forrige.

    Legg til hver korrigert fil når du er ferdig. Hvis konflikter er eliminert, kan du se endringene som vil bli løst ved hjelp av kommandoen

    Timing endres automatisk ikke i bindingen, men i den redigerbare oppgaven. Derfor må lenken "Neste" brukes, bare sørge for at oppgavene virkelig skal gå etter hverandre på et gitt tidsintervall mellom dem.

    Git diff -cached.

    Følgende bilder er viet til konfigurasjonen og administrasjonen av Redmine-systemet.

    . Så snart du vurderer resultatet tilfredsstillende, kan du fortsette å rebuas med laget

    Trackers spiller en viktig rolle i sporingsoppgaver. De er involvert i å bestemme vilkårene for overgangen av oppgaver fra en stat til en annen, tilgjengeligheten av felt.

    Git rebase --Continue.

    Tracker er en logisk sammenslutning av oppgaver i en gruppe i prosjektet, for eksempel eliminering av feilen, utviklingen av en ny funksjonalitet, etc. Tracker kan være

    Inkludert i ett, flere eller alle prosjekter.

    Redmine-brukere må inkluderes i en av rollegruppene, antall roller er ikke begrenset. Systemet gir to forhåndsdefinerte roller:

    Rollen som "anonym" - for uregistrerte brukere, rollen som "ikke-deltakende" - for registrert, men ikke inkludert i et brukerprosjekt.

Anonym kan ikke skape oppgaver.

Hver rolle er satt til å få tilgang til rettigheter til mulige handlinger med oppgaver, prosjekter, dokumenter, filer, wiki, fora, etc. Det er åpenbart det

Rollene til "prosjektleder" bør gis mer krefter, rollen som "utøver" - mindre, rollene til "ikke-deltakende" - enda mindre, rollene til "anonym" for å tillate minimumsmuligheter

I offentlige prosjekter, og i enkelte prosjekter, er alt forbudt. Deltakerne i systemrollen "Administrator" har ubegrenset rettigheter i hele systemet.

Avhengig av den valgte trackeren, kan hver oppgave passere gjennom bestemte stadier og ha forskjellige statuser.

Så, i eksemplet nedenfor for de opprettede trackers "feilsøkingen", "Engangsoppgave, ADHOC", "Ny utvikling" Maksimal full måte gjennom oppgavestatusene:

1. Ny -> 2. Distribuert -> 3. Analyse -> 4. I drift -> 5. Made -> 6. Godkjennelse av kunden -> 7. Lukket

Rollene til "prosjektleder", "Executive", "Kunde, medlem" ble opprettet. Siden prosjektleder er en administrator av prosjektet hans, så innenfor rammen av prosjektet hans kan flyttes til oppgaven med i forskjellige statuser. Utøveren av oppgaven eller kunden / deltakeren kan bare oversette oppgaven fra i visse statuser. På ethvert tidspunkt kan oppgaven bli kansellert (oversatt til statusen "avvist") som indikerer årsaken. .

Når du gjør endringer i oppgaven, endres i oppgavens status, legger du til kommentarer til alle brukerne som er involvert i oppgaven, kommer automatisk e-post.

For hvert par "rollesporing" er det en mulighet til å konfigurere synlighet, forpliktelsen til å fylle feltene (inkludert konfigurerbare felt) i oppgavekortet. Systemfelt

"Prosjekt", "Tracker", "Theme", "Priority", "Privat" (oppgave), er alltid pålagt å fylle. Konfigurere sekvensen av handlinger for en av parene "Roll - Tracker",

Sekvensinnstillinger kan kopieres for et annet par ("Kopier" -kobling).

I Redmine-systemet for oppgaver, brukere og andre enheter, kan du opprette et vilkårlig antall tilpassbare (egendefinerte) felt. Egendefinerte felt vil være

Vis i et oppgavekort i to kolonner etter området for forhåndsdefinerte systemfelt. Sorter bestemmer rekkefølgen på egendefinerte felt i oppgavekortet. Egendefinerte felt støtter følgende datatyper: String, lang tekst, heltall, ekte nummer, dato, liste for å velge en enkelt verdi, Liste for å velge flere verdier, lenke, bruker. Hvert egendefinert felt kan aktiveres i alle eller bare de angitte prosjektene, bruk de valgte sporene. Ved å definere et tilpasset felt, kan du umiddelbart installere Globale innstillinger er påkrevd og synlighet for roller, samt feltdeltakelse i brukerforespørsler (filtre) og søk. Programmet for administrering av servere og tjenester Redmine finner du som oppstart -> Bitnami Redmine Stack Group -> Redmine Manager Tool. Med denne administrative applikasjonen kan du administrere Redmine Services, Apache Web Server, MySQL Database Server.

Rapportering

Redmine-systemet gir et gantdiagram, og ved hjelp av ekstra plugins er det mulig å danne rapporter for å forstå statusen for prosjekter og oppgaver.

Kanskje en privat innsendelse av utviklere om formatene til disse rapportene vil ordne deg.

Likevel blir analytiske rapporter om prosjektoppgaver best opprettet basert på dataene som er eksportert til CSV-filen. For dette

I hovedmenyen til Redmine-systemet, velg "Prosjekter" -> "Alle prosjekter", følg linken "Vis alle oppgaver",

Til listen over oppgaver, bruk / avbryte de ønskede filtreringskriteriene og klikk på linken "Eksporter til csv" nederst til høyre under oppgavelisten.

På denne måten vil oppgavelisten bli lastet ut - problemene.CSV-filen.

Deretter må du åpne en ny MS Excel-bok, velg "Data" -> "Fra tekst" i hovedmenyen, angir banen til filproblemene.CSV, I dialogboksen Velg kodeside "1251: Cyrillic (Windows)", (Kanskje som et separatorsymbol, notert - "Annet", spesifiser symbolet | (vertikal egenskap)) og klikk på "Fullfør" -knappen. Data vil bli importert til Excel-filen mens du lagrer tilkoblingen til CSV-filen. På grunnlag av kildedatabellen må du opprette sammendragstabeller, diagrammer (markere tabellen / kolonnene, og velg deretter "Sett inn" -> "Sammendragstabell"). Det er mulig å sikre analytiske indikatorer i basisbordet, du må opprette flere beregnede kolonner.

Et eksempel på en rapport finnes i investeringen i denne artikkelen.

Redmine¶

Redmine er et fleksibelt prosjektledelses webapplikasjon. Skrevet med Ruby på Rails Framework, er det kryssplattform og tverrdatabase.

Redmin er åpen kildekode og utgitt i henhold til vilkårene i GNU General Public License V2 (GPL).

Funksjoner¶

Noen av hovedtrekkene i Redmine er:

Les mer om Redmine-funksjoner.

Dokumentasjon¶ .

Du kan lese

REDMINE GUIDE

Andre ressurser:

Online Demo¶ En delt online demo kan bli funnet på http://demo.redmine.org/. Det har blitt satt opp for å gi registrerte brukere muligheten til å lage egne prosjekter Dette betyr at når du registrerer deg, kan du opprette ditt eget prosjekt der og prøve prosjektadministrasjonsfunksjonene. Alternativt kan du få ditt eget Redmine Demo-miljø på http://m.redmine.org med fulladministratorrettigheter etter å ha fylt en enkel form.

Støtte og få hjelp¶

For å få hjelp eller diskutere Redmine, kan du bla gjennom

Redmine Forums. 

Hosted her i Redmine. Vi har også en Samtalerom. - Bli med #Redmin på Freenode IRC-nettverket. Det er også et uoffisielt arbeidsområde på

Slakk Hvor du kan stille spørsmål og delta i diskusjoner med andre Redmine-brukere. Før du sender en feilrapport, en oppdatering eller en funksjonsforespørsel her, vennligst les retningslinjene for innsending.

Bidrar og hjelper ut Redmine er bygget og vedlikeholdt av frivillige frivillige. Hvis du liker å bruke det og ønsker å gi tilbake til samfunnet, har den bidragsiden SEVEL-ideer. Programvareutviklingserfaring er ikke nødvendig. Sjekk ut lagsiden hvis du er interessert i et bestemt område for å bidra regelmessig. Du kan også gjøre en donasjon og bli oppført på siden Redmine Donors. Hvem bruker Redmine? ¶ Denne siden viser noen selskaper og prosjekter ved hjelp av Redmine. Redmine Books¶ Mastering Redmine 2nd Edition

Er en omfattende guide med tips, triks og beste praksis for bruk av Redmine.You kan kjøpe den på nettet.

Redmine plugin-utvidelse og utvikling Gir en oversikt over verktøyene som er tilgjengelige for utviklere som ønsker å forlenge Redmine til å jobbe seg. Du kan kjøpe den på nettet. Redmine Cookbook. Samtalerom. .

: Over 80 hands-on oppskrifter for å forbedre dine ferdigheter i prosjektledelse, teamforvaltning, prosessforbedring og Redmine Administration.Du kan kjøpe den på nettet. Redmine Books¶ Ansvarsfraskrivelse: Dette er ikke en vanlig typehåndbok "Slik installerer du Redmine". I den vil jeg ikke dykke inn i databaseninnstillingen eller installere webserveren. Jeg vil heller ikke snakke om å sette opp Redmine. Redmine dokumentasjon i denne planen er ganske komplett. Og i orden som ikke er nevnt i den offisielle dokumentasjonen, er det en generell prosedyre for å kjøre skinner applikasjoner som lett kan bli funnet på Internett.

I stedet vil det være i ferd med å være ledsaget av sin egen, mer eller mindre tilpassede versjon av Redmine, som kan distribueres ved hjelp av en shell-kommando når det er nødvendig. Klar? La oss da starte. Sett byggtypen "Alt-i-ett" og klar til å starte virtuelle maskiner Bitnami Installasjonspakker eller forhåndsinstallerte virtuelle maskiner er gode for den raske REDMINE-prøven, men er ikke egnet for produktiv bruk. Hvorfor? Fordi de ikke har noen oppdatering. Åh, et sekund, Bitnami har. Sant, det ser mer ut som en vits. "Installer den nye versjonen av hele stabelen til en annen katalog og flytt dataene dine der," Dette er ikke en oppdatering. Ikke et ord om å sette opp, tilpasning og plugins, som sannsynligvis også må lagres og installeres på nytt. Jeg ønsker lykke til med en slik "oppdatering". Reliza Redmine patches over eller to ganger i måneden. Korrigeringer av sikkerhetsrelaterte feil utstedes etter behov - du vil ikke savne dem?

Det faktum at folk ofte glemmer: Oppdateringstid er ikke alltid avhengig av deg. Selvfølgelig kan du utsette oppdateringen før utgivelsen av den neste yngre versjonen av Redmine - i noen uker (sannsynligvis enda i en lengre periode). Men du vil ikke oppdage nye sikkerhetsproblemer i Redmine eller Rails Sit med et nepostabelt system til det er mulig å frigjøre tiden for å installere og konfigurere den nye Bitnami-stakken og manuelt flytte alle dataene?

Installasjon er bare toppen av isfjellet. Oppdatering - dette er hva som må gjøre regelmessig 

Søket etter den enkleste installasjonsmetoden slutter definitivt å være relevant så snart vedtaket er gjort for å bruke Redmine i produksjon. Enkelt akkompagnement og muligheten for modernisering - dette er hva du trenger for å skarpere oppmerksomhet for å minimere kostnader og risiko knyttet til bruken av din egen Redmine.

  • Nedenfor vil jeg fortelle deg hvordan du bare skal støtte Redmine i den nåværende tilstanden. Redmine Books¶ .
  • Bruk git. Redmine Books¶ Selv om du har tenkt å kjøre lagerredemine uten noen innstillinger eller plugin-moduler, bruk GIT-depotet til å lagre Redmine Copy. I det minste vil tilstedeværelsen av et spesialisert arkiv gi deg lagringsplassen for alle nødvendige for distribusjon (senere vil dette bli vurdert som flere detaljer). Før eller senere du (eller dine brukere) Redmine er bygget og vedlikeholdt av frivillige frivillige. Hvis du liker å bruke det og ønsker å gi tilbake til samfunnet, har den bidragsiden SEVEL-ideer. Programvareutviklingserfaring er ikke nødvendig. Sjekk ut lagsiden hvis du er interessert i et bestemt område for å bidra regelmessig. .
  • VI VIL

Installer noe plugin eller skreddersydd emne, og for dette vil være klar infrastruktur. Eksperimenter med endringer og testing av plugins og de i lokale grener uten forstyrrelser i produksjonskoden blir veldig enkle i nærvær av eget GIT C Redmine-depot. Så nå begynner vi med konfigurasjonen av depotet. Selv om det viktigste Redmine-depotet er en forekomst av Subversion, har GitHub et semi-offisielt arkiv som støttes av hovedforpliktelsen og er kontinuerlig oppdatert. Bruk den til å konfigurere ditt eget depot: Sette opp Lokal Clone Redmine

$ Git clone [email protected]: Redmine / Redmine.Git $ CD Redmine $ Git Remote Rename Origin Upstream $ Git Remote Legg til opprinnelse [email protected]: Redmine.Git $ git Checkout -B Redmine / 3.2-stabil oppstrøms / 3.2 -Stable $ git Checkout -B Lokal / 3.2-stabil $ git push-set-upstream opprinnelse Lokal / 3.2-stabil

Endre versjonsnummeret 3.2-Stabil På nummeret på den siste stabile versjonen av Redmine.

Remote Repository

[email protected] 

Det skal være privat, da det vil lagre distribusjonskonfigurasjonen (og muligens annen informasjon, som ikke er verdt å publisere). Siden distribusjonsprosessen beskrevet nedenfor vil trekke ut koden fra dette depotet, må depotet være tilgjengelig under distribusjoner, så ikke plasser den på stasjonære datamaskiner. Idealet vil være situasjonen når depotet også vil være tilgjengelig fra en webserver som distribusjonen oppstår. Men dette, om nødvendig, kan du komme deg rundt. Nå har du to lokale grener: Redmine / 3.2-stabil Redmine er bygget og vedlikeholdt av frivillige frivillige. Hvis du liker å bruke det og ønsker å gi tilbake til samfunnet, har den bidragsiden SEVEL-ideer. Programvareutviklingserfaring er ikke nødvendig. Sjekk ut lagsiden hvis du er interessert i et bestemt område for å bidra regelmessig. и hvilke spor Redmine 3.2 uten ekstra funksjonalitet fra GitHub / Redmine-deporteret som presenteres av ovennevnte fjernkontroll stigende Redmine er bygget og vedlikeholdt av frivillige frivillige. Hvis du liker å bruke det og ønsker å gi tilbake til samfunnet, har den bidragsiden SEVEL-ideer. Programvareutviklingserfaring er ikke nødvendig. Sjekk ut lagsiden hvis du er interessert i et bestemt område for å bidra regelmessig. oppbevaringssted hvilke spor Redmine 3.2 uten ekstra funksjonalitet fra GitHub / Redmine-deporteret som presenteres av ovennevnte fjernkontroll Lokal / 3.2-stabil

Hvor alle innstillingene til distribusjonen, tilpasningen, temaene og pluginene vil bli plassert.

Avanserte oppdateringer av versjoner

Redmine bruker følgende versjon nummereringsskjema: XYZ Major / Minor / Patch. Hver yngre versjon har sin egen Stabil grenen I hvilke løsninger og sikkerhetsoppdateringer vil bli brukt over tid (så lenge denne versjonen fortsatt støttes). I vårt tilfelle er dette en gren

Fra tid til annen vil denne stigende grenen motta noen nye forpliktelser. Din oppgave er å inkludere nye forpliktelser i den lokale grenen For distribusjon. Selv om det er mulig og bare jevnlig utfyller den stigende grenen, foreslår jeg å bruke Git rebase. For å støtte ditt eget sett med endringer over .

lager redmin: REBUPPING LOKALE Endringer over "Naken" Redmine: $ Git kassa Redmine / 3.2-stabil $ git pull # Ny oppstrøms forpliktelser kommer i $ git kassen Lokal / 3.2-stabil $ git rebase redmin / 3.2-stabilt

Rebase:

Vil avbryte alle lokale endringer i

Lenker

  1. Oppdater
  2. å reflektere endringene som skjedde i
Hvis du uventet fikk en haug med konflikt, og det er ingen tid til å løse dette problemet, kan du bare forstyrre gjeldende rebuasion ved hjelp av parameteren

Alle lokale endringer på "Bare" -versjonen vil søke på nytt.

Redmin. Resultatet vil være Ren historie Der dine (lokale) forpliktelser alltid er på toppen av den siste (stigende) forplikter seg til Redmine.

Junior og eldre oppdateringer

Nå som det er en ny stabil gren (la oss si 3.3-Stabil ), gjør det samme - relorere endringene dine på toppen av den. Git-kommandoer vil være litt annerledes på grunn av endringen av den oppadgående grenen: Overføring av lokale endringer til en ny stabil gren $ Git hente oppstrøms $ git kassa -b redmin / 3.3-stabil oppstrøms / 3.3-stabil $ git Checkout -B Lokal / 3.3-stabil Lokal / 3.2-stabil $ git rebase --onto redmin / 3.3-stabil Redmine / 3.2-stabilt Lokal / 3.3-stabil Disse lagene lager først to nye lokale grener for versjon 3.3: en av de stigende, og den andre er fra den lokale grenen 3.2. Så flytter de lokale endringer over Redmine / 3.3-stabilt

. Lokale endringer her er forskjellen mellom

Lokal / 3.3-stabil (som fortsatt er ). Nå

Inneholder Redmine 3.3 pluss eventuelle lokale endringer.

Добавить комментарий