EAD: Bandit Johnson

Scrum之道 - [敏捷软件开发]

如果没有记错的话，国学中被翻译成外文最多的著作不是《论语》，也不是《孙子兵法》，而是《道德经》。区区五千字中间，给我们留下了太多的内容去领悟。老外，也不除外。：）

今天，看到了完整版本的Scrum之道，是一个老外写的，可以参看以下，算是道出了其中的精髓。

The Underlying Tao

The Way is Transparent. The Way should be Inspected. What is Inspected should be Adapted to.

The Tao of People

The Product Owner decides the ‘what’ of the Way.

The Team decides the ‘how’ and ‘how much’ of the Way.

The Scrum Master serves the Way, and tells others when the Way has been lost.

The Tao of Events

Release Planning defines what users of the Way will find of value, and by when.

Sprints are the Way of the Team, and do not vary in length.

Sprint Planning defines the Way for this week, and for next.

The Daily Standup helps the team Adapt to the Way, for today.

The Sprint Review helps the users of the Way Inspect what has been done in two weeks time.

The Retrospective helps the team decide the Way forward, by Inspecting the Way that is past.

The Tao of Things

The Product Backlog is the Way, in order.

The Sprint Backlog is the ‘How’ of the Way, for two weeks time.

The Product Burndown shows the Way of the Product Backlog.

The Sprint Burndown shows the Way of the Sprint Backlog.

The Tao of Endings

The definition of Done must be agreed upon by all who follow the Way.

应用开发的目的为何？ - [项目开发技术]

我喜欢应用软件和系统开发，但是，谈到为何要进行这样的开发，在我刚毕业的时候，我只是觉得这是一件很炫的事情，而且，还可以赚到一笔可以维持生活的钱。:)

随着时间的进展，我越来越认识到，事情远没有这么简单...，今早又看到一篇博文，摘录应题的内容如下：

The goal of software, be it web, mobile or desktop applications, is to help achieve business goals. However, without achieving people's goals, and with that the ones of software users, it is very unlikely that the business will achieve its own goals. This is why software projects should start with design, not programming. User centric design, that is, where accent is on understanding users and especially their activities. Not to diminish the value of other aspects, the quality of user experience is the most important.

又到一年拍马屁时... - [项目管理]

Performance management是件很SHIT的事情，但是，仍然有很多公司乐此不疲，有些原因是因为这样作实在是太简单了。但是，你回过头想想，有多少人在作self assessment的时候，是敷衍了事，为什么呢？你给了员工多少安全感，多少实际的指导与沟通，还是真的只是每年两次例行公事？如果你跟我对待pmp的态度一样，那就看看Esther的好文一篇。如果你是个所谓的管理人员，千万不要真的只是每年1／2次的例行公事；如果你是个想成长的员工，那么也要多跟你的mentor/coach沟通，而不是仅仅跟所谓的Manager作例行公事。:)

[zt]敏捷团队工作空间建议 - [敏捷软件开发]

一篇蛮好的Dos and Don'ts的文章，可以看看。这些建议都是跟敏捷原则和价值密切相关的，不理解的话，就更不容易实施了。

最有意思的是不带耳机，呵呵，要PP以及及时沟通的话，怎么带耳机阿？不过，很多人貌似已经习惯了这个。

［ZT］敏捷开发的三条腿 - [敏捷软件开发]

三是个很有趣的数字，道家有云“道生一，一生二，二生三，三生万物。”，很多原则性的东西，都很喜欢归纳到三条，不知道跟这个是否有很大的关系？

回到敏捷开发，实际上应该是所有的开发，都逃不开三个问题：组织工作，开展工作，一起工作。这篇博文给出了很好的解读，记录一下。:)

［ZT］Questions for managers - [项目管理]

Esther又出好文，提出了13个管理者需要回答的问题，非常有借鉴意义。

What we’ve overlooked or ignored is a manager’s role as designer. Managers are designers of the experience of work and of systems to produce valuable products.

这个视角本身就值得关注。

[ZT]团队的心 - [敏捷软件开发]

之前应某个领导的要求，做过一个Leadership的session，当时谈得还不透，因为毕竟都是自己公司的人，很多话不敢说，:)

今天，看到了一篇博文，讲Scrum中team的定义，我觉得颇为精彩，值得学习和以后引用。ZT如下：

At the heart of the scrum team is the interaction of the team. A daily meeting around the task board is interactive, vibrant, collaborative, visual, and tactile. It is a visual way of showing the goal the team is striving toward and the progress they are making. They, each and every member of the team, are peers.

They own the goal. It's a team effort. They gather around the board to align themselves with each other, to honor each others' contribution to the effort, and to course-correct when they are missing the mark. They argue, discuss, share, learn, continually improve, celebrate, boost each other up, and create solutions.

There is another thing that scrum does for the team: it creates transparency. Since scrum depends on collaboration and continual forward progress, problems are addressed by the team as they crop up instead of dealing with them later or covering the problem under a layer of "spin".

A structured, militant environment will never create a team. A team works together toward a shared goal. A group works together toward a goal given to them. Scrum is messy, and noisy. It lives, it breathes, it stretches, it morphs and it expands. Interaction is the heart of the team. The heart of scrum, is the team.

Just make it & Manager's role in the team - [敏捷软件开发]

我没有查询，但是，印象里之前说过JUST DO IT之类的话，所以，就把标题换成了JUST MAKE IT，哈哈。其实，意思是一样的...

人没有主见很可怕，更可怕的是把主义建立在道听途说或者臆想上面，今天dreamhead的博文就很好的说明了这一点，实在是不想多说什么了。

Manager确实不好当，大环境或者小环境不好的时候，更是如此。敏捷团队中的Manager，跟一般团队的Manager并没有什么不同，看看Johanna列出的这些事情吧，是不是很熟悉？

For example, what good is a functional manager? If functional managers don’t need to assign tasks and check on how the work is going (the team does this), the functional manager needs to build a trusting relationship with people, and provide career development. The manager sets the mission/purpose of the group. The manager needs to see when the team (or teams) need more people, and to start and lead the hiring process. The functional manager may act in what I think a technical lead role is: to help uncover other ways of working, whether that is specifics (extend the design this way, test that way) or to coach the person into recognizing where to look for help. And, the big decision that managers make: which project to work on now. (Of course, there is also strategic planning, customer visits, etc.)

不管是不是敏捷团队，单单只是前面两条，就不是那么简单的事情，但是，却是一切事情的基础，否则，敏捷团队也不可能心无旁骛。这也从一定的侧面，说明了敏捷的实施自顶而下的好处。

Buy in Vs. Follow up - [敏捷软件开发]

讲TDD也好，讲UT也罢，都是随着敏捷的风行而越来越被人熟知，但是，真正执行的好的，确实不常见。为什么呢？因为buy in和follow up还是有很大的区别的...

今天看到DREAMHEAD的一篇讲UT的文章，讲的非常有道理。最近，我进入了一个新的团队，他们的人员构成上Senior的人很少，但是，项目看上去还是蛮成功的。有些问题，在测试的阶段不可能全部暴露出来（例如代码的可维护性等等，要在产品生存了一定的时间才会越来越明显，可惜的是，很多时候，团队稳定的时间更短，然后，就是后来的人骂娘，然后，再被人骂娘的恶性循环），而且，你也不可能寄希望于QA／Tester去发现所有的问题，关键是要明确SE的职责，也就是Scrum中对于Done的定义。

如果我们去除那些开发流程需要的文本内容的话，从代码的三个层次来看看开发人员到底应该有些事情作完了，才叫DONE吧（一家之言）。

• 完成功能：项目确定coverage的UT；功能的demo；
• 代码规范与开发规范：利用Checkstyle等类似的工具来检查代码规范，并集成到daily building或者code commit的过程中（这点是项目开发团队SCM的事情，SE需要清楚的了解规范，并检查反馈并改进）；不能用现有工具进行的开发规范的检查（例如，报表或者UI对应的元素的字体等等），可以通过编写BVT（Build Verification Test）来进行。（对于这一点，我一向觉得，规范没有检查，只是纸上谈兵，SE以及TL要有用机器来帮助检查的意识，否则，很容易流于表面，或者让Code Review变成了规范检查，不值！）
• 代码的设计与维护性等等：PP以及Code Review希望可以解决的问题。在Code Review之前一定要确保基本功能和规范都没有问题。

能够切实理解，才能很好的执行，否则，流程最后还是会被规避，国人的聪明才智在这些方面还是很强的...

非完美世界的敏捷 - [敏捷软件开发]

今天在InfoQ上看到两篇文章，一篇是谈《给成功敏捷开发的26条建议》，一篇是谈《敏捷的一个基本要素》。个人对于两篇有截然不同的看法。

敏捷也好，LEAN也罢，传统的瀑布模型也成，都是适用于某些情景下的一堆最佳实践的总结。第一篇中提到的那些个实践，尤其是中文中特别罗列的几条，其实，在非敏捷的开发中也是很好的建议；反而对于真正有敏捷精神的团队来说，是不需多言的内容。如果你只追求“术”，而不了解背后的“道”，硬背的招数再多，还是会忘掉，或者是生硬裁剪掉，或者是“时间不够噢”（最后一个是最可笑的理由...，可惜也是最常看到的）。

而对于第二篇的内容，从管理层次来说，如果你碰到的是那种谦卑的Boss是你的幸运，但是，在一个矩阵式管理的团队中，你不能祈求所有的Boss都理解何为敏捷，以及，敏捷需要什么样的环境？自顶而下最好，如果不成，农村包围城市也未尝不可。关键是要让团队体会到切实的好处，否则，口土莲花还是会被打下神坛，敏捷也逃不脱...

结对很重要，但是你能开心于每天被纠正几十次更重要。测试驱动开发很有用，但是去设想一百多种让测试通不过的场景更有用。站立会议可能很有效，但是同事的信任解放了你去做自己的事情，才让会议真正有效。

信任意味着你不得不放弃控制，放弃很多。
设想意味着你将少了很多确定性。
改正意味着你不得不承认从来就没有完美这回事。

...成功运用敏捷软件开发——或者任何其他种类的敏捷——的公司，都是那些能处理好失去控制、确定性以及完美保证的公司。