Here I am going to share all the things I faced during the software development process. This article is in working progress (and always will be). Feel free to discuss out the content on github or make a pull request with your changes.
If something becomes difficult to plan or to do there is high change there is a mistake in the design or solution.
Ask your developers to write down all the features they want see in the app. Try to estimate the value. Rewarding the creativity will bring it more and more.
A sprint is a chunk of job usually planed for week or two.
Thare are a couple of suggestions
Sprint should end up with the demo, where every person involved in the project shows his work to others. It is also very desirable to publish a new version for the customers.
During my career I faced a lot of different approuches to the subject.
There are several successful branching models, but there are my modified model.
masterbranch [protected] - contains stable version of the application where are tags with released version named for example
release-1.1.1. Hot fixes are done here and merged back to development branch.
developmentbranch [protected] - here should land every pull request from feature branches that are desired to be released in the next version
Those are created for special purpose. Should have been described
feature-name- the feature branch with changes that are not scheduled for the next release
A protected branch is the branch when it might be changed only in pull request process.
We might consider to have only those two branches in the main repository. Developers should work on theirs own forks and send the changes through pull requests. Suggested names of branches for them might be like:
JIRA, for example
The idea is to force the team to check the new changes in the code and helps catch the bugs, bad quality code, teach everybody, make code less redundant. The code review is a very important process which in my opinion should be a must-to-have thing. The goal is to check the code according to specification and make code readable/extendable.
However it leads to a blame war especially then there is no clear code guidelines.
There are a couple things that make the process easier
rebase -iinstead of
The company should have a document that describes the rules all programmers shall follow. it decrease tension during the pull review process.
Unit testing team : Probably not everyone will agree with me, but in my opinion tests should do separate team. This approach has very important advantage, if somebody else will write tests, he has to understand the code, if not, he will reject the push request. This team should work closely to refactoring team
The monkey and automation testing team. The team that tests functionality of the app from top level.
Help desk team Collecting the feedback from the users and helping them out. Giving feedback to other teams about the problems the user faced.
In order to make a project successful you have to spend significant amount of time on marketing. Good product will not advertise for itself, even if it is the best of the best in the business area.
I have to admit I have a little experience in this subject, however I have some thoughts I’d like to share.
In my opinion the success of the project is in 20% talent of the workers and the rest is a hard and dedicated work, therefore the recruiters should make sure the candidate is motivated and focused on solving the problems. A can-do attitude is only thing that is mandatory.
Another thing that has to be checked is if the candidate fits to the team. Good sense of humor and optimism is highly desirable. In case the candidate fails this step, you can still hire him and work on him, but you have to pay attention if he will not make bad influence to the team. You and the candidate can work on improving the attitude, if it will work, great, but if not you should consider to give a notice after probation period.
I have no idea :) I will update this one when I fugure out
Encourage team to healthy live style and help them out make it happen, give them gym-cards, award them, something it works. Try to convince them, but remember this is theirs lives, so you have no right to enforce anything in that area, just polite suggestions.
Demo: Show the project status and gives opportunity to developers present their contribution and abilities. The meeting should be short (in my opinion no longer than 10 mins per person + extra time for answering the questions) and dense with informations. As a project manager pay attention to the questions. Pretty often they are more important than the answers. To this meetings should attend only people who are involved in and optionally executives.
Daily stand-ups. In my opinion this kind of meetings tend to be very unproductive, especially when participants work on the same project but for different platforms or areas (marketing, software development, design …) Just nobody is listening to things (at last don’t remember for longer period of time) that don’t really care about. If you are only one on your field (let say there are only you who works on iOS) you can consider make a request to your project manager to let you quit such meetings. However there might be a situation that you want to know what it going on in entire project (bacons you want to know if somebody had the same problem as you etc.), so you can look at demo slides, or look at task tracker. Another solution might be running an IM chat room for stand-ups, so it can be searched out for the things that particular person is interested in.