-2

I am used to treating the issue tracker as a source of truth and an organisational memory. I use it to record what the issue is and what has been done towards resolving it. I consider this to be essential and basic to good software engineering (including agile development).

I am willing to consider the possibility that I am wrong however.

I am now part of a development team split over multiple sites in the world not all of whom speak the same language (a few do not share English as a common language and can only communicate via my team leader). To me this makes good use of the issue tracker even more important.

However, the other team (despite my protestations) regularly adds user stories which are just a single line. If I am lucky enough for there to be a description it is quite terse. The stories are typically closed and accepted with no commentary added at all. Sometimes there are sub-tasks that only have a title. The team leader has to accept tickets after the developer closes them (and is thus complicit). Some of these are small issues but others are huge like "evaluate orchestration methods" which has led to the use of Kubernetes.

I am not discouraged from using the ticket tracker how I want myself but I have no visibility of what others are doing. Granted, I don't often need to know unless I am working on a related issue (my point is kind of that I might need to in the future). It seems they prefer talking face to face or not at all. This is claimed to be 'agile'. The issue tracker is just an internal tool not directly connected to any incentives, perverse or otherwise.

Is there any sane world or process in which this makes sense? Some kind of ultra lean - less paper, less testing, just barely enough code, tick the box and ship it system that actually works (or appears to work from the perspective of management)?

Bonus points for good suggestions on how get developers and management on board with better process.

  • 4
    Is this process you describe actually causing any problems for you in terms of being able to get on with your job? or are you only worried about the fact that you may need to refer back to the information in future? If it's the latter it may be that the team considers this kind of documentation to be a case of 'YAGNI' – Ben Cottrell Nov 27 '18 at 12:43
  • So far only occasionally as people are sticking to their own parts of the system. It feels like a time-bomb. I can't ask does this solution to this story meet or original intent or the business requirement if it isn't expressed. Compared to other issues such as the quality of their code perhaps its not a big deal. But if its a YAGNI why use the tracker at all? Just check stuff in. While I'm in rant mode why bother with comments in code while your at it or tests outside the golden path? – Bruce Adams Nov 27 '18 at 12:56
0

Is there any sane world or process in which this makes sense?

No.

There are certainly multi-volume books written about how to do it better, but I have never seen one that said "just don't care for requirements. Just shout fragments of them over to each other in the hallway. We have good memory, why write them down".

It's a sure sign of chaos.

  • someone obviously disagrees and thinks I'm being stupid as I have 3 downvotes for just asking. Perhasp being the type of people who don't care for documentation is why they didn't explain the downvotes ;). Rants are a bit off topic though I guess. – Bruce Adams Nov 27 '18 at 22:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.