Agile training

1. intro of agile:  intro_of_agile.pdf
2. Scrum process & Scrum planning : Day1_CoreScrum_training.pdf Day2_PlanningAnAgileProject.pdf

 

 

통합 Pt : 20100302[2].ppt

 

Sustainable Software Development_ An Agile Perspective ( Kevin Tate )

chapter 1. sustainable software development

 

• Outline: the value of sustainable development

 

• the more successful an application or tools is, the greater the demands placed on the development team to keep up the pace of innovation and feature development.

 

• unsustainable development:

1. over or under design
2. code first then fix defects later(code-then-fix)
3. too many dependencies between code modules
4. the lack of safeguards such as automated tests
5. temporary patches or workarounds that are never addressed.

 

• unsustainable development: reactive to changes in their ecosystem -> death spiral
• sustainable development: able to be proactive about changes in their ecosystem. -> virtuous cycle

 

sustainable development

 Sustainable development is a mindset(principle) and an accompanying set of practices.

 Optimal doesn't mean fastest - that would be pure coding, such as for a prototype.

 

Sustainable development is about efficiency and balancing the needs of the short and long term.

• the needs of the short term are met by regularly producing software that has the highest possible value to customers.(low cost)

   

Chemical Manufacturing and Sustainable Development

productivity at chemical manufacturing plants has parallels in software development.

 

Working harder(more hours)

• short-term increase in overall capability

• long-term effect is actually declining capability(vicious cycle or death spiral)

  • unanticipated side effects -> As more hours are worked, more mistakes are made.

•  Parking Lot Managers: Managers who judge the morale or productivity of their company by how many hours their employees work on evenings and weekends on a regular basis. -> No coreelation with the number of hours worked. because.. working harder may be valid in ther short-term when concerted effort is required.

 

Working Smarter

• taking the time to examine the entire plant's systems and processes and continually attempting to identify problems before they occur.

• consistently produced better results over the long term especially doing preventive maintenance.

Continual Improvement: The Accelerator Button

 The main lesson is that in sustainable software development, you need to strive for continual improvement while resisting the temptation to focus on features and simply working long hours to meet demands.

 

1. Many developers have a mindset that non-feathre work is not part of their job. -> focused on defect detection, not defect prevention.

   -> if developers don't personally pay attention to the infrastructural details of their products, it is all too easy for problems to creep in that eventually impact key performance indicators that also impact developers productivity.

   -> extremely expensive, wasteful

2. Managers must recognize that they have a key role in leading the attitude of the organization.

3. Many software teams are unable to pay attention to the "health" of the underlying software or the development infrastructure.

   -> this is a key part of the software development death spiral

4. use shortcuts that compromise the underlying architecture  -> broken windows (ch.4)

 

A Sustainable Development Experience

the vital to the success of the company's products

: produce the amount of work they did and keep quality so high.

 

1. our software worked every day.
2. we relied heavily on automated testing to catch problems while we were working on new features.
3. we had high standards onf testing and code quality, and we held each other to those standards.
4. we didn't overdesign our work and built only what our customeres needed.
5. we were uncompromising with defects, and made sure that all the known defects that were important to our customers were fixed in a feature before we moved on th the next one.-> never had a defect backlog.
6. we replanned our work as often as we could.
7. we were always looking for ways to improve how we worked and our software.

 

chapter 2. Unsustainable Software Development and its Causes chap2.ppt

 

 

Figure 1. Unsustainable development is characterized by a constantly increasing cost of change to the software. The usual evidence of a high cost of change is a constantly increasing number of defects. Each change adds complexity and uncovers or causes defeats that require more changes, and this complexity leads to a declining ability to respond to customer requests and changes to the ecosystem

 

 

[Unsustainable Development and the Boiled Frog]

• If you are working on a project on the unsustainable developement path, you may not be aware of it.
• If you drop a frog into a pot of boiling water, it will immediately jump out.
• But if you put a frog a pot of cold water and then slowly heat it up, the frog will stay put until it is boiled.
• The difference between you and a frog is that you have a significant ability to influence the temperature of the water through your actions and by collaborating with others.
• You have to be able to make an honest assessment of your situation ans be willing to make change.

 

Technical Debt and the Flywheel

• Technical Debt: The underlying cause of the inability to develop new features due to a defect burden
• Technical Debt is caused by an accumulation of poor decisions over time
•  Flywheel metaphor: describes how decisions affect momentum in an organization [Collins, 2001]

 

 The Perils of Jumping in Place

• One strong piece of evidence for technical debt in the software industry: the number of products that  must be completely rebuilt in order to keep up with competitive products or to respond to a major technology change.
• Jumping in place(the same market with a similar product)
• Even if the product is truly better, the loss of market share and customer mindshare is not easily overcome, especially since existing competitors will have gotten stronger and new competitors entered the market during the time required to build the next generation product

• example: Osborne effect

   - Osborne produced one of the first portable computers in the 1980s. It had a successful computer on the matket that was selling well. For some reason, it decided to build a replacement rather than refining its current product. This was a huge mistake; customers stopped buying Osborne computers to wait for the new generation, cash got tight, the new product fell behind schedule, and soon Osborne Computer was in bankruptcy.

• Bankruptcy is the extreme end of a spectrum of lost market share

 

The Causes of Unsustainable Development

 

Figure 2. Software projects are subjected to a number of project stresses that can't be controlled. These stresses are a constantly changing set of forces that push your project towards unsustainability. You can employ a number of defenses that you can control or influence to try and keep the project on a sustainable path.

 

Project Stresses

1. User Requirements: continually evolve and change
2. External Dependencies: Today's software depends on operating systems, libraries, third-party components, computer hardware or hardware interfaces,etc. The steady advance of technology means that changes to these interfaces are a given. The software team must support the old and the new inerfaces. This adds to development complexity and to the risk that the software will break in unexpected ways.
3. Competition: It is relatively easy to set up a software organization today because the barriers to entry are low. All that is needed are some bright people, a few computers, and a connection to the Internet to get started. But unfortunately, many companies lack is a workable business plan. They may be good at getting initial funding and making some initial sales, but most software organization struggle to stay in business.
4. Disruptive Technologies: Internet is an example of a disruptive technology.
5. Disruptive Business Models: Dell computers(Dell does not innovate technologically; their innovation is the ability to produce computers on demand by clustering their suppliers and taking all orders over the Internet), Open source software()
6. Cost Management: Because of the complexity of software development, it is hard to control costs through greater efficiency. Achieving high efficiency is difficult because of factors such as the mindset of the organization, its processed, training,deadlines, etc. Hence, the easiest way to reduce costs is to employ people such as the India and the China. But more people in the industry need to recognize the need for efficiency, because efficiency is at the heart of sustainable development.

 

 Project Controls

1. Collaboration: Working effectively with other people in your organization and your customers is a crucial aspect of software developement. Good things happen when people can cooperatively work together toward a common objective

2. Methodology: The development methodology, the principles and practices you use, has a dramatic impact on the success of a project. Methodology directly influences efficiency, change tolerance, responsiveness, ans software quality.

   • Plan-driven development: emphasis on producing documenets of requirements, designs, test plans, etc.
   • Documentation has value as an important means of communication,
   • The real value comes from the process you have to go through to produce the documentation, not from the documentation itself
3. Expertise: Expertise with software development and with the project's ecosystem is a strong indicator of success
4. Decision Making: Your ability to make decisions in a complex and constantly evolving ecosystem, often with incomplete information, is crucial to success
5. Leadership: Leadership helps to keep projects on track
6. Culture: The culture of an organization shapes the attitudes and priorities of the people who work in it

7. Simplicity and Reliability:

   • The vast majority of software today is overly complex, hard to use ans learn, and has too many features for most of its users

     : Office97 version of Microsoft Word had 265 functions, only 12 functions were used by more than 75% of users, and 42 were not used at all![McGrenere 2000]

   • Software is notoriously unreliable. Many users refuse to buy the first version of any software product, and users are frequently frustrated by version upgrades

     : Apple's iPod, Palm PDA are simple and reliable devices that are popular because they do a few things very well

 

 Summary

 Unsustainable development

• a development pace that is typified by stress, frustration, and a sense of not being in control

• evidenced by a continually increasing cost of change and defect rate and a corresponding decreasing ability to respond to changing condition

  => In order to achieve 'sustainability', the organization must recognize its stresses and continually adjust its defenses and coping mechanisms

 

 

Chapter 3. The principles of sustainable software development

 Chapter_3.ppt

 

• In the traditional software organization, the emphasis in software development is on features, bug fixing, and the plan.

  analysis and design -> development of a plan -> coding -> testing -> fixing of problems -> careful tracking against the plan -> use

•  The linear (waterfall) approach to software development is still the primary method of software development taught in school. <- engineering approach
•  Software developers do not receive an education that prepares them for the real world(complex, changing ecosystem of technology, competitors and customers).

=> In order to provide a bridge from the academic to the practical worlds, we need a mindset that can be used to create a culture of  sustainable development.

 

why principles are more important than practices

 

• the difference between principles and practices ≒ the difference between vision and features in a project

• • unsuccessful project : start by defining a set of features that when put together are surmised to meet some user need.

  • successful project : start with a clear user need and a vision of how to meet that need.

     

• Key aspects in the vision-oriented approach to product development

1. A user need and vision so it is clear what is being built
2. rapid refinement to adapt to change
3. a close relationship with users so they can provide timely feedback
4. continual learning to refine the product so it best meets user needs while avoiding unnecessary features

 

• in sustainable software development, the principles are like vision and the practices are like features.

  • principles define "what you want to accomplish"

  • practices define "how you want to go about it"

     

•  Great teams...

  •  recognize that What they are trying to achieve is more important than how they achieve it.

  •  see through the strict rule-based facade

     

•  three elements to sustainable development :

1. a vision and set of guiding principles that define what needs to be accomplished.
2. practices that are consistent with the principles.
3. a tight feedback loop of experimentation, learning, and refinement.

 

<Applying the principles of sustainable development>

1.  Continual Refinement of the product and project practices

    : at the start of any project it is impossible to plan for all the required changes (user requirements, evolving ecosystem of markets, partners, technologies, competition). Therefore, teams must plan for change and implement practices that enhance their ability to change.

    => Continual refinement defines a set of practices that establish a heartbeat for a project. this hearbeat establishes a steady rhythm that is used to keep the project going and continually monitor progress in a lightweight way.

    

2.  A working product at all times

   : A software product should always be in a working state. this mean it works and has high quality. a secondary meaning to this principle is that the emphasis of the team i on producing a working product and sipping it.

   => A working product ensures that time is spent on productive activities.

    

3.  A continual investment in and emphasis on design

   : Agile software development advocates designing only what you need today

   => good design and sustainable design practices extend the life of the product by keeping the implementation in a healthy state that enhances maintainability and changeability while ensuring there is a simple long-term design vision.

    

4.  Valuing defect prevention over defect detection

   1. defect detection

      : involves trying to find and fix defects after changes have been merged into the production software.

   2. defect prevention

      : emphasizes catching defects before the changes are merged into the production software.

 => An emphasis on defect prevention is required for sustainable development to ensure the development team is highly efficient and is putting its effort into creating value for the customer. Also, by minimizing the number of defects that reach customers, development teams are able to have productive conversations with users about features and workflow.

 

Striving for Sustainable development is like juggling

 

Figure 3-1

Juggling demands you understand each ball, its shape, weight, color, and texture, and that you are able to focus on any one ball while keeping all four in focus.

The larger balls that represent features and bugfixing are completely different in shape and weight from the small balls. the complexity of the task of juggling the four small balls and two large balls usually leads teams to juggle only a few balls because that's much easier.

=> great software teams are able to juggle all six balls. They understand that juggling the small balls comes first because they are more predictable, and this makes the task of juggling the large balls much easier.

 

culture, by descriptive words and phrases

1. disciplined

   : difference between discipline and ceremony

   1. Disciplin is what the team uses to ensure that all the work is done properly and with no shortcuts.

   2. Ceremony refers to the required activities that must be performed in a project.

       

2. responsible
3. leadership
4. visionary and tactical
5. shared sense of urgency
6. highly collaborative
7. complementary talents and skills
8. continually improving and learning
9. change tolerant
10. risk-aware

11. fun

    chapter 4. Working Productchap4.ppt

     

    • It is the ultimate goal for every software team.
    • It is an underpinning of agile software development.
    • It could be called 'virtually shippable'.
    • It means that can be shown to or given to a customer for use with the minimum possible number of unexpainable errors.
    • It imparts greater flexibility and agility.
    • Achieving a working product is not extra work if it is done every day!

     

    [Why Working Product and not Working Software?]

     In customers' point of view, they rarely receive just software. Software is almost always accompanied by explicit deliverable and implicit deliverables. Working product emcompass all the explicit and implicit deliverables and reinforce the requirement. Software is one important part, but not the only part.

     

    [The Need to Address Quality Promptly]

     Software teams may hate having to stop their work, but addressing quality concerns promptly is a critical part of keeping a product in a working state while minimizing the effort required to keep it in that state.

     

    [Ship at Unpredictable Times]

    One of the chief advantage of having a working product is being able to ship at unpredictable times. Having a working product alloewd the flexibility and confidence to ship when it wanted.

     

    Practices

    1. No 'Broken Windows'

       Broken windows: Once a house has a broken window, the occupants of the house will tend to be careless and more prone to leaving broken windows thenselves. Software has same properties as a house, once one sloppy change has been made, other will follow. Therefore, never start the decay, and if you find some bad code, clean it up immediately.

       [Imagine that your customer can see your broken windows]: While being under extreme time pressure may be a valid reason for leaving a broken window.

    2.  Be Uncompromising about Defects

       It is vital that you adopt an uncompromising attitude toward defects.  The goal is to avoid a defect backlog, where there is a list of open defects that is too large for the team to deal with immediately.

       A defect backlog must to be avoided because it makes many tasks such like repetitive searching, sortingans categorizing that make waste time and cost of fixing. Therefore when a defect is reported, decided as quickly as possible to either fix it or get rid of it and fix regressions.

       Put more effort into defect prevention than bugfixing(defect prevention is described in detail in chapter 5). Being pragmatic about defects.

       [The value of being Uncompromising] : What mattered was the mindset.

       [Use a defect tracking database, but don't built it yourself!] : Using a defect tracking system like bugzilla

    3. 'Barely sufficient' Documentation

        In order for teams to concentrate on a working product, they should minimize the amount of time spent writing documents that are not part of the product. Barely sufficient documetation is another important part of Agile. Many people lose sight of the fact that what truly matters in any development project is the process, especially the conversations and decisions required to produce a useful product. Customers don't know what they want until they see it;; documents don't help customer at all!

       [Minimal documentation and code comments]: Some people carry the drive for minimal documentation too far. But it is a dangerous attitude because good comments aid the understandability of code. Many of the best programmers I know write the comments first and describe the logic of what they are doing and then they write the code.

       [The dangers of excessive decumentation]

    4. Continuous Integration

       Frequent integration helps to ensure that modules that must fit together will, and also that the product continues to work with all the changes. Developers should integrate their work every day, or even better, many times per day. This gradual intoroduction of changes ensures that integration problems or regressiona are caught early.  In order to catch the problems, your team has automated tests in place to help catch integtation problems as explained in chapter 5.

    5. Nightly Builds

        In order for your team to ensure that your software is working, it should be comlpetely rebuilt from scratch. The build should be include as many automated tests as possible to catch integration problem early. Nighttime is a good time to do this because no one is working on the code, and there are plenty of idle computers available. You should always keep on eye on the product build times. The faster you can keep the build, the faster the feedback you 'll get when you need to quickly generate a cut of the product. Long build time are almost always an indicator that something is wrong with the structure of the product.

    6. Prototyping

       Prototypes are an inexpensive way to try out ideas that as many issues as possible are understood before the real implementation is made. There are two main classes of prototypes that you can use to positively impact your product. The first is the true prototype, where a test implementation is used to understand a problem before it is implementated for real. The second is the notion of 'Tracer bullets'. Reducing risk is a key part of working software.  Prototypes are an extremely effective and relatively inexpensive way to evaluate risks.

       'Throwaway prototype' is an excellent tool to evaluate risky features ans develop better time estimates for a feature.

    7. Don't Neglect Performance

        Performance is one topic that generates passionate discussions in software development. You must be concerned with performance AND clarity, with a strong bias toward the latter. You need to understand what the customers's expections are, design for the right level of performance from the beginning and where performance really matters, ensure that you have tests to measure performance and let you know when performance degrades in a noticeable way.

    8. Zero Tolerance for Money and Resorce Leaks

        If you develop in a programming language or enviroment where memory or resource leaks are possible, you must have zero tolerance for leaks.Resource leaks lead to unpredictable behavior suah a program crashes. You exercise due diligence- don't just ignore trying to find leaks. The tools available today have APIs that you can hook up to your application to start and stop leak detection. These can be very useful.

    9. Coding Standards and Guidelines

       Team should follow the same formatting conventions. Make sure that your team talks about what good code is and what coding practices team members like and dislike. Having consistent coding conventions simply makes code easier to read. There is a huge benefit to having the team discuss good code and bad code; they can learn from each other and understand each other's viewpoints. Our goal was simply to avoid problems like files being reformatted(to suite someone's taste who uses different conventions), variables being renamed(because of different naming conventions), and multiple conventions being used in the same file.

    10. Adopt Standards(Concentrate on Your Value-Add)

         It means that don't reinvent the wheel. You need to understand where your value-add is, and the ensure that you put as possible into portions of your project that are not value-add. One of the most significant changes to the softwareindustry is taking place in open source software. Open source is doing is changing our definition of what is plumbing and what is value-add. If the provider doesn't or can't fix the problem in a timely manner, you often have to implement an ugly workaround. With open source, you can make the cahnge and submit it to the community, where all the other users benefit.

    11. Internationalize from Day One

        Get in the habit of ensureing your products are internationalized from day one. Internationalization is act of making software capable of displaying its user interface in multiple languages. Localization is the traslation of text strings into other languages.

    12. Isolate Platform Dependencies

        If your code must support multiple platforms, a clean seperation between platform-specific code and all the other code is essential to have software that can be easily kept in a working state.Platform dependencies are important to your project, take the time to do right. The effort will pay off.

     

 

 ch.5 Defect PreventionCh5.ppt

 

•  Defect detection

  1. the code-then-fix (features are developed-> testing -> defects are fixed)

  2. the majority of defects are found through manual testing and after code has been integrated into the product

  3. low-value manual testing, elaborate defect tracking system -> time delay between when a defect is introduced and when it is fixed

   

•  Defect Prevention

  1. features are developed using automated tests and related practices that catch the vast majority of defects when they are introduced so they can be fixed immediately when it is cheapest to do so.

  2. the emphasis is on finding defects before integration into the product.

  3. automated testing, high-value manual testing

 

figure 5-1

 

In a culture predominantly oriented around defect detection(left), the main burden for finding defects is placed on a quality assurance organization, and quite a few defects are shipped to customers. However, in a defect prevention culture(right) the largest numbers of defects are found at the earliest possible moment, before the product reaches quality assurance, and very few defects are shipped to customers.

 

The Role of Quality Assurance

: to ensure that new features work in ways that customers expect them to and that the product as a whole capable of meeting customer's need.

※ In a culture that emphasizes defect detection, the end result of QA's spending too much time on low-level testing and being relied upon too much for defect detection is that defects in new features and serious workflow problems are going to be shipped to and found by customers. This is the most expensive scenario for fixing these problems.

 

Practice 1: Ruthless Testing

Ruthless testing is all about developers doing absoulutely everything in their power to ensure that their software is as heavily tested as it can be before the software reaches people, both QA and customers.

 

Figure 5-3

 

 The different types, or levels, of tests that should be utilized in ruthless testing. the types of tests are organized by how aware they are of user tasks and code implementation. User-awareness indicates how close the tests are to replicating exact tasks that users perform. Code-aware-ness indicates the degree of knowledge the tests have with the actual implementation of the product.

=> Ruthless testing requires a strategy that mixes both code-level and user-level tests.

 

1. Unit Tests: Test-Driven Development

   1. Unit tests are the lowest level of tests you can create for software.
   2. Test-driven development means writing the unit tests for new code before writing the code and then ensuring that the tests always pass whenever new changes are made.
   3. In test-driven development, tests are run every time the developer builds the software.

   4. benefits:

      1. code with tests can be modified and refactored with a great deal of confidence
      2. preventing defects in existing features

      3.  spend less time debugging their software.

          

2. Integration Tests

   1. integration tests can be a useful mechanism to document and test the expected behavior of a library.

   2. integration tests can be useful because they are separately maintained and created from the unit tests.

       

3. System Tests

   1. system tests are automated tests that cover the functioning of the complete, integrated system or product. system tests know nothing about the structure of the software, only about what the product is intended to do from the user's standpoint.

   2. system tests are the most difficult type of test to implement well. this is because in order to be useful over the long term, the system test capabilities must be designed into the software. also, it is exceptionally difficult to add system test capabilities to existing software.

       

4. Record and Playback

   : it is possible to read the log file back into the application and have the application perform all the operations recorded in the log file in the same sequence and at the same time to produce the same result as when the recording was made.

   ※ the automation of user interface testing

   : one of the most frequently cited complexities in system testing is testing a product's user interface. one way to test applications with any type of user interface is through a record and playback architecture where all user input is captured in the recording and ban be played back.

    

5. Visual Validation Testing

   : Visual applications are the most complex to produce automated tests for. it is important to ensure that the amount of visual verification required is at an optimal minimal level. this is only possible by automating the code-aware tests as much as possible to ensure that focus can be put on the verification, not say testing for regressions.

    

6. Performance Testing

   : performance tests ensure that your application achieves or exceeds the desired performance characteristics. the most common way to do performance testing is by using system timers in your tests and either logging the results so they can be compared or graphed against previous test runs or by creating a test failure if the performance is not within some expected range.

   ※ Run-Time Monitoring

   : a run time monitor is a piece of code that can be enabled or disabled and displays or saves a log of critical events.

    

7. Resource-Usage Testing

   : Resource usage testing ensures that your application is using desirable amounts of memory, CPU, time, disk bandwidth, network bandwidth, for example.

   three factors...the type of application, the operating system, the programming language

    

8. Regression Testing

   : regression tests are tests written to prevent existing features or bug fixes from being broken when new code changes are made. they are included as a reminder: be sure to add tests when you fix a defect.

    

9. Usability Testing

   : for any application with a user interface, usability testing is a critical part of sustainable development and should not be considered optional unless the interface is brain-dead simple.

    

10. User Verification Testing

    : user verification testing is typically the last type of testing that is performed before a product is installed and actually used by customers. it isn't necessary for all products and will depend on the customer. this testing involves real users performing real work on the software in conditions that are as close as possible to how the end-users will use the product, often in parallel with the live system.

     

11. Resources Required for Ruthless Testing

    :Ruthless testing is only effective if tests are easy to run and results can be obtained and analyzed quickly. Ruthless testing may require additional computing resources and effort, depending on the size and complexity of the product.

 

Practice 2: Use Available Tools

: better tools are becoming available all the time, and it is important for a team to know what tools are available and how they could help.

1. Compiler

   : a compiler is the perfect example of a tool that virtually everyone uses, but that is not always as effectively as it could be.

   => you should understand the warnings

2. Source Code Analyzer

   : a source code analyzer is a tool that detects common coding errors that require more sophisticated analysis than that performed by a compiler. these tools are obviously language dependent and typically come with a default set of errors they look for, but they can also be customized.

3. Test Coverage Analysis

   : a tool you should consider using is one that measures how many source code statements are "covered" by your tests. this measure of coverage can be used to help add tests to get more coverage and even to remove tests, which can be necessary when your tests take too long to run.

4. Execution Profiler

   : an execution profiler is a tool that helps pinpoint performance problems in code. typically, these tools give you a report of the methods/procedures/functions in your code that are taking the most time in a given run. you can use these reports to examine the methods in question and determine if there are any obvious performance issues.

5. Event Logging

6. Source Code Documentation

   : extract documentation from your source code and generate a set of web pages

7. Memory and Resource Leak Detection

   : memory leaks result when a developer allocates memory for an object but doesn't free it, and she is using a language and/or run-time environment that has no memory management.

8. Configuration Management

   : all assets developed for and used in a project should be stored in a configuration management tool. a good CM tool should allow a team to do basic version control over a network and also provide some form of merging changes together.

 

Practice 3: Pair Programming and Code Reviews

there are two primary ways to ensure someone else looks at code changes:

• code reviews : learning happens and good ideas are exchanged. but very poor at finding logic errors
• pair programming : two programmers work at the same computer on the same problem at the same time with one monitor, keyboard, and computer. it is simple! but it is very intense experience that can be stressful and possible even demotivating for one or both people in the pair.

 

Practice 4: Lightweight Root-Cause Analysis

 Use regular lightweight root-cause analysis sessions to understand what caused a defect and how to prevent it in the future. Root-cause analysis is an attempt to understand the real cause of a problem and to prevent similar problems in the future. the goal is to learn and move on so that you can minimize the number of defects in your product and hence minimize the amount of time spent fixing defects overall.

 

  chapter 6. Emphasis on Designchap6.ppt

 Software is complex and it is continually changing and evolving.  In order to achieve sustainable software development, software must be designed to support and enhance changeability.  Well-designed software is useful and easy to use, maintain, extend, and understand. Good design practices are one of your most important tools to help control the cost of change.

 Top-down design method : ① Overdesigned Project; It produces stacke of documents but no code.

                                         ② Code-then-fix; There is little or no design, and change is just as hard.

 Extreme Programming outlines evolutionary or emergent design. This method relies on simple design(Only design what you need), refactoring(Disciplined code changes), and test-first development(To ensure that the behavior atrays as original intended)

 Design in sustainable software development means creating an enviroment where decisions are continually made within a framework that emphasizes change and designing for change, while ensuring consistency in the decisions.

 The elements of design in sustainable software development are:

• Working software
• The prosess of doing the design
• Collaboration and face-to-face communication

• Simple design

   

Practices

1. Design Vision

   If you don't have a vision, iteration development is really hard. A design vision or conceptual design is an overall picture of the pieces of your software.

   Without a design vision, oscillation will likely result because the team will not have a clear idea of how the software is and should be structured.

    

2. Guiding Principles

   Guiding principles are a short list of statements that specify overall design goals and requirements. It helps team members make daily design decisions that are consistent with the design intent. It refers as pillars because it never changes, or is not changed in major ways. Guiding principle can be thought of as the vision for the design,but vision describes what the project is about, the guiding principles describe how the project should be built.

   Two important and distinct guiding principles are recommended;

   • Engineering guiding principles: These describe how the project is implemented in technical terms that the project team's developers can understand.

   • User experience guiding principles: These describe attributes that the user cares about. They are described in a user-centric way that everyone on the team can understand.

      

3. Simple Design

   The goal would be only design what you need immediately. You need to keep the design as simple as possible. Add the interfaces later that you don't   immediately. If a problem is understood well enough to know that its solution can be found in a design pattern, then the pattern should be used because patterns work and are well understand. But patterns aren't perfect and again you need to always think about simplicity first. Sometimes you're going to get it wrong and over or underdesign in some interfaces. That's software development. Fix the problem as soon as you can, learn from the experience, and move on. Teamwork, knowledge, experience, and collaboration are vital to make the right decision. The more people make design decisions with others and use each other as sounding boards for ideas, and the more people learn from each other, and the greater the collective experience and knowledge in the team, the greater the chance that the correct decisions are going to be reached.

    

4. Refactoring

   The structure of the code is changed but the code's behavior remains unchanged.(It is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure) It is a disciplined way to clean up code that minimizes the chances of introducing bugs.  Step-by-step manner with tests in place to catch problems as you proceed. With refactoring, the quality of communication and the level of confidence are high.

    

5. Design Pattern

   Design patterns are an invaluable resource for software developers. Many developers have never heard of design patterns, and others feel that simple design means they should  not use patterns because using a design pattern seems like up-front design. The most common design patterns were observed by some clever and experienced software developers as solutions that worked time and again in different software projects and over time. Patterns are known to work, they are tested, and they have a known behavior. The design patterns are valuable and they shouldn't be ignored. Mistaken identification of a pattern has led to wasted time when trying to find a problem or understand the code. The code is needed a pattern means that other developers can quickly add the interfaces they need at a later time with full confidence that the expected behavior of the pattern will not be altered.

    

6.  Frequent Rapid Design Meetings

   The rapid design meeting is an important mechanism for a team to ensure it is having frequent design discussions. The output of formal design meeting is a document. The desired output of a rapid design meeting is shared understanding, learning, and collaboration. There are two types of design meetings that teams can use: the design discussion and the design review. A design discussion is when a number of team members get together to discuss design decisions of any kind. A design review is an opportunity for a team to analyze its current architecture and discuss short and long-term changes that need to be made. Design discussions should happen more frequently than design reviews. These discussions are rarely a waste of time, because they gave th entire team a chance to learn and collaborate. Design review  meetings might be held after every Nth iteration or they might be added to the agenda in a retrospective. The goal of the design review is to learn and provide a positive future direction for the design.

    

7.  Commitment to Rearchitecture

    Refactoring is a powerful discipline, but sometimes it is necessary to completely reachitect and replaces some portiion of a product. In many cases, this is the preferred approach since the cost of the replacement will over time be less than trying to bend the current architecture in the required direction.  Therefore, teams need to be committed to understanding when rearchitecture is required and be committed to making it happen. The most glaring need for rearchitecture work is just after the completion of the first version of a product. Because development teams, no matter how experienced, are bound to make some tradeoffs and mistakes that will cost them over the long term.

    

8.  Design for Reuse

   Reusable software has fewer defects and cleaner interfaces. Once a piece of software is used but not duplicated in more than one place, it is going to be tested twice, and likely in different ways. Reuse is vital to sustainability because it minimizes wasted effort and allows new initiatives to be launched quickly. One of the largest problems and most important reasons to have reusable software is to eliminate duplicated code. Reusable software also eases replaceability.

 

 Summary

Design is vital to sustainable development because in order for software to last over the long term, it must be well design. Good design practices should stress finding a balance between up-front and emergent design and emphasizing a collaborative design process that is not built around heavy requirements for decumentation of the design.

It is important to start with a vision and guiding principles for the design. These are the goalposts that team members must consider everyday as make they make tradeoffs. From there, the design visibility, and collaboration. Mistakes are inevitably made, where software is over- or underdisign. Software teams should rely on a focus on simplicity and a desire to avoid duplicated effort plus teamwork, knowledge, experience, and collaboration to reduce the number of mistakes and their severity.  It is vital that design mistakes are fixed as quickly as possible, the appropriate lessons are learned, and then the team moves on. It is also critical that the team has the guts and instincts to make difficult decisions, such as to rearchitect before the cost of change becomes too high.

 

Ch.7 Continual Refinement Ch7.ppt

 

In order to achieve sustainable development, teams need a way to balance short-term requirements and long-term needs: to ship their product as soon as they can while accepting, anticipating, and even welcoming change.

• Teams must adopt a mindset and related practices that help them easily adapt to change as it happens while also anticipating change. 

   

• The core agile software development practice of iterative development encourages continual refinement because it is a lightweight.

   

• In agile development, teams work from a simple and clear vision and deal with change through frequent iterations; the goal of each iteration is to deliver something useful to customers.

   

• The main advantage of agile methods is that they help teams manage uncertainty and change early and throughout the project.

   

•  The challenge with agile methods is to rely on both adaptability and anticipation and to have a team that knows when and how to apply each, and in what measure.

   

•  The need to involve both adaptation and anticipation in agile methods is similar to the need to consider both the short and long terms.

   

 

Practice 1: iterative development

Iterative development gives the team a lightweight way to make measurable progress and to get feedback from customers as frequently and as early as possible.

-         The schedule is broken up into a number of short equal-length iterations (2 to 6 weeks).

-         Re-plan and reprioritize at the beginning of every iteration(with feature card)

-         The feature cards and their arrangement into a number of iteration is the project schedule.

-         Feature cards contain all the documentation required to begin the work.

-         Iterative development provides a regular heartbeat or checkpoint to the development effort.

Collaboration and iterative development

-         Cross-functional collaboration is important to sustainable development because there is no hiding risk from any of the participants. Hence, active risk management is encouraged.

-         Collaboration helps to ensure that the right tradeoffs are made and the best possible priorities are set.

Velocity

-         The velocity is a record of the number of feature points completed in any given iteration

-         Velocity is tracked through the project and gives an immediate indication of how well the project is (or is not) progressing.

Iteration 0

-         Iteration 0 is a short iteration that the team can use a perform critical analysis work before starting actual development.\

-         Iteration 0 helps teams identify and document longer term consideration.

 

Practice 2: Release planning

A release is a version of a product that can be installed and used by customers in their production environments.

Release planning provides the longer term view that is necessary for planning purposes.

 

 

Practice 3: Daily standup meetings

Hold a standup meeting the same time every day that is attended by the entire team-including businesspeople. The meeting should take an absolute maximum of 15 minutes. It helps to get issues out in the open each day, which helps to ensure that people aren’t blocked for long periods of time and that everyone on the team is aware of what everyone else is doing.

•  keep track of time & limit discussion => meeting finishes quickly

•  Standup meetings are highly effective at gathering status, getting important issues out into the open and encouraging collaboration among the team.

   

 

Practice 4: Retrospectives

• Teams should hold retrospective meetings at regular intervals during their projects.

   

• The purpose of retrospective is to provide a forum where the teams can openly question their current development processes and progress, learn from their mistakes and failures, and decide what changes they need to make to proceed effectively.

•   Retrospectives should help uncover areas for improvement and give everyone ideas as to how to contribute more strongly to the project.

•    Retrospectives should never be personal or antagonistic.

   

 

Practice 5: Coaching and Team Development

Coaching and team development are important for continual refinement to help the team achieve the best possible results while collaborating together and with customer.

•  Coaching is an interpersonal skill that helps people provides each other with real-time feedback.

   

• Team development are equally important because the more the team understands the business and has current skills, the better it will be at both anticipating and initiating changes in its ecosystem.

   

   

Professional development

Professional development is important for both personal and project reasons.

•  From a project standpoint, teams that are knowledgeable in as many areas as possible, even those that are seemingly unrelated to the current project, have the best chance of succeeding at sustainable development.

   

 

Practice 6: Make key metrics visible

Visibility might be achieved by a simple web page or maybe even a big visible chart on a whiteboard or by the water cooler. The reason metrics are helpful is that they can, if they are presented in the right way, help the team focus on keeping important aspects of its project under control.

 

  chapter 8. Culture Change and Sustainable Develpmentchap8.ppt

 Implementing sustainable development in most organizations is going to require a change in the development culture. This chapter is an introduction to some techniques that can be used while outlining change factors and enabler that must be thought of.

 

Making Change Happen

• Software people come from many backgrounds
• In many organizations people who understand amazingly little about software development, somtimes appallingly so, wind up managing the organization. Management is only a problem when it is bad or incompetent
• Many organization do not pay attention to key people issues such as professional development and leadership. Instead, they focus on projects, schedules, and results.
• Software education lacks standards and a poor understanding of what the basic are
• People don't like being told how to work
• People are different. Software deveoplers tend to be introverts
• Organizations are complex simply because of the mix of different people

People, and the culture they have built for themselves, are probably the largest variable between organizations. People ans culture are also the largest potential barriers to change

 

change factors and Enablers

change factors: leadership, a sense of urgency, executive support

change enablers: persistence, training, continual 'wins', positive reinforcement of desired behaviors, communication

 

Leadership: top-down, bottom-up -> no single person can make change happen. In order for any change to suceed, there must be leadership at all levels.  Change starts with individual leaders.

Sense of urgency: Change won't happen unless people understand and agree with the need for change. Early and empatically states the need for change

Executive support: The more executive support there is, the easier the change effort will be

 

Persistence: You have to knowing that these are going to occur and you will need continual effort over a long period of time

Training: It can be done by bring consultants in(external training) or using your own people(internal training)

Continula 'wins': These can be in the form of new tests, new tools, changes in defect trends, sucessful project, or whatever is meaningful to your company. You cannot expect change to happen quickly, so you must use the continual wins to reinforce sucess

Positive reinforcement of desired behaviors: Change requires new behaviors that must replace existing bahaviors

Communication: The purpose of communication during change is to keep people excited and in tune with the importance of the changes

 

Start with what you can control and influence

You can't try to solve everything at once, and you need to think about the problem in understandable increments that keep you on the desired path. Change initiative will fail if they attempt to boil the ocean or lack focus or a clear sense of first steps and overall vision

 

Avoid traisition plans

Transition plans are something that can be put in place later or are somehow optional. Later may never come. There must be a strong desire for change, and change often means taking a risk or being aggressive. Transition plans are rarely risky or aggressive

 

Truning unstainable into sustainable development

If you are working in a project that is on the unsustainable development curve, the most important thing you must recognize is that you can't just 'blow up' your current processes and practices. You need to recognize that achieving sustainable development is going to take time, and probably more time than you think.

Assuming that you have buy-in to change and have decided on your approach, where do you begin? Start by analyzing the mindset of your organization and mapping it againist the four principle: continual refinement, working product, defect prevention, and design empasis

 

Some other ideas

Every project and situation is going to be different, so it is impossible to provide a step by step solution to your problem.

 

Identify key architecture bettles: Do architecture analysis, where you identify things such as poor structure and areas with a large number of defects.

Get your defects under controls: Work hard toward a culture built around defect prevention and working software

Collaboration with users: One of most difficult steps in introducing agile development is getting timely feedback from users

Training: Training is a crucial part of moving from an unstatinable to sustainable developement culture

Group refactoring exercises: Pick a peice of code that has many broken windows in it. Then, get a bunch of people together in a conference room and do a pair programming exercuse to refactor the code

The work enviroment: Change the physical space that the team operates in to facilitate collaboration and reduce unnecessary interuptions

 

Sustainability and agility are more important than consistency. If you have multiple teams working together or on multiple projects, it's more important that they have the same mindset than that they employ the exact same set of practices in exactly the same way

 

 Change examples

 There are two successful changes. The first was the introduciton of a controversial practice into a small development team, and the other was the introduction of agile development into a relatively large mature software organization(approximately 200 people)