Tuesday, August 30, 2011

Feature Driven Development

I don't understand why Feature Driven Development is not as known as other agile methods. Maybe it's because there are not so visible things like 2 programmers siting behind 1PC (extreme programming), people standing while short meetings (SCRUM)...


It's based on small pieces of final product with real additional value for customer  which are called features. There are 5 basic activities. During the first three of them (Develop Overall Model, Build Feature List and Plan by Feature) you establish an overall model shape. And the rest (Design By Feature and Build by Feature) are repeated for every feature. There is a nice process model diagram for this activities.

Feature-Driven Development is built around a core set of industry-recognized best practices. Part of Wikipedia article follow:
  1. Domain Object Modeling. Domain Object Modeling consists of exploring and explaining the domain of the problem to be solved. The resulting domain object model provides an overall framework in which to add features.
  2. Developing by Feature. Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature. This makes it easier to deliver correct functions and to extend or modify the system.
  3. Individual Class (Code) Ownership. Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. The owner is responsible for the consistency, performance, and conceptual integrity of the class.
  4. Feature Teams. A feature team is a small, dynamically formed team that develops a small activity. By doing so, multiple minds are always applied to each design decision and also multiple design options are always evaluated before one is chosen.
  5. Inspections. Inspections are carried out to ensure good quality design and code, primarily by detection of defects.
  6. Configuration Management. Configuration management helps with identifying the source code for all features that have been completed to date and to maintain a history of changes to classes as feature teams enhance them.
  7. Regular Builds. Regular builds ensure there is always an up to date system that can be demonstrated to the client and helps highlighting integration errors of source code for the features early.
  8. Visibility of progress and results. By frequent, appropriate, and accurate progress reporting at all levels inside and outside the project, based on completed work, managers are helped at steering a project correctly.
For me is it very well combined "old" (model-centered) and "new" (agile) concept of development process for middle-sized projects, but I haven't try it for any project yet.

I have a few question:
  1. Do you know FDD?
  2. Do you use FDD?
  3. What do you thing about?
  4. Which software do you use for support FDD?
Resources:
  1. Feature-drive development (Wikipedia, EN)
  2. http://www.featuredrivendevelopment.com/ (Community, EN)
  3. Feature driven development (Chapter 6 of book Java Modeling in Color with UML, EN)
  4. Feature-driven development and the ‘5 Ds of Done’ (Edward Kay, EN)
  5. Metodika feature-driven development neopouští modelování a procesy... (PDF, Alena Buchalcevová, CZ)
  6. Metoda FDD (překlad Jiří Sochor, CZ)

Thursday, August 18, 2011

How to find a reliable PHP development company?

I have a task - to prepare tender for contractor to our next project. We need a reliable company which works with PHP & MySQL & JavaScript. It's not so small project and we plan to maintain and add feature every month. So it's quit big deal if you see the long term. So I was thinking how to choose a good company for our project. And I have an Idea which I want to discuss with you.

Cube in orange stock photo by www.pixmac.com

I want to split the tender to 2 rounds:
  1. In the first I want to collect basic information through questioner about potential contractors and test communication with them. 
  2. In the second I want to invite selected companies from the first round and if they sign the NDA we'll send them a part of documentation and wait for comments and eventually the offers.
What do you think should be in in the questioner? I have tried to design a template for it, so we can improve it and than I can submit in to free templates to google docs. So here it is in Google docs:
As you see I have split it to 3 steps (actually 4 including the "Thank you step"). In the first I'm trying to get the basic information about company. In the second how they manage their source code and finally in the third how they work.

What's your comments to this questioner?

PS: If you want to compete in our tender send me mail please.

What should manager know?

While I was reading The Goal (E. M. Goldratt) I was thinking what should excellent manager do. The book didn't serve me the answer, but there were three core things what should every manager know:


Arrow & Young Businessman Lying in the Park stock photo by www.pixmac.com

  • What to change.
  • What to change to.
  • How to cause the change.
And what do you think?