Hi All,
I have just taken on a new position at a company and have been tasked with putting a development process methodology in place. After spending some time looking at the various options I belive that FDD is the right direction for us.
I have done as much reading as I can and I am pretty confident on most parts of the process and where I need to make minor tweaks to fit in with our enviroment.
The main question I am a little stumped on is during the Planning by Feature stage it mentions devloping a "Development Sequence" what actually is this ? Also how/who decide what features are built in each iteration and is this done in the Planning by Feature stage or is this done at the beginning of each iteration ?
Thanks for any feedback
Dave
It's the sequence or order of business activities by date
Having decomposed the Features List (FBS) you specify the month/year that each Business Activity will be completed. This series of Business Activities by target completion date is what is called the Development Sequence in process 3. This is poor terminology and will be changed in the next version of the process descriptions.
There are no fixed iterations in FDD. Depending on your point of view, the thing that drives it is the Chief Programmers putting features into workpackages. A workpackage is some number of features that are to be put through Design By Feature (DBF) and Build By Feature (BBF). They are constrained by time in that it can take no longer than 2 weeks, but it is NOT a fixed 2 week cycle. At any point in time there will be a number of workpackages active and they will overlap each other (in time) by varying amounts.
During the construction phase (iterations of DBF and BBF) the Project Manager (PM) is assigning features from the Features List to Chief Programmers for DBF-BBF. The PM has the flexibility to pick and choose features as he likes. He is guided, of course, by the dates on the Business Activities, but does not have to follow the categorisation in the Features List or the implied date sequence of features (derived from the Business Activity they come from). A Chief Programmer (CP) then logically has an inbox of features waiting to be put through DBF-BBF. The CP himself decides which features to put into a workpackage. He has the flexibility to choose from his virtual inbox of features waiting for DBF-BBF.
Let me contrive an example:
There are seven features in the CP's inbox. The first three all touch a certain class. That class owner is known to be very busy this week. The next four features in the inbox are in a different area and touch classes that the owners are not very busy with. So, the CP takes the last four features and puts them in a Workpackage. It is at this moment that the CP sets the plan dates for the 6 discrete per-feature milsetones (domain walkthrough, design, design inspect, code, code inspect, and promote to build) and it is this act that identifies those features as now being "in progress."
Jeff
Going a little deeper
Jeff,
Thanks for the detailed response and I have found it very useful.
From reading through your response would i be correct in thinking that a chief programmer is rather like what is traditionally called a team leader and that he is responsible for drawing on the teams resources to get features in his work package completed ( as well as developing some himself )
If this is the case then would also be correct in assessing that a programmer who may own several different classes would get a virtual inbox listing all of the the changes that he is been required to make to the classes he own for server different cp/workpackages ?
Dave
What a CP does
Yes, a CP also designs and codes themselves - absolutely. A CP is also a class owner (a CP also owns classes).
Features are assigned to CPs. The CP looks at a feature, and using his knowledge from participating in the Develop an Overall Model process (in particular) he identifies in his head the classes this feature will touch. Since classes are owned by programmers, thus a feature team dynamically forms. Feature teams are forming all the time and a programmer will likely be in more than one feature team at a time.
I only use the virtual inbox metaphor to describe features that are asssigned to a CP waiting to be put through DBF-BBF.
A programmer is clear on what changes he needs to make to a class he owns as he participates directly in that feature team.
Having said that we do often use group calendar/todo list entries that list the things a class owner must do (see the last exit criteria of the Design By Feature process). You could just as easily call this a virtual inbox of changes he is required to make to the classes he owns (as you say).
Jeff
Feature Dependancies
Jeff,
Another little issues i have is where do you define the a feature depends on another feature to be developed first. For instance I a feaure which is to develop a sales commision algorithem. Then I have another feature with is to allow a sales to be entered. This second feature can only be written once the first one has been written. Both of these feature may be in the same feature set or different ones as well. At what stage in the process would you identify this dependency and how would you document the dependency ?
Dave
I don't show them explicitly
Hi Dave,
in practice, I don't show them explicitly as I've never needed to. The thing about process 1 Develop an Overall Model is the amount of knowledge transfer that is taking place. This is what allows a features list to be constructed that is both granular and accurate. As an exercise, after the features list is done, I can ask the team to rank a feature by complexity. For example, I can point to a feature and ask "this feature here - is it simple, medium or complex?" and I'll get a fast, unanimous response. Same if I point to two features and ask "could we build this feature before that feature?" which is asking about a dependency and again I'll get a fast, unanimous response.
This is also in the context of the features list being a functional decomposition of the domain, where the top-level categories usually come straight from the partitioning of the domain done by the domain experts in the Develop An Overall Model process (where they are asked to describe the domain in a series of 20 minute topics).The majority case here is that when asked to do this, domain experts will breakup the domain in terms of its major workflow.
Thus, from these top-level categories (that usually follow the major workflow in the domain) we functionally decompose them into the categorised features list.
One effect of this is that we get the same kind of benefits we get in tracking and planning in terms of a coarse-grained mechanism (month year target completion dates on business activities) and also a very fine-grained mechanism (self-organising workpackages of features and their milestone completion dates).
The same two-levels apply here. In other words, it is very easy to see dependencies between business activities (coarse-grained) and for the CP and programmers to see dependencies between features (fine-grained).
Jeff
Planning and late binding of features to development
Dave this is somewhat theoretical answer to your question.
Senior managers love to see plans and timelines. It makes them feel comfortable that things are under control. So early in a project you have to give completion date for a set of work (features). This the purpose of Process 3 - Plan By Feature - to lay out the planned development schedule.
At the same time it is valuable to be able to decide as late as possible what gets developed in a development iteration because of many factors - staff availability, technical issues, etc. Several Agile processes recognize this - XPs planning game and SCRUM schedule features for development immediately prior to the iteration. I have also used this approach and in FDD terms the CP is the final arbiter of what goes into the iteration and will decide from what is in a ready to design/build state.
Note that FDD reporting - Parking Lots - focuses on percentage complete and not on whether some timeline is being kept to as GANNT charts do.
The JMCU book says nothing about deciding the content of an iteration and a fully FDD exposition should address this issue.