-
编写Story的一周，预示了项目的不祥未来 - [Agile]
2010-06-13
我最近Lead一个QuickStart，第三周编写Story，这一周就像是整个项目的缩影，它让我看到了项目的未来：屈服于压力，不尊重实际的速度，迷信业务的承诺，轻信自己的判断，后期加班，项目延期。
我和一个BA想用一周时间（本周有7个工作日）把Story都做出来，并制定交付计划。之所以是一周，是因为第二周要做汇报。开始比较乐观，认为Story可以很快产出。
周一：
只做了30个Story，比预期的少了近一半，但一想只花了半天做Story，以后应可以补回来。周二：
做了28个，远少于预期，因为今天又有别的事，不能全力做Story，也许明天会好些。周三：
做了34个，今天多了些，但感觉Story的总量会比预期多不少。我们反思了一下，业务（客户）的支持不足是最大问题。心想，如果业务一直在身边，写起Story肯定神速。于是争取了一下，业务承诺每天10点至少支持我们2小时。周四：
业务如约来支持我们，但主要是Review做好的Story，没写新的。下午业务开会，还是我们自己写Story，今天完成40个。周五：
业务没有来，因为他每天都工作到凌晨3点，虽然承诺10点到公司，但11点还在自家床上呢。看来只能加班适应他的时间了。今天做了33个。周六：
我们11点多才到公司，就是准备晚上陪业务加班。加上加班的2个多小时，共写了42个，并没有预期的50～60个那么多，原因是“软柿子”都被我们捏过了，剩下的都是复杂的需求了。周日：
一早我和老大分析了一下，决定推迟汇报的日期。业务那哥们今天大部分时间都在支持我们，但由于剩下的都是复杂的逻辑，今天只做了40多个。一周回顾：
一开始根据汇报的时间点做了乐观的估计。3天后有了实际的“速度”，但迫于压力没有据此调整预期，因为还梦想着业务会支持我们并大大提高生产率。后来发现业务近两天不可能提供全面支持，于是决定加班。之后又发现即使业务支持了，速度也未必明显提高。最后决定延期交付。哈哈，整个过程俨然就是将来项目的缩影，该犯的错误是一定要犯地！
-
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
