Недоліки вертикальних історій користувачів

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

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

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

Які ще є недоліки вертикально нарізаних історій користувачів?

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

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

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

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

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

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

Я багато думав над цим точним питанням.

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

Для деякого передумови: я працював у проектах з повнорозмірними розробниками, однорівневими розробниками, вертикальними (повними стеками) командами, горизонтальними (однорівневими) командами та діагональними командами. Під діагональною командою я маю на увазі, що містять усі рівні, необхідні для історії, але не обов'язково всі рівні в системі, а також, можливо, містять кілька розробників, орієнтованих на один і той же рівень; Іншими словами, вертикальний за духом, але, можливо, дещо горизонтальний за зовнішнім виглядом або деталізацією.

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

Поки я сформулюю свою думку наступним підсумковим порівнянням:

Горизонтальні команди

Переваги:

• Сприяє гарному розділенню проблем та слабко пов'язаному рівням
• Набагато простіше управління розподілом робочого навантаження
• Легке для спеціаліста технічне керівництво
• Виховує внутрішньорівневу співпрацю, кращі практики, гордість та культуру досконалості
• Вирівнюється з природними / виникаючими моделями спілкування

Недоліки:

• Може призвести до ізоляції ярусів і, таким чином, перешкоджати міжрівневому спілкуванню
• Увімкнює культуру рівня "міхур", якщо не пом'якшується
• Складно скористатися генералістським керівництвом
• Заважає генералістам

Вертикальні / Діагональні команди

Переваги:

• Усі частини історії користувача в одній команді ("одноповерховий магазин")
• Спеціально допомагає надавати n-ярусні історії в одному спринті (хоча це вам справді потрібно?)
• Сприяє міжрівневій співпраці та зростанню загальнонаціональних навичок
• Підтримує генералістів

Недоліки:

• Набагато складніше управління розподілом навантаження
• Дозволяє погано розділяти проблеми та щільно зв'язані рівні
• Перешкоджає спеціалізації шляхом зменшення внутрішньорівневого спілкування; важко зрозуміти, як культура передового досвіду могла виникнути з цієї структури, не додаючи пом'якшуючих горизонтальних / спеціалізованих поведінок

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

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

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

Одне застереження: я, мабуть, упереджено вважаю, що будь-яка людина у сучасному світі розробки програмного забезпечення вважає твердження про загальні здібності без вагомих доказів, хоча я знаю кількох рідкісних виняткових загальних фахівців. Я відчуваю, що загальність є справді високим (вертикальним?) Порядком, особливо, коли кожен рівень зростає у складності та з поширенням альтернативних мов / платформ / фреймворків / розгортань, кожен задовольняючи різні потреби. Особливо в ці дні, джек з усіх торгів може бути легко господарем. Також, анекдотично, я вважаю, що більшість людей хочуть трохи спеціалізуватися, знову ж таки, за деякими винятками.

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

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

Такі речі неминучі, але не є блокаторами. Я намагався боротися з цим двома способами:

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

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

Я також не знаю жодних недоліків, проте вертикальні історії можуть бути реалізовані погано.

Коли я вперше розпочав свою кар'єру, я приєднався до команди, яка хотіла займатися XP, але у них не було досвіду. Ми допустили ряд помилок, використовуючи вертикальні історії користувачів.

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

Перехід на створення вертикальних історій вирішив ці проблеми та зменшив / усунув відходи повторної роботи для інтеграції.

Існує ряд практик XP, які підтримують такий спосіб роботи. Кожен повинен мати можливість працювати в будь-якій області, і всі очікують, що вони виправлять виявлені помилки ( Колективне право власності ).

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

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

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