 |
 |
| Software development for many organizations is an ad-hoc activity. The process used to build the software cannot be reproduced across engagements with the level of quality that should be expected. The software development teams either make up the process as they go along or rely on what has worked for them in the past. These processes might work for small initiatives, but will cause larger projects to fail. Although most organizations will state that they have a structured methodology for software development, it is generally not implemented by the project teams. The teams will state several reasons why they do not use the well documented methodology: |
• "The methodology is too rigid for my project."
• "My team was not fully trained on the methodology."
• "If I followed the methodology, I wouldn't have been able to meet my schedule." |
| The above statements show that the methodology adopted by the organization does not meet the needs of the project teams. Experience demonstrates that there is no single methodology that works for every organization, or every project within an organization. The solution, therefore, is not a single methodology for an organization, but a set of processes that can be customized for each project. This approach supports the natural diversity across projects and among team members. The software teams continually evolve these processes, making the team more efficient and the processes easier to use after each evolution. In essence, the methodology is built around a culture of constant improvement. An organization needs to infuse process improvement into the teams' everyday work. Tacit Knowledge assists an organization in evaluating the many different methodologies used in the industry, and in identifying which processes from each will fit the needs of your project teams. |
| Documentation and Improvement |
Before we can improve upon a process it is necessary to catalog what currently exists. The first task is to document the methodology currently in practice. All companies have a methodology regardless of whether it is formalized. It consists of the social conduct which has evolved to get work done. Processes are mapped by interviewing members of the various project teams to identify how they do what they do. We facilitate the interviews to assist the project leads in truly understanding what each team member is doing on a regular basis.
Subsequently, we identify principle areas of improvement specific to redundancy within the communications architecture. Often times, written communication is used when spoken communication would suffice. In other instances, redundant oral communication occurs as a result of the lack of important written documentation. We work with the project teams to achieve collaboration which is both efficient and relevant.
The key to process improvement is to make iterative, incremental changes. Adding a sequential change, evaluating its effects, and making the necessary corrections are crucial steps to evolving a methodology. These changes are reviewed within short time-frames; two to three week intervals. This gives the project enough time to try out the new/modified process. Since the team is evaluating their process frequently, the process continually evolves to better suit their needs. |
| Tools and Techniques |
| There are several tools and techniques that can assist in the software development process. Below are a few that we employ on our engagements to facilitate communication and reduce risk. |
Version Control Tool
Every software development project should implement a version control tool. We recommend an industry standard tool, but any will suffice. The largest advantage to a version control tool is that the team can revert back to any version of the code base, reducing the risk of over-writing code.
Centralized Document Repository
This includes several tools; bug/issue tracking, project calendar, and file storage. There are several way to approach each of these, the point is to select a tool that works for the team. Ideally your organization has a standard, but if not the team should select tools that will be flexible enough to meet the changing needs.
Use Cases
Use cases can be thought of as a set of steps performed by a user to achieve a desired function. The use case should be documented in a few sentences, enough to describe the user's interaction with the system for a given function.
Class-Responsibility / Collaboration (CRC) Cards
CRC cards assists the software architecture team in planning out how a particular function will be built. The architects can look at interactions between classes and rearrange them without having to create new diagrams. This technique encourages a dialog between the development team, reducing confusion and miscommunication.
Class Diagrams
Class diagrams are used to further describe the types of objects within the system and the relationships between them. These diagrams will also be more detailed than the CRC cards mentioned above, class diagrams will contain information about the attributes and methods of the class.
Prototypes
Building prototypes is the best way to address technology risks. This gives the development team the opportunity to validate the technologies chosen for the project will be able to meet the requirements. The most difficult tasks on any development project is the integration of different components, prototyping helps the team identify potential issues early in the project. This gives the team the opportunity to re-evaluate their choices before too much of an investment is made in the development process.
Scripted Build and Deploys
Most organizations do not have their build or deploy processes scripted. Someone has to initiate the execution of the build and deploy scripts, usually making changes based on the environment they are working on. This introduces the potential for human error. Having automated builds and automated deployment eliminates the possibility of these errors arising.
|
|
|
| Key Benefits |
Actionable Recommendations
Any documentation created as part of the offering is not nebulous and addresses specific issues within the evaluation process. Findings are presented so that they can be understood by both business stakeholders and developers alike.
Flexible Offering
The offering is tailored to the needs of an individual customer. The scope of the engagement can range from specific projects or expanded to process improvements across multiple business units.
No Unnecessary Overhead
The customer will only pay for actual work on the project in question. There are no hidden sales costs, no superfluous project management expenses, and no administrative fees.
Predictable Development
With the improvements that are made over time, your project leads will be able to better estimate project schedules taking into account the potential project risks and their ability to compensate for them.
Reduction of Project Costs
As a methodology evolves in the context of an organization, projects become more efficient, and project failures become less common.
Customized Results
All of our consultants have extensive experience in working with a wide range of methodologies, from waterfall with extensive documentation to agile with low ceremony. We leverage our experience to custom tailor a solution that fits your needs.
|
| |
| What is a methodology? |
| A methodology can be thought of as a "social construct". Essentially, this means that your methodology is made up of processes that define how work is done on a daily basis. In software development, the key role of a methodology is to avoid risk by encouraging communication between the various roles on a project. Risk can be organized into several categories. Below are four examples. |
Skills
Does the team have the proficiency required?
Requirements
Have the requirements been understood by the development team?
Technology
Will the selected technologies work together? What are the issues with integration?
Political
Are the fundamental goals of a project understood and agreed upon by all the relevant stakeholders in the organization?
|
| Tacit Knowledge will assist in the selection of the appropriate processes based on the specific kinds of risk most prevalent in an organization. |
|
|
