soonsam님의 노트

Agile article

Sun, 23 Jan 2011 14:12:50 +0900

Kanben vs Scrum

1) Similarities

- both use pull scheduling

- both focus on delivering releasable software early and often

- both are based on self – organization teams

- both require breaking the work into small pieces

2) Differences

- both limit WIP

- both use transparency to drive process improvement

Scrum	Kanban
Timeboxed iterations prescribed	Timeboxed iterations optional (They can choose when to do planning, process improvement, and release)
Team commits to a specific amount of work for this iteration	Commitment optional
Uses Velocity (how many items or story points) as default metric for planning and process improvement	Uses Lead time as default metric for planning and process improvement
Cross-functional teams	Cross-functional teams are optional. Specialist teams allowed
Burndown chart prescribed (Major role: track the progress of an iteration so that find out as early as possible if work is behind or ahead of schedule)	No typical diagram (Burndown or Cumulative can be chosen)
WIP limited indirectly per sprint (WIP per iteration)	WIP limited directly per workflow state
Can not add items to ongoing iteration (based on prioritization scheme)	Can add new items whenever capacity is available (prioritization scheme and product backlog are optional)
A sprint backlog is owned by one specific team	Kanban board may be shared by multiple teams or individuals
priscribes 3 roles (PO/Team/SM)	Doesn't prescribe any roles
reset	persistent
Scrum meeting is prescribed (same time, same place everyday)	meeting is optional

kanban, flow, cadence

1) Kanban

- Just in time and automation system

- Queue work: a number of stages of development until its done.

- Kanban has two limits: Queue limits and WIP limits

- Queue limits are designed to just-in-time achieved.

- Work In Progress limits are to reduce multi-tasking, maximizing throughput, and enhance teamwork.

- Little’s Law for Queuing Theory:

Total cycle time: Number of Things in Progress /Average Completion rate

- WIP limit sizes can depend on type of work and size of team and adjusted to achieve maximum flow.

2) Flow

- It describes how the work in the system can delivery maximum value.

- One piece flow: moving one piece at a time

- It focuses on optimizing the value stream of larger minimal marketable feature.

3) Cadence

-Time-boxed iteration which couples planning, review and releas together

-Kanban system decouples these events.(separate cadences)

-Throughput(the amount of complete a process) = WIP/ Cycle Tim

Key metrics for measuring sprint status

- Introduction

Traditional progree has been measured considering accuration (like how much work has been done, in how much time) . but it works well for intensive production systems like manafacturing (tangible, repetitive task). but building commercial software can't ne ruled by the same principles. It's not well defined requirements and changing developing conditions.So many specialists have tried to provide a methodology that reduces complexity to a level.

The results were Agile popped up as an alternative but to adapt to changes and react in kind.

This article will explore some indicators like burn down charts, user storied life cycle, estimated vs. actual hours and team velocity.

-Burn down chart (impricising)

1) Burned hours that are not related to productive tasks.

2) Hours are different for team works.

3) User story acceptance criteria need to be defined.

4) Burned hours need to be baselined to initial estimation.

-Suggentions for improvements

1) Create the tracking tool related to productive work(coding, testing, automation).

2) Classify the differet works(developers, engineers ...)

3) When we have poor initial estimation or reestimations, do mitigate for this mediating burn down chart.

-User stories life cycle

1) Visualize indicator for the progress of a user story

2) Draft, Planned, Implemented, Verified, Accepted: This indicator complements the burn down chart perfectly.

-Estimated hours vs. actual hours

You don't need to accurate estimations, at least not for Scrum sprints. Because Scrum has these characters: short, light, adaptive, variable, differ from works(quality engineer's>developer's accuracy,repetitive tasks)

-Team velocity-(It is based on the number of hours not in the degree of success)

1)When engineers have enough user stories to test, the velocity tend to increase while productivity decreases or stay the same.

2)It is also different from work types.

3)This can be a misleading indicator(unit testing or bug fixing)

4)Indivisual velocity is very good indicator for detecting some matters.

step #8: track progress with a daily burndown chart

Traditional software development has common problem like "testing". In agile, testing is integrated lifecycle, features are completed one by one.
Scrum agile development offers a practice to track progress daily- the daily burndown chart(simple, powerful)
Update the estimated time to complete each task on dailly basis,(sprint backlog)
Team members take responsibility
Team's goal is for the team to reach zero hours to go, by the end of the Sprint duration.
Plot progress visually on a graph
Annotate the graph describing key events.
Scrum highlights your problems.
But one big advantage! You get to the true picture about the project(wherever, whenever)

5. Posts Tagged 'backlog T indicator'

The workers commit to deliver value at the end of a sprint or release. But for various reasons, some requests may be dropped out or added and some effort may differ from initial estimations. 'blacklog T indicator' shows these kind of values in one single and simple visual indicator.

Cumulative Flow Diagrams

A cumulative flow diagram shows the arrival and departure of items into a particular state or queue. So we can visibly demonstrate the condition of a particular project or release at a given moment in time. Especially we can futher data mine based on ticket type and priority and do this over various ranges depending on our needs and goals. Thus, this CFD enables us to visualize the workflow and better manage.

Priority 1 and priority 2 defects for the Yahoo!

Global Finance Site, SIABv1

1) It shows the current state of project at a given moment when used in real time.

2) Performing honest and critical retrospetives to guide the team on overall process improvement.

3) Better data management

Global Sports World Cup project

This graph is more smoother than SIABv1. Beacuse It has more frequent releases(WIP remains more steady for Workd Cup project).

How we can use CFD in an effective way?

we can add more states like 'Accepted' and 'Resolved-Fixed.'
we can begin tracking and observing results by different levels of service by priority and ticket type.
Teams can review the cumulative flow diagrams for their respective products during sprint and project retrospectives and make continual process improvements.

Creating and Interpreting CFD

CFD is a valuable tool for tracking and forecasting Agile projects. It is used to gain insights into project issues (bottleneck..), cycle time, and likely completion dates.

Interpretation of CFD

Red area: all the works planned

Yellow area: work in progress

Green area: works done

There is a law called 'Little's Law' introduced with the purpose of analyzing Queue in CFD. The yellow area representing all the works which started but not yet finished can be seen as Queue here. We can determine how many works are in the queue by looing at the vertical (Y) distance and we can also know how long they will likely take to complete by examining the horizontal (X) distance.
Poppendieck argues those WIP and lead time should be removed or minimized as much as possible as as they represent sunk investment costs with no business benefits"

Managing the work in an Agile project

-Introduction-

This article introduces the ideas of a functional Work Breakdown Structure(WBS), Business Value(BV), Earned Business Value(EBV), and Earned Business Value Index(EBVI).Like artifact-driven and waterfalish, that agility is perceived as too developer-centric, too light-weight, or that feedback to business is hard to understand. The essence of agility is validation and feedback, and incremental develping software with attention to changing priorities, requirements.So this article focuses on the major problem: Communication of progress to management.

-Two views of work-

1)developer's point of view

It is looking at the project from the inside, and is interested in the work as it is being done.

2)business point of view

It is looking from the outside. It supplies the overall requirements and prioritizations.

-Stories and Tasks-

1)Story is used as the interface between the business and developer sides of the project.

(A description, usually in business terms; A size, for rough estimation purposes; A short description)

2)Task is smaller than a story, and is the unit of work tha tis actually worked on by a developer.

(A description of work to be performed, technical or business terms; estimation of how much time the work will take;

Exit criteria and verification method)

-Work backlog: In both XP and Scrum-

1)An evolving, prioritized queue of business and technical functionality that needs to be developed into a system.

(Front burner_right now, Back burner_soon, Fridge_someday)

2) It is developer focused, interseted in the order of development through iteration, velocity which measures how many stories or tasks per iteration.

-Work breakdown structure-

1)A deliverable-oriented grouping of project elements which manages the total sope of the project.

(main area: product, team, business)

2)Because of never completed cases,there to be many different strategies for developing and assigning stories to them.

-Business Value:prioritize them

1) ROI, PNL, numerical value, BVI, BV(bucket)=BV(project)*BVI(bucket)

-The planning game-

1) BV(story)/size(story)

2) BV(story)/(sub tasks sigma)etimate(task)

-Earned business value-

1)EBV=we add up the business values for all those stories that have been completed-that have earned their bisiness value.

2) Subjective part: the weights allowing us to determine the BVI ,

Objective part: whether of not a story is "done".

3)EBVI: the percentage of its own value the bucket has earned, and the weight of a story is either 0 or 1.

-When we have some matters like stop working,we have to show how "doneness"can be "undone" through EBV caculation.

-Color of money problem-

Color of money requires us to track actual expentidure of time against the tasks. However. it requires datailed bookkeeping at the task level.Also it allows us to manage our money down where the work is, allows us to fine-tune our planning.

Value-Based management and Agile methods

-Introduction-

VBM(Value Based Management) is an integrated stratefic and financial approach to the general management of business. There are 5 priciples for Value Based IT Management.

1) Economic value maximization.

2) Strategy drives selection of IT investment.

3) IT Investments are actively structured to maximize embedded stratefic options.

4) Traditional disvounted cash flow (DCF) and options-based techniques.

5) Metrics are used to measure and guide performance.

-The tomato garden metaphor-

Active management of an XP project invloves continuous cultivation through tech. such as refactoring automated tests, and daily builds to maximize the setrategic options available at any time.

-The role of strategy

1) Market economics: Agile support the creation of strategic options both for entry into profitable market situations, and

exit from unprofitable ones.

2) Competitive position: Diffrentiation provides us with a good illustration of the difference between an operational methodolofy and a stratefic/financial methodology.

-Valuation-

PV = C1/(1+K) + C2/(1+K)^2 + .........

-Economic value maximization

Every company has a governing objective, although it is often onlly implicitly expressed in the way it conducts its business.There is a strong-tendency for a company to set a strategic, or product-market oriented governing objective:

1) achieving the highest possible quality

2) maximizing growth of the business

3) maximizing customer satisfation

-Value based metrics-

1) Ratio between estimated develpment

2) Unit test scores

3) Functional test scores

These metrics are important in agile methods for measuring and providing feedback on operational performance.

-Measuring profitability-

ROI=E/I

-Economic profit-

ROI doesn't consider the cost of the capital like labor, equipment,...The metric used in VBM, known as economic profit.

EP= C- I*K

eXtreme Adoption eXpriences of a B2B start up

This paper tries to show the motivations and goals for adopting XP, and the context under which the adoption efforts were evaluated.

Benefits for adopting XP

1) Increased rate of development

2) Reduced development costs

3) Increased correlation of software to business needs

4) Reduced release cycle

5) Increased product quality

6) Increased quality of implementation

An initial investigation of test driven develpment in industry

Test Driven Development (TDD) is a software development practice in which unit test cases are incrementally written prior to code implementation.They investigated how different from TDD vs waterfall-like approach. They found that the TDD developers produced higher quality code, which passed 18% more functional test cases. However, TDD developer pairs took 16% more time for develoment. It is conjectured that the resulting high quality of code written using the TDD practice may be due to the granularity of TDD which may be more frequent and tighter verification and validation.

Process Improvement? Is it a lottery?

This article provides an overview of the approach utilized to implement process improvement across its globali organization without losing focus of its business drivers. It provieds a practical overview of how over a 4 year period an organization moved form CMM. It will describe the steps taken to avoid failures by institutionalizing project management good practices across its global software development organization.

Standardizing project process irrespective of where development work takes place also provides for; more effective resource utlization, faster project start-up and less re-training, improved temwork and employee morale, and increased customer confidence as project successes become repeatable.

Mature Scrum at Systematic

This article describes the adotion of Lean led to a unique way of working based on synergies between CMMI, Lean, Scrum. The ecxperiences from combining Lean, CMMI and Scrum have led Systematic to identify examples of explicit guidance from CMMI that help to execute Scrum activities even better.

CMMI ensures that agile methods are institutionalized, including consistent implementation throughout the organization, role based training and continous improvment.

Scrum also needs some initial planning or setup activities
Project initiation is fast, and risk are not hidden by speculative planning
Project plannning in CMMI is a disciplined and comprehensive Sprint zero
Planning and risk management activities reduces risk of product baklog
Two levels of planing and tracking
Risk management can proactively prevent impediments
Use cheklist to ensure quality of strories
Automated test is a must in order to do one month sprints
Continuous integration must be supported with discipline for check in
Automated test and integration must be supported by a standard production line
CMMI facilitates data driven identification and elimication of impediments
Focus on "fix-time after failed build" drives good discipline in project
Explicit quality plans helps the team to build the right quality

Systematic has worked with Lean, CMMI, and Scrum for several years, and found that they can be mixed in a way where strong synergies are achived. We believe that these experiences can be adopted by many agile projects and are independent to whether your project or organization is working according to CMMI or Lean.

Agile software development methodologies: An overview of the current state of research

The current papper identifies and structures the main theoretical contributions to the field of Agile Methodologies research, by analyzing the main papers on socail implications of using Agile, by analyzing the main papers on social implications of using Agile.

1.Introduction and motivation

(Charette, 2005)(Voas & Whittaker, 2002) (Jones, 1995) -> Minimizing risk and approaching projects in a structured manner become critical success factors. Many authors describe the benefits of organizations which successfully adopted agile practice.

2.Overview of Agile methodologies

The differences between traditional methodologies and Agile methodologies relies on 2 main assumptions; 1) Customers need guidance from the developers, but Agile assume that both customers and developers don't have full understanding of requrements when the project starts. 2) Traditional mehodologies assume that customers ability to foresee their future requirements is limited, but Agile Methodologies emphasize simplicity.

3.Research on social implications of using Agile Methodology

While the waterfall methodologies rely on a large number of documents and artefacts. SCRUM and the rest of Agile Methodologies use a minimum of documentation. The implication of their article, especially when implementing Agile Methodologies, are that using software tools to manage Agile teams can be done, but only after a social contect and meaning has been created.

4.Research on implementation of Agile Methodologies

They propose a conceptual framework regarding the acceptance of Agile Methodologies. They propose that a series of factors such as (a) ability related factors (b) motivation factors (c) opportunity related factors

5.Emprilical studies reagarding Agile methodologies

The paper of (Salo&Abrahamsson, 2008) brings a series of interesting findings from empirical study of Scrum and XP in European embedded software development organizations.

Hoewever, there are few papers which empirically study Agile Methods, such as Scrum or XP.

Agile software development: Adaptive systems principles and best practices

This article examines how complex adaptive systems(CAS) theory can be used to increase our understanding of how agile software development practices can be used to develope this capability.

As in the past with heavy weight methodologies, organizations often develop their own customized versions of these named agile development approaches to suit their development needs and organizational environment.

The metrics so developed ought to capture each of the three dimensions of software development; people, process, and product. These metrics should be identified and developed in such a way that they incorporate the interactions across all of these dimensions.

This article contributes to the literature on complexity science and IT devlopment by providing a clear understanding and appreciation of the sources, nature, and types of interdependencies between individuals, organizations, and IS solutions within the contect of fast-paced agile software development.

A key limitation of this article is that it stops short of deriving and validating metrics for agile software development for the theory-based best practices suggested.

Kanban implementation at a tyre manufacturing plant: a case study

-Introduction-

This paper describes implementation of the Kanban system in a continuous product line of a tyre manufacturing plant. The paper also describes a practical approach to the design of Kanban card, board, container sizing, the number of Kanban, operating rules and day- to- day scheduling of machines using Kanban, and the neccessary changes in a wage system to support its acceptability by workers on the shop floor.

-Methodology-

(a) Housekeeping - 5S

(b) Multi - skilling

(d) Layout improvement and trolley identification

(e) Statistical process control and visual control

-Conclusions-

The study provides structured guidelines in implementation of the Kanban system, by developing applicable rules from the abstract ones, in day to day processing and scheduling of components on machines using Kanban. Implementation of the Kanban system in the model area alone has resulted in cost reduction of INR in output from reduction in changes and setup times, increase in machine uptime and reduced defects.

Lean Software Development: Two Case Studies

This papaer describes how the concepts of lean manufacturing can be successfully transferred from the manufacture of software development. The two case studies reported here confirm that lean software development can produce rapid quality and productivity gains.

Lean tech. work by rapidly identifying why and how person is making mistakes. They then provide the data to assist the necessary changes to the organizational infrastructure. The rapid organization learning and alignment of people, process and goals enables people to produce the quality of work.Lean production has always presented itself as a complete management system dedicated to the elimination of waste.

This paper experimented cases between Team A and B. Team A(Series 1) consists of younger and less experienced people while Team B(Series 2) consists of mid-thirties anaylysts worked in a variety of companies.

Lean software development indicates that software quality problems are often the result of deeply embeded organizational habits of recruitment, retention and motivationl. Lean technique has demonstrated that it can go right to the ploblems of motivation, quality assurance and staff evaluation. By moving responsibility for measuring quality from the manager to the workers, a much quicker and more thorough response to defects was obtained.

Principles of Lean Thinking Written by Mary Poppendieck

<Purpose & Goal>

This paper aims to provide a clear framework about how lean principles, especially what features of lean thinking works for software development. While many other papers have argued that lean idea could be a good foundation to develop software, they are not enough to explain how it works and make people who wish to incorporate lean into software development understand how it can be accomplished. This paper, on the other hand, suggests major ideas of lean thinking and how they are all applied to software development.

What is lean thinking about?

: It is an evolved idea from craft and mass production involved tremendous works which were not necessary. Lean has seen doing such unnecessary works is the thing reduces ‘value’. As a result, what the lean is pursuing is to remove all non-value added works (steps, procedures and extra).

<Research Model & Conclusion>

In the main part of paper, basic lean principles are introduced so as to show how they are applied for developing software.

Basic lean principles for development (Application of lean to software development)

First. Add nothing but value (Eliminate waste)

(Add value = Eliminate waste = Eliminate or reduce defects happened during coding)

- Wastes in software development: extra features, requirements, extra steps, finding information, defects not caught by tests, waiting including customers, handoffs.

- Suggested tool: XP (Extreme Programming) which focuses on rapid software development via frequent refactoring works. (Test-oriented way to minimize defects as much as possible)

‘Don’t code unless you understand what the code is supposed to do and have a way to determine whether the code works’

Second. Center on the people who add value

- Gives power to front line workers. That means, whom should be empowered are software developers who actually write code.

- With authority, developers will have strong responsibility and be motivated for contribution on what they are doing. It means any problems happened in code could be immediately handled by them, so the value of software will be improved.

Third. Flow value from demand

- A goal of lean is to maximize information flow and delivered value

- Suggested solution for information flow maximization: replace documents with automated test of code

- Suggested solution for maximizing value delivered: split a problem into small batches pulled by a customer story and customer test

Fourth. Optimize across organizations

- Avoid gaps such as sub-optimizing measurement, earned value measurement across an organization

- Suggested solution: make a team oriented structure in an organization

<Shortcomings of the research>

Even though this paper endeavors to give readers deep understanding of how lean principles can be realized in software development, the explanation seems to reach at just conceptual level. It will be better if this deals with empirical evidences and clear guidance for companies which are in different business environment with different conditions.

Lean Software Process

<Purpose & Goal>

Gaining competitive advantages from purchasing equipment is ineffective since it can be easily copied. So, what can bring sustainable competitive advantages over rivals is having competent, well performing staff which is hardly duplicated. It can be realized through the use of lean that motivates staff via frequent feedback. In addition, lean technique assures quality of product (software) and evaluates staff in a better way traditional one does. This paper has purpose to prove these role of lean on software development based on an empirical work comparing how an organization work with lean or without lean.

<Research model & conclusion>

To test the applicability of lean techniques for software development, this paper introduces an experiment designed and carried out.

I. Subject of experiment

: An organization employing 7000 people. The IS department of the firm makes two teams consist of an analyst, programmer/analyst and a programmer and they are called A, B respectively.

II. What teams are doing?

: To write enhancements and corrections for the same financial & management IS currently in use.

III. The problems in the IS

: The code written is not consistent because it has been programmed by many people. Hence, the styles and standards used in different parts of the code vary considerably.

- Frustrating people working on code

- Late project completion

- Possibility generated weekly finance & management report to be wrong

- No measurement for work performance or productivity on programming

To cope with those problems, a set of standardized procedures was introduced, but not effective as defects are still found.

IV. Suggested solution – Lean introduction

- Manager no longer has a direct role in quality assurance

- Analysts pass work file to the programmer right after a page of analysis work is completed

- Programmers return immediately to the analyst when errors and any works which do not conform to standards are found. (use ‘tally marks’ to record errors on a sheet at the front of the project file) They do nothing while errors are being corrected. This enables to avoid accumulation of error-ridden work in process.

V. Results of Introducing lean working (Comparison of team A & B)

Team A

Team B

Description

: All team members are less educated, experienced and younger. Also they are all positioned at each domain area (clerical and junior administrative positions)

Team Climate

: well follow constructed standards and continually enhance by their suggestions

Description

: Analyst and programmer/analyst are well educated. But, analyst is chronically error-prone and never documents anything.

(Stopped experiment)

Result

: fairly successful

Result

: unsuccessful

Factors driving the result:

- workers are motivated for contribution (project success)

- Regularly well conducted work reviews along comments

- See works as jobs to be done methodically

(not as a series of clever tricks)

Factors resulted in failure:

- Analyst’s overconfidence, dislike of showing or sharing own work

- Analyst’s lack of responsibility

- Lack of communication in team

As can be seen from the result of experiment of team A and B, well conducted lean technique goes right to the core of the problems of motivation, quality assurance and staff evaluation.

<Shortcomings>

Only a case is presented as a supportive experiment. Also, teams used in the case look quite extreme.

Process Improvement via Scrum from the Perspective of Lean: Yahoo case

Purpose & Value of the paper

Shows Agile is an effective tool realizing Lean principle, particularly 'Remove Waste' in developing software based on the case of Yahoo
Is a new approach attempted to combine two powerful ideas - Agile and Lean
Introduces an interesting tool named 'Cumulative diagram' to better show the effect of Scrum introduction to implement Lean.
Provides a good guideline for future studies as considering the fact that no enough stuides about Lean application to Agile exist in Korea.

Research Model

Subject company: Yahoo! Korea
Way of Research conducted: Analyze the result of Cumulative diagrams with Scrum and without Scrum. The results are demonstrated in terms of changes of WIP and Lead Time.

(The reason why used CFD instead of Bundown Chart: While Burndown chart has a limitation as it is only able to show the current status, CFD shows holistic process status, so it is much easier to find any point causing problems (=wastes). As a result, CFD is an excellent on visualization of workflow)
Result of the research
1. the case applied SCRUM: WIP and Lead time are continously decreased as the project process is being forward
2. the case not applied SCRUM: WIP and Lead time are continuously increased as the process is being forward
  
  (What the above result is going to tell is that Scrum plays an critical role of minimize fluctuation of the project and customer requirements while maximize the value of delivered product at the end of the project)

Shortcoming of the paper

Yahoo! case is not enough to convince readers the effectiveness of SCRUM adoption to get the advantages Lean principle has. It will be better if some more evidences based on empirical works are mentioned together. In addition, it fails on showing all diverse process states of CFD.

Lean Software Development: Is it feasible?

Purpose

Explain what the Lean thinking evolved from Toyota's production system (TPS) is, but mostly focused on exploring the feasibility of applying Lean principles to software development.

Main ideas captured from the context

Lean?

It is all abbout getting the right things to the right place at the right time while minimizing wastes and being open to change.
Basic concepts of Lean Thinking & its application to developing Lean software
1. Value
  
  : Value is what the customers perceive as value or useful to them
  
  : A question about how to extract the value as perceived by the customer is remained to be answered.
  
  Rapid prototyping is one of the process that may help here. By rapidly prototyping and reviewing with the customer, one can develop the customer's requirements and their value
2. Value Stream
  
  : A set of actions required to bring a value product or service to the customer.
  
  : By examining value stream, unnecessary wastes can be eliminated
3. Flow
  
  : flow is to make every activity in the product development take place continuously with no stappage, no back flows and no scrap
4. Pull
  
  : a basis of JIT
  
  : It means that no one should produce goods or services untile customers ask for it. Thus only what is required by the customer should be built in the software
5. Perfection
  
  : is the principle based on the concept that continuous improvements are needed to be better, cheaper, and faster, as a result to be closer to perfection. (opposite to Reengineering concept)
Software Development - today

: Pro. Niklaus Wirth asserted 'almost all software have grown "fat"' as software vendors adopt almost any fearues user may want.
Lean software development

: Suggested idea to make Lean software development to be feasible is that software should be developed in a reusable way based on the concept of object oriented reusability technologies.

: How reusable? Component based software development from object oriented concept

ex) Microsoft com. developed class libraries for object oriented language (reusability went up!)

This "Re-Use" concept helps in achieving in improved quality and redueced flow time and cost since already developed, tested, and proven components are used.

Summarize the main idea

This paper has mentioned several concepts such as reusability, rapid prototyping, object-oriented technologies, component-based software development, and extra to show the feasibility of Lean thinking in software development with their use. Based on this, the paper drives the answer 'Yes' for the question 'Is it feasible to develop Lean software?'.

Lean Primer

It covers the concept of Little's Law, basic lean lessons based on author's years of experiences.

* Little's Law provides foundation to understand the goal of Lean principles - Reduce lead time and WIP.

Simple formulation is here,

Lead time = WIP/average completion rate

* Basic Lean Lessons

Most processes are un-lean: Most of work is non-value-added. This is easily illustrated by using colors to visually separate value added from non-value added work on a process map
A primary goal should be reducing WIP: refers Little's Law
Every process should operate on pull, not push to eliminate variability in lead time.
Only 20% of the activities cause 80% of the delay - Pareto effect in action.
Invisible work can not be improved.

Agile training

Tue, 02 Mar 2010 16:58:09 +0900

intro of agile: intro_of_agile.pdf
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:

over or under design
code first then fix defects later(code-then-fix)
too many dependencies between code modules
the lack of safeguards such as automated tests
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.

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
Managers must recognize that they have a key role in leading the attitude of the organization.
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
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.

our software worked every day.
we relied heavily on automated testing to catch problems while we were working on new features.
we had high standards onf testing and code quality, and we held each other to those standards.
we didn't overdesign our work and built only what our customeres needed.
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.
we replanned our work as often as we could.
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

User Requirements: continually evolve and change
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.
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.
Disruptive Technologies: Internet is an example of a disruptive technology.
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()
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

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
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
Expertise: Expertise with software development and with the project's ecosystem is a strong indicator of success
Decision Making: Your ability to make decisions in a complex and constantly evolving ecosystem, often with incomplete information, is crucial to success
Leadership: Leadership helps to keep projects on track
Culture: The culture of an organization shapes the attitudes and priorities of the people who work in it
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

A user need and vision so it is clear what is being built
rapid refinement to adapt to change
a close relationship with users so they can provide timely feedback
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 :

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

<Applying the principles of sustainable development>

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.
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.
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.
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

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.
responsible
leadership
visionary and tactical
shared sense of urgency
highly collaborative
complementary talents and skills
continually improving and learning
change tolerant
risk-aware
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.

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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.

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
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.
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.
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.
Event Logging
Source Code Documentation

: extract documentation from your source code and generate a set of web pages
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.
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

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.
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.
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.
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.
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.
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.
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.
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)

Books & Notes

Mon, 01 Feb 2010 15:36:38 +0900

#1. 피플웨어(Peopleware) by Tom Demarco, Timothy Lister

1부. 인적 자원 관리

1. 기술 문제가 아니라 사람 문제다.

업무에서 발생하는 문제들은 대부분 기본적으로 기술의 문제가 아니라 조직사회학의 문제이다. 업무의 성공 여부는 그 과정에서 얼마나 좋은 인간 관계를 유지할 수 있으냐 아니냐에 달려있다.

2. 햄버거 마인드

만들어서 팔기만 하면 된다는 식의 '햄버거 마인드'는 부하 직원들의 사기를 떨어뜨리고, 정말 중요한 문제에 쏟아야 할 관심을 분산시켜 작업에 직접적인 악영향을 미칠 것이다. 개발 분야에서 일하는 직원들을 효과적으로 관리하려면 정반대의 관리 기법을 택해야 한다. 다음은 이를 위한 접근법들이다.

실수를 업무의 일부로 여긴다 : 실수를 허용하지 않는 분위기는 평균적인 기술 수준은 약간 향상될지도 모르지만, 팀은 위기에 처할 것이다. 직원들이 실수를 털어놓으면, 그것은 칭찬할 만한 일이다. 실수는 바로 업무의 일부이기 때문이다.
스스로의 동기에 의해서 일하도록 만들어라 : 사람들의 옆구리를 찔러서 단기 생산성을 올릴 수 있을지는 모르지만 장기적인 관점에서는 효과적이지 않다. 대다수의 사람들은 자신의 일을 사랑한다. 따라서 직원들에게 일을 시키기 위해 폭군 같은 방식을 택해야 할 필요는 없다.
직원들의 자기 주장에 위압감을 느낄 필요는 없다 : 각 직원의 고유한 특성은 생산 관리식 스타일을 맹목적으로 따라온 관리자들에게는 끊임없는 골칫거리이다. 그러나 사람을 관리하는 기법에 대해 잘 아는 유능한 관리자는 그러한 개성들이 뒷받침되어야 프로젝트가 더 생기 있고 효율적일 수 있다는 것을 잘 알고 있다.
현상 유지만 하는 일은 이미 실패한 일이다 : 프로젝트 관리는 개발 과정이 얼마나 역동적으로 이루어지는가에 초점을 맞추어야 한다. 또한 팀원 전체가 개발 과정에서 어떠한 역동적인 역할들을 담당하고 있는가에 대해서 관심을 가져야 한다. 촉매 작용을 하는 사람들은 프로젝트를 원활하게 진행하도록 돕기 때문에 아주 중요하다. 프로젝트의 팀원들이 서로 뭉치게 하는 사람은 그저 맡은 일만 하는 두 명의 몫을 해내는 셈이다.
일에 대해 고민할 시간이 필요하다 : 맡은 업무가 중요하면 중요할수록 더욱 더 신중하게 업무에 접근해야 한다. 일배우기에 들이는 시간을 줄이고 일 자체에 대해 생각하는 시간을 늘리려면 거의 초인적인 노력이 필요하다. 그러나 그런 많은 노력을 기울여서 프로젝트 팀원들이 서로 잘 교류하고 일 자체를 즐기는 법을 배우는 것은 무엇보다 중요하다.

3. 진정한 생산성의 의미

생산성은 이익을 비용으로 나눈 것으로 정의되어야 한다. 이익은 수행한 업무로부터 벌어들인 수입과 절감한 비용을 합한 것이고, 비용은 그 과정에서 소진된 몇몇 직원들의 교체 비용이 포함된 총 비용으로 보아야 한다. 생산성을 높이려면 항상 이직률도 고려해야 한다. 어떤 성과를 얻든지 간에, 그 성과는 중요한 사람들을 잃은 대가로 얻어지는 결과이기 때문이다. 시간을 쫓기며 일하는 사람들은 일을 더 잘 하는 것이 아니라 단지 더 빠르게 일할 뿐이다.

4. 여유 시간이 있어야 품질을 따진다.

품질은 무한정이지만 그것은 품질 향상에 많은 비용을 투자할 용의가 있는 사람들에게만 유효하다. 품질 향상을 위해 한 푼도 투자할 의향이 없는 회사는 그만큼의 품질밖에 얻을 수 없다. 여유 시간이 있으면 품질을 따지는 정책을 따르는 회사의 제품에는 좋은 품질이 끼어들 여지가 조금도 없는 것이다. 휴렛팩커드 경우, 높은 설계자 중심 품질 기준 설정으로 생산성을 향상시켜 이익을 거둔 기업이다. 개발자들은 자신들이 시장에서 요구하는 것 이상으로 좋은 품질의 제품을 만들어 내는 기업 문화의 한 부분임을 인식하였고, 이러한 품질 인식은 직업 만족도를 높이고, 업계에서 유례 없는 낮은 이직률이라는 결과를 낳았다.

5. 다시 본 파킨슨 법칙

파킨슨 법칙이란 업무는 그 시간에 할당된 시간만큼 늘어지는 경향이 있다는 것이다. 그러나 파킨슨 법칙은 당신의 직원들에게는 거의 적용되지 않는다. 직원들은 빈둥거리며 일하기에는 인생이 너무 짧다는 것을 알고 있으며, 자신의 일을 즐기기 때문에 일을 무한정 질질 끌려고 하지 않는다. 또한 그런 태도는 그들이 찾는 일의 만족감을 떨어뜨릴 뿐이기 때문이다. 뉴사우스웨일즈 대학에서 나온 조사 결과, 상사가 일정에 압박을 전혀 주지 않은 경우, 프로젝트들은 최고의 생산성을 기록했다. 즉, 파킨슨 법칙을 약간 변형시켜보면 많은 회사에서 볼수 있는 놀라운 진실이 생겨나는데 회사 일정에 쫓겨 일을 해야 할때 직원들은 근무 시간만 채우도록 일을 늘이는 경향이 있다는 것이다.

6. 만병통치약은 없다.

사람들에게 의존하는 것도 최신 기술 장치를 도입하는 것도 생상성 향상에는 별로 도움이 되지 않는다. 생산성 향상을 위해 관리자가 진정 해야하는 일은 사람들에게 일을 시키는 것이 아니라 그들이 일에 전념할 수 있는 환경을 만들어 주는 것이다.

2부. 사무실 환경

7. 비생산적인 작업 환경

생산성에 문제가 있는 대부분의 회사들은 무엇보다도 사무 환경 개선을 통해 생산성을 급속히 향상시킬 수 있다. 직원들이 시끄럽고 삭막하며 불안을 일으키는 사무 환경에서 일하고 있다면 사무 환경을 개선하는 것이 가장 시급한 문제이다.

8. 도대체 여기선 일할 수가 없어요.

1984년부터 1986년까지 92개의 회사에서 600명 이상의 개발자들을 대상으로 모의 코딩 대회를 실시하여 생산성에 영향을 미치는 요소들에 대해 살펴보았다. 먼저, 생산성과 관련이 없는 요소들은 프로그래밍 언어, 경력, 결함도, 급여의 차이로 나타났다. 반면, 업무 능력에 큰 연관성이 있는 것으로는 업무 파트너가 누구냐는 것이다. 수년간 관리자들은 개인에 따른 능력차이는 원래부터 있는 것이기 때문에 관리자가 어떻게 할 수 없다는 숙명론에 가까운 입장을 지니고 있었다. 그러나 개인들이 모여 있을때 발생하는 효과에 대해서는 그런 식의 입장을 고수할 수 없다. 회사의 업무 환경과 기업 문화 속의 무엇인가가 뛰어난 사람들을 유치하고 회사에 남아 있게 하는 것을 어렵게 하거나 효율적으로 일을 하지 못하게 하는 것이기 때문이다. 따라서 업무 환경의 특징들에 대해 태만하게 대체해서는 안된다. 정신 노동직에 종사하는 사람들과 일하거나 그들을 관리해야 한다면 업무 환경은 관리자가 책임져야 한다.

9. 사무실 시설비 아끼기

업무 환경 조성 비용을 조금이라도 아끼는 것이 이익이라는 판단을 내리는 사람은 진정한 이윤이 어떤 것인지 연구해 보지도 않고 비용과 이윤 연구를 하는 우를 범하는 것이다. 비용을 아끼는 것은 좋은 일이긴 하지만 무엇과 비교하여 좋은 것인가? 이 문제에 대한 대답은 시설 비용을 아끼는 대신 얼마나 효율성이 떨어지는지를 비교해 보아야 알수 있다. 연구직에 있는 사람들은 업무를 최적화하기 위해 적절한 크기의 조용한 공간을 필요로 한다. 만일 적정 수준 이하로 사무 공간 시설비를 절감한다면 그것으로 인한 절감 비용보다 효율성 저하로 인한 손실 비용이 더 크게 될 것이기 때문이다.

10. 머리로 일한 시간, 몸으로 일한 시간

플로(Flow)란 한 가지에 깊이 집중하여 거의 명상 상태에 빠지는 것을 의미한다. 몸이 일하는 시간 대신 플로 시간을 기록하는 업무 평가는 직원들이 플로 시간의 중요성에 관심을 갖게 하고, 집중해서 일하는 의미있는 시간을 기록할수 있게 한다는 점에서 의의가 있다.

11. 전화로부터 벗어나자.

업무 시간의 질에 대한 데이터를 수집하기 시작하면, 업무 방해의 주원인인 전화에 주목하게 된다. 가령 하루에 걸려오는 전화 15통쯤 받는 일은 대수로운 일이 아니나 한 통화 끝낼 때마다 다시 일에 집중해야 하는 시간이 걸린다. 건전한 업무 환경을 조성하는 방법은 전화와 각종 방해 요소에 대해 지금까지와는 다른 태도를 갖는 것이다. 사람들은 일을 하기 위해 차분하고 조용한 환경을 제공받아야 한다. 즉 방해 요소로부터 완전히 차단된 시간이 필요하다는 것이다. 집중해서 일하고 싶으면 걸려오는 전화를 무시해도 될 만큼 효과적이고 수용가능한 방법을 찾아야 한다. 그러나 문제는 기술이 아니라 습관을 바꾸는 것에 있다. 어떤 혁신적인 도구보다 중요한 것은 태도를 바꾸는 것이다. 사람들은 때때로 전화를 받지 않아도 된다는 것을 배워야 하며 시간이- 시간의 양이 아니라 질이- 중요하다는 사실을 알아야 한다.

12. 사무실에 다시 문을 달자.

적절한 사무 공간이 누구에게나 정확히 똑같은 모양일 수는 없다. 개인의 공간과 팀의 공유 공간은 고유의 특성을 갖기 마련이다. 경영은 직원들이 자신에게 적합한 업무 공간을 만들 수 있도록 프라이버시를 보장해 줄 수 있는 방법을 제공하고, 충분한 공간과 조용한 분위기를 만들어 주는 것이어야 한다.

13. 진화하는 업무 공간

공간 문제를 회사 전체 차원에서 해결할 필요는 없다. 프로젝트 팀이나 업무 그룹을 회사 밖으로 이주시키는 것은 합리적이다. 특별히 마련된 공간에서 하는 일은 더 많은 에너지를 쏟게 하고 성공률도 높기 때문이다. 가장 핵심이 되는 프로젝트가 있다면 회사 밖에서 수행하게 하라. 정말 중요한 작업은 밖에서 더 잘되는 법이다.

3부. 꼭 필요한 사람들

14. 혼블로워 효과

조직 또는 회사에서, 엔트로피는 태도, 외모, 사고 과정의 획일성으로 간주될 수 있으며 기업 내 엔트로피는 항상 증가한다. 따라서 가장 성공적인 관리자는 비록 회사의 기준에서 벗어날지라도 유능한 사람들을 데려오고, 기업 내의 엔트로피를 줄이는 사람이다. 비록 회사가 전체적으로 이미 손쓸 도리가 없는 엔트로피 상태에 있더라도 적어도 관리자가 당당한 작은 부분에서는 그렇지 않도록 해야 한다.

15. 직원을 제대로 뽑으려면

지원자의 능력을 검증하기 위해 지원자가 만든 샘플(포트폴리오)을 제출 하도록 한다. 또한 채용 과정에 있어서 사회학적이고 인간적인 커뮤니케이션 기술을 확인하기 위해 오디션을 이용하는 것이 좋다. 다만, 적성검사는 채용 시에 사용해서는 안된다. 적성 검사는 거의 대부분 지원자가 채용 후에 수행하게 될 업무에 초점이 맞춰있으므로 단기적으로 업무를 잘할 수 있는 사람을 뽑는 데는 도움을 주지만 장기적으로는 도움이 되지 않는다.

16. 여기서 일하는 것에 만족합니다

사람들은 진정으로 머물고 싶은 느낌을 주는 회사에서 근무하고 싶어 한다. 가장 낮은 이직률을 기록하고 있는 회사들의 공통점은 끊임없는 재교육이다. 최고의 회사들은 기존 직원에 대한 재교육을 통해 지속성을 중시하는 태도를 형성하려고 한다. 그러한 태도가 기업에 자리 잡으면 이직률은 낮아지고 강력한 공동체 의식이 생겨난다. 또한 그렇게 함으로써 지출된 비용보다 더 많은 이익을 얻을 수 있다.

17. 자가 수정 시스템

호돈효과란 변화 자체가 중요한 것이 아니라 변화를 가져오는 행동 자체가 더 중요하다는 것이다. 즉, 사람들은 새로운 것을 시도할 때 더 나은 수행 능력을 보인다는 것을 의미한다. 호돈 효과를 업무에 적용하려면, 비표준화된 접근 방법을 규정으로 삼아야 한다. 만일 표준화된 방법이라면 모든 표준들의 총합은 10페이지를 넘어서는 안되며 간단하고 융통성이 있어야 한다.

4부. 드림팀 키우기

18. 전체는 부분의 합보다 더 크다.

단결된 팀은 강력하게 짜여져 전체가 부분의 합보다 더 큰 그룹을 말한다. 하나의 팀이 단결하기 시작하면, 성공의 가능성은 극적으로 커지며 그 팀은 거의 막을 수 없는 성곡을 위한 불가항력적인 존재가 된다. 하나의 팀이 굳게 단결하기 전에, 개인들은 다양한 목적을 지니고 있을 것이다. 그러나 단결의 과정에서 그들은 모두 공통의 목적을 지니게 된다. 팀의 목표는 목표의 달성이 아니라 목표의 일치이다. 팀원들이 즐겁게 일한다는 것은 팀이 단결되었다는 것을 보여주는 신호이며 단결된 팀은 프로젝트 기간 동안에 이직률이 낮다. 단결된 작업 집단은 거만하고 자족적이고 자극적이고 배타적일수 있으나 관리자의 실제적 목표 달성에 이바지 한다.

19. 블랙팀의교훈

북부 뉴욕에 한 회사에서는 최종 버그를 발견하기 위하여, 뛰어난 재능을 지닌 이들을 블랙팀으로 만들었다. 초기, 팀원들의 테스트 능력은 다른 동료들보다 약간 더 나은 정도였으나 동기부여는 다른 동료들보다 약간 더 잘되어 있었다. 블랙팀은 그들만의 특징을 형성하며 테스터 집단으로서 성공을 거두었다. 블랙팀의 구성원들은 팀의 일에 엄청난 열정을 갖게 되었고, 다른 동료들은 긍정적인 질투심을 갖게 되었다. 검은 옷을 입고 우스꽝스럽고 과장된 행동을 하는 것은 단지 그들이 느낀 재미의 일부였으나 팀 내의 공감대 형성이라는 궁극적 목표를 이루어 냈다.

20. 팀죽이기

팀 형성을 불가능하게 만드는 방법은 다음과 같다.

방어적 관리법 : 확실한 성곡을 보장받으려고 방어적 태도를 취하는 것은 상황을 악화시킬 뿐이다. 방어적 태도는 단기적으로 걱정을 덜겠지만 장기적으로는 전혀 도움이 되지 않는다. 결국 팀을 단결시킬 수 있는 가능성이 사라지기 때문이다.
관료주의 : 관료주의가 팀 형성을 방해한다. 팀은 팀 내에서 만들어지는 목표가 무엇이든 그것을 신뢰해야 한다.
팀을 따로 떨어뜨려 놓기 : 긴밀하게 상호 작용을 요구하는 사람들을 따로 떨어뜨려 놓는 것은 함께 일하는 직원들에게 소음과 방해의 원인이 된다. 반면 그들이 모두 같은 팀에 속할 경우, 동시에 함께 조용해질 가능성이 많다. 따라서 이러한 상황에서는 플로 상태를 방해발지 않고 일할 수 있다.
여러 업무를 동시에 분담하기 : 동시에 여러가지 업무를 맡는 것은 팀 형성과 효율성에 좋지 않다. 오직 한 번에 하나의 업무만 맡도록 함으로써 여러 개의 업무를 동시에 떠맡아 시간을 쪼개게 하는 관행을 줄여 실질적으로 팀을 형성하는 기회를 제공할 수 있다.
제품의 품질 저하 : 제품을 더 적은 시간 내에 만들어 내면 필연적으로 품질은 떨어지게 마련이다. 또한 품질을 낮추어서 제품을 생산하게 되면 제일 먼저 파괴되는 것은 팀 정체성이다.
거짓 데드라인 : 데드라인을 촉박하게 설정해 놓으면 종종 직원들의 사기가 떨어진다. 하지만 촉박하지만 불가능하기 않은 최종 시한을 설정하면 팀은 그것을 즐거운 도전으로 받아들이기도 한다. 그러나 거짓으로 데드라인을 설정하는 것은 팀의 단결에 전혀 도움이 되지 않는다.
소집단 관리 : 팀은 위계 질서가 있는 집단의 하부에서만 나타나는 것이다. 관리 단계에서는 단결된 팀이 존재할 수 없다. 관리자들이 팀에 결속된다면, 그것은 오직 그들이 관리자와 팀의 구성원이라는 이중적인 역할을 수행하기 때문이다. 조직의 상부로 올라가면 갈수록, 단결된 팀의 개념은 더욱더 멀어져서 결국 사라진다.

21. 스파게티 회식

관리자는 팀원들이 함께 성공을 거둘 수 있는 작은 업무들을 끊임없이 제공한다. 업무는 쉬운 일들로, 팀원들이 함께 성공을 거두는 것에 익숙하게 만든다. 특별히 관리자가 개입하지 않고, 팀이 동료 집단으로서 다정하고 친밀하게 일할 수 있다면 가장 훌륭히 성공한 것이다. 최고의 관리자는 팀원들이 '관리되고 있다'라는 느낌을 받지 못하는 가운데 끊임없이 이런 기회들을 제공하는 사람이다.

22. 서로 신뢰하는 문화

최고의 회사에는 자연스러운 권위가 자유자재로 기능하고 있다. 관리자는 일반적인 방향 설정, 협상과 고용 같은 몇몇 분야에서 다른 직원들보다 뛰어나며 확실히 인정받고 있다. 각 직원들은 각각의 전문분야에서 다른 사람들보다 뛰어나고 그 분야에 자연적인 권위를 갖고 있다. 이러한 신뢰감 넘치는 분위기는 팀이 단결할 수 있는 최적의 조건이다.

23. 팀 형성을 위한 공감대 형성

건강한 기업을 만들기 위한 독자적 기법의 요소들

품질을 중시하는 문화를 만들어라.
종결감을 느끼게 하라.
엘리트 의식을 키워 주어라.
이질성을 허락하고 격려하라.
성공적인 팀들을 잘 유지하고 보호하라.
전술적인 것이 아니라 전략적인 방향을 제시하라.

5부. 일은 재미있어야 한다

24. 때론 무질서가 필요하다

25. 자유 전자적 속성을 지닌 사람들

26. 잠자는 거인을 깨워라

6부. 피플웨어 그후

27. 다시 본 팀 죽이기

28. 과도한 경쟁은 단결을 해친다

29. 프로세스 개선 프로그램

30. 변화를 두려워하지 말라

31. 사람에게 투자하자

32. 조직 학습이 필요하다

33. 궁극적으로 관리자가 저지르는 죄

34. 공동체 형성

#2. 스크럼(Scrum) by Ken Schwaber, Mike Beedle

스크럼이란 애자일 개발방법론 중 하나로 복잡합을 제거하는 관리 제어 프로세스이다. 스크럼의 기본 개념은 단순하다. 앞으로 팀이 완료할수 있는 모든 것을 우선 순위에 따라 정리한 product backlog를 작성하고, 스프린트에서 수행할 일의 목록인 sprint backlog를 작성한다. 또한 매일 일정한 시간에 약 15분동안 팀원이 모여 일일 스크럼 회의 실시하고 burndown chart를 활용하여 스프린트(30일 반복주기)를 진행하는 것이다. 스크럼에서는 스프린트 동안의 관리자인 스크럼 마스터의 역할이 중요한데 팀원들이 스크럼 실천법을 실천하고 팀이 결정을 내리거나 필요한 자원을 얻을수 있도록 돕는 역할을 수행한다.

경험주의적인 관리 모델 : 스크럼에서 사용하는 경험주의적인 프로세스 관리 피드백 루프, 피드백 메커니즘을 이용해서 예측하지 못한 부분을 감시, 적응할수 있게 하고, 규칙성과 예측성을 제공한다. 스크림 팀원들은 경험에 기초해서 자신의 기술, 경험 그리고 현재 상황에 맞는 최선의 방법을 궁리하고 실행한다.

I : 입력 또는 요구사항이나 기술

C : 일일 스크럼 회의와 매 스프린트의 마지막에 스크럼 진행 상황을 확인

O : 매 이터레이션마다 개발되는 제품 증분

생각해볼 문제..

스프린트는 반드시 30일이여야 할까? -> 몇 일로 할수 있을까?

; 저자는 30일이 절묘한 절충일임을 제안하며, 1달이 지나가면 관리자들이 프로젝트에 관여하고 싶어하는 충동을 억제하기 힘들어진다고 주장한다. 또한 먼저 30일 동안 진행한 후에, 스크럼에 어느 정도 적용이 되면 팀원들간에 상의하여 기간을 조정하도록 제안하고 있다. 그렇다면 과연 몇 일이 적당할까? 팀마다 고유의 특성과 프로젝트의 특성에 따라 팀원간의 적당한 절충점을 찾아가야 하겠지만, 2주 단위로 끊어서 생각해보는 것을 제안한다. ex) 2주, 4주, 6주, 8주..
개방된 업무환경 - 항상 좋은 일만 벌어질 것인가?

; 저자는 개방된 업무환경 속에서 다양한 의견을 주고받으며 프로젝트의 생산성을 높임을 주장하고 있다. 그러나 오픈된 공간이 항상 좋은 일만 발생하도록 하는 것일까? 팀원이 한 공간에서 작업을 하는 것은 각자 떨어져서 작업을 진행하는 것보다 효과적임은 분명한 사실이다. 하지만 집중을 요구하는 개발하는 사람들에게는 오히려 개방적인 공간이 소음으로 인식될수 있음을 염두해야한다.
결과지향적인 스크럼이 바람직한가? - 목표를 얼마나 달성했는가를 평가, 목표를 달성하기 위해 사용되어진 시간은 평가하지 않는다 -> 생산성은 높아지지만 기능 축소, 비용 증가, 품질 저하는 어떻게 해결할 것인가?

; 스크럼은 결과지향적이다. 과정지향적이지 않다. 그러나 결과지향적인 것이 항상 생산성 향상에 도움이 되는 것일까?
일일 스크럼 회의를 15분간 진행하는 것이 현실적인가?

; 현실적으로 7(+-)2명의 팀원이 15분간 일어서서 미팅을 하는 것은 불가능하다고 생각한다. 어제 한일, 오늘 할일, 그리고 업무에 방해가 되는 내용을 한사람씩 보고하는 것이 일일 스크럼 회의의 목적이지만, 팀원간에 그에 따른 피드백도 요구되기 때문이다. 보고만 하기 위한 미팅이라면, 굳이 전화나 모임을 통해서가 아니라 메일같은 간접적인 의사소통으로도 가능하다.
변화를 싫어하는 사람들을 위해 자연스럽게 스크럼 실천법을 적용한다 -> 무엇부터 어떻게 해나갈 것인가?

; 대다수의 사람들은 변화를 싫어한다. 따라서 특정한 이름을 붙이고, 어떤 방법론을 사용하자고 제안할때 많은 사람들은 먼저 그것이 무엇인가를 확인하기 전에 거부 반응을 일으킬수 있다. 따라서 저자는 자연스러운 분위기 속에서 스크럼 실천법 적용을 제안하고 있다. 그렇다면 실제로 어떻게 적용해 나가는 것이 바람직할까? 우선 product backlog라든가 sprint backlog등 이런 개념을 명명하기보다는 자연스럽게 이루어 질수 있도록 하는 것이 필요할 것이다. 모든 프로젝트 개발에 있어서 먼저 사용자의 요구사항을 파악하고, 어떻게 일을 진행시켜나가야 할 것인가의 문제는 필수적이다. 따라서 이를 자연스럽게 적용해나가는 일이 요구된다.

#3. Agile Project Management with Scrum by Ken Schwaber

1. Backdrop : The Science of Scrum

Empirical Process Control

In the long run, making successful products the first time using empirical process control turns out to be much cheaper than reworking unsuccessful products using defined process control.-> example(code review)

Code review : 코드를 실행하지 않고, 사람이 검토하는 과정을 통하여 코드상에 숨어있는 잠재적인 결함(defect)을 찾아내고 이를 개선하는 과정. forrnal한 코드리뷰기법일수록 결함발견에 집중하고, 소프트웨어 개발 주기의 후반에 위치하지만, lightweight한 코드리뷰기법은 결함의 발견뿐만 아니라 같은 로직을 여러 관점에서 생각하는 아이디어 회의나 주니어 개발자에게로의 지식 전달 등 부가적인 목적들을 함께 가지고 있다.

Three legs that hold up every implementation of empirical process control : visibility, inspection, adaptation.

Scrum Roles

Three scrum roles : Product Owner, Team, Scrum Master

Scrum Flow
New Management Responsibilities

Scrum Master : managing the scrum process, like a sheepdog

The ScrumMaster at MetaEco : (i) 스프린트 기간 동안 그의 팀과 일이 방해 받지 않도록 했으며 (ii) 프로세스가 MetaEco의 CEO와 회사의 요구에 부합하도록 하였다.

The Product Owner at MegaEnergy : Janre(Product Owner)는 제품 백로그에서 가장 우선순위가 높은 요구사항을 반영한 작업을 선정하여 작업을 진행시켰고 MagaEnergy는 빠른 자동화를 통하여 이익을 창출시켰다.

The Team at Service1st : 17명 team-> 4 subteams(3~5명) self-organizing team.
The ScrumMaster

The ScrumMaster is responsible for the success of the project, and he or she helps increase the probability of success by helping the Product Owner select the most valuable product backlog and by helping the Team turn that backlog into functionality.

(i) The untrained ScrumMaster at Trey Research : Daily Scrum에서의 오류=> self-organizing team의 중요성을 잊고 있었다. (스크럼 마스터가 지시한 일을 팀원이 지난 스크럼 미팅 이래로 이행하였는가를 확인, 지금과 다음 스크럼 미팅 사이에 할 일을 각 팀원에게 지시, 목표에 도달하기 위해서 스크럼 마스터가 도와줄 수 있는 일이 무엇인가를 찾음)

c.f.) Critical shift from controlling to facilitating, from bossing to coaching

(ii) The untrained ScrumMaster at Litware : ScrumMaster인 John은 ScrumMaster의 역할에 대해 이해하지 못했고 ScrumMaster로서의 역할을 충실히 수행하지 못했다. 따라서 ScrumMaster의 역할을 중요시 생각하는 다른 팀원으로 대체시켰다.

(iii) Overzealous at Contoso.com : ScrumMaster는 변화가 필요하면 바꿔야 한다. 그러나 변화가 문화적으로 수용되지 않을 경우, ScrumMaster는 이를 받아들여야 한다. Scrum은 가능한 것을 바꾸는 것이다.(The art of the possible)

(iv)Wolves at MegaFund : ScrumMaster는 스크럼 룰과 실행방법을 조직에 잘 적응시키고 자신의 의무를 잘 이행해야 한다.
Bring Order from Chaos

Service1st, Tree and Lapsec 의 프로젝트는 모두 너무 복잡해서 project planning과 control practices가 실패했다. 그러나 self-organization을 통해 풀어나갔다. 상황이 너무 복잡해서 개인들이 계획을 실행하는데 어려움이 있었지만 스크럼마스터로서 coach하고 mentor했다.

Service1st : 팀에게 하나씩의 일만 부여하고, 이것에만 집중하도록 함.

Tree : Scrum of Scrums – the work of many teams is coordinated by individuals from each of the teams

Lapsec : 팀에게 실제 일과 비슷한 예제를 제공하여, 스크럼을 이해하도록 도왔다.

The Product Owner

ScrumMaster는 개발팀과 제품관리자와 고객 간의 장벽을 없애서 고객이 개발에 직접적으로 참여할 수 있도록 하는데 책임이 있다. 또한 제품관리자가 제품 투자수익률(ROI)를 최대화하고 제품의 목적에 충족할 수 있도록 Scrum을 사용하는 방법을 보여주어야 한다.

스프린트 리뷰 : collaboration – a vibrant demonstration of a reality

XFlow at MegaFund : Goeff(product owner)는 미팅을 통해 MegaFund에서 성공적인 organization을 만들었다 – engineer와 internal customer의 요구사항이 달라 갈등이 있었지만 미팅을 통해 두 집단간이 공통으로 생각하는 우선순위 작업을 결정(7가지의 item과 bug를 fix하는 일)하고 30일간의 개발과정을 통해 output을 만들어냈다.

Geoff는 전통적인 스크럼 제품관리자가 아니었고, product backlog도 사용하지 않았으나 스프린트 계획 미팅에서 개발팀을 만났다. Geoff는 “the art of the possible”과 고객과 엔지니어 팀간의 직접적인 협력을 가능하게 했다. Face to face로 만날 때, 요구와 문제들은 상당히 overlap된다.

Company goal at Techcore :

Company goal at MegaBank Funds Transfer system : the importance of taking in plain language

Project manager인 Pat은 FTS(Fund Transfer System)에 스크럼을 사용하면 고객들로 하여금 개발 프로젝트에 보다 참여시키는데 도움을 줄 것이라고 생각했다. Product backlog(작업의 우선순위 리스트)를 사용, 한 달을 개발주기로 삼았다. FTS팀과 경영팀간의 의사소통을 위해 공통된 언어의 사용이 필요하다.

팀(기술용어 사용)과 제품 관리자(비즈니스 요구와 목적)는 스크럼을 사용하기 전, 서로 다른 언어를 사용했다. 그러나 스크럼에서는 product backlog를 사용(common denominator), 제품 관리자와 팀 have collaborated to do the best for the business, Each collaboration has resulted in an improved ROI.

#4. 익스트림 프로그래밍(Extreme Programming Explained) by Ken Beck, Cynthia Andres

익스트림_프로그래밍(1).ppt

XP란 ?
1. 오래되고 효과가 없는 사회적 습관들을 버리고 효과 있는 새로운 습관들을 채택하는 것
2. 오늘 내가 기울인 모든 노력에 대해 자신을 인정해 주는 것
3. 내일 좀 더 잘해보려고 애쓰는 것
4. 팀 전체가 공유하는 목표에 내가 얼마나 기여했는지를 잣대로 자신을 평가하는 것
5. 소프트웨어 개발을 하는 중에도 여러분의 인간적 욕구(인간관계를 맺고 싶다는 욕구도 포함) 가운데 일부를 채우겠다고 요구하는 것
XP의 패러다임 : 깨어 있고 적응하며 변하는 것
가치, 원칙, 실천방법
1. 가치 : 의사소통, 피드백, 단순성, 용기, 존중
2. 원칙 : 인간성, 경제성, 상호이익, 자기유사성, 개선, 다양성, 반성, 흐름, 기회, 잉여, 실패, 품질, 아기발걸음, 받아들인 책임
3. 실천방법 : 함께앉기, 전체팀, 정보를 제공하는 작업공간, 활기찬 작업, 짝 프로그래밍, 짝 프로그래밍과 개인적 공간, 스토리, 일주일별 주기, 분기별 주기, 여유,

10분 빌드, 지속적 통합, 테스트 우선 프로그래밍, 점진적 설계

<참고 > 보조실천방법 : 진짜 고객참여, 점진적 배치, 팀 지속성, 팀 크기 줄이기, 근본원인분석, 코드공유, 코드와 테스트, 단일코드기반, 매일배치, 범위협상계약, 사용별지불

전체 XP팀

테스터 : 구현을 시작하기 앞서, 고객이 자동화된 시스템 차원의 테스트를 선택하고 작성하는 일을 돕고, 프로그래머에게 테스트 관련 기법 지도

상호작용 설계자 : 시스템 전반적인 메타포를 선택하고, 스토리들을 작성하고, 새로운 스토리들을 찾아낼 기회를 잡기 위해 이미 배치된 시스템의 사용 양상을 조사, 최종 사용자의 문제거리를 해결 -> 우선순위가 높은 작업

아키텍트 : 대규모 리팩토링을 찾아내고 실행하는 일, 아키텍처를 집중 테스트하는 시스템 차원의 테스트를 작성하는 일, 스토리를 구현하는 일

프로젝트 관리자 : 팀 내의 의사소통이 용이하도록 하고, 고객과 공급자 그리고 조직의 다른 부분과의 의사소통을 조정, 팀의 역사가로 활동, 팀에게 프로젝트의 진전 정도를 상기시킴, 게획과 현실이 계속 일치하도록 유지시킬 책임이 있음

제품 관리자 : 스토리를 작성하고, 분기별 주기에서 주제와 스토리들을 고르고, 일주일별 주기에서 스토리들을 고르고, 구현 과정 중 스토리에서 완전하게 명세되지 않은 부분들이 드러날 경우 질문에 답변하는 일을 수행

임원 : XP 팀을 후원하거나 감독하는 일, 개선을 감시하고, 권장하고, 조장하는 일

테크니컬 라이터(기술적 출판물) : 기능에 대한 빠른 피드백 제공, 사용자들과 긴밀한 관계

사용자 : 스토리를 작성하고, 고르는 일을 돕고 개발 중에 문제영역에 관련된 결정을 내림, 사용자가 전체 공동체를 대변

프로그래머 : 스토리와 과업을 추정, 스토리를 과업으로 나누고, 테스트 작성, 기능을 구현하는 코드 작성, 개발 프로세스 자동화, 시스템의 설계 개선

인적자원부 : 평가와 채용

계획짜기 : 범위를 관리하기

매일, 매주, 매분기별로. 시간과 비용 , 품질. yeasterday's weather.

목록작성
시간추정
주기를 위한 예산
해야할 일을 예산범위내에서

테스트 : 일찍, 자주, 자동화

팀 내부의 신뢰와 고객과의 신뢰를 강화함으로써 개발에 기여

테스트 비용효율을 높이기 : 재확인(double checking), DCI(defect cost increase)

설계하기 : 시간의 가치

XP : 언제나 설계하라, 지속적인 설계비용을 낮추려는 의도를 담고 있다

테일러주의와 소프트웨어

테일러- 과학적 관리(공장 생산성을 개선하기 위해 관찰과 가설, 실험을 적용)

계획과 실행의 분리 : 교육받은 공학자(아키텍처, 프레임워크 그룹), 작업자-기계부품
품질부서 따로 두기 : 품질과 엔지니어링을 조직 구조에서 분리하면 품질 부서가 하는 일의 성격이 징벌적이 된다

도요타 생산 시스템

going fast -> 자동차 생성 공정의 모든 단게에서 쓸모없이 낭비되는 노력 제거

TPS(Toyota Production System) : 엄격한 사회계층화 없음, 전체 조직이 품질 조직, 과잉 생산의 낭비가 가장 큰 낭비,

TPS와 소프트웨어개발의 유사점 : 작업자들의 교차훈련, 공장을 세포로 나누어 조직, 고객과 공급자 사이에 이익을 공유하는 계약 작성

XP 적용하기예

자기 자신부터의 변화 -> 조직의 변화

비즈니스와 기술관심이 조화를 이루도록 해야함

단, XP의 가치와 조직의 진짜 가치가 어긋날 때는 XP의 사용은 부적절

#5. 린 소프트웨어 개발(Lean Software Development) by Mary Poppendieck, Tom Poppendierk

린의 7가지 원칙

1. 낭비를 제거하라 ; 실질적으로 고객의 가치를 높이는 일에 시간을 쓰기

낭비 찾기- 미완성작업, 가외기능, 직무전환, 대기, 이동, 결함

가치흐름도 작성 - 낭비확인가능(가치측정, 개선하는 시작점 찾기 가능), 고객요구 신속대응, 실제 가치를 생산하는 활동으로 묶임

2. 배움을 증폭하라 ; 어려운 문제가 있을때 피드백을 증가시키기

피드백 - 개발 프로세스에 문제가 생겼을때, 피드백 횟수를 늘리기, 스래싱이 생기지 않으면서 가능한 짧게

반복(린의 기본 원칙)- JIT(Just In Time)흐름;작업자의 충분한 의사소통->품질문제발생확인, 작은단위의 작업->짧은 피드백, 짧은 반복 주기; 설계.구현.테스트 주기를 소화할만큼 길면서 고객에게 피드백을 자주 받을만큼 짧을것, 고객이 중요하게 여기는 기능을 골라서 계획

동기화 - 코드공유; 스패닝 어플리케이션(소규모team->전체시스템), 매트릭스(전체아키텍어->독립된 컴포넌트, 서브시스템)

집합 기반 개발방법 - 점/집합(제약조건알아내기, 적은데이타->많은정보전달->강력한의사소통형태, 선택미루기)

3. 가능한 늦게 결정하라 ; 선택이 유효할 때까지 되도록 결정하지 않은 채로 두기. 그러나 그 이상은 안됨

대안적 사고 - 결정미루기(HP;전기코드, JIT;복잡성을 통제-> 되돌릴 수 없는 활동을 최소로 줄이는 것), 옵션(미래에 어떤 것을 할수 있는 권리, 고객의 요구를 명확히 이해하고 개발중인 기술이 성숙할 시간을 가질때까지 결정을 미룰수 있도록 함)

책임이 따르는 마지막 순간 - 결정을 미루는 몇 가지 전술(부분적으로 완료된 설계 정보 공유(짧고 반족적인 탐험주기를 통한 설계), 작업자들 간 직접 협력체계구성(직접 의사소통), 변화를 수용하는 방법에 대한 감각을 개발(전문가;오류가 문제를 일이키기전에 수정), 한분야에서 특히 중요한것이 무엇인지 느끼는 감각을 계발, 결정을 언제 내려야 하는지 감각 키우기, 빨리 반응하는 능력 개발

의사결정 - 너비우선(깔데기-다양한 전문적 지식을 가진 사람 필요)vs깊이우선(터널-초점을 맞추는 올바른 선택이 있을때 효과적), 단순한 규칙(결정이 필요할때 필요한 곳에서 현재 정보를 고려하여 즉시 이루어지도록함),

4. 최대한 빨리 납품하라 ; 고객이 요구하는 가치를 실현하도록 빨리 납품하기

당김 시스템 - pull(고객의 요구가 일을 끌어당기도록 하는것); 생산라인 끝에서 변화 고려, 칸반-인덱스카드+ 일일회의

대기행렬 이론 - 순환주기줄이기(일정한 도착률, 일정한 서비스율, 여유)

지연비용 - 개발 프로젝트의 간단한 경제 모델 만들기-> 개발팀의 트레이드오프 결정의 길잡이

5. 팀에 권한을 위임하라 ; 사람들이 자신의 잠재력을 써서 가치를 더할수 있도록 하기

자기 결정권 - 워크아웃(노동자->관리자)

동기 부여 - 작은 실수보다 지시하는 방식이 장기적으로는 심각

리더십 - 개발명인(개발자의 역량을 이끌어내기)

전문지식 - 뉴코, 전문 지식 커뮤니티 필요

6. 통합성을 구축하라 ; 처음부터 통합성을 생각하여 만들기(interface)

인식통합성 - 고객이 시스템을 사용하면서 겪는 경험전체와 관련 -> 시장점유율

개념통합성 - 시스템을 구성하는 중심 개념들이 총체적으로 자연스럽게 결합한 통일체

리팩토링 - 시스템을 개발하면서 설계를 변경, 지속적인 개선(린)

테스트 - 실제로 작동하는가에 대한 피드백 제공

7. 전체를 보라 ; 전체를 희생하여 부분을 최적화하려는 유혹을 경계하기

측정 - 성과측정-> 정보측정

계약 - 시간자재계약(동시개발방법, 고객이 범위를 제한 ->비용을 쉽게 조정), 단계적 계약(주계약 이용, 각반복주기에서 릴리즈), 목표비용계약(양측 작업자에게 목표비용을 맞추는 선에서 문제의 해결책을 찾는데 권한 부여), 이익공유계약(시간이 지남에 따라 상호이익을 위해 양측이 하는 일을 수정가능) => 범위를 상세히 결정하지 않음

#6. Practices of an Agile Developer

Beginnig Agility

1. Work for outcome(Blame doesn't fix bugs) : 불평을 들으면 구체적인 원인을 찾고, 도울 수 있는 일을 찾기
2. Quick fixes Become quicksand(Don't fall for the quick hack) : code review, unit testing
3. Criticize Ideas, not people(-) : negativity kills innovation
4. Damn the torpedoes, go ahead(do what's right) : 정직하게, 사실을 말하는 용기를 갖기
Feeding Agility
1. Keep up with change(keep up with changing technology) : 변화에 속도에 맞춰 career와 project를 맞춰라
2. Invest in your team(Raise the bar for you and your team) : brown-bag session
3. Know when to unlearn(Learn the new; unlearn the old) : 새로운 기술을 배울땐, 오래된 습관을 버릴것
4. Question until you understand(keep asking why) : 이슈의 본질을 이해할때까지 질문을 계속하기
5. Feel the rhythm(Tackle tasks before they bunch up) : stand-up meeting, iteration length -> 정기적인 리듬은 결정을 내리고, 프로젝트 진척을 돕는다.
Delivering what users want
1. Let customers make decisions
  
  devil - 개발자들은 창조적이고 이성적이므로 application에 대해 가장 잘 알고있다. 따라서 개발자들이 모든 critical한 결정을 내려야 한다
  
  angle - Let your customers decide : business owners가 이해할수 있는 언어로 자세하게 제시한 다음, 그들이 결정을 내리도록 하라.
2. Let design guide, not dictate(A good design is a map : let it evolve) :
3. Justify technology use
  
  devil - resume driven design
  
  angle - Choose technology based on need : 먼저 필요한게 무엇인지 결정하고, 그러한 구체적인 문제에 적용할 기술적인 사용에 대해 평가하라.
4. Keep it releasable
  
  devil - 지금 당장 고쳐야할 무언가를 발견하면 하고있는 일을 멈추고 결함을 고쳐라
  
  angle - keep your project releasable at all times :언제나 프로젝트가 compilable, runnable, tested, deploy되어 있게 하라
5. Integrate early, integrate often
  
  devil - 프로젝트가 끝날때 code를 integrate할 시간이 많이 있다
  
  angle - code integrate를 일찍, 그리고 정기적으로 계속 할수록 위험은 줄어든다
6. Automate deployment early
  
  devil - it's ok to install your product manually, especially to QA. you don't have to do it all that often, and they are pretty good about copying all the right files.
  
  angle - deploy your application automatically from the start : Use that deployment to install the application on arbitrary machines with different configurations to test dependencies. QA should test the deployment as well as your application
7. Get frequent feedback using demos
  
  devil - It's not your fault : the problem lies with our customers - those pesky end users and clients
  
  angle - Develope in plain sight : keep your application in sight during development. Bring customers together and proactively seek their feedback using demos evey week or two
8. Use short iterations, release in increments
  
  devil - We've got this beautiful project plan with all the tasks and deliverables scheduled for next three years. When we release the product then, we'll capture the market!
  
  angle - Develop in increments : Release your product with minimal, yet usable, chunks of functionality. Within the development of each increment, use an iterative cycle of one to four weeks or so.
9. Fixed prices are broken promises
  
  devil - We have to deliver a fixed bid for this project. We don't have all details yet but need to put a bid in. I need an estimate for the whole team by Monday, and we'll have to deliver the whole project by the end of the year
  
  angle - Estimate based on real work : Let the team actually work on the current project, with the current client, to get realistic estimates. Give the client control over their features and budget.
Agile feedback
1. Put Angle on your shoulders
  
  devil - You can't justify the time and effort it takes to write unit tests. It will just delay the project. You're a darn good programmer anyway- unit tests are just a waste of time, and we're already in a crunch
  
  Coding feedback
  
  angle - Use automated unit tests : Good unit tests warn you about problems immediately. Don't make any design or code changes without solid unit tests in place
2. Use it before you build it
  
  devil - Go ahead and complete all of your library code. There's plenty of time later to see what people think of it. Just throw the code over the wall for now. I'm sure it's fine
  
  Write tests before writing code
  
  Good design doesn't mean more classes
  
  angle - Use Test Driven Development as a design tool. It will lead uyou to a move pragmatic and simpler design
3. Diffrent makes a differnce
  
  devil - As long as the code works on your machine, that's Ok. Who cares it works on some other platform? You don't have one
  
  Automate to save time
  
  angle - RUne unit tests on each supported platform and enviroment combination, using continuous integration tools. Actively find problems before they find you
4. Automate acceptance testing
  
  devil - All right, so your unit tests verify your code does what you think it should. Ship it. We'll find out it it's what the customers want s soon enough
  
  angle - Create tests for core buiness logic ; HAve your customers verify these tests in isolation, and exercise them automatically as part of your general test runs
5. Measure real progress
  
  devil - Please use your time sheets to report your progress. We'll use these for project planning. Always fill in 40 hours each week., regardless of how much you really worked
  
  Focus on where you're going
  
  angle - Measure how much work is left : Don't kid yourself - or your team- with irrelevant metrics. Measure the backlog of work to do
6. Listen to uers
  
  devil - Users are always complainning. It is not your fault; they are just too sEvey complaint holds a truthtupid to read the stinkinn' manual. It is not a bug; they just don't understand. They shoud know better
  
  It is a bug
  
  angle - Every complaint holds a truth; Find the truth, and fix the real problem

5. Agile code

1. Program intently and expressively
  
  devil - Code that works and is understandable is nice, but it's more important to be clever. You are paid for being smarts; show us how good you are
  
  angle - Write code to be clear, not clever; Expres your intentions clearly to the reader of the code. Unreadable code isn't clever
2. Communicate in code
  
  devil - Comments should help out when the code is too tangled to read. Expalin exactly what the code is doing, line by line. DOn;t worry ahout why, jus tell us what on Earth it's doing
  
  Don't comment to cover up
  
  angle - Comment to communicate : Document code using well-chosen, meanigful names. Use commments to describe its purpose and constraints. Don;t use commenting as a substitute for good code
  
  (COmments fieel like helpful friends; you can read them and quickly scan code to fully understand what it's doing and why)
3. Actively evalute trade-offs
  
  devil - Performance, productivity, elegance, cost, and time to market are the most important,critical issues in software development. You have to maximize all of them
  
  No best slution
  
  angle - Consider performance, convenience, productivity, cost, and time to market. If performance is adequate,then focus on improving the other factors. Don't complicate the design for the sake of perceieved performance or elegance.
4. Code in increments
  
  devil - Real programmers work for hours and hours straight, without a break, without even looking up. Don't break your flow to stop and compile; just keep typing
  
  angle - Wtite code in short edit/ bulid/ test cycles : It's better than coding for an extended period of time. You'll create code that's clared, simpler, and easier to maintain
5. Keep it simple
  
  devil - Software is complex business. Any fool can write simple, elegant software. You'll get fame and recognition(not to mention job security) by writng the most sophisticated, complex programs possible
  
  Simple is not simplistic
  
  angle - Develop the simplest solution that works ; Incorporate patten, principles, and technology only if you have a compelling reason to use them
  
  (Code is easy to follow and correct)
6. Write cohesive code
  
  devil - You are about to write some new code. and the first decision you need to make is where to put it. It doesn't really matter where it goes, so just go ahead and add it to the class that happen to be open in your IDE now. It's easier to keep track of code when it;s all in one big class or component anyway
  
  angle - Keep classes focused and components samll : Avoid the temptation to build large classe or components or miscellaneous catchall classes
  
  (Classes and componets feel tightly focused; each does one thing,and does it well. Bugs are easy to track down, and code is easy t modify because responsibilities are clear)
7. Tell, Don't ask
  
  devil - Don't trust other objects. After all, they were written by other people, or even by you last month when you weren't smart. Get the information you need from others, and then do your own calculations and make youe own decisions. Don't give up control to others
  
  Keep commands seperate from queries
  
  angel - Don't take on another object's or component's job. Tell it what to do, and stick to your own job
  
  (Smalltalk uses the concept of "message passing" instead of method calls, tell, Don't ask feels your are sending messages, not calling functions)
8. Substitute by contract
  
  devil - Deep inheritance hierachies are great. If you need functionality from some other class, just inherit from it! and don;t worry if your new class breaks things; your callers can just change their code. It's their problem, not yours
  
  Use inheritance for is - a ;use delegation for has - a or uses - a
  
  angle - Extend systems by substituting code ; Add and enhance features by substituting classes that honor the interface contract. Delegation is almost always preferable to inheritance
  
  (It feels sneaky ; you can sneak a replacement component intothe code base without any of the rest the code knowing about it to achieve new and improved functionality)
Agile Debugging
1. Keep a solution log
  
  devil - Do you often that deja vu feeling during development? Do you often get that dejavu feeling during development? That's Ok. You figured it out once. You can figure it out again
  
  Don't get burned twice
  
  angle - Maintain a log of problems and their solutions : Part of fixing a problem is retaining details of the solution so you can find and apply it later
2. Warning are really errors
  
  devil - Compiler warnings are just for the overly cautious and pedantic. They are just warnings after all. If they were serious, they'd be erroes, and you couldn't cmpile. So just ignore them , and let'er rip
  
  angle - That warning as errors : Checking in code with warnigs is just as bad as checking i cde with errors or cde that fails its tests. No checked- in code should produce any warning from the build tools
3. Attack problems in isolation
  
  devil - stepping line by line through a massive code base in pretty scaray. But the only way to debug a signifucant problem is to look at the entire system. All at once. After all, you don't know where the problem may be, and that's the only way to find it
  
  Prototype to isolate
  
  angle - seperate a problem area from its surroundings when working on it, especially in a large application
  
  (When faced with a problem taht you have to isolate)
4. Report all exceptions
  
  devil - Protect your caller rom weird exceptions. It's your job to handle it. Wrap everything you call, and send your own exception up instead - or just swallow it
  
  angle - Handle or propagate all exceptions : Don't suppress them, even temporarily. Write your code with the expection that things will fail
  
  (You feel you can rely on getting an exception when something bad happens. There are no empty exception handlers)
5. Provide useful error messages
  
  devil - Don't scare the users, or even other programmers. Give them a nice, sanitized error message. Use something conforting like "Use Error. Replace, and Continue"
  
  angel - Present useful error messages : Provide an easy way to find the details of errors. Present as much supporting detail as you can about a problem when it occurs, but don't bury the user with it
  
  (Error messages feel useful and helpful, When a problem arises, you can hone in on the precise details of what went wrong, where)

Agile collaboration
1. Schedule regular face time
  
  devil - you need to hold meetings - lots of them. In fact, we're going to keep scheduling more meetings until we discover why no work is getting done
  
  question- 1. what did I achieve yesterday? 2. what am I planning to do today? 3. what's in my way?
  
  angel - Use stand- up meeting : stand-up meetings keep the team on the same page. Keep the meeting short, focused, and intense
2. Architects must write code
  
  devil - Fired, our expert architect, will deliver a design for you to code. He's very experienced and very expensive, so don't waste his time with silly questions or implementation problems
  
  You can't code in PowerPoint
  
  angle - Good design evolves from active programmers : Real onsight comes from active coding. Don't use architects who don't code- they can't design without knowing the realites of your system
  
  (Architecture, design, coding, and testing feel like diferent facets of the same activity - development. They shouldn't feel like seperate activities)
3. Practice collective ownership
  
  devil - Don't worry about that crippling bug ; Joe will fix it when he gets back from vacation next week. Just work around it until then
  
  angel - Emphasize collective ownership of code : Rotate developers across different modules and tasks in different areas of the system
  
  (You feel comfortable working on most any part of the project)
4. Be a Mentor
  
  devil - It took you a long time and a lof of hard work to get where you are. Keep it to yourself so you look better. Use your superior skills to intimidate your teammates
  
  Knowledge grows when given
  
  angle - Be a mentor : There's fun in sharing what you know - you gains as you give. You motivate others to achieve better results. You improve the overall competence of your team
  
  (You find that teaching is another way to improve your own learnining, and others come to trust that you can help them)
5. Allow people to figure it out
  
  devil - You're so smart ; just provide neat solutions to others on the team. Don't waste time trying to educate them
  
  angle - Give others a chance to solve problems: Point them in the right direction instead of handing them solutions. Everyone can learn something in the process
6. Share code only wwhen ready
  
  devil - Check in all code as often as you can, especially when you leave for the day, whether it's ready or not
  
  angle - Never check in code that's not ready for others. Deliberately checking in code that doesn't compile or pass its unit tests should be considered an act of criminal project negligence
7. Review code
  
  devil - Users make great testers. Don't worry - if it's wrong, they'll tell us eventually
  
  angle - Review all code : Code reviews are invaluable in improving the quality of the code and keeping the error rate low. If done correctly, reviews can be practical and effective. Review code after each task, using differnt developers
  
  (Code reviews happen in small chunks, continuously. It feels like an ongoing part of the project, not a big scary event)
8. Keep others informed
  
  devil - The manager, your team, and the business owners are relying on you to get tasks done. If they want your status, they'll ask you for it. Just keep your head down, and keep working
  
  angle - Publish your status, your ideas and the neat things you're looking at. Don't wait for others to ask you the status of your work
  
  (You don't feel pestered by managers or co-workers constantly asking for your status or your lastest design or research efforts)

#7. 엔터프라이즈급 애자일 방법론(프로젝트 규모 확장에 따른 애자일 기법과 사례) - 딘 레핑웰

1부 . 소프트웨어 애자일 방법론 소개

(1) 폭포수 개발방법론의 문제점 – “일정관리”

(a) 요구사항을 잘 이해하고, 제대로 정의하려면 시간을 투자해야 한다.

: 개발자나 고객이 모든 요구사항을 완벽하게 이해하고 있다거나 사전에 누군가가 이해하고 있을 것이라고 가정하면 안 된다.

(b) 변경사항은 많지 않을 것이고 수용 가능할 것이다.

: 변경사항은 지속적으로 생겨나며, 변경사항을 잘 추적하기 위해서 좀 더 시간이 필요하다고 가정하는 편이 낫다.

: 시스템 통합은 중요한 프로세스이며 위험을 줄이는 본질적인 요소라고 가정해야 한다. 그러므로 프로젝트를 시작할 때부터 통합을 시작하여 프로젝트가 끝날 때까지 지속해야 한다.

(d) 일정에 맞게 완료할 수 있다.

: 새롭고 최첨단에 혁신적이고 검증되지 않았으며 위험 요소가 있는 소프트웨어 프로젝트는 기능이 고정된다 하더라도 일정 안에 완료할 수 있다고 가정하면 안 된다. 오히려 할 수 없다고 가정해야 한다. 대신, 중요한 기능에 대해서는 소비자가 예상하는 것보다 빠르게 완료할 수 있다고 가정한다. 원하는 것이 아니더라도 즉각적인 소비자의 피드백 덕분에 모든 것을 재 작업하는 일은 일어나지 않는다.

(2) XP(eXtreme Programming)

모호하고 빠르게 변하는 요구사항을 가지고 일을 하는 중소규모 팀을 위한 경량화된 방법론

문서화 작업을 최소화 -> 코드를 작성하면서 잘못된 부분을 직접 발견하고 수정하면서 비용을 최소화

XP의 특징

(i) 5명에서 10명으로 구성된 프로그래머가 고객과 함께 한 장소에서 일한다

(ii) 개발은 점진적으로 자주 이뤄지고 각 단계마다 산출물의 기능을 덧붙여 나간다

(iii) 요구사항 정의 시에는 사용자가 요구하는 새로운 기능을 스토리 형태로 구체적으로 작성한다

(iv) 프로그래머는 엄격한 코딩 규칙을 준수하고 짝(pair)를 이뤄 일하며 단위테스트를 실시한다

(v) 요구사항, 아키텍처, 디자인은 프로젝트 중간에 언제든지 발생한다

XP의 핵심가치: 의사소통, 단순성, 피드백, 용기, 존중

XP의 practices

(i) 함께 앉기: 관리자와 팀원이 함께 앉기, 공동체라는 생각과 격의 없는 대화가 꾸준히 일어나는 곳

(ii) 하나의 팀: 여러 프로젝트를 동시에 수행하는 것 금지

(iii) 정보를 제공하는 작업공간: 시각적인 환경 -> 모든 스토리를 한눈에 볼 수 있도록 벽에 전시

(iv) 열정적인 작업: XP로 일하는 동안은 개인적인 업무나 사적인 일을 고려하지 않는다

(v) 짝 프로그래밍: 코드와 테스트 케이스에 대해 즉각적인 피어 리뷰 -> 좋은 품질의 코드생산

(vi) 스토리: 유동적, 정의된 이후 구현을 하는 동안 수정될 수도 있고 우선순위 변경도 가능

(vii) 주 단위 주기: 개발상황은 주단위로 평가

(viii) 사분기 주기: 주제, 서사, 릴리스, 주요산출물 등 막대한 노력이 필요한 작업들은 사분기 단위로 계획, 사분기는 업계에서 성과나 측정을 위해 지금도 사용하고 있는 단위

(ix) 느슨함: 고도의 생산성을 요하는 프로세스에서 약간의 느슨함은 팀웍과 인간미 유지에 도움

(x) 10분 빌드: 10분 안에 전체 시스템을 빌드하고 테스트 할 수 있어야 함

(xi) 지속적인 통합: XP에서 모든 변경사항은 몇 시간 이내, 최소한 하루 이내에는 통합되고 테스트되어야 한다

(xii) 테스트 우선 프로그래밍: 코드를 작성하기 전, 실패할 테스트 케이스를 먼저 작성

(xiii) 점진적 설계: 지나치게 복잡하게 설계된 부분을 찾아 재설계하고, 코드를 리팩토링한다. 그리고 자동화된 테스트를 다시 한번 수행한다.

(3) 스크럼

스크럼의 특징

(i) 소규모의 기능협업 팀들은 30일간의 제품 릴리스를 점진적으로 수행하는 개방된 환경에서 모여 함께 일한다. 이 기간을 스프린트라고 한다

(ii) 팀은 스프린트의 목적을 달성하기 위해 스스로 방향을 잡고 권한을 갖는다

(iii) 스크럼 마스터가 팀웍을 북돋운다. 스크럼 마스터는 기술적인 방향은 제시하지 않지만 스크럼의 핵심 원리를 강화하고 방해요인은 제거한다

(iv) 각 스프린트의 우선순위를 정의하는 제품 백로그를 통해 작업을 구성한다

스크럼에서의 역할

(i) 제품 책임자: 고객의 의견을 대변하고 팀에 관련된 이해관계자의 관심사항을 표명하는 책임을 갖고, 제품 백로그를 관리한다

(ii) 스크럼 마스터: 팀이 목표를 성취하도록 돕고, 팀원 모두에게 스크럼을 지도하며 스크럼 활동과 규칙을 이행하도록 이끈다

(iii) 팀: 기능을 구현한다. 팀의 구성원은 업무를 정의하고 분배, 관리하는 작업을 스스로 진행하며, 다른 사람과 수행업무를 교환하고 협업한다

스크럼의 기본원리: 경험적 프로세스 제어

반복적으로 수행되는 프로세스에서 만족스러운 품질의 산출물을 만드는 것을 정의된 프로세스 제어라고 한다. 프로세스 진행 중 예측 불가능해서 계획과 예측으로 이뤄진 ‘정의’를 통한 접근법의 사용이 어려운 경우, 측정과 조정으로 이뤄진 ‘경험’을 이용하는 접근법을 선택하는 것이 바람직

(4) RUP

래셔널 소프트웨어 사(현재는 IBM의 래셔널 소프트웨어 사업부)에서 상용으로 개발한 프로세스와 프로세스 프레임워크

반복적이고 점진적인 개발방법론에 기반한 소프트웨어 개발 프로세스이자 프로세스 프레임워크

주요특성

(a) 4가지 생산단계: 개념화(inception) – 정교화(elaboration) – 구축(construction) – 전이(transition)

(b) 소프트웨어 개발방법론과 여러 소프트웨어공학 활동을 제공하여 소프트웨어 개발에 필요한 주요 분야들을 다룬다

(d) 점진적이다. 각 반복은 이전 반복단계에서 만들어진 기능 위에 덧씌워진다. 이처럼 소프트웨어 어플리케이션은 주기적이고 지속적인 피드백을 통해 진화한다.

RUP의 핵심 이론(8)

(i) 주요 위험 요소들을 조기에, 지속적으로 공략하라. 그렇지 않으면 그것들이 당신을 공격할 것이다.

(ii) 고객에게 가치를 전달해줘야 한다.

(iii) 실행 가능한 소프트웨어에 대한 지속적 관심

(iv) 프로젝트에서 변경사항에 대한 신속한 수용

(v) 초기 실행 가능한 아키텍처의 기초작업

(vi) 시스템은 컴포넌트로 구축하라

(vii) 하나의 팀으로 함께 일한다

(viii) 뒤 늦게 고민하기보다는 품질 개선을 위해 상시 노력하라

RUP의 Best Practices(6)

(i) 반복적 개발

(ii) 요구사항 관리

(iii) 컴포넌트 아키텍처 사용

(iv) 시각적 모델링

(v) 품질에 대한 지속적인 모니터링

(vi) 변경사항 확인

애자일 RUP의 변형판 –오픈 유니파이드 프로세스(OpenUP)

: 다른 프로세스에 비해 경량화된 프로세스이며, RUP처럼 반복적이고, 유스케이스(사용자 가치에 우선을 둔) 기반, 아키텍처 중심이며 RUP와 동일한 단계를 따른다.

(5) 린소프트웨어

작업공정과 재고 감축 =>정밀한 요구사항, 문서화된 설계간소화

시간 주기 단축 => 세분화된 업무단위, 스토리, 유스케이스, 더 작게 더 잦은 릴리즈

교차 훈련과 셀 기반제조 => 짝 프로그래밍과 코드 자산 공유를 통한 교차훈련

끊임없는 프로세스 개선 => 지속적인 반성과 적응

(6) 동적 시스템 개발방법론(Dynamic Systems Development Method)

고품질의 해결책을 빠르게 제시하는 것에 집중하는 프레임워크

애자일 선언문의 유럽버전

DSDM은 전통적인 가정을 거꾸로 뒤집는다: 과거 방법론이 요구사항(기능)을 확정한 후에 자원과 날짜(비용과 일정)을 측정하는 경향이 있다고 설명한다. 반면, DSDM은 기한 안에 완성하기 위해서는 자원은 고정되고 요구사항은 가변 변수가 되어야 한다. 이것은 모든 애자일의 핵심원리이고 가장 놓은 우선순위의 요구사항을 선별하고 최고 가치를 지닌 상품을 먼저 고객에게 인도하게끔 하는 원동력이다.

DSDM의 핵심원리(9)

(i) 활발한 사용자 참여가 필수적이다

(ii) 팀은 반드시 모든 권한을 위임 받아야 한다

(iii) 제품은 자주 출하해야 한다

(iv) 사업 목적에 부합하는 제품을 만들어야 한다

(v) 반복 점진적인 개발은 명확한 비즈니스 솔루션을 개발하기 위해 필수적이다

(vi) 개발 중에 일어난 변경은 모두 되돌릴 수 있다

(vii) 요구사항은 고수준의 언어로 기술한다

(viii) 테스팅은 전체 개발 주기에 걸쳐 끊임없이 진행해야 한다

(ix) 모든 이해관계자의 협력과 협조는 필수적이다

DSDM의 핵심활동

(i) 타임박스: 시작부터 고정된 완료날짜(릴리즈 날짜, 혹은 큰 타임박스)까지 팀 별로 작은 타임박스(반복)을 구성하고 이것도 고정된 날짜를 갖는다.

(ii) 모델링: DSDM의 구성요소, 아키텍처의 기반을 이룬다. 그러나 DSDM에서 모델은 가볍고 사용자 지향으로 설계된다

(iii) 프로토타이핑: 신속한 애플리케이션 개발에 중점을 두고 대규모 프로토타이핑도 지원한다

(iv) 테스팅: 전체 개발주기에 걸쳐서 테스트하는 것을 매우 중요시 여긴다. 이런 테스팅의 대부분은 사용자 기반 테스트이며, 사용자가 프로토타입을 받을 때 일어난다고 가정한다.

(v) 형상 관리: 점진적인 개발 중 일어난 모든 변경은 취소할 수 있고 빌드 정보, 테스트 스크립트, 예상된 결과 등 모든 릴리즈/프로토 타입은 재생산할 수 있다.

(7) 기능 주도 개발(Feature-Driven Development)

XP와 스크럼과는 다르고 RUP와는 유사하게, FDD는 넓은 범위와 대규모 시스템에서 개발되고 수정됐다.

FDD의 Best Practice(8)

(i) 도메인 객체지향

(ii) 기능에 따른 개발

(iii) 클래스(코드 소유권)

(iv) 기능팀

(v) 정밀검사

(vi) 정기 빌드 일정

(vii) 형상 관리

(viii) 결과의 보고와 가시성

l 애자일의 핵심요소

(i) 성공의 새로운 척도: 계획에 따른 성실한 수행 -> 변경사항에 대응하는 능력, 동작하는 코드

(ii) 관리문화의 차이: 명령과 관리(관리자) -> 리더십/협업(팀)

(iii) 요구사항, 아키텍처, 설계에 대한 접근법의 차이: 대규모로서 앞 단에서 조기수행 -> 지속적으로 드러나며, 즉시 수행

(iv) 수정된 코드와 구현활동: 모든 기능을 각 팀에서 동시에 코딩/사후테스트 -> 코딩과 단위테스트와 배포를 순차적으로 수행

(v) 테스트와 품질보증 활동에 대한 변화: 대규모, 계획적/사후테스트 -> 지속적/동시/조기 테스트

(vi) 계획과 스케줄 작성의 새로운 방법: 퍼트(pert)-계획의 평가검토기법/상세한/확정된 범위, 시간과 자원예측 -> 두 단계 계획-릴리즈를 위한 개괄단계와 반복을 위한 상세단계/일정 확정, 범위 예측

l 가장 큰 변화: 개발 범위 vs 일정 => 일정의 승리

기존에는 개발 범위가 개발 주기를 결정했으나, 반복 주기(릴리즈 수준에서 논하는 릴리즈 주기)가 범위를 결정한다.

ð 폭포수/전통적 가정: 범위는 시간을 결정하고, 범위와 시간이라는 두 변수는 모든 계획 주기와 큰 변경사항에 따라 다양하게 변화한다.

계획기반: 요구사항(고정) -> 자원, 일정

ð 애자일: 시간을 고정 -> 그에 따라 범위를 결정하도록 하므로 무엇을 만들 것인지 같은 하나의 변수만 남겨놓는다. 범위는 언제나 우선순위에 따라 결정되기 때문에, 팀 구성원은 시간이 허락하는 한 반드시 최상의 솔루션을 제공할 것이다.

가치기반: 자원, 일정(고정) -> 요구사항

*애자일의 심장: 짧은 타임박스(해당 업무를 시작해서 끝날 때까지의 일정을 정확하게 확정한 것) 내에서 동작하는 코드 만들기

정의/빌드/테스트의 각 세 가지 활동은 서로 어느 하나라도 완료되지 않으면 전체활동이 완료되지 않음을 의미

-타임박스 내에서 일하기/ 작은 덩어리로 개발하기

* 애자일 방법론이 직면하는 장벽

(i) 소규모 팀: 수백 개의 작은 팀으로 구성해 기존 조직체계에 어떻게 새로운 모델을 적용시킬 것인가?

(ii) 고객의 밀접한 참여: 수천 명의 고객을 대상으로 하는 경우, 각 고객이 원하는 것이 다르거나 특정 고객층이 목소리를 높이는 경우도 있으며, 제품 관리자가 고객의 대리인 역할을 수행한다면 변화에 따른 빠른 반복주기와 신속한 반응으로 만들어낸 세부 항목을 이끌어 낼 수 있는 훌륭한 전략적 제품관리 방법을 찾아내기란 매우 어렵다

(iii) 한 공간에서 일하기: 개발자, 제품 책임자, 테스터는 시간과 언어의 장벽이 없는 같은 장소에서 함께 일한다. 그러나 서로 다른 국가, 시간대, 언어를 사용하는 경우, 이런 상황을 해결하기 위해서 방법론과 조직 체계에 무언가 변화를 줘야 할 것이다

(iv) 서서히 드러나는 아키텍처: 시스템 수준을 다루는 아키텍트의 역할이 애자일에서 다뤄지지 않기 때문에 견고한 아키텍처 없이는 성공적인 시스템을 만들 수 없다고 생각하는 사람들은 애자일 적용에 부정적이다

(v)요구사항 분석과 문서화된 명세의 부족: 엔터프라이즈급 애플리케이션을 만들면서 한 번에 하나의 스토리만을 작업하는 것이 가능한가?

(vi)업무 문화와 물리적 업무환경: 효율적이고 잘 조직화된 엔터프라이즈에서는 팀이 일을 하고 있다고 생각 할 수 없을 것이다-열린 공간에서 일을 하고, 벽에 사용자 스토리를 붙이거나, 화이트보드가 여기저기 붙어 있거나, 팀원들이 코딩보다 이야기를 하는 데 더 중점을 두는 것처럼 보이기 때문

2부. 애자일을 확장 적용하는 7가지 팀 단위 애자일 활동

(1) 정의/빌드/테스트 컴포넌트팀 -> 프렉탈(부분이 전체를 닮는 자기유사성을 특징으로 하년 형상) 소프트웨어 유닛, 애자일의 기본 조직 단위

짧은 타임박스 안에서 동작 가능한 코드를 설계하기 위해 소프트웨어 개발에 필요한 세가지 기본 능력을 보유할 수 있도록 팀을 조직해야 한다. 첫째, 고객 대리인 역할을 하며 솔루션을 정의하는 제품 책임자. 둘째, 장애를 최소화하고 다른 프로젝트와 중복되지 않는 최소의 일정을 확보해 코드를 개발할 수 있는 팀원. 셋째, 통합테스트, 테스트 자동화와 품질보증을 할 수 있는 기능

정의/빌드/테스트의 세 가지 과정은 동시에 일어나며, 협력적이고, 쪼갤 수 없다.

(i) 기능 사일로(: 기능 중심으로 독립적으로 움직이는 조직)의 제거: 제품관리, 개발, 테스트와 QA => 관리자의 역할: 사일로를 넘나드는 팀을 조직하는 것

(ii) 애자일 컴포넌트팀의 역할과 책임:

최대 8~10명의 팀 구성: 개발자, 테스터, 제품 책임자(:애자일에서 역할 중요 – 팀과 유기적으로 스토리 작성을 돕기 위해서 자세한 세부사항 필요) + 애자일/스크럼 마스터 + 아키텍트(팀 활동을 통해 나타난다) + QA 담당자(품질에 대한 기본 채임이 개발자와 테스터에게 분담, 간과됐을지도 모를 전반적 품질 재확인) – 팀은 애자일 과정을 잘 알고 있는 애자일/스크럼 마스터나 테크니컬 리더가 이끈다. 팀원은 일반적으로 외부의 아키텍트와 QA 담당자들과 의사소통하며 팀과 컴포넌트 범위를 넘는 프로세스를 테스트한다.

(2) 두 단계 계획과 추적 -> 계획 일정주기를 짧은 시간으로 나눔

첫 번째 단계: 백로그 기반의 주제와 상위 수준의 기능들을 정의하고 이에 따른 릴리스 시리즈를 정의하는 애플리케이션 또는 제품 로드맵을 작성한다

두 번째 단계: 세밀한 계획 – 세분화하여 평가 절차를 개선하고 반복에 대해 팀이 책무를 쉽게 달성할 수 있도록 한다

애자일 계획: 대단위 릴리스 계획 + 소단위 반복 계획

(3) 반복 숙달하기

작은 타임박스 안에서 테스트된 동작 코드 전체를 개발하는 팀의 능력 -> 각 반복에서 통합된 코드는 동작이 가능하기 때문에 각 반복 단계마다 잠재적으로 배포 가능한 기능들이 추가된다

반복의 주기: XP 의 경우(1주 ~ 4주), 스크럼의 경우(30일 스프린트), RUP의 경우(2주 ~6주)

ð 1주일은 짧고, 30일은 길다 -> 2주 길이의 반복 표준화

반복 프로세스 모델:

1단계- 하루보다 짧은 기간을 가진 계획 단계: 반복 백로그 검토, 우선순위 결정, 예측

2단계- 개발 단계: 백로그 항목들을 코드로 구현하고 테스트 수행

3단계- 반복 중 추가된 내용에 대한 출하와 반복에 대한 평가 수행

일일스크럼미팅: 개발팀이 반복에서 수행해온 진행상태에 초점을 맞추는 것을 목적

(4) 짧고 빈번한 주기의 릴리스(작게 자주 릴리스 하기)

애플리케이션이 고객이나 의도된 시장 목적에 부합하는지에 대해 연속적인 피드백이 필요하다. 많은 IT업체에서는 각 반복 끝에서 소프트웨어 출하를 통해 연속적 피드백을 얻을 수 있다

일정주도형 릴리스: 고정된 일정에 맞춰 진행, 일정을 바탕으로 프로젝트의 범위 추정

기능 셋 추정: 과거 생산율로부터 개발팀이 주어진 시간에 할 수 있는 일의 양을 예측

주간 현장 리뷰 미팅: 컴포넌트팀이 전체적인 릴리스 게획을 어떻게 수행하는지 평가

(5) 동시 테스트 -> 애자일에서 모든 코드는 테스트된 코드

단위 테스트, 인수 테스트, 성능과 신뢰성 테스트는 각 반복에서 일어난다

반복이 진행되면서 발생하는 스토리에 대해 더 다양한 유형의 테스트 케이스가 개발과 동시에 작성된다. 테스트 케이스란 단위 테스트, 인수 테스트뿐만 아니라 시스템 테스트, 성능 테스트, 신뢰성 테스트를 모두 들 수 있다. 이 모두가 개발 초기에 관여된다.

단위테스트(개발자테스트): 개발자 스스로 그들이 작성한 모듈을 테스트할 코드를 작성하는 것

인수테스트: 새롭게 쓰여진 코드가 요구사항에 부합하는지 검증하는 기능테스트

컴포넌트테스트: 각 반복과 릴리스가 진행되는 동안 애자일팀은 다양한 도구를 활용해 컴포넌트 수준에서 시스템 검사

시스템과 성능 테스트: 시스템 전체의 기능, 성능, 신뢰도 검사

(6) 지속적인 통합

매일 개발자들이 만들어낸 변경사항을 정리하고, 이에 적합한 빌드 환경을 만들고, 통합/빌드/빈번한 ‘스모크 테스트(: 사전 테스팅, 뒤에 있을 본격적인 테스트 전에 쉽게 발견되면서 크게 영향을 미칠 수 있는 오류를 잡아내기 위한 테스트)’를 위해 필요한 툴들을 자동화하는 것과 같은 일들은 상당히 어려울 수 있기 때문에 지속적인 통합 역시 확장 적용하는 데 있어 많은 어려움을 야기한다

지속적 통합에서 모든 코드는 최소한 매일 시스템에 체크인된다. 빌드는 자동화되어 있고 자동 회귀테스트는 매일 이루어진다. 결함 발견 프로세스는 계속 이뤄지며 재작업과 리팩토링도 끊임없이 이어진다. 이를 통해 고품질의 코드를 더 빨리 만들어낼 수 있다.

소스코드통합 + 자동화된 빌드 관리 + 자동화된 빌드 검증 테스트 => 시스템은 언제나 동작한다!

(7) 정기적인 반성과 적응

주기적으로 팀은 좀 더 효율적인 팀이 될 수 있을지 숙고하여, 그에 따라 팀 활동을 조율하고 개선시켜 나간다

반복 회고: 반복의 목표를 시간 안에 달성하지 못한 주요 이유를 깨닫게 된다

정량적 분석- 반복의 측정지표들(팀에 할당된 스토리 카드관리, 오류개수, 테스트 케이스등)을 수집하고 보고하면서 진행, 정성적 분석- 무엇이 제대로 되었는지, 무엇이 제대로 되지 않았는지를 판단, 개선할 점이 무엇인지 브레인 스토밍- 모든 문제가 즉시 처리되지 않지만, 반복은 짧아서 머지않아 결국 모든 문제점 해결

릴리스회고: 많은 주요 이해관계자가 참여, 정량적 분석, 정성적 분석

3부. 엔터프라이즈 환경에 맞는 애자일 방법론

1. 계획된 아키텍처

각 팀들이 만든 컴포넌트들을 하위시스템으로 통합하고 이를 다시 대규모 시스템으로 통합한다면, (1) 컴포넌트 기반으로 작성돼야 하고, 각 컴포넌트는 가능한 한 독립적으로 개발할 수 있어야 하며, 체계적인 인터페이스 정의와 분명한 목적을 가져야 한다. (2) 아키텍처는 팀의 핵심 능력이 되고, 팀의 물리적 위치와 부합돼야 한다.

아키텍처: 이해관계자들의 요구사항을 포함해 사용자의 요구사항에도 부합하도록 논리적인 기술들을 바탕으로 시스템을 설명해야 한다 => 눈에 보이지는 않지만 매우 중요한 시스템의 구조와 행동 요소들이 정의돼야 한다.

XP: 소수의 스토리들과 한두 번의 반복을 통해 아키텍처 베이직라인을 구현, 시간이 지남에 따라 아키텍처가 시스템 요구사항을 지원하지 못한다면 시스템은 상대적으로 빠르게 재작업 또는 리팩토링 돼야한다(XP 프로젝트의 아키택처도 여타 소프트웨어 프로젝트에서와 같이 중요하다)

스크럼: 소프트웨어 아키텍처에 대해 특별한 언급 없음(자체적으로 조직된 팀에서 최고의 아키텍처, 요구사항, 설계가 나온다)

도메인 객체 모델링(Domain object modeling): 기능주도개발방법론(FDD)중 하나, 애자일 활동 중에서 특별하게 아키텍처 개념에 대해 설명하고 있는 활동, 동시에 많은 팀이 함께 작업할 수 있도록 프로젝트의 기반이 되는 아키텍처를 도메인 모델 구축을 통해 간단하고 효과적이면서 시각적으로 표현하기 시작한다

RUP: 아키텍처는 명명될 수 있고, 관리될 수 있다, 아케텍처는 유스케이스를 반영해서 설계되고, 리스크를 감소시키며 점진적, 반복적으로 발전한다.

2. 린 요구공학: 비전, 로드맵, 적시 정교화 => 간결하고 확장 가능한 요구사항 패턴은 대규모 팀과 대규모 시스템을 만드는 팀에 애자일의 장점을 적극 활용할 수 있게 된다

비전: 팀에게 공동 목표를 갖게 하고 시스템 전체에서 강조해야 할 주요 비기능적 요구사항 뒷받침

a) 비전 문서 접근방식: RUP기반에서 성공적, 애자일에 적용 용이, 알고 있는 것을 얼마나 이해하고 있는지 테스트하기 위해 비전 문서를 작성한다(아무리 대규모 프로젝트라도 문서는 20~30페이지 유지)

b) 진보적인 방식의 데이터 시트 접근 방식: 매우 간결하게 작성, 의사소통에 중요한 요소(매우 간결하게 작성, 보통 2페이지)

c) 백로그 접근 방식: 제품 책임자가 주의를 기울여 앞으로 발생할 작업들을 예측하고 우선순위를 고려하여 팀원들에게 프로젝트가 어떤 방향으로 가는지 알려줌

로드맵: 광범위하게 우선순위를 매긴 백로그에 따라 비전이 어떻게 구현돼야 하는지 나타냄, 릴리스 기준으로 비전을 설명하고 시간에 따라 주제와 기능을 기획하는 방식으로 제품의 로드맵 만들기. 팀은 구현 가능한 기간 안에 우선순위가 높은 기능을 구현하는데 초점을 두고 주제와 날짜를 결정해야 한다

적시 요구사항 정교화: 마지막 책임 순간(LRM)이 되어서야 상세한 요구사항 표현 -> 낭비제거

XP: 스토리, 사용자 스토리. 스토리는 고객이 작성하고, 고객이 개발자와 같은 공간에서. 지속적으로 의사소통을 같이하고 개발하는 동안 스토리에 대해 토론할 수 있어야 한다.

스크럼: 제품 책임자_ 스크럼 산출물의 핵심인 제품 백로그를 개발하고 유지

제품 백로그의 원칙: 제품 책임자에 의해 중요도, 우선순위 매갬=> 중요한 것에 대한 모호성 없음, 우선순위와 투입공수를 견주어 고객을 대신해 팀의 투자 정도를 최적화 할 수 있다 => 대규모 시스템 개발에 매우 좋은 접근방식

RUP: 유스케이스로 정교화 – 사용자 관점에서 시스템의 행동을 표현하는 일관된 표현방법, 유스케이스 안에 기술된 이벤트의 흐름을 이해하면 모든 사용자 또는 이해관계자와 관련된 논의를 할 수 있다.

3. 대규모 시스템과 애자일 릴리스 기차: 대규모 시스템에서 서로 분산되어 있는 컴포넌트팀 개발자들 사이에 의존관계를 관리하고 계획하는 것이 필수적 -> 계획적이고 중장기 릴리스 주기(3~4개월)이 필요 -> 컴포넌트를 기반으로 하는 ‘애자일 릴리스 기차’를 사용하여 애질리티, 생산성, 품질을 달성하려고 한다

대규모 회고의 결과는 모든 팀이 관심을 둘 것이고, 널리 확산될 것이다. 결과는 다음 릴리스 계획에 반영되고 이런 방식으로 대규모 시스템 릴리스에 대한 지속적인 프로세스 개선 작업이 이뤄질 수 있다.

애자일이 제품을 좀 더 빠르게 만든다면, 시장출시를 조율하는 것도 엔터프라이즈 기업의 도전 과제이다

효과적인 릴리스 계획을 수립하는 것과 대규모 시스템의 릴리스 일정을 맞추는 것은 엔터프라이즈급 애자일 프로세스을 만드는 데 있어 가장 중요한 일이다

애자일 릴리스 기차: 반복-반복-반복- 굳히기(릴리스)

기차는 동기화되어야 한다: 같은 반복일정으로 동기화 되어야 한다. 관리층은 고정된 길이의 반복에서 시작과 끝 날짜만을 지정할 수 있다. 지속적 통합이 시스템 수준에 적용되면 시스템도 컴포넌트와 마찬가지로 고객이 평가할 수 있도록 반복과 내부 릴리스를 갖게 된다.

기차가 궤도를 이탈하지 않고 일정을 준수하도록 유지하기: 스크럼 관리팀이 존재해야 한다. 기차의 일정과 모든 통합 마일스톤(전체 통합을 조절할 수 있는 중간 매체)을 결정한다, 릴리스에 필요한 공통의 요구사항과 비전을 가지고 팀과 함께 대화한다, 팀 활동을 정리할 수 있도록 릴리스 계획을 작성한다.

릴리스 관리팀은 프로젝트의 진행 상태 검토 및 진행상 장애물을 제거하고 필요에 따라 범위를 조절하기 위해 최소한 일주일 단위로 모인다. 계획 또는 범위의 변경사항에 대해 전체 팀원들과 공유할 책임이 있다.

4. 분산 개발의 관리

분산된 장소에서 발생하는 의사소통의 통합을 지원하는 환경은 팀에게 현재 프로젝트에 대한 충분한 가시적 자료를 제공하여 팀이 업무의 우선순위와 실시간 상황, 의존성을 파악할 수 있게 한다

애자일 개발의 성공 열쇠: 조직의 변화와 의사소통 장려, 분산된 팀에게 소프트웨어 개발 프로세스의 모든 부분에서 의사소통이 강조될 때 성공할 수 있다.

5. 조직변화

조직 안에 존재하는 걸림돌과 병목현상 그리고 생산성을 저하시키는 장애요소 식별

문화적 조직적 장애물: 불충분한 테스트 자동화, 시스템 수준 테스트에 대한 부족한 자원, 제품 관리에 필요한 인터페이스를 느리게 하고 방해하는 요소, 반복과 프로젝트 진행에서 고객에 대한 빠른 피드백을 방해하는 요소

스크럼과 애자일이 가진 ‘즉각 경험적으로 반응’하는 특성으로 인해 스크럼/애자일 프로세스 자체는 점진적으로 논리적인 방법으로 조직에 변화를 일으키는데 쓰일 수 있다. 이러한 프로젝트에서 경영층의 후원은 결정적인 역할을 하며, 베스트 프렉티스에 의한 리더십, 프로세스에 대한 협의와 헌신이야 말로 애자일이 엔터프라이즈 조직 전체에 가져다 주는 이익에 채워진 자물쇠를 푸는 중요한 요소이다

6. 고객과 조직에 미치는 영향

좀 더 가용성이 있는 코드와 빠른 대응이 사용자들에게 많은 영향을 줄 것이다. 또한 릴리스 계획 대비 실제 진행 상황을 파악할 수 있는 시스템과 좀더 밀접하게 사용자와 의사소통 할 수 있는 고객 접점도 필요할 것이다

애자일: 관련 마케팅 팀원에게 좀 더 지속적인 집중과 잠재적으로 높은 작업량을 주며 개발팀과 함께 의사소통을 하도록 한다.

새로운 자원과 새로운 조직구조 필요:

영업과 마케팅은 제품관리자- 제품 책임자 간의 인터페이스를 확장하여 마케팅/제품 관리 담당자를 추가할 수 있어야 한다. 가끔 새로운 팀원이 고용되거나 다른 팀원이 추가될 수 있다.

개발팀원들 역시 제품 특성, 하위시스템 컴포넌트에 대한 제품 책임자 또는 요구사항 분석가로서 역할을 수행할 수 있는 준비를 해야 한다. 또한 영업 또는 마케팅 팀원과 함께 지속적으로 의사소통 해야 한다

7. 비즈니스 성과 측정

경영진이 그들의 목표가 지속적으로 향상되고 있는지, 추가적인 진척이 필요한 곳은 어디인지를 알 수 있는 무엇인가를 만들어낼 필요가 있다

큰 수준의 문제를 다루기 위한 설득력 있는 측정 지표 셋: 균형성과기록표(BSC, balanced scorecard) – 효율성(R&D조직이 현재 조달성, 생산성, 수익성, 비용 목표에 부합하는지에 대해 평가), 가치 조달(측정기간(12개월)동안 고객에게 전달된 소프트웨어의 가치측정), 품질(고객의 환경에 맞게 결정된 제품에 대한 품질 측정), 애자일(차기 성능 목표를 위한 개선되고 이뤄야 할 조직의 능력 평가)

대기업을 위한 유연하고 자동화되고 의미 있는 BSC의 구현:

1단계- BSC 항목 수치화: 0-100사이의 점수를 갖도록 데이터 수집

2단계- 알파벳 점수로 변환: A-F; 표의 각 항목이 한 관점의 평가를 의미하고, 그 관점은 더 수치화된 상세 항목으로 자세히 알아볼 수 있기 때문에 팀은 무엇을 향상시켜야 할지 알 수 있다

3단계: 제품라인, 비즈니스 부서, 대기업에 대한 결산

Sustainable Software Development - an agile perspective by 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:

over or under design
code first then fix defects later(code-then-fix)
too many dependencies between code modules
the lack of safeguards such as automated tests
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

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
Managers must recognize that they have a key role in leading the attitude of the organization.
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
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.

our software worked every day.
we relied heavily on automated testing to catch problems while we were working on new features.
we had high standards onf testing and code quality, and we held each other to those standards.
we didn't overdesign our work and built only what our customeres needed.
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.
we replanned our work as often as we could.
we were always looking for ways to improve how we worked and our software.

agile paper

Wed, 20 Jan 2010 15:24:35 +0900

Evaluate XP Effectiveness Using Simulation Modeling

(Alessandra Cau, Giulio Concas, Marco Melis, and Ivana Turnu)

Introduction :

Few studies about XP have been published that provide quantitative results and these are empirical studies, which are extremely costly to perform and for which it is virtually impossible to achieve a high degree of completeness. Therefore, the use of Simulation to estimate and qualitatively verify the effectiveness of a particular development process represents an alternative solution.

We developed a simulation executive to enable simulation of XP software developement activities. The model follows an object-oriented approach and has been implemented in Smalltalk language, following the XP process as well. It is able to vary the usage level of some fundamental XP practices(Pair programming, Test-first Programming), and to simulate how the modelled project entities evolve as a result.

Related Work :

Using the System Dynamics(SD)

Cao(2004)
Misic et al.(2004)
Kuppuswami et al(2003 a, b)

An Exteme Programming overview :

(1) Empirical Studies on Pair Programming

(2) Empirical Studies on Test-first Programming

The Simulation Modelling Approach :

The system was developed using Smalltalk object-oriented language. Smalltalk is one of the firtst object-oriented lauguages, it is easy to use, powerful and achieves high developement productivity levels and it is closely related with XP. WIth regard to the specific simulation technique, we followed a hybrid approach merging Discrete Event Simulation(DES) ans System Dynamisc so as to exploit the advantages of both.

Model Description :

Our model developement was based on the gollowing assumptions;

User Stories are independent from each other. For this reason, the code needed to implement a specifics user requirement is associated to one and only User story.
User Stories are not split into engineering tasks, as normally happens in an XP approach. It was not considered neccessary for the scope of this model.
The developement team remains the same throughout the project. Turnover was not considered.
Problems/defeats are only found and committed at the end of a release.

Debugging activites do not add any other code and defeats to the system.

Calibration and Validation :

We cite two XP projects where tracking activity has been conducted systematically and where the data available are sufficiently detailed : Repo Margining System project(KlondrikeTeam 2000) and Market Info(Bossi 2003a, b)

We hypothesized that the estimation error decreases according to the specific team's experience. This hypothesis is used to choose the input project parameter. M@Info team was more experienced than the Pepo Margining team. We observed that the average velocity of a single developer of the M@Info team was 16% higher than a developer of the Repo Margining team. So, we decided to decrease the average estimation error by the same percentage.

Results :

Our research hypothesis were as follows;

Hypothesis A : The residual defect density of the project using and or PP and TDD is different from that obtaioned without PP and/ or TDD.

Hypothesis B : The number of working days needed to complete the same number of functionalities using and/or PP and TDD is different from that without PP and/ TDD.

Hypothesis C : The number of lines of code needed to implement the same number of functionalitis using and/or PP and TDD is different from that without PP and/ or TDD.

Hypothesis D : The numner of released User stories using ans/or PP and TDD is equal to that without PP and/or TDD.

Conclusion :

We found that increasing the usage of PP and TDD significantly diminishes product defectiveness. On the other hand, the results showed that greater effort, in terms of working days, was required to implement the same functionalities. To obtain a similar level of project quality, the time needed to complete the same number of functionalities increased significantly when these practices were not adaopted.

soonsam님의 노트

Thu, 09 Jul 2009 11:52:34 +0900

We are...

우리 그룹의 소개를 적어주세요.

Notice

주요 페이지
멤버 소개
가입안내
공지사항

주요 페이지

카테고리1	카테고리2	카테고리3

멤버 소개

멤버 소개 보기

공지사항

공지사항 내용
공지사항 내용
- 덧글