You are here
Distributed development is quickly becoming the norm rather than the exception... Recent surveys have shown that only 45% of Agile teams are collocated; the rest are distributed in some manner.
A Practical Guide to Distributed Scrum, IBM Press, 2010
In a globally-distributed development environment, operations infrastructure and procedure are of paramount importance. Whatever your company's size and requirements, Creadyne offers you a clearly-defined development process. This robust project management structure allows us to deliver your requirements on-time and on-budget.
When you work with Creadyne, your primary contact will be your project's project manager. Your project manager liaises with your project's development team leader and individual developers, designers and QA personnel. In most cases we deal with a single representative of a client company; usually a Product Manager, CTO, CEO, etc. However, we can also work with management groups, engineering teams, or any combination thereof. Our only requirement is that one person is responsible for signing-off on project requirements and delivered products. Just let us know how you'd like us to fit in with your existing business structure!
Creadyne uses a variety of online applications for project and staff management. These tools allow us to:
- Track and manipulate project requirements and issues
- View valuable information on current and forecasted development progress
- Keep our development times tight
- Integrate our development teams
- View granular or big-picture project statistics
- Track staff activity in real-time
- Collaborate and communicate, both formally and informally
Creadyne uses a well defined development process, based on Agile/Scrum, with modifications based on our experience with globally-distributed operations. This provides an exceptionally robust methodology that allows us to:
- Manage complex projects
- Prioritize tasks
- Encourage innovation
- Maintain tight control on resources
- Receive real-time feedback on projects' progress
- Ensure daily exchange of information and ideas amongst all team members and managers
Please note: the following describes the framework we use to develop typical products. We use it in the vast majority of cases due in part to its ability to keep globally-distributed teams engaged and collaborative. However, your project may be atypical! If so, we will mention this and suggest a modified or alternative framework.
When you first get in touch with us, or we begin a new project or product release for an existing client, the very first things your project manager will discuss with you are your project's requirements (features), and constraints (operating timescale, budget, etc.) We will also discuss topics such as the deliverable's look and feel, image, usability, marketing, and anything else you feel important to the creation of your ideal finished product.
After this initial consultation, your project manager assigns a team leader to your project. We then create your project's draft Software Requirements Specification (SRS) document, which acts as the blueprint for the product we will create for you and defaines all its features, its aesthetic components, and provides a firm cost for the defined feature set.
At this point, we will discuss each feature and its prioritization with you. The draft SRS document provides a suggested prioritization, but in most cases this will require modification after consultation with the client. This prioritization is extremely important, as it serves to create the product backlog which will be the basis of the subsequent development operation. Sign-off on this feature list and its prioritization is ultimately your responsibility, and should not be undertaken lightly (although our system does allow a degree of flexibility down the line). Once we agree on a production SRS - on the understanding that subsequent requirements of varying priority may later emerge, and that existing priorities may change - we are ready to proceed to Team Selection.
We are now in a position to go to our pool of talent and hand-pick the individual developers, designers, writers, QA personnel, etc., with the expertise required to fulfill your project's requirements. Depending on the nature of the project, we may have already contacted some of these people for input when preparing the SRS document.
So now we can begin to put our aesthetic and technical skills to work! Here's how the process works.
If your business requires branding and logo design we will do this first, as the aesthetic and psychological considerations distilled into the brand will provide the basis for all other aspects of the website's design. If your business is already fully branded, we will base our designs on the existing considerations.
Once any branding work receives your sign-off, we will work on creating "design intent" (mockup) images of your website. Depending on its complexity, we may need to create several different images; for instance, your home page, an example content page and an example product page. All our actions at this stage are based on the parameters defined in the aesthetic and functional sections of the SRS document.
Once we are happy with the designs, we will ask you to verify that they meet the defined criteria, and sign off on them (or, if changes are required, to specify them).
PRIMARY BUILD PHASE
Now, we enter the build phases. The primary phase is where the designs and SRS are turned over to the technical folks, who turn the images into a functioning website. This is usually done on our test servers (depending on the type of site). Sometimes, clients notice a drop-off in communications at this point, but don't worry - during the initial consultation and design phase, we will be asking for your opinions, requirements and feedback very often - perhaps daily - to ensure that we're going to deliver what you need. But once those phases are complete, the time for such feedback is past, and we can proceed with the build. So, rest assured that activity continues apace at this stage; it just requires less client input.
Once the design intent images are successfully coded, we will show you the result and request your approval that this has been done according to our defined terms and the design intent images.
SECONDARY BUILD PHASE
Now that the design is coded, we can start to build out all the other features and requirements defined in the SRS. The nature of these features will be very different from one project to another, but the completion of this phase takes us to a point at which the SRS criteria have been fulfilled.
There is no milestone at the end of this phase, as testing is required before we consider the product ready to present to you.
QUALITY ASSURANCE PHASE
What happens: at this point, we will call in our Quality Assurance people, who try to break the website. They create QA reports; essentially, "punch lists" of any errors, bugs, vulnerabilities and so forth. We go through and fix these.
Once the lights are all green, we're good to go! We'll give you the access codes that you need to go in, view and test all of the public-facing and administrative features and functions. If your site has a financial component, we may need to you to plug in certain sensitive information and assist in a "live fire" test. Once we receive your approval, the final milestone payment (25%) is due.
In the final stage, we have a completed website, normally on our test servers, which needs to be moved across to your own hosting provider's server prior to go-live. Our final action is to do that, working alongside any commercial launch date/time, party, promotional event, or whatever you have planned. Additionally, after launch we will be around for thirty days to offer advice and, in the unlikely event that any build errors have gone unnoticed, to fix them.