Навіщо мені потрібен SCRUM порівняно з менш формальним, легшим процесом для моєї команди?

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

До цих пір я розвивався в командах по 4-5 членів дуже ефективно, повністю самоорганізований і без необхідності в будь-якому навчанні, методиці чи спеціальному програмному забезпеченні. Просто обговорення в кубиках, спеціальні зустрічі та огляди коду один на один. Зараз я перебуваю на роботі, де нам говорять про SCRUM - це шлях, і все, що йде разом з цим. Коли вони описують мені SCRUM, я читаю такі речі:

• Індивіди та взаємодія над процесами та інструментами
• Працює програмне забезпечення над всеосяжною документацією
• Співпраця з клієнтами щодо укладання договорів
• Відповідаючи на зміни протягом наступного плану

Це чудово, але все це здається мені здоровим глуздом. Чому це потрібно було кодифікувати? Потім мені кажуть, що методологія допомагає нам реагувати на зміни. Що конкретноаспекти SCRUM дозволяють мені бути настільки гнучким, що я раніше не досягав своїх спеціальних зустрічей, обговорень з кубами та зустрічей з планування розробників? Вони пояснюють необхідність мати робочий результат кожні два тижні або спринт. У моєму конкретному проекті немає «клієнта», програмне забезпечення не закінчиться рік і більше, а тим часом я, мабуть, демонструватимуться лише керівництву кожного місяця або менше. То чому ж явна потреба в доставці через кожний другий тиждень? Вони підкреслюють важливість зустрічі зі планування спринту, де вся команда викладає розповіді та завдання для наступного спринту. Це не відрізняється від імпровізованих зустрічей з планування, які я проводив у минулому. Чому це повинно відбуватися щопонеділка, і чому повинна брати участь вся команда? Я розумію концепцію кожного члена "власника" продукту, але факт полягає в тому, що лише кілька людей можуть дійсно сприяти розбиванню кожної історії на завдання, а решта просто дивитися простою.

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

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

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

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

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

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

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

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

Вірите чи ні, хороші команди програмного забезпечення існували ще до того, як Scrum з'явився. Scrum допомагає поганим виправлятися.

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

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

Інші системи раніше пробували, і люди пропонували незліченну кількість метрик, щоб спробувати виміряти розробку програмного забезпечення, але не змогли. SCRUM повертає проблему на голову і перекладає тягар вимірювання від менеджерів та самих розробників. Логіка проста: хто краще оцінити, скільки часу потрібно зробити, ніж ті, хто сам виконує роботу?

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

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

тощо.

Ви можете помітити, що все вищезазначене в основному робить дві речі:

1. Вони вимірюють роботу. Або робота, яку потрібно виконати, або виконана робота, або виконана робота.
2. Вони дуже намагаються уникнути проблеми надмірного програміста, щоб отримати кращу і реалістичнішу оцінку.

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

Особисто я вважаю, що метою SCRUM є задоволення старих організацій, де керівництво не може чи не зможе не відстати від слабшого процесу. Я працював архітектором (курка) близько року у відділі, який активно використовує SCRUM. Мій попередній досвід - це стартапи в Силіконовій долині, більшість з яких використовували набагато більш швидкі, спеціальні та дуже ітеративні (іноді щотижневі чи навіть щоденні натискання), орієнтовані на функції. Я вважаю SCRUM, щонайменше те, як ми реалізуємо його, є надмірним в процесі процесу (і в деякому відношенні більш важким, ніж водоспад (принаймні, з точки зору розробника). Щоб бути справедливим, я скажу, що один з аспектів нашого процесу, який Відхиляється те, що власники наших продуктів насправді більше схожі на вимог аналітиків в ІТ-організації. Як результат, вони, як правило, притупляють інформацію, що надходить від бізнесу, і ще гірше залишають бізнес непридатним для команди розробників (що вимагає регулярних послідовних вторгнень в історії користувачів). Тим не менш, у своєму майбутньому запуску я не використовую SCRUM. Я, мабуть, використовую його лише в тих випадках, коли керівництво вимагає додаткових накладних витрат.

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

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

PS: Scrum не передбачає, що ваш спринт повинен тривати два тижні. Це може бути місяць (ваш випадок).

Будь ласка, спочатку подивіться мої коментарі до цього питання.

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

Маючи 2 тижні спринти - важко. Дуже жорсткий. 3 тижні краще, але справді досвідчені та знайомі з командою процесу. У нас було 4 тижні чи місяць. Це дало нам достатньо часу, щоб "вирішити" так би мовити на початку і мати більше впевненості в кінці завдяки більшому тестуванню. Мені це сподобалось і я б дотримувався принаймні 3 тижні.

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

Це легше? Це безумовно. Але це не СКРУМ. Що мені подобається в SCRUM - це він сприяє дисципліні. Люди відчувають тиск, щоб доставити щось щоденне. Всі знають, що роблять інші, і він провалюється, всі це знатимуть. Навіть якщо хтось намагається приховати це (читати брехню), це стає очевидним набагато швидше, ніж з іншими процесами. Тож, коли ви розходитесь та спрощуєтесь, як у цій команді, ви повинні бути впевнені, що ви робите це з правильними людьми. В іншому випадку це може просто розпастись дуже швидко, принижуючи до безглуздих статусних зустрічей, де кожен просто залишиться і подумає: "Що я тут роблю?

Це мої два центи. Я роблю свій власний СКРУМ на кшталт розробки: планую роботу, розбиваюся на завдання, оцінюю їх, спостерігаю за прогресом. Це дійсно допомагає мені бути на вершині речей. Я застосував деякі речі з SCRUM до проектів, які я передавав на аутсорсинг, і це для мене вийшло чудово.

Просто ... будьте спритними ;-)

Я рекомендую вам ігнорувати scrum. Через пару років з'явиться нова примха, і ви будете менш цинічні і все-таки зможете охопити це всесердечно. Насправді ви могли швидко стати експертом. Тоді ви можете заробити багато грошей, написавши на ній книгу і виступаючи на конференціях.

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

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

Це чудово, але все це здається мені здоровим глуздом. Чому це потрібно було кодифікувати?

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

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

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

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

Оригінальний Scrum призначає місячні спринти. Існує неприємна тенденція до Agile Machismo у скороченні спринтів. ("Так, добре, що наші спринти - це лише один день ...") Замовник / Клієнт - це той, хто має повноваження сказати, що проект хороший, або потрібна більша робота. Якщо ви щомісяця демонструєте вище керівництво, вони, ймовірно, ваш клієнт, і ви, мабуть, вже дуже близькі до Scrum.

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

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

Ми не використовуємо Scrum на роботі. Ми використовуємо методологію, засновану в Agile and Lean, яка багато в чому схожа. Я використовував цей процес у колективах різної чисельності між 3-5 людьми, включаючи ведучих. Хоча існують відмінності, я думаю, що ви, можливо, зможете допомогти вам зрозуміти, чи корисний Scrum для вашої ситуації.

Виконання методики Explcit

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

Підписати

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

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

Вертикальні зрізи

Ми робимо всю свою розробку вертикальними зрізами. Це підтримує можливість робити вихід із завершеною функцією, а також інші причини.

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

Прийняття TDD

Ми використовуємо тестові рамки блоку для прийняття tdd. Це дає нам багато переваг.

• Велика реструктуризація не коштує багато часу для тестової переробки.
• Ми гарантуємо функціональність клієнтів.
• Ми охоплюємо інтеграцію коду.
• Підтримка практики розробки вертикальних зрізів.

Збірка завжди доступна

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

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

Постійна інтеграція

Кожен натиск генерує збірку через наш сервер збирання CI. Сервер збирання перевіряє код, проходить весь тестовий набір, тегує код і пакує його для розгортання. Підсилює нашу політику, що збірка завжди звільняється.

Оцінка точок для карт

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

Швидкість

У нас тривали тижні спринти. Кожної п’ятниці ми робимо планування роботи та визначаємо пріоритетність роботи на наступний тиждень. Виходячи зі своєї швидкості, ми маємо гарне уявлення про те, скільки «роботи» ми можемо виконати протягом тижня. Наша швидкість - середня та медіана загальної кількості балів, виконаних протягом тижня. Збільшення стандартного відхилення аналізується на предмет поганих оцінок (які завжди намагаються покращитись) або збільшення перерв (про які я говорю з менеджером). Швидкість також може бути використана для розрахунку точної дати завершення проекту, але тільки якщо це єдиний проект, над яким працює.

Поступове вдосконалення та дизайн

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

Здебільшого це правила, яких ми дотримуємось, і чому ми їх дотримуємось.

Мені це здається, що ти в дуже досвідченій команді з високим рівнем функціонування. Вітаємо, Scrum / Agile в основному формалізує те, що інтуїтувала ваша команда весь цей час.

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

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

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