How to implement a software development process in an existing project?

Question

My question involves setting up a Software Development process. If you came in to an existing project that had no formal methodology or process set up, and then were asked to set one up yourself, how would you handle it? I have looked into various methodologies like Agile, or subsets thereof like XP, but these are primarily aimed at how to set up new projects. I am rather unsure how to implement them into an existing project.

Also, many of these are aimed at web or desktop applications. My software project is an embedded system, so while many aspects of them are applicable, it is a bit overwhelming trying to figure out which one to use and how to convert it for use in an embedded system. Unit testing on embedded hardware (especially with a Single Board Computer for which no simulator exists) is incredibly difficult, particularly if the software is very far along, and to add a hardware abstraction layer to aid unit testing would involve tearing up the code dramatically.

What tips would you have for setting up a Software Development Process for an existing project, for a programmer that knows how to program, but is new to software development process management?

Answer 1

First of all do it step by step. It's hard to teach old dog new tricks and if you try to implement all at once - nothing will get implemented.

Here are some questions that may help you to figure out if you are ready for methodology ;)

1. Code repository (do you use code repository? do you have branching strategy? if I ask you who and when introduced last major bug / feature and why - can you tell me?)
2. Do you have a road map of the project? Are you able which commits in the repository are directly related with accomplishing the next major goal.
3. Do you have a bug tracker?
4. Do you know (have written down) the process of deploying your app? Who decides when you deploy? Who merges the changes to the release branch of code repository? etc..
5. Do you have code guidelines in place? (variable names, function names, test names etc.)

Maybe this is not directly answering your question but I'm writing from experience. I also once was assigned a task to implement methodology in a company. Unfortunately it's hard to build methodology if code is send between programmers in zip files, stored in a dozen of shared folders without versions and nobody knows where code from few years ago is stored.

If you can answer all of the above questions and still feel good about the state of things the tip for implementing methodology is - choose what makes you feel comfortable.

If you have a strong base (repository, road map, bugtracker, deployment workflow, code guidelines) just test methodologies one by one and see which works best for you and your team.

Answer 2

In my experience the software methodology is more an organization policy than a project decision. Implementing any methodology in an organization requires a level of commitment that transcends the barriers of the project team (i.e. customers, managers, project-managers, stakeholders and other decision makers).

Establishing a new order of things, in my experience, rarely works if it comes from bottom-up. It works better when you negotiate with all parties involved. Unless you have the unlimited power to decide what should be done.

If there is already a methodology in place, even if it is not a good one (meaning it is not producing good results), introducing change is always painful and there will be resistance. Here it is where you will need support and commitment from managers and decision takers in the organization.

If you want to change a methodology in place by proposing a new one, then you will need to gather evidence that demonstrate how the current methodology is preventing the organization from achieving better results and you may propose to run a pilot with a project or two to gather results that demonstrate that a new methodology could prove to be much better.

Given the fact that the status quo is evidently not working, you may consider introduce the new methodology gently, by first making changes where it matters most, those changes that will help you prove with results that the new methodology, the new order of things, is valuable.

For example, if you are not doing any kind of testing, you may consider the introduction of some of the practices of TDD and then gather statistics for a few months, and then demonstrate to managers how the bug statistics have been increasingly improving. You can show this to the team as well, so they get excited and even more compromised with the methodology. Then you can move to a second phase and most probably get better support from the rest of the organization. Eventually, the whole organization can adopt the methodology.

I think that something of paramount importance is to get project managers on board with the new methodology, they must believe in it, and believe that it will improve performance. They must enforce it in the team members, who initially may show resistance. Otherwise, the changes will lose momentum and eventually fall into disuse and people will go back to the status quo.

Ultimately, whatever methodology you choose must show to improve the performance of your organization, ideally with numbers you can show to your manager and your customers. As such, IMHO, I would introduce change little by little, improving where I see problems, not caring so much about a methodology itself, but on how to make things better.

Have you considered other less popular methodologies like Personal Software Process or Team Software Process?

Answer 3

Software Development process/methodology is usually important part of a company culture and rarely changes per project. It is also strongly correlated to development methodologies that development team is comfortable/capable to practice.

One of the widely known and used methodologies is the model-based design for Embedded Systems developments. The significant feature of this model based design is that it facilitates quicker and more cost-effective development of the dynamic embedded systems. More detailed info is provided here - Embedded 360.

Another very important trend for Embedded Systems Development is to use Agile Methodology. It is widely used by software companies to develop embedded products based on requirements sent in by the client at different points of time. Here, different iterations of the embedded products are developed based on different sets of client requirements.

Answer 4

I think eventually, you'll want to create or acquire a simulator that will allow you to test your code in shorter cycles than you say you are currently able to do. In the meantime, look at other best practices and start incorporating them in a serious, standardized way,

Fist and foremost, you can certainly institute regular code reviews. Code reviews, done well, will prevent more bugs than just about anything else you can do. http://www.amazon.com/Peer-Reviews-Software-Practical-Guide/dp/0201734850/ref=sr_1_1?ie=UTF8&qid=1343746666&sr=8-1&keywords=code+reviews is a great reference for doing this.

Second, work closely with your QA group--make sure the developers know the tests they are coding against.

Third, simply take the principles of the Agile Manifesto to heart--do what you can do to focus on working software and simple communication throughout the project. Get people talking constructively about what is wrong and what can be done better NOW. Then do it.

I'd also recommend Alistair Cockburn's http://www.amazon.com/Agile-Software-Development-Cooperative-Game/dp/0321482751/ref=sr_1_7?s=books&ie=UTF8&qid=1343746954&sr=1-7&keywords=agile+software+development for suggestions on how to build a methodology appropriate to your environment.

Answer 5

as for embedded systems vs TDD:

When I was at university, we were required to write embedded system unit tests by use of a logic analyser. However, the ones we used did cost about 15000 dollars each, and we were told firmly, not to break them. On the other side, it was nice and easy: plug the chip into the board, start app, tadadada, green, bamm.

But I guess you have that.

As for methodologies:

Methodologies are about people. I'm yet to succeed in forcing down a methodology on any company culture, especially in large companies.

When I was in a primary RUP culture, I did XP with my team, in order to be faster than the rest. It did succeed.

When I was in a primary XP (or, fresh Agile, SCRUM wasn't mainstream yet), we did RUP, with modeling and all, in order to have a better understanding on what the f* is happening on the project, and act with much more confidence. It worked.

When I was in a SCRUM environment, I did either RUP (to have the better understanding), or, realizing that scrum backlocks are always broken, that we have no real iterations, etc, (we were the "bugs & small features team") I switched to Lean/Kanban in order to have stability in what we do. It mostly worked, although not as well as previously (and this was an enterprise, while the previous ones had a startup core team)

When I was in the SCRUM environment (you know, the N test), I switched to RUP like it was water in the desert, me being out for weeks there: I was left alone with it, but I had no bugs and was blazingly fast just because I just didn't accept all the excuses SCRUM had.

But all in all: in our new agile world, the programmer is the king. If programmers feel themselves well in chaos, you either switch companies or switch programmers.

I'd suggest instead of speaking about implementation to treat your programmers as your users: you have to solve their problems in order to help them work. I don't always like this approach (or rather, I don't like some programmers' approach and find it hard to support them in what they want) but today's leader is someone who should help the others, not someone who should be obeyed.