Process & Tools
Process is only correct when it does not overload people with unnecessary actions, but still provides transparency and predictability for the project.
Job tracking: Redmine & Redbot
We try to replace personal management with automation where possible. It is now possible to automate and make it transparent the process of task definition, task estimation, development and deployment.
Agile development process
Agile process, based mainly on Extreme Programming (XP) practices which we feel fits best small and average sized projects. For a larger projects we consider using Scrum or similar approaches.
Agile requirements The customer can change requirements for a project partly or fully at any moment. This allows our process to follow the immediate customer business needs (market changes, new ideas, priority change) the best way.
Clear definition of roles
It is very important to understand who does what, in which sequence and who is responsible for providing all necessary materials for the steady development process.
How to start project with us: phases of development
Initial project requirements meetings, prototypes and mockups, estimation, pre-payment, iterations, releases.
We were one of first who tried automation in the software development, and still using it everywhere in our projects. So with QA we have: (a) unit tests (b) functional "black box" tests, (c) manual testing. In production we use monitoring tools.
When our process fits best, and when don't
Agile process fits best in situations when requirements change during implementation. This usually happens by a few typical reasons: - growing market changes priorityes for tasks - there are no full vision/understanding of final product - ...
More information about our process on UA2WEB Public Wiki
Our public Wiki contains materials which are easy for change by project managers within company. Primary usage of those are meant to be in the company, but you as customer welcome to see our internal procedures.
So far we've achieved what we achieved by constantly improving our skills, reading and analysing industry experience. Those are management books we've read, respect, and use in our work.
Distributed Version Control
We are proficient in both Mercurial and GIT, but we do prefer Mercurial for a corporate style business development by a few reasons: (a) its branching model (b) it is pure Python system where developing plugins is easy (c) it is simply easier to remember commands.