Depends on the team size. For a 1-man team, I think keeping it on the simpler side is beneficial. As already mentioned, you don't know how your project will progress, what new features you decide to add and what features you decide to scrap... etc. You might find this thread to be a bit insightful.
As a single developer myself, I've decided to switch to a concise bullet list approach, and I've found it to be quite beneficial for me. Most importantly, I no longer find myself sitting at the computer and staring at the monitor not knowing what to do next. I now sit at the computer, open the project's workflow, pick a bug to fix or a feature to start implementing, and starting coding right away. It has boosted my productivity quite noticeably, which was an issue for me before. But of course, there is no single approach that works for all people.
For my personal game projects I work on different aspects whenever I have time and feel like it. I could be drawing concept art one day and the next day do some programming. Programming wise I have a good prioritization in my head of things that need to be done, but I don't have a strict process.
Even so, sooner or later you need to actually ship a product. That is the final cutoff.
And this is about the point that a lot of self-described "agile" organisations start to fall apart.
Without some sort of global waterfall-style planning process, you end up with a list of features required in the final product which only trends up (never down), a constantly-decreasing rate of feature delivery as you have to keep refactoring and iterating on earlier design decisions, and generally an immovable deadline for when to ship.
Those factors can add up very quickly to a failed project, if you aren't careful to keep everything synced with a high-level planning process.
Agreed. Some people read over the Agile Manifesto where they prefer "Responding to Change over Following a Plan" and wrongly interpret this to mean no planning.
As some famous general I won't bother to look up is quoted with, plans are useless but planning is invaluable.
In the longer version of the Agile Manifesto they go on to explain the point a little more: "We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment." Or in other words, make plans that you are going to use, don't bother with plans you won't use or learn from. Constantly adapt, but have clear goals and plans in place.
Specify the destination clearly but allow for changes in the route.
For a big party you might know everyone is going to a major park on a specific date, but everyone can follow their own path to reach the destination. Some people may live in the area and will drive from their home, others will travel from distant areas, driving or flying and staying at their own individually planned locations. Each can vary their plan for what they bring, shopping at various stores or even bringing items from home, having their own implementation details for getting party items. Each can embrace their own changes, have flights that are delayed, visit tourist attractions, or otherwise do their own thing, react to their own turbulent lives, but still deliver on their commitments for being at the destination on time with their correct party items.
In this case we know the product (a well-specified game) and a series of dates, but Agile means we are not specifying by contract up front the path we go to reach the destination. We can take detours, we can re-arrange the order of many details, we can even swap out enormous implementation details if needed. Changes to the plan can mean cutting features that are not part of the big commitment or scaling things up or down to fit ever-changing constraints. But the plan still has the product with a list of features and we can deliver on our commitments while still adapting to change.
We plan, and we have a firm destination in mind. But when roads are closed we respond to the change and deviate from the plan by following detours rather than driving through freshly-poured concrete to strictly follow the plan.
We use Agile but we use continuous integration and continuous delivery. Features are proposed worked on and tested and only merged into the main branch when they are ready. At any time a manager can say right we don't care about the rest of the features lets treat what we have now as an MVP and ship. The product is always in a state where it is ready to be shipped to clients.
1. Register
2. Initial Requirements
3. Review ( Approve / Reject)
4. Detailed Requirements.
5. Approved for Development (enters the development backlog)
6. Development
7. Unit Testing
8. User / Play Testing (reject / approve)
9. Build & Release
You are doing your unit testing and development in the wrong order. You should write your unit tests before development. Otherwise your tests will only pass against what you have just developed which could be wrong.
You should as part of your detailed requirements write a set of Acceptance Criteria for each feature (Should probably be done by QA and Management).
Write Mocks and Unit Test against them
When it comes to development replace the mocks as you develop the code. The Unit Tests should still pass.
1. Register 2. Initial Requirements 3. Review ( Approve / Reject) 4. Detailed Requirements. 5. Approved for Development (enters the development backlog) 6. Development 7. Unit Testing 8. User / Play Testing (reject / approve) 9. Build & Release
You are doing your unit testing and development in the wrong order. You should write your unit tests before development. Otherwise your tests will only pass against what you have just developed which could be wrong.
It doesn't matter what order you implement the code and the unit tests in. Both require that the programmer translates their expectations into code properly. If the programmer screws up both, the unit tests are not responsible for the human's failure.
Unit tests don't make sure your code behaves as YOU expect. They make sure the code behaves as the TEST expects.
The saving grace is that it's extremely unlikely for you to make concurring mistakes in both the code and the tests.
