Imagine a situation when you have a few well educated and quit experienced programmers and the project which technically could be done by any of them.
And was made a decision to unite them and make to work for a project altogether. They were not a team before and did not have an experience to work in a team. Neither mangement guys I think had indeed experience of creating and working with a programmers team. Finally we got actually a quite friendly company of IT people linked with common business who worked for the project all by their own way.
Ok, they did not write Unit tests and did not have other QA software. QA was only manual – it’s important to remember to continue the story. In the same time project appeared to be big. I mean really on a stage of estimate the main problem about which everybody were talking about was a game logic. Prototype for it was created quite fast. And during development it took to bring the game logic to the final state in total no more than 10 hours.
Imagine a situation when you have a few well educated and quit experienced programmers and the project which technically could be done by any of them.
And was made a decision to unite them and make to work for a project altogether. They were not a team before and did not have an experience to work in a team. Neither mangement guys I think had indeed experience of creating and working with a programmers team. Finally we got actually a quite friendly company of IT people linked with common business who worked for the project all by their own way.
Ok, they did not write Unit tests and did not have other QA software. QA was only manual – it’s important to remember to continue the story. In the same time project appeared to be big. I mean really on a stage of estimate the main problem about which everybody were talking about was a game logic. Prototype for it was created quite fast. And during development it took to bring the game logic to the final state in total no more than 10 hours.
Main part of work began when project came in stage of localization. Funny thing that on stage of making architecture nobody thought about that going to be the most hard part. So, localization was started when we met first deadline. So, lets repeat again to bring all the dramatics of situation: we reached deadline and only after it started to do a biggest and hardest part of the project!
We got UI documents which would need to follow strictly for localizations. Project growed up in complexity and amount of code on 300-400% and remember now that only manual QA was available… It was epic fail. A lot of bugs started to appear. Funny to look from the side: the same bugs were fixed many times… No one task was too complex for any of team members, but because of system problems, the project, what seems actually very logical now after review, is failed.
Resume: this is classical way of immature IT teams fail. Main problems here are:
1) no QA and Unit tests,
2) poor management and nobody think architecturally and in advance,
3) weak communication skills, no technologies was applied for that.
And was made a decision to unite them and make to work for a project altogether. They were not a team before and did not have an experience to work in a team. Neither mangement guys I think had indeed experience of creating and working with a programmers team. Finally we got actually a quite friendly company of IT people linked with common business who worked for the project all by their own way.
Ok, they did not write Unit tests and did not have other QA software. QA was only manual – it’s important to remember to continue the story. In the same time project appeared to be big. I mean really on a stage of estimate the main problem about which everybody were talking about was a game logic. Prototype for it was created quite fast. And during development it took to bring the game logic to the final state in total no more than 10 hours.
Imagine a situation when you have a few well educated and quit experienced programmers and the project which technically could be done by any of them.
And was made a decision to unite them and make to work for a project altogether. They were not a team before and did not have an experience to work in a team. Neither mangement guys I think had indeed experience of creating and working with a programmers team. Finally we got actually a quite friendly company of IT people linked with common business who worked for the project all by their own way.
Ok, they did not write Unit tests and did not have other QA software. QA was only manual – it’s important to remember to continue the story. In the same time project appeared to be big. I mean really on a stage of estimate the main problem about which everybody were talking about was a game logic. Prototype for it was created quite fast. And during development it took to bring the game logic to the final state in total no more than 10 hours.
Main part of work began when project came in stage of localization. Funny thing that on stage of making architecture nobody thought about that going to be the most hard part. So, localization was started when we met first deadline. So, lets repeat again to bring all the dramatics of situation: we reached deadline and only after it started to do a biggest and hardest part of the project!
We got UI documents which would need to follow strictly for localizations. Project growed up in complexity and amount of code on 300-400% and remember now that only manual QA was available… It was epic fail. A lot of bugs started to appear. Funny to look from the side: the same bugs were fixed many times… No one task was too complex for any of team members, but because of system problems, the project, what seems actually very logical now after review, is failed.
Resume: this is classical way of immature IT teams fail. Main problems here are:
1) no QA and Unit tests,
2) poor management and nobody think architecturally and in advance,
3) weak communication skills, no technologies was applied for that.