Тенденции

Forrester Research Survey on Impact of Agile

Forrester Research is conducting a survey on the impact of agile processes on technology companies. They are looking for feedback from both technical and business people within organizations. It takes only about 10 minutes to complete the survey, and I encourage people to do so. Take the survy here.

A Requirements Challenge

A challenge to think of a feature in Microsoft Word (as an example) that is new functionality rather than a better way of doing something that could have been done 100 years ago.

"Classic" versus "Mockist" TDD, Distinction Real?

Hot in the TDD Yahoo group is a discussion concerning the perceived continuum between the "Classic" and "Mockist" TDD. Steve Freeman, Nat Pryce, Michael Feathers, Dale Emery, and many more discuss terminology and describe their approaches. The discussion also debates whether there even really exists such a continuum, and if so, what distinguishes the approaches that represent it's extremes? By Mike Bria

the “anchor adapter”

Warning: academic theorizing and hypothesizing follow. Oh, and half-baked pontification.
I just finished refactoring reek to drive in a major new chunk of functionality (configuration files) which I’ll release soon, when I’ve had time for some thorough testing.
The refactoring needed to accommodate the change was huge, occupying much of my free time over the course of [...]

ОПЫТ ПРИМЕНЕНИЯ AGILE МЕТОДОЛОГИЙ В РАЗРАБОТКЕ ЭЛЕКТРОНИКИ

По-моему, отличная статья Алексея Омельянчука о том, как применяется Agile в проектах разработки электронных устройств.

Потрясающе интересный опыт итеративной разработки в абсолютно (казалось бы) непригодной для этого среде. Кроссфункциональности нет. Сборка занимает 2 недели (а не 5 минут, и даже не 3 часа). Куча смежных проблем.

В общем, читать всем :-)

A thought on empowerment

For me being empowered is a property of 'the system' in which we play a part. It's constructed between people, by the actions they take individually in the environment they occupy.

Having the right environment is essential. When it's safe and fun people are motivated by trust. They begin to demonstrate the courage to be creative and they take risks and make mistakes. An environment that tolerates mistakes to cultivate learning helps people face their fears and act decisively. And when people are able to perform freely they become energized and create a buzz.

Empowerment is not something that can be assigned. I can't give you empowerment and you can't give it to me. So don't try to empower people. Concentrate on creating the right environment for people to construct their own empowerment and step back.

Example Driven Acceptance Testing

Unit and Integration testing often get more importance in Agile teams as compared to acceptance testing. Gojko Adzic and Lisa Crispin suggest approaches to efficiently include acceptance tests as a part of development. By Vikas Hazrati

Eclipse PHP Development Toolset 2.0 released

The Eclipse Foundation has announced the immediate availability of PDT 2.0, a major upgrade to the popular Eclipse PHP Development Tools project. PDT is an open source development tool that provides all the basic code editing capabilities developers need to get started developing PHP applications. By Alex Blewitt

A Simple Scrum Sprint Review

At the end of the sprint, the Product Owner, Team
and Scrum
Master meet to review the progress of the sprint. The product owner has
to
evaluate the state of the project so s/he can decide what to do next.
How does
the Product Owner ensure that s/he gets a complete and correct
understanding
about the state of the project, including all inconvenient truths? Here
is a
simple agenda/meeting template to follow, to make sure all the bases
are
covered.

Last week, I introduced that concept of a Sprint
Contract to
define the parameters of the sprint. The factors Scope, Quality, Time
and Cost
will be familiar to any project manager. Scope is defined by the
stories and in
particular their size. Quality is defined primarily by the definition
of done.
Time is fixed by the sprint duration. An upper limit on the costs is
set by the
team size * sprint duration, after adjusting for absences and other
tasks.

A simple sprint review needs to

1. Confirm that the team has delivered on its commitments
2. Confirm that the overall project is on track
3. Examine the functionality which has been delivered.

<!--break-->

Confirm that the team has delivered on its commitments

The Scrum Master should take a few minutes to
review and
summarize the agreement between product owner and team. How many
stories? How
many story points? What is the definition of done? How much effort did
the team
plan to invest?

Next the Scrum Master should present a summary of
what the team
actually accomplished. How many stories achieved done? How many story
points?
Did the team invest more, less or the same effort as planned? If there
were any
important differences, now is the time to make them visible.

Confirm that the overall project is on track

The Release Burn Down chart is the primary tool
for
measuring progress and scope of the project. Scope, progress and
estimated
completion date are all clearly presented in one easy to interpret
chart.
Everyone in the project should see the update release burn down chart
after
each sprint. It's even better to keep it posted on the wall.

Is this enough? Beyond the basic burn down chart,
it might
useful to keep an eye on the other parameters of the project, i.e.
quality and
cost.

Monitoring quality builds confidence in the
product and
keeps your technical debt under scrutiny. The number of unit tests and
acceptance tests defined and passed should increase every sprint.
Insufficient
tests are warnings that technical debt is accumulating or that
requirements
could change suddenly as the project nears completion. A rising number
of open
bugs may be a sign that the quality is not sufficient. Your next
retrospective
would be a good to time ask yourselves how to produce fewer bugs.

I think the main reason for monitoring work
invested is to
make sure that your teams efforts are not being diverted from the project.
Monitoring
budget in actual money will keep your top management happy and make
your
Product Owner's life easier. Budget can be tracked with a burn down
chart, just
like scope, and the budget divided by burn-rate should be sufficient to
cover
the remaining sprints.

Examine the functionality which has been delivered

Your team is only allowed to demonstrate finished
functionality, i.e. meets the definition of done. My experience has
been that trying
to demo unfinished functionality causes trouble -- things which haven't
been
fully tested often break. Everyone should get a chance to talk, so each
developer should demonstrate the functionality s/he was primarily
responsible
for.

As a product owner, you should ask questions and
explore.
This is a demo of product which your users will use, not a tour through
the
mine field. So everything you see should work or fail gracefully.

Once you've seen everything that is done, you can
discuss
briefly anything which was not successfully delivered. Why wasn't it
delivered?
What needs to be different, so that it can be completed in a future
sprint? Or
do you need to rethink?

The Simple Scrum Sprint Review Meeting

Here is a sample agenda for the meeting, with
timings for a
2 week sprint.

Present: Product Owner, Implementation Team, Scrum
Master
Moderation: Scrum-Master
Duration: 1 hour per week of sprint length
Agenda:

What	Description	Who	Duration h:mm
Confirm that the team has delivered on its commitments	Review Sprint Contract Summarize sprint results (stories, story points, effort, etc) Note discrepancies between plan and actual	Scrum Master	0:05
Confirm that the project is on track	Review & Discuss Release Burndown Chart, other key points as needed	Scrum Master	0:05
Examine the functionality which has been delivered	A spontaneous guided tour, led by the developers, through the new functionality in the product.	Product Owner and Team	1:40
Discuss functionality which was committed but not finished	Understand what happened and why, but save deeper investigation for the retrospective	Product Owner and Team	Up to 0:10

Seven Principles of Lean Software Development

Lean Software Development has its roots in Toyota Production System and it helps software organizations optimize their processes and production methods in order to deliver their products to the market much faster and with better quality. Lean movement can be considered as a new development method that tries to identify and eradicate all problems and "disabilities" of old methodologies like Waterfall. Lean puts main focus on people and communication - if people who produce the software are respected and they communicate efficiently, it is more likely that they will deliver good product and the final customer will be satisfied.

Lean Software Development subsequently gave birth to Agile Software Development methods and its main branches like Scrum or Crystal Clear. For many people who know the subject Agile is just another word for Lean or Lightweight.

In one of the most popular books on Lean subject, namely "Implementing Lean Software Development - from Concept to Cash", Mary and Tom Poppendieck explain how to implement Lean by following seven principles - principles that are some kind of Lean commandments:
<!--break-->

1. Eliminate Waste
   • Provide market and technical leadership - your company can be successful by producing innovative and technologically advanced products but you must understand what your customers value and you know what technology you're using can deliver
   • Create nothing but value - you have to be careful with all the processes you follow i.e. be sure that all of them are required and they are focused on creating value
   • Write less code - the more code you have the more tests you need thus it requires more work and if you're writing tests for features that are not needed you are simply wasting time
2. Create Knowledge
   • Create design-build teams - leader of the development team has to listen to his/her members and ask smart questions encouraging them to look for the answers and to get back with encountered problems or invented solutions as soon as possible
   • Maintain a culture of constant improvement - create environment in which people will be constantly improving what they are working on - they should know that they are not and should not be perfect - they always have a field to improve and they should do it
   • Teach problem-solving methods - development team should behave like small research institute, they should establish hypotheses and conduct many rapid experiments in order to verify them
3. Build Quality In
   • Synchronize - in order to achieve high quality in your software you should start worrying about it before you write single line of working code - don't wait with synchronization because it will hurt
   • Automate - automate testing, building, installations, anything that is routine, but do it smartly, do it in a way people can improve the process and change anything they want without worrying that after the change is done the software will stop working
   • Refactor - eliminate code duplication to ZERO - every time it shows up refactor the code, the tests, and the documentation to minimize the complexity
4. Defer Commitment
   • Schedule Irreversible Decisions at the Last Responsible Moment - you should know where you want to go but you don't know the road very well, you will be discovering it day after day - the most important thing is to keep the right direction
   • Break Dependencies - components should be coupled as loosely as possible to enable implementation in any order
   • Maintain Options - develop multiple solutions for all critical decisions and see which one works best
5. Optimize the Whole
   • Focus on the Entire Value Stream - focus on winning the whole race which is the software - don't optimize local inefficiencies, see the whole and optimize the whole organization
   • Deliver a Complete Product - teams need to have great leaders as well as great engineers, sales, marketing specialists, secretaries, etc. - they together can deliver great final products to their customers
6. Deliver Fast
   • Work in small batches - reduce projects size, shorten release cycles, stabilize work environment (listen to what your velocity tells you), repeat what's good and eradicate practices that creates obstacles
   • Limit work to capacity - limit tasks queue to minimum (one or two iterations ahead is enough), don't be afraid of removing items from the queue - reject any work until you have an empty slot in your queue
   • Focus on cycle time, not utilization - put in your queue small tasks that cannot clog the process for a long time - reduce cycle time and have fewer things to process in your queue
7. Respect People
   • Train team leaders/supervisors - give team leaders the training, the guidance and some free space to implement lean thinking in their environment
   • Move responsibility and decision making to the lowest possible level - let your people think and decide on their own - they know better how to implement difficult algorithms and apply state-of-the-art software frameworks
   • Foster pride in workmanship - encourage passionate involvement of your team members to what and how they do

If this brief introduction to Lean Software Development is still not enough for you I strongly recommend buying and reading Poppendiecks' book "Implementing Lean Software Development - from Concept to Cash".