1. Water fall ( Microsoft Solution Framework)
The project is divided into following phases:
Envisioning
gathering and documenting requirements, at the end of phase, the requirement get sign off. The requirement are documented in the form of user case documentation set ( User case description document, User case diagram and activity diagram), wireframes and a set of non-functional requirements . the main players in the phase are BA and User experience designer.
Planning/Design
I started my engagement with the project as the architect in this phase, I was not in the project when it was in Envisioning phase. Based on the output in envisioning phase. the architect and designers design system archituere. The design artifacts are in the form or package diagram, component diagram, class diagram, and sequence diagram, class / member description and deployment diagram. Based on the design artifacts, we de-composite the components into WBS, and ran then through an estimation model. Based on the WBA and their estimation together with the resource information, the team led by the PM established development schedule. A key consideration for scheduling is the dependency of the WBSs. It as bottom up model. In another words, we planned to work on database tables, views , triggers, functions and then stored procedures. After that we worked classes in data access layers, then business layers …finally on UI. At the end of the phase the development schedule get sign off by the client.
Building
This is the phase lots of developers got involved, we did weekly planning to put these WBSs into development, a typical WBS is like a method of a specific class, a user control, a window form, a web page. The developer construct the component based on class / member description… for an example, I was given a task to write a data retrieving method to load a list of customer based on some search conditions in a data access class. As a developer, I did not need know how is the method is used on use case, or calling sequence, but I was told which base class I would be using and which stored procedure I would be calling.. when I started to work on the WBS, the base class and the stored procedure were there for me to use.
Stabilize
This is the time the QA team got involved. When we finished all WBSs, the system supposed to work, If it was bug free. Of course it was not the case. After the QA team run through the system with their test cases. Lots of bugs were identified. We had design bugs, programming bugs. All developers are assigned to bug to fix them. When we claimed these are fixed, the QA ran their test cases. More bugs are identified and some resolved bugs got re-opened… then we try to fix them again… finally all the bugs with Exit Criteria are all resolved. the UAT passed, and client sign off for deployment. At that time, the development team start to down size and I left the project…
Deploy
Omitted
Support
Omitted
2. Agile ( extreme Programming)
I got into the project at very beginning of the project, my first week was conduct a .Net training for these who never done .Net before ( they were COBOL or JAVA developers).
The project decided to do weekly iteration. The iteration officially starts on Monday. on Friday morning we demo what we did in the week to real end user. In the afternoon, the real end user tells the user story she wanted to be done in next week.( the user stories were in hand-writing) .. after getting the user stories, we developers do some brainstorming have some discussion document them in whatever way we feel like. On Monday we start to write code… every day, our real user is sitting next to us. She was ready to explain her user story, and questions, and making decisions on requirement. There was nearly no documentation at all, let alone design documentation…
There were 4 important particles we follow:
a. pair-programming
b. test driving development
c. Continuous integration
d. Dare to refactor
during the time, I read many books on extreme Programming. One of the good books was Extreme Programming Explained by Kent Beck. It looks like what the project did was quite close to what Kent Beck described in his book. An observation I had during the time, was, it looks like every developers are designer, so it posed high demand on developers. At the same time, as it believe in a. pair-programming, so new fresh developer can get into the team very easily…
No comments:
Post a Comment