| bio | website | neverletdown.net |
|---|---|---|
| location | United States | |
| age | ||
| visits | member for | 2 years, 7 months |
| seen | May 14 at 1:56 | |
| stats | profile views | 52 |
|
Jan 23 |
comment |
Has research been done on the effectiveness of Planning Poker as an estimation technique? Planning poker is an example of a delphi estimation technique, and is a variant of wide-band delphi. There is much research on wide-band delphi that applies to planning poker. |
|
Jan 2 |
comment |
IEEE SRS documents: lightweight version when working with outside contractors? "...I realize that with outsourced development that it is a good idea to be as firm and specific as possible..." interesting that you seem to hold a double standard to the way your team works vs. an external company. In this scenario, wouldn't your team fill the "customer" role? |
|
Jan 2 |
comment |
IEEE SRS documents: lightweight version when working with outside contractors? we're in total agreement on that point. No process is... no process no matter what label you put on it. The main problem I have with your answer is in the idea that "SRS is a no-go in Agile" and "in agile, requirements are specified as User Stories." You can still be perfectly Agile and not use user stories. This is wrong and distracting an otherwise good answer. |
|
Jan 2 |
comment |
IEEE SRS documents: lightweight version when working with outside contractors? I don't recall reading anything about user stories in the Agile Manifesto... be careful not to confuse common agile practices with what you must do to "do agile." Being agile is about promoting practices that allow change and maximizing value. In an outsourcing scenario such as this, sometimes extra structure can create greater opportunities for agility. |
|
Dec 7 |
comment |
How do bug reports factor in to a sprint? One way I've handled Option 1 is to set aside a block of points, in the backlog for bug fixing. It makes planning a little easier and gives visibility to priority etc. along with other work items. Of course you wouldn't include these "bug fixing points" in with your velocity since you're not adding any value... |
|
Sep 15 |
comment |
Are costs part of the requirements? Cost is very much an architectural driver and should be considered side-by-side with functional requirements, technical constraints, quality attributes, etc. |
|
Aug 27 |
comment |
Story points for bug fixing tasks: Is it suitable for Scrum? @maple_shaft "bugs found in a feature after the sprint has been accepted means testers made a mistake in not catching these bugs before acceptance" -- or developers made a mistake injecting the bug in the first place, or the product owner made a mistake not understanding customer's actual needs when articulating the story, or .... A defect can be injected in lots of different places by lots of different people. You can't test in quality. |
|
Jul 25 |
comment |
Documentation degrading - how to deal with it? The underlying point here is important -- you need a documentation champion who is going to hold the team to some kind of standard. |
|
Jun 27 |
comment |
Who should be the architect in an agile project? Don't forget about the "5th value" of the Agile Manifesto: "Craftsmanship over crap." It sounds like your team is favoring the item on the right a little too much. infoq.com/news/2008/08/manifesto-fifth-craftsmanship |
|
May 25 |
comment |
How to create the architecture/design of an application in Agile? @SamehSerag, "The core grows automagically as you [re]factor..." implies that the architecture is not being actively chosen but rather allowed to "automagically" emerge by coincidental choices about lower-level (not systemic-level) decisions. That is the problem with trying to organically "grow" the architecture through refactoring. |
|
May 25 |
comment |
Ways to version user generated documents What is the security model -- I assume each users' documents are private? |
|
May 21 |
comment |
How to specify a functional requirement? The story wouldn't stop with just "manage the list of users" but would also include a bulleted list detailing what this means, as well as additional clarifying discussion (for example, on the back of the card) to help clarify the requirement as new information is uncovered, and maybe even some paper prototypes showing what the feature would look like. |
|
May 21 |
comment |
Are there any scientific studies done on TDD that use total cost of ownership for a product as the measurement? slide n50 is extremely misleading. "The more coverage the more bugs" most likely means "the more coverage the more bugs... you'll find." It's possible, but I doubt that more coverage will lead to more injected defects. This is simply stating that the more coverage the higher the defect yield out of the development phase. And yes, there are plenty of metrics that can measure quality and cost of ownership -- # injected defects by phase, defect yield by phase, and rework are all measurable things with a direct impact on quality and cost. See PSP/TSP for some great examples of these metrics. |
|
May 11 |
comment |
Agile - Spikes and the Overall Timeline Bandaids on the nips are an absolute must! And so is Sprint 0 for all but the most trivial and lowest risk projects! |
|
Apr 26 |
comment |
How to create the architecture/design of an application in Agile? You can't simply refactor the architecture of a system into existence. This is a common myth of agile and architecture. |
|
Apr 17 |
comment |
Formalizing programmers errors 10 defect types initially, and a key step in the process is the PIP - process improvement proposal which lets you evolve the process over time as you learn more about yourself and the way you code. |
|
Mar 18 |
comment |
Is a company order to switch to a certain IDE a red flag? This is such a classic Java religious war -- I love how IDE choice isn't really an issue in .Net shops... |
|
Mar 18 |
comment |
Is it OK to repeat code for unit tests? Right on. Tests are code -- all the same principles for writing good code still apply! Test the refactoring by running the tests, but be sure that there is adequate coverage and that yo're hitting more than one boundary condition in you tests (e.g. a normal condition vs. a failure condition). |
|
Mar 18 |
comment |
What is the difference from the push and pull development models? Continuous vs. Incremental is another underlying concept that might be confusing matters. For example, XP is an incremental pull system while Kanban is relies on continuous pull (i.e. no time boxed sprints). |
|
Mar 7 |
comment |
How to measure external quality of software @MartijnvanderMaas It wouldn't necessarily be more conclusive research, it's just a different view of the same problem space. Both approaches have pros and cons. As a community of practitioners we need both perspectives to gain meaningful insights we can use in practice. |