Links on Development Management
Labels: agile, development
weblog for MikeBD.com. Musings of a 24/6 techie (Software Architect / Technical Manager) family guy struggling to find meaning, balance and strong design / implementation supporting excellent user experiences.
Labels: agile, development
Software Estimation and Agile MethodologyMy Response:
I am new to Agile Methodology. I am working on a project which is following Agile. I have the following questions:
1. What are the estimation techniques for Agile?
2. Typically which type of Projects use Agile?
3. In the name of Agile, can people procrastinate every single decision during requirements gathering? For example, we know what is expected but we don't know the most atomic level of the requirement. Say, I know I must build a webpage, but I don't know the validation of the webpage.
I think Agile principles can be an antidote against procrastination. I would agree with the thoughts expressed in this post. If you continually drive to keep the design and implementation as simple as possible and don't get overly concerned with anticipating potential future needs, there is nothing left to do but build what you know is needed now.
This hinges on the fact that scope is always negotiable as long as quality remains consistently high. Therefore, developers can feel confident delivering features as required without excessive buffering of estimates and over building solutions just in case something may be needed in the future. When and if it is needed, it can be built, and the customer will defer other scope items because they have learned to trust the development team due to consistent and frequent delivery with high quality.
You may appreciate some of the points made and links posted on my blog entry which captured the introduction of Agile practices at my company.
Another important factor in your scenario is the provision of a "Customer in the room". The process works best with a high level of interactivity between developers and end-users or a suitable surrogate that can effectively direct the developers through the micro decisions (like field validations).
Many businesses balk at providing a true customer in the room because of how valuable their time is. I think this is short-sighted and would always expect better results with direct customer interactions vs. large formal requirements documents.
Labels: agile, development, projectmanagement
Testing hours as function of development hours.My Response:
Does it make sense to say that number of testing hours in a project should be a function of the number of development hours, such as
TestingHours = X% * DevHours? If so, what should X% be. What considerations would make it be lower or higher. Are there industry standards around this?
In a word - no.
There are just too many variables at play of which some will include:Having said that, I expect that most teams come to a sense of comfort with a testing hours % of development that works for them and can be applied as a rule of thumb as new projects are conceived. Take the last successful project of similar size / complexity etc...
- type of testing (functional, regression, performance / stress /load, usability, automated / manual, UI / API, back end / white box, browser / multi-platform compatibility)
- strength of your requirements definition process / artifacts and likelihood of disagreement between the business and the developers which QA must arbitrate. Also, how soon QA is engaged in the project life cycle.
- strength of the bug list triage and management process and health of communications between all involved. Related issue: is any part of the project outsourced / off-shore.
- system complexity
- maturity of system (getting version 1 through QA may take more effort than getting version 2 out depending on the level of innovation between versions)
- strength of development unit and integration testing (manual or automated)
- quality risk assumption comfort level / industry quality requirements (medical device / financial services / flight control would be examples with high quality requirements)
- project time line
- time line compression (the more a project time line is compressed from its natural length - overall or in any of the phases before QA), this is a paradox though as the forces that tend to compress a project time line usually are unforgiving of long QA cycles. You can bend a time line but eventually the project will break.
- number and type of users / diversity of their activities with the system (related to system complexity)
- time to market as a strategic need to break new ground, if so I would rather reduce the feature set than compromise on quality
- QA build frequency - test concurrently as development proceeds rather than wait for the final build. Some rework will be required but this is well worth the many benefits.
- headcount ratio between development and QA
- seniority of staff in BA, development and QA
- development and QA tools
- UAT / beta / release candidate process factors
- prototype activities / early access releases.
- project manager strength (natural ability, experience and empowerment to minimize scope creep) and attention level. Same for software architect / development manager and business lead if they are not the PM. Product of this factor for all three roles. Apply a communications frequency and health factor to that.
I've never thought of it before but wonder if you could apply the concepts of XP story points and velocity as an estimation tool for future work. This would fit with the statements above about the factors that are unique to your environment and would require measurement before use. You would write stories for testing (separate from development stories) and measure velocity. I would not look for a correlation between developer story size and QA story size or between developer velocity and QA velocity, although they may appear to emerge, I fear they could be deceptive.
Labels: agile, development, projectmanagement, testing
Labels: social networking
Agenda:I've not specifically gone to any lengths to "sell" Agile, Extreme Programming or Scrum. Some of the values and practices were discussed briefly in my Team Introduction. Beyond that I am trying to foster adoption without any great fuss. This meeting is more Stand-Up than proper Scrum as we have not yet begun moving toward sprinting in iterations and working off backlogs.
1) Accomplishments since the last meeting
2) Planned activities before the next meeting
3) Identification of any blockers that are preventing progress
The result should be the following benefits:
- knowledge sharing / reuse scenario identification
- quickly identify sore spots that require further deep dive follow-up meetings / actions
- dynamic balancing of work assignments as people have availability and projects can benefit from additional resources that are not dedicated to them
- build the team work / sense of commitment to each other
Please be on time, we will start promptly and this should only take 10-15 minutes once we get into a rhythm. The idea is not to talk a lot but to say what needs to be said. Resist the urge to get into detailed requirements or design conversations - this is quick status and identification of issues. We can decide to have a few people hang back and get into deeper conversations once the main group meeting is complete. The remainder of the hour is reserved for that purpose so everyone knows there is a set time for these things if they need them.
Read these:
- http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig (follow the external link to here as well: http://www.agilemanagement.net/Articles/Weblog/ChickensandPigs.html)
- Big Visible Charts (http://www.xprogramming.com/xpmag/BigVisibleCharts.htm). The release planning chart is an example of that and we can do more as we go… A corkboard will be put up for QA and Support to fill with status and issues that development must address.
- http://www.controlchaos.com/old-site/implem.htm and http://www.effectivemeetings.com/teams/teamwork/scrum.asp (focus on the scrum philosophy and meeting style - less on the sprint iteration, something we might contemplate in the future but not immediately).
- http://www.mountaingoatsoftware.com/daily_scrum (especially the bottom section on impediments / blockers).
Developers and QA are the Pigs. PMs and business stakeholders are Chickens. Support are Pigkens (we'll work on that)… Obviously, everyone is fully committed to all of our initiatives and we don't mean to imply otherwise. This is mainly a tool for development and QA to plan and track our work effort and ensure we're each doing the most important things we can be doing on a daily basis. Having others attend the meeting should provide mutual benefit in knowledge sharing and issue identification / resolution and will naturally provoke healthy follow-up conversations.
This is an open meeting. Everyone can feel welcome to forward this invite to other chickens and pigkens as long as they are told to stand on the outside of the pigs and observe silently unless spoken to. We can do a quick hand raise at the end for chickens to ask questions. We'll work on the format as we go…
I expect the result will be that it becomes easy for anyone to quickly see where we are and where we are going as a team and what we need help with (blockers).
Labels: agile, development
I'm especially interested in trap doors and negative experiences you were unable to workaround.I propose the following for new applications (we can have a separate discussion on if / when / how we migrate existing code).- Maven (consider for project dependancy release management) and/or CruiseControl or similar for build automation / continuous integration server- JDK 5 (to at least gain the benefits of generics and metadata / annotations). My gut feel is it might be a little premature to use JDK 6 right now.
I believe all of the above are stable enterprise quality frameworks with a critical mass of developer support and strong reference resource availability. It also seems that the particular combination of frameworks play well together and have been documented to be a good combination, see Beginning POJOs (combining Spring + Hibernate + Tapestry).
My motivations for this include:- reduce design risk / complexity / time to develop and debug custom code that provides non-domain specific functionality (logging / tracing / profiling, database access, transaction management, pooling / caching, security, configuration, UI templates etc...). Save our innovation efforts for domain specific value added use cases.- ease the ramp up for new developers by leveraging industry recognized frameworks which are either readily available in candidates or easily learned
Labels: development, java
With a bent towards code slinger service providers...
In my travels I have been passively collecting a list of resources to be used in this manner and was optimistic that starting small on one or two of these and collecting strong rating / feedback would be a good approach.
My caution personally and from advisors has always been the economy of scale and whether I could expect to win many bids if they came down to pricing vs. offshore consulting houses or individuals.
The key then is to either compete primarily on capability / niche (very current or very dated but still sometimes required) skill sets vs. price - at least until a strong record has been established. Another alternative is to do business development outside of these sites (or between them) and farm out the bulk of the crank turning to an offshore consulting firm using these sites if your skills lean towards client facing technical / project management. Just build in buffers to the project plan to account for the extra handoffs, communications and possible rework required. Know yourself though, if you're an overly perfectionistic OCD plagued code artist you might not be successful representing other people's work at your accustomed level of quality / elegance (I could also recommend a good therapist).
In practice I have not yet had (made) the opportunity to diligently pursue this plan as I've since decided to refocus on being an employee - will I ever learn??? When I was focused on self-employment business development I found that knowing people was much more important to finding and winning bids than knowing things or pricing level. That would argue strongly in favour of the argument in your blog posting.
One tool to use in building a validated portfolio of work that can be referrenced from any of these sites in your profile is claimID.com (mine is http://claimid.com/mikebd).
Sites I've bookmarked - YMMV:
https://www.odesk.com/
http://www.rentacoder.com
http://getafreelancer.com
http://www.sologig.com/
http://freelancepool.com
http://www.freelance.com
http://www.guru.com
http://drupal.org/node/57624
http://www.php-freelancers.com/
http://www.hotgigs.com
http://www.getacoder.com/
http://contractedwork.com/
http://www.eworkmarkets.com/
http://Drupalancers.com
http://drupal.org/forum/51
PHP: http://www.php-editors.com/forums/forumdisplay.php?f=25
http://www.elance.com
CMS: http://www.freelancecms.com
http://www.ifreelance.com
Labels: social networking