Team management hvilken vei å gå

[HDSoftware]

Folkens...

 

Trenger noe input angående valg av team management

 

Vi skal i gang med å bruke noen eksterne utviklere, stort sett i C# og noe for IOs og noe for Android. Vi bruker i dag TFS i sin reneste form som kode repository.  Vi bruker så langt ingenting av det TFS tilbyr og således har jeg ingen erfaring med dette heller.   Så derfor spør jeg her:

 

Hvilket system er å foretrekke til utvikling prosjekter med flere deltagere?

 

Har TFS alt som egentlig trengs?  Burde vi vurdert GIT?  Eller er det rett og slett noe annet der ute som er bedre?

Kan gjerne være av typen Open Source, men det bør helst være et system som installeres inhouse..

[tingo]

Har aldri brukt TFS, så jeg overlater til noen andre å kommentere den. Dersom du bruker git så vil du gjerne ha Github / Gitlab eller et tilsvarende grensesnitt hvor folk (team-medlemmer) kan kommentere, lage pull requests osv.

[Lycantrophe]

Det er ingen alternativer til git for faktisk seriøst utvikling.

[HDSoftware]

Det er ingen alternativer til git for faktisk seriøst utvikling.

 

Oj, det var ikke bra.  Har trodd at TFS kunne brukes i mange år nå og vi har for så vidt greid oss godt med det.  Kan ikke du fortelle meg hva som gjør at jeg må bytte til GIT.  Ønsker jo nødig å være useriøs.   

[HDSoftware]

Har aldri brukt TFS, så jeg overlater til noen andre å kommentere den. Dersom du bruker git så vil du gjerne ha Github / Gitlab eller et tilsvarende grensesnitt hvor folk (team-medlemmer) kan kommentere, lage pull requests osv.

 

Ok.  Da skal jeg sjekke ut GITLAB og se hva den bringer til torgs.  TFS har masse funksjonalitet den også, men så langt har jeg ikke hatt det helt store behovet for team management. Ha<r stort sett kun brukt dette som et Code Repository.  Når det er sagt så tror jeg muligens GIT kan være vanskelig å implementere for oss fordi vi jobber med to utviklingsverktøy, Clarion og Visual Stidio.  Clarion er ikek basert på Source files, men APP files som er binære og det betyr at systemet må støtte file locking og så vidt jeg vet støttes ikke det av GIT

[Emancipate]

Facebook bruker Mercurial, men de bedriver kanskje ikke "seriøs utvikling" etter enkeltes standard.

 

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

[Lycantrophe]

Oj, det var ikke bra.  Har trodd at TFS kunne brukes i mange år nå og vi har for så vidt greid oss godt med det.  Kan ikke du fortelle meg hva som gjør at jeg må bytte til GIT.  Ønsker jo nødig å være useriøs.

1. distribuert modell

2. bedre branch-and-merge resolution enn noen alternativer

3. *raskt*

4. git rebase, reset, checkout og andre tools for å modifisere lokale historikker før merge.

5. solid branchingmodell

6. aktiv utvikling

7. gpl https://git-scm.com/about/free-and-open-source#free-and-open-source

8. https://git-scm.com/about/free-and-open-source#free-and-open-source

9. egentlig alt som står her https://git-scm.com/about

 

TFS er en vits. Hvis det har fungert for dere, så for all del, fortsett med det.

[Sokkalf™]

Brukte subversion før jeg begynte med git. Går aldri tilbake, for å si det sånn.

 

Lycantrophe nevner fordelene, men en del av dem gir kanskje ikke mening for deg før du har prøvd. Man blir en bedre og mer effektiv utvikler, rett og slett. Eller for å si det på en annen måte, git som verktøy legger til rette for at du kan bli det, om du bruker mulighetene som er der.

 

Det går an å bruke git som man bruker svn (og sikkert TFS), men det gir ikke særlig mening.

 

Mercurial har en del av det samme tankegodset som git, men git har forlengst vunnet kampen om mindshare.

[HDSoftware]

Ok.  Jeg er nysgjerrig :-)   GIT høres veldig lovende ut, men mitt spørsmål handlet ikke om kildekode kontroll, men om management av prosjekter og alt det andre rundt dette. 

Altså ting som resursfordeling, estimering, oppgavefordeling i grupper, prototyping/mockup muligheter, timeregistrering, vurdering av timebruk, produksjon av timelister, grunnlag for viderefakturering, rapportering o.s.v.

 

Sokkalf: File locking er noe vi MÅ ha dessverre.  Jeg er selvsagt imot alt sånt, men vi har tre utviklere som kun holder på med Clarion for Windows og dette verktøyet baserer seg ikke på kildekode i filer, men i en slags database som ikke er åpen.  Det betyr at disse ikek lar seg merge på noen som helst måte.  Man må "Sjekke ut" det man skal jobbe med og så sjekke inn igjen etterpå. Og når man gjør dette så MÅ filene være read only hos alle andre utviklere.  Dette må det være automatikk i hvis ikke blir det ikke gjort.  TFS hadde ikke dette før og dette skapte selvsagt problemer.  TFS fikk det etter hvert og dermed fungerer dette ypperlig.

 

Hvis GIT også greier dette så er det jo helt topp, men har mine tvil for da bruker man jo ikek lenger GIT på den måten det er tenkt, og som du sier så gir det ingen mening.

 

Alternativt kan jeg jo bruke både TFS og GIT.  Visual Studio har ingen problemer med det, men da må det være en gevinst i det.  

 

Anyway, som tidligere nevnt handler altså ikek denne tråden om kildekode håndtering, men prosjekt management..  

[Sokkalf™]

Tja, hvis dere er en ren MS/Visual Studio-sjappe er kanskje VSTS det dere ser etter. Har alt av prosjektmanagement-opplegget, såvidt jeg vet.

 

Vet at den støtter git, men aner ikke om den kan kjøres som en inhouseløsning eller hvordan støtten for det du bruker TFS idag er.

[HDSoftware]

Tja, hvis dere er en ren MS/Visual Studio-sjappe er kanskje VSTS det dere ser etter. Har alt av prosjektmanagement-opplegget, såvidt jeg vet.

 

Vet at den støtter git, men aner ikke om den kan kjøres som en inhouseløsning eller hvordan støtten for det du bruker TFS idag er.

 

Da er det VSTS jeg skal undersøke.  Ser det er imple,entert i VS, men har ikek studert dette enda.  Siden du nevnte det så ble jeg nysgjerrig og ser at VSTS har et REST API så da skal det være mulig å integrere det med vårt intern system også.  Dette ser lovende ut..

 

Takker for info..

[Lycantrophe]

Hvis du ikke spør etter versjonskontroll, men noe annet, hvorfor blander du inn git?

[nomore]

Team management er heller ikke det samme som project management.

[HDSoftware]

Ok.  Skjønner jeg ikke har greid å frembringe mitt budskap på en skikkelig måte.  Prøver igjen da...:

​Jeg trenger et system der jeg kan fordele oppgaver til andre utviklere, både inhouse og eksterne.  Disse utviklerne skal så lage et slags estimat på tidsforbruk. Så skal jeg vurdere dette opp imot tilgjengelig tid/resurser og eventuelt gå runde to for kanskje å korte inn eller utvide der det trengs. Oppgavene må kunne hektes på planlagte releaser og således få deadlines. Oppgavene må også kunne ha forskjellige status, som OPEN, ACTIVE, CLOSED, POSTPONED, CANCELLED, etc. etc.

Det må være ,mulig å ta ut status rapporter, progresjonstrender og alt dette som hører med i prosjekt styring

 

Prosjekt styringen og kildekode håndteringen må på en måte gå hånd i hanske, altså "Hey, der sjekket jeg inn noe, som tok meg 3 timer å fikse og jeg måtte gjøre sånn og slik fordi han/hun hadde gjort ditt og datt i stedet for datt og ditt. Videre måtte jeg reise på seminar og her er bilagene for den reisen. Dessuten måtte jeg prototype inn noen uferdige metoder i en klasse A fordi den ikke var kompatibel og det tok 2 timer ekstra. Fullføring av disse metoden må X gjøre innen 2 måneder"

En del ting her så klart som ikke kan støttes out of the Box, men TFS har en masse API'er og det er derfor mulig å mekke til ting der

 

 

Jeg nevnte også GIT i tilfelle ikke TFS har dette og at vi derfor må vurdere GIT i bunn i stedet.

 

Benytter anledningen til å beklage hvis GIT ikke er korrekt å nevne i denne sammenhengen.  Jeg har aldri brukt GIT og vet svert lite om GIT annet enn at jeg har hørt om det og alle sier det er så bra.  Antok derfor at det vare betimelig å ta med GIT i farta. Hvis det er slik at GIT ikke er annet en kildekodehåndtering så er det bare å se bort ifra at jeg har sagt noe om GIT i det hele tatt.  Jeg trodde systemet var mer enn det.

[Sokkalf™]

git (skrives med små bokstaver) er bare versjonskontroll, men gitlab og github osv gir deler av det du etterspør rundt selve versjonskontrollbiten.

 

Har inntrykk av at det i MS-verdenen er mer vanlig å velge en svær pakke som gir deg alt, mens i open source-verdenen er det nok mer vanlig å velge flere verktøy og kombinere dem slik det passer.

[nomore]

Ingenting å beklage. Var bare litt vanskelig å forstå helt hva behovet var når du skriver en ting, beskriver en annen ting og etterspør en tredje ting

 

Min mening er at det finnes ikke ett verktøy som mestrer alt dette perfekt. Det er godt mulig man kan sy sammen en komplett pakke med Microsoft produkter(Teams, TeamFoundation, Project, Sharepoint etc), men du må sannsynligvis uansett ha flere løsninger for å oppnå målet ditt.

 

Og da føler eg det er bedre at du ser på løsninger som finnes der ute, og gjør de enkelte oppgavene bra for dere. Viktig at løsninger dere velger har integrasjonsmuligheter, men det har alle med selvrespekt i dag. Da kan du koble løsningene sammen slik at oppgaver i ett system blir merket som løst når Jonas committer en endring til kodebasen i ett annet system. Og på toppen kan du ha ett tredje system som følger med på totalfremdriften. Kanskje til og med dere skulle sett på system for feilrapportering og.

[HDSoftware]

Ingenting å beklage. Var bare litt vanskelig å forstå helt hva behovet var når du skriver en ting, beskriver en annen ting og etterspør en tredje ting

 

Min mening er at det finnes ikke ett verktøy som mestrer alt dette perfekt. Det er godt mulig man kan sy sammen en komplett pakke med Microsoft produkter(Teams, TeamFoundation, Project, Sharepoint etc), men du må sannsynligvis uansett ha flere løsninger for å oppnå målet ditt.

 

Og da føler eg det er bedre at du ser på løsninger som finnes der ute, og gjør de enkelte oppgavene bra for dere. Viktig at løsninger dere velger har integrasjonsmuligheter, men det har alle med selvrespekt i dag. Da kan du koble løsningene sammen slik at oppgaver i ett system blir merket som løst når Jonas committer en endring til kodebasen i ett annet system. Og på toppen kan du ha ett tredje system som følger med på totalfremdriften. Kanskje til og med dere skulle sett på system for feilrapportering og.

 

Feilrapportering er selvsagt aktuellt.  Vi har jo mye av dette allerede i dag, men det er hjemmesnekret og enkelt å håndtere fordi vi så langt har vært tre.  Nå skal vi blande inn utviklere i Polen og Cannada og da må vi strukturere dette på en helt annen måte. Mye fordi noen sover mens andre er på jobb i en slikt oppsett.

[quantum]

Jira er jo mye brukt (til det ta egentlig lurer på), men man kan til en viss grad argumentere for at det er litt "panzer" i noen sammenhenger. Har et digert økosystem med plugins for "alt".

[HDSoftware]

Jira er jo mye brukt (til det ta egentlig lurer på), men man kan til en viss grad argumentere for at det er litt "panzer" i noen sammenhenger. Har et digert økosystem med plugins for "alt".

 

Heisan, den så jo interessant ut.  Prisen var jo i alle fall overkommelig.  Skal sjekke den ut...

 

Takker for tipset..

[etse]

Vil bare nevne at det høres ut som du jobber med IT-prosjekter, noe jeg synes er en uting. Man burde ikke organisere IT-utvikling som et svært prosjekt, men heller ta mer lærdom av Lean og ordentlig smidig utvikling. Alt det orginasatoriske rundt IT-prosjekter fører bare til mer problemer enn det løser, og følelsen du får av kontroll og oversikt er gjerne bare en illusjon.

 

En tidligere kollega av mneg skre ven fin bloggpost om nettopp dette: BEKK Open: Slutt med IT-prosjekter