Ongelmat Uusi

Kysymys: Kuinka monta uutta numeroa syntyy tietyn ajanjakson aikana?

Kuvaus

Projekteissa keskustellaan siitä, kuinka ne korjaavat vikoja tai lisäävät uusia ominaisuuksia ongelmanseurantajärjestelmän lippuihin. Tietty henkilö avaa (lähettää) jokaisen lipun (ongelman), ja monet muut kommentoivat ja kommentoivat niitä myöhemmin.

Riippuen tarkasteltavasta ongelmajärjestelmästä, ongelmalla voi olla useita tiloja (esimerkiksi "triaged", "toimii", "korjattu", "ei korjata") tai se voidaan merkitä yhdellä tai useammalla tunnisteella tai se voi olla määritetty yhdelle tai useammalle henkilölle. Mutta missä tahansa ongelmanseurantajärjestelmässä ongelma on yleensä kokoelma kommentteja ja tilan muutoksia, mahdollisesti muilla merkinnöillä. Ongelmat voivat myös joissain järjestelmissä liittyä virstanpylväisiin, osiin, eeppoihin tai tarinoihin. Joissakin tapauksissa osa näistä on myös itse ongelmia.

Yleensä voidaan tunnistaa ainakin kaksi "korkean tason" tilaa: avoin ja suljettu. "Avoin" tarkoittaa yleensä, että ongelmia ei ole vielä ratkaistu, ja "suljettu" tarkoittaa, että ongelma on jo ratkaistu, eikä sen kanssa tehdä enempää työtä. Kuitenkin se, mitä voidaan käyttää tunnistamaan ongelma "avoimeksi" tai "suljetuksi", riippuu jossain määrin ongelmanseurantajärjestelmästä ja siitä, kuinka tietty projekti sitä käyttää. Todellisissa projekteissa suoraan lähdekoodiin liittyvien ongelmien suodattaminen on vaikeaa, koska ongelmanseurantajärjestelmää voidaan käyttää monenlaiseen tietoon, bugien korjaamisesta ja uusien ominaisuuksien käyttöönotosta keskustelemisesta projektitapahtuman järjestämiseen tai kysymysten esittämiseen. miten hankkeen tuloksia käytetään.

Useimmissa ongelmanseurantaohjelmissa ongelmat voidaan avata uudelleen sulkemisen jälkeen. Ongelman uudelleen avaamista voidaan pitää uuden numeron avaamisena (katso parametrit alla).

Esimerkiksi "ongelmat" vastaavat "ongelmia" GitHubin, GitLabin tai Jiran tapauksessa, "virheraportteja" Bugzillan tapauksessa ja "ongelmia" tai "lippuja" muissa järjestelmissä.

Tavoitteet

Projektissa käsiteltyjen asioiden määrä. Ongelmat ovat proksia projektin toiminnalle. Laskemalla koodia käsittelevät ongelmat projektia vastaavissa arkistoissa, voit saada käsityksen projektin kysymyksistä keskustelemisen kokonaistoiminnasta. Tämä mittari ei tietenkään ole ainoa, jota tulisi käyttää koodaustoiminnan määrän seuraamiseen.

Täytäntöönpano

Terveysmittareiden käyttö ja levittäminen voi johtaa yksityisyyden loukkauksiin. Organisaatiot voivat altistua riskeille. Nämä riskit voivat johtua GDPR-asetuksen noudattamisesta EU:ssa, Yhdysvaltain osavaltion lain tai muun lainsäädännön noudattamisesta. Tietojen tarjoajien, kuten GitHubin ja GitLabin, palveluehdoista voi myös aiheutua sopimusriskejä. Mittareiden käyttöä on tutkittava riskien ja mahdollisten dataeettisten ongelmien varalta. Ole hyvä ja katso CHAOSS Data Ethics -asiakirja lisäohjeita varten.

Aggregaattorit:

  • Kreivi. Uusien numeroiden kokonaismäärä kauden aikana.
  • Suhde. Uusien emissioiden suhde emissioiden kokonaismäärään kyseisenä ajanjaksona.

parametrit:

  • Aikavälillä. Aloitus- ja päättymispäivä ajanjaksolle, jonka aikana asioita käsitellään. Oletus: ikuisesti.

  • Lähdekoodin kriteeri. Algoritmi. Oletus: kaikki ongelmat liittyvät lähdekoodiin.
    Jos keskitymme lähdekoodiin, tarvitsemme kriteerin sen päättämiseksi, liittyykö ongelma lähdekoodiin vai ei.

  • Avaa uudelleen uutena. Boolean. Oletus: False.
    Kriteeri, jolla määritellään, katsotaanko uudelleen avatut numerot uusiksi numeroiksi.

Suodattimet

  • Näyttelijöiden mukaan (lähettäjä, kommentoija, lähempänä). Edellyttää samaa tekijää vastaavien henkilöllisyyksien yhdistämistä.
  • Toimijaryhmien mukaan (työnantaja, sukupuoli... jokaiselle toimijalle). Edellyttää näyttelijöiden ryhmittelyä ja todennäköisesti näyttelijöiden yhdistämistä.

visualisointeja

  • Laske ajanjaksoa kohti ajan kuluessa
  • Suhde ajanjaksoa kohti ajan kuluessa

Nämä voidaan ryhmitellä käyttämällä edellä määriteltyjä suodattimia. Nämä voitaisiin esittää pylväskaavioina, jolloin aika kulkee X-akselilla. Jokainen palkki edustaisi ehdotuksia koodin muuttamisesta tietyn ajanjakson (esim. kuukauden) aikana.

Tiedonkeruustrategiat

Tarkka kuvaus: GitHub

GitHubin tapauksessa ongelma määritellään "ongelmaksi".

Liikkeeseenlaskun päivämäärä voidaan määritellä (tarkastellaanko sitä ajanjaksolla vai ei) päivämääräksi, jolloin liikkeeseenlasku avattiin (lähetettiin).

Tarkka kuvaus: GitLab

GitHubin tapauksessa ongelma määritellään "ongelmaksi".

Liikkeeseenlaskun päivämäärä voidaan määritellä (tarkastellaanko sitä ajanjaksolla vai ei) päivämääräksi, jolloin liikkeeseenlasku avattiin (lähetettiin).

Tarkka kuvaus: Jira

Jiran tapauksessa ongelma määritellään "ongelmaksi".

Liikkeeseenlaskun päivämäärä voidaan määritellä (tarkastellaanko sitä ajanjaksolla vai ei) päivämääräksi, jolloin liikkeeseenlasku avattiin (lähetettiin).

Erityinen kuvaus: Bugzilla

Bugzillan tapauksessa ongelma määritellään "virheraportiksi", kunhan se liittyy lähdekooditiedostoihin.

Ongelman ilmestymispäivä voidaan määritellä (tarkastellaanko sitä tietyllä ajanjaksolla vai ei) päivämääräksi, jolloin virheraportti avattiin (lähetettiin).

Viitteet