How can my team avoid frequent errors after refactoring?

Posted by SDD64 on Programmers See other posts from Programmers or by SDD64
Published on 2014-06-12T06:41:14Z Indexed on 2014/06/12 9:39 UTC
Read the original article Hit count: 219

to give you a little background: I work for a company with roughly twelve Ruby on Rails developers (+/- interns). Remote work is common. Our product is made out of two parts: a rather fat core, and thin up to big customer projects built upon it. Customer projects usually expand the core. Overwriting of key features does not happen. I might add that the core has some rather bad parts that are in urgent need of refactorings. There are specs, but mostly for the customer projects. The worst part of the core are untested (as it should be...).

The developers are split into two teams, working with one or two PO for each sprint.

Usually, one customer project is strictly associated with one of the teams and POs.

Now our problem: Rather frequently, we break each others stuff. Some one from Team A expands or refactors the core feature Y, causing unexpected errors for one of Team B's customer projects. Mostly, the changes are not announced over the teams, so the bugs hit almost always unexpected. Team B, including the PO, thought about feature Y to be stable and did not test it before releasing, unaware of the changes.

How to get rid of those problems? What kind of 'announcement technique' can you recommend me?

© Programmers or respective owner

Related posts about agile

Related posts about teamwork