Чи є право власності на функції належною практикою?

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

Для запису ми використовуємо SCRUM в SAFe, і ми працюємо на повний робочий день для кожної команди, що ділиться QA та власниками продуктів між нашими двома командами (Android та iOS).

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

Огляд коду втрачає значення.
Мінімальний обмін знаннями.
Збільшення ризику.
Втрата гнучкості команди.

Я правий чи це зовсім не погана практика?

agile team code-ownership

— mdelolmo
джерело

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

— Ixrec

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

— JensG

@JensG: Мех, я маю емпіричну теорію про те, що людина, яка мені найчастіше потрібна ("wtf? Чому він написав це саме так?") - це я, і як такий фактор шини для "запам'ятовування речей, які повинні були бути записані на той час "- 0. Це просто помітніше, коли мене заблокує хтось інший, тому що я переживаю за це замість того, щоб переглядати наявний код з нуля за власними силами ;-)

— Стів Джессоп

@SteveJessop: Безумовно, намагаючись переосмислити спосіб мислення інших людей, вивчивши купу KLOC їхнього коду, тоді як клієнт кричить на вас, що йому потрібне рішення зараз ( або ще! ) Можливо, для деяких людей крута ідея, але я Я не дурний, щоб побачити щось смішне, витрачаючи час, що я можу замість цього витратити більш продуктивно.

— JensG

@JensG: на щастя, мої клієнти краще соціалізовані, ніж твої. Тому я переживаю не стільки тиск, скільки займатися таким магічним мисленням, яке призводить до висновку, що важливість для мене справді призводить до того, що люди будуть меншими досяжності. Як такий, я подумав, що в тому, що ви сказали, є елемент жарту, так що так, я досить дурний, щоб знайти ситуацію, в якій ви компенсуєте незрозумілий код, намагаючись утримати кількох людей, які пам’ятають, як це працює. Тим більше, що такі wtfs часто є моєю власною дурною виною, а не моїми колегами.

— Стів Джессоп

Відповіді:

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

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

— Джейсон К.
джерело

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

— JensG

Фактор автобусів потрібно торгувати за рахунок вартості та ЯГНІ, і те, чи справді автобус калічить вашу організацію, чи просто спричинить багато клопоту. Якби це був вибір між втратою, скажімо, 3 годин на тиждень назавжди, гарантуючи, що двоє людей навчаються про певний біт коду замість одного, або втрачають, скажімо, 60 годин як разові, щоб хтось виховував себе щоб досягти швидкості, якщо хтось із ваших розробників потрапив, тоді у багатьох випадках ви вибрали разову вартість. Але з зазначених причин, у силосних знань є інші важливі недоліки (хоча і менш очевидні).

— Стів Джессоп

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

Але ти про це не говориш. Ви говорите про створення нової команди з одного - вирізати цю людину з решти коду. Це не чудово. Це обмежує їх кар’єру. Це додає ризику проекту / компанії. Це шкодить товариству.

Тому може бути деяка помірність, щоб відвернути це від поганої ідеї.

— Теластин
джерело

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

— Джейсон К.

@jason - звичайно, в команді повинно бути кілька людей, комфортних і здатних працювати над кодом. Але одна людина закінчиться експертом з теми, просто не працюючи над цим найбільше.

— Теластин

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

— Джейсон К .