Software the Agile Way....

User story-  As a product owner, I would like to get an web based email program by which I can compose email on-line and can send email. TDD-  This program should send email if To address is valid. This program should send email if CC address is valid even if To address is not valid This program should send email if BCC address is valid even if CC and To address is not valid. This program should send email even if the subject line is empty. This program should send email even if the body is empty. Problem in this - T here might be some more test cases if the option stated in 1, 2 and 3 are altered. Even there might be more test cases if he considers the format of the body of the email (like plain text, rich text or HTML). If the body is HTML, then he needs to think about the HTML encoding things. BDD- Given  that a web based email module has been developed And I am accessing it with proper authentication When  I shall write sender email address i...

BDD is usually done in very English-like language helps the Domain experts to understand the implementation rather than exposing the code level tests. Its defined in a GWT format, GIVEN WHEN & THEN. Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design Instead of writing tests you should think of specifying behavior. Behavior is how the user wants the application to behave. When your development is Behavior-driven, you always start with the piece of functionality that’s most important to your user. I consider this phase as taking the developer hat off and putting the user hat on. Once you've specified the user needs, you put the developer hat back on and implement your specification. Test-driven development focuses on the developer’s opinion on how parts of the software should work. Behavior-driven development focuses on the users’ opinion on how they want your application to behave.

http://www.isixsigma.com/tools-templates/sipoc-copis/sipoc-diagram/ The SIPOC tool is particularly useful when it is not clear: Who supplies inputs to the process? What specifications are placed on the inputs? Who are the true customers of the process? What are the requirements of the customers?

Requirements Definition Creating context and process diagrams Creating functional specifications Creating technical specifications Participating in business system design Prototyping Creating/Executing test plans Systems Implementation System documentation Production support Work with external (3rd party partners) Project Managment and status communication

responsible  ensuring  finding  help  understanding  coaching  removing 

Waste is simply anything that does not add real value to the overall end goal is considered waste. Things that could be considered waste are  - Unnecessary features or functionality  - Over engineering  - Unnecessary code  - Weak requirements  - Bureaucracy  - Anything that slows down or delays the team  - Weak testing, resulting in many production issues  - Poor or unnecessary communication  - Unnecessary documentation (note documentation may still be needed)  - Anything that wastes time without any valuable benefit   "The Seven Wastes of Software Development":  1. Partially Done Work  2. Extra Features  3. Relearning  4. Handoffs  5. Delays  6. Task Switching  7. Defects

http://agileramblings.com/2012/12/11/littles-law-its-not-about-the-numbers/

List of Topics on which I specialize and would like to talk in my future posts..... Agile Modelling Agile Unified Process (AUP) Crystal Clear / Methods Dynamic Systems Development Method (DSDM) Extreme Programming (XP) Feature Driven Development (FDD) Graphical System Design (GSD) Kanban Lean Software Development Scrum Velocity Tracking Software Development Rhythms

  Improve quality    -     Reduce cost      Improve time to market      Improve teamwork      Increase customer involvement