it-swarm-eu.dev

Metrika, podle které mají být vývojáři zodpovědní

Zeptal jsem se na řádky kódu za hodinu a roztrhal jsem nový. Takže moje vyzrálá následná otázka zní:

Pokud ne řádky kódu, jaká je dobrá metrika, podle které lze měřit (podle hodiny/dne/jednotky času) účinnost vzdálených programátorů?

72
Kyle

Za 16 let jsem vlastně nenašel funkční metriku, jakou hledáte.

V zásadě musí být cokoli užitečné, musí být měřitelné, reprezentativní a neměnné (to je systém, který nemohou hrát chytrí vývojáři). Ve vývoji softwaru je prostě příliš mnoho proměnných, aby bylo možné měřit jako kusovou práci tímto způsobem.

Nejblíže dostanete pokrok oproti odhadům - to je, kolik úkolů plní v rámci dohodnutých odhadů. Trik je v tom: (a) získání dobrých a spravedlivých odhadů a (b) pochopení toho, kde byly odhady překročeny z dobrých důvodů, za které vývojář nemůže/neměl být obviňován (to je něco skutečně složitějšího, než se očekávalo). Nakonec, pokud vyvíjíte tlak na vývojáře příliš tvrdě, pravděpodobně najdete odhady, které se postupně plazí až na úroveň, kde se vždy setkávají nejen kvůli zvýšené produktivitě, ale kvůli vycpávaným časovým rozvrhům.

Pokud jde o odhady, jděte příliš daleko (snižte je, abyste vytvořili tlak na plnění) a vytvořte falešné termíny, které studie ukázaly, že nezvyšují produktivitu a pravděpodobně budou mít dopad na týmovou morálku (další informace viz Peopleware) ).

Ale v podstatě jsem zvědavý, jestli se díváte na mírně falešný problém. Proč se vzdálení programátoři liší od ostatních programátorů, pokud jde o měření produktivity? Jak měříte produktivitu vzdálených programátorů?

Pokud je to o tom, že jim nedůvěřujete, že budou pracovat vzdáleně, pak je to v podstatě širší problém s důvěrou. Pokud jim nedůvěřujete, aby pracovali z domova, pak musíte buďto důvěru založit, nenechat je pracovat z domova, nebo najít nějaký způsob, jak se přesvědčit, že skutečně pracují, když mají být.

101
Jon Hopkins

Metriky fungují nejlépe v továrnách a programátoři nepracují na montážní lince.

Plně chápu touhu měřit produktivitu.

Ale použili byste stejnou metriku pro rodinného lékaře i pro srdeční chirurga? A co Michelangelo, jak maloval Sixtinskou kapli, a nějaký chlápek v Mexiku vymrštil černé sametové obrazy Elvisa?

Louis de Broglie napsal doktorskou práci, která byla tak krátká, zkoušející ji odmítli - kromě toho, že de Broglie byl vysoce postavený aristokrat, a potřebovali dobrou omluvu. Zkoušející ji tedy poslali do Einsteinu, který ji nejen neodmítl, ale předal ji Nobelově komisi a de Broglie za ni získal Nobelovu cenu za fyziku o pět let později.

Numerická opatření nejlépe fungují na opakovaných pracích, jako je litina nebo šrouby na dveřích auta. Ale pokud opakujete kód, který byl proveden dříve, nepotřebujete programátora, stačí pouze kopírovat a vložit. Programování je v zásadě tvořivá disciplína a produktivita závisí zcela na tom, co děláte.

Někdy jsem vytáhl 1000 řádků kódu. Dnes opravím chyby souřadnicové geometrie a kód se může zmenšit. Kdybych měl opravit chybu v ovladači jádra Linuxu, mohl bych strávit celý den ladením a nepsat řádek nového kódu.

Měření produktivity programátora je velmi, velmi, velmi subjektivní.

Pokud chcete vědět, zda je Joe produktivní, najděte Sally a Ralpha, kteří vědí, co Joe dělá a je zdatný ve stejných oblastech, a zeptejte se jich.

Nejlepší numerický systém, jaký jsem kdy viděl, byly agilní plánovací pokerové body. To je jen fantastický způsob, jak se zeptat Joe a Sally a Ralpha, jak těžko si myslí, že Joeova nadcházející práce bude pravděpodobně. Pak můžete měřit produktivitu bodů za týden pro každého člena týmu. Ale i pak to chvíli trvá, než se zkalibrují odhady týmu, a čísla jsou nejasná a snadno zahoditelná.

Mnoho lidí chce odhady produktivity, aby mohli plánovat plánování. Je to druh teorie „zapojte se do projektu MS Project, podívejte se na kritickou cestu a existuje datum vaší lodi“. Nikdy jsem tuto práci nikdy neviděl - existuje jen příliš mnoho neznámých. Pokud to chcete, použijte vodopád, navrhněte všechno dopředu, nedovolte žádné změny objednávek a buďte připraveni na zklamání.

48
Bob Murphy

Jedinou metriku, kterou používám, je množství pracovního softwar, který produkuje pro dané množství peněz, který jsem investoval.

Bez ohledu na jeho harmonogram, pokud pracuje na dálku nebo ne, počet pozastavení, metodiky, které používá, nebo počet pracovních hodin.

Od pracovní software Mám na mysli:

Seznam funkcí definovaných uživatelem/zákazníkem, který splňuje požadovanou úroveň kvality

Od množství peněz:

Kolik uživatel/zákazník zaplatil za definované funkce + náklady na údržbu

Má tedy přímý vztah k tomu, jak je vytvořen, a kvalitě vyrobené práce, ale není vázán na žádné metriky řádků zdrojového kódu.

42
user2567

Potřebujete odhadnout, jak dlouho může nějaký úkol trvat, a zkušeného vývojáře nebo týmového vedoucího (který není spojen s těmito vzdálenými programátory). Účinnost se měří porovnáním jejich požadovaného času s odhadem. Abyste se ujistili, že odhady jsou dobré, můžete si náhodně vybrat několik úkolů a nechat je provést interní tým, který máte pod kontrolou.

23
user281377

Dalším zajímavým způsobem, jak měřit produktivitu, by bylo spočítat automatizovatelné testy přezkoumávané manažerem za den. Vývojář dostane:

  • bod pro napsání automatizovaného testu (a absolvování recenze) a jeho přidání do soupravy regresních testů,
  • bod, který jim umožní projít, aniž by to způsobilo jiné selhání regresního testu.

Vývojář a manažer mohou systém společně vylepšit:

  • společně dohodnout na důležitých oblastech vývoje a testování
  • nezávislé přezkoumání a spuštění testovací sady.
  • rozhodnutí nevytvářet funkci, která má omezené obchodní výhody, ale vyžaduje hodně vývoje a testování, které je třeba k dosažení této funkce. (Nejproduktivnější řádek kódu je ten, který jste se rozhodli nepsat, protože nepřináší žádné obchodní výhody).
  • rozdělení systému na architekturu (jako je model-view-controller), která usnadňuje postupný vývoj funkcí bez porušení celého systému.

Vývojář nemůže hrát metriku, protože:

  • redundantní testy budou blokovány kontrolou správce.
  • jemnozrnné testy mohou být blokovány kontrolou správce.
  • jemnozrnné testy zlepší kvalitu systému.

Manažer nemůže hrát metriku, protože:

  • odmítnutí příliš mnoha testů povede k opotřebení vývojářů.
  • požadovat příliš mnoho testů bude obtížné odmítnout pozdější termín.

Vývojář nemůže správce zašroubovat, protože

  • Každá dodaná jednotka funkčnosti s testy musí také projít regresní sadou. tj. to nutí vývojáře, aby se vyvíjel opatrně, aniž by porušil jiný kód.
  • Jakýkoli nárok na práci musí být prokazatelný absolvováním nových testů a regresních testů.

Manažer nemůže přišroubovat vývojáře, protože.

  • Každá požadovaná funkční jednotka musí zahrnovat klíčové testovací případy a odhad počtu testovacích případů potřebných k dokončení práce.
  • Je těžké požádat o agresivní rozvrh a/nebo volný přesčas, když zjevně žádáte spoustu práce.

Další velkou výhodou pro manažera je to, že může přinést nové vývojáře a vědět, že nebudou schopni dodat kód, který tiše narušuje systém (protože to regresní testovací sada chytí).

Velkou nevýhodou pro manažera je, že ho nutí připustit, že jeho systém je složitější, než se zdá na jednostránkovém popisu funkce. Druhou nevýhodou je, že transparentnost této metody ztěžuje vinu vývojářů za neúspěch v podnikání.

7
Jay Godse

Určitě je možné vymyslet různé druhy komplikovaných metrik pro hodnocení výkonu, ale na konci dne se značná část vašeho úsudku musí spoléhat na subjektivitu a vstup od lidí, kteří jsou blízko kodebázy.

Například je docela možné, že některý tým vyhnal vnitřně ohavný neudržitelný svah velmi rychlým tempem, což by mohlo dokonce splnit požadovaný termín a specifikaci. Je však technický dluh z tohoto druhu pracovního stylu horší, než kdyby tým vyřadil něco robustního a udržovatelného, ​​ale posunul termín o několik týdnů? Záleží.

Pokud je cílem otázky vyřešit nějaký problém s produktivitou, řekl bych, že to, co manažer ve skutečnosti dělá, aby usnadnil práci týmu, je stejně důležité nebo důležitější než jakákoli měřicí technika používaná k hodnocení tým. Je to obousměrná ulice. Jinými slovy, říkám, že metriky jsou v pořádku, ale pokud chcete více z jakéhokoli týmu, konečnou otázkou je, zda manažer dělá vše pro to, aby tým mohl být produktivní.

To jde daleko za rámec psaní specifikace, nalezení týmu, házení spec "přes zeď" a kliknutí na stopky.

6
Angelo

Několik nápadů:

  1. implementovány funkce
  2. opraveny chyby (také účet pro chyby později znovu otevřené QA)
  3. uživatelské stížnosti vyřešeny (všimněte si, že to není stejné jako 2 - jedna vážná chyba může být bolest v krku, zatímco 100 překlepů nemusí být tak důležité)

Možná budete chtít sledovat:

  1. Pokrytí kódu testy
  2. Pokrytí kódu interní dokumentací
  3. Pokrytí funkcí externí (uživatelskou) dokumentací
2
StasM

Měřte stejným způsobem, jakým jste měřeni zákazníkem. Z hlediska funkčního kódu, ale v menším měřítku.

Stanovte krátké cíle - týden nebo dva - a zjistěte, zda programátoři cíle plní, a to uspokojivým způsobem.

Důrazně bych doporučil peer review kódu, protože to vám umožní chytit špatný kód dopředu.

2
user1249

A co míra prodeje produktu/služby.

Někdy jsem slyšel, že se tomu říká provize/procento hrubé

Lidé kupují dobré výrobky, že?

Podnik chce produkt prodat (nebo možná službu, za to stejný rozdíl)

Takže pokud je to, co chcete, změřte to.

Trochu jako říkat lidé, kteří navrhují auto, které získává dobré recenze a prodává dobře, odvedli opravdu dobrou práci.

Nyní přijměte tuto metriku a programovací tým bude chtít komunikovat s prodejcem ze dvou důvodů.

  • Nadějné nedobytné

  • Neprodávat produkt zákazníkům efektivně

1
Tim Williscroft

Psaní kódu/programování není jako kladivo na hřebík. Stejně jako „psaní“ obecně, není to něco, co můžete použít také obvykle metriky - podle mého názoru.

Nemohli byste se jednoduše podívat na jejich check-iny, nebo co udělali prostřednictvím peer-review, code-review?

Nebo víte, jestli skutečně produkují pracovní kód a řešení, která řeší problémy?

0
Jack Marchetti