Як виглядає добре "визначення зробленого" для зрілої команди?

Переглядаючи приклади визначень зроблених у різних джерелах, вони зазвичай включають такі пункти, як

• код виконано
• одиничні тести виконуються
• код рецензований або парний
• код зареєстрований
• оновлена ​​документація
• …

У нашій команді у нас є подібний список, але ніхто його ніколи не дивиться, тому що ці пункти здаються настільки очевидно очевидними, що нікому не прийде в голову пропустити будь-який із цих кроків. Тож нам було цікаво, чи це в основному інструмент для команд, які переходять до спритного процесу, і чи не варто ми його просто позбуватися.

З іншого боку, багато літератури стверджує, що всі високоефективні команди мають чітке визначення зробленого. Цей вид натяків, що ми можемо пропустити можливість покращитись тут.

То які приклади чітких визначень, зроблених для зрілої команди? Які бали вони зазвичай включають?

Настанови існують для всіх. У зрілому колективі, як ви вже згадували, це роблять усі, тому це не означає, що там немає місця. Припустимо, приєднується новий член, який раніше не піддавався цій методології. Маючи структуру на місці, це було б для нього життєво важливим. Йому не доведеться турбувати інших членів або не "забувати" результати.

На мою думку, перерахуйте все, включаючи очевидне. Можливо, є "короткий чіт-лист" для очевидних, якщо це допоможе тим, хто хоче коротший список, але розглянемо випадок скачування нових членів.

Це ітеративний процес, і кожного разу, коли ви бачите щось, що можна вдосконалити, додайте це у визначення зробленого. Понаднормово, ви складете список, який стосується вашої компанії. Ананн вже згадувала деякі, які варті того.

Тільки тому, що точки очевидно очевидні, не означає, що люди завжди їх виконуватимуть. Візьмемо ще два приклади - пілоти та хірурги. У кабіні комерційного авіалайнера або операційної кімнати є кілька людей, які мають між собою добру освіту та досвід. Однак все одно йдуть не так - кроки робляться не в порядку, щось забувається, щось робиться неправильно. Я бачив на ряді сайтів джерел, що велика кількість (до 70%) аварій на літаках, пов’язаних з помилкою пілота, можна було запобігти контрольним списком . У медичному світі, до 29% судових процесів щодо недосконалості в Нідерландах можна було запобігти за допомогою контрольного списку, вважають дослідники. Хоча ці люди пройшли навчання, і за заднім числом, ймовірно, легко було б ідентифікувати те, що вони зробили не так, все сталося, що спричинило їх затримку. Я ще цього не читав, але Маніфест Контрольного списку повинен бути актуальним. Це написано з медичної професії, але переваги зробити контрольний список або блок-схему видимим як нагадування про те, що робити, стосуються будь-якої професії.

Отже, першим кроком було б скласти список речей, які є частиною вашого визначення зробленого, і зробити його видимим. Не має значення, наскільки очевидно це завдання, якщо воно має бути завершеним, щоб історія вважалася виконаною, вона повинна бути в цьому списку. Список повинен бути десь видно команді. Зауважте, що це не повинно бути нічого вигадливого чи формального - можливо, це лише низка питань, які кожен повинен задати собі, перш ніж історію можна назвати виконаною.

Крок другий - це вирішити, що стосується цього контрольного списку для вашого визначення зробленого. Все, що вам потрібно зробити для виконання завдання, повинно бути конкретним, однозначним, прийнятним та реалістичним. Це також повинно знаходитись в контексті часу для розгляду зробленого. Наприклад, вам не потрібно включати "змінити код" або "змінити дизайн" у визначення зробленого - якщо вам не потрібно було змінювати робочий продукт, історія не потребувала.

Я б підозрював, що хорошим контрольним списком, який послужить основою для визначення зробленого, буде:

• Чи були оновлені всі асоційовані одиниці, інтеграція, система та тести прийняття?
• Чи перетворився робочий виріб у звільнену форму? Наприклад, вбудований код, документація у форматі файлу, що експортується, тощо.
• Чи були рецензовані всі асоційовані робочі товари? Приклади робочих продуктів включають вихідний код (виробництво та випробування), коментарі, конструкторські документи, процедури тестування та посібники користувача.
• Чи були виконані та пройшли всі пов'язані тести (на всіх рівнях тестування)?
• Чи був об'єднаний код у сховище інтеграції?

Звичайно, вам потрібно придумати чітке визначення зробленого, що включає будь-які інші дії, які ваша команда та ваш клієнт відчувають додаткову цінність. Якщо він знаходиться у контрольному списку, це має бути щось, що потрібно зробити, щоб додати кому-небудь цінність (команду, замовника, користувача). Чітко перерахувавши те, що ви робите, ви також можете виявити та усунути сторонні дії для покращення процесу.

Це насправді звучить як ви один щасливий хлопець:

У нашій команді у нас є подібний список, але ніхто його ніколи не дивиться, тому що ці пункти здаються настільки очевидно очевидними

Ваша команда вже "зріла" ;-). Але завжди є можливість для вдосконалення!

До вашого питання:

То які приклади чітких визначень, зроблених для зрілої команди? Які бали вони зазвичай включають?

Угорі списку ви можете додати:

Різні показники якості коду: - Нестабільність, абстракція - LOC проти DLOC (документально підтверджено) - тощо.

Основним правилом може бути те, що показник не повинен погіршуватися при здійсненні комісії. Зверху ви можете сформулювати "зроблено: зExcellence", якщо хтось насправді робить показники покращитись. Хоча це (показники покращуються) зазвичай не є частиною фаз розвитку (нових можливостей), а фазами рефакторингу.

В одній з моїх минулих компаній у нас було визначення поняття "зроблено", яке говорило про те, що ваші показники повинні залишатися нижче певних порогових значень, якщо ви переходите вище, ви ще не виконали. (Цикломатична складність ніколи не повинна перевищувати 15, якщо у вас немає дуже-дуже хорошого виправдання, як складні калькування.)

Те ж саме стосується і типу порушень Checkstyle, особливо якщо у вас є спеціальний набір правил для перевірки стилів коду ваших команд. Якщо ви порушуєте стандарт кодування, ваше ще не зроблено.

Тоді ви не могли виконати UnitTest, ви могли також виміряти покриття коду. Якщо не менше 50% покрито, ви не зробите. Хоча це і є хитке визначення зробленого, оскільки ви повинні мати тести для основних / головних / критичних методів, а не обов'язково для 100% бази вашого коду.

О так ... і якщо у вас є (вам слід) сервер CI з автоматизованою інтеграцією гілок ... ви будете робити лише в тому випадку, якщо ваш комітет у відділенні DEV об'єднався з поточною LIVE-відділенням і не спричинить жодних помилок. (Тести одиниць тощо)

хммм ... це все, що я добре пам'ятаю, знаю з минулих компаній / проектів, про яке не згадувалося у вашому списку.

Я сподіваюся, що дав вам кілька ідей ;-)

Ура,

anann

У середовищі TDD / BDD визначення "зроблено" (технічно "Кодекс завершено", оскільки визначення Метса S "дійсно" зроблено ") є досить простим:

• Усі автоматизовані тести проходять (ці автоматизовані тести повинні включати нові, написані для відповідної історії, щоб перевірити, чи потрібна функціональність чи поведінка існує та працює)
• Переглянуто перевірку коду (принаймні один старший розробник команди задоволений тим, щоб ваша робота стала частиною кодової бази, і щоб ви не «обманювали» чи «не зламали» свій шлях через історію)
• Здійснюйте успіх (включаючи бот для складання, проходячи всі автоматизовані тести, показники покриття коду, перевірки стилю копів тощо)

У цей момент можна рухатися далі. Ці три моменти мають вирішальне значення, але це все, що має стосуватися середнього кодера команди. Написані або неписані, вони є непорушними в середовищі TDD. Документація, коли кодери - це ті, хто робить документування, є додатковим моментом. У моїй останній команді Agile документацію обробляли БА / КА; вони знали, що хоче клієнт, запустили UAT і, таким чином, найкраще змогли документувати нову функцію таким чином, щоб вона мала значення для клієнта, тому документація не була частиною визначення кодера як "зроблено", хоча це було частиною визначення команди.