Автор читал какие-то книги на тему инвестиций?
Советую хотя бы The Simple Path to Wealth: Your road map to financial independence and a rich by J L Collins
В ней доходчиво объясняется, что, выбирая конкретные акции на рынке, показывать доходность при долгосрочном инвестировании выше S&P 500 удается лишь 2% инвесторов.
То есть вы не смогли найти хорошего руководителя и решили стать "бирюзовыми"?
Что будете делать при двукратном росте отдела?
Какие объективные метрики можете показать в доказательство эффективности данного подхода?
Хорошо, вот написали вы в личный чат «Поправь Х» и «Ревью обязательно» в общий, но разработчик не выполнил необходимое. Дальше что будете с ним делать?
Акцент статьи не на разборе конкретного кейса, а на том как конструктивно передать обратную связь своему сотруднику. Иван — руководитель, считаем по умолчанию, что он им стал заслуженно и более компетентен, чем остальная команда.
Ок, в ваших терминах моя статья про «методологии управления разработкой». Однако, везде в литературе «методологии управления разработкой» == «методологии разработки».
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.
Проект — это не только документация и требования. Это также планирование, управление качеством, стоимостью, рисками, людьми, коммуникациями и много что еще. Всем этим часто и занимается методология разработки.
Так что нет, я не противоречу себе.
А что, принципиально, поменялось с 1999 года?
Чем вам не угодил DevOps? Это набор практик, методология, направленная подружить разработку и сопровождение, наладить быструю и безболезненную доставку продукта.
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.
Об этом и написано в самом начале статьи!
Поделитесь, пожалуйста, если бы компенсация была соразмерной в двух компаниях, что для вас стало бы определяющим фактором?
"Бояться и управлять рисками на проекте - это не одно и то же" (с)
— Ну, хоть что-то у нас в безопасности!
Советую хотя бы The Simple Path to Wealth: Your road map to financial independence and a rich by J L Collins
В ней доходчиво объясняется, что, выбирая конкретные акции на рынке, показывать доходность при долгосрочном инвестировании выше S&P 500 удается лишь 2% инвесторов.
Если все прочитали | когда все прочитаете, напишите мне, подкину еще)
Один из лучших комментариев и отличное дополнение к статье, плюсую!)
Я ведь написал почти не освещен, так что строго говоря я никого не обманул.
Я публикую свои мысли про процесс увольнения, чтобы подытожить опыт, который я получил. Не нравится — не читайте.
Вместо негатива рассказали бы лучше какую-нибудь веселую историю про увольнение из собственного опыта. Пятница же!)
Поделитесь, пожалуйста, опытом, как построить самоорганизующуюся команду?
Меня интересует, как влияет такая организационная структура на эффективность подразделения. Про мотивацию и вовлеченность персонала понятно, она выше.
Еще вопрос, кто принимает решение о том, что нужно расширять штат. Загруженный сотрудник сам создает таску и доказывает всем, что он сильно загружен?
То есть вы не смогли найти хорошего руководителя и решили стать "бирюзовыми"?
Что будете делать при двукратном росте отдела?
Какие объективные метрики можете показать в доказательство эффективности данного подхода?
То, что вы подразумеваете под методологией разработки («как писать код, cнизу вверх или сверху вниз, TDD и прочие *DD») — это программистские техники и практики.
Отвечая на ваш вопрос сверху: Нет я ничего не путаю и не смешиваю, я хорошо разбираюсь в вопросе.
Хорошо, тогда поясните, пожалуйста, где по вашему мнению граница между методологией разработки и методологией управления разработкой?
Во всем должен быть баланс, да.
Так что нет, я не противоречу себе.
Работали по обоим процессам разработки?
Меряться не буду.
Чем вам не угодил DevOps? Это набор практик, методология, направленная подружить разработку и сопровождение, наладить быструю и безболезненную доставку продукта.
Водопадная модель процесса, безусловно, является более «тяжелой» по сравнению со Scrum.