Feature Driven Development

Six Key Roles

1. Project Manager
2. Chief Architect
3. Development Manager
4. Chief Programmer
5. Class Owner

The five processes of FDD

1. Develop an overall model
2. Build a feature list
3. Plan by feature
4. Design by feature
5. Build by feature

Design by feature
       1% domain walkthrough      
     40% design
       3% design inspection
Build by feature
     45% code
     10% code inspection
       1% promote to build

Feature
    

Meine Idee für eine Systemdokumentation (ähnlich Pflichtenheft)

• Intro
• Context (Diagram)
• Use Cases
• Interfaces
• Data Structure (DB Schema)
• Aspects
  • Logging
  • Security
    • Authentication
    • Authorization
    • Transport
  • Data Consistency (e.g. transaction handling)
• Service
  • Garbage collection (e.g. removal of old data from DB)
  • Updates
  • Configuration
  • History / Revision
• Laws / company rules

Lastenheft - Inhalt

1. Ausgangssituation und Zielsetzung
2. Produkteinsatz
3. Produktübersicht
4. Funktionale Anforderungen
5. Nicht funktionale Anforderungen
   • Benutzbarkeit
   • Zuverlässigkeit
   • Effizienz
   • Änderbarkeit
   • Übertragbarkeit
   • Wartbarkeit
6. Risikoakzeptanz
7. Skizze des Entwicklungszyklus und der Systemarchitektur oder auch ein Struktogramm
8. Lieferumfang
9. Abnahmekriterien

Test case outline

• Introduction/overview contains general information about Test case.
  • Identifier is unique identifier of test case for further references, for example, while describing found defect.
  • Test case owner/creator is name of tester or test designer, who created test or is responsible for its development
  • Version of current Test case definition
  • Name of test case should be human-oriented title which allows to quickly understand test case purpose and scope.
  • Identifier of requirement which is covered by test case. Also here could be identifier of use case or functional specificationitem.
  • Purpose contains short description of test purpose, what functionality it checks.
  • Dependencies
• Test case activity
  • Testing environment/configuration contains information about configuration of hardware or software which must be met while executing test case
  • Initialization describes actions, which must be performed before test case execution is started. For example, we should open some file.
  • Finalization describes actions to be done after test case is performed. For example if test case crashes database, tester should restore it before other test cases will be performed.
  • Actions step by step to be done to complete test.
  • Input data description
• Expected results contains description of what tester should see after all test steps has been completed

The Rules of Stand Up

1. The first rule of Stand Up is, you do not talk while someone else is talking. 
2. The second rule of Stand Up is, you DO NOT talk while someone else is talking. 
3. You talk fast and you keep it moving fast. 
4. Tell us what you did yesterday. 
5. Tell us what you FAILED to do yesterday. 
6. Tell us what you will do today. 
7. Tell us who is BLOCKING you today. 
8. If this is your first day at Stand Up, you have to talk.

from:- i am pretty sorry, but i do not recall where i found it! I would be happy to link the right source!

Some things i came across in india... best practices for the rest of us

Some things i came across:

• Do not double-assign tasks to different people 
• Do not switch task assignment when first one is 90% done - second person will start from zero again 
• Do provide clear and precise bug reports.
  
  
  • Actions to follow when reproducing behaviour
  • Rerence to testcase if applicable
  • Expexted result
  • Actual result
  • Log files, error messages, etc.
  
  
  
• Provide tracebility requirement->testcase->bugs/status 
• Do not put date/version tags to the file names when using svn. Use svn mechanismn (copy to version) instead! 
• Do not produce multiple copies of documents in different folders
• If you change something (code, config, etc), send precise and complete information
• Use same logins (username,password) on every environment 
• Don't change them 
• Provide public list of these logins (put on wall!). 
• Do project/task planning in one location only. Do not mix MSProject, Excel, Whiteboard, Resultspace. This will become a maintenance nightmare! 
• Plan activities or results, not fluff like "Anything else?" or "Multiple CDP porlets on same page leads to multilple calls to Content fetch" 
• Intregrate specialists early in the project, especially in the design. It does not really help to do a bad design, than get lot's of experts to help implementing this.
• Get experienced people and leverage them properly. Do not let them do trivial things... They are too expensive and get pissed off easily.
• Do not start project with tons of rookies... 
• Assure they know the basics upfront. You cannot easily teach a 4 years old how to drive a Ferrari... 
• Have Arch decisions double checked by someone else. They may be wrong...
• Go for simple approaches, do not plan to future proof everything. 
• Watch performance impact early. After 96% completion, it becomes harder to change. 
• If you identify potential problems, clear them immediately, even if LOE seems to high. Later they will catch you again... (e.g. logger - my fault not to escalate it...) 
• Enforce some discipline (be on time, read and answer email, check your own stuff, inform properly and precise, provide ALL necessary information,...) 
• Setup process for environment replication early (ghost images, vmware, etc.). See this: 50 developers spend minimum 2 days on setup and also need help from others => Minimum waisted time= 100 person days = ??Euro?? 
• Setup monitoring and notification early. How often did we have the case of not running servers and following research? 
• Environment down => 2-50 people playing pocket billiard... 
• Provide a valid build process early. In the 39th week of implementation you don't want build problems any more...
• Start vertical slices of complex functionality early. Release working software often, with minimum functionality. E.g. implementation for CDP as a very important part of the solution might have started much earlier. And you always want to be able see something... 
• Setup continuous integration - at least for common parts like framework or portal_commons, etc.
• Watch dependencies and 3rd party library usage!! We currently seem to include every open source lib in the world... 
• Provide reasonable hardware. 100€ (even 1000!) for Ram is nothing compared to people being unproductive. 
• Have QA people who know their job. Rookies will not give you any benefit here! Only if you want a "delivery assurance" instead of "quality assurance". But, this will get you later...
• Value/productivity of really good people compared to rookies can be 1:10!! So, get the best and let them do what they can do best! 
• Roles of senior developers/techies needed! There currently is a gap.