-
Make visible both progress and smell - [Agile]
2009-01-05
Burn down chart and story wall are often used in agile project for
visualizing the status and progress of project. They should be designed
to visualize smell easily as well.Smell is sometime made less visible unintentionally. We probably did things as below:
- Enlarge the wall for more cards.
The wall then became more 'smell tolerant'. Problems are hard to identify.
- Categorize bugs so that we can manage more.
Feeling of bugs being well organized weakens the strength of the will to fix them soon. The count of half done stories may increase with the bugs.
So, in order to resist the tendency, we can try:- End-to-end evaluating, keep goal in mind.
- Make it brittle for even small problems. Here 'it' fits for process, story wall and more.
- Keep it simple, less is more.
- Enlarge the wall for more cards.
-
Comments on Agile Practices from My Recent Project - [Agile]
2008-12-20
Story wall- Less is more. Keep wall small and concise. The wall for our project is too big.
- Be sensitive to the wall's smell.
- Move cards under the rules your team currently follow.
- A real wall is better than online system in many aspects. It's more visible, complexity/smell amplifier, team focused, free formed and has just enough functionalities.
- For a distributed agile team, an online system serves a key role.
Story Estimation
- Be aware that under estimation brings the feeling of hurry and tends to lead to less tests and poor design.
- Be aware that under/over estimation contributes ruining the predictability of stories based plan.
- Re-estimate if the original estimations are out of date considering new knowledge gained about the story(requirement or implementation).
- Don't blow up estimations by considering technical debts much. Treat technical debts actively so that we need not to pay much 'interests', and the relativity is there between early and later stories.
Story Planing- Story being played should be end-to-end testable, if not, try putting necessary story in the same iteration. E.g. playing draft page story earlier could make the binding testing of creation page story more doable.
- Play stories around one page one by one, not at the same time. This brings less conflicts, less pain of fixing previous stories' issues, earlier end-to-end testability and facilitates evolutionary design. E.g. stories of creation page.
- Story, bug and tech-task should be treated equally. No need to categorize them separately in 'ready for dev' column on story wall.
Quality
- All roles share the responsibility of quality.
- Build quality in the process how a story is produced.
CI- Light, sound, monitor are all candidates for indicating build status.
- Long local build will stop frequently checking in. If this happen, try to optimize build process, then optimize time consuming tests, then run only a subset of tests in local.
- Run in local build the UATs which are most likely to fail recently.
- Run in local build the UATs which ensure critical features. As smoke tests.
Test- Leverage jsunit tests for client side logics. This reduce the need to write selenium tests which have long feedback cycle compared with jsunit tests.
- It's unpractical to write UATs for all logics. Consider the priorities as below:
- Logics which are most likely to fail.
- For repeated manual testing procedures. As smoke tests.
- For bugs.
- For individual stories.
- Try to refactor your design if you feel it's hard to write unit test.
- Try to refactor your design if it's hard to understand a test.
To DEVs
- Be sensitive when a larger design is needed, initiate group discussion at this time and do just enough simple design.
- Simple design means every guy knows every piece of code.
- It's an opportunity to refine the design when you revisit the same piece of codes. Do evolutionary design.
- Don't write code for sth. you don't fully understand, go to BA at this time, otherwise you may mis-model sth.
- Keep priority/value in mind, be sensitive to the opportunity of spliting a story into two when playing a story. The derived story cost much with less value, could be planed in later iteration.
- Feedback your feelings about a requirement to BA, it's an opportunity to build a new mutual understanding.
- Observe carefully how QAs test a story in mini showcase.
- Respect QA's feeling about the quality, refactor bravely around the area with poor quality.
To QAs- Be aware that the INNER quality can only be enhanced by improving the design of code directly or indirectly. Working closely with dev is the key for high quality software.
- Try to enforce the sense of quality for devs by finding bug quickly and feedback on time.(mini showcase, quick feedback after dev-complete)
- Provide feedback of your feeling about the bad quality of some part, discuss with devs for potential big refactoring around that.
- Let team know the open/critical bug count and bug fixing progress in standup.
- Work with devs closely writing UATs and refactoring them.
- Ask 'does anybody know what allowed the error to occur?' instead of 'who made the error?'.
To BAs
- Make sure devs have the same understanding as you about the stories, otherwise devs may mis-model the domain into code and introduce bugs eventually.
- Be aware that some detailed requirements emerge after start playing the story. Story is negotiable when playing.
- Respect DEV's feeling about a requirement, treat it as an opportunity to achieve a new level of mutual understanding.
- It's an opportunity to simplify a requirement or identify a mis-defined requirement when dev complains it's too difficult to implement a story.
To Team Manager
- Every time you tell people what to do, you take away their sense of responsibility.
- Drive team by prioritizing story/bug/tech-task.
- Enabling members instead of managing them. Coaching over managing.
- Let team know 'all' what you know through an on time and visible way.
- Visual control. Leverage burn-up chart, story wall and more.
- Self-management. Be provided enough information for self decision making.
- 'SLACK' time is the investment to the creativity. Learning, sharing, innovations and breakthrough improvements may come from 'SLACK' time.
Stand-up Meeting- Begin at a fixed time. Don't always make unnecessary delay.
- Make sure problems raised are always followed by action or owner.
- Try attending other team's standup.
Retrospective Meeting- Focused on a higher level reflection on the way we have worked, identifying key problems in project and process, instead of discussing and solving detailed problems, which should happen after daily standup.
- Doable actions with owners are key outputs.
- All members should take responsibilities on long term improvements. The owner should find ways "pushing" the team and keep an eye on the improvement.
- The owner may not be the doer. Every member could be the owner of every kind of action or long term improvement.
- Hold at a relaxed time, in a safe environment.
- Chaired by a guy outside the team if possible.
- Hold not so often. Remember it's not designed to solve daily based problems.
- Try different forms.
Daily Session- An ideal daily session comes from this week and serves mainly on next several weeks.
Spread Agile into Other Teams- Be patient, try and see what happens.
- Group an Agile Promotion Committee consists of Agile experts and a sponsor providing authority support.
- Start with small, step by step. Avoid trying to push all practices to all teams in a unified way.
- Avoid building any standard. Team decide on their own.
-
你在项目组中有“安全感”吗？ - [Agile]
2008-11-18
回顾会议中的Safety Check 在敏捷项目回顾会议正式开始之前，我们有时会做个匿名的“Safefy Check” ，以了解大家在分享自己的想法时是否有“安全感”。一般分5个等级，1代表“我会微笑，说事情进展的不错，并同意经理的所有看法”，5代表“愿意敞开谈任何问题”。
这样做是让大家认识到，每个人心里的安全感是不一样的，组织者会据此变换会议的形式，以确保在达到会议效果的同时不让任何人感觉不舒服。
项目组中的Safety Check
同样的，在项目组中，每个人也都有自己的“安全感”等级。让我们试着回答下面的问题（每个问题的前一个选择表示你在团队中有较高的“安全感”）：
- 你是否愿意及时表达自己的意见，而不必担心会被指为是幼稚的想法。
- 在有疑问时，你是否愿意在第一时间找到对此问题最熟悉的人寻求帮助，而不管他/她是谁，也无需担心被鄙视。
- 在你做一些自己没有把握的尝试时，得到的常常是鼓励与指导，还是阻力或质疑。
- 在你做一个选择或决策时，考虑的是对整个团队是否有价值，还是更在意给项目经理或某一个人留下的印象。
对上面问题的回答可以反映出成员在项目组中的“安全感” 级别。当安全感等级较高时，团队的能动性和创造力可以被充分激发出来，团队成员工作起来也开心，幸福。相反，较低的安全感让人感觉压抑，要处处小心。“安全感”是主观的，无法强加的，也是团队建设的重要方面。你在项目组中有“安全感”吗？
-
重构泄露的逻辑而不仅仅是修bug - [Agile]
2008-10-12
修bug时我们都有这样的经历：简单查看了一下代码，发现没有那个类负责这个逻辑，进一步深入代码，查找一番，才在一个看似不相关的地方找到了错误的根源。原来这个逻辑被散落在几个地方，隐讳地错误实现了。我们在出错的地方多加一个if else，或是写点别的什么代码，这个bug就这样被fix了。仅仅这样做虽然提高了软件的外部质量，但对内部质量的提高毫无益处，泄漏在外的逻辑不仅仍然无家可归，而且有变得越加复杂和晦涩的倾向。
每一个bug的出现都是对分析、设计和编码过程的一次质疑。这次......
-
【本文发表于《程序员》杂志2008年第7期，是在《频繁的Switch Pair是一种浪 费吗？》一文的基础上修改而成的。】
敏捷软件开发中有一项实践是结对编程（Pair Programming），指的是两个人坐在一起共同完成一项任务，这样做的目的常常被解释为便于共享和传递知识，提高代码质量。
结对的两个人是需要更换（Switch Pair）的，否则时间长了就跟一个人没什么区别了。不同的团队往往有不同的更换策略，... -
想起了准备“敏捷中国”大会演讲的过程 - [Agile]
2008-06-28
《精益工厂之旅》演讲视频
精益工厂之旅PPT
精益 思想与软件开发(简化版)PPT
Lean Thinking & Software Development PPT
精益 思想与软件开发PPT
6月21号，我参加了第三届“敏捷中国”技术大会，做了“精益工厂之旅” 的演讲。其实我一开始准备PPT并不是这个题目，是在大会的前一天中午才决定换成这个题目的。
回想起准备演讲材料的过程，还真是费了些周折。我本来准备了一个“精益思想与软件开发”的PPT ，在公司内部演练的时候，发现时间严重超时，同事反馈说内容跳跃太大，理论和新概念太多。我心里有些没底了。
我又赶紧把PPT拿给马波看了一下，结果被他痛批了一番。他说......
-
Unit Test Make Smelly Code More Smelly - [Agile]
2008-05-20
Unit tests have many benefits, they are usually expressed as:
* ensure existing logics during developing
* drive out design
* documentation of requirements
Another big benefit is making smell code more smeller, brave developer... -
Thoughts on building the environment for innovation - [Agile]
2008-04-20
Thoughts on building the environment for innovation:
* Don't Vote
Voting does not usually encourage ideas which are not mainstream or attractive enough.
Voting is reasonable only for 2 cases, one is that the voters ha... -
频繁的Switch Pair是一种浪费吗？ - [Agile]
2008-04-13
敏捷开发中有一种实践是结对编程（Pair Programing），指的是两个人坐在一起共同开发一项任务，这样做的目的常常被解释为便于传递知识，提高软件质量。
结对的两个人是需要经常换的，不同的团队往往有不同的Switch策略。有的做完一个Story再换，一般要2、3天或更长；有的团队每1、2天换一次，不管有没有做完Story；有的团队确保每个Story有一个Owner，他始终不离开这个Story；还有的... -
创建鼓励创新的工作环境 - [Agile]
2008-04-10
前天公司组织了一次非正式的讨论，关于如何创建一个鼓励创新的工作环境。
ThoughtWorks非常重视创新，并视其为保持其行业领导力和文化的重要因素。北京分公司也曾经有同事有很好的技术创新，并开发出了软件工具，但从增个公司的角度看还不够理想，现在的问题是公司如何创造出一个更好的鼓励创新的环境，让大家在工作中发现和培养具有创意的想法，让这些想法有机会进一步发展，创造更多的价值。
下面是我的一些想法：
* 不要给创新的点子投票（Don't... -
Stand Up Meeting Pic - [Agile]
2008-04-03
早上发现办公楼下建筑工人也在开Stand-Up meeting！！
-
Agile Brief Introduction - [Agile]
2008-03-21
The presentation I gived in the pre-sale activity.
http://luning12.blogbus.com/files/12068545210.ppt
... -
强调测试的同时不要冷落了设计 - [Agile]
2007-11-11
单元测试可以确保代码的局部行为是按照设计意图实现的，但单元测试只能覆盖一部分逻辑，还有些逻辑需要引入集成测试。尽管如此，很多bug还是 很难被各类测试覆盖，此时系统就特别依仗良好的设计了，良好的设计简化单元测试，让深层的逻辑变得简单，进而让更多的逻辑变得可测。糟糕的设计让单元测试 成为负担，而且往往导致重复的测试和难以理解的测试。
这里说的良好设计当然就是指简单设计，但有时“简单”二字... -
聊聊开发过程中的“反馈” - [Agile]
2006-12-29
沟通，反馈，简单，勇气，尊敬是敏捷开发的五个价值观， 它们深刻地反映了当前软件开发组织中相对缺少但又对团队建设和成功交付至关重要的东西。
里我想聊聊反馈，但并不讨论关于反馈的全部，主要是集中在对“想”与“做”的节奏的探讨。
馈是我认为最特别的一个价值观。实际上，做很多事情，我们总是重复着&ldqu... -
单元测试 VS 跟踪调试 - [Agile]
2006-12-22
前些天在程序员杂志上看到同门大师兄WPC的文章"Javascript程序调试 - 不调之调”，有些感触，文章通过诙谐的语言讲述了作者在Thoughtworks工作时处理Javascrip调试问题的对策 - 通过应用Selenium页面测试工具来减弱甚至消除对调试的需要。
其实，敏捷开发推荐的测试驱动开发对于跟踪调试的态度正是“不调之调”，跟踪调试在绝大多...
共1页 1
