Usually we have certain constrains on our project which define what we can achieve and most likely also what we have to do first. Having a backlog packed with user stories makes it very difficult to get an overview of the upcoming workload. To be able to actually get an idea for the upcoming sprints we need to estimate the product backlog. Doing that detailed for each user story would take us quite some time. So instead of estimating each single user story (as exact as possible) we could try to estimate a bunch of similar user stories at once. This is Magic Estimation.
As soon as new code is finished it should be integrated into the code base. By that it is not only ensured that all members of the development team get access to new code, it also minimises the risk of running into incompatibilities and reduces the complexity of merging changes.
In a recurring fashion this could happen at the end of development day. Also partly finished features can already be pushed into the base as long as they meet the project's quality minimums (etc. testable/tested, documented). At the beginning of the next development day changes would get individually pulled into the working copy.
Maximise coverage of automated tests
Testing code is a crucial part in reaching a certain level of quality and stability. To minimise the workload needed the process should be automated where possible. This can be done with unit tests using state of the art testing frameworks (JUnit, Selenium, etc) to further reduce workload.
It should be also possible to combine testing with continuous integration. This gives the advantage of running tests as often as possible and getting the chance to react to issues quickly.
Think ahead and stay flexible
Each team member should keep the future constantly in mind. As the application grows requirements might (or most likely "will") change. To be able to react and implement these changes it is important to always develop for scalability and flexibility. This accounts not only for the development members but also for the management members of team. The management should always evaluate new features with what might come next.
Keep it simple
Always create the simplest solution for a problem that will work and deliver for the minimum requirement. Maintaining a simple, clean and open design ensures that the application can be easily extended while staying focused and meeting dead lines.
(AL) = affiliate link The links marked with (AL) are so-called "affiliate links". If you buy something from the seller via this link, I get a commission from your purchase. For you the price remains unchanged. Die mit (AL) gekennzeichneten Verweise sind sog. "Affiliate Links" (Provisions-Links). Wenn du über diesen Link bei dem Anbieter etwas kaufst, bekomme ich von deinem Einkauf eine Provision. Für dich bleibt der Preis unverändert.
So here is the situation: you build up some JSON objects and pop them into a StringEntity so your HTTPClient can send the stuff to server. We know on Android, the default charset is UTF-8 and use that knowledge through out the whole application, not considering that this fact might change in some places. But it does! Using a default StringEngtity with data supposed to be encoded in UTF-8 won't give us the expected results on Android. A look into the code explains why: