Aluksi tuli agile ja scrum, joilloin saimme vihdoin kauan kaivatun oikeiden päivittäin raportoida tekemisiämme. Todella hienoa! varmasti jokainen, joka joutuu työskentelemään ilman jokapäiväistä seurantaa kadehtii meitä kehittäjiä. Eipä enää koodarit pääse notkumaan tyhjän panttina, kun tekemisten seuranta on saatu melkein reaaliaikaiseksi.
Nyt otetaan sitten käytöön uusi hieno käytäntö. Jokainen rivi koodia, jonka kirjoitamme, tarkistutetaan toisella kehittäjällä. Tästähän me kaikki olemme unelmoineet. Sanotaan sitä vaikka katselmoinniksi, koska kyttääminen kuulostaa pahemmalta, vaikka asia ei siitä miksikään muutu. Siis kulkeeko sairaanhoitajat osastolla joku toinen olan takana tarkistamassa kaikki työvaiheet? Miksei HKL:n kuljettajilla ole kakkoskuskia, jonka tehtävät on tarkkailla ratissa istuvan työn laatu?
Jos joku nuori tällä palstalla pohtii tulevaa uraa, voin suositella IT-alaa todellisena unelmatyönä. Päivittäin saat tehdä selvityksen, miksi työsi tuottavuus ei ole yltänyt tavoitteisiin. Jos tuottavuus onkin kohdallaan, niin joku tarkistaa kaikki tekemisesi ja kirjaa ylös virheet, jotta niistä voidaan asianmukaisesti rapostoida eteenpäin. Onko mitään, mihin kehittäjät eivät sopeudu?
Ei niin hyvää, ettei jotain pahaakin. Scrumit sun muut ovat ihan helvetin hyviä juttuja, silloin kun ne toimivat oikein, vaan eivät silloin kun niitä muka käytetään - kuten teillä ilmeisesti.
Laiskottelu koodaushommissa on useimmiten seurausta siitä, että tekijä tietää, että tällä hetkellä tehty työ olisi turhaa. Ei siis kannata tehdä. Agiileissa menetelmissä kehittäjästä ei koskaan saisi tuntua, että hän tekee turhaa työtä. Silloin on jo menty metsään niin että rytisee...
Toki, jos tarkoitus on vain lepäillä töissä tekemättä mitään, on scrum aika hankala. Sitten pitää oppia lepäämään siten, että saa jotain aikaiseksikin... Haastavaa, mutta siitä hyvän koodarin tunnistaa. :)
Mitä katselmointeihin tulee... Noh... Niitä tehdään lähinnä kolmesta syystä:
1) Jonkun tuottama koodi on niin bugista ja/tai muuten surkeaa, että pitää ottaa selvää mistä se johtuu
2) Jonkun tuottama koodi on niin hyvää ja toimivaa ja kaunista, että siitä saa johto sulan hattuun kun teettää katselmoinnin.
3) Joku aloittelee koodausta kyseisellä välineellä/kielellä/tavalla/... Halutaan varmistaa, että mennään sovituilla tavoille eteenpäin.
Itse olen törmännyt vain kakkoseen ja kolmoseen. Välillä on tehnyt mieli ottaa ykkönen käyttöön parin tyypin kanssa... :)
Eihän kontrollissa voi olla mitään pahaa, kun töissä kerran ei ole tarkoitus lepäillä. Miksei saman tien linjamanagereille avata omalta työasemalta 24/7 näkymää alaistensa näytöille. Pelkkä scrummi kun ei aina saa joutavaa surffailua kuriin. Nytkin täällä vaan velttoilen kesken työpäivän. En kyseenalaista scrummin etuja työnantajan kannalta oikein käytettynä. Pointti oikeastaan on, että tekeeko tuottavuutta parantava kontrolli miellyttävän työyhteisön, jossa työntekijät haluavat jatkaa alati nousevaan eläkeikään asti. Toisaalta tuskin meistä koodareista kukaan Suomessa eläkeikään saakka softaa voi kehittää. Parin vuosikymmenen kuluttua ohjelmoinnin oppikirjoja luultavasti on saatavissa vain kiinaksi (tai vietnamiksi tms).
Meillä onkin niin tasa-arvoinen työyhteisö, että managementin mukaan on tarpeen katselmoida jokaisen developerin koodi. Jatkossa jokaikinen kirjoitettu rivi katselmoidaan ennen tuotantoon ottoa. Aikaisemmin developerit saivat käyttää omaa harkintaansa, mutta olivat ilmeisesti liian laiskoja vahtimaan toistensa työtä, tai käyttivät liikaa aikaa koodaamiseen toistensa koodin lueskelun sijasta. Lisäksi katselmointi ei ole enää mitään leppoisaa jutustelua neukkarissa iltapäivän ratoksi, vaan saimme sitä varten uuden softan laatua parantavan cutting edge työkalun. Siihen jokaisesta huomatusta puutteesta tulee kirjata kommentti, jotka luonnollisesti talletetaan backendin tietokantaan managementin myöhempää käsittelyä varten. Kaiketi kehityskeskustelussa saamme odottaa uutena kohtana agendassa katselmoinnissa havaittujen puutteiden henkilökohtainen käsittely. Tuskin maltan odottaa.
Itse aloitin softakehityksessä kauan sitten, kun Cobol oli vielä käytetyin ohjelmointikieli. Toisinaan olen tehnyt jotain ja toisinaan en niinkään paljon, mutta aloittaessani kollegoista kukaan ei olisi suostunut alistumaan nykyiseen kyttäykseen. Silloin kehittäjät sanoivat itse, miten softaa tehdään. Nykyään sen kertovat agile konsultit ja muut tuottavuus expertit.
Ko "työkaluhan" takuulla romuttaa ohjelmoijien viimeisenkin motivaation ja itseohjautuvuuden.
"Silloin kehittäjät sanoivat itse, miten softaa tehdään. Nykyään sen kertovat agile konsultit ja muut tuottavuus expertit". Tämähän on aivan järjetön tilanne. Ohjelmoinnin (ja systeemityön, tietokantojen ja vastaavien) opettelemiseen menee vuosia. Hyväksi ohjelmoijaksi vielä enemmän aikaa.Miten kukaan agile-konsultti (joka ei ehkä koulunsa jälkeen ole koodannut riviäkään) voi alkaa neuvomaan paremmin asioista perillä olevia, jotka ovat tehneet vuosia ko duunia?
Hyvä ohjelma ei sitä paitsi ole pelkästään bugi-vapaa. Hyvään ohjelmaan liittyy ylläpidettävyys, muokattavuus, yksinkertaisuus
Koskakohan "managementti" oikein tajuaa, ettei ohjelmistoalalla ole silver bullettia. Edellinen muotisanailmiö ei toiminut, ei toiminut sen edeltäjäkään, ei nykyinen, ei tuleva. Parin vuoden päästä on scrummit ja agilet aikansa eläneitä. Onneksi. Lähimpänä silver-bullettia on mielestäni GoFfin design patternit ja olioparagdiimat, sekä oikeasti näihin perustuen ohjelmien suunnittelu ennen koodausta.Vieväthän suunnittelu ja mallintaminen toki aikansa, johon nykyinen kvartaalitalous ei anna mahdollisuuksia..
Kaikkein hämmästyttävimpiä ovat työtoverit, jotka ehkä ruskeakielisyyttään tai työriippuvuuden takia selittävät managementille "hyvä kun agilessa seurataan edistymistä päivittäin, niin tuottamaton työaika vähenee" ja "hyvä kun katselmoidaan kaikki koodi, niin laatu paranee". Miten näiden teollisuusrobottien kanssa voi tehdä töitä? Terveet ihmiset tekevät töitä palkan takia, siinä määrin kuin on tarpeen, ja nauttivat saadessaan tehdä asioita, jotka oikeasti kiinnostavat. Minun nuoruudessani ei ohjelmistoalalla ollut friikkejä, joiden mielestä miellyttävän työpaikan ensisijainen kriteeri on mahdollisimman korkea tuottavuus.
Eräässä globaalissa yrityksessä, jonka pääkonttori on Espoossa. Meitä on täällä muutama muukin suomalainen tuotekehityksessä. Jääköön loput lukijan pääteltäväksi.. Arvaa lähtisinkö, jos olisi realistisia vaihtoehtoja. Jos nyt lähtee, niin saa tuskin edes sitä liksaa, jonka neuvottelin tullessani muutama vuosi sitten. Onko softa-alalla edes yrityksiä, joissa ei käydä YT-neuvotteluja? Sitä paitsi nykyään ohjelmistoalalla on vain kahdenlaisia työpaikkoja. Niitä joissa käytetään agilea ja niitä joissa ei vielä käytetä.
Kyse ilmiöstä joka firman sisältä syö mahdollisuuksia tehdä hyvää ja tuottavaa bisnestä. En usko että ruskeakielisten tyyppien kohdalla on kyse huoli firman tuloskunnosta vaan omasta palkka-ja urakehityksestä. Tähän ajaa IT-alalta puuttuvat, palkkakehityksen turvaavat yleissitovat työehtosopimukset. Samoin kuin ylimalkaiset tehtävänkuvaukset, mahdollisuus hengailla porukassa tekemättä mitään järin tuottavaa. On lukuisia esimerkkejä huipputyypeistä joille ei meriittikorotuksia heru koska naamavärkki ei ole managementin mieleen.
Mun mielestä on aivan sietämätöntä, että on juurikin teitä. Tämä vahvistaa kokemuksiani siitä, kuinka paljon huonoja tekijöitä löytyy. Toivottavasti en tee sinun kanssasi hommia.
Toivottavasti nämä kyttäämistavat kuuluvat meidän ohjelmatoimittajien tuotekehitykseen.. on niin saa*nan bugista ja törkeää jälkeä ollut viimeiset pari vuotta.
Totta kai koodifirman pitää seurata tiiviisti mitä ollaan tekemässä. Että voidaan kääntää kelkka nyt, eikä sitten metriä ennen törmäystä. Byrokraattinen, päivittäinen tasan-kello-0900-0915 oleva palaveri ei kuitenkaan välttämättä ole paras tapa tuohon..järkeä sopii ja saa mielestäni aina käyttää
Lisäksi pitemmän päälle jatkuva pelkkä sprinttailu alkaa varmaan hiukan ahdistamaan, kuvittelisin..
XP kuulostaa kyllä mielestäni ihan viksulta. Mutta mielestäni vain ohjelman alkuvaiheessa, kun mietitään luokkahierarkkiat ja kuinka hyvin OOP-periaatteita käytetään, tällöin toinen voi esim huomauttaa, että "nyt sun ideas rikkoo OCPtä koska tätä ja tätä ei voi vaihtaa, olisko parempi tämmönen vaihtoehto..tai baseClass määrittelee vääriä metodeja tms". Mielestäni tätä syvemmälle ei kannata mennä, itse koodaus on sitten yksittäisen koodarin vastuulla..Ei ole mitään järkeä toisen tuijottaa selän takana herjaako Eclipse kun jäi puolipiste vahingossa pois
Hei niinku oikeesti.. oottehan te nyt melkein kaikki ihan pihalla..
1. Jos jossain on jotain idioottimaista pelleilyä niin vaihda muualle jos olet niin älyttömän fiksu itse. Kyllä tänne meillekin pääsee vaikka heti jos on oikeasti kova :-)
2. Joskus ennen moni asia oli toisin.. ja koodarit oli miehiä, eikä naisia ja miehet oli rautaa ja koneetkin oli rautaa, eikä jotain virtuaalikoneita. Voi kyynel. Silloin oli varmaan oikeastikin erilaista väkeä kun alalle tultiin vähän eri reittejä ja eri syistä, mutta ajat muuttuvat. Palaa kohtaan 1.
3. Katselmoinnit, scrum tai joku muu juttu ei ole turhaa tai tyhmää touhua sen takia että just sun firmassa ja projektissa niitä pyörittää joku ääliömääliö. Palaa kohtaan 1.
Sössötys kertoo lähinnä siitä, että et ole oikeasti mikään guru, joka tajuaa asioita. Muuten olisit omassa firmassasi se joka sanoo miten tehdään tai voisit koska tahansa vaihtaa järkevään paikkaan töihin.
"Jonkun tuottama koodi on niin hyvää ja toimivaa ja kaunista, että siitä saa johto sulan hattuun kun teettää katselmoinnin". Siis johto, ei koodin tehnyt apina, korjaan ihminen.
Ei agile menetelmät estä turhan työn tekemisen tunnetta jos kerta kyse on... turhasta työstä. Turha työ tehdään agile menetelmissä vain "ketterästi".
Lisäsyitä katselmointeihin:
4) Aikatauluissa on pysytty mutta hetken huilia ja hyvänolontunnetta tehdystä työstä ei management katso hyvällä tämän alan töissä. Pistetään pystyyn katselmoinnit. Vaikka olisit viilannut pilkunkin oikein niin ainahan voidaan väittää että se olisikin pitänyt olla piste jonka viilaaminen on ollut tärkeää.
5) Management haluaa näyttää kuka oikeasti osaa. Onnistuneelle kehittäjälle on saattanut tulla "virheellinen käsitys" omasta kompetenssistaan ja tokihan tällainen tyyppi pitää palauttaa takaisin maan pinnalle.
Jos agileilla menetelmillä tehdään turhaa työtä, silloin ei kyse ole ainakaan scrummista oikein toteutettuna. Kyllähän niitä vesiputousscrummejakin näkee, mutta onko niilä enää mitään tekemistä agilen menetelmän kanssa?
Ideahan on, että jos työ tuntuu turhalta, ei sitä tehdä, ennen kuin selviää miksi se ei ole turhaa — ja jos ei selviä, ei tehdä ollenkaan.
Jollakin white trash täytyy elättää. Vaikka helpommalla Suomessa pääsis ryhtyessään juomaan kokopäiväisesti keskiolutta lähiökuppilassa. Silloin koodiorjasta tulisi kerta heitolla niin tärkeä henkilö, että Helsingin kaupunki ryhtyisi suorastaan maksamaan asumisesta. Tähän saakka ovat sietäneet nurkissa, vain tuomieni verotulojen takia. Ystävien määräkin moninkertaistuisi kerta heitolla.
organisaatioon ruohonjuuritasolta ja se on kannattanut. Tuo työkalu kuulostaa kyllä aika hullulta vekottimelta, mutta pitäähän projektin jäsenten nyt päivittäin tietää, mitä toiset tekee. Ei meillä ainakaan raportoida niitä päivittäisi tekemisiä muille kuin omille työkavereille ja mitään arkistoa niistä ei synny.
Koko homma on auttanut siinä, että teemme toimivaa softaa asiakkaille ja asiakas on tyytyväinen ja itse voin olla tyytyväinen siihen, että tuotan maailmaan jotain, mikä mielestäni parantaa asioita. Koko ajan töissä on kyllä jotain hommaa, mutta tauot pidän ja töistä lähden ajallaan. Eikös sen niin pidä ollakin?
Ei siihen entisajan malliin, jossa sai viikon tehdä jotain ja sitten vaan sanottiin, että "en oikein ymmärtänyt, mitä oli tarkoitus tehdä" ei ole mitään paluuta ja hyvä niin. Pakko meidän on olla itseohjautuvia ja sietää sitä, että omaa työtä arvioidaan koko ajan.
Kerrot olevasi pitkän ajan konkari: sinun pitäisi osata työsi niin, ettei siihen ole kenelläkään mitään sanottavaa. Jos katselmoinneissa saat jotain huomautuksia, niin joko selität, miksi teit niin kuin teit tai sitten korjaat tapasi. Ei kenelläkään ole mitään oikeutta pitää huonoista tavoistaan kiinni. Kun taas tutkit toisten koodia, niin tee vain asiallisia huomautuksia ja perustele ne kunnolla.
Jos tuo systeemi toimisi teillä hyvin teillä olisi parin vuoden päästä ihan pirun osaavaa porukkaa kun olisitte oppineet toistenne kommenteista. Mutta ilmeisesti epäilet, että koko systeemi on vain irtisanomisperusteiden kaivamista varten?
Jos teet työsi hyvin, niin eihän työnantajan lisääntyvä työntekoon kohdistuva kontrolli sua haittaa. Jos et tee rikoksia, niin eihän poliisin pakkokeinojen rajoittamiseen ole mitään syytä.
Vaikken ole rikollinen, niin mielestäni poliisin oikeuksilla täytyy edelleen olla tiukat rajat. Miksi haluaisin siis työnantajan lisäävän kontrollia, vaikka teen työni kunnolla? Toisaalta, jos mielestäsi poliisilla kuuluisi olla rajaton oikeus puuttua kansalaisten yksityisyyteen, niin ymmärrän ehkä myös pointtisi työn seurannan suhteen.
Poliisin ja työnantajan oikeuksilla pitääkin olla tiukat rajat, mutta nyt puhutaan siitä, että työnantaja tarkkailee työn tulosten laatua ja se ei ole kiellettyä. Ja ei työnantajankaan kaikkea pitäisi tonkia. Meillä raportointi on kuitenkin lähinnä siis työkavereille ja mitään syyllisyysarkistoa ei rakenneta. Silloin homma mielestäni toimii.
On todella kamalaa, jos joutuu tilanteeseen, jossa ei pysty vaihtamaan työpaikkaa halutessaan. Se aiheuttaa juuri tuon ongelman, että alkaa pelkäämään sitä, että työnantaja on vihollisesi. Ja joskushan työnantaja on vihollisesi, sitä en kiistä. Mutta sellaisista työpaikoista pitäisi päästä pois riippumatta siitä, miten toimitaan.
Vanhat hyvät ajat eivät kuitenkaan palaa ihan jo sen takia, että se toiminta oli läpeensä tehotonta ja intialaiset jyrää meitin kokonaan, jos niin jatkamme. Tehokkaalla toiminnalla osa hommista jää Suomeen, vaikka intialaiset nytkin jyrää meitä aika paljon.
Epäilemättä vanhat ajat, jolloin projektipalaveri oli viikottain, ovat jääneet taakse mainitsemastasi syystä. Se oli tehotonta, mutta toisaalta myös työntekijälle vähemmän stressaavaa. Silloin viikossa piti saada jotakin aikaan, jotta projektipalaverissa oli kerrottavaa. Nykyään on ratkaisua edellyttävä ongelma, jos päivässä asiat eivät etene.
Terveysviranomaiste mukaan nykyään työnteijät ovat hyvin stressaantuneita ja kaiketi useimmat meistä ennen pitkään jonkin sortin varttihulluja. Massoittain ihmisiä päätyy työkyvyttömyyseläkkeelle psyykkisten syiden takia, koska töissä ei kestä. Samalla lopuilla eläkeikä nousee koko ajan korvaamaan työkyvyttömien puuttuva panos. Jos tuottavuuden hinta on työkyvyttömyien määrän jatkuva kasvu, kuten nykyään, niin mitä luulet kansantalouden siitä hyötyvän. Yritykset luonnollisesti hyötyvät niin kauan kuin työkyvyttömyyden kustannukset lankeavat yhteiskunnalle ja tilalle voidaan ottaa uusi sukupolvi.
Täytyy kyllä sanoa, että jos scrumpalaverit ja koodikatselmointi aiheuttavat noin paljon stressiä, niin teette sen päin helvettiä tai olet harvinaisen herkkänahkainen ihminen.
"Vanhat hyvät ajat eivät kuitenkaan palaa ihan jo sen takia, että se toiminta oli läpeensä tehotonta ja intialaiset jyrää meitin kokonaan, jos niin jatkamme. Tehokkaalla toiminnalla osa hommista jää Suomeen, vaikka intialaiset nytkin jyrää meitä aika paljon."
Älä kuule valehtele asioista, joista et tiedä yhtään mitään, vaikka valehtelulla elätkin. Katselmukset eivät lisää toiminnan tehokkuutta, päin vastoin. Joiden bugien määrää ne vähentävät. Moni katselmuksiin siirtynyt suomalainen kooditalo on jäänyt ihan suomalaistenkin katselmuksia käyttämättömien kilpailijoidensa jalkoihin.
Toinen tyypillinen arkkivalehtelijatyyppi on se, joka vastaa kaikkeen kritiikkiin: "Mutta fiktiivisessä Oy Taivas Abeessä tämä homma toimii!!"
Ohjelmistokehitysmenetelmien hautausmaalla on paljon menetelmiä, jotka toimivat kuulema jossain.
Vai virtasiko kiukku vain niin voimakkaana, että silmät sumeni ja pystyi vain kirjoittamaan kiukkua kommenttin?
En minä puolustanut katselmointeja tuossa kirjoituksessa ollenkaan ja muutenkin vain huomautin, että niillä voi olla jokin muukin käyttö kuin irtisanomisperusteiden kerääminen. Sen sijaan puolustin scrumia sellaisena kuin olen sen itse kokenut - siihen kuuluva kehittäjien välinen yhteistyö auttaa heitä oppimaan toisiltaan.
Nokialla se meni tuotannon puolella niin että kaikkeen vastattiin : mutta Kiinassa se toimii vaikka kuinka hyvin! Jos oli systemaattinen virhe, kerrottiin että ei niillä vaan Kiinassa tuota ole (eli vika on tekijöissä, ei tuotteessa). Kunnes kuulimme viikon päästä että itseasiassa Kiinassa oli tapeltu saman asian kanssa vielä enemmän. Saksa-kortti oli todella kuumaa kamaa, kunnes se loppui ja voi voi! Monta kertaa vuodessa kerrottiin että jos ei ala kädet käydä niin viedään teidän työt Saksaan, ne kyllä tekee ja osaa. Kumma juttu että niin taitava tehdas piti lopettaa, ja vielä työhalutkin kohdillaan.
Hah, intialaisia on turha pelätä, laatu täyttä skeidaaa. Yksi intialainen koodari työllistää kolme suomalaista: Yksi käskee, yksi vahtii ja yksi korjaa työn tuloksia
Sikäläisten off-shore firmojen "Agile" toimintapa on seuraava:
1-Tuotetaan nopeasti jotain joka näyttää vähän siltä mitä asiakas speksaa
2-Laskutetaan asiakasta
3-Laskutetaan asiakasta lisää kun tutkitaan asiakkaan tekemiä bugiraportteja
4-Korjataan bugit ja tehdään nopeasti vähän lisää jotain mitä asiakas speksasi mutta joka jäi edelliskerralla tekemättä
5- Jos asiakas alkaa valittaa, muistutetaan että agilen luonteeseen kuuluu iterointi ja että on asiakkaan oma vika ettei valittanut tarpeeksi ja kyllin ajoissa
6-Laskutetaan asiakasta valitusten käsittelyyn kuluneesta ajasta
7-Toisteaan steppejä 1...6 niin kauan että asiakkaan projektipäällikkö on paska housuissa kun aikataulut ja budjetti ovat ylittymässä.
8-Annetaan kustannusarvio työn loppuun saattamisesta ja kun lupa on saatu, palataan steppiin 1
Lopulta on pakko pistää ulos buginen, ylläpidettävyydeltään painajaismainen häkkyrä, jonka jatkokehitysprojekteista intialainen firma käärii lisää rahaa.
Eli tyhmää tehdä kerralla hyvää kun voi laskuttaa paskan moneen kertaan.
"Jos katselmoinneissa saat jotain huomautuksia, niin joko selität, miksi teit niin kuin teit tai sitten korjaat tapasi. Ei kenelläkään ole mitään oikeutta pitää huonoista tavoistaan kiinni. Kun taas tutkit toisten koodia, niin tee vain asiallisia huomautuksia ja perustele ne kunnolla. Jos tuo systeemi toimisi teillä hyvin teillä olisi parin vuoden päästä ihan pirun osaavaa porukkaa kun olisitte oppineet toistenne kommenteista."
Paljastit, ettet ole ollut yhdessäkään nk. katselmuksessa. Sinä olet myyntipuolen heppu, joka valehtelee nälissään päivät pitkät tietävänsä jotain tuotteesta, jota myy. Sinun huonoksi onneksesi, minä tunnen sekä myyntipuolen limaiset huijarit että pölvästit koodarit.
Katselmuksissa nypitään joitain virheitä koodista. Koska katselmuksissa istuu pääsääntöisesti pölvästejä niin joskus hyvän koodin laatu laskee. Kas kun keskiarvo ja hyvä koodaustyyli ovat ohjelmistoalalla keskenään ristiriitaisia käsitteitä. Eli katselmuksilla nypitään pelkästään virheitä koodista.
Toisekseen, ei ne pölvästit opi yhtään mitään katselmuksista, koska ne ovat yhtä paksupäisiä kuin sinä. Jos ne eivät osaa jotain ohjelmointikikkaa niin pölvästit vaihtavat mieluummin duunia kuin opettelevat sen. Tämä on nähty pariin kertaan. Toisinaan nämä pölvästit menevät huijaamaan asiakkaita.
Mutta ei minulle ainakaan ole ihan selvää, mitä tuo alkuperäinen kirjoittaja tarkoitti, sinulle ilmeisesti on. Joka tapauksessa niissä katselmoinneissa voi yrittää toimia niin kuin olisi järkevää tai sitten voi alkaa pelata peliä, niin kuin sinä ilmeisesti jo teet. Itse ajattelin, että ne katselmoinnit voisivat olla jotain pariohjelmoinnin kaltaista - lue se alkuperäinen viesti, siinä mainitaan katselmoijan olevan toinen kehittäjä - ja se voisi olla fiksua, jos toimialalla virheettömyys on tärkeää.
Katselmointeja ei varmaankaan ole pakko tai edes hyödyllistä pitää, mutta jos kehittäjät eivät lue toistensa koodia he eivät voi tehdä yhtä tiivistä yhteistyötä vaan järjestelmä on pakko jakaa isoihin moduleihin, jotka taas jaetaan kehittäjille. Silloin ne "pölvästit" saavat rauhassa sekoilla siellä omassa modulissaan ja aiheittaa suurta tuhoa projektille, kun se moduli ei koskaan tee sitä, mitä sen pitäisi. Ja mikä vielä pahempaa, kehittäjät eivät tunne toistensa osuuksia, joten he eivät voi auttaa toisiaan tekemään paljon kehitystä samalle järjestelmän osalle.
Alkuperäiselle kirjoittajallekin suosittelisin työpaikan vaihtoa, mutta hän taisi jo kirjoittaa, ettei se onnistu. Sinulle kyllä suosittelisin samaa: ei tuo kiukun määrä ole enää tervettä. Mutta jos et tulisi meille, kiitos. Jos saisit kirjoitettua yhden asiallisen viestin, sinulla varmaan olisi hyvää sanottavaa siitä, miten katselmoinnit voivat olla vahingollisia - se olisi mielenkiintoista lukea.
"Koko homma on auttanut siinä, että teemme toimivaa softaa asiakkaille ja asiakas on tyytyväinen ja itse voin olla tyytyväinen siihen, että tuotan maailmaan jotain, mikä mielestäni parantaa asioita."
Olen ollut aikeissa siirtyä softa-alalle, mutta kynnys ollut siitä syystä liian suuri, että koodaamani softa on armotta parin vuoden päästä jo vanhentunut ja hyödytön. Siksi ei softapuoli oikein napeksi...
Sitähän scrum ei ota huomioon että osa koodareista on aivan oikeasti itseohjautuvia ja päivittäinen raportointi siitä mitä teit eilen ja mitä aiot tehdä tänään on heidän kohdallaan ajan hukkaa. Ne jotka vanhaan hyvään aikaan kävivät kerran viikossa kävivät kertomassa "en oikein ymmärtänyt, mitä oli tarkoitus tehdä" eivät scrum tiimissä menesty mutta en usko että he ovat tulosta tekevinä työntekijöinä menestyneet viikkopalavereihinkaan perustuvissa projektiorganisaatioissa. Sitäpaitsi, eikö ole työnantajan edustajan tehtävä yksilökohtaisesti seurata miten tyypit hoitavat hommansa. On heitä joita pitää potkia päivittäin kun taas eräiden voi luottaa tuottavasti etenevän viikkojakin ilman ohjausta.
Scrum&Agile hommissa pääpointti on, että koko ryhmä on vastuussa projektista. Homma tosin kulkee näppärästi metsään, kun biolannoite osuu tuulettimeen. Silloin alkaa johdon toimesta organisoitu syyllisten etsintä ja siinä putoaa sitten koko Scrum hommalta pohja. Leikitään ryhmätyötä, mutta samalla pitää varmistaa omat istumalihakset. Sen sijaan, että jelppaisit muita porukassa tai selvittäisit mystistä bugia, suoritat story pointseja asianmukaisesti fuskaten.
Koodikatselmointien perusteella tehty syntikirjasto kuulostaa irvokkaalta. Vähän niin kuin Venäjän lait, joiden perusteella kuka tahansa on syyllinen ja voidaan tarvittaessa tuomita. Tuollaisten katselmointien perusteella tuskin erotellaan muita kuin pahimmat tunarit. Vielä suurempi riesa eli hyväpuheiset psykopaatit, selvittävät tuonkin esteen, vaikka eivät koodata osaisikaan.
jo kauan sitten olin IT-talossa, jossa intoiltiin ISO-standardeista. Siihen kuului myös tuo koodin "tarkastaminen", joka kaatui siihen mahdottomuuteen, että se olisi vienyt firman tuloksen miinukselle, vaikka teoriassa kuulostikin hyvältä. Toisaalta, kun koodia ei tarkastettu, sai jokainen kirkasotsainen uusi koodaaja ohjeen ottaa pohjaa "vanhoista hyvistä" ohjelmista, jotka osittain olivat painajaismaisia sekasotkuja.
Jotta periaatteessa hyvä asia, kunhan se auttaa välttämään virheitä, eikä tulehduta työympäristöä.
Silti joka kerta, kun teen itse alokasmaisen virheen, tekisi mieli takoa päätä seinään jotta jos oppi sitten sinne paremmin menisi. Takana on vasta 27 vuotta RPG-koodausta, eikä loppua näy.
koodausta kutakuinkin riittävästi, eikä opit ja kokemukset ole edes vanhentuneita. Juu, olen myös
sertifioitu scrum-masterikin. Silti en allekirjoita kaikkia agilen ja scrumin oivalluksia, koska en näe niillä
ainakaan sen toimialan, jolla itse väännän softaa, softatuotannossa mitään tolkkua.
Esimerkiksi päivittäiset kokoukset ovat mielestäni pääosin turhia, viikoittaiset projektipalaverit piisaavat ja akuuteissa ongelmissa ei ole mitään estettä kokoontua spontaanisti vaikka viisi kertaa päivässä jos asia vaatii. Miksi pitää joka päivä kokoontua kertomaan pääosin samaa asiaa kuin edellisessä kokouksessa, kun ei päivässä kumminkaan aivan ihmeitä tapahdu. Toinen on katselmointi: Mitä ihmeen tolkkua on katselmoida kaikkea makkarakoodia ellei siihen sisälly mitään erityistä haasteen paikkaa? Hieman sama kuin parityöskentely: Tottakai jos tehdään jotain niin hankalaa että koko toimintaprosessi johon softa tulee, on vierasta, on hyvä olla käytettävissä ko. liiketoimintaa tunteva business analysti käsillä. Jos taas on tarkoitus että koko ajan on toinen olan yli toimettomana katselemassa jokaisen puolipisteen kirjoittamista, niin ei kyllä minulla pinna kestäisi sen enempää katselijan kuin koodarin roolissa. Pitää muistaa että näiden erilaisten katselmoijien, laatuvalvojien ym. varsinaiseen työhön osalistumattoman hangaround-porukankin palkka pitää maksaa siitä hinnasta joka softasta saadaan.
Projektipäälliköstä paljon riippuu, miten jengi tulee toimeen scrumin periaatteiden kanssa. Scrum on ihan ok tyyli seurata projektin edistymistä. Siinä vaiheessa mennään kuitenkin metsään, jos projektipäällikkö tulee selän taakse säännöllisesti kyttäämään mitä näytöllä tapahtuu. Eikä töiden edistyminen tapahdu ns. daily scrum meetingeissa.
Kuten meidän firmassa, jossa projektipäällikkö lukee myös sähköpostin selän takaa, jos sellanen on auki näytöllä. Tullaan koputtamatta selän taakse jne... Näinpä kerran työkaverin koneella ko. projektipäällikön kattomassa, mitä näytöllä on, kun tämä työkaveri oli vessaan menny ja jättänyt koneen lukitsematta. En tiedä sitä, että uskaltaako siitäkään sanoa sitten kenellekään. Ei varmaan täysin luvallista toimintaa? Kertokaa viisaammat?
Sitten julkinen vittuilu projektipäällikön asemasta: "aina samat virheet", "hyvin koodattu" jne... Kerran olin saman viikon aikana kahdessa eri projektissa koodaamassa juttuja. Pistin toisessa projektissa taskin stand by tilaan, kun en voinut edetä ilman toisen tyypin töitä, joka oli parasta aikaa koulutuksessa. Aloin sitten työstää toista projektia ja reilussa päivässä sain melkein valmiiksi aika laajan kokonaisuuden. Esittelin sitä sitten meidän tekniselle pomolle ja tämä projektipäällikkö tuli huoneeseen. Tekninen pomo sano tälle pp:lle, jotta nyt se on melkein valmis, että ainoastaan muutama juttu enää. Sitten tämä pp pysty vetäsemään siihen, jotta tämä tekninen pomohan sitten korjaa 2 pv meitsin tekemiä juttuja sieltä. WTF? Siis kyllä huumoria ymmärrän, mutta tämä oli mielestäni liikaa.
Koodirivien määrän seuraaminen on kanssa yksi, mitä tämä pp käyttää seuratessaan projektin edistymistä. No ok... Itse olen kolmen parhaan joukossa meidän firmassa koodirivien määrässä. Enkä tuota pelkästään html:laa. Siis sinänsä ei aihetta huoleen rivien seuraamisesta.
Mahdollisimman paljon rivejä, mutta rivien määrä ei kerro mitään. Joku voi vääntää samaa nappulaa viikon ja siihen menee 10 riviä ja toinen taas vääntää viikossa 1000 riviä. Rivien määrä ei ole hyvä mittari peilattuna tehtävän vaatimukseen. Mutta yleensä paljon rivejä tuottavat tekevät myös suurimman osan tehtävistä. Vai onko mielipiteitä?
ohessa simppeli ohjelma kahdella ääritavalla toteutettuna. Kuten hyvin voi huomata, ei rivimäärän perusteella voi tehdä mitään johtopäätöksiä. Toisaalta, jos pomo=genericPointyHairBossWhoDoesntKnowShit voi jälkimmäisellä tavalla esittää pomolle olevansa tehokas ja taitava
Itse väittäisin, että mitä vähemmän rivejä ohjelmassa on, sen modulaarisempi ja vähemmänbugi-herkempi se on.
public class HelloWorldPrinter{public HelloWorldPrinter(){}public void printHello(){System.out.println("HellO World");}}
public
class
HelloWorldPrinter
{
public
HelloWorldPrinter
(
)
{
}
public
void
printHello
(
)
{
System.out.println
(
"HellO World"
)
;
}
}
no toi sun tapa kirjottaa koodia ei menis katselmoinnista läpi ainakaan meillä. Oletko ikinä joutunut tekemisiin koodikäsikirjan kanssa? Tuolla tavalla vähillä rivillä koodaaminen ampuu itseään nilkkaan pitemmässä juoksussa. Voithan koodata noin, jos ohjelmat ovat hello world tasosia. Mutta, kun rakennetaan järjestelmiä, joissa on satojatuhansia rivejä koodia....
kerro kumpi on luettavampaa (ylempi taitaa olla basic esimerkki C:sta):
tuossa kahdessa ohjelmassa oli saattaa naurunalaiseksi tapa, jossa koodin tasoa mitataan sen pituudella. Kumpikin ohjelma toimii, luettavuus on molemmissa ala-arvoinen. Keinotekoisesti voidaan kasvattaa (tai kutistaa) ohjelmarivien määrää, järkeä tässä ei ole.
Tarkoitin koodirivien vähyydellä pikemminkin sitä, että luodaan oikeat luokat ja metodit ja sitten käytetään niitä, eikä jokaisessa paikassa jossa jotain "palvelua" tarvitaan, aleta koodaamaan uusiksi juuri siihen kohtaan. Näin kokonaiskoodirivimäärä todennäköisesti pienenee.
Olen useamman kerran toteuttanut uuden ominaisuuden isoon järjestelmään niin, että kokonaiskoodimäärä on kutistunut. Vanha koodi on ollut niin höttöä, että sitä on voinut poistaa suuria määriä, eikä ole kyse pelkästä formatoinnista. Olenko siis ollut todella tuottamaton?
Dijkstra oli oikeassa jo kauan sitten:
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger."
Ja jos nyt kiskaisen tämän takaisin otsikon aiheeseen, niin ketterissä menetelmissä on yleensä paljon parempia keinoja etenemisen seuraamiseen kuin LOC.
joka yleensä personoidaan johonkin yksittäiseen ihmiseen. SLOC on hyvä mittari, koska se on helppo laskea ja kaikki tietävät mistä on kyse. SLOC on huono mittari, koska se ei ole yksikäsitteinen eikä se kerro sisällöstä mitään. Se on kieliriippuvainen, organisaatioriippuvainen sekä ongelma-alueriippuvainen. Se on eräänlainen pituuden mitta. Jos minä sanon olevani 185 cm pitkä, niin olenko silloin myös tukeva ja mies tai jos sanon olevani 165 cm pitkä, niin olenko silloin keskimittainen nainen vai lyhyt mies. Onko minulla siniset silmät tai ruskea iho? SLOC:n sinnalle tarvitaan muita mittareita kuten syklomaattista kompleksisuutta ja/tai Halsteadin mittarit eikä silloinkaan voi antaa tulevan lottoarvonnan 7 oikein numeroita vaan edelleen pitää vähän arvuutella (kokemus parantaa arvausta).
SLOCin käytöstä työmäärän arviointiin: edelleen helppo laskea ja jos on käytössä historiatietoa yrityksen edellisistä projekteista, niin voi luoda vähän trendiä saman tyyppisille projekteille. Esim. jos edellisissä projekteissa on syntynyt 15 SLOC/päivä, niin voi hyvin arvata että saman verran menee jatkossakin. Siis työmäärää arvioitaessa. Mutta toteutuma voi tietysti olla jotain muuta.
Jos SLOC/päivä metriikkaa ruvetaan käyttään tuottavuuden mittarina, niin sitä saa enintään käytää projektin keskiarvona eikä ihmisten mittaamiseen. Parempia koon mittareita ovat funktiopisteet (kuka niitä jaksaa laskea) tai käyttötapauspisteet (tai käyttötarinapisteet). Parempia ja parempia...?!?!
Tunnustan: olen Sertifioitu ScamMaster. Tuliko minusta parempi ihminen tai ohjelmistoammattilainen tämän kurssin pohjalta? Tuskin. Scrum on hyvä, koska se pyrkii osoittamaan, että softan tekeminen poikkeaa konepajateollisuudesta malkoisesti. Se pyrkii parantamaan projektin ohjausta tuntemattomissa vesissä. Ja mikä parasta, se korostaa kommunikaation ja yhteispelin tärkeyttä. Eikä scrumissa ole projektipäälliköitä, vaan ohjaajia ja mahdollistajia eli ScrumMastereita. Ja nämä SCM:t voidaan erottaa virastaan projektiryhmän toimesta ja projektiryhmä voi valita uuden SCM:n. Scrumin tärkein anti taitaa olla se, että oikean työ tekijöille annetaan valta sanoa eri tehtäville työmäärä, johon he voivat sitoutua. Eli kun luvataan jotain, niin se sitten tehdään annetussa ajassa. Näin siis siinä scrum-rinnakkaistodellisuudessa, joka valitettavasti poikkeaa todellisuudesta. Scrum on etupäässä organisaation muutos ja se tapahtuu hyvin harvoin.
Keskusteluissa on tullut selkeästi esille se vallalla oleva (väärä) käsitys koodikatselmuksesta, että organisaation tulisi ohjeistaa katselmus. Koodin katselmointi on koodarin työkalua vastaava kuin debuggeri, jota kannattaisi omaehtoisesti käyttää. Eli pyyntö katselmoinnille tulee koodarilta itseltään eikä projektipäälliköltä tai linjajohdolta. Katsolmoinnin käyttäminen on yleensä koodarille vaikeaa, koska oman tuottaman koodin synnyttäminen vastaa joskus naisten synnytystuskaa ja syntynyt lapsi on aina maailman kaunein ja ihanin. JA JOS JOKU KEHTAA SANOA MINUN LASTANI RUMAKSI, NIIN.... Ketteryys pyrkii poistamaan tämän inhimillisen piirteen yksittäisestä koodarista vaatimalla, että koodi on yhteisesti omistettua eli kaikki koodaa kaikkien mokkuloita. Katselmoinnissa ei kuitenkaan kannata käydä läpi kaikkia 140 koodausstandardin kuvaamaa juttua, vaan noin 20-30 juttua, jotka ovat olleet virheiden ja hankaluuksien aiheuttajina organisaation samantyyppisissä projekteissa.
Sympatia vaan kaikille kärsiville, "been there, done that", "kuulkaa pojat, ei ne asiat vaihtamalla aina parane".
"Oikean työ tekijöille annetaan valta sanoa eri tehtäville työmäärä, johon he voivat sitoutua. Eli kun luvataan jotain, niin se sitten tehdään annetussa ajassa".
Mikäs sen parempi. Vaan kun 20 vuoden kokemuksella kaupallisen softan vääntämisestä käytännössä on ensimmäinen kiinnitetty ilmoitusluonteinen asia se koska homman on oltava valmis, ennenkuin edes tiedetään mitä ollaan tekemässä.
Scrumin ja agiilimenetelmien paha puute on mielestäni koodauskeskeisyys. Vanha kunnon vesiputos oikein sovellettuna se vaan oikeasti jyllää. Kun ymmärretään prosessi, mihin softa tulee, ja käyttötapaukset joita sen pitää osata, ja arkkitehtuuri miten se sopii ympäristöönsä, on itse koodaus lopulta se pienin ongelma koko hankkeessa.
ihan hyviä pointteja sinulla vaikken jaksanut lukeakaan.. Olen scrum/agile helvetissä osittain mukana siinä isoimmassa tehtaassa. En tunne yhtään työkaveria joka aidosti pitäisi kyseisestä projektinhallintajärjestelmästä, en yhtään (ihmistä).
Tarkoitus kuitenkin taitaa olla se, ettei yksikään tiimi pysy kasassa vuotta pidempään. Mitään luovuutta ei ole enää olemassakaan, ainoastaan kilpailua tiimien sisällä. Täydellinen kilometritehdas.
Vaikka 10 presidenttiä laitetaan samaan huoneeseen aina voi jotakuta osoittaa sormella, että sinä olet muuten mulkku. Jatkuvaa yt paskaa sataa niskaan kokoajan.
Todella, todella harvat uudet alalle tulevat jaksavat 10 vuotta kauempaa.
Niin urakehitys/guru sallikaa minun nauraa...;) Jos haluat ponnistella useita vuosia saadaksesi oman 'esimiehen' paikan itsellesi muutaman satasen palkankorotuksella, onneksi olkoon:-D
Gurut on ihan samanlaista tykinruokaa kuin kaikki muutkin, joko olet laskutettavassa projektissa kun yt:t alkavat tai et ole, todella yksinkertaista.
Vaikka kirjoitukseni onkin todella negatiivinen haluaisin kysyä, tuleeko enää aikaa esim. softapuolella, että esimiehet sanoisivat että nyt voidaan käyttää vuosi tähän projektiin aikaa, ollaan luovia ja tehdään parhaamme?
Sääliksi käy kokopäiväisesti agilessa mukana olevia. Ei olisi mukavaa hikoilla joka päivä mitä keksiä seuraavassa 'meetingissä'.
Eikö se toimiva ja vaatimusten mukainen ohjelma ole tärkeämpi kuin koodirivien lukumäärä? En minä ainakaan ole kiinnostunut siitä menikö siihen 100 vai 1000 riviä koodia, pääasia että toimii.
Managementin töpeksintä (epäonnistunut tuotekonseptointi/markkinointi) tulee niin kalliiksi ettei koodaamisen ole aina varaa vaikka joku tekisi sitä ilmaiseksi. Perinteisestihän tuotekehityskustannukset joihin "koodaus" sisältyy on rahoitettu tuotteen myyntituloilla ja vieläpä tilitetty osakkeenomistajille hyvät osingot. Mutta tällöin on ollut kyseessä taitava management ja hyvät, myyvät tuotteet.
Kiitos viestistäsi. Se on ainakin herättänyt keskustelua. Ensimmäinen ajatukseni viestisii luettuani viikonloppuna oli, että kysessä on trolli, joka provosoi keskustelua esittämällä asiat voimakkaasti kärjistettynä. Olisiko joku todella voinut ymmärtää ketteryyden noin väärin? Tänään päätin sittenkin ottaa asian tosissaan ja kirjoitin siitä lisää blogiini. http://leandeveloper.com/wordpress/2009/11/command-and-control-with-pair-programming/
