Agile 的衰敗緣由

The Decline and Fall of Agile
http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

我想很多人一定讀過"The Art of Agile Development", 它是一本很紅agile 書籍, 在Amazon上有四顆半的評價. 可是作者在2008年11月時, 寫了一篇文章談Agile的誤用與衰亡.

雖然Agile現在似乎是當紅, 可是作者卻唱衰地說, Agile可能在幾年後走向敗亡的道路.

因為剛開始時, 別人都是要做這去教他們怎麼用agile, 可是現在卻是叫作者去救急. 因為他們apply agile後遭遇到很多問題. 像是無法meeting iteration commitments, a lot of technical debt, 和測試要花很長的時間等等.

甚至有同行還笑稱 "Rescuing Scrum teams keeps me in business". 聽起來很糟, 但卻是事實.

所以作者覺得 agile這行應該快有問題了, 尤其Scrum讓這種情況更加惡化

以下是作者認為Agile失敗的原因如下

(1) Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design.
- Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement.
- Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt.

(2) People just adopt rapid cycles(Sprints and Scrums), but none of the good stuff that makes rapid cycles sustainable.

(3) People aren't working in shared workspaces or emphasizing high-bandwidth communication.
- They're don't have on-site customers or work in cross-functional teams.
- They don't even finish all of their stories by the end of each Sprint, let alone deliver releasable software, and they certainly don't use good engineering practices.

(4) People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work.

我認為是這就像王安石變法一樣, 立意雖佳, 但是若是執行的人不佳, 結果還是不好的. 這也樣當初在推OO一樣, 都是表面上像OO, 但是內部精神上並沒有把原汁原味給做到位.

作者寫完後, 目前已有133人給他feedback, 我想這是很驚人的回應. 很值得大家去看看, 尤其是你現在run agile, 特別是Scrum的人, 好好小心是否自己也有相同的問題.

kojenchieh 發表在 痞客邦 留言(0) 人氣()

什麼是Definition of Done (DoD)?
What is Definition of Done (DoD)?
http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

Definition of done (DoD) 對一個Scrum的team來說非常的關鍵, 因此你必須要和team找出你們共同的DoD出來. 以下是DoD所擁有的特性, 和你的team檢查看看, 是否你們都有注意這些重點


1. DoD是檢查它們完成程度的checklist
- A simple list of activities that add verifiable/demonstrable value to the product.
- Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts.
- For example: writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.


2. DoD 對team members來說, 它是主要的reporting mechanism
- Reporting in its simplest form is the ability to say, “This feature is done.”
- DoD is a simple artifact that adds clarity to the “Feature’s done” statement.  
- Using DoD as a reference for this conversation a team member can effectively update other team members and the product owner.


3. DoD 是根據現實狀況來回報的
(1) Scrum asks that teams deliver “potentially shippable software” at the end of every sprint.
- Potentially shippable software is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion.
- Ideally, potentially shippable is equivalent to the Definition of Done.

(2) In reality, many teams are still working towards a potentially shippable state.  Such teams may have a different DoD at various levels:
- Definition of Done for a feature (story or product backlog item)
- Definition of Done for a sprint (collection of features developed within a sprint)
- Definition of Done for a release (potentially shippable state)

(3) There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release.  
- Ultimately, the decision rests on the answer to the following three questions:
    Can we do this activity for each feature? If not, then
    Can we do this activity for each sprint? If not, then
    We have to do this activity for our release!

(4) Teams should, “Discuss all of the obstacles which stop them from delivering this each iteration/sprint”. Common root causes for impediments include:
    - Team does not have the skillset to incorporate activities into the definition of done for a sprint or for a feature.
    - Team does not have the right set of tools. (Example: continuous integration environment, automated build, servers etc.)
    - Team members are executing their sprint in mini-waterfalls.
    - Aha! Here’s an opportunity to be more cross-functional and share responsibilities across functional silos.


4. DoD 不是一成不變的
- The DoD changes over time.
- Organizational support and the team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints.


5. DoD 是一份auditable checklist.
- Features/stories are broken down into tasks both during sprint planning and also within a sprint. The DoD is used to validate whether all major tasks are accounted for (hours remaining).
- Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist.
- The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis.


kojenchieh 發表在 痞客邦 留言(0) 人氣()

如何找出Definition of Done (DoD)?

"Done"這個東西, 常常是每個role有自己的想法, 因此這裡常常是誤解的根源. 而在Scrum中, 它是非常關鍵的一個要素, 特別強調大家對"Done"這東西, 要有一致的認知. 這樣每個iteration的進行才會更有效率, 更能確認是否真的滿足customer的需求.

這裡我看到一個blog上寫著, 他們team如何來找出DoD的步驟:

Step 1 – Brainstorm:
- Take a Pen and Sticky Note pad
- Write on the sticky notes what they believed was part of achieving the objective written on the whiteboard
- Place the sticky note in the centre of the table and read out aloud their idea
- No idea is to be criticized!

Step 2 – Categories
- Discuss what categories should be used to facilitate our DoD
- Category Example:
    a. Release
    b. Sprint
    c. User Story

Step 3 – Categorise
- Take the sticky notes from the table and place them into the categories

Step 4 – Sorting:
- If we believed that two or more ideas where similar or overlapped.  We overlap the sticky notes.
- Where ideas no longer seem valid, has lost their context or simply made no sense we move these to another area outside of the categories.

Step 5 – Review:
- Review each of the sticky notes to analyse the meaning
- Query if the idea was required to be done?  Is it in the correct category?
- The definitions could be rewritten and consolidated after dicussion

Step 6 – Document:
- You could place a printed version in the team work space or project wiki


這裡我收集了一些DoD的定義, 來供大家參考.

(1) User Story 做完的定義
Example 1:
   A. All story should have automated acceptance test.
   B. The story should have working code supported by unit test that provide around 60 - 70 percent coverage.
   C. The story should have well defined acceptance criteria.
   D. The code must have been written as a pair or should be code reviewed.
   E. Code must be completely checked in to the source control system and the build should pass with all the automated tests running.
   F. The product owner must accept the story.
Example 2:
    A. All tests for acceptance criteria identified, written, tested and passed
    B. Unit tests for story written and passed
    C. Continuous integration build is working with checked-in source code
    D. All source code for user story checked-in to source control
    E. Completed all tasks associated with user story
    F. Code coverage of 80% achieved
    
(2) Sprint 做完的定義
Example 1:
   A. Product owner should have defined a sprint goal.
   B. All stories completed for the spring must be accepted by the product owner
   C. All the automated acceptance tests should be running for the stories in the sprint.
   D. All code should have been pair progrmmed or must have gone thorough a code review process.
   E. If there is a database involved, the database scripts must have been automated and tested.
Example 2:
    A. All automated tests passed
    B. Documented all user stories completed in sprint
    C. Regression testing passed
    D. Done all agreed user stories
    
(3) Release 做完的定義
Example 1:
   A. Product is deployed to the test box and makes it to staging
   B. Product has a formal release date.
   C. There are deployment documents for the release
   D. Training manuals are available for users.
   E. All stories for the release are completed and accepted.
   F. The release does not have any level one bugs.
Example 2:
    A. User documentation written and delivered
    B. Create branch for release and deploy from it
    C. Deliver source code to client
    D. Pass FX Cop(a free static code analysis tool) to appropriate level


Reference
1. What is definition of done?  
http://agilefaq.net/2007/10/24/what-is-definition-of-done/
2. Definition of Done?
http://blogs.imeta.co.uk/CSkipper/archive/2008/10/21/459.aspx

kojenchieh 發表在 痞客邦 留言(0) 人氣()

Agile Testing要成功的7個關鍵要素

Teaching Values vs. Process
http://lisacrispin.com/wordpress/?p=82

最近這個project要開始run agile. 因此小弟不遺餘力在加強agile的knowledge. 這裡"Agile Testing"一書的作者提出了, agile testing要成功的7個關鍵要素, 請大家享用

1. Use the whole-team approach.
- The whole development team must commit to producing high-quality software that delivers maximum business value.
    
2. Adopt an agile testing mind-set.
- We have a chapter in the book with “Ten Principles for Agile Testers”, and explain that an agile testing attitude is proactive, creative, open to new ideas, and willing to take on any task.
    
3. Automate regression testing.
- Without automated regression tests, the team will fail in the long run, because there won’t be time to do adequate exploratory testing, much less to do all the manual regression tests as the product grows.
- This is really a practice, but its root is in the value of feedback.

4. And feedback is our next success factor
- Provide and Obtain Feedback.
- Feedback is a core agile value, and testers are in a prime position to help provide the feedback that keeps the team on course.

5. Build a foundation of core practices.
- Again, these are practices such as continuous integration and working incrementally, but they are rooted in core agile values such as simplicity, communication and feedback.

6. Collaborate with customers
- Another core agile value.

7. Look at the big picture
- Another strength of testers.
- Even code produced test-first may cause unintended results in other parts of the system.
- Testers help the team evaluate how each story fits into the larger system.


kojenchieh 發表在 痞客邦 留言(0) 人氣()

什麼一個好的User Story?
- form User Stories Applied: For Agile Software Development

好的User Story會具備哪些要素:
- Independent
- Negotiable
- Valuable to users or customers
- Estimatable
- Small
- Testable

Independent
(1) Avoid making dependencies between stories
- Hard to prioritize and plan
(2) Instead,
- Combine dependent stories
    If the combined story is longer, it is usually to find a different dimension along which to split the stories
- Split in another way
(3) Example
- 你可能會寫出這樣的user story
    A company can pay for a job posting with a Visa card.
    A company can pay for a job posting with a MasterCard.
    A company can pay for a job posting with an American Express card.
- 改成這樣會比較好
    A company can pay for a job posting with a credit card
    
Negotiable
(1) User stories are not written contracts
- Story cards are short descriptions of functionality
- The details are to be negotiated in a conversation between the customer and the development team
(2) Consider them placeholders/reminders for a conversation you should have
(3) Consider what is the right amount of information written in a user story
(4) Details that have already been determined through conversations become tests.
- Tests can be noted on the back of the story card or
- in whatever electronic system is being used
(5) Example:

Valuable to users or customers
(1) Stories with value for the user is a given
(2) Remember stories for the customer
(3) Avoid stories that have only value for the developers
- Rewrite them so they have value for the customer
(4) The best way is to have the customer write the stories.
- Ensure that each story is valuable to the customer or users
(5) Keeping in mind the distinction between user and purchaser
- These stories might be only valued by purchasers
    Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit.
    The development team will produce the software in accordance with CMM Level 3.
- These stories might be only valued by users
    Each of the 5,000 computers is using the same configuration for the software.
(6) Find business values, not technology and the advantages to the programmers
- Examples:
    All connections to the database are through a connection pool.
    All error handling and logging is done through a set of common classes.
- Better examples:
    Up to fifty users should be able to use the application with a five-user database license.
    All errors are presented to the user and logged in a consistent manner.

Estimatable
(1) Without estimates, no plan
(2) Typical reasons why a story is hard to estimate
- Developers lack domain knowledge
- Developers lack technical knowledge
- The story is to big

Small
(1) Size matters
- Wrong size makes planning hard
(2) No definitive answer to size
(3) Faced with too large a user story see if it is
- A compound story
- A complex story
(4) A compound story
- Epic that comprises multiple shorter stories
- What does the user story: “A user can post her resume” mean ?
    It should be split
- But not to small…
- CRUD operations can work as guidelines
(5) A complex story
- Cannot easily be disaggregated
- Stories are often complex because of uncertainty
- Split in two stories
    An investigation store
    A development story

Testable
(1) Stories must be written so as to be testable.
- Successfully passing its tests proves that a story has been successfully developed.
(2) If a story cannot be tested, how can we know when we are done coding ?
(3) Un-testable stories commonly show up for nonfunctional requirements
(4) If possible, make test automated


kojenchieh 發表在 痞客邦 留言(0) 人氣()

Close

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼