Шикарно, треба перечитати, читала років 20 тому, забулося 😍

То так, оці всі скрами з аджайлами — вони для інноваційних проектів (там дійсно треба брейнштормити), а коли 80% задач — це якийсь CRUD або задачі рівня третього курсу («розробіть мікросервіс для менеджмента каталогу книг бібліотеки») то там достатньо просто комусь спроектувати, розкидати задачі між собою та зробити.

Але при такій схемі (продуктивний Beaver 🦫 який може порішати складні задачі, якщо його не чіпати кожні 15 хвилин) ти — бас-фактор!

Для стабільності та диверсифікації бізнесу надійніше тримати пять хомячків мощністю 0.2 бівера.

Це керівнику потрібно, щоб робітник просто тихенько сидів робив «задовольний обсяг роботи» і не створював проблем

Давайте якось простіше, поясніть на прикладі скрам команди з 5 людей: де там альфа, де там сігма і за який ресурс ми бʼємося? За честь зробити таски?

Поганому гравцю вони заважають? Як у танцорів?

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

Та да, це вочевидь дічь. Але мені ще оце трохи дивно:

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

Навіщо збирати нараду, якщо багфікс очевидний? Це на кожен багфікс збирати нараду? Чим більше нарад — тим більш командний дух?

беремо якусь (невеличку) погану частину

Я не так робила — коли є задача, яка якимось чином торкається цієї «поганої частини» — то не просто робиш задачу, вставивши в старий гівнокод пару своїх красивих строчок, а покращуєш те що є (і ще навколо пару-тройку функций або весь файл) + робиш ту правку, яку запросив клієнт.

Таким чином, ти (чи QA) все одно ж будеш тестувати свою правку — заодно і протестуєш всі ці зміни. Можна навіть два pull requests прислати — один «рефакторинг» а другий вже «багфікс» чи що там тебе попросили зробити.

Ми так переходили з promises на async/await коли дістався чужий старий проект на промісах.

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

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

Не тільки донати, у багатьох родичі/батьки тепер знаходяться на їх утриманні (якщо цілими родинами виїхали з прифронтових регіонів)

Ну. Плюсів небагато:
1) Може це якась болєзнь вообще
2) Вільного часу від того не більше, бо навіть якщо ти поробив всі таски — треба +/- бути біля компьютеру, бо тобі можуть прилетіти запитання ітп, тобто ти не можеш за три години поробити всі таски і поїхати в СПА до кінця дня (а хотілося би 😂)
3) Якщо ти превишаєш норму — в тебе просто піднімається норма

1) В мене нема проблем з концентрацією, скоріш навпаки — проблема РОЗконцентрируватися коли робочий день закінчився, або хтось мені раптом шось каже/пише/дзвонить
2) Іноді сідаю за комп, зробила то-се-пяте-десяте — дивлюся вже 16:30 — так закопошилася з тими тасками, що сама не помітила, як день майже пройшов
3) Довгі роки треніровки => виработався скілл
4) У нас небагато мітингів, по суті в мене зранку в 9 стендап/планування і все, от якби кожні дві-три години був якийсь мітинг або зідзвон — то я би між ними тільки каву пила, точно би не було часу продуктивно думати/кодити
5) 4.5 роки на одному проекті (оце я динозавр) — тут в тасках середньої важкості вже з закритими очима знаходиш де баг, де фіксити, як зробити ітп. Зі складними буває що повозишся добряче.

Клаааааааааасссс!

Коли буде стаття як знизити продуктивність? Люди дуже просять бо не встигають ПР-и ревьювити, вчора пять відправила ще сьогодні три буде, якби не сиділа на доу було б ще пʼять 😂

даже вне спринта

Як це вне спринта? Він у вас овертаймить чи по вихідних працює?

Замените на «опытный участник команды разработки»

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

А тепер підвох: в скрамі-то нема техлідів! Є продукт овнер, скрам мастер і команда. Де там техлід? Є складна задача — хто робить дослідження? Хтось з команди. А в команді можуть бути люди з 20-річним досвідом і з 2-х-річним.

Я вже питала чатжпт “чим відрізняється скрам від комунізму” бо починаю пагано розуміти різницю — і там і там “власть народа” , і там і там партсобранія 😂

От:

Here’s a list of what Scrum and communism have in common:

Equality: Both promote the idea that everyone is equal, whether it’s in a team or in society.

Collective Ownership: Scrum encourages collective ownership of tasks, much like communism emphasizes collective ownership of resources and means of production.

Shared Responsibility: Both systems advocate for shared responsibility, with no individual being more accountable than others.

Lack of Hierarchy: Scrum minimizes hierarchy within teams, similar to communism’s goal of abolishing class distinctions.

Collective Decision-Making: Scrum promotes decisions made by the whole team (as in retrospectives or sprint planning), just as communism encourages collective decision-making in governance.

Idealistic Vision: Both Scrum and communism are based on an idealistic vision of how things should work when everyone participates equally and for the common good.

Focus on Community/Team: Both put the group (whether the community in communism or the Scrum team) above individual interests.

Resistance to Leadership Dominance: Scrum downplays the role of traditional leadership (like a manager), while communism resists dominant leadership and seeks to distribute power.

Utopian Appeal: Both Scrum and communism often promise an ideal or utopian environment, though in practice, achieving this can be very difficult.

Accountability by the Group: Scrum teams hold each other accountable just as communism relies on collective accountability rather than individual oversight.

Якщо для джуна 1 поінт — це 1 день, а для сеньора 1 поінт — це пару годин, то сеньор робить 4 поінта в день = 40 поінтів в тиждень, а джун робить 5 поінтів в тиждень.

Ви наплануєте роботи на 45 поінтів на спринт (40 сеньору і 5 джуну) а сеньор захворів — упс. Навіть якщо сеньор робить 2 поінта в день, а джун робить 1 поінт в день — якщо ви наплануєте на спринт 15 поінтів а сеньор захворів — у вас проблема.

У мене був прикол. ПМ захворіла і її не було на стендапі. Замовник мене питає «Коли ви це зарелізите?». Я дивлюся — залишилося 10 тасок по 2 поінта, а ми робимо якраз 20 поінтів в спринт. Думаю — мабуть, треба казати «через 2 тижні». А він як давай мене перевіряти — каже «А якшо хтось захворіє? А якщо ще баги знайдуться? А якшо те? А якщо се?» я так зрозуміла що треба казати 4-6 тижнів щоб точно не помилитися :D

платна, GPT-4o.

Він оперує не логічними послідовностями

Ну про pair programming начебто гОдна ідея. Правда робити всі таски в режимі pair programming я би не змогла.

Спитала чатжпт — якщо для джуна таска буде 20-поінтовою (якщо він буде робити сам), а для сеньора 1-о-поінтовою (якщо він буде робити) то він рекомендує робити pair programming і естимейтити скільки займе цей «pair programming»