Кто должен исправить ошибки в среде Толпы / Гибкой среде? [закрытый]

Люди должны исправить свой собственный код. Воспользуйтесь тем фактом, что никому не нравится возвращаться и исправлять старые вещи, когда они могут писать новые. Если можно определить разработчика, ответственного за ошибку, убедитесь, что он несет ответственность за ее устранение. Это побудит разработчиков быть более прилежными при написании чистого кода с первого раза, поскольку никто не хочет, чтобы его считали человеком, который должен исправлять то, что они сломали. Это верно и во время разработки, когда кто-то ломает текущую сборку.

Обновление : Сказав это, я не обязательно буду категоричным по этому поводу. Потребности клиента превыше всего, и если человека, создавшего ошибку, нельзя переназначить для исправления, возможно, вам придется назначить исправление кому-то другому.

ScrumMasters don't allocate developer resources. ScrumMaster is a role fulfilled by someone on the Team.

That aside, the Product Owner is the "on the Team project manager", and should be fighting to secure the resources that are needed to stablize the product into production.

Engineering practices have to be improved so that the Team(s) are approaching zero bugs. "Bugs" that live past the end of a Sprint have to go on the Product Backlog to be prioritized by the the Product Owner.

This is a very interesting topic, project management is vital and the apprpriate allocation of resources is essential.

One point I would raise is that having dedicated bug fixers may increase the quality of the code. If I was developing code that had my name against it that I knew other people were responsible for I would do everything I coudl to make sure it was good code.

Perhaps a combination approach is required.. You could take a couple of developers on any project - a different pair on each project - and make them resposible for the bug fixing phase outlining that responsibility up front. That way they can ensure they are up to speed as the project goes along as well as a handover at the end. Your resource allocation is easier and the client gets top notch support.

Just a slightly different way of looking at it.

Cheers Nathan

Ваша команда НЕ должна начинать работу над новым проектом, пока не будет выпущен текущий. Я думаю, что большинство практиков схватки будут утверждать, что в схватке нет места для UAT (как это было сделано в водопаде). То, что вы ищете, называется стабилизационным спринтом, и это ваш последний спринт прямо перед запуском. Над этим работает ВСЕ команда. В течение этого времени работа над ошибками в последнюю минуту, улучшения внешнего вида графического интерфейса пользователя, развертываемая документация, справочные руководства, обучение эксплуатации и длительные обеды. Это также потенциально прекрасное время для команды, чтобы узнать что-то новое самостоятельно, без «давления», связанного с поставкой невыполненных задач, или немного расслабиться перед тем, как начать что-то новое. На основе ожиданий вашего клиента по срокам UAT; если он имеет тенденцию быть на более длинной стороне; вы также можете отложить на этот спринт задачи, не связанные с клиентом, такие как мониторинг журналов, создание сценариев настройки сервера, экраны обслуживания или создание других дополнительных инструментов.

Что бы вы ни делали, не выполняйте никакой работы за пределами границ спринта. Это скользкий спуск к забвению, похожему на водопад.

I think bugs should be fixed by the original developer. Making developers to fix bugs in code that was written by someone else could take a lot more time and moreover could make them demotivated since fixing bugs is not that very exiting.

I vote for #2. As a developer I hate context switching and that's what you essentially impose with #1. As for the code ownership issue, having developers own pieces of code is an anti-pattern. Strive for shared ownership: introduce pairing, rotation etc.

To second @kevindtimm's comment, UAT is just another sprint. Perhaps w/ less developers.

On the other hand, the core of Agile Software manifesto is to deliver business value incrementally, so ideally you're supposed to push to PROD at the end of each sprint. If so then shouldn't UAT be part of every single sprint. Isn't that what the Demo is for?

I am a lead developer in a Scrum driven team. The way that we tend to work it in my organisation is this:

Before the starts of a sprint each developer will be allocated a percentage of how productive we think they are going to be during the sprint. For example a more skilled more experienced developer will probably be able to be productive 70-80% of his total time during the sprint. This gives time for unexpected meetings, bug fixes. I will come onto the bug fixes in a moment. We will get the estimates for all the tasks signed off and then plan the developers work.

Going into the sprint the developer will carry out his planned work and complete his own testing. If Possible as each block of work is completed another testing phase will take place either by the Scrum leader or the product owner (project manager) just to make sure that there isn’t anything glaringly obvious that needs to be looked at. Anything that comes up in this testing phase goes straight back to the developer that wrote it to complete in the sprint. The way we see it is that the team has effectively committed to completing the tasks given to us at the beginning of a sprint so we needs to complete them one way or another.

If an urgent bug comes into the team and it has to be done right this minute then myself and the scrum leader will take a view on whether or not it it is possible to get it done without effecting the planned work depending on how well we are doing. I.E. if we are half a day ahead of schedule and the estimate on the bug is half a day we will do it without changing the planned work. If that’s not possible we go back to the product owner who decides what it is that has to be pulled out of the sprint.

If a non urgent bug is assigned to the team part way through a sprint then the product owner give it a priority and it will remain in our pot. When the product owner then comes up with our next set of objectives he will prioritise the bugs and the project work together and these will become our planned items for the next sprint.

The thing to note is that it doesn’t matter which project the bug came from. Everything has a priority and that is what needs to be managed. After all you only have a certain development resource. When it comes to which developer does it that depends on several things. you don't always know exactly whose code introduced the bug. Especially if it’s from a very old project. If the same developer can fix it then there is obviously a time benefit there but that exact developer might not be available. The way that we try and work it is that any developer should be able to work on any given task. In the real world this isn't always possible but that that is always our end goal.

I realise that I have been beating around the bush here but in answer to your question about who should do the bug fix in short this is what I would say:

• If the bug is identified during the same sprint that the work was being done then send it back to the original developer.
• If its urgent then it has to go to the best person to do the task because it needs to done as fast as possible. That might not be the person that originally wrote the code it might be someone with more experience.
• If you have prioritised and planned the bug then you should also have time to work out who is the best man to do the job. This would be based on the other work that needed doing, the availability of developers and your general judgment.

With regards to handovers these should be fairly minimal. At the end of the day your developers should be writing code in a way which makes it clear, clean and obvious to any developer that has a task to revisit it. It is part of my job to make sure the developers on the team are doing this basically.

I hope that this helps :)

I really don't like option 2) because:

• It gives people the feeling that the job has been done while it hasn't (it's not DONE, there are bugs),
• I think people should be responsible for the code they wrote, not others,
• I don't think that "bug fixer" is a job, you are not respecting people when doing this.

So option 1) has my preference (but please stop talking about resources and resourcing).

Finally, a little quote:

If you have separate test and fix cycles, you're testing too late. --M. Poppendieck

Yes, I know, it's easier to say than to do... but nevertheless, she's damn right.

Часть этого ложится на Владельца продукта, который расставляет приоритеты, если некоторые ошибки, на мой взгляд, важнее некоторых карт. Если запрос на поставку: «Исправьте эти ошибки СЕЙЧАС», то исправления ошибок должны быть перемещены в верхнюю часть списка. Если имеется множество высокоприоритетных ошибок, возможно, стоит провести стабилизационный спринт, в котором ошибки будут исправлены, а новые функции не будут реализованы. У меня возникнет соблазн спросить у ЗН, сколько времени они хотят потратить на устранение ошибок, хотя я не уверен, насколько это практично.

Идея иметь разработчиков сопровождения хороша, но вы подумали, где могут возникнуть проблемы необходимость объединения изменений кода из того, что делает обслуживание и что делают разработчики новых функций? Да уж, это просто наступление на пальцы, но у меня было несколько болезненных слияний, когда день был проведен с двумя разработчиками, пытающимися продвигать код из-за стольких изменений между средой тестирования и разработки.

Могу я предложить идею, чтобы другой разработчик исправил ошибку ошибка, чтобы кто-то еще понял, как что-то было закодировано? Наличие нескольких человек, работающих над некоторой функцией, может способствовать развитию коллективного владения, а не индивидуального владения кодом. Другая часть состоит в том, что иногда кому-то другому может быть легче с ошибкой, потому что они исправляли этот вид ошибки раньше, хотя это также может привести к зависимости, которую следует регулярно проверять.

Могу я предложить другому разработчику исправить ошибку, чтобы кто-то другой понял, как что-то было закодировано? Наличие нескольких человек, работающих над некоторой функцией, может способствовать развитию коллективного владения, а не индивидуального владения кодом. Другая часть заключается в том, что иногда кому-то другому может быть легче с ошибкой, потому что он исправлял этот вид ошибки раньше, хотя это также может привести к зависимости, которую следует регулярно проверять.

Могу я предложить другому разработчику исправить ошибку, чтобы кто-то другой понял, как что-то было закодировано? Наличие нескольких человек, работающих над некоторой функцией, может способствовать развитию коллективного владения, а не индивидуального владения кодом. Другая часть состоит в том, что иногда кому-то другому может быть легче с ошибкой, потому что они исправляли этот вид ошибки раньше, хотя это также может привести к зависимости, которую следует регулярно проверять.

I think people should fix their own code as well. Why waste all the time with handovers?

It might be worth doing UATs as and when each feature is complete; so the "testers" working along side the "developers" testing functionality as they go. The testers should be able to run through the UAT criteria.

If there are more issues within the UAT with the stake holders, then they are change requests or the acceptance criteria is probably ambiguous in the first place!

Я обычно следую варианту 1. Часто потому, что ресурсы уходят на другие проекты. Если вы проведете анализ первопричин, обсуждая, как были созданы ошибки, есть небольшой побочный эффект общественного смущения. Если вы привили какое-то чувство собственности проекту, ваши разработчики должны быть более чем немного смущены, если их код отображает более высокий процент ошибок, чем другие, или что является разумным.

Обычно я нахожу, что в этих случаях, большинство разработчиков на самом деле разочарованы, если они слишком заняты, чтобы исправить свои старые ошибки. Им не нравится, когда кому-то приходится исправлять их ошибки.

Очень важно привить чувство сопричастности и гордости. Если вы этого не сделали, вы всегда рассчитываете на угрозу наказания, чтобы заставить их поступать правильно.