Experience Report From Walmart

Author : Bhavin Kamani(Gembatech) Abinav Munshi(Walmart)

31-Dec-2013

報告人 : 林志信 ( 資工三 100502058)

.Outlinea) Background 背景簡介b) Problem & Learnings 遇到的問題與學習處理c) Conclusion 從過程中反思

.Background:

• 在一個龐大的電子商務平台上遇到的挑戰1. 現有的系統升級2. 如何”無痛式”地增加新的功能3. 遭遇的問題切割成各個獨立問題4. 舊有的演算法整合進新的系統

❶ Problem:• During the beginning of our journey, our dilemma was

where do we start, how do we know if things are working and how do we align everyone on the teams to have the same goal. How do we present information that is real time, easy to understand, available and actionable?

• 重點 :整個行程從何處開始、如何了解和如何組織？資訊要該如何呈現？

❶ Learnings:• Visualization : A good inception point for achieving agility

1. Know what is happening2. Let the visualization evolve3. Separate signals from noise

• 重點 :了解目前的行程、把逐步發展視覺化和屏除干擾

❷ Problem:• As we began, we quickly realized after few iterations that

to achieve agile delivery, we needed a well decomposed product backlog. We needed finer acceptance criterias that were well aligned with both business priorities and architectural feasibility. Who will be most suited to take care of this requirement :

• 重點 :要拆開 backlog, 而且找到一套標準來規劃優先權和架構上的可行性 , 誰最適合這份工作 ?

❷ Learnings:• Answer : all of the above – it is collaborative

Product Manager/Domain expert -- get the big picture, market alignment. Help the team to establish a delivery rhythm by prioritizing requirements

Functional/System architect -- contribute by vertically slicing into time-boxed deliverable workflows while aligning with the architecture

Engineering team -- bring value by detailing the acceptance criteria and questioning the value that each slice brings.

In order to build a workable product backlog the whole team has to contribute.

• 重點 :團隊中每個人都要互相溝通合作 , 提供貢獻

❸ Problem:• One of the key challenge that we were facing in a large

program, such as this, is to ensure that teams are executing independently and at the same time are aligned to the cross-functional use cases. Furthermore, existing business had to go on and we wanted incremental upgrades to our programs, which directed us to have an appropriate release plan supported by the right architecture.

• 重點 :面對龐大的程式 , 團隊要同時獨立運作且使用跨功能的 case, 並在持續運作的程式上加新功能 , 所以需要一個完善的配套措施

❸ Learnings:• Organizing Release Management was an important learning for us:

We divided the system functionally to enable individual teams to stay autonomous for their releases.

The architecture choice of using a Service Oriented architecture with ESB provided the necessary framework.

This strategy helped us run multiple programs (both new as well as old) with their respective delivery cycle while still retaining the alignment required for a holistic user experience.

• 重點 :我們把系統切割給團隊並賦予自治權自我管理 , 架構要使用服務導向 , 尊重各個 delivery cycle 但仍然要保持整體使用者感覺

❹ Problem:• Having multiple autonomous teams brought agility at

project level. It created a web of dependencies at program level. The situation challenged us with maintaining program level alignment around use cases, user experience, technology, tools, etc. It was critical for the program to establish certain standards and synergy across teams while maintaining their autonomy.

• 重點 :在專案中各自有自治權帶來了 Agility, 卻也挑戰了維護程式這項工作 , 建立可靠的標準和團隊的合作是極大關鍵

❹ Learnings:• Building continuous communication channels via:

A working agreement between various stakeholders is formed to thrash out modus operandi. This has been huge success in establishing understanding between dependent teams.

Bringing “away” user story as a concept to track and manage inter team dependencies.

Tools, technologies, QA methodologies agreement within and outside the team.

• 重點 :在多人共同協議推敲出工作方法 , 在不同的團隊裡都適用的 , 用user story 的觀念管理組織

❺ Problem:• After making initial progress, we realized that definition-by-

book templates for processes did not yield the desired results. Certain practices such as planning meetings and story points worked well for some and did not work well for others. We could either stick with a process by the book or introspect the process itself.

• 重點 :原先的模型並不太滿足需求 , 特定的方式對於某個部分表現得很好 , 但某些方面表現的卻不好 , 我們不是堅持就是反省

❺ Learning:• Process Retrospection:

Retrospectives were good platforms to listen to the voice of the team. For example, some of the key improvement that came out team retrospectives were: WIP bottlenecks QA, UI resources. Focus on finishing stories rather than completing task.

Experiment with process changes. Preponing acceptance test case creation before start of development Establishing early integration with related projects

• 重點 :回顧反省是一個很好的傾聽平台 , 有很多關鍵的改變都來自那裡 , 在開始發展時提前規畫好測試案例

❻ Problem:• We observed that estimation planning and tracking was

sucking a large chunk of team energy. We, therefore, introduced story points and started observing velocity variance and other key metrics.

• 重點 :觀察到計畫和追蹤 project 是很耗團隊的能量的 , 因此特別導入 story points 的方式 , 觀察整個團隊的工作速率提升

❻ Learning:• As we went from absolute to relative measurement, planning and

tracking overheads reduced dramatically.

• Story decomposition was the key to do a better job at estimation. Estimation became a communication tool to normalize and refine stories

• Team commitment was more important than hitting estimation numbers.

• 重點 :過度的計畫和追蹤大幅度的減少了 , 預測成了一個溝通的工具 , 而且團隊會議是比達到預期更來的重要 .

❼ Problem:• The journey of adapting agile practices is a huge culture

change for any organization. As an organization, we wanted to establish a continuous improvement mindset that helps the team/people identify improvement areas and experiment with solutions

• 重點 :在調整 Agile 的過程對任何一個組織而言都是高度文化的改變 , 我們想要建立一個不斷地進步的思維來幫助整個團隊發現改進的地方和處理方法的實驗

❼ Learning:• Listen by getting outside-in perspective - Coaches, experts

Bringing in industry experts such as Jez Humble, Henrik Kniberg, Naresh Jain to share their experience.

• Actively seek different perspectives Hiring external agile consultants to push start agile practices by

providing real-time coaching to teams. Conduct workshops on story slicing, agile practices, iteration

management etc.

• 重點 :藉由聆聽外面世界的聲音和可以洞察事情的教練和專家 , 不斷的進步

.Conclusion:•結論 :

在沃瑪特的工作團隊中實行 Agile Method 來建立持續整合的能力 , 把看這件事情的視野放大 , 就會發現這整個程式是需要從最基礎的地方開始改善 , 例如 : project, teams, processes, technology and tools, 而且 Agile Method 的關係幫助我們把不同的領域拆開來 , 並給予各自需求的實作方式 , 同時我們仍要秉持著維護整體的一致性 , 特別強調他們彼此之間的關連 , 終究給使用者一個整體的感覺 .