1 April 2013 7 minutes to read
This article might be helpful in case you are a business person with an own small company; you would like to improve the level of communication with developers or you plan to start it from scratch.
The overriding point in the cooking of inexperienced developers is motivation. From time to time you must talk about how much they did and how complicated it was. Even if developer is too weak, you should try to find some positive sides and demonstrate that you see the progress. Never tell a junior something like “I'm thinking about firing” or “Bob can do it better”.
For a skilled developer, the moral support has no weight. A skilled one knows bad sides of the project. This type of guys requires description of your ideas. If you decided to close the project, describe why. If you’re looking for a new project, describe what do you think etc. Just habituate yourself to talk with such developers.
IT sphere is too unstable because of amount of different projects. A developer knows much about the current state of technologies and one day he will find something that looks more interesting. That is why periodically you should provide a new project based on "modern" technologies. It will help to increase the marketing weight of your company and to work up an experience for the developer.
Sometimes you'll have free time to rest and to read articles at IT portals. Articles will scream about a new and awesome technologies that are making your project more valuable. And you'll ask yourself: "Why not? Let's use it. I like new things and we should be in step with the mainstream!".
It is a mistake. Your role is to manage the process, monitoring the status of projects, handling deadlines, finding new projects etc. Don't try to be developer; just don't think about technologies at all. You are a driver. And your team is an engine in your car. Check it, repair it, wash it twice a year but don't open it. Your engine is maintained by CTO (or a tech lead), and not by you.
The most important team is a tester team. Yes, it looks strange, because many companies don’t have such a team. A number of companies have no testers at all! Every developer makes code-typos, every. That is why you should test code in all possible ways. The tester-team can be standalone, and not linked to the project. The main role of this team is to test code before it comes to production.
* Scrum masters usually introduce the "Definition of Done (DoD)" if the project hasn't such a team.
A development team should be divided by 3-5 guys (one of them is team leader, another one is the architect). Every task should be started and completed only by one developer from the start to the end. Do not tell to a developer what tasks he has to start. Instead of it, try to use the “Priority” feature of your issue-tracking software.
A developer who will review the code before it comes to the tester-team. In small companies team-leader can do it as well.
A project manager/product owner of course.
Big projects have many other roles like usability engineer, copywriter, designer, layout developer, web-administrator, etc. Don’t think about dividing them, just analyze the whole process. I'm sure you will feel when the project needs one more role to involve.
It depends on projects. Some projects have the inviting budget and no time. Another one looks nice but you have no complete team for it; projects without clear plan and many others. Every project is unique, but with a bit of common things:
Application life is the endless cycle. Every new feature goes with bugs side by side. To organize this cycle you need one of these software: Trac or JIRA. For sure, you can find other solutions like Redmine, YouTrack and so forth. The Trac project is open source and aims to solve daily developer needs, not more. At the same time, JIRA provides much more management features divided by commercial modules. Youtrack is something in between.
Good start for your company might be to use Trac first, and then switch to JIRA.
Compare two links: JIRA Roadmap and Trac Roadmap. They look the same. The idea is to take some time in future, label it and put issues into this new box. Small issues come to the nearest box, complicated entries to box with a label in the far future. Moreover, you can use the “Agile” software development method in your project. In that case the “box” will be “Epic” or “Sprint”. It depends on amount of issues.
The same situation with the code in a repository, where Roadmap is a “Tag” and every issue is a “Branch”. Example of a nice branching model: A (Simpler) Successful Git Branching Model. It helps to decrease amount of mistakes if you have several inexperienced developers in your team.
Which one do you need? Use GIT. It will be easy to learn and to start at the beginning. Moreover it becomes a standard de facto for open source and commercial software development. CVCS is stricter in the development life-cycle. When you work with the CVCS, you should think about how to secure the data, backup it and so on.
The easiest way to store the project source code is to buy JIRA with the Stash component or create the company account on GitHub. The second way is more cheaply nowadays. Stash has not so many features and it is hard to contend with GitHub. On the other hand, if you have the JIRA tracker, it is more rational to buy the Stash component instead of GitHub account.
Don't forget to link branches and tags with "organization of releases". Also, you can read a nice article that describes basic things for newbies about Git and Subversion.
Why do you need tests? There are much topics you can find in the web by the "TDD" keyword. It is nice when you can start with tests, but usually projects require rescue. And you can't cover code and implement a new functionality in the same time. That is why you should gather time to create tests only for the core of project. Like custom libraries, billing forms etc. Mark out some hours a week for testing. It will save much time in future. The goal is to cover the whole application with tests, but to start only with important sections.
The best option here is to follow the three laws and write your tests first.
Merging time is the time when a lead developer merges your current version that have been tested by testers with production (main website, or trunk/master tree). A perfect time is two-three hours before the end of the working day from Monday to Thursday. Purpose of this action is habituate to cleanup completed issues from the development dashboard. Moreover, this point will handle the version number of your application and it helps to organize JIRA's "Roadmap" or Trac's "Roadmap" more transparent.