How should I behave as a developer in a project that's headed for failure?

Unless you have the authority to guide the project back on track, there are only so many options available to you:

1: Document your concerns and any problems you've identified. Be objective wherever possible (i.e don't bitch about your co-workers even if the reason the project is failing is because they're fucking it up). Any problems that you've spotted and are worried about, WRITE THEM DOWN and email them to your project manager.

2: Keep a cool head. This is incredibly difficult once endless frustration sets in. Bite your tongue, and don't get personal. You will probably fail from time to time, because knowing that you're going to fail is a horrible, insomnia-inducing feeling, and your patience will almost certainly be tested.

3: Offer solutions. If you think a particular decision is to blame for some aspect of the failure, then document it, what went wrong, and what any alternatives may be.

Unfortunately, in my experience and from what I gather from other people, these kind of things tend to come along with ridiculous company politics and emotions. If your gut feeling is that it's going to fail, then your best approach is to try to raise the alarm as soon as you notice. You may be ignored or brushed aside, but you must document everything you do. Don't raise the concerns in conversation, make sure there is a paper trail.

In my own case, the project failures ultimately led to me and several other developers abandoning the company. The project could have been saved if our concerns were taken into consideration and acted on. We even presented a proof of concept redesign which solved all of the existing problems AND presented new opportunities for growth, and were told that our new design would not see the light of day. Keep in mind that we had working code, schemas, deployment plans, addressed scalability concerns, and even had a development roadmap for the new design. Some battles are un-winnable.

Being upset at being labeled a "rat" means you're alive.

This pervasive "don't raise concerns or you'll get targeted" is all too often WHY projects fail: people keep telling the decision makers "everything is fine, we'll deliver on time" while mumbling "ain't no way this thing's gonna make it" in dark corners, leaving those with the power to do something about it unaware of the problem approaching, and looking for heads to roll when it does. If you're going to be punished for speaking up (objectively, professionally) then it's time to get out of a toxic environment.

I'm in a similar situation and the pressure is mostly caused by a lack of management.

I've been appointed project leader halfway the project and I did my homework by reading the Software Project Survival Guide. We are also supposed to work in a scrum system, but on going business causes scrum to be just an extensive time management tool.

We're nearing the deadline and a few things I picked up are:

1) You need to have a hands on approach and come up with solutions yourself. Show a lot of initiative.

2) Have clear roles of who needs to do what.

3) Don't change roles halfway a project, it only causes confusion and someone needs to clean up the mess.

4) Be frank to your business owner about the current reality . You don't want to be the guy, who didn't say anything and pass the deadline. And don't wait too long with saying it.

5) Make it very clear to the business owner, all changes cause a delay. And whatever you do, do not let the business owner decide how long a change will take.

6) Don't fight with the external guys, even if they are trying to run the show. If they start pressing for decisions (framework/system/etc) without a good reason, other than their own comfort, be warned... Get ready for a sticky situation. If you can, stick together with your current team to have some counterbalance.