Redmine for it-ledelse: Praktisk erfaring Omfattende implementering OpenSource Systems

Lille forhistorie. Som du ved, begynder Automation altid med noget "muntert". Automatiser dig selv eller din ledelse, vi starter ikke fra et godt liv. Dette sker normalt, fordi organisationen vokser op, bliver det svært at navigere i en stor mængde indgående og tilgængelige oplysninger. Så vores organisation på et bestemt punkt begyndte at vokse hurtigt, så vi havde brug for meget hurtigt fra kaos til at gøre noget struktureret, nyttigt og praktisk.

Hvad betyder kaos i vores systemer? Det betyder, at ikke-bestilte anmodninger, der ikke er underlagt analyser og struktureringsanmodninger, kommer fra brugerne, og der er ingen projektledelse som sådan. Forespørgsler fryser et sted i posten, i Word, i lederne af analytikere, programmører, afdelingsledere - afhængigt af hvilken struktur der bruges i organisationen.

Vi besluttede at fjerne dit kaos ved hjælp af Redmine Software. Straks foretage en reservation, at vi ikke vil tale om metoden. Vi vil snakke nøjagtigt om mulighederne for Redmine, om, hvordan vi anvender det. Hvert firma har sine egne nuancer, tager os ikke til os, tag ikke andre. Gør din analyse, fungerer som du tror korrekt og nødvendigt for dig. Vær ikke bange for fejl, fordi vi på fejl, vi lærer.

Fra kaos, som vi havde, forsøger vi at flytte til ordre. Nu er vi midt på denne måde. Selvfølgelig var ikke alt og vil være skyløs og glat, men vi forsøger meget.

Inde i vores firma tildelte vi tre hovedproblemer:

  • For det første havde vi brug for et system til sporing af fejl, hændelser og indgående anmodninger, dvs. Vi var nødt til at automatisere Bug Tracker;
  • For det andet ønskede vi på en eller anden måde at tildele projektledelsen. Ikke helt overvåget af automatisering, hvilket indebærer brugen af ​​metoder og i det omfang det er nødvendigt at ske på udviklingsstadiet og med en slags fremtid. Derefter vil du se, hvordan vi bruger Redmine for dette, og hvor vi skal udvikle det videre;
  • For det tredje tildelte vi IT-servicekontrolenheden (ITSM) i et separat system, men også ikke fuldt ud. Vores afdeling tilbyder forskellige it-tjenester, der skal styres.

Derudover tildelte vi vores private problemer:

  • Dette gentager jeg, forskellige it-tjenester, fordi programmører lever deres liv, systemadministratorer, der er stadig en internet marketing afdeling og andre;
  • Hver har sin egen struktur og deres ønsker til styring af afdelingen. I alle afdelinger, forskellige metoder, tilgange, ledere og psykotyper - pålægger det sit aftryk til valget af systemet. Men det er nødvendigt at flytte med alle på samme tid og nå et mål - en bestemt rækkefølge i organisationen, tilgængeligheden af ​​information og prognose;
  • Derudover er der en anden KPI, som i alt beregnes af forskellige indikatorer;
  • For at udvikle sig yderligere, har vi brug for en yderligere analyse af de indkommende oplysninger, hvad der sker i afdelingerne og hvordan det afspejles i organisationen som helhed;
  • Vi skal kontrollere de interne budgetter, som vi indtaster eller oftest, ikke indtaster. De skal også på en eller anden måde analysere og administrere dem. Det er bedre at gøre alt dette i et enkelt system - især det er bekvemt for manualen.

Således tildelte vi tre systemer, som jeg gerne vil kombinere i en.

For hver af disse systemer er der en separat specialiseret software. Det er alle de velkendte automatiseringsprodukter, der har deres egne fordele og ulemper, så hvis du vælger systemet for dig selv, skal du overveje alt.

Ikke alle produkter er noteret på diaset, der er meget flere af dem, og ikke kun på det russiske marked, men også på vestlige. Men for os var et af kravene en russisk-talende grænseflade, fordi dette produkt ikke kun ville blive brugt programmører og systemadministratorer, der er mere eller mindre forståelige engelsk, men også almindelige brugere.

Hvor skal vi hen? Mange produkter. Krav til dem fra forskellige afdelinger og kontroller er forskellige. Vi vælger.

Som et resultat af analysen og valget, såvel som med indgivelse af Alexei Lustin, kom et redminprodukt, der dækker et bestemt område, til os. Lad os finde ud af, hvilken slags region det dækker?

Det dækker fuldstændigt Bug Tracker, som vi ønskede at køre i virksomheden. Dette er centraliseringen af ​​modtagelse af applikationer fra brugere og kunder på ethvert niveau. Det var det mest grundlæggende smertepunkt, som var nødvendigt for hurtigt at automatisere. Jeg tror, ​​at alle har dette problem, for som jeg allerede har sagt, kommer oplysningerne i forstyrret og bosætter sig på forskellige steder - i posten, i Word, i Excel eller Heads. Sådanne oplysninger er ikke underlagt analysering og opnåelse af konklusioner og resultater. Som et resultat viser det sig, at:

    • Informationskomponenten i vidensbasen, som kan analyseres og forstår, hvad der skal gøres næste, er fraværende. Dette sænker reaktionshastigheden og påvirker den uafbrudthed og kvalitet af arbejdet, hvorfra overskuddet er direkte afhængig af;
    • Øger "dykket" tid for nye medarbejdere til at arbejde sammen med virksomhedssystemer;
    • Manglende tolerance er også hver af egne - nogen uden et arbejdssystem kan ikke leve to minutter. Derfor spiller Bug Tracker en stor rolle, og på det tidspunkt blev problematikerne meget akut.

Redmine Project Management dækker halvdelen, fordi dette produkt ikke specialiserer sig i styring af projekter, men der er en bestemt blok, som hjælper i dette. Desværre er dette ikke et ideelt produkt, men på det tidspunkt dækkede han de krav, vi satte op til systemet.

Og en meget lille ITSM-blok er dækket. Redmine-systemet er ikke beregnet til at styre it-tjenester, så der er nogle fejl i ledende og strukturering af data. Vi er kommet ud af denne situation ved at vælge din version af ITSM-systemet.

Så vores valg er redmine. Det er ret tilpasset, skalerbart, fleksibelt og med bekvemme indstillinger.

Hvorfor redmin?

  • Dette er det søde ord "freebie". Redmine er dog gratis med reservationen, at der er betalte plugins, du vælger selv. Under alle omstændigheder har du en slags omkostningsprognose, for hvis du har købt et plugin og ikke ændrer Redmine-platformen, kan dette plugin i nogen tid bruges uden yderligere investeringer. Og hvis du for eksempel skal opdatere det, så betaler du for denne opdatering og bruger den yderligere. Redmine platform-opdateringen opstår en eller anden eller to om året og opdateret eller ej - dette er dit ønske.
  • Redmine har en intuitiv grænseflade. Vi har implementeret Redmin ikke kun som et produkt til it-styring, men også som et produkt, hvor applikationer fra brugere modtages for forskellige afdelinger. For eksempel fremhæves en separat gren til ansøgninger fra den administrative og økonomiske afdeling.
  • Det er muligt at kontrollere prioriteter i forskellige analytiske former, herunder individuelt efter opgaver.
  • Forvaltningstid og ressourcer. Jeg tror, ​​det er hovedenheden for hovedet. Det giver dig mulighed for at forstå, hvor meget afdelingen er lastet, med hvilke opgaver, hvilke omkostninger er relateret, og hvordan man klassificerer omkostningerne, men om det nedenfor.
  • Analytics og rapporter i Redmin er svagt udtrykt, men der er en omfattende API. Du kan tage data fra API-databasen, losse dem til dit system og få rapporter.
  • Fleksible indstillinger, tilpasning og automatisering af manuelle operationer med plugins.
  • Integration med GIT er en af ​​de vigtige indikatorer. Repositionen i vores database er forbundet til GITLAB, og i enhver redmin opgave kan du se logfiler (relaterede udgaver): Hvem, hvornår og hvad der er ændret i henhold til denne opgave, med overgangen til gitlab.

For information: GIT er et distribueret versionsstyringssystem. Det sporer, løser og gemmer oplysninger (versioner) om ændringer i eventuelle filer og mapper, og overvåger også dataintegriteten. I vores tilfælde taler vi om kildekoden 1c.

Dette er, hvad listen over relaterede udgaver ser ud:

  • Opgavehåndtering og fejlsporing. Dette er en standard bug tracker, som vi vil bruge.
  • Forvaltning af hændelser, projekter, budgetter. Alle budgetformation udføres på deres egen måde. Jeg vil vise, hvordan vi automatiserede det på dig selv, og du kan så forsøge at automatisere ledelsen af ​​budgettet i dig selv - jeg tror, ​​det vil være nemt, fordi der er arbejde i Redmine, og du kan også overføre dem til penge også.
  • Wiki i Redmin er ikke særlig godt implementeret, så det er bedre at bruge et andet produkt med det formål at skabe en videnbase og samarbejde. For mig selv valgte vi sammenflyvningssystemet fra Atlassian, hvilket er et af de mest almindelige og nemme at arbejde. Du kan også overveje systemer: Dokuwiki, MediaWiki og andre.

Hvad er Redmine under hætten?

  • Redmine meget hurtigt og udfolder sig bare.
  • Det virker på de fleste OS.
  • Den platform, som den er implementeret, er rubin på skinner. Hvis du vil tilpasse Redmine under os selv, skal du have en kompetence på Ruby på Rails, ellers vil det ikke være meget praktisk, fordi Ikke alt kan gøres færdige plugins.
  • Støtte til forskellige DBM'er taler for sig selv.
  • Med RSS eller e-mail kan du organisere advarsler om eventuelle begivenheder.
  • AD-godkendelse er tilgængelig.
  • Integration med SCM Version Control Systems (SVN, CVS, GIT, Mercurial, Bazaar og Darcs).

Mød Redmin

Du kan downloade Redmine, installere den på din computer og "eksperiment". Eller brug cloud-serveren, og "I et klik" for at sætte dig selv en forudinstalleret version af Redmin, som normalt er inkluderet i hosting-tjenesten.

Eksempler på installation til ethvert system, herunder brug af cloud service, findes på internettet. Officiel instruktion på linket:

Så ligner en liste over opgaver i Redmine.

Der er en standard og flere yderligere grænseflader. Sandt nok, når du ændrer grænseflader, kan nogle funktioner stoppe med at arbejde, fordi Brugerdefinerede grænseflader tager ikke højde for de plugins, som du vil arbejde på - det er trods alt et open source-produkt. Men det forhindrer ham ikke i at være et bekvemt værktøj, selv ved hjælp af standardgrænsefladen.

Administration er tildelt i en separat og ret forståelig struktur.

Listen over moduler, der er tilsluttet din Redmine, kan du altid se og analysere i den relevante administrationssektion.

Vi har ikke en "ren" redmin, fordi Der er omkring 35 plugins. Vi købte et par af dem.

Oplysninger om plugins findes i søgemaskinen efter søgeord "plugins til redmin". For eksempel er der to steder, hvor du kan downloade eller købe gode plugins for at begynde at arbejde med Redmin:

Alle plugins er russificeret, du kan købe og bruge. Det vigtigste er at vælge komfortable. Bare vær opmærksom på hvilken version af Redmin understøtter pluginet, fordi hvis den understøttede version ikke passer til din, er der en chance for, at plugin ikke virker.

Lidt om automatiseringen af ​​vores behov

Struktur "projekter"

Vi bruger Redmine ikke i henhold til standard lederskab. Som et eksempel inden for rammerne af systemet er begrebet "projekt" en separat gren i strukturens hierarki. Vi bruger "projekter" træet som en klassificering af niveauer. På øverste niveau er der en eksekutiv afdeling, han er underlagt tjentafdelinger, så følges systemer, delsystemer og tjenester.

En del af træet ser sådan ud:

Systemadministrationsafdelingen bruger også sin tilgang til projekternes hierarki. Arbejdet er bygget på baggrund af klassificeringen af ​​ydelser - det hjalp med at løse problemet med servicekontrollen. Derfor i ITSM-filialen er projekthierarkiet et forretningsservice katalog. For nemheds skyld er de nummereret.

Adgang til applikationer i Redmin

Ifølge eksemplet vil jeg fortælle dig, hvordan vi organiserede modtagelsen af ​​applikationer i Redmine.

Vores afdeling er opdelt i 3 grupper:

  • Udviklingsteam;
  • En gruppe af analytics og akkompagnement - her omfatter medarbejdere, der producerer niveauet af "to og en halv" støtte. De rådgiver, analyserer problemet, hvis det er nødvendigt, "Læs" -koden kan skrive anmodninger om dataanalyse samt korrekte fejl i koden. Som følge heraf klarer vi at udelukke distraktionen af ​​programmører fra små problemer, såvel som ved hjælp af analytikere, vi adskiller programmører fra kunder og tilbage, fordi Alt, sandsynligvis konfronteret problemerne med relationer mellem dem.
  • Og gruppe af administratorer af database 1c.

Så modtagelsen af ​​applikationer i Redmine med os gennemføres gennem skrivning af det sædvanlige brev på den fremhævede postkasse. For tilrettelæggelsen af ​​de enkelte postkasser tildelte vi i hver afdeling og i hver gruppe deres "projekter" -struktur, for eksempel:

For hvert af projekterne konfigurerede vi i HelpDesk-pluginet din postkasse. Screenshot viser indstillingerne for HelpDesk-pluginen for et af projekterne:

Bogstaver, der kommer ind i postkassen, der er knyttet til "Project", falder ind i vores system som applikationer med en visning af "Brugeranmodning". Alt dette fører til et fald i lønomkostninger medarbejdere til den primære klassificering af indgående anmodninger. (Eksempel i screenshot: 1.2 Administratorer 1c, 1.4 Tegnforstyrrende, 1,5 Støtte til Yurait DPP)

Hvis det er umuligt at producere et sådant udvalg af strukturen, er det helt muligt at vælge en postkasse og i træet for at oprette underordnede grene, hvor applikationerne vil blive distribueret til den første supportlinje efter den primære klassifikation (prøve screenshot : 1.3 Brugerstøtte).

Som følge heraf sender applikationen cyklen:

  • For det første sker den primære automatiske post i projektet;
  • Derefter distribuerer analytikeren ansøgningen, dvs. klassificerer, kategoriserer og prioriterer det;
  • Derefter overfører analytikeren applikationen til den ønskede gren.

I ansøgningen er der visse klassificeringsfelter, nogle af dem prætentisk, og delen tilføjes af os. I overensstemmelse hermed udføres den primære nødvendige påfyldning ved hjælp af parametre:

  • Prioritet;
  • Kategori;
  • Kundeafdeling;
  • Castom felter af forskellige typer.

De der. Hvis der opstår en hændelse, kan du være sikker på, at den ikke vil passere ubemærket.

Et eksempel på modtagne applikationer og felter, der anvendes:

Indstillinger "Project"

Inde i "Projektet" kan der være flere typer trackers. Her, for eksempel ofte brugte trackers:

  • Brugeranmodning;
  • En opgave;
  • Fejl;
  • Dømme;
  • Business Project;
  • Forretningsprogrammer mv.

Trackere kan være et ubegrænset antal - de kan tilføjes manuelt. Hver tracker er fleksibelt konfigureret.

I indstillingerne "Project" kan vi angive, hvilke trackers i den bruges, såvel som hvilke brugerdefinerede felter kan tilsluttes.

De nødvendige moduler og andre indstillinger er også forbundet til hver gren. Du kan finde dette i standard redmin dokumentation.

Når du har tilsluttet modulerne, behøver du ikke at producere komplekse manipulationer, du skal bare gemme listen over modulerne i det aktuelle "projekt", og de vises i form af faner, når du går, hvor du kan gøre det nødvendige Indstillinger.

Derudover er redminen meget fleksibelt konfigureret til at få adgang til forskellige niveauer både til "projektet" og på separate relaterede funktioner samt tilgængeligheden af ​​hvert felt.

På oversigtssiden "Projektet" kan du se alle former for trackers og statistikker over dem. Og også, når "falder ned" i trackeren, ser du underordnede af dette "projekt" af problemer - lad os kalde dem "kort".

Forretningsprojekter

Jeg gentager lidt. Siden i begreberne Redmine "-projektet" - dette er en gren af ​​strukturen i strukturen, så til opretholdelse af virkelige projekter tildelte vi en separat afdeling med "Business Project" og "Business Project Program" Trackers. Dette giver os mulighed for at holde statusrapporter om vores forretningsprojekter og formular omkostninger i form af distributionsbaser.

Strukturen af ​​denne gren er også opdelt i stavemåder på specifikationerne: afdeling, kunde, system, delsystemet.

Fordi Vores administrationsselskab, afdelinger centralt ledsage alle virksomheder inkluderet i Wiseadvice GK. I den henseende gennemfører vi projekter både individuelt for enhver virksomhed og fælles for flere virksomheder. Som følge heraf er for hvert projekt og opgaven at budgettere og skrive omkostningerne ved afdelinger.

I et Business Project Card kan du også konfigurere de nødvendige felter. Et eksempel på de felter, vi bruger:

  • Basisfordeling / omkostningsmodtager;
  • Bonus for projektet;
  • Evaluering af lønomkostninger
  • Start / færdiggørelsesdatoer planlagt;
  • Dagstatusrapport og andre.

Alle opgaver, der er oprettet i projektet, er underordnet hovedkortet i Business Project.

Statusrapporten overleveres til kunder mindst en gang om ugen. Hele historien akkumuleres på kortet og sendes til interesserede parter.

Kunden og andre interessenter kan til enhver tid se følgende oplysninger om forretningsprojektet:

  • Projektstatus;
  • Anslåede lønomkostninger;
  • Faktiske lønomkostninger er i øjeblikket i forbindelse med udførelse og medarbejdere;
  • Projektberedskab;
  • Formulering af et forretningsprojekt
  • Hele historien om korrespondance
  • Projektets planlægningsdato begyndte, hvis han blev udskudt på grund af prioritering;
  • Den planlagte dato for afslutning af projektet.

Faktiske lønomkostninger indsamles fra de underordnede forretningsprojektopgaver i tide brugt af afdelingerne i afdelingerne.

Baseret på de dannede opgaver, kan du opbygge et Ganta-diagram, men kun i en informativ version. Derudover er det umuligt at bruge det og interaktivt.

Når du arbejder med tidsplanen for kalenderplanlægning, kan du bruge grafiske rapporter. For eksempel:

Vi bruger opgavebrædder til at distribuere opgaver inden for ugentlig planlægning.

Alt dette er implementeret via plug-ins, som omfatter muligheden for at gennemføre Agile eller Kanban Boards.

Som et eksempel:

Under hensyntagen til pluginets egenskaber viser det sig som Kanban Board. Det kan interaktivt overstyret af pakkerne - både mellem status og mellem kunstnerne. På tre grænseflader blev kontrolleret - det virker kun på to. Standardgrænsefladen kører nøjagtigt. Meget praktisk at vise på et stort tv / skærm til planeter / rallies.

Planlægning kan også udføres ved hjælp af versioner og derefter konvertere versioner til udgivelser.

Som effektiviteten af ​​instituttets arbejde danner vi rapporter i forbindelse med omkostningerne ved distribution af omkostninger og faktiske arbejdsomkostninger for afdelinger.

Standard arbejdsrapporter kan skitseres:

Vi bruger hældningen af ​​rapporten om lønomkostninger:

  • Omkostningsdistributionsdatabase - vores brugerdefinerede felt;
  • Omkostningsmodtager - vores castom felt;
  • Brugeren er et standardfelt.

Dannelsen kan forekomme i sammenhæng med perioder:

For vores budgettering bruger vi kun "måneden". Rapporteksempel:

Screenshot præsenterer et eksempel med faktiske lønomkostninger i forbindelse med distributionsbasen for august.

Derudover kan du danne en detaljeret rapport for hver deklareret tidsværdi. Om nødvendigt konverteres alle rapporter til CSV, så yderligere analyse kan laves i Excel.

Og selvfølgelig kan vi som det sande 1C-kaldenavn skrive losseoplysninger fra Redmin i 1C for at danne din rapport i 1c med de nødvendige grupper og oplysninger.

Et eksempel på en af ​​omkostningsrapporterne:

Lidt mere om Redmine funktioner

Af de yderligere nyttige funktioner i Redmine vil jeg gerne fremhæve:

  • Authentication Mode - enten ved annonce eller ved login og adgangskode;

  • Alerts system. Brugeren vil blive underrettet om ændringer i opgaven. Du kan konfigurere e-mail-advarsler og RSS;

  • Kombinere brugere til grupper. Med dette værktøj kan du danne i Redmine Hierarchical Structure of the Enterprise. Der er plugins på integration med regnskabssystemet og kloning af strukturen i grupper;
  • Rollemodel højre, med flere multi-level opsætning;

  • Indstilling af arbejdsgangen (livscyklus) for hver tracker for hver rolle;

  • Tilstedeværelsen af ​​integration plugins med MS Outlook. For eksempel et ret bekvemt plugin med mange funktioner, såsom at skabe en applikation i Redmin direkte fra bogstavet, kommentar, sporing osv.; Officiel side:

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

  • Der er også plugins til at integrere med instant messaging systemer, såsom telegram og sms gateways. På en hvilken som helst kommunikationskanal kan du sende advarsler, såsom hændelser, overvågningsoplysninger mv.;
  • Hvis der er en kompetence, er det muligt at gøre plugins selv.

Spørgsmål - Svar:

Spørgsmål fra hallen : Antag, at vi har givet adgang til kunden, og vi har en vis liste over støttede tjenester til det. For eksempel, som i dit eksempel, er der tjenester af Sysadminov og Coder Services. Med en slags kunde arbejder vi på begge typer tjenester og med en slags kun en type. Er det muligt på niveauet af rettigheder for at begrænse, hvilken type tjeneste der er tilgængelig for kunden?

Svar: Dette varierer kun ved en separat gren, der er tildelt under kunden - "Projektet", hvor opgaver for udvalgte tjenester kan oprettes individuelt for denne kunde. Eller du bliver nødt til at give adgang til alle opgaver i filialen - "Projekt" -støtte til denne service. Standard evne til at begrænse rettighederne på tegn på tjenesten og kunden i "projektet" i Redmine "ud af boksen" er ikke. Du kan se efter et sådant plugin eller skrive det selv. Vi har ingen sådan kompleks struktur, men der er opgaver, der kun skal være tilgængelige for individuelle større enheder, så de er blevet oprettet for dem.

Spørgsmål fra hallen: Det viser sig, at hver kunde er et "projekt". Og inde i et "projekt" kan delprojects gøre?

Svar: Ja, så meget som du vil. Vi fremhæver for eksempel græsk til at adskille kundeafdelinger og give den der for at få det til at få adgang til de vigtigste medarbejdere, så de ikke ser hele HelpDesk, der er forbundet med kunden, og hele strukturen, fordi Hun er ret stor. Redmine fleksibel i indstillingerne, men desværre og i sin fleksibilitet er der begrænsninger, der leverer nogle ulejlighed. Selvfølgelig er der mere bekvemme højt specialiserede løsninger, men de betales.

Spørgsmål fra hallen : Og arbejdskraftomkostningerne på hver status opsummeres? For eksempel på statusen for "i arbejdet" sætter jeg arbejdskraftomkostningerne 0,3, og derefter på status for "analysen" indstillede jeg nogle flere lønomkostninger.

Svar : Større omkostninger går generelt for opgaven. Det er umuligt at klassificere lønomkostninger i henhold til status, men lønomkostningerne har et felt "aktiviteter", hvis essens kan afspejle den proces, hvor du skriver tid. Det er også redigeret. Når man skriver gennem lønomkostninger, vælger en medarbejder en type aktivitet, der er fastsat. Derefter kan du trække tiden tilbage i forbindelse med processerne.

Uden en angivelse af typen af ​​aktivitet kan rapporten kun formes af den samlede tid i forbindelse med medarbejderen + dag.

Sammendrag Analytiske data kan ses af rapporter. Direkte i opgaven er kun omkostningerne ved den aktuelle opgave synlig.

Spørgsmål fra hallen : Det viser sig, at jeg har den første linje med teknisk support og den anden linje af teknisk support. Hver af dem bruger på samme opgave i samme status "i arbejdet" på en bestemt tid. Derfor, hvordan kan jeg definere de faktiske lønomkostninger pr. Person på opgaven på første linje, på anden linje, på den tredje linje?

Svar : Jeg gentager, omkostningerne går generelt på opgaven, men hvis en person tilbragte så mange gange, og så brugt en anden person - dette afspejles her. Delvist blev svaret givet under det foregående spørgsmål. Så kan du se, hvilke af dem, hvor meget der har brugt, men kun i denne version. Der er kun ingen separate omkostninger, hvis du tilføjer brugerdefinerede felter for at afskrive arbejdskraftomkostninger eller bruge brugergrupperinger og yderligere danne analytiske rapporter.

Spørgsmål fra hallen : Hvordan organiseres brugerinteraktionen? Via e-mail?

Svar : Afsendelse går til et e-mail-standardbrev eller skrevet af brugeren eller en automatisk redminfold, hvis det er en observatør for denne opgave. Også, hvis han er en Redmine-bruger, viser toppanelet, hvor mange opgaver der er udnævnt til, hvor mange nye og hvor mange ændringer. Jeg ser nu, at jeg har 20 opgaver, hvoraf den ene er ny og en ændret. Fra brugerens side - kun e-mail.

Som beskrevet ovenfor, når du tilslutter plugins, kan du ensidigt underrette brugerne ved hjælp af Instant Messaging Systems.

Spørgsmål fra hallen : Er der en webgrænseflade til indsendelse af applikationer?

Svar : Ikke. Redmine arbejder på smartphones og tabletter, dvs. har en tilpasset grænseflade. Men applikationer kan enten indsendes via e-mail eller give adgang til brugeren direkte ind i systemet, hvilket begrænser det til rettigheder kun for at oprette. Som en ekstra funktion kan du sætte et plugin i Outlook for at oprette opgaver i Redmin.

I øjeblikket er der en Tracker Highter-plugin, som du kan begrænse adgangen til trackers i forbindelse med brugere eller roller.

Eksempel: Enhver bruger med "observatør" rolle i "projektet" er kun tilgængelige kort med "brugeranmodning" tracker.

Spørgsmål fra hallen : Og funktionaliteten af ​​at arbejde med e-mail er en af ​​kassen eller fra plugins?

Svar :Ja, det er "ud af boksen." Ved hjælp af plugins erhverver det simpelthen yderligere faciliteter og indstillinger.

Spørgsmål fra hallen : Og er det muligt at konfigurere, at meddelelsen af ​​kunden, som vi trådte ind i systemet, kun gik på en bestemt status. Hvorfor skulle han se vores interne ti faser, hvis han havde brug for meddelelse til at gå, når opgaven er afsluttet?

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

1. Først og fremmest handicappede vi for brugere-kunder standard Redmine-meddelelser i brugerindstillinger. Denne indstilling er global for al rødmin for den aktuelle bruger.

2. Yderligere for den krævede filial ("Project") forbundne muligheden for at sende breve.

3. Analytiker, eller RP-Shnik kan sende en e-mail ved hjælp af en standardmekanisme: Ved at trykke på "Send et note" -log i kortredigeringsfunktionen. Om nødvendigt kan du angive yderligere modtagere.

4. Afsenderen kan skrive enhver tekst og tilføje de nødvendige vedhæftede filer. Eller brug tidligere konfigurerede mønstre.

 

For at gøre dette vælges det færdige mønster, der er erstattet af brevet i brevet, og det forbliver kun at udfylde, om nødvendigt yderligere oplysninger.

Derefter skal du klikke på knappen "Accept", så kommentaren bliver gemt, og brevet vil blive sendt. Kunden modtager en meddelelse i form af et regelmæssigt brev.

Dette er en standard mekanisme, vi rørte ikke noget. Skabeloner til hvert projekt er tilpasset individ. Dette er en forholdsvis betydelig forenkling af analytikerkonsulenten, fordi hver gang du skriver den samme tekst - er det besværlig.

Skjul enhver tekst fra kunden, hvis den har adgang til ham direkte til opgavekort, er det kun muligt kun ved brug af en "privat" kommentar eller ved at slukke adgangen til denne type kommentarer.

Den anden mulighed er at bruge et ekstra plugin, fordi Som standard er der ingen sådan indstilling.

Spørgsmål fra hallen: Er det muligt at binde modparten til den modtagne opgave? For eksempel har jeg et telefonopkald med PBX, hvor modpartsnummeret er scoret, og Redmine tager det ankomne nummer fra PBX, skaber en opgave og undervist det til modparten. Har du løst opgaven med hierarkiet af modparter?

Svar: Nej, vi integrerede ikke Redmine med IP-telefoni, det var ikke vores mål. Ideen er god, men i vores specifikationer er det ikke nødvendigt. På internettet kan du finde Redmine Integration med Asterisk.

Spørgsmål fra hallen :Vi har et spørgsmål ikke på IP-telefoni, men på modparternes hierarki. Vi ønsker ledere at se det samme hierarki af modparter i Redmine som 1c.

Svar : Nej, kontaktstrukturen er flad. Det eneste, vi tilføjede, er et link til afdelingen. Maksimum, at vi bruger, samler kontakter af afdelinger, vi laver bug tracker til indenlandske tjenester og ikke for eksterne kunder. I Redmin selv er det umuligt at organisere et hierarki af modparter, men du kan knytte enheder i Redmine og 1C og danne denne rapport ud af 1c.

Spørgsmål fra hallen : Og hvor er dybden af ​​scrum? Vi har betingelsesmæssigt sprint - 7 kalenderdage (5 hverdage). Hvor kan jeg se, hvad er iteration af sprint? Hvad er kalenderugen, hvad er Sprint-nummeret?

Svar : Scrum Dybde kan styres af versioner. Der er en funktion af versioner.

Til dette er der en særlig sektion "operationel plan" (eller "version" afhængigt af grænsefladen).

Jeg har f.eks. Tre versioner.

 

Hver version kan have sit eget navn, status og begrænset til færdiggørelsesdatoen.

For hver version er opgavelisterne synlige, hvis de præsenteres, såvel som antallet af ufærdige.

For visualisering kan du danne diagrammer

Versioner kan grupperes, bryde opgaver, du kan bygge brædder efter dem. Du kan overføre opgaver mellem sprints - en sådan mulighed er i versionen "Planlægningsversioner".

Faktisk kan redmin være et redskab til at organisere arbejde på omfanget eller canbana. Det er dog nødvendigt at tage højde for, at nogle gange ikke er nok sortering og andre små ting for nemheds skyld. Måske er der plugins, der understøtter det. I det krævede volumen af ​​nuværende funktionalitet er der nok. Her kan du gøre opgaven af ​​opgaver, flytte mellem sprints, se, at du ikke havde tid til at gøre for den planlagte tid mv.

Spørgsmål fra hallen : Hvordan tager vi hensyn til de opgaver, der ikke blev opfyldt i den nuværende sprint? Skal jeg se det i status? Eller de på en eller anden måde vil jeg vise det, at de nu er nødvendige for at bestille en ny version?

Svar : Du kan vælge opgaven i henhold til versionen. For eksempel at se på "operationel plan", for hvor mange procent de er færdige og hvor opfyldt. Dem. Hvor mange opgaver er lukket fra Sprint og hvor meget der endnu ikke er lukket - det vil blive skrevet her. Når du klikker på det tilsvarende emne, er en liste over opgaver, der ikke er lukket, åbne. Desuden kan de som jeg sagde analyseres og overføres til en anden sprint.

Du kan også danne bestyrelser med opgaver, i overensstemmelse med de samme versioner og i forbindelse med statuser.

Og selvfølgelig brug standardlisten over opgaver med det nødvendige valg, som kan gemmes og bruges i permanent drift.

Spørgsmål fra hallen : Hvordan kan du overføre opgaven til en anden Sprint - jeg skal åbne en liste over opgaver på en fane, Kanban-Board på en anden og overføre?

Svar: Kunne være det. Men det er mere bekvemt at bruge versionsplanlægningsværktøjet. Vælg fra listen over unassignerede opgaver eller ufærdige opgaver af en bestemt version af den ønskede opgave og smid den til den næste version af musen - vis, at vi tager denne opgave i sprinten.

Spørgsmål fra hallen: Og hvordan kan du give alle de ulåste opgaver? Måske tre eller fire versioner tilbage havde jeg en form for vigtig opgave der. Jeg registrerede det, hun hænger der. Hvordan kan jeg ikke miste hende, så hun blev konstant hængt med mig? Så vidt jeg forstod, kan du kun se ikke-forbundne opgaver eller opgaver fra den valgte Sprint. Og hvordan man ser alle de ulåste opgaver med et kumulativt resultat, for at forstå, tage dem ind i den nuværende sprint eller ikke at tage?

Svar: Dette kan implementeres ved hjælp af filtrering i opgaver. Du kan foretage valgindstillinger i statusen "Åbn" med de nødvendige parametre og gemme.

 

For eksempel kan vi overveje indstillingen, som kaldes "opgaver til lukning". Der er opgaver med statusen "Løst", som blev implementeret af vores afdeling og overført til kunden til produktionsoperationen, men ingen feedback fra kunden har endnu ikke modtaget. De der. Dette er en pulje af opgaver, der skal kontrolleres for at præcisere resultaterne af produktionsudnyttelse og tæt på. For eksempel kan du ændre i statusfilterværdien "svarer til" og tegnet "Ny". Som følge heraf vil nye opgaver blive vist, der endnu ikke er taget til arbejde. Du kan variere status, prioriteterne, kategorierne, eventuelle værdier for både standard og brugerdefinerede felter.

For eksempel kan du tilføje et specielt brugerfelt til filteret. Dette er et bekvemt værktøj, meget enkelt. For projektet, for opgaven, til kontakt.

Nyt felt - Angiv den type objekt, hvor vi tilføjer, bruges oftest "opgaver".

Vi angiver feltformatet - muligheder, der er dækket et sted 90% af behovene.

Angiv navnet, hvordan vil rollerne være tilgængelige.

Vi angiver, hvilke projekter, som Trackers anvendes.

Spørgsmål fra hallen : Og brugerdefinerede felter kan gøres obligatorisk?

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

Obligatoriske felter er markeret med en rød stjerne til højre for navnet.

Spørgsmål fra hallen : Og hvordan har du rapporteret om udført arbejde? I samme opgave går til en anden bruger - der er en opgaveinitiator, og der er en performer.

Svar: Det er rigtigt, hvis feltet ændrer sig - til hvem det er tildelt, så i rapporten returnerer det den endelige værdi.

Lad mig fortælle dig, hvordan vi alle arrangeres. Delvist gentag.

  • Den vigtigste tracker for Service Desk er en "brugeranmodning", med hvilken posten er demonteret automatisk, og bogstaver bliver til "Brugeranmodninger". Hvis brugeren sendte et svarbrev til anmeldelse fra Redmin eller sendt et præciserende bogstav med det samme emne, vedtager derefter på emnet eller ID i emnet automatisk tekst fra et sådant bogstav til en eksisterende forespørgsel - en klassisk limfunktion anvendes.
  • Næste - når for eksempel en anmodning om rådgivning i KIS-afdelingen kom, demonterede Analytikerkonsulenter ansøgningen og producerer sin primære klassifikation. Bestem, at dette er en hændelse, fejl eller opgave. Det kan endda være en ide til et nyt projekt. Derfor er dette også en del af Service Desk. Efter klassifikationen fordeles alle "brugeranmodninger" til underprojects i ITAS-grenen, hvor yderligere arbejde allerede gøres med dem.
  • Hvis dette arbejde degenererer opgaven for udvikleren, oprettes den tilhørende underordnede "opgave" på baggrund af brugerens anmodning. Det vil sige, at "brugeranmodningen" tracker bor i sig selv, og opgavesporet er også adskilt. Vi taler om små ændringer og fejlkorrektioner, som vi har en separat strøm - de fremgår af "brugeranmodninger".
  • Hvis opgaven vedrører et bestemt forretningsprojekt, og udvikleren ikke gjorde det på grundlag af "brugeranmodningen", er det bundet til det underordnede forretningsprojekt til blokkene i Kisa's funktionalitet, så senere kunne opgaven ses - På hvilken blok og i forbindelse med hvilken vi gjorde - var det "brugeranmodning" eller et forretningsprojekt.
  • Separat lever Tracker "Business Project", som vi kommunikerer med virksomheden - ikke med brugerne på forespørgsel og mindre forfining, og allerede med reelle projekter, der bærer forretningsmæssig værdi. I "Business Project" som underordnede opgaver kan også være deres undertekster og endda pakker af opgaver - stort, med underordnet og forbindelser. Dette er sådan et mini-bevis. Alle disse undertekster er igen bundet til blokkene af funktionaliteten af ​​KIS.
  • Det er ligegyldigt, hvor opgaven kom fra - fra Service Desca eller fra et forretningsprojekt. Men vi binder alle dem til funktionalitetsblokkene.

Baseret på ovenstående gentager jeg, vi kan se lønomkostninger i sammenhængen:

  • Blokke af funktionalitet af kisa;
  • Projekter;
  • Kunstnere;
  • Kommunikation "Request - Opgaver / Business Project - Underordnet Trackers".

Screenshot præsenterer et eksempel med faktiske lønomkostninger i forbindelse med projekter for august om måneden. Medarbejdere skal distribuere deres faktisk brugt tid på de opgaver, de udførte. Dette kaldes tidsark. Vi har daglige udviklere indtaste de særlige optegnelser over "Arbejdsrapporter" og distribuere deres tid - Faktum er dannet. Således forvalter vi i det mindste omtrent faktisk projektets budget.

Vores projekter har en foreløbig arbejdsplan. Og i hvert projekt vi ser, vi overskredet det eller ej. Redmine opsummerer automatisk bredden af ​​alle opgaver underlagt projektet. Derfor ved vi, at dette projekt er tildelt 700 timer. Vi ser faktum - 617 timer er blevet udarbejdet. Dette er et af projektstyringselementerne.

Aktivitetsprocessen i systemet med hændelser kan repræsenteres som følger:

  • Analystkonsulenten udfører en analyse af den ønskede anmodning, om nødvendigt udgør en udviklingsopgave;
  • Udvikleren implementerer opgaven og returnerer sin analysekonsulent for at verificere og yderligere kommunikation;
  • Analystkonsulenten kommunikerer allerede efter anmodning fra brugeren med en beskrivelse af resultaterne;
  • Hvis alt er i orden, lukker analytikeren opgaven - udvikleren er forbudt at lukke opgaverne.

I flere store opgaver inkl. Design, processen er bygget mere udvidet:

Og selvfølgelig falder alle ændringer i arbejdsbasen gennem frigivelsen af ​​frigivelsen.

Hvis du sender det i en mere bekvem mulighed, så har vi vores egne "otte".

Dem., Virkelig mange opgaver overgår mellem ansvarlige, men det er ikke kritisk for os. Vi vurderer lønomkostninger i forbindelse med medarbejderne, omkostningerne ved distribution af omkostninger, kunder og i sjældne tilfælde i form af aktiviteter. Alt dette er allerede nævnt tidligere.

Spørgsmål fra hallen : Er det muligt at få oplysninger om, hvilke opgaver der har gjort en bestemt udvikler?

Svar : Der er. Der er et "arbejdsrapport" -værktøj, som du kan se, hvad en medarbejder til hvilken opgave hvor meget tid og hvilken dag jeg brugte.

Eller det kan ses af en standardrapport "Arbejdsomkostninger" - det kan også være dannet i forbindelse med brugere med afkodning.

Spørgsmål fra hallen : Og hvordan man spore dine lønomkostninger?

Svar: En medarbejder kontrollerer også deres arbejde gennem "Arbejdsrapporten". Og fikseringen af ​​lønomkostninger i opgaven udføres manuelt - enten direkte i opgaven eller i "arbejdsrapporten". Der er plugins, der giver dig mulighed for at holde styr på tid. For eksempel ser RedMine-problemet Timer-plugin sådan ud:

Når du begynder at arbejde på en opgave, klikker en medarbejder knappen "PLAY" og i slutningen - "PAUSE" -knappen. Ved opretholdelse af opgaven er lønomkostningerne fastsat i den.

Spørgsmål fra hallen : Spørgsmål til tidsstyring og ressourcer er postfactum management, der er allerede sket registreret, når jeg ser på, hvordan mine medarbejdere er blevet indlæst, eller er det muligt at planlægge? Når jeg ser det i morgen, skal min programmør tage opgaven med dette, og dagen efter i overmorgen dette. Og jeg forstår, at det konventionelt set er en stærk programmør, og han kan få rapporter uden problemer for to, tre pr. Dag til nitte, og jeg kan sætte en kø af opgaver i en uge.

Svar :Evnen til at planlægge er, men det er ikke perfekt - gratis produkt gør dine nuancer. Der er et felt på "planlagt tid", det er muligt at indstille dit brugerdefinerede felt, hvis du mangler et standardfelt ved at planlægge tid - hvor mange timers timer det vil bruge. Det er muligt at angive den planlagte tid og derefter sammenligne den planlagte og aktuelle tid. Og selvfølgelig kan du bruge Standard Story Points feltet til pokerplanlægning.

Spørgsmål fra hallen : Du sagde, at Wiki i Redmine ubehageligt.

Svar :Wiki i Redmin ser uvenlig ud.

 

For at formatere artikler og opgaver anvendes den markeringssprogmarken. Formatering er ikke "på flugt", men angiver markeringssymbolerne.

Søgningen er - i henhold til ordet inde i teksten og overskrifterne. Hvis du indtaster "Exchange" i søgningen, vil den give både temaer og trackers. Der er et valg efter type tracker.

Indholdsfortegnelsen er ikke hovedsiden, og når du indtaster Wiki, vises blot en liste over oprettede artikler.

Indholdsfortegnelsen er som følger:

Og selvfølgelig er Wiki i Redmine kun beregnet til lagring af artikler. Det kan ikke bruges til at samarbejde.

Historien om ændringen af ​​artikler udføres og kan findes, når, hvem og hvilken ændring produceres.

Spørgsmål fra hallen : Hvordan fylder wiki?

Svar : Vores proces er konstrueret som følger. Analyse af Service Desk udføres med en vis periodicitet i den forløbne periode. Ved hjælp af en indledende klassifikation, der blev foretaget af analytikere, når vi anmodede om en anmodning, forsøger vi at opsummere temaerne og identificere de mest problematiske zoner. Næste - Vi introducerer selvbetjening, dvs. Dokumentation af, hvordan brugeren selv kan løse sit problem eller spørgsmålet. Hertil kommer, at analytikeren under det nuværende arbejde kan oprette artikler efter eget skøn, hvis det er nødvendigt, uden at vente på den samlede analyse. Også forberedelse af WIKI-instruktionen er inden for rammerne af udviklede forretningsprojekter eller specielt dedikerede dokumentationsprojekter. Dette er ikke en sammenflydelse, ikke samarbejde. Dette er fra top til bund med administrative metoder. Brugere deltager ikke i dette.

Spørgsmål fra hallen : En af kollegerne bruger et meget interessant system. Jeg kunne virkelig godt lide det, jeg vil implementere det selv. Den første linje med teknisk support er altid forpligtet til at lukke opgaven fra Wiki. Og hvis hun ikke finder en artikel i WIKI, adresserer hun den anden linje med teknisk support. Og allerede den anden linje skaber en artikel, der skal monteres til en opgave.

Svar :Vi forsøger også det, men vi handler iterativt - Setels, analyseret, lavede en række arrangementer. Men det tager måneder. Så igen - satte sig ned, analyseret, tildelte de nødvendige blokke, lavede en række arrangementer.

Spørgsmål fra hallen : Ikke meget klar - hvordan er GIT-integrationen med Redmine?

Svar :Når du gemmer ændringer i 1C-oplagringen (ved beregning), angiver beskrivelsen taskenummeret med "#" -mærket, for eksempel "# 74516". Således kommer vi igennem regnskabsmæssige - vi kan se, hvilke udvalg i GIT-oplagringen er bundet til opgaven. Det var vigtigt for os, at dette er en desktop-løsning, så vi bekvemt kan administrere dem, og om nødvendigt gå til en anden løsning, fordi alle de samme behov vokser, og ikke alle redminbehov kan dækkes. Derfor undskylder jeg igen - hvis du vælger et produkt, skal du først analysere, at du vil automatisere, og som blokerer "Cover".

Spørgsmål fra hallen : Har du brugt mobilapplikationen fra Redmin?

Svar :Mobil applikation er, men det er ikke helt behageligt. I vores organisation er der ikke behov for det. Vi arbejder primært på en fastnetcomputer eller laptop. Du kan også bruge plugins med informationsfunktioner - for eksempel ved hjælp af SMS eller via telegram.

Spørgsmål fra hallen : Du sagde, at du losser depotet i giten, og hvad ser du der i git?

Svar : I Commut Git er der et link til opgaven. Fra udvalget åbner vi selve opgaven. Og fra problemet kan vi også åbne et kommode, der er forbundet med det. Til hvert projekt, uanset hvilket hierarki er, kan du forbinde dit depot. Selvfølgelig administreres integrationen med git ikke helt gennem webgrænsefladen. Håndtag der skal stadig klatre, men hurtigt og simpelt.

Hvad vi har i sidste ende:

Baseret på ovenstående vil vi opsummere de korte resultater.

Fordele:

  • Redmine - OpenSource-produkt med et stort og aktivt fællesskab;
  • Det forventes om omkostninger, billigt, fleksibelt, tilpasset, let integreret og skalerbar;
  • Helt dækker Bug Tracker, Half-Project Management, ganske lidt - ITSM;
  • Har integration med git;
  • Castomizes "på flugt";
  • Det har en temmelig bred vifte af plugins. Derudover er det nemt at finde specialister til at automatisere deres processer;
  • Bekvem regnskabelse af faktiske lønomkostninger. Muligheden for at planlægge arbejdskraftomkostninger og budgetter.

MINUSER:

  • Ubehageligt wiki;
  • Hvis du har brug for at automatisere dine processer og i mangel af kompetence på rubin på skinner, er kun brugen af ​​plugins eller søgning efter tredjepartsudviklere mulig;
  • Et lille antal analytiske rapporter;
  • Ikke altid en "venlig" grænseflade;
  • Ubehagelige masseklassifikatorer, der gerne vil opbevare i form af et hierarki.

I processen med at anvende Redmine-produktet har vi gjort en stor mængde arbejde på analysen, systematisering og automatisering af vores aktiviteter og et fald i kaos i vores strukturer. De foretog en ændring og optimering af processer både inden for afdelingerne og i forretningsprocesser i hele organisationen. Optimeret og forbedret kontrol, analytiske og ledelsesmæssige funktioner i afdelingernes arbejde og på designaktiviteter.

Yderligere skridt, vi har taget, er at fremhæve vidensbasen i et mere bekvemt konfluenssystem, fordi Muligheden for at arbejde sammen er en af ​​hovedmekanismerne i udviklingen af ​​organisationer, giver dig mulighed for hurtigt at producere kommunikation, reducere tiden for at overføre oplysninger, reducere antallet af fejl og tid til at løse hændelser.

I Redmine-delen vil der være yderligere skridt til at opbygge klarere og kontrollerede forretningsprocesser.

Vælg generelt værktøjet, og lad dit kaos blive ubemærket.

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

Denne artikel er skrevet om resultaterne af rapporten, der læses på Infostart Event 2017 Community Conference. Flere artikler kan findes her.

I 2020 inviterer vi alle til at deltage i 7 regionale tildelinger, såvel som jubilæet Infostart-arrangementet 2020 i Moskva.

Vælg begivenhed.

Redmine. - Åbn server webapplikation til projektstyring og opgaver (herunder fejlsporing). Redmine er skrevet i Ruby og er en applikation baseret på den velkendte webrammer rubin på skinner. Distribueret i henhold til GNU General Public License.

Funktionalitet

Dette produkt indeholder følgende funktioner:

  • opretholdelse af flere projekter
  • Fleksibelt rollebaseret adgangssystem;
  • Fejl sporingssystem;
  • Gantt og kalender diagrammer;
  • Projektnyheder, dokumenter og filhåndtering;
  • advarsel om ændringer ved hjælp af RSS-streams og e-mail;
  • Wiki for hvert projekt;
  • Fora for hvert projekt
  • regnskabelse af midlertidige omkostninger
  • Brugerdefinerede vilkårlige felter til hændelser, tidsomkostninger, projekter og brugere;
  • Nem integration med versioner Control Systems (SVN, CVS, GIT, Mercurial, Bazaar og Darcs);
  • Oprettelse af fejlregistre baseret på de modtagne bogstaver;
  • Støtte til flere LDAP-godkendelser;
  • evnen til selvstændigt at registrere nye brugere
  • Flersproget interface (herunder russisk);
  • Støtte til MySQL DBMS, PostgreSQL, SQLITE, Oracle.

Database struktur

Brugersystem

Brugere er et af de centrale begreber i fagområdet. Brugermodellen er grundlaget for at identificere og godkende systemet for personale og kunder, samt at godkende dem i forskellige roller, projekter mv.

Rolle

Brugerroller bestemmes af en fleksibel model til bestemmelse af brugeradgangsrettigheder. Roller omfatter et sæt privilegier, der giver mulighed for at skelne adgang til forskellige systemfunktioner.

Brugerne er tildelt en rolle i hvert projekt, hvor det deltager, for eksempel "Manager i projektet til udvikling af webstedet A", "udvikler i projektet for at opretholde virksomhedens intranetfirmaer" eller "klient i et refactorprojekt af informationssystemet i selskabet B ". Brugeren kan have flere roller. At tildele en rolle for en separat opgave (problem) er i øjeblikket umulig.

Projekter

Projektet er et af de grundlæggende begreber i fagområdet for projektledelsessystemer. På grund af denne enhed er det muligt at organisere samarbejde og planlægge flere projekter samtidigt med afgrænsning af adgang til forskellige brugere (se ovenfor). Projekter indrømmer hierarkisk nesting.

Trackers.

Trackers er den vigtigste klassifikation, hvormed opgaver er sorteret i projektet. I sig selv går begrebet "Tracker" tilbage til Fejlregnskabssystemer (ENG. Bug tracking værktøj ), repræsenterede hvert separat projekt.

Faktisk er i "Redmine" trackers en analog af klasse "opgave" -klassen og er grundlaget for polymorfisme af forskellige typer opgaver, så forskellige felter skal bestemmes for hver af dem. Eksempler på trackers er "forbedring", "fejl", "dokumentation", "support",

Opgaver.

Opgaverne er det centrale koncept for hele systemet, der beskriver en bestemt opgave, du vil udføre. Hver opgave har en obligatorisk beskrivelse og forfatteren, ved obligatorisk, er opgaven bundet til trackeren.

Hver opgave har status. Statusser er en separat enhed med muligheden for at bestemme rettighederne til at tildele status for forskellige roller (f.eks. Status "afvist" kan kun tildeles en leder) eller bestemme relevansen af ​​opgaven (for eksempel "åben", " Udnævnt "- relevant, og" lukket "," afvist "- nej).

For hvert projekt defineres et sæt udviklingsfaser og et sæt opgaver kategorier separat. Andre felter er også interessante for den "estimerede tid", som tjener som grundlag for bygningsstyringsdiagrammer, samt udvælgelsesfeltet for observatører til opgaven (se "Modtagelse af meddelelser"). Opgaverne er i stand til at vedhæfte filer (der er en separat enhed "applikation").

Værdierne for andre børsnoterede egenskaber (f.eks. Prioritet) opbevares i et separat fælles tabel.

Sporing af status for opgaver

For at spore ændringer i opgaveparametrene af brugerne, reagerer systemet to enheder: "Optagelse af en ændring log og" ændret parameter ". Logindtastningen viser en handling af brugeren for at redigere parametrene for opgaven og / eller tilføje en kommentar til den. Det er samtidig fungerer som et værktøj til at udføre opgavens historie og et værktøj til opretholdelse af en dialog.

Den enhed "ændret parameter" er bundet til en separat logindtastning og er beregnet til lagring af den gamle og nye værdi af den bruger-ændrede parameter.

Kommunikation mellem opgaver

Opgaver kan indbyrdes forbundne: For eksempel er en opgave en underopgave for en anden eller forud for den. Disse oplysninger kan være nyttige i programudviklingsplanlægningen, en separat enhed er ansvarlig for opbevaring i Redmin.

Regnskab brugt på udkastet til tid

Systemet opretholder regnskabsføring af den brugte tid på grund af essensen af ​​den "brugte tid", der er forbundet med brugere og opgaven. Essensen giver dig mulighed for at gemme den brugte tid, type brugeraktivitet (udvikling, design, support) og en kort kommentar på arbejde. Disse data kan f.eks. Anvendes til at analysere hver deltagers bidrag i projektet eller at vurdere den faktiske arbejdsintensitet og udviklingsomkostningerne.

Bindende repositorier

Redmine giver integration med forskellige versioner kontrolsystemer (repositories). Integration er at spore ændringer i det eksterne lager, fastsætte dem i databasen, analyse af ændringer for at binde til bestemte opgaver. I den infologiske struktur af systemet for integration med eksterne repositorier er tre enheder ansvarlige: "Repository", "Redaktion" og "Ændring". "Repository" er et projekt, der er forbundet med et projekt, der lagrer typen af ​​tilsluttet depot, dens placering og identifikationsdata for brugeren.

"Editorial" er visning af Redaktionsstyrelsen for depotet, og ud over informationsfelter kan være bundet til en bestemt opgave (for dette vil du angive i beskrivelsen af ​​"REFS #Num" -ændringer, hvor num er task nummeret) og til forfatterforfatteren af ​​redaktionen. Enheden "Ændring" er designet til at gemme listen over modificerede (tilføjede, fjernbetjente, forskudte, ændrede) filer i hver udgave.

Modtagelse af meddelelser.

Brugermeddelelser om ændringer, der opstår på webstedet, udføres ved hjælp af essensen af ​​"observatører", der forbinder brugere med genstande af forskellige klasser (projekter, opgaver, fora osv.). I databasen er RSS-abonnementsadgangstasterne også gemt, hvilket muliggør underretninger via denne teknologi, også meddelelser sendes ved hjælp af e-mail.

Nogle fejl redmine

For den nye ældre version skal du gøre det samme.Kontroller neutralitet.

Diskussionssiden skal have detaljer.

  • Håndtering af filer og dokumenter i Redmin reduceres til at tilføje, slette og redigere dem. Du kan ikke administrere adgangsrettigheder til eventuelle filer eller individuelle dokumenter.
  • Der er ingen advarsler om ændring af dokumenter.
  • I Redmine kan du ikke administrere adgangsrettigheder på niveauet for de enkelte opgavefelter. For eksempel er det i øjeblikket umuligt at skjule skøn over arbejdet på et projekt eller oplysninger om den brugte tid.
  • I Redmin er alle yderligere felter tilgængelige for alle brugere, alle projektdeltagere vil kunne se dem og ændre dem. Denne begrænsning kan føre til vanskeligheder i nærværelse af en inhomogen kommando, når ledere og udviklere, og kunder har adgang til projektet.
  • Redmine har ikke ret til at adskille typer af overgange i workflow. For eksempel er det nu umuligt at angive, at når nogen er færdig med at rette fejlen, skal den vælge en ansvarlig tester og skal angive byggens nummer. Du kan heller ikke skjule den interne korrespondance mellem programmører fra klienten.
  • I Redmine vises den samlede arbejdsintensitet af opgaver ikke i opgavelisten, og i arbejdskraftintensive rapporter er det umuligt at foretage udvælgelse, herunder ifølge entreprenøren.

Chiliproject.

Som følge af, at visionen om nogle brugere i forhold til projektet blev kendetegnet ved udgivelseslederens vision, blev forma-redminen kaldet chiliproject oprettet.

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. - DPUNT.VERlag GmbH, 2009. - P. 362. - ISBN 9783898645218

Links.

Redmine. [ɹɛdmɑɪn] - Åbn server webapplikation til projektstyring og opgaver (herunder fejlsporing). Redmine er skrevet i Ruby og er en applikation baseret på den velkendte webrammer rubin på skinner. Distribueret i henhold til GNU General Public License.

Encyclopedic YouTube.

  • 1/4Visninger: 337.

    1.067.

    20 314.

    1 108.

  • Sådan installeres Redmine (Project Management) på Antsle

  • Mit redmine effizient mitarbeiter, projektet und Aufgaben Verwalten

  • Redmine - Herramienta de Gestion de Proyectos

  • [Kube 42] Implementering af Redmine i Kubernetes Cluster

Indhold

Funktionalitet

Dette produkt indeholder følgende funktioner:

  • opretholdelse af flere projekter
  • Fleksibelt rollebaseret adgangssystem;
  • Fejl sporingssystem;
  • Gantt og kalender diagrammer;
  • Projektnyheder, dokumenter og filhåndtering;
  • advarsel om ændringer ved hjælp af RSS-streams og e-mail;
  • Fora for hvert projekt
  • regnskabelse af midlertidige omkostninger
  • Brugerdefinerede vilkårlige felter til hændelser, tidsomkostninger, projekter og brugere;
  • Nem integration med versioner Control Systems (SVN, CVS, GIT, Mercurial, Bazaar og Darcs);
  • Oprettelse af fejlregistre baseret på de modtagne bogstaver;
  • Støtte til flere LDAP-godkendelser;
  • evnen til selvstændigt at registrere nye brugere
  • Flersproget interface (herunder russisk);
  • Support DBMS MYSQL, Microsoft SQL Server [2] , PostgreSQL, SQLITE.

Database struktur

Brugersystem

Brugere er et af de centrale begreber i fagområdet. Brugermodellen er grundlaget for at identificere og godkende systemet for personale og kunder, samt at godkende dem i forskellige roller, projekter mv.

Rolle

Brugerroller bestemmes af en fleksibel model til bestemmelse af brugeradgangsrettigheder. Roller omfatter et sæt privilegier, der giver mulighed for at skelne adgang til forskellige systemfunktioner.

Brugerne er tildelt en rolle i hvert projekt, hvor det deltager, for eksempel "Manager i projektudviklingsprojektet", "udvikler i projektet for at opretholde virksomhedens intranetfirma" eller "klient i et refactorprojekt af informationssystemet af Virksomheden B ". Brugeren kan have flere roller. At tildele en rolle for en separat opgave (problem) er i øjeblikket umulig.

Projekter

Projektet er et af de grundlæggende begreber i fagområdet for projektledelsessystemer. På grund af denne essens er det muligt at organisere fælles arbejde og planlægge flere projekter samtidigt med afgrænsning af adgang til forskellige brugere (se ovenfor). Projekter tillader hierarkisk nestning.

Trackers.

Trackers er den vigtigste klassifikation, hvormed opgaver er sorteret i projektet. I sig selv går begrebet "Tracker" tilbage til Fejlregnskabssystemer (ENG. Bug tracking værktøj ), repræsenterede hvert separat projekt.

I det væsentlige, i "Redmine", er trackers en analog af klassens "problem" klasse og er grundlaget for en polymorfisme af forskellige typer opgaver, så du kan bestemme for hver af deres type forskellige felter. Trackerne er "forbedringer "," Fejl "," Dokumentation "," Support ".

Opgaver.

Opgaverne er det centrale koncept for hele systemet, der beskriver en bestemt opgave, du vil udføre. Hver opgave har en obligatorisk beskrivelse og forfatteren, ved obligatorisk, er opgaven bundet til trackeren.

Hver opgave har status. Statusser er en separat enhed med muligheden for at bestemme rettighederne til at tildele status for forskellige roller (f.eks. Status "Afvist" kan kun tildeles en leder) eller bestemmelse af opgaven af ​​opgaven (for eksempel "åben", "Udnævnt" - relevant, og "lukket", "afvist" - nej).

For hvert projekt defineres et sæt udviklingsfaser og et sæt opgaver kategorier separat. Andre felter er også også interessante for den "estimerede tid", som tjener som grundlag for opbygning af ledelsesdiagrammer, samt valg af observatører til opgaven (se "Modtagelse af meddelelser"). Opgaverne er i stand til at vedhæfte filer (der er en separat enhed "applikation").

Værdierne for andre børsnoterede egenskaber (f.eks. Prioritet) opbevares i et separat fælles tabel.

Spor ændringen af ​​opgaveparametre

For at spore ændringer i opgaveparametrene af brugerne svarer to enheder i systemet: "Optagelse af en ændring log" og "udskiftelig parameter". Logindtastningen viser en handling af brugeren for at redigere parametrene for opgaven og / eller tilføje en kommentar til den. Det er samtidig fungerer som et værktøj til at udføre opgavens historie og et værktøj til opretholdelse af en dialog.

Den enhed "ændret parameter" er bundet til en separat logindtastning og er beregnet til lagring af den gamle og nye værdi af den bruger-ændrede parameter.

Kommunikation mellem opgaver

Opgaver kan indbyrdes forbundne: For eksempel er en opgave en underopgave for en anden eller forud for den. Disse oplysninger kan være nyttige i programudviklingsplanlægningen, en separat enhed er ansvarlig for opbevaring i Redmin.

Regnskab brugt på udkastet til tid

Systemet understøtter, at der tages hensyn til essensen af ​​den "brugte tid", der er forbundet med brugere og opgaven. Essensen giver dig mulighed for at gemme den brugte tid, type brugeraktivitet (udvikling, design, support) og en kort kommentar på arbejde. Disse data kan f.eks. Anvendes til at analysere hver deltagers bidrag i projektet eller at vurdere den faktiske tid på grund af udviklingsomkostningerne.

Bindende repositorier

Redmine giver mulighed for at integrere med forskellige versioner kontrolsystemer (repositories). Integration er at spore ændringer i det eksterne lager, fastsætte dem i databasen, analyse af ændringer for at binde til bestemte opgaver.

I den infologiske struktur af systemet for integration med eksterne repositorier er tre enheder ansvarlige: depot, redaktører og forandring.

  • Repository - et projekt, der er knyttet til den enhed, der lagrer typen af ​​tilsluttet depot, dens placering og identifikationsdata for brugeren.
  • EDITORIAL - Viser Redaktionskontoret for depotet, og ud over informationsfelter kan være bundet til en bestemt opgave: Dette kræver, at der i beskrivelsen af ​​"REFS #Num" ændres, hvor num er opgavetummeret), og til forfatterforfatteren af ​​redaktionen.
  • Ændring - Gemmer en liste over modificerede (tilføjet, fjernbetjente, forskudte, ændrede) filer i hver udgave.

Modtagelse af meddelelser.

Brugermeddelelser om ændringer, der opstår på webstedet, udføres ved hjælp af essensen af ​​"observatører", der forbinder brugere med genstande af forskellige klasser (projekter, opgaver, fora osv.). Databasen gemmer også adgangstaster til RSS-abonnementet, så du kan tillade dig For at modtage meddelelser via denne teknologi sendes også meddelelser ved hjælp af e-mail.

Nogle fejl redmine

  • Håndtering af filer og dokumenter i Redmin reduceres til at tilføje, slette og redigere dem. Du kan ikke administrere adgangsrettigheder til eventuelle filer eller individuelle dokumenter.
  • I Redmine kan du ikke administrere adgangsrettigheder på niveauet for de enkelte opgavefelter. For eksempel er det i øjeblikket umuligt at skjule estimater af arbejdstid på opgaven. Men du kan kun gøre yderligere felter synlige for brugere med definerede roller.
  • I Redmine vises ikke den samlede arbejdskraft overvejelse af opgaver i opgavelisten.
  • Der er ingen mulighed for at give brugeren en rolle i hele systemet; For eksempel skal "Project Office Manager" få adgang til alle projekter i systemet: For dette skal du tilføje en bruger med denne rolle til alle projekter.
  • Tilslut GIT-depotet er kun muligt, hvis Redmin, og depotet er på samme server.

Chiliproject.

Som følge af, at visionen om nogle brugere i forhold til projektet blev kendetegnet ved udgivelseslederens vision, blev forma-redminen kaldet chiliproject oprettet. I øjeblikket er dette projekt lukket.

se også

Noter.

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. - DPUNT.VERlag GmbH, 2009. - P. 362. - ISBN 9783898645218.

Links.

  • Officielle site redmine (Eng.)
  • Android Client til Redmin (Eng.)
  • Installation og konfiguration af redminbundter med perle, rubin, skinner, postgreesql, passagerer, nginx
  • Installation og konfiguration af redminbundter med perle, rubin, skinner, mysql, passagerer, nginx (utilgængeligt link)
  • Oprettelse af plugins til redmin
  • RedMineApp - iPhone ansøgning til redmin
  • Redmine PM - Redmine Client til iPhone / iPad
  • Redmine to Go - Windows Phone Client til Redmine
  • Redmineup er et sæt gratis og kommercielle plug-ins og temaer til redmin.
  • RMClient er en klient til Windows, Mac, Linux, Commercial.
  • Indstilling af livscyklusopgaver
  • Løsning af præstationsproblemer
  • Driftsplanlægning i Redmine
  • Plugins Writing Guide.
  • Detaljeret installationsvejledning
  • Easy Redmine - Commercial Option
  • Designer Jetware Installars og Virtual Machines med Redmin

Denne side blev senest redigeret den 3. maj 2021 kl. 13:31.

  • - opretholdelse af flere projekter
  • - Fejl sporingssystem
  • - Advarsler om ændringer via e-mail og RSS-feeds;
  • - Brugerdefinerede opgavestatus
  • - tilpassede vilkårlige felter til opgaver, tidsomkostninger, projekter og brugere
  • - regnskabelse af tidsomkostninger (timer)
  • - Ganta-diagrammer og kalender;
  • - Wiki for hvert projekt
  • - Projekthyhedsforvaltning, filhåndtering og dokumenter;
  • - fora for hvert projekt
  • - flersproget interface, herunder russisk
  • - nem integration med repositorier (SVN, CVS, GIT, Mercurial, Bazaar og Darcs);
  • - Adgang separationssystem baseret på roller
  • - støtte til flere LDAP-godkendelser
  • - evnen til selvstændigt at registrere nye brugere
  • - Udvidelse af systemets funktionalitet ved at installere yderligere plugins. ;
  • - Support DBMS: MySQL, PostgreSQL, SQLITE, MS SQL Server (fra version 2.3).
  • Overvej Redmine-systemet mere detaljeret. Nedenfor er nogle screenshots, på den første af dem - en liste over opgaver i henhold til et af projekterne.

    TASK TAB giver dig mulighed for at se både de aktuelle projektopgaver (som standard) og tidligere lukkede opgaver - kundeforespørgsler er mulige.

    Gud du er min, jeg har konflikter!

    (filtre). Brugerdefinerede forespørgsler kan gemmes for efterfølgende brug af alle brugere af systemet.

    (Når du installerer afkrydsningsfeltet "Offentlig" forespørgsel) eller til brug for brugeren, der oprettede anmodningen. Når du har oprettet en forespørgsel, kan du konfigurere listen over opgaver i et enkelt klik,

    Før eller senere (sandsynligvis allerede under den første opdatering til den nye yngre version) vil du støde på konflikter af fusioner. Under GIT Rebuasion, bruger den på en efter en og stopper hver gang brugen af ​​tilsagnen forekommer med fejl. I dette tilfælde holdet holdet

    Udnyttelse af referencen med forespørgslen ved de "gemte forespørgsler" på sidepanelet til højre.

    • Systemet implementerer mekanismerne til sporing af opgaver og abonnementer på opgaver. For hver opgave kan observatører tildeles, hvorefter som status ændres, parametrene for opgaven, tilføjer nye kommentarer, filer til opgaven, vil observatørbrugerne modtage de relevante e-mail-meddelelser.
    • Alle systembrugere kan oprette nye opgaver. For at tilføje en ny opgave til projektet skal du gå til fanen Ny opgave,
    • Vælg Task Tracker og udfyld obligatorisk (*) og yderligere (inklusive brugerdefinerede bruger) Taskfelter. På feltet "Tema" er det kort formuleret, men informativt betydningen af ​​opgaven (når du går til et andet felt ved at trykke på TAB-tasten, kan du i forbindelse med en ekstra plugin søge efter indgangen til emne blandt tidligere oprettede opgaver). I feltet "Beskrivelse" angiver et detaljeret indhold af opgaven. For at forbedre læsbarheden af ​​teksten kan du bruge funktionerne i den indbyggede webeditor.
    • Opgaven kan vedhæftes filer, hvis maksimumstørrelse er reguleret af systemadministratoren.
    • Observatører kan tilsluttes opgaven: For at oprette en opgave, skal observatører ændre passende meddelelser til deres e-mail-adresse, når du laver måltider til opgaven. Brugere kan også tilføje sig som observatør til en overkommelig opgave, for hvilken i opgavekortet skal efterfølges af linket "Følg".

    Opgaverne i systemet kan indbyrdes forbundne: For eksempel er en af ​​dem en underopgave til en anden, forud for hende, eller disse opgaver er simpelthen relateret til hinanden.

    Git status.

    Redmine-systemet giver en separat enhed kaldet "relaterede opgaver". Relaterede opgaver kan have følgende typer af links:

    Viser problemfiler.

    - "duplikater" - associerer opgaverne på en sådan måde, at afslutningen af ​​en medfører afslutningen af ​​en anden opgave

    Kontroller, hvilken af ​​de begår, der har gjort en fejl, find ud af, hvorfor det var beregnet (meningsfuldt begå meddelelser vil hjælpe), korrekte filer, kommando

    - "Relateret til" er blot en henvisning til en anden opgave. Et sådant link bruges til at demonstrere, at disse opgaver kombineres med et mål eller andre fælles attributter; - "Blokke" - viser, at denne opgave skal udfyldes, inden arbejdet på en anden opgave begynder. I begge opgaver kan du selvstændigt ændre procentdelen af ​​udførelse, datoer, status, men med en undtagelse: Den låste opgave kan ikke lukkes, før blokeringsopgaven er lukket. Men i den låste opgave er det muligt at indstille statusen "udført", beredskabet på 100%, selvom beredskabet af blokeringsopgaven efterlader meget at ønske; - "Forudder" - Indstiller proceduren for udførelse af opgaver, så denne opgave skal udfyldes for n dage før starten af ​​den tilknyttede. I det tilhørende opgavekort vil det ikke kun være en post på bindende, men også automatisk ændre timingen og slutningen af ​​opgaven. Tillæget for opgaven vil svare til datoen for det bundet problem, steget med antallet af dage, der er angivet i bundtet;

    Git tilføjelse

    - "Næste" - Indstiller proceduren for udførelse af opgaver på en sådan måde, at denne opgave kun kan udføres efter den tilhørende. Denne forbindelse er omvendt den forrige.

    Tilføj hver korrigeret fil, når du er færdig. Hvis konflikter er blevet elimineret, kan du se de ændringer, der skal løses ved hjælp af kommandoen

    Timing ændres automatisk ikke i bindingen, men i den redigerbare opgave. Derfor skal linket "næste" bruges, kun sørge for, at opgaverne virkelig skal gå efter hinanden på et givet tidsinterval mellem dem.

    Git diff -cached

    Følgende billeder er afsat til konfigurationen og administrationen af ​​Redmine-systemet.

    . Så snart du overvejer resultatet tilfredsstillende, kan du fortsætte med at genopbygge med holdet

    Trackers spiller en vigtig rolle i sporingsopgaver. De er involveret i at bestemme betingelserne for overgangen af ​​opgaver fra en stat til en anden, tilgængeligheden af ​​felter.

    Git Rebase - Fortsæt.

    Tracker er en logisk sammenslutning af opgaver i en gruppe inden for projektet, for eksempel eliminering af fejlen, udviklingen af ​​en ny funktionalitet mv. Tracker kan være

    Inkluderet i en, flere eller alle projekter.

    Redmine-brugere skal indgå i en af ​​rollegrupperne, antallet af roller er ikke begrænset. Systemet giver to foruddefinerede roller:

    Rollen som "Anonymous" - for uregistrerede brugere, rollen som "ikke-deltagende" - for registreret, men ikke medtaget i ethvert brugerprojekt.

Anonym kan ikke oprette opgaver.

Hver rolle er indstillet til at få adgang til rettigheder til mulige handlinger med opgaver, projekter, dokumenter, filer, wiki, fora osv. Det er indlysende at

Rollerne "Project Manager" bør gives flere beføjelser, rollen som "performer" - mindre, rollerne ", ikke-deltagende" - endnu mindre, rollerne "Anonymous" for at tillade minimumsmuligheder

I offentlige projekter, og i individuelle projekter, er alt forbudt. Deltagerne i systemrollen "Administrator" har ubegrænsede rettigheder i hele systemet.

Afhængigt af den valgte tracker kan hver opgave passere gennem visse faser og have forskellige statuser.

Så i eksemplet nedenfor for de oprettede trackers "Fejlfinding", "engangsopgave, adhoc", "ny udvikling" maksimal fuld måde gennem opgavestatus:

1. Ny -> 2. Distribueret -> 3. Analyse -> 4. I drift -> 5. Lavet -> 6. Godkendelse af kunden -> 7. Lukket

Rollerne "Project Manager", "Executive", "Kunde, medlem" blev oprettet. Da projektlederen er en administrator af sit projekt, kan der inden for rammerne af hans projekt flyttes til opgaven med forskellige statuser. Opretten af ​​opgaven eller kunden / deltageren kan kun oversætte opgaven fra visse statuser. På ethvert tidspunkt kan opgaven annulleres (oversat til status "afvist"), der angiver årsagen. .

Når du foretager ændringer i opgaven, ændres der i opgavens status, tilføjer kommentarer til alle de bruger, der er involveret i opgaven, automatisk e-mail.

For hvert par "rolle - tracker" er der mulighed for at konfigurere synlighed, forpligtelsen til at udfylde felterne (herunder konfigurerbare felter) i opgavekortet. Systemfelter.

"Projekt", "Tracker", "tema", "prioritet", "Private" (Opgave) er altid forpligtet til at udfylde. Konfiguration af sekvensen af ​​handlinger for en af ​​parerne "rolle - tracker",

Sekvensindstillinger kan kopieres til et andet par ("Kopier" link).

I Redmine-systemet for opgaver, brugere og andre enheder kan du oprette et vilkårligt antal tilpassede (brugerdefinerede) felter. Brugerdefinerede felter vil være

Vis i et opgavekort i to kolonner efter området for foruddefinerede systemfelter. Sorter bestemmer rækkefølgen af ​​brugerdefinerede felter i opgavekortet. Brugerdefinerede felter understøtter følgende datatyper: String, Long Text, Integer, Real Number, Date, List for at vælge en enkelt værdi, Liste til valg af flere værdier, link, bruger. Hvert brugerdefineret felt kan aktiveres i alle eller kun de angivne projekter, brug de valgte trackers. Ved at definere et brugerdefineret felt kan du straks installere Globale indstillinger er påkrævet og synlighed for roller, samt feltdeltagelse i brugerforespørgsler (filtre) og søgeforespørgsler. Programmet til styring af servere og servicesredsmine kan findes som opstart -> BITNAMI REDMINE Stack Group -> Redmine Manager-værktøj. Med denne administrative ansøgning kan du administrere Redmine Services, Apache Web Server, MySQL Database Server.

Rapportering

Redmine-systemet giver et gant diagram, og ved hjælp af yderligere plugins er det muligt at danne rapporter for at forstå status for projekter og opgaver.

Måske vil en privat indsendelse af udviklere om formaterne af disse rapporter arrangere dig.

Ikke desto mindre er analytiske rapporter om projektopgaver bedst oprettet baseret på de data, der eksporteres til CSV-filen. For det

I hovedmenuen i Redmine-systemet skal du vælge "Projekter" -> "Alle projekter", følg linket "Se alle opgaver",

Til listen over opgaver skal du anvende / annullere de ønskede filtreringskriterier og klikke på linket "Eksporter til CSV" nederst til højre under opgavelisten.

På denne måde vil opgavelisten blive losset - Emissions.CSV-filen.

Derefter skal du åbne en ny MS Excel-bog, vælge "DATA" -> "Fra tekst" I hovedmenuen skal du angive stien til filproblemerne.csv, I dialogboksen Vælg kode side "1251: Cyrillic (Windows)", (Måske som et separator symbol, bemærket - "Andet", angiv symbolet | (lodret træk)) og klik på knappen "Afslut". Data vil blive importeret til Excel-fil, mens du gemmer forbindelsen til CSV-filen. På baggrund af kildedatatabellen skal du oprette sammendragstabeller, diagrammer (fremhæve tabellen / kolonnerne og derefter vælge "Indsæt" -> "Sammendragstabel"). Det er muligt at sikre analytiske indikatorer i bundbordet, du skal oprette yderligere beregnede kolonner.

Et eksempel på en rapport findes i investeringen til denne artikel.

Redmine¶

Redmine er en fleksibel projektstyring webapplikation. SKRIFTET BRUG AF RUBY ON RAILS RAMME, DET ER KRAFTPLATODE OG CROSS-DATABASE.

Redmine er åben kilde og frigives under betingelserne i GNU General Public License V2 (GPL).

Funktioner¶

Nogle af de vigtigste træk ved Redmine er:

Læs mere om Redmine-funktioner.

Dokumentation¶ .

Du kan læse

Redmine Guide.

Andre ressourcer:

Online Demo¶ En delt online demo kan findes på http://demo.redmine.org/. Det har været opsat for at give registrerede brugere evnen til at oprette deres egne projekter Det betyder, når du registrerer dig, du kan oprette dit eget projekt der og afprøve projektadministrationsfunktionerne. Alternativt kan du få dit eget Redmine Demo-miljø på http://m.redmine.org med fuld administratorrettigheder efter at have udfyldt en simpel formular.

Support & Få Hjælp¶

For at få hjælp eller diskutere Redmine, kan du gennemse

Redmine Forums. 

Hosted lige her i Redmine. Vi har også en Chatrum. - Tilmeld dig #redmin på FreeNode IRC-netværket. Der er også et uofficielt arbejdsområde på

Slack. Hvor du kan stille spørgsmål og deltage i diskussioner med andre redminbrugere. Før du sender en fejlrapport, en patch eller en funktionsanmodning her, skal du læse indsendelsesretningslinjerne.

Bidrager og hjælper ud Redmine er bygget og vedligeholdt af fællesskabsfrivillige. Hvis du nyder at bruge det og gerne vil give tilbage til samfundet, har den bidragsside Sevel Idéer. Softwareudvikling erfaring er ikke påkrævet. Tjek holdesiden, hvis du er interesseret i et bestemt område til at bidrage regelmæssigt. Du kan også lave en donation og blive opført på Redmine Donors Page. Hvem bruger Redmine? ¶ Denne side viser nogle virksomheder og projekter, der bruger Redmin. Redmine Books¶ Mastering Redmine 2nd Edition

Er en omfattende guide med tips, tricks og bedste praksis til at bruge Redmine.Du kan købe det online.

Redmine plugin forlængelse og udvikling Giver et overblik over de værktøjer, der er tilgængelige for udviklere, der ønsker at udvide Redmin til at arbejde deres vej. Du kan købe det online. Redmine kogebog. Chatrum. .

: Over 80 hands-on opskrifter for at forbedre dine færdigheder i projektledelse, teamstyring, procesforbedring og Redmine Administration. Du kan købe det online. Redmine Books¶ Ansvarsfraskrivelse: Dette er ikke en almindelig type guide "Sådan installeres Redmine". I det vil jeg ikke dykke ind i databaseindstillingen eller installere webserveren. Jeg vil også ikke tale om at oprette Redmine. Redmine dokumentation i denne plan er ret komplet. Og for ikke at nævnes i den officielle dokumentation, er der en generel procedure for løbeskinnerapplikationer, der nemt kan findes på internettet.

I stedet vil det være ved at blive ledsaget af sin egen, mere eller mindre tilpasset version af Redmine, som kan implementeres ved hjælp af en shell-kommando, når det er nødvendigt. Parat? Så lad os starte. Indstil byggetype "all-in-one" og klar til at starte virtuelle maskiner BITNAMI Installationspakker eller forudinstallerede virtuelle maskiner er gode til den hurtige redminprøve, men er ikke egnet til produktiv brug. Hvorfor? Fordi de ikke har nogen opdatering. Åh, et sekund, bitnami har. Sandt nok ser det mere ud som en vittighed. "Installer den nye version af hele stakken til en anden mappe og flyt dine data der," Dette er ikke en opdatering. Ikke et ord om opsætning, tilpasning og plugins, som sandsynligvis også skal gemmes og geninstalleres. Jeg ønsker held og lykke med en sådan "opdatering". Reliza Redmine patches over eller to gange om måneden. Korrektioner af sikkerhedsrelaterede fejl udstedes efter behov - du vil ikke savne dem?

Det faktum, at folk ofte glemmer: Opdateringstid afhænger ikke altid af dig. Selvfølgelig kan du udskyde opdateringen før frigivelsen af ​​den næste yngre version af Redminen - i et par uger (sandsynligvis selv i længere tid). Men du ønsker ikke at opdage nye sikkerhedsproblemer i Redmin eller Rails sidde med et nepostabil system, indtil det er muligt at frigive tiden til at installere og konfigurere den nye Bitnami Stack og manuelt flytte alle dataene?

Installation er kun toppen af ​​isbjerget. Opdatering - det er det, der skal gøre regelmæssigt 

Søgningen efter den enkleste installationsmetode ophører helt sikkert til at være relevant, så snart beslutningen er truffet for at anvende rødmin i produktionen. Enkelt akkompagnement og muligheden for modernisering - det er det, du har brug for for at skærpe opmærksomheden på at minimere omkostninger og risici forbundet med brugen af ​​din egen redmin.

  • Nedenfor vil jeg fortælle dig, hvordan du simpelthen understøtter redminen i den aktuelle tilstand. Redmine Books¶ .
  • Brug git. Redmine Books¶ Selvom du har til hensigt at køre Stock Redmine uden nogen indstillinger eller plug-ins, skal du bruge GIT-repository til at gemme Redmine Copy. I det mindste vil tilstedeværelsen af ​​et specialiseret lager give dig plads til opbevaring af alt nødvendigt for implementering (senere vil dette blive betragtet som flere detaljer). Før eller senere (eller dine brugere) Redmine er bygget og vedligeholdt af fællesskabsfrivillige. Hvis du nyder at bruge det og gerne vil give tilbage til samfundet, har den bidragsside Sevel Idéer. Softwareudvikling erfaring er ikke påkrævet. Tjek holdesiden, hvis du er interesseret i et bestemt område til at bidrage regelmæssigt. .
  • GODT

Installer noget plugin eller specialfremstillet emne, og for dette vil være klar infrastruktur. Eksperimenter med ændringer og test af plugins og dem i lokale grene uden lidelser i produktionskoden bliver meget enkle i nærvær af det eget git C Redmine Repository. Så nu starter vi med konferencens konfiguration. Selvom det vigtigste redminrepository er en forekomst af subversion, har Github et semi-officielt lager, der understøttes af hovedkomiteen og opdateres løbende. Brug den til at konfigurere dit eget depot: Opsætning af lokal klon redmin

$ Git klon [email protected]: redmine / redmine.git $ cd redmine $ git remote Rename oprindelse opstrøms $ git remote Tilføj oprindelse [email protected]: redmine.git $ git checkout -b redmine / 3.2-stabilt opstrøms / 3.2 -Stabile $ git checkout -b lokal / 3.2-stabilt $ git push --set-upstream Oprindelse Lokal / 3.2-Stabil

Skift versionsnummeret 3.2-Stabil På nummeret på den sidste stabile version af Redmin.

Remote Repository.

[email protected] 

Det skal være privat, da det vil gemme implementeringskonfigurationen (og muligvis andre oplysninger, som ikke er værd at udgive). Da implementeringsprocessen beskrevet nedenfor vil udtrække koden fra dette depot, skal depotet være tilgængeligt under implementeringer, så læg ikke det på stationære computere. Idealet vil være situationen, når depotet også vil være tilgængeligt fra en webserver, hvorpå implementeringen opstår. Men det kan om nødvendigt komme rundt. Nu har du to lokale grene: Redmine / 3.2-stabilt Redmine er bygget og vedligeholdt af fællesskabsfrivillige. Hvis du nyder at bruge det og gerne vil give tilbage til samfundet, har den bidragsside Sevel Idéer. Softwareudvikling erfaring er ikke påkrævet. Tjek holdesiden, hvis du er interesseret i et bestemt område til at bidrage regelmæssigt. и som sporer Redmin 3.2 uden yderligere funktionalitet fra Github / Redmine Repository præsenteret af ovenstående fjernbetjening stigende Redmine er bygget og vedligeholdt af fællesskabsfrivillige. Hvis du nyder at bruge det og gerne vil give tilbage til samfundet, har den bidragsside Sevel Idéer. Softwareudvikling erfaring er ikke påkrævet. Tjek holdesiden, hvis du er interesseret i et bestemt område til at bidrage regelmæssigt. Repository. som sporer Redmin 3.2 uden yderligere funktionalitet fra Github / Redmine Repository præsenteret af ovenstående fjernbetjening Lokal / 3.2-stabilt

Hvor alle indstillingerne for implementeringen, tilpasning, temaer og plugins vil blive placeret.

Avancerede opdateringer af versioner

Redmine bruger følgende versionsnummereringsordning: XYZ Major / Minor / Patch. Hver yngre version har sin egen Stabil Branch. I hvilke rettelser og sikkerhed patches vil blive anvendt over tid (så længe denne version stadig understøttes). I vores tilfælde er dette en filial

Fra tid til anden vil denne stigende filial modtage nogle nye forpligtelser. Din opgave er at inkludere nye forpligtelser i den lokale afdeling Til implementering. Selvom det er muligt og bare regelmæssigt supplerer den stigende filial, foreslår jeg at bruge Git rebase. For at understøtte dit eget sæt af ændringer over .

Stock Redmine: Rebupping lokale ændringer over "nøgen" redmin: $ Git checkout redmine / 3.2-stabile $ git pull # nye upstream begår kommer i $ git checkout lokale / 3.2-stabil $ git rebase redmine / 3.2-stabile

Rebase:

Vil annullere alle lokale ændringer i

Links.

  1. UPDATE.
  2. At afspejle de ændringer, der opstod i
Hvis du uventet fik en flok konflikt, og der ikke er tid til at løse dette problem, kan du simpelthen afbryde den nuværende rebuansion ved hjælp af parameteren

Alle lokale ændringer på "Bare" -versionen vil genbruge.

Redmine. Resultatet vil være Ren historie. Hvor dine (lokale) begår altid på toppen af ​​de sidste (stigende) begår af redmin.

Junior og ældre opdateringer

Nu hvor der er en ny stabil filial (lad os sige 3.3-stabilt ), gør det samme - rækk dine ændringer oven på det. GIT-kommandoer vil være lidt anderledes på grund af ændringen af ​​den opadgående gren: Overførsel af lokale ændringer til en ny stabil filial $ Git hent opstrøms $ git checkout -b redmine / 3.3-stabilt opstrøms / 3.3-stabilt $ git checkout -B lokal / 3.3-stabil lokal / 3.2-stabilt $ git Rebase --onto redmine / 3.3-stabil redmin / 3.2-stabilt Lokal / 3.3-stabilt Disse hold opretter først to nye lokale filialer til version 3.3: En af de stigende, og den anden er fra den lokale gren 3.2. Så flytter de lokale ændringer over Redmine / 3.3-stabilt

. Lokale ændringer her er forskellen mellem

Lokal / 3.3-stabilt (som stadig er ). Nu

Indeholder Redmin 3.3 plus eventuelle lokale ændringer.

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