目前分類:Agile Concept (204)

瀏覽方式: 標題列表 簡短摘要
如何找出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) 人氣()

如何找出Legacy Code中的Bad Smells

Smells Like Legacy Code
http://www.testearly.com/2006/12/14/smells-like-legacy-code/


如果你要知道你程式碼中的健康狀態, 你要如何檢查呢?

就像身體健康檢查一樣, 你必要知道你想檢查哪些問題(肝臟, 心臟或是過敏等等), 接著再看有哪些index可以呈現相關的狀態, 然後健檢人員會使用工具來做檢查, 最後你就會拿到一堆數據, 並且告訴你在哪個範圍內是好的, 還是有問題的. 如果真的是有問題, 醫生還會告訴你, 要做什麼事情會讓情況好轉.

對於程式碼也是一樣的, 你要先知道你想看的bad smells是什麼, 接著就看有怎樣的index, 可以表達目前的狀態如何. 然後你就用一些tools來parse source codes, 看看它的狀態如何. 如果不是很好, 這時候一些refactoring 或是design pattern, 便可以來應用看看.

作者列了三個samples讓大家看看, 並且告訴大家說他已經開始收集這些資料, 希望他功能圓滿的那天, 可以分享給我們知道.
1.
Smell: Conditional Complexity
Measure: Cyclomatic Complexity
Tools: IDE, CCMetrics, Source Monitor, JavaNCSS, Eclipse Metrics
Refactoring: Extract Method, Extract Class, Replace Conditional with Polymorphism
Pattern: Abstract Factory, Strategy

2.
Smell: Long Method
Measure: Number of Lines in Method
Tools: IDE, PMD, Eclipse Metrics, CheckStyle, Source Monitor, FxCop
Refactoring: Extract Method
Pattern: Abstract Strategy

3.
Smell:
Measure: Depth of Inheritance (DIT)
Tools: IDE, PMD, Source Monitor
Refactoring: Replace Inheritance with Delegation, Pull Up/Push Down Method
Pattern: Delegation



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

當你遇到"程式碼就是文件"時, 要如何進行測試

Testing when "the code is the documentation"
http://blogs.msdn.com/joshpoley/archive/2008/09/03/testing-when-the-code-is-the-documentation.aspx

作者說在他工作生涯中, 經常聽到這個可怕的聲明: code is the documentation. (我常聽到的則是, 沒有改什麼, 或是這次需求很簡單, 所以不需要文件). 不管背後的原因是什麼, 反正你就是不會拿到任何文件, 來說明這個系統是如何運作. 當然啦, 拿到一份過時的文件, 也是同樣的慘狀.
(記得當年第一次看到"code is the documentation", 覺得真的很好笑, 不想寫文件就不想寫文件, 還可以用這麼有學問的方法來描述)

當作者遇到這種狀況時, 通常會利用以下模式來處理. (分成四個階段)

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

Agile is All About Feedback

http://www.io.com/~wazmo/blog/archives/2008_08.html#000285

這是Bret Pettichord寫的一篇文章, 道盡了Agile的精髓. 我之前雖然有隱約這樣想過(有點馬後炮), 但是看到這篇文章之後, 覺得深深大獲我心. 在此整理了 一下, 跟大家分享

1. Agile methods allow your team to get feedback regarding the software you are building.
(1) The feedback works on several levels.
    - Pair programming gives developers instant feedback on their code.

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

Close

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

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

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

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

reload

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼