Качество срещу постижимост в софтуерното инженерство

Intro

В този момент се провеждат мозъчни атаки, където софтуерните инженери обсъждат дали да забавят доставката на софтуер, за да подобрят качеството му.
Тази статия се опитва да предложи техники за измерване на тези два абстрактни термина и е възприет мнение на активен майстор на софтуер за това кога да избере постижимост спрямо качеството и обратно.

http://devwijewardane.blogspot.com/2010/10/leather-school-at-santa-croce-firenze.html

Как да се измери качеството на софтуера

Нека започнем с това как НЕ да измерваме качеството на софтуера.

Сандро Манкузо, евангелист на Софтуерното майсторство, споменава в своите беседи:

Качеството не може да бъде измерено, но може да се усети.

Наистина има най-различни софтуерни показатели (# грешки, покритие на тестов код%, дублиране на код, цикломатична сложност), за да назовем няколко.
Склонен съм да се съглася с пъргавия цитат: „Когато показателят стане цел, той престава да бъде добър показател.“
Стремежът религиозно към спазването на който и да е показател ще направи някои числа да изглеждат по-добре в графиките, но не е задължително да подобрят качеството. В този процес това ще струва време за разработка, като се фокусира върху спазването на процесите, а не върху творческата работа.
Не ме разбирайте погрешно, аз съм голям защитник на TDD и очаквам 98% покритие на кода в основните модули на всеки проект, който пиша или чета. Въпреки това съм виждал и написал код с лошо качество със 100% тестово покритие и отличен код без тестове.

Има две специфични показатели, въпреки че обичам да измервам качеството
1. време за отстраняване на грешка (от докладване до отстраняване в производството). В Kanban терминът се нарича "Време за изпълнение"
2. четене на код
Как измервате четенето на кода? Намерете скала (например от 1 до 5) и попитайте софтуерните инженери, които активно участват или ще участват активно в писането на дадена кодова база, за да оценят нейната четимост! Обобщете го и вземете средното.
От съществено значение при измерването на четливостта или качеството е да поискате от хората, които ще участват активно, да гласуват. Не се доверявайте на мнението на нито един човек, независимо от трудовия стаж.
Каква е ползата, когато вашият най-старши инженер (особено когато той няма да се включи в проекта) счита качеството на софтуера за страхотно, и
хората, които ще се развиват в тази кодова база не са съгласни?

Единствената възможна употреба е да се докаже, че екипът е тъп, но най-вероятно това не е така.

Не вярвам, че има много глупави хора, които работят върху създаването на софтуер, камо ли, че във вашата организация се събраха куп от тях.

Изграждането на софтуер е това, което се движи и ще движи света напред поне няколко десетилетия. Всеки, който е усвоил занаята на изграждането на софтуер, се грижи дълбоко за изграждането на страхотен софтуер.

Доверете се на екипа

На ниво екип, когато предложението за качество има силни последователи в екипа, тогава трябва да бъде кристално ясно, че това е пътят.
Тогава е отговорността и задължението на водещите инженери да приведат всички сили, за да свършат работата правилно.
ЗАБЕЛЕЖКА: Не е достатъчно екипът да се съгласи, че качеството е ужасно, те също трябва да се споразумеят за плана за решаване на проблема с качеството.

Съгласявайки се, че качеството е лошо, но несъгласието как да се реши проблемът може да доведе екипа в безкраен цикъл, когато не се свърши работа.

Как да се измери доставността

Нека започнем с това как НЕ да измерваме постижимостта.
Не използвайте истории!
Историческите точки са чудесни, за да може екипът да добие представа за това, което потенциално може да бъде предоставено в близко бъдеще.
Ако това е показателят на вашата компания, когато тя стане цел за екипа, резултатите вече няма да са полезни.

Освен това НЕ измервайте постижимостта въз основа на постигането на ангажираност.
Екипът може много лесно да поеме ангажимент, за да изглежда успешен. Силните екипи често прекаляват с ангажиментите си, но липсата на ангажираност не означава непременно, че тяхната изпълнение е ниска.

Един от начините за измерване на резултатите е чрез вашата конкуренция. Това обаче изисква малко вътрешна информация.
Когато вашият екип изгражда функция за три месеца, а вашият конкурент го изгражда в половината от времето с половината хора, това със сигурност ще каже, че екипът на вашия конкурент има повече резултати от вашия.

Друго е просто ... да броим!

Брой функции, пуснати в производството за даден период!

Този показател е наивен, тъй като никоя от двете характеристики няма еднаква трудност или стойност.
Смисълът да се направи тук е:
Избягвайте да сте част от екип, който работи по голям пренаписване и не е давал нищо на продукцията от 12 месеца! Може да е страхотен проект, но 12 месеца в наши дни са много време. Нещата трябва да са се променили драстично в този период. Най-вероятно нуждата от този проект се е променила.

Предимства на резултатите

* заинтересованите страни са доволни
* инженерите са във възторг; те получават усещане за постижение
* инженерите са реалистични (изграждане на значение)
* повече артефакти са на разположение за изследване, когато трябва да се обърне внимание на качеството. Последният ви проект, който го направи в производството, е отлично ръководство за това какво да подобрите при изграждането на следващия по отношение на качеството.

заключение

Когато работите като инженер на конкурентен пазар, дългосрочната доставка трябва да бъде вашата движеща сила.
Жертва за изпълнение на качеството само ако това най-вероятно ще гарантира по-добра доставка скоро. Но бъдете внимателни, че „най-вероятно се гарантира“ е вярата на целия екип. Не се доверявайте на мнението на нито един човек, че това е пътят. Вземете поне трима старши инженери, за да се съгласите по този въпрос.

Изпълняемостта прави креативните хора щастливи, тъй като те получават опит в работата върху много различни неща. Освен това плаща за заплатите!

Изпълнявайки много проекти, прави хората по-мъдри да взимат качествени решения за следващия си проект, без да жертват постижимост.