-
2009-10-16
IntelliJ IDEA would go to open source! - [XP与相关工具]
今天看到的新闻，呵呵，IDEA是我之前用过的最好的JAVA开发的IDE，现在终于有OS的版本了（版本9，是下一个版本），备忘一下。刚刚去查了查，有Linux的版本，也有一个Vim Emulator。等到正式发布了，再去尝试一下。:)
-
2007-04-30
XPlanner挺不错的 - [XP与相关工具]
记得以前好像也使用过一个XP的项目管理工具，前几日在CSDN上看到一篇关于敏捷软件开发工具调查的文章，找到了免费的XPlanner，把玩了一下，觉得还不错。功能比较多，基本上PLANNING需要的内容都有了，相关的报表和CHART也不错。
CSDN上还有一篇JAVA开源项目管理工具的文章，备忘一下。
-
2006-08-17
【ZT】Practicable TDD & PP - [XP与相关工具]
完全意义上的PP，其实真的没有实施过，目前公司的项目，由于开发平台等等的限制，做TDD的可行性不是很大；但是，对于PP的要求，却是在做前面项目的总结中，大家提出来，需要在下一个项目里面实施的一个实践。
今天在看Jo Cranford的Blog的时候，看到了他对于Agile 2006的一些需要highlight的Sessions，其中，最不应该错过的就是这个《The Test-Driven Development Pairing Game》。
下面就抄录一些核心的描述：There are three legs to the development “stool”:我已经发给了相关的同事，请他们也看看。希望下一个项目，一起实施看看。：）- Test driven design
- Real time code review
- Refactoring
Step 1 ? write a test that compiles, but doesn’t pass. Pass the keyboard.
Step 2 ? write enough code to make the test go green. Pass the keyboard
Step 3 ? either write another test, or go back and do one refactoring.
The rules of the game are simple:- If the test light is red, the next step must be to make it go green.
- If the test light is green, choose whether to write a successful test, a failing test, do a refactoring, or stop and think strategically about the system design ? use the whiteboard to diagram it, etc.
- If the system doesn’t compile, the keyboard can’t be passed.
- Don’t write too much code. Throw exceptions if things are not yet implemented. You’ll be surprised where it leads you if you don’t write too much code.
- One test at a time to evolve the game.
- No email, no phones with email, no IM.
-
2006-07-12
-
2006-04-19
XP不是程序员的首选? - [XP与相关工具]
呵呵，今天早晨看到庄兄的这篇文章，感觉非常的好玩。我个人不是很清楚他的年纪，但是，从语气上看，也可以算是愤青了。
先说说这次聚会吧，我本人没有参加，从一个同事那里听到过，而且，那几个主讲人都是原来ChinaXP上的几个人，从经验值方面，应该是很强的。这一点，从原来的网站以及他们准备的培训材料上，可见一斑。
不过，从最后讨论的那个问题（遇到问题搞不定的解决方法）上看，两个人都跑题了。这个人XP有何想干？如果只是因为XP强调开发人员需要有勇气暴露自己的不足，而把任何跟这点相关的争论都引导倒XP上，有些偏颇了。
如果一定要把开发人员和老板（有的时候，充其量也是一个高级打工仔，跟开发人员有多少不一样？）的关系搞成对立，从传统的人与人关系的角度来讲，也应该首先完成个人对于工作的承诺，然后再考虑触类旁通的问题。而且，就算用GOOGLE来查找问题的解决方案，触类旁通的时间代价对于很多人来说，还是太大了。个人还是同意Yangger的Comments：其实是不是xp一点儿都不重要，作为管理者，就是创造好的团队性格。如果是学术的争论，讨论某些做法是否是XP，可能是那些传道士的工作了...
-
2006-04-04
Effective daily stand - [XP与相关工具]
1. Fix the time of your stand-ups.
2. Keep the task board visible at all times: There is no task board in my team. But I setup a dev trace matrix with task item, originator, expectation complete date and real complete date. It could replace task board, I think.
3. Focus on individuals: Everyone in the daily stand-up meeting should answer three questions: "what did you do since we last met?", "what will you do until we next meet?" and "what might prevent you doing that?" While it isn&apost necessary to go through the ceremony of actually asking those questions, it is very important to get individual answers to them - particularly the last.
4. Only count finished tasks
5. Structuring the task board:
-
2006-03-21
XP，我回来了... - [XP与相关工具]
http://www.agileunited.org/track/experience_reports
在过去的三年间，准确的说，应该是03～04的两年间，是我个人实践XP的Practice最执着的时间。如果单纯从产品或者项目的结果来看，不是特别的理想，但是，可以肯定的是如果没有实施这些实践，结果可能会更糟。；）
05年，是我个人比较彷徨的一年，跳槽、换房子...，折腾了一年，总算有了一个相对平稳的阶段。应该是再次静心研究敏捷软件开发的时间了...，目前公司的情况，可能有很多的限制，没有办法象原来使用Java的平台那样去照搬以前的做法，但是，Improvement的空间是始终存在的，这一点，我完全有信心。
这个链接是05年的Agile Conference的链接，从Subject上来看，有很多应该是蛮有意思的，周末的时候好好看看吧。
-
2006-03-21
是否应该考虑实施持续集成了... - [XP与相关工具]
刚刚看到【Continuous Integration Check List】就联想到最近项目碰到的问题：
1、Code的Comments没有遵循制定的标准，制定了标准之后没有修改原来的代码。客户已经使用产品很长时间了，而且有自己定制的开发，新的功能增加的时候，肯定需要做一些代码Merge的工作，那么就需要我们对于修改已有的代码的时候，注意Comments的写法。当我从美国回来制定这些Standard的时候，我们的代码已经进行了一些开发的工作，并没有回头再进行已有代码的修改。
2、某些模块的开发比原来Delay了一周。不知道跟这个开发人员要离职有没有关系，但是，应该也不能完全怪他的开发效率，从PM的角度，是否是应该在分配任务以及了解Status的时候，就进行合适的再次分配？
3、将Local Env的代码集成到VAT的问题。搞了一周，基本上都是集成环境上出现的问题，种种苦楚不多提了。可能需要在后面模块的开发中，进行持续集成了。明天晨会的时候，跟大家讨论一下可行性吧。对于第一个问题，是自己考虑问题不够全面，可以通过CheckList来加强印象；第二个，目前来说，我还没有找到合适的解决方案，不过，对于团队成员的要求，可能确实太严格了；第三，典型的持续集成可以解决的问题。
明天再问问Team成员的意见，一起改善一下，争取下个月的Release不要出现这么多问题了。：）
顺便把这个List给补上：
When you check in, follow these steps:
Run the build/test script locally and make sure it passes 100%.
Get the rubber chicken from its resting place. If it&aposs not there, find the person who has it and annoy them until they&aposre done with their check-in.
Get the latest code from the repository and run the build script again just in case. If it doesn&apost pass, you know that there&aposs some integration problem with the code you just got. Bitch and moan, put the chicken back, and get the person who last checked-in to help you out. Start over when you&aposre ready.
Check in your code.
Walk over to the crappy build computer, get the latest code from the repository, and run the build script again. If it doesn&apost pass, revert (undo) your check-in. You installed some new software, or modified an environment variable, or set a registry setting, or forgot to add a file to the repository, or something. Anyway, you need to fix the problem on your computer and try again. You can hang on to the chicken for a moment, but give it back (and start over) if anybody needs it.
Ring the bell. (Everyone else, that&aposs your cue to applaud, or otherwise rejoice. "Yaaay.") Put the chicken back. You&aposre done.
-
2006-03-19
[ZT]Xper的一天 - [XP与相关工具]
上周给公司的同事介绍了XP以及ASD，但是，可能是准备不充分的原因，效果不是很理想，而且，他们对于XP还是持很大的怀疑态度。很多人的借口都是从别人那里听来的，也不原因实施，理由就是我们目前的平台很多实践没有办法执行，呵呵。
今天又发现了一篇介绍XPer一天的文章，可以给他们一个参考。【A day in the life】
-
2005-06-04
MoinMoin是个好东西 - [XP与相关工具]
早就知道WIKI是个好东西，但是，自己的惰性使然，一直也没有去尝试，更加谈不上在团队里分享。前端时间看到胖子的帖子里谈到了MoinMoin，就DL了一个尝试了一下。到现在，已经用了1个月了，我是把DailyBuilding的结果和自己的工作日志都搞到了一起，虽然没有用的都是基本的功能，但是，也已经让我对于每天的工作有了很好的掌握和了解，：）
EAD: Bandit Johnson
Technology and skills (Team/Process/Technology) on Enterprise Application Development, especially those on Agile Software Development, XP, J2EE/Python and Patterns.
