(UA) IT/Tech Ukrainians in Canada
-
Я вище це дуже детально описував :-) і в цілому, естімейти часу - це не відповідальність девів, нащо мені тоді product owner 😂 Щодо "кожний дев - це архітектор" - як саме тоді ви впевнюєтесь, що high level архітектура однорідна, оптимальна, має сенс, scalable, maintainable, resource / cost optimal і тд і тп - тоді потрібна дуже тісна взаємодія, або дуже високий рівень взаєморозуміння між девами, інакше через пару років продукт може просто впертись у стіну Архітектурні рішення у нас доволі високорівневі та лишають достатньо місця девам to express themselves - ми не тільки не форсимо, скажімо, якісь конкретні паттерни, а навіть часто віддаємо вибір мови чи фреймворку на розсуд девів
-
1 chief architect, 1 просто архітектор, один я (свіженький архітектор, досі досить багато роблю в ролі principal dev) - тобто 2.5 мабуть девів ееее штук 16 здається
-
Архітектори ще десь є?
-
Ось гарна стаття щодо пойнтів та часу medium.com/serious-scrum/the-risks-of-estimating-time-as-an-agile-team-and-what-to-do-about-it-f31623f6c3a6 у нас ніхто не питає естімейти, тому що є historical velocity, є more or less accurately pointed tickets (це зона відповідальності девів), тому на базі цього можна _приблизно_ вирахувати естімейт у часі (це може бути відповідальністю product owner, може бути agile delivery manager) Це скоріше за все буде помітно точніше, аніж подивитись на таску і сказати, "наша команда із 5 розробників зробить це за 4 місяці"
-
Ви хочете, шоб оце деви робили? там ще сторінок 45 в цьому документі
-
Пиздець)