New answers tagged project-management-style
0
I normally do a business test after the code has been reviewed and tested by the team. This to make sure that we deliver quality software to the users for testing. This prevents them from finding any obvious bugs and raises their trust in the delivered software.
But this does not mean that the users cannot be consulted during the development of the ...
1
Post-Hoc Testing is an Anti-Pattern
You have succinctly described the use case for test-first development. In general, you want to first determine if you've built the right thing. Then you need to determine if you've built the thing right!
With that said, the notion of divorcing functionality from code correctness is a false dichotomy. In order to meet a ...
1
It seems rather nitpicky to determine if the order of reading code and performing any manual testing, especially since it's an iterative process.
Since it's not stated, there's an assumption that the developer who did the work didn't just write code and throw it over the wall. They tested it, by some combination of writing automated test code as well as ...
-1
Here's my admittedly-informal use of the term:
The "product owner" represents The Almighty Customer, and is often the team's most direct liaison to them, usually reporting directly to them. This role is very specifically focused on what the product will do and for whom it will eventually do it, and for ensuring that the whole thing actually does meet the ...
0
In my experience, software tasks often have both hidden dependencies and hidden contexts. You often find one developer "specializing" in this or that area of the system because (s)he is more familiar with it and can get the work done faster. Anyone else on the team should be familiar enough with any part of the system to "ramp up" on any area and get the ...
0
The origin is... Certain methods were developed at software companies and not for IT groups (companies such as Easel or Borland). Thus Turbo Pascal was a "product" that they sold
-it was not a brand, Borland was the brand- thus if you lead the Turbo Pascal group you "owned" the product.
Marketing did not have a concept of product owner, they centered ...
0
When you are designing an API which will be consumed by many business units (and maybe by external customers), a Waterfall approach with fixed and rigidly-stated requirements might very well be exactly what should be done. The business impact of such a layer of software is enormous. "This one scrum team" is only one of the many clients that this layer has.
...
0
Remember, Scrum can be applied to anything, not just software development. It can be applied to fleshing out API requirements too.
I assume your entire project does not revolve on this one API call. Just put a priority of fleshing out your API requirements.
In this you are your own product owner. Put the API-related feature / code at the top of your ...
4
For what it's worth, APIs and protocols are an area you often do need things fixed. This has to be very deliberately and explicitly designed because if you need to change it later, every consumer will have to update their code. APIs which are often changing are a nightmare to work with especially if they implement backwards incompatibilities.
I do not see a ...
3
They are also strict. No changes to the requirements. They want to lock down the requirements.
That is not really true though. They would like to restrict changes to the requirements, for sure, because that's the nature of waterfall development. In practise though it is never possible to avoid some changes to requirements, because issues will always occur ...
3
When the API is not too complex, you could create your own mock API to experiment with which returns test data. When you got your requirements down, you can contact them to create a real API delivering real data.
4
I have been in this situation a couple of times and it is very challenging.
Things that can help:
Spend some time with the waterfall team explaining how you work. Even if you can't resolve the conflicts between the approaches it still helps if they understand what you are trying to do.
Ask them to produce a mock/stub at the earliest opportunity to at least ...
48
Pretend the Waterfall team is an outside contractor
Since you're interfacing with the Waterfall team's code solely via an API, just pretend you're hiring an outside contractor to create that code for you.
The Scrum rules for how you write your code don't apply to them. You submit your requirements to them, they write up a formal Statement of Work for ...
19
First of all, make it known to your stakeholders that there is a project risk in your project. The waterfall team is asking for things (final, unchanging requirements) that you don't have at the start of your project.
To mitigate this risk, you can analyse your current backlog for items that may affect the data that you need to exchange with the system ...
1
Tom is the most experienced developer on the team (approx 10 yrs exp)
It sounds to me like Tom is pretty good at his job.
No developer should implement things in any other way than the way they believe is best for users. If you haven't shown Tom why his way is objectively worse you've not done your job. Don't moan about Tom for that - get him the rationale ...
Top 50 recent answers are included
