目前日期文章:200903 (31)

瀏覽方式: 標題列表 簡短摘要

如何開始進行Test Automation

How to catch up on test automation

03, Jan, 2008
Posted by Henrik Kniberg

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

Burndown Chart的好處和用途

Questions About Burndown Chart

February 21, 2009
Posted by Jimmy Zhao
Published in Dig Knowledge Everyday

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


Comfortably Scrum: How Scrum Are You?

January 26, 2009
Posted by 
Published in Tommy Norman's blog

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

十件你所不知道有關Agile Development的事

March 2009
Posted by Jeffery Oayne
Published in Better Software

1. 敏捷才是目標
- The debate about what development practices practices are or are not agile is moot

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

幫助做Cross Browser Compatibility Test的工具

7 Fresh and Simple Ways to Test Cross-Browser Compatibility

February 25, 2009
Posted by Mason Hipp
Published in freelancefolder

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


最近有人提到test cases太多run不完, 找到bug太多RD解不完, automation rate太少, 高層總是schedule導向, 因此導致整個QA的工作很忙, 士氣也不高.

我想這些都是QA常見的問題, 不過我想換個角度來思考這些問題:

1. Test cases太多run不完

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

要進行Test Automation時, 其可能的組織架構為何?

最近有人請我和他們團隊, 一起討論如何開始進行test automation. 這真是一個很大的題目, 實在不容易回答

這裡我提供了一些想法, 有關於test automation常見的組織結構:

Organization 1
A. Role
 - Only limited dedicated test developers do test automation programs

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


GUI test automation is not child's play

March 12, 2009
Posted by Bj Rollison
Published in I. M. Testy

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

在面試Automation 和Load testing相關經驗時可以問的問題

Automation Q & A

Posted by Thiyagarajan Veluchamy
Published in Thiyagarajan Veluchamy's BLog

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

如何利用Microsoft Hyper-V來進行自動化測試

Automating Software Testing with Microsoft Hyper-V

Posted by Jani Jarvinen
Published in Developer.com

每次在作測試時, QA很大的effort是在準備環境, 不但要乾淨的環境, 還要各式各樣的環境, 所以常讓QA覺得生命為何要浪費在這樣無意義的事情上.

因此當VMWare出來時, 讓software testing看到了一道曙光. 尤其它提供了API,讓你可以自動化這些流程時, 更是讓QA高興的不得了.

就在這時候, Microsoft也不甘示弱, 也加入這場戰場, 推出了Virual PC, 之後還有Hyper-V. 現在推出了Hyper-V Server 2008, 和VMware的 ESXi很像, 它是一個免錢的軟體.

因此有了Hyper-V Server 2008, 再加上Visual Studio Team Foundation Server (TFS) 和 Team Build 的功能, 你就能做到 one click, 就能將compile, deploy和testing畢其功於一役.

這裡有篇介紹如何使用Hyper-V來做自動化測試的文件, enjoy it!!

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

IDEO 的相關資料

公司花了十萬元讓我們去上Innovation workshop, 回來之後, 老闆要我們給個交代, 希望能介紹一下, 這堂課的賣點在哪裡. 因此花了一些時間, 整理了一些有關IDEO的相關資料, 發現真是多到不行, 看起來要花好多時間用功一下, 否則Steve問起來, 可是會丟臉的.

1. IDEO系列文章
From 美感經濟與風格社會的對話 - http://www.aestheticeconomy.com/blog/

IDEO系列 1 : 創新 + 美學 = IDEO

IDEO系列 2 : 從 IDEO 到 McKinsey 的觀察:設計的力量,挑戰管理權威

IDEO系列 3 : 從設計到管理的觀察: 讀IDEO的「決定未來的10種人」

IDEO系列 4 : 當設計思考者,不需科班畢業

IDEO系列 5 : 設計思考,始終來自於人性

IDEO系列 6 : 51種啟發創新思考的方法 (IDEO Method Cards)

IDEO系列 7 : 誰讓哈佛商業評論與美學經濟俱進

IDEO系列 8 : 關於設計思考的五個問題

2. Inside IDEO
美國ABC廣播公司的Nightline對IDEO所製作的特別節目, 該報導除了一般性的介紹了IDEO之外, 還請IDEO組成一個團隊, 在數日之內進行購物推車設計專案, 展示他們的設計流程, 風格與方法。

Part I
Part II
Part III

3. Useful Articles
a. 四大拼圖,拼出世界頂尖設計版圖

b. IDEO 方法圖卡的認知組織

c. 六大原則:SUCCESs 清單──原則五:情緒

d. IDEO創新的3個秘訣

e. IDEO設計公司 - 美國設計公司的演變與地緣特質

f. Design Thinking. 從產品設計到創意顧問的IDEO

g.  IDEA物語

h. Bill Moggridge:Service Design

4. Web Site
a. IDEO Labs
IDEO 開了一個 Blog,這個 Blog 叫做 IDEO Lab,比較有趣的是,它們的 Lab 的第一個計畫竟然是做 Multitouch。

b. IDEO Web Site

5. Books
a. The Ten Faces of Innovation: IDEO's Strategies for Defeating the Devil's Advocate and Driving Creativity Throughout Your Organization
by Thomas Kelley (Author), Jonathan Littman (Author)

b. The Art of Innovation: Success Through Innovation the IDEO Way
by Thomas Kelley

c. Designing Interactions
by Bill Moggridge

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


Disadvantages of Agile Software Development

Posted by Kelly Water
Published in All About Agile

作者說不要懷疑他, 他是道道地地Agile的fan.

雖然Agile有很多好處, 但是他也是一定有不少缺點

所以當你在採用Agile時, 你一定要知道他當初要解決的問題是什麼, 或是為了達到什麼目的. 這樣你才可檢查這樣的東西是否適合你, 你也才知道一些trade-off.

這裡是作者列出一些, 在agile中不錯的practices, 但是它卻帶來一些問題:

1. 在開發過程要求顧客積極加入及緊密合作
- However these principles are very demanding on the user representative's time and require a big commitment for the duration of the project.

2. 在開發過程, 需求會逐漸浮現及演進
- There are two big flip sides to this principle though.
    * One is the potential for scope creep, which we all know can create the risk of ever-lasting projects.
    * The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver.
- This can make it harder to define a business case for the project, and harder to negotiate fixed price projects.
- Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.

3. 簡潔的需求就已經足夠了
- However this can mean less information available to new starters in the team about features and how they should work.
- It can also create potential misunderstandings if the teamwork and communication aren't at their best, and difficulties for team members (especially testers) that are used to everything being defined up front.
- The belief in agile is that it's quicker to refactor the product along the way than to try to define everything completely up front, which arguably is impossible.
- And this risk is managed closely through the incremental approach to development and frequent delivery of product.

4. 測試是被整合到整個開發過程
- However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project.
- This does have the effect of reducing some very significant risks, that have proven through research to cause many projects to fail.
- The cost of a long and unnpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs.
- However there is an additional cost to the project to adopt continuous testing throughout.

5. 經常交付產品給客戶
- The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project.
- This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.

6. 綿密的iterations/sprints
- Finally, common feedback is that agile development is rather intense for developers.
- The need to really complete each feature 100% within each iteration, and the relentlessness of iterations, can be mentally quite tiring so it's important to find a sustainable pace for the team.

不知各位看倌, 你覺得這些是否也是你的問題?

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


The Power of a Whiteboard

Posted by Kelly Water
Published in All About Agile

Agile的開發團隊通常使用一些low-tech, 手動的方式來追蹤他們的工作.  像是用便利貼來記載工作項目, 用手繪的burndown chart, 或是用手繪的architecture等等

你或許會很好奇, 像這樣高科技的產業, 應該有一堆現成的project management tools, 或是一些為特定目的所建造的工具可以使用, 會何會用這樣low-tech的方式呢?

作者認為白版提供很多好處, 是這些軟體工具所比不上的.

1. 白板讓大家都看得見
- When you see something in print, somehow it seems more real. I guess because it's physical.
- A large number of post-it notes on a whiteboard looks like a lot of work.
- You can show some information like: Sprint Status, Burndown Chart

2. 白板有著無限的彈性
- You can put literally anything you like on it.
- Unlike an electronic system, there are never any constraints.

3. 白板可以快速, 有效的被修改
- You could completely reoarganise a set of cards in just a few moments.
- Or sketch something important in seconds.

4. 讓你覺得有形的
- For people that like tactile, it feels good to move a card to done.
- You feel a sense of ownership when you pick up a card.

5. 它也讓你感到很新穎, 新奇的
- When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look.
- The whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.

6. 白板提供一個可以一起合作, 一起討論的地方
- It's a focal point.
- Like a campfire in days gone by. Or a fireplace in your lounge.
- Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design.

7. 在白板上, 不同團隊會呈現出不同的文化
- The team can express itself through the things it puts on its whiteboard.
- It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.

作者也提到他並不是反對使用工具, 只是他認為工具是用來輔助白板, 而不是取代它. 有些事情是白版無法做的, 像是keeping track of longer lasting information, doing calculations, searching等等.  

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

招募SDET來當QA是必要的嗎? 正確的嗎?


尤其是你在掙扎, 是否要效倣Microsoft hire大量的SDET來做QA的工作時, 這裡提出了不同的見解, 提出了這樣的作法的盲點在哪裡.

此外在後面, 作者和James Bach所提到QA和RD想法上的差別, 我想是非常一針見血的見解. Enjoy it

What's an SDET - II

March 06, 2009
Posted by Matthew
Published in Creative Chaos

我想很多人都看過"The art of software testing", 在書中最有名的例子, 是測試一個三角形的程式. 讓我先回顧一下這個題目

有一個程式, 會讀入三角形的三邊長, 然後會輸出這個三角形是何種三角形. 比如說, 正三角形, 等腰三角形, 一個普通的三角形, 和不是三角形等等.

作者認為, 書中的回答是非常RD style的答案, 為什麼呢? 作者解釋如下:

作者認為如果你只是注意input 和expected results, 那你心中只看到這樣的東西

my $triangle_type = get_triangle_type($sidea, $sideb, $sidec);

- The basic equivalence classes,
- The boundaries,
- Maybe measure statement coverage - maybe even branch coverage,
- Perhaps have a bunch of negative tests like entering words instead of numbers,
- A "length" of a negative number
- In the days of MS-DOS where you had a single user sitting at a single computer typing in one value at a time, that might be just fine.

但是作者認為, 在現在的環境中, 只做對了一半. 因為通常我們的程式, 會放在web上執行, 或是做成 web service讓別人呼叫. 因此你可能還需要考慮以下問題

- Does it render correctly in all browsers? IE6, IE7, FF2, FF3, Safari?
- Does it look pretty? Is the user interface usable?
- What happens if I resize the browser? Does the new rendering make sense?
- If I click tab through the various inputs instead of using the mouse, does the change in order make sense?
- If I press the "ENTER" or "RETURN" key, does that trigger the submit button?
- What happens if I click "submit" twice in a row - really fast?
- What happens if, after I click submit, I click the back button? Do I go back to the main screen or do I get one of those bizarre "This page was generated dynamically do you want to re-post?" error messages?
- What if I am visually impaired? Can I turn up the font or does the Cascading Style Sheet "lock" down the user experience? If I can crank up the font is it visually appealing?
- What if I am blind? Can I use the application by a tool for the blind like Lynx? Do all of the images have "alt=" tags?
- Is the web service reasonably fast? What if it's used by 100 users all at the same time? (Note: This was never a problem on MS-DOS, where you only had one user at a time)
- Can I run the application on my 1024x600 netbook? The ads said my netbook was good "for web surfing"
- Can I run the application on my Cell Phone?
- If I come in from a chinese, korean, or italian system but I know english, does the user experience make sense?
- What if I don't know English? Should our software be localized? If yes, what localizations?

這就是會什麼作者覺得書上的答案是不夠的, 這個三角形的例子是不夠理想的, 因為它只著重在某一類型的測試, 而忽略了其他類型的測試.

所以作者認為如果你只是hire RD來當 QA, 其實是一件很危險的事. 因為他很可能都只是注意到前半部的測試 : code, code, and statement coverage, 而不會去想到後半部的測試.

作者還認為, 我們在前半部份的測試,通常都做的很好. 但是對於後半部的測試, 我們經常是缺乏根據使用者的經驗, 來建立一些在real world會遇到的測試

Now, the Microsoft Guys claim to be doing it right.

They want Software Design Engineers in Test (SDETs) who can do *both* entry-level developing *and* critical investigation of software under test - and there are some people who fit into that category.

But that's like saying you want excellent sprinters who are also world-class distance runners - while they do exist, there just ain't that many of those people on the planet.

Those that are here can usually find gainful employment, and not all of them want to live in Washington State, China or India.

The result is that, as an employer, you'll either have to (A) Pay an relative large sum for these people, (B) Have a bunch of open positions while you look for people with the right mix, or (C) Compromise, hiring people who are, for example, good devs you think might make good testers.

This runs the serious risk of developer myopia.


之後作者和他同事James Bach (有名的software testing作者)討論過, 以下是Jame Bach的意見

The words that you quoted [Matt talking about MS's view of testers] represent an attitude that systematically misunderstands testing as a purely (or primarily) a technical activity the object which is to produce "test cases." I too had that attitude, early in my career.

I grew out of it as I came to understand, through my experiences as a test manager, that a test team becomes stronger when it hosts a variety of people with a variety of backgrounds.

Through the ordinary action of teamwork, a diverse group of thinkers/learners exploits the knowledge and skills of each for the benefit of all.

My attitude about testing is deeply informed by a study of cognitive psychology, which is the study of how people think, and epistemology, which is the study of how people can know what they know. ...

When you approach testing not as hot-dogging with test tools or techniques, but rather as a process of human minds encountering human artifacts and evaluating them in human terms for other humans, you eventually realize that the testing process is harmed when any one point of view or way of thinking comes to dominate it.

I would like at least one programmer on my test team. Maybe a few.
In some cases (such as in testing development tools) I will need everyone to be a programmer.

However, I do not treat programming ability as the center of gravity for testing.
Instead I look for rapid learning, high tolerance for uncertainty, and general systems reasoning.
Even then, I don't need EVERYONE to be good at those things.


I'd use different rhetoric and be less critical, but I understand what James is saying.
As testers, we tend to have developer-envy.
The reality is that the two skills are separate, distinct, and complementary.
(Unless, say, you are testing a compiler or a debugger. Are you?)

Now, can a non-developer-tester be a more effective by picking up a little code?
Absolutely. I have an undergraduate degree in Math/CS and a Master's in CIS, of which I am extremely proud - not to mention a decade with a title of developer on my business card.
AND it took me years to fight my way through developer myopia to see the whole picture of software testing.

Developers tend to think in terms of automatable business processes - when exactly what needs to be done up front isn't clear, developers claim that the requirements are "inconsistent" and refuse to program.

The whole picture of testing might include some repeatable elements, but it also includes empirical processes - which adapt through learning as they happen.
This is not a straightforward business process to automate. Developer-Envy doesn't help our craft, it hurts it.

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


The Ideal Agile Workspace

March 5th, 2009
Posted by Mike Cohn
Published in Mike Cohn's BLog

作者認為一個理想的Agile 工作環境, 需要具備以下狀況

1. 引人注目的大型圖表 (Big Visible Charts)
- Agile teams like to hang the charts on their walls.
- Charts like these provide a strong visual reminder of the current state of the project.
- What is shown on these charts will get the attention of team members so display charts showing the most important information for that sprint.
- There are some items could on the charts
    * sprint burndown chart, showing the number of hours remaining as of each day of the current sprint.
    * the number of passing customer acceptance tests
    * the pass/fail status of tests by day
    * print and release burndown charts
    * number of new stories introduced to the product backlog per sprint, and more.

2. 額外回饋的機制 (Additional feedback devices)
- For example:
    * A lava lamp that is turned on whenever the automated build is broken.
    * Use flashing red traffic lights to indicate exceptional conditions such as an issue on a production server.
    * Ambient orbs and Nabaztag rabbits, which are wireless programmable devices that can also be configured to change colors, speak messages, or wiggle their ears as a team desires.
- Devices like these make a workspace more dynamic, unobtrusively bringing into it information the team may find helpful.

3. 每個人都在同一工作場所 (Everyone on your team)
- Each person on the team should ideally be able to see each other person on the team.
- This absolutely includes the ScrumMaster and ideally includes the product owner.
- I do understand, however, that product owners often have responsibilities to other groups outside the development team and so may sit near them instead.
- Still, in an ideal world the product owner would be visible to everyone in the team workspace.

4. 在這Spint中的工作清單 (The sprint backlog)
- One of the best ways to ensure that everything necessary is completed in the sprint is to make the sprint backlog visible.
- The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board.
- A task board is usually oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story.
- Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.”
- In this way, team members are able to see work progressing across the task board during the sprint and all work to be done is visible at all times.

5. 整個專案的工作清單 (The product backlog)
- One problem with running an endless series of sprints is that each can feel disconnected or isolated from the whole of a planned released or related set of new capabilities.
- A good way to reduce the impact of this problem is by displaying the product backlog somewhere clearly visible.
- This can be as simple as keeping the shoebox full of user stories written on index cards on a table in the middle of the team’s space.
- Even better, tack the index cards with those upcoming user stories on a wall where all can see them.
- This allows team members to see how the user stories they are working on in the current sprint relate to others that are coming soon.

6. 至少要有一個大白板 (At least one big white board)
- Every team needs at least one big whiteboard.
- Locating this in the team’s common workspace encourages spontaneous meetings.
- One developer may start using the board to think through a problem; others may notice and offer to help.

7. 要有私人和寧靜的空間 (Someplace quiet and private)
- As important as open communication is, there are times when someone needs some peace and quiet.
- Sometimes this is for something as simple as a private phone call.
- Other times it can be to think through a particularly challenging problem without being interrupted.

8. 食物和飲料 (Food and drink)
- It’s always a good idea to have food and drink available.
- These don’t need to be fancy, and they don’t even need to be provided by the organization.
-  It could  buy a small under-desk refrigerator and share the expense of buying water bottles or soda for it.
- Other teams buy a coffee machine, depending on team preferences.
- Some teams rotate bringing in snacks, both healthful and not.

9. 對外的窗戶 (A window)
- One of the nice things about an open workspace is that windows are shared.
- Even if the view is only of our parking lot and can only be seen across three messy desks, at least I can see the window and some natural light.

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

Hyper-V, ESX, XenServer的被參考趨勢

Comparing Search Trends of Hyper-V, ESX, XenServer

March 12th, 2009
Posted by Srihari Palangala
Published in Virtual Lab Automation BLog

之前在上Performance Testing的課程, 有學員問我是否virtualization 已經很普及了, 是否會在VM上執行performance testing, 或是在上面執行loading很重的程式.

老實說, 我並沒有這樣的經驗. 因此在網路上簡單找了一下, 發現有人做這樣的比較: Hyper-V, ESX, XenServer被search的狀況.

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


相信大家在網路上, 曾經聽過這樣的一個小故事


接著我們再來看另一個故事, 有關 電影院爆米花.

美國農業部建議每個人正常飲食量不該超過20公克的飽和脂肪, 但是每包(中包)爆米花平均含有37公克的飽和脂肪, 桶裝爆米花無疑必超過三位數. 主要罪魁禍首是椰子油, 戲院都是用它來爆玉米, 但是它含有大量的飽和脂肪.

公益科學中心被指示要登一個廣告的廣告, 他們想了很久要如何製作, 才能喚醒大家對這個議題的重視. 因為37公克這個東西很抽象, 我們會想那是很壞的不好(像抽菸), 還是普通的不好(像吃餅或喝奶昔)? 此外飽和脂肪是什麼東西, 這個字眼既枯燥又學究, 誰會理它?


在電影院中買到的”牛油”爆米花, 所含會阻塞血管的脂肪量, 超過
一份大麥克漢堡加薯條的中餐 +

在電視攝影機前展示了這套油膩大餐, 一整天的不健康食物量, 全擺在桌上.

這段節目立即造成轟動, 成為CBS, NBC, ABC, CNN的頭條, 也上了今日美國報, 洛杉磯時報的頭版.

這個觀念讓人記住了, 大批的罷吃爆米花, 銷售量大跌.

所以什麼想法才能被黏得住? 好的想法往往難出人頭地, 但是荒誕的盜腎事件, 卻是不斷流傳. 為什麼呢?

通常一般溝通的訓練會包含這些東西, eye contact; gesture; repeat; practice; say joke, storey first, 有幫助, 但是大家還是記不住.

本書作者提到一件事: 知識的詛咒(The Curse of Knowledge):


因此我們即使我們簡報再好, 或是內容再怎樣有道理, 也無法讓人印象深刻.

作者分析了數百件黏得住的觀念, 發現他們都有一些共同的元素, 找出以下六項原則: SUCCESs
簡單 Simple
意外 Unexpected
具體 Concrete
可信 Credible
情緒 Emotional
故事 Stories

1. 簡單
- 簡單 = 核心 + 簡潔
- 一位成功的辯護律師說
    如果你辯論時向內容, 即使每項都很有道理, 陪審團進了陪審房間後, 一個也不會記得
- 要把觀念剝到只剩核心, 我們必須精通拋棄之道
- 我們必須無情地分出輕重先後順序, 光是簡單並非我們的目標
- 斷章取義並不理想, 諺語才是最理想的, 我們必須創造出既簡單又有深度的觀念

2. 意外
- 吸引對方注意:用驚奇。維持對方注意:用興趣。
- 要如何才能讓聽眾注意我們的想法, 如何才能在說的過程中維持住他們的興趣?
- 這就得要反其期待而行。我們必須要反直覺。
- 我們可以出奇致勝,來提高對方的警覺性和注意力。
- 單是驚奇是不能持久的。要持久,我們必須提供趣味和好奇。

3. 具體
- 讓人家聽得懂、記得住。
- 很多商業上的宗旨說明、策略、願景
- 往往都模糊到了毫無意義的地步。
- 那些天生就能黏得住的觀念都是充滿了很具體的形象的,因為人類腦袋的構造就是要用來記住具體訊息的。
- 以諺語為例,抽象的真理往往被編碼成具體的辭句
- 具體的描述是確保你的每一位聽眾都真正聽到同樣訊息的唯一方法。

4. 可信
- 讓人相信。
- 如何讓別人相信我們的說法?黏得住的說法必得要有自己的信用背景。
- 我們得幫助人們親身試用我們的構想,也就是一種「先試用再買」的哲學。
- 在一九八0年雷根與卡特的美國總統大選辯論會上,

5. 情緒
- 讓別人關心在乎。
- 要如何讓人家關心你的構想?就是要讓人家有感覺。
- 研究顯示,人們比較可能捐款給一個需求迫切的個人,而不是一整片貧窮地區。
- 我們天生就容易對人產生感覺,而非抽象事物。

6. 故事
- 故事即模擬,激發別人採取行動。
- 如何才能讓人家依照我們的觀念行事?講故事。
- 消防隊員很自然地會在每次火災後交換彼此的故事,因而累積了多重經驗
- 長年下來,他們心中就存下了更豐富更完整的危急狀況大全,可用來正確地對付未來的各種火災。
- 研究顯示,在心中預習某一情況能讓我們在事情一旦發生時有更佳的表現。
- 同樣地,聽故事也可算是一種心理模擬飛行器,讓我們能更快速更有效地應變。

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

在開始Run Scrum時, 要注意的事情

Scrum Hell!

May, 2008
Posted by Kelly Water
Published in All About Agile

如果你剛開始成立一個team, 並且大多數的人沒有做過Scrum, 或是沒有接受過Scrum的training. 這時候, 你要team開始使用Scrum來開發, 你將會遇到很多問題, 並且會有大的挫折.

作者看過很多這樣的狀況, 並且每個team所遭遇的問題還不盡相同.

- Much time is spent discussing the process and how things should be done as actually doing it
- The product backlog is confusing and disorganised
- Requirements are not clear.
- User Stories are not adequately prepared.
- Sprint Planning takes *days* instead of hours.
- No too many developers love sitting in meetings!

以下作者提供了一些小秘訣, 來幫助大家度過這樣的難關
1. 首先最重要的, 把你的backlog排出重要順序
- Here I say you should proceed no further until this step is completed, otherwise you'll regret it.
- Accept the fact it will take your team at least 3 or 4 Sprints to get into any sort of rhythm.
- Refine how you handle the process in each Sprint.

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


10 Things You Might Not Know About Automation
By Linda Hayes, Better Software, Jan/Feb 2009

1. 測試資料是最困難的部份
- Automation is all about repeatability, and if your data is unstable or unpredictable, then your tests can't be repeated.
- Consider using your automation tool to load data so you always know the state of your test environment.

2. Record and play 只是商業噱頭, 不應該完全是你實作的策略
- Designed to make it look easy long enough for your check to clear, recorded scripts are nothing more than bad, fragile code.
- The mere mention of this term by a vendor should be grounds for expulsion from serious consideration, as it has been proven responsible for untold failed automation efforts. Don't be fooled.

3. Don't write programs to test programs
- Don't try to replicate application logic in your tests or you will end up with more code than the application itself has.
- Write your automated test to expect the expected and use logic only to recover from the unexpected
(我真的不是很了解作者想強調什麼, 知道的人分享一下吧)

4. 量多不一定有用
- Just because automation can run more tests than you can perform manually does not mean more is better.
- Every test takes time to design, develop, execute, and analyze.
- Worry about coverage, not quantity.

5. 維護性是重要的考量
- We test software because it changes.
- If it takes too long to update your tests, you can't keep up and you will have to revert to manual testing to meet schedules.
- If a vendor tells you it is easier to re-create the test than to maintain it, run for your life.
- Be sure that maintainability is a key quality of any test library design.

6. 不要認為Automation是在最後才能做的
- Anyone who says you can't automate until the application is complete and stable does not know how to design a proper test.
- Modern techniques allow tests to be automated before the code is even allowing automation to play a part in even the most agile of environments

7. 不要認為做了automation,就不需要領域專家
- If an automation tool is so technical it cannot be used by the people who know your application best, keep looking.
- Programming prowess is not a substitute for domain expertize.
- Testing is only as good as the tester.

8. 規劃好內部開發規則
- Establish and enforce naming conventions, design standards, and change control procedures.
- Whitout them, you will lost track of your test assets, resulting in duplication and omission.
- If you cannot find a test, you cannot use it, and if you cannot make sense of it, you cannot maintain it.

9. 要記錄下你的設計原理
- The most elegant of all architectures has no value if you cannot understand it.
many a genius has labored over an approach only to leave confusion behind when he leaves.
- Insist on diagrams and documentation that describe the overall structure and the purpose of components.

10. 要請開發人員也加入
- Unless the developers cooperate by deliveing testable code in the form of persistent object names, exposed methods and properties, and enough heads-up on changes for you to react, all of your efforts will be in vain.
- Make programmers your partners, educating them about what it takes to automate and supporting them with automated build tests and other time savers.

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


When is Scrum not Scrum?

February 21st, 2007
Posted by Tobias Mayer
Published in Agile Thoughts

作者認為之前一些Scrum書中的practices有些過時, 根據他的過去使用及教學的經驗, 整理出一些他認為更有幫助的practices.

1. Product Owners應該要是團隊的一份子
- Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture.
- Encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings.

2. 兩週的Sprint比較合適
- Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed.
- Today it is far too long. It is also true that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming.
- A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.

3. 工作不應該只是考慮多少小時做完
- Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach.
- In my experience team members find this practice frustrating and meaningless.
- Long ago I moved towards encouraging team members to break all tasks down as small as possible.
- A task must be completed in a single working day or it is considered an impediment, and should be marked as such.
- This approach serves two purposes:
    *Ease and accuracy of burndown
        burndown on tasks rather than hours
        making the whole process binary: a task is done or it is not done
    *It raises impediments which developers themselves may not see.
- Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.

4. 使用看板來記錄專案狀態會比spreadsheets好
- The Scrum books, and many courses promote the use of spreadsheets to track the sprint.
- This is really horrible. Spreadsheets hide information, and they lie.
- The best way to create transparency is to display everything on Big Visible Charts.
- The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.

5. 要適時考慮未來要做的事情
- Again, moving away from spreadsheets.
- At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
- Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case.
- The less time we give to thinking ahead in detail on features that may never see the light of day the better.

6. 要有效率的Estimation Meetings
- Estimation is done before the first sprint, and then on a regular basis during each sprint.
- I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time.
- The estimation meeting is an integral part of a successful cycle.
- Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.

7. 要堅持使用一些Agile Engineering的 practices
- It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t.
- It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start.
- This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed.
- Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices.

8. Scrum Master的腳色不一定需要
- An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to.
- The Scrum Master role becomes superfluous in a healthy Agile organization.
- There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people.
- Coaching should be appropriate to the context.

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

1 2


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

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

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