в любой хорошей компании есть какой-либо выработанный подход к разработке, не обязательно agile, которого все придерживаются. В таком случае каждый занимается своим делом
Все же мы говорим про выгорание, а при такой системе, его получается избежать на сколько это возможно.
По мере роста своих знаний ты получаешь все более сложные задачи
видишь свой рост, а когда ты его видишь - откуда браться выгоранию?
Есть коллеги, с которыми ты на митинге обсуждаешь проблемные места. Коллеги могут помочь и подсказать как лучше сделать.
без лишних напрягов и стресса. Ты получаешь удовольствие от работы.
Agile почти рифмуется с «выгорай»
Но недели сменились месяцами, и мы начали ощущать на себе некоторое «выгорание». Дело в том, что какой бы идеальной ни была методология — всегда будут вылезать незапланированные баги, которые требуют больше времени, чем планируется. Чтоб латать все эти дыры и в понедельник выглядеть так, будто у тебя всё идеально, приходилось работать на выходных. Почти ежедневные овертаймы даже не обсуждались — каждый думал над тем, что ему нужно будет говорить на следующий день на SCRUM-митинге. И ситуация была такова, что никто не хотел выглядеть на собрании «слабаком». Поэтому каждый старался побольше сделать вечером и пораньше прийти на работу, чтобы успеть к 11 что-то закончить и сказать что-нибудь в духе — «Этот функционал готов, но его нужно потестить» или «Новый сервис работает, но у меня не было времени его полностью проверить». И звучит вроде бы хорошо — что-то работает, что-то готово, что-то функционирует, осталась лишь мелочь, ерунда — потестить.
Часто используется agile
Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
я ведь не DBA
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.4/angular.min.js"></script>2019/01/24 07:07:25 [error] 8#8: *5 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 172.24.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://172.24.0.2:9000", host: "localhost:6080
location ~ \.php$ {
fastcgi_pass php:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/site.loc$fastcgi_script_name;
include fastcgi_params;
}
2019/01/24 07:07:25 [error] 8#8: *5 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 172.24.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://172.24.0.2:9000", host: "localhost:6080
location ~ \.php$ {
fastcgi_pass php:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/site.loc$fastcgi_script_name;
include fastcgi_params;
}
Часа два ломал голову....