Sunday, January 28, 2007
(Selling More, By Having An Adaptive Enterprise System, An XYZ Company Story)
Section 9: Development Steps Some Guidelines
Section Contents
Development Steps
Development Guidelines
- Team Make-up
- Team Meetings
- Light Documentation
- Modeling
- Development Iterations
- Adaptability
Development Steps
1. An initial project kickoff meeting to define purpose, objectives, key IT\business team players, priority, and expected cost\benefit ratio. Deliverable, a very small document (a few pages at most) containing statements documenting decisions on the proceeding items.
2. Followed by an initial development team modeling meeting involving senior team members to review the results of the prior meeting and extend its results to produce the following deliverables:
a. A common language for the project developed through IT explaining a suitable modeling approach and business users explaining how the business domain basically functions and what key business terms mean.
b. An initial broad-stroke model of the desired system or module(s) that sets boundaries on what they need to do.
c. A breakdown of objectives into more specific goals, which are measurable. Covering such matters as functionality, performance, increased profits, and\or reduced costs.
3. Where necessary or useful, have relevant team member pursue research and analysis of suitable business domain solutions through the review of existing systems, reports, custom business documents and processes, commercial software candidate packages, and publicly available data models. The deliverable from this activity should be an assessment of suitable candidate packages, (if any), or a list of considerations that should be made in developing a new custom system.
4. Transition to short iterative development cycles where a limited set of specific system functionality and business rules are fleshed-out in a team meeting. Any consideration of additional modules outside of the primary one being worked on should only be considered at the boundary of their interaction with the current functional area under development. The primary focus should be the delivery of working software every couple of weeks. All development work to be centered around commonly understood business domain and database models, supplemented by a listing of business rules classified by their type. These rules should be documented in the system’s online (editable) help, along with any prose found necessary to communicate the systems purpose. Data or process flow diagrams should only be developed where there is strong case for such.
5. Actual programming within each iteration to be done with some form combination of RAD and Agile methodologies e.g. standard screen\report painting with walk-through, combined with extreme programming or test driven programming, with frequent code check-ins and automated tests and builds.
6. Regular reviews of ever more detailed working software by joint IT and business development teams, evolving the system one cohesive feature set at a time.
7. Prior to final delivery in any cycle, let users play with working model to see if any final changes need to be made.
Development Guidelines
Team Make-up
The development team should be made up of both IT and business people who meet frequently to define what should be in the next deliverable and review progress.
The team should have senior members from IT and the business domain involved from the outset to define the overall parameters\boundaries of the project and to help resolve any business issues and\or conflicts.
Additional IT staff and key users should be heavily involved as soon as project progresses to discussions that are detailed and pragmatically oriented.
These development teams should be kept relatively small and closely coordinate\ communicate their work on a frequent basis.
Team members should use the project’s common language and where possible involve people who are comfortable with both IT and business topics.
All projects should be guided by the chief technical architect and\or his direct assistance to make sure all efforts fit into the overall system vision for the company.
Team Meetings
Team meetings should start with an agenda, and have a moderator and time limit. They should quickly review what was previously agreed upon in the last meeting, and then quickly seek to make new progress building on what is already known. There should also be some mechanism for recording what is learnt, so people can review and confirm a common understanding of the material was achieved.
After initial broad stroke meetings in the early phase of a project, subsequent meetings should largely focus on what will be done during the next development\deliverable cycle.
Light Documentation
Just as it’s said a photograph is worth a thousand words, so can a diagram. Because of the power with which they can quickly convey a large amount of knowledge business domain and database model diagrams should be the primary tools of communication for the team.
An additional nice feature of diagrams is that they can be easily drawn on whiteboards or easels during meetings to keep people focused on the discussion at hand, and to solidify concepts brought-up.
The second level of importance for documenting is the use of functional lists bulleting what needs to be coded within the system and terse classifications of business rules that must be observed.
Data flow diagrams may also prove useful.
But long wordy prose should be discouraged, as subsequent changes to the document are hard to identify and people quickly get tired of reading lengthy documents with frequent changes.
However, terse prose on how the system works, along with concise statement of the business rules should be maintained as online help, as the system is being developed and being reviewed. That help should be editable by developers and quality assurance people so they can correct and update it as needed.
Modeling
Two of the most popular modeling techniques are Data Modeling and Use Case. The former is the more traditional one, while the latter is currently gaining popularity.
When using Data Modeling the following concepts generally have to be defined for non-IT members, (and this is as technical as it really needs to get for them): Entities, Entity Attributes, and Relationships between Entities including their type, (one-to-one, one-to-many\many-to-one, and many-to-many).
A decent alternative to the Data Modeling approach that is becoming increasingly popular is ‘Use Cases with UML Notation.’ It’s generally perceived by its promoters as being easier to explain to non-IT people then the Data Modeling process, as it primarily deals with simple stories about system usage.
Regardless of which approach is followed, the initial steps are the same i.e. define technical concepts, notation, and start fleshing out the domain diagram(s) slowly, while focusing on the development of a common language for the combined development team.
Development Iterations
The development team should focus on getting through an iteration of planning, development, testing, and delivery every couple of weeks or less.
Respect for schedules should be maintained, otherwise, overall control of the project will be weak. Thus, when schedules are running late, time boxing should be applied. After each deliverable is made, a post-mortem should be applied to see what went wrong and what went right. Things that went right should be applied again, while corrective action should be taken on those that went wrong before the next cycle of the project begins.
With regular and short deliverables, everyone will always be aware of how well the project is progressing, and any problem areas will be identified and tackled quickly.
Adaptability
Having frequent meetings and short development cycles allow the development team to quickly react to changes in business needs and specifications. The longer a project takes, the more likely the business needs will change while it’s progressing. Also, the larger a project, the more likely the team will not get every requirement correct up front. Having frequent deliveries of working software allows one to more quickly identify necessary changes and make sure they are incorporated in the next short iteration of the system, instead of trying to re-do everything at the end when there is much more to contend with.
Section 9: Development Steps Some Guidelines
Section Contents
Development Steps
Development Guidelines
- Team Make-up
- Team Meetings
- Light Documentation
- Modeling
- Development Iterations
- Adaptability
Development Steps
1. An initial project kickoff meeting to define purpose, objectives, key IT\business team players, priority, and expected cost\benefit ratio. Deliverable, a very small document (a few pages at most) containing statements documenting decisions on the proceeding items.
2. Followed by an initial development team modeling meeting involving senior team members to review the results of the prior meeting and extend its results to produce the following deliverables:
a. A common language for the project developed through IT explaining a suitable modeling approach and business users explaining how the business domain basically functions and what key business terms mean.
b. An initial broad-stroke model of the desired system or module(s) that sets boundaries on what they need to do.
c. A breakdown of objectives into more specific goals, which are measurable. Covering such matters as functionality, performance, increased profits, and\or reduced costs.
3. Where necessary or useful, have relevant team member pursue research and analysis of suitable business domain solutions through the review of existing systems, reports, custom business documents and processes, commercial software candidate packages, and publicly available data models. The deliverable from this activity should be an assessment of suitable candidate packages, (if any), or a list of considerations that should be made in developing a new custom system.
4. Transition to short iterative development cycles where a limited set of specific system functionality and business rules are fleshed-out in a team meeting. Any consideration of additional modules outside of the primary one being worked on should only be considered at the boundary of their interaction with the current functional area under development. The primary focus should be the delivery of working software every couple of weeks. All development work to be centered around commonly understood business domain and database models, supplemented by a listing of business rules classified by their type. These rules should be documented in the system’s online (editable) help, along with any prose found necessary to communicate the systems purpose. Data or process flow diagrams should only be developed where there is strong case for such.
5. Actual programming within each iteration to be done with some form combination of RAD and Agile methodologies e.g. standard screen\report painting with walk-through, combined with extreme programming or test driven programming, with frequent code check-ins and automated tests and builds.
6. Regular reviews of ever more detailed working software by joint IT and business development teams, evolving the system one cohesive feature set at a time.
7. Prior to final delivery in any cycle, let users play with working model to see if any final changes need to be made.
Development Guidelines
Team Make-up
The development team should be made up of both IT and business people who meet frequently to define what should be in the next deliverable and review progress.
The team should have senior members from IT and the business domain involved from the outset to define the overall parameters\boundaries of the project and to help resolve any business issues and\or conflicts.
Additional IT staff and key users should be heavily involved as soon as project progresses to discussions that are detailed and pragmatically oriented.
These development teams should be kept relatively small and closely coordinate\ communicate their work on a frequent basis.
Team members should use the project’s common language and where possible involve people who are comfortable with both IT and business topics.
All projects should be guided by the chief technical architect and\or his direct assistance to make sure all efforts fit into the overall system vision for the company.
Team Meetings
Team meetings should start with an agenda, and have a moderator and time limit. They should quickly review what was previously agreed upon in the last meeting, and then quickly seek to make new progress building on what is already known. There should also be some mechanism for recording what is learnt, so people can review and confirm a common understanding of the material was achieved.
After initial broad stroke meetings in the early phase of a project, subsequent meetings should largely focus on what will be done during the next development\deliverable cycle.
Light Documentation
Just as it’s said a photograph is worth a thousand words, so can a diagram. Because of the power with which they can quickly convey a large amount of knowledge business domain and database model diagrams should be the primary tools of communication for the team.
An additional nice feature of diagrams is that they can be easily drawn on whiteboards or easels during meetings to keep people focused on the discussion at hand, and to solidify concepts brought-up.
The second level of importance for documenting is the use of functional lists bulleting what needs to be coded within the system and terse classifications of business rules that must be observed.
Data flow diagrams may also prove useful.
But long wordy prose should be discouraged, as subsequent changes to the document are hard to identify and people quickly get tired of reading lengthy documents with frequent changes.
However, terse prose on how the system works, along with concise statement of the business rules should be maintained as online help, as the system is being developed and being reviewed. That help should be editable by developers and quality assurance people so they can correct and update it as needed.
Modeling
Two of the most popular modeling techniques are Data Modeling and Use Case. The former is the more traditional one, while the latter is currently gaining popularity.
When using Data Modeling the following concepts generally have to be defined for non-IT members, (and this is as technical as it really needs to get for them): Entities, Entity Attributes, and Relationships between Entities including their type, (one-to-one, one-to-many\many-to-one, and many-to-many).
A decent alternative to the Data Modeling approach that is becoming increasingly popular is ‘Use Cases with UML Notation.’ It’s generally perceived by its promoters as being easier to explain to non-IT people then the Data Modeling process, as it primarily deals with simple stories about system usage.
Regardless of which approach is followed, the initial steps are the same i.e. define technical concepts, notation, and start fleshing out the domain diagram(s) slowly, while focusing on the development of a common language for the combined development team.
Development Iterations
The development team should focus on getting through an iteration of planning, development, testing, and delivery every couple of weeks or less.
Respect for schedules should be maintained, otherwise, overall control of the project will be weak. Thus, when schedules are running late, time boxing should be applied. After each deliverable is made, a post-mortem should be applied to see what went wrong and what went right. Things that went right should be applied again, while corrective action should be taken on those that went wrong before the next cycle of the project begins.
With regular and short deliverables, everyone will always be aware of how well the project is progressing, and any problem areas will be identified and tackled quickly.
Adaptability
Having frequent meetings and short development cycles allow the development team to quickly react to changes in business needs and specifications. The longer a project takes, the more likely the business needs will change while it’s progressing. Also, the larger a project, the more likely the team will not get every requirement correct up front. Having frequent deliveries of working software allows one to more quickly identify necessary changes and make sure they are incorporated in the next short iteration of the system, instead of trying to re-do everything at the end when there is much more to contend with.
