Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu/atom
blfr6@https://blog.hu
©2024 blog.hu
https://agilitas.blog.hu/2014/02/17/scrum_master_reference_card_series_sustainable_pace
Scrum Master reference card series_sustainable pace
2014-02-17T14:50:17+01:00
2014-02-17T14:50:17+01:00
T. Balázs
https://blog.hu/user/851199
<ul style="margin-top: 0pt; margin-bottom: 0pt;" id="docs-internal-guid-01c176c9-4019-f7ef-9ae2-beb94a7207b9">
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">General qualities</span></p>
</li>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Sustainable pace is the tool and time where the team concentrates on its self improvement. It is an investment that brings its returns in higher business value delivered per sprint. Without sustainable pace a growing velocity is a vanity metric.</span></p>
</li>
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">It is not for covering up the slips on the estimated times</span></p>
</li>
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Its amount should be constant enough to be able to introduce metrics on it</span></p>
</li>
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Team has improvement backlog</span></p>
</li>
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Team has impediment backlog</span></p>
</li>
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Team has tech debt backlog</span></p>
</li>
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">These issues have to be treated as user stories, and planned. Preferably during the sprint planning meeting. A short time-box should be enough for it. Only real life practice will tell what “short” is.</span></p>
</li>
</ul>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: bold; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">In sprint planning</span></p>
</li>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">PO agrees to what the team commits to deliver by end of sprint:</span></p>
</li>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">improvement introduced. Team knows </span></p>
</li>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">what steps will be made > action plan</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">how the success will be measured</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">when will we be there > done criteria</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">owner of improvement volunteered</span></p>
</li>
</ul>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">impediment cleaned away. Team knows</span></p>
</li>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">what steps will be made > action plan</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">how the success will be measured</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">when will we be there > done criteria</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">owner of impediment volunteered</span></p>
</li>
</ul>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Tech Debt cleared and presented</span></p>
</li>
</ul>
<li dir="ltr" style="list-style-type: circle; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Tech Debt</span></p>
</li>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">prioritized backlog (high, medium, low)</span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">High, medium and low items all must get their share of being cleared! </span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Team has a fix day every week when they give presentation. </span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">The presentation begins not earlier than 17:00</span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">Every presentation day gives place to two or three presentations (each not longer than 15 minutes)</span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">preparing for the tech dept presentation is part of the sustainable pace</span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">every team member must present and be present</span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">in the sprint planning meeting </span></p>
</li>
<ul style="margin-top: 0pt; margin-bottom: 0pt;">
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">the tech dept topics are chosen</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">presenter volunteers</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">preparation resources are decided upon</span></p>
</li>
<li dir="ltr" style="list-style-type: disc; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">topic is publicised within the organization</span></p>
</li>
</ul>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">scrum master prepares QA page for the attending crowd</span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">best practices are learned and applied for ever better presentations</span></p>
</li>
<li dir="ltr" style="list-style-type: square; font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">
<p dir="ltr" style="line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt; text-align: justify;"><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">scrum master has various statistics on the subject</span></p>
</li>
</ul>
</ul>
</ul>
<p><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;"></span></p>
<p><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">author: Balázs Tornai</span></p>
<p><span style="font-size: 15px; font-family: Arial; color: #000000; background-color: transparent; font-weight: normal; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline;">please comment to: Twitter @Bal_A_gile or balazs.tornai@agilitas.hu</span></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2014%2F02%2F17%2Fscrum_master_reference_card_series_sustainable_pace%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2014%2F02%2F17%2Fscrum_master_reference_card_series_sustainable_pace%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2014%2F02%2F17%2Fscrum_master_reference_card_series_sustainable_pace%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Scrum Master reference card series_sustainable pace"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2014/02/17/scrum_master_reference_card_series_sustainable_pace#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/5818738" border="0" /></a><br /></p>
team
fenntartható_fejlődés
agile
scrum
openagile
agile_principles
agilis_szemlélet
agile_tools
agile_team
scrum_mastery
scrum_master-ség
önfejlesztő_csapat
self_improvement_of_team
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2013/03/04/agile_principles
Agile Principles - magyarul
2013-03-04T23:11:38+01:00
2013-03-04T23:11:38+01:00
Janovszki Zsolt
https://blog.hu/user/216090
<p>Számunkra a legfontosabb az <strong>elégedett ügyfél</strong>, amit az értéket képviselő szoftver korai fázisban történő átadásával, majd az értéknövelő fejlesztések folyamatos szállításával érünk el</p>
<p>A <strong>követelmények változását a fejlesztés késői fázisában is elfogadjuk</strong>. Az agilis folyamatok a megrendelői versenyelőny növelésének eszközeként fogják fel a változást</p>
<p><strong>Működő szoftvert szállítunk</strong> néhány héttől néhány hónapig terjedő gyakorisággal. Ezen belül preferáljuk a rövidebb szállítási gyakoriságot</p>
<p>Az<strong> üzletnek és a fejlesztésnek</strong> napi szinten, az elejétől a végéig <strong>együtt kell dolgozniuk</strong> a projekten</p>
<p>Motivált egyénekre építsd a projektet! Nyújts megfelelő környezetet, támogasd őket, és bízz bennük, hogy <strong>megcsinálják, amit meg kell csinálniuk</strong></p>
<p>A leghatékonyabb módja a fejlesztő csapat részére történő információ átadásának, illetve az információ áramlásnak a csapaton belül a <strong>személyes megbeszélés</strong></p>
<p>Az előrelépés elsődleges <strong>mértékegysége a működő szoftver</strong></p>
<p>Az agilis folyamatok a fenntartható fejlesztést támogatják. A szponzoroknak, a fejlesztőknek és a felhasználóknak képesnek kell lenniük előre nem meghatározott ideig fenntartani az <strong>állandó ütemben történő haladást</strong></p>
<p>A<strong> technikai kiválóságra törekvés</strong> és a jó tervezés erősíti az agilitást</p>
<p>Simplicity- a <strong>nem elvégzett munka maximalizálásának</strong> művészete - esszenciális</p>
<p>A legjobb architektúrákat, specifikációkat és terveket az <strong>önszerveződő csapatok</strong> képesek letenni az asztalra</p>
<p>Előre meghatározott időszakonként a csapat elgondolkozik azon, hogy miként lehetnének még hatékonyabbak, és ezután <strong>a megbeszélés eredményének megfelelően formálják</strong> át a viselkedésüket, hozzáállásukat</p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2013%2F03%2F04%2Fagile_principles%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2013%2F03%2F04%2Fagile_principles%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2013%2F03%2F04%2Fagile_principles%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Agile Principles - magyarul"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2013/03/04/agile_principles#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/5117148" border="0" /></a><br /></p>
manifesto
agile
agile_principles
működő_szoftver
agilis_szemlélet
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2012/11/28/agilis-coach-az-agilis-szervezetben
Agilis coach az agilis szervezetben
2012-11-28T12:00:00+01:00
2012-11-28T12:00:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p><span style="font-family: times new roman,times;"><em><span style="font-size: 12pt;" lang="HU">Alan Atlas, CST, CSC, Agile Coach, Rally Software and Mark Kilby, CSM, Agile Coach, Rally Software</span></em> </span></p>
<p>A coaching és a tréning elengedhetetlen elemei az agilis módszertan bevezetésének. Ezt nehéz lehet elfogadni bizonyos esetekben mivel az agilis kereteket könnyű átlátni, mégis rengeteg apró részletre kell odafigyelni, hogy kezelhessük az agilis átalakulás összetett folyamatát. Tagadhatatlan, hogy hasznosak az elérhető külső források pl.: könyvek, weboldalak, kurzusok és tanácsadók. A szervezetek többségének mégis szüksége van egy olyan személyre, aki érti az agilis átalakítás finomságait, és azt el tudja helyezni egy adott szervezeti kontextusban. Így biztosítva, hogy az átalakítás olyan sikeres legyen, amennyire csak lehetséges. Mi úgy hivatkozunk erre a szerepre: „a beépített agilis coach”. Ha csak lehet, kifejezetten bátorítjuk megbízóinkat, hogy azonosítsák ezeket a személyeket a szervezeten belül, ahogy egyre nő az igény a mind mélyebb agilis tudás elsajátítására és alkalmazására.</p>
<p>Agilis coachként számtalan emberi tulajdonság, tudás és tapasztalat kap központi szerepet, az ezek közüli választás pedig egy nagyon kényes folyamat. Ebben a cikkben tisztázzuk, hogy mikor kell egy agilis coach, mit is csinál tulajdonképpen, és adunk egy pár hasznos tippet, illetve miként hozható létre a saját belső „agilis coach”.</p>
<h1>1. Mikor kell egy agile coach?</h1>
<h2>1.1. A coaching szükségességének tünetei</h2>
<p>Sok cég egyedül indul el az agilis úton. Néhányan kitartanak a DIY (csináld magad) módszer mellett, de vannak akik amellett teszik le a voksukat, hogy egy külső professzionális agilis coach/tanácsadó segítségével járják azt végig.</p>
<p>Amint az agilis módszertan gyökeret ver a szervezetben, többnyire önmagától nyilvánvalóvá válik (vagy az agilis tanácsadó javasolja így), hogy a vállalkozásnak ideje létre hozni egy belsős coach pozíciót. Ez minden esetben jobban szolgálja az agilis irányba fejlődő szervezet érdekeit.</p>
<p>Azonban néha ez a szükségszerűség nem is olyan nyilvánvaló. Különösen a „csináld magad” szervezeteknek tart sokáig, hogy felismerjék: agilis tudás mindentől függetlenül is létezik, és az ő esetükben nincs belőle elég a szervezeten belül. Emellett az egy ösztönös vagy jobb esetben tervezett döntés, hogy egy szervezet mihez kezd a felgyűlt belső agilis tapasztalatokkal.</p>
<p>Íme néhány negatív jelenség ami egy szervezet elengedhetetlen szükségét jelzi egy jól finanszírozott, központilag támogatott, biztos lábakon álló és állhatatos agilis tanácsadó jelenlétének:</p>
<ul>
<li>Nem lehet egyértelműen megállapítani, hogy a meglévő agilis csapatok valóban sikeresen működnek-e</li>
<li>A csapatok teljesítménye széles skálán mozog</li>
<li>A csapatok nem kielégítően alkalmazzák az agilis eszközöket, nincs meg a várt áttörés, illetve nem látszanak az elvárt előnyök a korábbi működéshez képest</li>
<li>A külsős tanácsadó válik a strukturális változtatások kerékkötőjévé
<ul>
<li style="list-style-type: none;">
<ul>
<li>Pénzügyi okból – egyszerűen túl sokba kerül</li>
<li>Nem képes teljesíteni az elvárásokat</li>
<li>Nem elég tapasztalt</li>
</ul>
</li>
</ul>
</li>
<li>Az agilis módszertanok alkalmazása csapatok helyett programokban/projektekben jelentkezik</li>
<li>A cégen belül egyes szervezetek azon kapják magukat, hogy nincsenek szinkronban a már agilis szervezeti egységekkel</li>
</ul>
<p> Az első három pont az agilis csapatok teljesítményét nézi. Azaz: ha már nyakig van a cég az agilis átalakításban, de nem tudja megmondani, hogy hol tartanak az egyes csapatok, vagy ha a csapatok gyengén szerepelnek, jobb ha a saját kezébe veszi a kezdeményezést. A PMO világában ilyenkor még több szabály és új felügyeleti eszközök alkalmazásával kezelnék a helyzetet. Az agilis világban ellenben támogatással, tréningekkel, képzéssel kell segíteni, hogy a csapatok minél sikeresebben vegyék az agilis átalakítás akadályait. Ez a segítség biztosítja, hogy a lehető legtöbbet profitáljanak az új módszertanok alkalmazásából. Javasolt, hogy az agilis módszertan bevezetésében felgyülemlett tapasztalatokat, és a szervezetre jellemző speciális eseteket rendszerezzék. Ezzel nagyban segíthető a belső tréning és coaching eredményessége.</p>
<p>Ennek legjobb módja egy olyan személy alkalmazása, aki mélyen ismeri és érti az agilis módszertanokat, egyben fel tudja mérni, mikor ér el egy bizonyos fejlettségi szintet az agilis bevezetés, és ezután mint coach tudja támogatni a teameket (lásd alant).</p>
<p>A következő szimptóma azt a helyzetet írja le, amikor a szervezet túlnő a külsős agilis tapasztalat forrásán. Ez esetben önjáróvá kell válni, és a további agilis fejlődés motorja a belső indíttatás lesz. Ennek a pontnak a lényege akkor érezhető, ha már túljutottunk a kívülről indukált agilis bevezetés tréningjein.</p>
<p>Az utolsó két szimptóma természetes következménye az agilis adaptáció sikeres voltának. Végül minden bevezetés eredményeként megjelenik az az igény, hogy az agilis alapelveket a nagyobb projektekben is alkalmazzák. Az is fel fog tűnni, hogy amikor az agilis módszerek meggyökeresednek, a fejlesztői csapatokon kívüli más szervezetek is tréningeket kérnek a témában, hogy alkalmazkodni tudjanak az agilis csapatok által diktált új ritmushoz és stílushoz, kultúrához.</p>
<p>A figyelmes olvasó bizonyára észrevette, hogy hangsúlyozzuk a belső coach szükségességét amennyiben az agilis átalakítás döcögve halad és akkor is, ha épp kifejezetten sikeres. Más szóval, mindenképp helye van az agilis coachingnak minden szervezetben, ha az agilis módszertanok bevezetése útjára léptek vagy lépni fognak.</p>
<h1>2. Mit csinál egy coach?</h1>
<h2>2.1. Tréning azoknak, akik még nem ismerik az agilis módszertanokat</h2>
<p>Az agilis coach egyik fő feladata a tréning. Újonnan létrejött csapatoknak, alkalmazottaknak, menedzsereknek és felső vezetőknek mind szükségük van tréningre az agilis bevezetés kezdeti lépéseiben. A képzésekre azonban még azután is folyamatosan szükség van, hogy a teljes szervezet profin elsajátította az agilis technikákat (pl.: az új kollégáknak is meg kell tanítani, hogyan illeszkedhetnek be a helyi agilis környezetbe).</p>
<h2>2.2. Coaching</h2>
<h3><br />2.2.1. Új csapatok indítása</h3>
<p> A coaching folyamata a tanácsadásból, hibák javításából, javaslatok tételéből és bármi más segítség megadásából áll, hogy a csapatok javíthassanak az agilis bevezetés hatékonyságán. Miközben az olyan keretek, mint a SCRUM relatív egyszerűek, rengeteg a hibalehetőség és a finomhangolás/optimalizálás helye és igénye, amikor egy csapat először próbálja bevezetni. A coach-tól elvárt, hogy bevesse minden tapasztalatát a csapatok terelgetésében, ahogy azok először próbálkoznak az agilis alapelvek értelmezésével és alkalmazásával.</p>
<h3>2.2.2. Team értékelés és finomhangolás</h3>
<p>Ez egy igen érzékeny folyamat, ahol a coach általában megfigyel egy csapatot, majd ezen tapasztalatok alapján javasol problémamegoldó lépéseket. Ezek lehetnek tréningek, coaching egyes kiemelt agilis területeken, vagy személyreszabott tanács, hogy miként helyezzék el az adott csapatot az agilis szervezeten belül.</p>
<p>Sokan félreértik ezeket az értékeléseket és úgy tekintenek rájuk mint egy „standard agilis folyamatnak” történő megfelelési mutatót. A helyes szemlélet az, ha olyan eszközként tekintünk rájuk melyek segítenek feltárni a hatékonyabb agilis bevezetési módokat és megmutatják, miként érhető el a lehető legteljesebb üzleti érték.</p>
<p>Amikor van már egy bejáratott alap keretrendszer mint mondjuk a SCRUM vagy az XP, megtalálni ezek legoptimálisabb bevezetési módjait talán a legegyszerűbb kihívás, de semmiképp sem az egyetlen.</p>
<p>Figyelem: Ha az értékelés eredményére mint „megfelelősségi fok”-ra tekintünk, akkor a coach-ot óhatatlanul is egy újabb „folyamat felügyelő”-nek fogják látni, és hitelét veszti, mint a csapat bizalmát bíró team-tag.<em> <br /></em></p>
<h3>2.2.3. Folyamatos Oktatás</h3>
<p> Gyakran a tréningek bőségében dúskálnak a fejlesztő csapatok az agilis bevezetés elején, de mások, mint például a menedzsment, üzleti fejlesztés, értékesítés, marketing, PMO (projekt menedzsment iroda) és más szervezetek, nem kapják meg ugyanazt a szintű oktatást. Ezeket a szervezeteket az agilis módszertanokba bevezetni csak az első lépés ahhoz, hogy megőrizhessék hatékonyságukat mint az üzleti élet egyik résztvevői.</p>
<p>A coach ilyen folyamatos képzési és oktatási tevékenysége kevésbé intenzív és aprólékos, mint egy célzott agilis team képzés. Ugyanakkor a legtöbb esetben ez a helyes szintű információmennyiség ami hatékonyan adható át egy szervezetnek az agilis bevezetés korai fázisában.</p>
<h3>2.2.4. Támogatás és vezetés</h3>
<p>Csakúgy, mint ahogy a PMO módszerben van központosított folyamatirányítás, megvan az igény, hogy folyamatosan átlássák az agilis bevezetés éppen aktuális helyzetét a cégen belül. Ez lehet olyan triviális módszer, minthogy valaki egyenként végigmegy az agilis csapatokon és közvetlenül tájékozódik, vagy olyan komplex, mint tervezni egy irányítási rendszert, ami agilis metrikák sokaságát dolgozza fel, hogy ezáltal segítse az agilis bevezetést az egész cégen belül.</p>
<h3>2.2.5. Tanácsadás</h3>
<p>Az agilis keretrendszerek nem részletezik az agilis bevezetés minden aspektusát, különösen nem nagy szervezetekben és nagy projektekben. Egyáltalán nem magától értetődő, hogy miként kell az agilis módszertanokat bevezetni egy 500+ főt felölelő projektben, és elérni az integráció és hatékonyság azon fokát, mint egy jelentősen kisebb projektben, vagy csapatban. Egy agilis coachtól elvárt, hogy naprakész legyen az adott iparág sajátosságaiból, különösen ami az agilis módszertanok adott területen belüli alkalmazását illeti. Ez igaz kis és nagy projektekre egyaránt. Az egyes csapatok szintjén pedig képesnek kell lennie, hogy elősegítse a fejlődést, és támogassa a programokat az adott tudás sikeres alkalmazására.</p>
<h3>2.2.6. Közösség Formálás és Vezetés</h3>
<p>Kiemelt szolgáltatása a belső agilis coachnak, hogy elősegíti és kineveli a szervezeten belül az agilis módszertanok alkalmazóinak közösségét. Ez a közösség lesz a platform, hogy az emberek kicseréljék tapasztalataikat, megoldjanak helyi kihívásokat, problémákat. Ezeket a közösségeket a szervezet agilis átalakításának korai folyamatában létre kell hozni. A kezdetekben, mint egy speciális érdeklődésű kis csoport, ez a közösség jó hangulatú platformja lesz az agilis fejlődésnek és a tanulásnak. Különösen igaz ez, ha az agilis coach rendszeresen bedob hasznos és aktuális témákat a szélesebb értelemben vett agilis közösségből (akár az iparágon kívülről is), hogy azokat a csoport feldolgozza, alkalmazásuk területeit megkeresse.</p>
<p>A jó coach kinevel egy közösséget, ami csomópontként funkcionálva forrása az egyes csapatok, csoportok és szervezetek közötti új ötletek, elképzelések és probléma megoldási módszerek születésének. Ezen a csomóponton a coach gyengéden irányíthatja a beszélgetéseket, és beolthatja a résztvevőket egy kifinomult gondolkodásmóddal. Fontos, hogy ezt anélkül tegye, hogy túl irányító, vagy adott esetben elutasító lenne egyes egyénekkel szemben. Az ilyen közösségek agilis bevezetés lezárulta után is forrásai lesznek az új ötleteknek, módszereknek.</p>
<h2>2.3. Példamutatás az agilis működésben</h2>
<p>A legkritikusabb dolog amit egy agilis coachnak tennie kell egy szervezeten belül, az a folyamatos személyes példamutatás az agilis működésben, amit ő maga is képvisel, bevezetni igyekszik. Ennek megnyilvánulásai például: hatékonyságnövelő megbeszélések és tervezések elősegítése, konstruktív konfliktusmegoldások, a hibák mihamarabbi feltárása és ezek minél láthatóbb és transzparensebb megoldásának segítése. Lásd Davies és Sedky könyvét: „Agile coaching” valamint Tabaka könyvét, utóbbi témája a részletek feltárásáért történő együttműködés. Adkins könyve az agilis csapatokról, ezen példamutató megnyilvánulások széles skáláját vonultatja fel pl.: “…és ide kerül a Te kedvenced…” – ami arra utal, hogy egy coachnak mindig késznek kell lennie arra, hogy alkalmazkodjon a felmerülő legkülönbözőbb helyzetekhez. A folyamatosan előremutató és fejlődést elősegítő viselkedésekben történő példamutatás kulcskérdés egy agilis coach életében.<strong><em> <br /></em></strong></p>
<h1>3. A saját coach kinevelése, avagy mi kell egy agilis coach-hoz</h1>
<h2>3.1. Értékek</h2>
<p>Amíg az Agilis Kiáltvány lefektette egy hatékonyabb munkavégzés kereteit, mi ajánlunk egy értékrendszert ami elvárt egy agilis coachtól:<em> <br /></em></p>
<h3>3.1.1. Tettek a puszta beszéddel szemben</h3>
<p>Az agilis filozófia az emberek együttműködését tartja legértékesebbnek. Ezért egy jó agilis coach előszeretettel használja az interaktív tanítási technikákat. Röviden átbeszéli az új koncepciókat az érdekeltekkel, és bevonja a hallgatóságát a megbeszélésekbe, tevékenységekbe és önszervező kísérletekbe. Ezzel bátorítja az embereket, hogy a gyakorlatban megvalósítsák a tanultakat. Ez a fajta coaching tudás az irányítatlan egyéni stílustól az évek során finomított és tökéletesített professzionális tréning tudásig terjedhet.</p>
<h3>3.1.2. Minden részletre kiterjedő megfigyelés (Szokrateszi kérdezési módszer) az elszámoltató kikérdezéssel szemben</h3>
<p>Bár az agilis coach szélesebb tudással rendelkezik az agilis módszertanokról, mint bárki a szervezetben, tudniuk kell, hogy nem mindig van kéznél náluk sem a helyes válasz. Épp ezért egy agilis coach nem úgy fog kérdezni, hogy „És akkor miért nem próbáljátok meg a pair-programming módszert?” de helyette rávezeti a csapatokat, hogy maguknak fedezzék fel és döntsék el, hogy mi lesz nekik a leghatékonyabb megoldás. Hogy elérje ezt, a coach olyan kérdéseket tehet fel mint: “Milyen problémáitok vannak a minőséggel? Hogy látjátok, mi működik és mi nem, a jelenlegi felállásban? Van alternatív megoldás, amit kipróbálhatunk a jobb eredmény reményében? Érdemes fontolóra venni ezek alapján a pair-programming alkalmazását?” Az ilyen jellegű kérdéssor segíti a csapatokat, hogy maguknak válogassák össze azokat a gyakorlatokat, melyek a legmegfelelőbbek a rájuk jellemző környezetben A jó agilis coach kerüli, hogy a csapatra felülről erőltessenek egy új módszertant.</p>
<h3>3.1.3. Tárgyalásvezetés a parancsoló vezetéssel szemben</h3>
<p>Az agilis coach biztosítja, hogy mindenki megoszthassa a többiekkel amit gondol, és nem egy felülről diktált menetrendet erőltet. Miközben eléri a kiegyensúlyozott inputot a megbeszélés levezetésével, az agilis coach egyben segíti a csapatot, hogy konszenzus alapján döntsenek, és nem ő dönt a csapat helyett. Az agilis coachnak ezt a fajta tárgyalásvezetői feladatot a szervezet minden szintjén meg kell tudnia valósítani a kisegítő személyzettől a felső vezetésig. Így minden szinten profitálnak az együttműködésen alapuló önmenedzselésből.</p>
<h3>3.1.4. Közösségorientált a hierarchikus berendezkedéssel szemben</h3>
<p>Az agilis coach úgy tekint egy szervezetre, mintha az egy önálló ökoszisztéma volna, és tisztában van azzal, hogy a legapróbb változtatás is alapjaiban és megjósolhatatlan módon befolyásolhatja a szervezetet. Minden változtatás gyakorlatilag egy kísérlet, ami számos tervezés-megvalósítás-ellenőrzés-akció ciklusból áll. Ezek a ciklusok segítenek felderíteni, hogy a kérdéses változtatás hatékonyságnövelő volt, vagy adott esetben kártékony a csapat és a szervezet szempontjából. Ez a szemléletmód jelentősen eltér a klasszikus szervezeti felépítésekhez képest, ahol megkíséreljük beskatulyázni a munkaterületeket, és hierarchiát tükröző címekkel ruházzuk fel az embereket. Ezzel szemben az emberek a legritkább esetben illenek bele ezekbe a skatulyákba. Ehelyett keresztül kasul vándorolnak a szervezet egyes részein belül. Nagyjából úgy, ahogy a borostyán kúszik át a drótkerítésen. Az agilis coach azt figyeli, hogy ezek a „borostyánok” hol támasztják és hol fojtják meg a szervezet agilis átalakítását, és a megteszi kellő lépéseket, hogy új változtatásokkal a helyes irányba terelje a folyamatot.</p>
<h2>3.2. Emberi tulajdonságok</h2>
<p>A fent leírt tulajdonságokon túl, a következőkkel sem árt tisztában lenni egy agilis coach esetében:</p>
<h3>3.2.1. Aktív és mély figyelem</h3>
<p>„Ez több mint aktív odafigyelés.” Ahogy Adkins írja a könyvében: több szintű figyelem létezik, és egy jó coach tudja, hogy nem csak meghallania kell a szavakat, hanem érteni és érezni is kell a szavak mögötti kontextust.</p>
<h3>3.2.2. Szenvedéllyel Tanítani</h3>
<p>Egy coach nem feltétlenül szenvedélyes minden területen, de szükséges hogy szenvedélyt mutasson egyes témák iránt. Ez dönti el, hogy miként tanít többeket egy osztályteremben, vagy klasszikus szemtől-szemben tréneri körülmények között. Az ilyen coach a többiek szemében, energikus, motiváló személyként jelenik meg.</p>
<h3>3.2.3. Az örök tanuló</h3>
<p>Az agilis módszertanok folyamatos változásban vannak, ahogy az azokat használók közössége növekszik és a módszertanok a munkájukon keresztül megmérettetnek és tapasztalatokat cserélnek. Egy agilis coachnak szemmel kell tartania ezeket a trendeket, hogy ha kell bevezethesse őket a szervezetben.</p>
<h3>3.2.4. Örökre Szolgál</h3>
<p>A legjobb coach-ok mindig szolgálják a csapatukat, a közösségüket és a szervezetüket. Ez nem azt jelenti, hogy elnyomják a saját céljaikat, ambícióikat. A „Rally”-nél az egyik fő értékünk a „saját valóság megteremtése”. Ennek az értéknek lényegi eleme, hogy mindannyian folyamatosan próbáljuk meg felismerni és fellelni a legbelsőbb mozgatórugóinkat és azokat összeegyeztetni a szervezeti célokkal Így tudjuk hatékonyan szolgálni saját magunk és a szervezetet. A jó agilis coach példát állít ennek a viselkedésnek és tanítja a többieket, hogyan tehetik ők is ezt.</p>
<p>Hogy átgondoljunk további karakterisztikákat az agilis coachokról, javasoljuk, hogy nézd át Rising and Mann könyvében kifejtett a mintákat a „Fearless Change” témában, vagy megfontolás tárgyává tenni Roger Brown listáját az ő 2009-es blog post-jából. </p>
<h2>3.3. Felvenni vagy Belülről Választani?</h2>
<h3><br />3.3.1. Építsd Magad, vagy Vedd Meg</h3>
<p>Vannak jó érvek amellett, hogy a cégen belül keressük meg az agilis coach-ot. Az agilis átalakítás kultúrára történő hatása, mély ismerete a belső politikai viszonyoknak, történelmi kontextus, üzleti környezet és más cég-specifikus faktorok komoly fegyvertény lehet egy coach eszköztárában. Ha a hatékony coach munkát nézzük, ezek legalább olyan fontosak, mint bármely más coach tulajdonság és minőség melyeket feljebb már említettünk.</p>
<p>A másik fontos dolog egy céges coach esetében az elhivatottság és pozitív hozzáállás. Valaki, aki hisz az agilis módszertanok erejében és előnyeiben, sokkal valószínűbb, hogy helyesen fogja azokat alkalmazni. Véleményünk szerint az energikus odaadás sokkal értékesebb mint az érzelemmentes tudás.</p>
<p>A harmadik fontos előny, ami miatt érdemes az agilis coachot a cégen belül keresni, az az illető garantált ismertsége a szervezeten belül, főleg ha pozitív, motivált és hozzáértő személyként ismerik. A szakmai hitel kulcsfontosságú egy coach életében. Ha valaki már felépítette ezt a hitelességet, legtöbbször sok év kitartó munkájával, az döntő fontosságú lehet az illető kiválasztásában. Mindez elengedhetetlen ahhoz, hogy legyőzzük a cégekben általánosan meggyökerezett szemléletet, miszerint „nálunk minden más”. Az a személy, aki már sikereket tud felmutatni az agilis módszertanok használatában a helyi céges viszonyokon belül, sokkal hitelesebb lesz a többiek szemében, mint bármely külsős. </p>
<h2>3.4. Pár Jótanács Coach Felvételhez</h2>
<p>Ha úgy döntünk, hogy a cégen kívülről keresünk embert, abban a rendhagyó felvételi helyzetben találhatjuk magunkat, hogy nem tudjuk megítélni a jelölteket, mivel nincs meg a megfelelő belső tudás a szakterületen. Hogy ezt leküzdhessük, alkalmazzunk erre az időszakra egy külsős agilis coach-ot, aki segít végigvinni a kiválasztás folyamatát.</p>
<p>Ne csak kérdésekkel bombázzuk a jelölteket egy interjú szobában. Rengeteg jó forrás van a területről, de az agilis alapelvek tőlük függetlenül azt követelnék meg, hogy „együttműködjenek” és ezáltal „eredményeket mutassanak fel”.</p>
<p>Egy pár kérdés ízelítőképp:</p>
<ul>
<li>A jelölt coach vezessen le egy megbeszélést a szervezeten belüli valamely csapattal. A csapatnak szenvedéllyel kell viseltetnie a téma iránt. Ez lehet egy dizájn, vagy stratégiai kérdést taglaló megbeszélés. Legyenek egymással ütköző álláspontok. Figyeljük meg, hogy a jelölt miként segíti a csapatot, hogy az önálló döntésre jusson a témában. Természetesen egy titoktartási szerződés ajánlott egy ilyen interjú szituációban.</li>
<li>Tegyük párba a jelöltet valakivel a szervezetből, hogy együtt dolgozzanak ki egy tréning anyagot vagy kódrészletet.</li>
<li>A jelölt tanítson egy adott témáról a legkülönbözőbb kollégák csoportjának a szervezeten belül. Az ebédelj-és-tanulj alkalmak tipikusan jók erre.</li>
<li>Figyeld meg miként reagál a coach egy váratlan eseményre. Próbálkozz például a Powerpoint Karaoke módszerrel. Lényege, hogy az előadónak olyan slideokból kell prezentálnia, melyeket korábban még nem látott. A slideokat automatikus váltásra állítsuk, mondjuk 20 másodpercre. A játék lényege, hogy a lehető legkoherensebb előadást rögtönözze belőle a jelölt.</li>
</ul>
<h1>4. Összefoglalás</h1>
<p>A coaching és tréning elengedhetetlenek az agilis átalakítás folyamatában. A legtöbb jelentősebb méretű cégnek, nagy értéket képvisel egy stabil, megbízható, belső agilis tudásforrás létrehozása és fenntartása (gyakran úgy hivatkoznak rá, mint „belső agilis coach”). Vannak felmerülő és érzékelhető szimptómák egy vállalkozásban, amik azt mutatják, hogy egy belső agilis coach igen hasznos extra lehet az agilis tevékenységekhez.</p>
<p>A belső agilis coach feladatai különbözőek: van benne klasszikus tréning, coaching és még sok egyéb. Agilis coach-nak lenni elvárást is támaszt számos emberi tulajdonsággal szemben, valamint különböző késségeket és képességeket igényel. Ezekből, mint megbízó, kiválasztani a legmegfelelőbbet óvatosságot és körültekintést igényel.</p>
<h1>5. Ajánlott irodalom</h1>
<p>“Agile Coaching”, Rachel Davies and Liz Sedley, 2009.</p>
<p>“Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition”, Lyssa Adkins, Addison-Wesley, 2010.</p>
<p>“Collaboration Explained: Facilitation Skills for Software Project Leaders”, Jean Tabaka, Addison-Wesley, 2006.</p>
<p>“Fearless Change: Patterns for Introducing New Ideas”, Mary Lynn Manns, Ph.d., and Linda Rising, Ph.d., Addison-Wesley, 2004.</p>
<p><a href="http://www.agilecoach.net/">http://www.Agilecoach.net/</a></p>
<p>“The Value of an Agile Coach”, Roger Brown, <a href="http://www.Agilecoachjournal.com/index.php/2009-10-15/scrum/the-value-of-an-">http://www.Agilecoachjournal.com/index.php/2009-10-15/scrum/the-value-of-an-</a></p>
<p><a target="_blank" href="http://agile.techwell.com/articles/weekly/agile-coaching-your-agile-company?cd=2&hl=en&ct=clnk&client=firefox-a">Forrás</a><em> fordította Tornai Balázs, válogatta Kulcsár Bence</em></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2012%2F11%2F28%2Fagilis-coach-az-agilis-szervezetben%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2012%2F11%2F28%2Fagilis-coach-az-agilis-szervezetben%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2012%2F11%2F28%2Fagilis-coach-az-agilis-szervezetben%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Agilis coach az agilis szervezetben"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2012/11/28/agilis-coach-az-agilis-szervezetben#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3536952" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2012/02/17/az_agilis_coach_7_buktatoja
Az agilis coach 7 buktatója
2012-02-17T14:15:00+01:00
2012-02-17T14:15:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p><style type="text/css">p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: "Times New Roman"; }h1 { margin-right: 0cm; margin-left: 0cm; font-size: 24pt; font-family: "Times New Roman"; font-weight: bold; }strong { }em { }p { margin-right: 0cm; margin-left: 0cm; font-size: 12pt; font-family: "Times New Roman"; }span.Heading1Char { font-weight: bold; }span.small { }div.Section1 { page: Section1; }</style></p> <p style="margin-bottom: 12pt;" class="MsoNormal"><style type="text/css">p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: "Times New Roman"; }span.small { }div.Section1 { page: Section1; }</style><em><span class="small"><span lang="HU" style="font-size: 12pt; font-family: "Times New Roman";">Lyssa Adkins, CST, Agile Coach</span></span></em><span class="small"><span lang="HU" style="font-size: 12pt; font-family: "Times New Roman";"> </span></span></p> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU">Az agilis coach-oknak komoly munkájuk van és kemény kihívásoknak kell megfelelniük:</span></p> <blockquote> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU"><br /> "Támogassák a csapatot, de se túl sokat, se túl keveset. "<br /> "Legyenek elérhetőek, de ne legyenek levakarhatatlanok. "<br /> "Adjanak ötleteket, de ne legyenek túl mélyen belevonva." <br /> "Coachok legyenek, ne menedzserek."</span></p> </blockquote> <p style="margin-bottom: 12pt;" class="MsoNormal"> </p> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU">Ezek a tanácsok zavarosak sőt, ellentmondásosak is. Nem csoda, ha az agilis coach-ok szerencsétlen viselkedési csapdákba esnek miközben újabb és újabb módokon próbálnak segíteni a csapatoknak. A probléma az, hogy ezek a viselkedési jelenségek alaposan alá tudják ásni egy csapat önszervező képességét és a fejlődését, hogy magasabb teljesítményt érjen el. Ezért hívjuk ezeket bukás-formuláknak.<br /> <br /> Pár év coaching, agilis coach-ok segítése, és sok más coach munka közbeni megfigyelése után, feljegyeztem egy csokorra való buktatót. Egyes coach-ok ideiglenesen felvehetnek egy vagy akár több buktatót is, amikor stresszhatásnak vannak kitéve. Mások folytonosan mutatják ezen buktatók jeleit, olyannyira, hogy a coach maga <b style="">sincs</b> is tisztában vele, vagy azok hatásával a csapatra. <br /> <br /> Ebben a cikkben az agilis coach kifejezést egyben a „scrum master” kifejezéssel tesszük egyenlővé. A nagy teljesítményű csapatok létrehozásáért, a scrum mastereknek és az agilis coachoknak mélyre kell merülniük a „scrum”-ban. Túl a konkrét technikákon egyenesen a munka coach aspektusaiba is, ezért a cikk csak az agilis coach kifejezést fogja használni. Fontos: a cikkben leírt buktatók, és az azok kikerülésének módjai mind az agilis coach-okra, mind a scrum master-ekre egyarán érvényesek. <br /> <br /> Mik is ezek a buktatók?</span></p> <p><strong><span lang="HU">A bukás-formulák, részletesen</span></strong></p> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU">Ím a hét buktató megszemélyesítve. Mindegyik esetében kifejtve a legfőbb jellemvonással.<br /> <br /> <h2>A Kém</h2> A kém épp csak annyi időt tölt a csapat megfigyelésével, amivel fel tudja majd tölteni a következő retrospektívet. <br /> <br /> <h2>A Sirály</h2> A sirály lecsap a standupok idején, összepiszkítja a csapatot (jószándékú megjegyzésekkel és tanácsokkal) majd tovább repül. <br /> <br /> <h2>A Véleménygyilkos</h2> A véleménygyilkos véleményt nyilvánít a csapatmegbeszéléseken, de oly módon, hogy úgy ragaszkodik a saját véleményéhez (vagy egy kiemelt személy véleményéhez), hogy azzal megöli a lehetőségét, hogy a csapat hatékony és magasan eredményes megbeszélést tarthasson. <br /> <br /> <h2>Az Admin</h2> Az admin azzal ássa alá a csapat önvezérlését, hogy felesleges közvetítővé (és más, adminisztrátor jellegű feladatokat ellátó személlyé) válik a megbeszélések szervezésében, a csapat-kérések teljesítésében.</span><br /> <span lang="HU"><br /> <h2>A Hub</h2> A hub (csomópont) úgy viselkedik, mintha ő lenne az univerzum közepe, már legalábbis ami a csapattagok közti kommunikációt és a közvetlen feladatszintű koordinációt illeti. <br /> <br /> <h2>A Pillangó</h2> A pillangó csapatról csapatra száll, épp csak addig telepszik meg, amíg elejt egy bölcsességet, vagy feltesz egy filozófiai kérdést. <br /> <br /> <h2>A Profi</h2> A profi olyannyira bevonja magát a csapat munkájába, hogy csak a fákat látja. „Hogy mi? Hogy egy erdőben lennénk? Ez azt jelenti, hogy innen ki is tudnánk keveredni?”</span></p> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU"><br /> Az összes bukás-módnak ugyanaz az <b style="">eredménye</b> a csapat szempontjából. Elszívja a csapat képességét, hogy valóban magasan teljesítővé váljanak, mert mind az agilis coach-ot nézik, ő van a reflektorfényben. Amikor a bukás-mód valamelyike bekapcsol, valahogy a coach kerül a csapat munkájának fókuszába. Talán a coach túl lerohanós, mint például a „hub”. Pont ennyire romboló hatású, ha a coach túlzottan visszahúzódó, mint a „pillangó”. Mindegyik esetben a coach kerül a középpontba, és az a legrosszabb hely, ahol a coach lehet. <br /> <b><br /> Mi a forrásuk?</b> <br /> Az egó, vagy a folytonosan megosztott figyelem, vagy mindkettő együtt. Bármilyen kombináció lehetséges, amikor egy coach a bukás-mód szorításában vergődik. <br /> <br /> <strong>Az egó normális dolog, nem?</strong> <br /> Természetesen az. Az egó az, ahol az értékítélet, intellektus, tervezés, érzékelés és valóságfelfogás mind összefut. Az tesz alkalmassá, hogy a kockázatokat vállalva megoszd mindenkivel az elképzeléseidet. Teljesen normális és szükséges dolog. Ugyanakkor az egó „én” centrikus. ÉN mit gondolok? NEKEM milyen ötleteim vannak amik segítenek? Mit fognak az emberek gondolni RÓLAM? Ez az „én” gondolkodás azonban könnyen túlzásokba eshet, egy csapat coach-olása folyamán. Miért nem értik amit ÉN értek? Mit fogok ÉN csinálni, ha nem jól csinálják, amit kellene? Mit fognak az emberek gondolni az ÉN csapatomról? Mit fognak az emberek mondani RÓLAM, mint az ő coach-ukról? <br /> <br /> Ami e mögött az „én” gondolkodás mögött van, az a félelem. Félelem attól, hogy a csapat nem fogja tudni a helyes utat, amin elinduljon. Félelem attól, hogy nem lesznek elég jók, abban amit csinálnak, és ez rossz fényt fog vetni a coach-ra. A probléma ezzel a körrel az, hogy a félelem félelmet szül egy olyan öngerjesztő folyamatban, aminek eredményeként a coach nem hagy elég teret a csapatnak, hogy maga tapasztalja meg, mi fog történni, mit tudnának magukból kihozni, és milyen szintre is tudnának fejlődni igazán. A „hub”, az „admin”, a „vélemyénygyilkos”, és a „profi” itt lép be a képbe. Ezek a bukás-módok annak eszközei, amikor a coach úgy akar belefolyni a folyamatokba, hogy biztosítani akarja, hogy a csapat nem tér le a kijelölt ösvényről. A probléma ezzel az, hogy ez egyben annak lehetőségét is kizárja, hogy a csapat valami egészen rendkívülivel rukkolhasson elő. <br /> <br /> <strong>A multitasking rendben van, ugye?</strong> <br /> Nos, nem igazán. A multitasking, és annak közeli rokona, a megosztott figyelem, alapjában véve új dolgok, és az emberi idegrendszer nem igazán erre van építve. Valószínűleg mindannyiunk jól ismerjük a multitasking intézményét – több dolgot csinál az ember egyszerre, melyből általában az egyik olyan egyszerű, hogy szimplán auto-pilot módban elkészül. A folyamatos részleges figyelem egy elég új fogalom ebben a témában, de több mint valószínű, hogy az sem új számunkra. Ilyen: „gyorsan válaszolok erre az e-mailre, amíg elmondod nekem a problémádat, és közben megnézem a Blackberry-met, mert épp rámciripelt. Most ismételd el kérlek még egyszer, hogy miről is akartál velem beszélni?” Olyan mint a multitasking, de van benne egy csavar – az az érzés, hogy az ember bekapcsolva lehet 24/7-ben, folyamatosan azt figyelve, hogy ki, vagy mi követeli leghamarabb ismét a figyelmet. <br /> <br /> A folyamatosan osztott figyelem akkor jelentkezik, amikor a coach egyszerre több csapattal foglalkozik, ami egy elég hétköznapi jelenség. Ez könnyen a „pillangó”, a „kém”, vagy a „sirály” bukás-módok bekapcsolásához vezet. Ezek annak a megoldásnak a különböző megjelenései, amikor valaki jelenléte épp arra elég, hogy azt éreztesse, mintha coach-olna, miközben valójában alig van ott. <br /> <br /> A helyzet a<span style=""> </span>valóságban az, hogy a coachok az idejük egy jelentős részét várakozással töltik. A csapattal kell lenni, figyelni kell a történéseket, és várni kell. De mire? <i style="">Értékes, tanításra használható pillanatokra. </i><br /> <br /> Tanításra használható pillanatok: „azok a kiemelhető átalakítási események, állapotok, amikor maximális a fogadóképesség arra, hogy a csapat új ismereteket sajátítson el." Ezek azok a pillanatok melyekben kikristályosodik egy-egy agilis alapelv, melyet készpénzre lehet váltani. Képes a csapatot egy olyan újabb szintre emelni az agilis módszertan megértésében és alkalmazásában, mely egy kiemelkedő termék elkészültéhez vezet. Ezek az úgynevezett "aha!" pillanatok, mindent egyesítenek és megalapozzák egy magasan teljesítő csapat kialakulását. <br /> <br /> Habár a tanításra legalkalmasabb pillanatok általában egyes tipikus átalakulási ponton megjelennek az egyének szintjén is, -mint pl. elhelyezkedés egy új munkahelyen- minden bizonytalan abban a pillanatban, hogy csapatokkal foglalkozunk. Egy agilis csapat kontextusában, a tanításra alkalmas pillanatok rendszertelenül és váratlanul jelentkeznek. Ezeket nem lehet kikényszeríteni és nem tudható, hogy mikor jönnek velünk szembe. A várakozás improduktívnak tűnhet, de ha nem áll a coach rendelkezésére elegendő idő ahhoz, hogy „csak legyen” a csapattal, ezen pillanatok könnyen észrevétlenek maradnak, vele együtt a lehetőség a kiemelt tanításra. Ha ezek a tanításra kiemelt pillanatok elvesznek, annak eredménye az, hogy a csapat útja egy kimagaslóan teljesítő team felé jelentősen meghosszabbodik.<br /> <br /> <b style="">Mit tehet az agilis coach?</b> <br /> Van egy „visszaállító-mód” – egy mód, hogy elkerüljük vagy legalábbis kikeveredjünk a bukás-módból. A visszaállító-mód lényege, hogy a félelmeket bizalommal kell helyettesíteni. Fontos, hogy itt ismét kiemeljük: a félelmeket bizalomra kell cserélni. Bízni kell abban, hogy a csapat tényleg tudja a megfelelő tennivalókat, még akkor is, ha különbözik attól, amit te csináltatnál velük. Bízni kell abban, hogy visszapattannak a zsákutcákból, vagy olyan megközelítésekből, melyek sehova sem vezetnek, úgyhogy nem neked kell őket megkímélni ezektől az esetleges csalódásoktól. Bízni kell abban, hogy kihozzák magukból a legjobbat, hogy örömet okozzanak a vevőiknek, és természetesen nekünk. Végül bízni kell abban, hogy ha elbuknak, abból tanulnak és ez által csak még jobbak lesznek. <br /> <br /> Nem kis diadal kivívni ezt a bizalmat. Ez egy hatalmas munka, de legalább annyira hatalmas a jutalom is. Egy elegáns mellékhatása ennek a fajta bizalomnak a következő: ahhoz, hogy a bizalom működjön, a teljes figyelmünket fel kell ajánlanunk. Hogy helyet adjunk a bizalomnak, pontosan figyelnünk kell, hogy mi folyik a csapatban és hogy mi „<i style="">akar folyni</i>”.</span></p> <blockquote> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU"><br /> bizalom + figyelem = Jó Coaching (de legalábbis az alapja annak, ami lehetővé teszi a jó coachingot).</span></p> </blockquote> <p style="margin-bottom: 12pt;" class="MsoNormal"> </p> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU">Bár nincs egy kiemelt helyes út, hogy elérjük a fent leírt bizalmat, álljon itt pár tipp, amivel érdemes megpróbálkoznunk: legyünk figyelmesek és gondosak, legyünk kíváncsiak, könnyedek és érzékenyek a másik felé. Ezek jól összedolgoznak, de önmagukban is megállják a helyüket.</span></p> <p style="margin-bottom: 12pt;" class="MsoNormal"><span lang="HU"><br /> <b style="">Figyelmes és gondos</b><b> <br /> </b><span style="">Bármi, amit </span>azért teszünk, hogy figyelmesek és gondosak legyünk egyből segít elkerülni a bukás-módokat. Miközben így teszünk, megtanulhatjuk hogyan legyünk folyamatosan elérhető a csapatnak, és ez növelni fogja az öntudatosságunkat is. A jelenlét és az öntudatosság két hatékony eszköz, hogy tudjuk, mikor érkezik meg egy bukás-mód, és hogy korrigáljuk az eddigi munkát és kikerüljük azt. Bármely könyv John Kabat-Zinn-től jó a figyelmesség és gondosság megtanulásának elkezdéséhez. <br /> <br /> A figyelmesség és a gondosság a fejben szóló zajok elhallgattatásával egyenlő. A zaj lehet például az aggodalom, hogy vajon mi lesz a következő dolog, amit a csapat tenni fog; ítélet arról, hogy a PO túlzottan irányító; bosszankodás, hogy egy csapattag nem igazán vesz részt; lelkesedés, hogy a csapat épp most fejezett be egy új terméket; és rengeteg más hasonló gondolat. Ezek a gondolatok mind ott vannak, és folyamatosan megpróbálják átkönyökölni magukat a belső védelmi vonalakon, hogy a figyelem középpontjába kerüljenek. Ezek ráadásul hangosak és elterelik a figyelmemet arról, amit coachként kéne tenni: ráhangolódni, hogy mi is van a csapattal <i style="">éppen most.</i> Nem arra, hogy mi történt a múltban, nem azon aggodalmaimra, hogy mi fog történni a jövőben, hanem arra, mi is történik a jelen pillanatban. Épp ezért azonosítják sokszor a figyelmességet és gondosságot a „jelenléttel”. Amikor jelen vagyunk, képesek vagyunk érzékelni, hogy mi is történik a csapattal, és tudunk segíteni nekik a következő lépésben, hogy konstruktívan a pozitív irányba fejlődjenek. Visszatekintve gyakran azt látom, hogy az ösvény, amin elindult a team tökéletes volt, és egyben teljesen más is, mint amit én javasoltam volna, ha az aggodalom, ítélet, bosszankodás, lelkesedés vezéreltek volna. <br /> <br /> <b>Légy kíváncsi <br /> </b><span style="">Amik</span>or megfigyelünk egy csapatot munka közben, legyünk mindig érdeklődők, hogy mi is történik valójában. Olyan kérdéseket tegyünk fel magunknak mint pl.: Mi akar itt történni? Hova akarnak eljutni ezzel? Mi lehetne nekik hasznos ebben? Ezután figyeljük tovább a történéseket. Adjunk magunknak időt, hogy átlássuk mi is folyik ott valójában és tiszta képet kapjunk a csapatról – egy olyan képet, amit nem befolyásolnak az ítéleteink és feltevéseink. Ezután vegyük szemügyre, hogy <i style="">velünk</i> mi történik. Milyen bukás-mód vár ránk a sarkon? Mit érzünk? A félelem motivál esetleg? Hol tart a bizalom? Hol jár a figyelmünk? És ekkor, amikor tisztán látjuk a csapatot, pontosan értjük, hogy mi zajlik bennünk, elkezdhetünk gondolkodni azon, miként coach-oljuk őket. <br /> <br /> <b>Csak könnyedén </b><span style=""><br /> Lehet, hogy annak felismerése, hogy épp valamilyen bukás-módban vagyunk elegendő lehet számunkra az adott pillanatban. </span>Elképzelhető, hogy az, ha tudomásunkra jut amikor bukás-módba kapcsolunk már egy nagy előrelépés lehet. Haladjunk ebbe az irányba, és legyünk tisztában ezzel. Természetesen támaszkodhatunk az idő által csiszolt relexeinkre is ha stresszhelyzetbe kerülünk. A trükk az, hogy legyünk tisztában azzal, hogy a stressz alatti működés nem kell, hogy a mindennapi rendes működéssé váljon. És ekkor, még ha stressz alatt is vagyunk, képesek leszünk elkerülni a bukás-módokat. </span><span lang="HU" style="font-size: 12pt; font-family: "Times New Roman";"><br /> <br /> <strong>Párban</strong> <br /> Párban dolgozni a coach-oknak is hasznos. Talán éppenséggel alapvető is. Neveljünk ki egy csoportnyi kollégát, akikhez fordulhatunk, ha úgy érzzük, hogy bukás-mód fenyeget. Ezek az emberek együtt éreznek velünk, és emlékeztetnek: a te célod egy kimagasló teljesítményt, önellenőrzést és önszabályozást alkalmazó csapat létrehozása. Ezzel a felfrissített céllal ellenőrzés alá vonhatjuk az egót, összpontosíthatjuk a figyelmet, és felkészülhetünk, hogy a bizalom pozíciójából coach-olhassunk. </span></p> <p><a href="http://www.agilejournal.com/articles/columns/column-articles/858-seven-agile-coach-failure-modes">Forrás</a> <em>fordította Tornai Balázs, válogatta Kulcsár Bence</em></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2012%2F02%2F17%2Faz_agilis_coach_7_buktatoja%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2012%2F02%2F17%2Faz_agilis_coach_7_buktatoja%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2012%2F02%2F17%2Faz_agilis_coach_7_buktatoja%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Az agilis coach 7 buktatója"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2012/02/17/az_agilis_coach_7_buktatoja#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/4123816" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/12/17/az_agilis_szervezetek_jellemzoi
Az agilis szervezetek jellemzői
2011-12-17T12:18:00+01:00
2011-12-17T12:18:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p><a href="http://www.amazon.com/Good-Great-Companies-Leap-Others/dp/0066620996/ref=ntt_at_ep_dpt_2" target="_blank"><img style="margin-left: 40px; margin-right: 40px; margin-top: 20px; margin-bottom: 20px;" src="http://jmstevens.files.wordpress.com/2011/05/good-to-great-cover-jim-collins.jpg" alt="" width="220" /></a></p>
<p><em>Jim Collins</em> a csapata 5 éves kutatási eredményeit elemzi híres könyvében -„Good to Great”-, melynek témája: miként alakítsunk egy már jó céget kimagasló céggé. Vajon az agilis módszertanok segítenek ebben?<br /><br /><em>Jean Tabaka</em> előállt egy 10-es listával az agilis szervezetek legfőbb jellemzőiről. Ez a lista rávilágít, hogy mi kell bármely cégnek a fent leírt minőségi ugráshoz.</p>
<ul>
<li><strong>Munka / Magánélet egyensúlya és folyamatos teljesítmény</strong> – Bátorítsd és támogasd azokat a csapatokat, melyek egyszerre propagálják a személyes és szervezeti célokat. Alkalmazz rövidebb szállítási periódusokat.</li>
<li><strong>A szolgáló vezető</strong> – A teljes menedzsmentnek el kell sajátítania miként tud szolgálva vezetni és miként fog a vezetés szolgálni. Ahelyett, hogy felülről erőltetnénk döntéseket a csapatra, a vezetőknek támogatást kell nyújtaniuk a teamek felé, hogy végigvihessék a saját maguk által vállaltakat.</li>
<li><strong>Fenntartható és sikeres teljesítmény</strong> – Át kell állni egy stabilan tartható tempóra. A teljes szervezetnek egy fő fókusza kell legyen: a vevői érték (amiért örömmel és megelégedéssel fizet).</li>
<li><strong>A közösséghez való hozzájárulás, és egy profitabilis cég fenntartása</strong> – A profitabilitáson és a fő tevékenyégen túl a közvetlen közösségre gyakorolt jó benyomás is a figyelmünk középpontjában kell legyen.</li>
<li><strong>Egymással együttműködő okos alkalmazottak</strong> – intelligens embereket alkalmazz és támogasd az együttműködést. Ez elősegíti mindenki egyéni fejlődését.</li>
<li><strong>Bottom-up és top-down döntési modellek</strong> – el kell érni, hogy a vezetőket az információ közvetlen birtokosai tájékoztassák és fordítva. A tacit tudás segíti az explicit tudás kialakulását.</li>
<li><strong>Személyes rugalmasság és ritmus</strong> – hozd létre a folyamatos értékszállítás körforgását.</li>
<li><strong>Minőség és sebesség</strong> – a teljes szervezet az értékek létrehozására és a gyors visszajelzések fogadására-feldolgozására kell koncentráljon.</li>
<li><strong>Saját valóság és vízió</strong> – ahelyett, hogy egy szervezetet kőbe vésett szabályok mentén terelnénk a vízió megvalósítása irányába, mint agilis szervezet, olyan egyéneket alkalmazzunk, akik a személyes kisugárzásuk révén mutatnak irányt a vízió alakításához és eléréséhez.</li>
<li><strong>Elkötelezettség, hogy végigmész a naggyá válás útján</strong> – fegyelmezett kultúra és mérőszámok alkalmazása – pl.: munka / magánélet egyensúly, bottom-up és top-down döntéshozás, a szolgáló vezetés megvalósításának fogásai, újítások alkalmazása, a technikai hiányosságok követése és ledolgozása. Mindezek segítenek annak feltárásában, hogy a cég vajon a jó úton jár-e, hogy elérje: a jóból nagyszerű legyen.</li>
</ul>
<p><br />Hasonlóképp, <em>Mike Beedle</em> a következő karakterisztikákat emelte ki:</p>
<ul>
<li>Megfordított menedzsment piramis</li>
<li>Nagyfokú szabadság biztosítása, hogy az egyén saját hatáskörben megoldhassa az előtte álló feladatot</li>
<li>Folyamatos tanulás, tudás létrehozása és megosztása</li>
<li>Emberibb és szórakoztatóbb munkakörülmények</li>
<li>Hiperproduktív, együttműködésen alapuló munkavégzés</li>
<li>Dinamizált tervezés, architektúra és követelmények</li>
<li>Olyan új értékek meghonosítása, melyek együttműködő(bb) szervezetté kovácsolják a jelenlegit</li>
<li>Életminőség</li>
</ul>
<p><br /><em>Mike Cottmeyer</em> eredménye az alábbi lista mely több szervezet mintáinak közös metszete. Ezek a minták elengedhetetlenek a sikeres agilis működéshez.</p>
<p><em>„Vannak bizonyos minták, melyekkel újra és újra találkozok. Ezek a minták megalapozzák az agilis működés sikeres bevezetését, vagy egy nagyszabású szervezeti átalakítást az agilis módszertan jegyében. Íme kigyűjtve a legfontosabbak és velük együtt az, hogy miért is azok.”</em></p>
<ul>
<li>Keresztkompetenciákkal rendelkező csapat</li>
<li>Felhatalmazott csapattagok – a lényeg az üzleti eredmény. Ezen felül minden csapat a maga hatáskörében dönt, azt miként éri el. </li>
<li>Az üzlet korlátozott beleszólása - Az üzletnek kell meghatároznia a prioritásokat és megjelölnie a létrehozandó értékeket a teljes fejlesztői csapatnak. (ezután a többi már a csapat kizárólagos hatásköre)</li>
<li>Megosztott felelősség – mindenki felelős az elért üzleti eredmény rá eső részéért.</li>
<li>Szolgáló típusú vezetés</li>
<li>Folyamatos értékteremtés – biztosítani, hogy a szervezet kiszámítható ütemben szállítson üzleti értéket.</li>
<li>Érték a tevékenység felett – minden egyes lépésnek további hozzáadott érték létrehozását kell eredményeznie.</li>
<li>Törekvés a technikai tökéletességre – folyamatosan figyelni és csökkenteni kell az felhalmozódó technikai hiányosságokat. Már az első pillanattól be kell építeni a minőség, megbízhatóság és skálázhatóság elveit minden tevékenységbe.</li>
<li>Korai visszajelzés és alkalmazkodás</li>
<li>Totális nyíltság és átláthatóság – egy valóban agilis szervezetben semmi sem maradhat rejtve. Az ember nem tud elbújni. Az haladást nem lehet elrejteni. A mérőszámokat nem lehet eldugni. Rossz minőséget nem lehet a szőnyeg alá söpörni. A kockázatokat nem lehet figyelmen kívül hagyni. Az akadályokat nem lehet nem észrevenni.</li>
<li>Bizalom – olyan környezet és kultúra megteremtése, ahol az emberek megbíznak egymásban.</li>
</ul>
<p><br />A fentiek alapján könnyen belátható, hogy a leghangsúlyosabb elemek: támogatás, kommunikáció és együttműködés. Mindennek kulcsa a bizalmon alapuló légkör, a folyamatos tudásfejlesztés és fenntartható tempójú értékteremtés.</p>
<p><a href="http://www.infoq.com/news/2011/01/characteristics-agile-org;jsessionid=D4A1B842E4EE6D08C729C2FCFC49C808" target="_blank">Forrás</a> <em>fordította Tornai Balázs, válogatta Kulcsár Bence</em></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F12%2F17%2Faz_agilis_szervezetek_jellemzoi%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F12%2F17%2Faz_agilis_szervezetek_jellemzoi%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F12%2F17%2Faz_agilis_szervezetek_jellemzoi%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Az agilis szervezetek jellemzői"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/12/17/az_agilis_szervezetek_jellemzoi#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3470721" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://jmstevens.files.wordpress.com/2011/05/good-to-great-cover-jim-collins.jpg
https://agilitas.blog.hu/2011/12/06/scrum_master_ellenorzolista
Scrum Master ellenőrzőlista
2011-12-06T11:41:00+01:00
2011-12-06T11:41:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p><object width="320" height="240" data="http://agilescout.com/wp-content/uploads/2011/02/scrummaster-retrospective-management-agile.jpeg" type="application/x-shockwave-flash"><param name="src" value="http://agilescout.com/wp-content/uploads/2011/02/scrummaster-retrospective-management-agile.jpeg"></param></object></p>
<p>Oka van annak, hogy amikor két pilóta elfoglalja a helyét a repülőn, minden alkalommal lépésről lépésre végigmennek egy ellenőrzőlistán. Ez az ok, pedig az, hogy az <strong>Ellenőrzőlisták Működnek. </strong>Az ellenőrzőlista pedig még egy olyan tökéletes ScrumMaster számára is hasznos lehet, aki az összes scrum master tesztinterjú kérdésre tudja a választ.</p>
<h2>Minden nap</h2>
<ul>
<li>Látható a feladat-tábla (information radiator)?</li>
<li>Teljes user story-k és hozzájuk tartozó feladatok vannak rajta?</li>
<li>Tudja a megbízó, ha a táblára néz, hogy mit vállalt a csapat?</li>
<li>Tegnap óta lett frissítve?</li>
<li>Van rajta „ön itt áll” státuszjelzés?</li>
<li>Láthatóak rajta a user story-k, melyek a végső elfogadásra várnak?</li>
<li>Fent van a burndown chart?</li>
<li>Az frissítve lett tegnap óta?</li>
<li>Az optimális sávban van?</li>
<li>Fent van a release-plan?</li>
<li>Ha ránézel a táblára, tudod, hogy mi várható a következő iterációban?</li>
<li>Akadálytalanítva lett a lehető tegtöbb user story a következő iterációból?</li>
<li>Volt napi stand-up?</li>
<li>Látható a következő demó dátuma? Biztos, hogy mindenki részt vesz rajta, akinek kell?</li>
<li>Fent vannak a PO elérhetőségei és neve?</li>
<li>Bízik a csapat abban, amit készít? Miért?</li>
</ul>
<h2>Minden sprintben</h2>
<ul>
<li>Vannak előre látható buktatók, a normális szintet többszörösen meghaladó kockázati tényezők a release tervben?</li>
<li>A teljes megbízói csapat látta (és elfogadta) a release tervet? Van úgynevezett csendes megbízó (aki vagy távolmaradásával, vagy a hallottak, látottak feltétlen elfogadásával jelent kockázatot)?</li>
<li>Az összes megbízó képviselője tisztában van a velocity-vel? És Te?</li>
<li>Kifizették ezt az iterációt?</li>
<li>Készült egy e-mail, ami tartalmazza listaszerűen a teljestett iteráció leírását, az elkészült és elfogadott user story-kat, a velocity-t, a kockázatokat és a projekt scope-ot?</li>
</ul>
<p><br /><a href="http://agilescout.com/scrummaster-daily-check-list/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+agilescout+%28Agile+Scout+-+Independent+Voice+Democratizing+Agile%29" target="_blank">Forrás</a> <em>fordította Tornai Balázs, válogatta Kulcsár Bence</em></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F12%2F06%2Fscrum_master_ellenorzolista%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F12%2F06%2Fscrum_master_ellenorzolista%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F12%2F06%2Fscrum_master_ellenorzolista%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Scrum Master ellenőrzőlista"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/12/06/scrum_master_ellenorzolista#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3442150" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/11/29/scrummaster_10_perc_alatt
ScrumMaster 10 perc alatt
2011-11-29T13:45:00+01:00
2011-11-29T13:45:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p>Talan egy kissé túloz a cím, de Hamid Shoajee videója tényleg 10 perc alatt foglalja össze miről is szól a scrum. Kezdőknek és érdeklődőknek ideális bevezető, gondolatébresztő. </p><p><iframe height="315" frameborder="0" width="560" allowfullscreen="" src="https://www.youtube.com/embed/Q5k7a9YEoUI"></iframe></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F11%2F29%2Fscrummaster_10_perc_alatt%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F11%2F29%2Fscrummaster_10_perc_alatt%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F11%2F29%2Fscrummaster_10_perc_alatt%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=ScrumMaster 10 perc alatt"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/11/29/scrummaster_10_perc_alatt#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3421989" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://i.ytimg.com/vi/Q5k7a9YEoUI/0.jpg
https://agilitas.blog.hu/2011/11/28/ki_alkalmas_userstory_irasra
Ki alkalmas UserStory írásra?
2011-11-28T12:59:00+01:00
2011-11-28T12:59:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p><span class="yj-message">Az, aki a megfelelő üzleti értéssel, tudással rendelkezik, alkalmas arra, hogy UserStory-t írjon. Ez a személy többnyire olyan valaki, aki elég közel van az üzlethez. </span></p>
<p><span class="yj-message"> Feltételezhető, hogy minden scrum team tag tudja, hogyan kell UserStory-t írni. </span></p>
<blockquote>
<p><span class="yj-message">Ron Jefferies’s Circle of Life, cikkére reflektálva egy UserStory készítésnek 3 kulcseleme van: Kártya, Párbeszéd és Megerősítés. <em>(3C, Card, Conversation, Confirmation)</em></span></p>
</blockquote>
<h3><span class="yj-message"><br />Párbeszéd kulcselem. </span></h3>
<p><span class="yj-message">Így zajlik egy tipikus „UserStory író” <a class="expand-body yj-small" style="display: none;">expand »</a><span class="remaining-body">párbeszéd:</span></span><span class="yj-message"><span class="remaining-body"><br /> </span></span></p>
<ol>
<li><em>A Product Owner(PO) vagy a Business Analyst leírja a UserStory-t egy kártyalapra.</em></li>
<li><em><span class="yj-message"><span class="remaining-body">A kártyát az asztalon hagyják, és behívják az érdekelt csapatot (fejlesztők, tesztelők stb.) a Párbeszédre. <br /> </span></span></em></li>
<li><em><span class="yj-message"><span class="remaining-body">A csapat kérdéseket tesz fel, hogy megértsék a UserStory-t. Ezek alapján a BA és a PO feljegyzi a módosításokat. Ettől függetlenül bármely jelenlévő felveheti a kártyát és rávezetheti a szükségesnek ítélt változtatásokat. <br /> </span></span></em></li>
<li><em><span class="yj-message"><span class="remaining-body">Amennyiben a párbeszéd technikai UserStory-k miatt megakad, bevonják az érintett technikai probléma szakembereit (DB admin, architect stb.) is. <br /> </span></span></em></li>
<li><em><span class="yj-message"><span class="remaining-body">A Product Owner dönt végül a UserStory-ról. <br /> </span></span></em></li>
</ol>
<p><span class="yj-message"><span class="remaining-body"><br /> A projekt méretétől függően dedikált emberek (tipikusan BA-k) felelőssége a UserStory-k megírása. Kisebb projektek esetén közvetlenül a Product Owner is írhatja a UserStory-t.<br /> </span></span></p>
<p><a href="http://agileworld.blogspot.com/2011/11/someone-with-strong-domain-knowledge-is.html" target="_blank">Forrás</a> <em>fordította Tornai Balázs, válogatta Kulcsár Bence</em></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F11%2F28%2Fki_alkalmas_userstory_irasra%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F11%2F28%2Fki_alkalmas_userstory_irasra%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F11%2F28%2Fki_alkalmas_userstory_irasra%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Ki alkalmas UserStory írásra?"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/11/28/ki_alkalmas_userstory_irasra#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3418292" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/08/25/top_100_agile_books_11
Top 100 Agile Books '11
2011-08-25T13:27:00+02:00
2011-08-25T13:27:00+02:00
kulcsár bence
https://blog.hu/user/447749
<p><img style="width: 150px; height: 150px;" src="http://agilitas.blog.hu/media/image/6a00e54ff8b9c188340154346fa28b970c-800wi.png" alt="" />Jurgen Appelo idén is előállította az Amazon eladási statisztikái alapján a legjobban fogyott agilis szakirodalmak listáját. Külön jó érzés, hogy e lista alakításában én is aktívan részt vettem -már ami vásárlás oldalát illeti. Érdekesség, hogy maga a szerző az idei év egyik legígéretesebb könyvét dobta piacra, Management 3.0 címmel. 45. pozíciója remekül indikálja, hogy a zseniális gondolkodók radikalitásuk miatt nem válhatnak best seller-ré. Külön respekt Mike Cohn-nak, aki az első 11-ben rögtön 3 könyvet tudhat magáénak.</p> <p><em>TY: This Year, LY: Last Year.</em></p> <table cellspacing="2" cellpadding="0" border="0"> <tbody> <tr> <td align="center" valign="middle"><strong>TY</strong></td> <td align="center" valign="middle"><strong>LY</strong></td> <td valign="middle"><strong>Title</strong></td> <td valign="middle"><strong>Author(s)</strong></td> <td valign="middle"><strong>Year</strong></td> </tr> <tr> <td align="center" valign="middle"><strong>1</strong></td> <td align="center" valign="middle">5</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1933988274?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1933988274">The Art of Unit Testing: With Examples in .Net</a></td> <td valign="middle">Roy Osherove</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>2</strong></td> <td align="center" valign="middle">1</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131479415?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131479415">Agile Estimating and Planning</a></td> <td valign="middle">Mike Cohn</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>3</strong></td> <td align="center" valign="middle">3</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131177052?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131177052">Working Effectively with Legacy Code</a></td> <td valign="middle">Michael Feathers</td> <td valign="middle">2004</td> </tr> <tr> <td align="center" valign="middle"><strong>4</strong></td> <td align="center" valign="middle">8</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0984521402?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0984521402">Kanban: Successful Evolutionary Change for Your Technology Business</a></td> <td valign="middle">David J. Anderson</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>5</strong></td> <td align="center" valign="middle">9</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321579364?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321579364">Succeeding with Agile: Software Development Using Scrum</a></td> <td valign="middle">Mike Cohn</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>6</strong></td> <td align="center" valign="middle">2</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0132350882?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0132350882">Clean Code: A Handbook of Agile Software Craftsmanship</a></td> <td valign="middle">Robert C. Martin</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>7</strong></td> <td align="center" valign="middle">6</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0135974445?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0135974445">Agile Software Development, Principles, Patterns, and Practices</a></td> <td valign="middle">Robert C. Martin</td> <td valign="middle">2002</td> </tr> <tr> <td align="center" valign="middle"><strong>8</strong></td> <td align="center" valign="middle">4</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0201485672?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201485672">Refactoring: Improving the Design of Existing Code</a></td> <td valign="middle">Martin Fowler, et al.</td> <td valign="middle">1999</td> </tr> <tr> <td align="center" valign="middle"><strong>9</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1934356581/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=1934356581">The Agile Samurai: How Agile Masters Deliver Great Software</a></td> <td valign="middle">Jonathan Rasmusson</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>10</strong></td> <td align="center" valign="middle">7</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/020161622X?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=020161622X">The Pragmatic Programmer: From Journeyman to Master</a></td> <td valign="middle">Andrew Hunt, David Thomas</td> <td valign="middle">1999</td> </tr> <tr> <td align="center" valign="middle"><strong>11</strong></td> <td align="center" valign="middle">11</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321205685?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321205685">User Stories Applied: For Agile Software Development</a></td> <td valign="middle">Mike Cohn</td> <td valign="middle">2004</td> </tr> <tr> <td align="center" valign="middle"><strong>12</strong></td> <td align="center" valign="middle">10</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321503627?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321503627">Growing Object-Oriented Software, Guided by Tests</a></td> <td valign="middle">Steve Freeman, Nat Pryce</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>13</strong></td> <td align="center" valign="middle">32</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1935401009?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1935401009">The Principles of Product Development Flow: Second Generation Lean Product Development</a></td> <td valign="middle">Donald G. Reinertsen</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>14</strong></td> <td align="center" valign="middle">14</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0596527675?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596527675">The Art of Agile Development</a></td> <td valign="middle">James Shore, Shane Warden</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>15</strong></td> <td align="center" valign="middle">23</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1430322640?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1430322640">Scrum and XP from the Trenches</a></td> <td valign="middle">Henrik Kniberg</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>16</strong></td> <td align="center" valign="middle">12</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321150783?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321150783">Lean Software Development: An Agile Toolkit</a></td> <td valign="middle">Mary Poppendieck, Tom Poppendieck</td> <td valign="middle">2003</td> </tr> <tr> <td align="center" valign="middle"><strong>17</strong></td> <td align="center" valign="middle">13</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321125215?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321125215">Domain-Driven Design: Tackling Complexity in the Heart of Software</a></td> <td valign="middle">Eric Evans</td> <td valign="middle">2003</td> </tr> <tr> <td align="center" valign="middle"><strong>18</strong></td> <td align="center" valign="middle">16</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131857258?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131857258">Agile Principles, Patterns, and Practices in C#</a></td> <td valign="middle">Robert C. Martin, Micah Martin</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>19</strong></td> <td align="center" valign="middle">17</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321534468?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321534468">Agile Testing: A Practical Guide for Testers and Agile Teams</a></td> <td valign="middle">Lisa Crispin, Janet Gregory</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>20</strong></td> <td align="center" valign="middle">24</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321437381?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321437381">Implementing Lean Software Development: From Concept to Cash</a></td> <td valign="middle">Mary Poppendieck, Tom Poppendieck</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>21</strong></td> <td align="center" valign="middle">18</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/097451408X?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=097451408X">Practices of an Agile Developer: Working in the Real World</a></td> <td valign="middle">Venkat Subramaniam, Andy Hunt</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>22</strong></td> <td align="center" valign="middle">15</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0596517718?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596517718">Making Things Happen: Mastering Project Management</a></td> <td valign="middle">Scott Berkun</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>23</strong></td> <td align="center" valign="middle">57</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0596159811?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596159811">Beautiful Testing: Leading Professionals Reveal How They Improve Software</a></td> <td valign="middle">Adam Goucher, Tim Riley</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>24</strong></td> <td align="center" valign="middle">19</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0976694026?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0976694026">Behind Closed Doors: Secrets of Great Management</a></td> <td valign="middle">Johanna Rothman, Esther Derby</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>25</strong></td> <td align="center" valign="middle">34</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0201699478?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201699478">Crystal Clear: A Human-Powered Methodology for Small Teams</a></td> <td valign="middle">Alistair Cockburn</td> <td valign="middle">2004</td> </tr> <tr> <td align="center" valign="middle"><strong>26</strong></td> <td align="center" valign="middle">28</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1934356433?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1934356433">Agile Coaching</a></td> <td valign="middle">Rachel Davies, Liz Sedley</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>27</strong></td> <td align="center" valign="middle">20</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0596009488?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596009488">Applied Software Project Management</a></td> <td valign="middle">Andrew Stellman, Jennifer Greene</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>28</strong></td> <td align="center" valign="middle">21</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321658396?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321658396">Agile Project Management: Creating Innovative Products (2nd Edition)</a></td> <td valign="middle">Jim Highsmith</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>29</strong></td> <td align="center" valign="middle">22</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131495054?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131495054">xUnit Test Patterns: Refactoring Test Code</a></td> <td valign="middle">Gerard Meszaros</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>30</strong></td> <td align="center" valign="middle">31</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1934356298?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1934356298">Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects</a></td> <td valign="middle">Johanna Rothman</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>31</strong></td> <td align="center" valign="middle">26</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0201702258?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201702258">Writing Effective Use Cases</a></td> <td valign="middle">Alistair Cockburn</td> <td valign="middle">2000</td> </tr> <tr> <td align="center" valign="middle"><strong>32</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1617290084/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=1617290084">Specification by Example: How Successful Teams Deliver the Right Software</a></td> <td valign="middle">Gojko Adzic</td> <td valign="middle">2011</td> </tr> <tr> <td align="center" valign="middle"><strong>33</strong></td> <td align="center" valign="middle">41</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0684839911?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0684839911">Managing the Design Factory</a></td> <td valign="middle">Donald G. Reinertsen</td> <td valign="middle">1997</td> </tr> <tr> <td align="center" valign="middle"><strong>34</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0137081073/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=0137081073">The Clean Coder</a></td> <td valign="middle">Robert C. Martin</td> <td valign="middle">2011</td> </tr> <tr> <td align="center" valign="middle"><strong>35</strong></td> <td align="center" valign="middle">29</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0977616649?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0977616649">Agile Retrospectives: Making Good Teams Great</a></td> <td valign="middle">Esther Derby, Diana Larsen</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>36</strong></td> <td align="center" valign="middle">39</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/073561993X?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=073561993X">Agile Project Management with Scrum</a></td> <td valign="middle">Ken Schwaber</td> <td valign="middle">2004</td> </tr> <tr> <td align="center" valign="middle"><strong>37</strong></td> <td align="center" valign="middle">30</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321514521?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321514521">Agile Adoption Patterns: A Roadmap to Organizational Succes</a></td> <td valign="middle">Amr Elssamadisy</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>38</strong></td> <td align="center" valign="middle">27</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321213351?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321213351">Refactoring to Patterns</a></td> <td valign="middle">Joshua Kerievsky</td> <td valign="middle">2004</td> </tr> <tr> <td align="center" valign="middle"><strong>39</strong></td> <td align="center" valign="middle">40</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321278658?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321278658">Extreme Programming Explained: Embrace Change (1st+2nd Edition)</a></td> <td valign="middle">Kent Beck, Cynthia Andres</td> <td valign="middle">1999</td> </tr> <tr> <td align="center" valign="middle"><strong>40</strong></td> <td align="center" valign="middle">37</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0596519788?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596519788">The Productive Programmer</a></td> <td valign="middle">Neal Ford</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>41</strong></td> <td align="center" valign="middle">60</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321605780?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321605780">Agile Product Management with Scrum: Creating Products that Customers Love</a></td> <td valign="middle">Roman Pichler</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>42</strong></td> <td align="center" valign="middle">25</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131111558?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131111558">Agile and Iterative Development: A Manager's Guide</a></td> <td valign="middle">Craig Larman</td> <td valign="middle">2003</td> </tr> <tr> <td align="center" valign="middle"><strong>43</strong></td> <td align="center" valign="middle">68</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321572882?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321572882">Stand Back and Deliver: Accelerating Business Agility</a></td> <td valign="middle">Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent McDonald</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>44</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0982866917/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=0982866917">The Elements of Scrum</a></td> <td valign="middle">Chris Sims, Hillary Louise Johnson</td> <td valign="middle">2011</td> </tr> <tr> <td align="center" valign="middle"><strong>45</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321712471/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0321712471">Management 3.0: Leading Agile Developers, Developing Agile Leaders</a></td> <td valign="middle">Jurgen Appelo</td> <td valign="middle">2011</td> </tr> <tr> <td align="center" valign="middle"><strong>46</strong></td> <td align="center" valign="middle">47</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321146530?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321146530">Test Driven Development: By Example</a></td> <td valign="middle">Kent Beck</td> <td valign="middle">2002</td> </tr> <tr> <td align="center" valign="middle"><strong>47</strong></td> <td align="center" valign="middle">36</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0130676349?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0130676349">Agile Software Development with Scrum</a></td> <td valign="middle">Ken Schwaber, Mike Beedle</td> <td valign="middle">2001</td> </tr> <tr> <td align="center" valign="middle"><strong>48</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/B003TZLNKY/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=B003TZLNKY">The Concise Executive Guide to Agile</a></td> <td valign="middle">Israel Gat</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>49</strong></td> <td align="center" valign="middle">48</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321336380?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321336380">Continuous Integration: Improving Software Quality and Reducing Risk</a></td> <td valign="middle">Paul M. Duvall, Steve Matyas, Andrew Glover</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>50</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321601912?ie=UTF8&tag=noopnl-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321601912" target="_self">Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation</a></td> <td valign="middle">Jez Humble, David Farley</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>51</strong></td> <td align="center" valign="middle">35</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0201786060?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201786060">Requirements by Collaboration</a></td> <td valign="middle">Ellen Gottesdiener</td> <td valign="middle">2002</td> </tr> <tr> <td align="center" valign="middle"><strong>52</strong></td> <td align="center" valign="middle">42</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0978739248?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0978739248">Manage It!: Your Guide to Modern, Pragmatic Project Management</a></td> <td valign="middle">Johanna Rothman</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>53</strong></td> <td align="center" valign="middle">45</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321480961?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321480961">Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum</a></td> <td valign="middle">Craig Larman, Bas Vodde</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>54</strong></td> <td align="center" valign="middle">38</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131467409?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131467409">Organizational Patterns of Agile Software Development</a></td> <td valign="middle">James O. Coplien, Neil B. Harrison</td> <td valign="middle">2004</td> </tr> <tr> <td align="center" valign="middle"><strong>55</strong></td> <td align="center" valign="middle">43</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321620704?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321620704">Leading Lean Software Development: Results Are not the Point</a></td> <td valign="middle">Mary Poppendieck, Tom Poppendieck</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>56</strong></td> <td align="center" valign="middle">51</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0974514047?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0974514047">Ship it! A Practical Guide to Successful Software Projects</a></td> <td valign="middle">Jared Richardson, William A. Gwaltney</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>57</strong></td> <td align="center" valign="middle">86</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0557138329?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0557138329">Kanban and Scrum - Making the Most of Both</a></td> <td valign="middle">Henrik Kniberg, Mattias Skarin</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>58</strong></td> <td align="center" valign="middle">71</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321637704?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321637704">Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition</a></td> <td valign="middle">Lyssa Adkins</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>59</strong></td> <td align="center" valign="middle">49</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321268776?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321268776">Collaboration Explained: Facilitation Skills for Software Project Leaders</a></td> <td valign="middle">Jean Tabaka</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>60</strong></td> <td align="center" valign="middle">55</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0201775948?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201775948">Beyond Software Architecture: Creating and Sustaining Winning Solutions</a></td> <td valign="middle">Luke Hohmann</td> <td valign="middle">2003</td> </tr> <tr> <td align="center" valign="middle"><strong>61</strong></td> <td align="center" valign="middle">50</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/047051504X?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=047051504X">Changing Software Development: Learning to Become Agile</a></td> <td valign="middle">Allan Kelly</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>62</strong></td> <td align="center" valign="middle">80</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321437292?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321437292">Innovation Games: Creating Breakthrough Products Through Collaborative Play</a></td> <td valign="middle">Luke Hohmann</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>63</strong></td> <td align="center" valign="middle">70</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0932633641?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0932633641">Just Enough Requirements Management: Where Software Development Meets Marketing</a></td> <td valign="middle">Alan Mark Davis</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>64</strong></td> <td align="center" valign="middle">52</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321321308?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321321308">Agility and Discipline Made Easy: Practices from OpenUP and RUP</a></td> <td valign="middle">Per Kroll, Bruce MacIsaac</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>65</strong></td> <td align="center" valign="middle">61</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321413091?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321413091">Implementation Patterns</a></td> <td valign="middle">Kent Beck</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>66</strong></td> <td align="center" valign="middle">62</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0201708426?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201708426">Extreme Programming Installed</a></td> <td valign="middle">Ron Jeffries, Ann Anderson, Chet Hendrickson</td> <td valign="middle">2000</td> </tr> <tr> <td align="center" valign="middle"><strong>67</strong></td> <td align="center" valign="middle">56</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0596518021?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596518021">Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders</a></td> <td valign="middle">Andrew Stellman, Jennifer Greene</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>68</strong></td> <td align="center" valign="middle">53</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321293533?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321293533">Refactoring Databases: Evolutionary Database Design</a></td> <td valign="middle">Scott W. Ambler, Pramodkumar J. Sadalage</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>69</strong></td> <td align="center" valign="middle">88</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0955683610?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0955683610">Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing</a></td> <td valign="middle">Gojko Adzic</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>70</strong></td> <td align="center" valign="middle">58</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131240714?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131240714">Managing Agile Projects</a></td> <td valign="middle">Sanjiv Augustine</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>71</strong></td> <td align="center" valign="middle">46</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321482751?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321482751">Agile Software Development: The Cooperative Game (2nd Edition)</a></td> <td valign="middle">Alistair Cockburn</td> <td valign="middle">2006</td> </tr> <tr> <td align="center" valign="middle"><strong>72</strong></td> <td align="center" valign="middle">81</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131424602?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131424602">Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results</a></td> <td valign="middle">David J. Anderson</td> <td valign="middle">2003</td> </tr> <tr> <td align="center" valign="middle"><strong>73</strong></td> <td align="center" valign="middle">73</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1933988258?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1933988258">Becoming Agile: ...in an Imperfect World</a></td> <td valign="middle">Greg Smith, Ahmed Sidky</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>74</strong></td> <td align="center" valign="middle">66</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321509366?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321509366">Emergent Design: The Evolutionary Nature of Professional Software Development</a></td> <td valign="middle">Scott L. Bain</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>75</strong></td> <td align="center" valign="middle">75</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1932394850?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1932394850">Test Driven: TDD and Acceptance TDD for Java Developers</a></td> <td valign="middle">Lasse Koskela</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>76</strong></td> <td align="center" valign="middle">83</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321502752?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321502752">The Software Project Manager's Bridge to Agility</a></td> <td valign="middle">Michele Sliger, Stacia Broderick</td> <td valign="middle">2008</td> </tr> <tr> <td align="center" valign="middle"><strong>77</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321714083/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0321714083">Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration</a></td> <td valign="middle">Ken Pugh</td> <td valign="middle">2011</td> </tr> <tr> <td align="center" valign="middle"><strong>78</strong></td> <td align="center" valign="middle">63</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/160773074X?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=160773074X">Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams</a></td> <td valign="middle">Greg Cohen</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>79</strong></td> <td align="center" valign="middle">54</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1895186110?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1895186110">Managing Agile Projects</a></td> <td valign="middle">Kevin J. Aguanno</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>80</strong></td> <td align="center" valign="middle">69</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1439803897?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1439803897">A Tale of Two Systems: Lean and Agile Software Development for Business Leaders</a></td> <td valign="middle">Michael K. Levine</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>81</strong></td> <td align="center" valign="middle">67</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0201741571?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201741571">Fearless Change: Patterns for Introducing New Ideas</a></td> <td valign="middle">Mary Lynn Manns, Linda Rising</td> <td valign="middle">2004</td> </tr> <tr> <td align="center" valign="middle"><strong>82</strong></td> <td align="center" valign="middle">64</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321186125?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321186125">Balancing Agility and Discipline: A Guide for the Perplexed</a></td> <td valign="middle">Barry Boehm, Richard Turner</td> <td valign="middle">2003</td> </tr> <tr> <td align="center" valign="middle"><strong>83</strong></td> <td align="center" valign="middle">79</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1430314885?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1430314885">Patterns of Agile Practice Adoption</a></td> <td valign="middle">Amr Elssamadisy</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>84</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0470684208/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0470684208">Lean Architecture: for Agile Software Development</a></td> <td valign="middle">James O. Coplien, Gertrud Bjørnvig</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>85</strong></td> <td align="center" valign="middle">59</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321532899?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321532899">Lean-Agile Software Development: Achieving Enterprise Agility</a></td> <td valign="middle">Alan Shalloway, Guy Beaver, James R. Trott</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>86</strong></td> <td align="center" valign="middle">84</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/047041345X?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=047041345X">Business Agility: Sustainable Prosperity in a Relentlessly Competitive World</a></td> <td valign="middle">Michael H. Hugos</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>87</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0984618104/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0984618104">Just Enough Software Architecture: A Risk-Driven Approach</a></td> <td valign="middle">George H. Fairbanks</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>88</strong></td> <td align="center" valign="middle">78</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1584505869?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1584505869">Principles of Software Development Leadership: Applying Project Management Principles to Agile Software Development</a></td> <td valign="middle">Ken Whitaker</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>89</strong></td> <td align="center" valign="middle">77</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0137041136?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0137041136">A Practical Guide to Distributed Scrum</a></td> <td valign="middle">Elizabeth Woodward, Steffan Surdek, Matthew Ganis</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>90</strong></td> <td align="center" valign="middle">76</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1604270314?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1604270314">The Business Value of Agile Software Methods: Maximizing Roi With Just-in-time Processes and Documentation</a></td> <td valign="middle">David F. Rico, Hasan H. Sayani, Saya Sone</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>91</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1453802266/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399373&creativeASIN=1453802266">Personal Kanban: Mapping Work | Navigating Life</a></td> <td valign="middle">Jim Benson, Tonianne DeMaria Barry</td> <td valign="middle">2011</td> </tr> <tr> <td align="center" valign="middle"><strong>92</strong></td> <td align="center" valign="middle">74</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321618521?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321618521">Agile Game Development with Scrum</a></td> <td valign="middle">Clinton Keith</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>93</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321635841/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0321635841">Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise</a></td> <td valign="middle">Dean Leffingwell</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>94</strong></td> <td align="center" valign="middle">85</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131914510?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131914510">The Enterprise Unified Process: Extending the Rational Unified Process</a></td> <td valign="middle">Scott W. Ambler, John Nalbone, Michael J. Vizdos</td> <td valign="middle">2005</td> </tr> <tr> <td align="center" valign="middle"><strong>95</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321554132/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0321554132">Managing Software Debt: Building for Inevitable Change</a></td> <td valign="middle">Chris Sterling</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>96</strong></td> <td align="center" valign="middle">82</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/1604270276?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=1604270276">Project Management the Agile Way: Making It Work in the Enterprise</a></td> <td valign="middle">John C. Goodpasture</td> <td valign="middle">2009</td> </tr> <tr> <td align="center" valign="middle"><strong>97</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0932633714?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0932633714">Agile Software Development with Distributed Teams</a></td> <td valign="middle">Jutta Eckstein</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>98</strong></td> <td align="center" valign="middle">-</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0986519405/ref=as_li_ss_tl?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0986519405">SDLC 3.0: Beyond a Tacit Understanding of Agile</a></td> <td valign="middle">Mark Kennaley</td> <td valign="middle">2010</td> </tr> <tr> <td align="center" valign="middle"><strong>99</strong></td> <td align="center" valign="middle">33</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0321458192?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321458192">Scaling Software Agility: Best Practices for Large Enterprises</a></td> <td valign="middle">Dean Leffingwell</td> <td valign="middle">2007</td> </tr> <tr> <td align="center" valign="middle"><strong>100</strong></td> <td align="center" valign="middle">95</td> <td valign="middle"><a href="http://www.amazon.com/gp/product/0131016490?ie=UTF8&tag=lstab01-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0131016490">Test-Driven Development: A Practical Guide</a></td> <td valign="middle">David Astels</td> <td valign="middle">2003</td> </tr> </tbody> </table> <p> </p> <p><a href="http://www.noop.nl/2011/08/top-100-agile-books-edition-2011.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+noop+%28NOOP.NL%29">Forrás</a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F08%2F25%2Ftop_100_agile_books_11%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F08%2F25%2Ftop_100_agile_books_11%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F08%2F25%2Ftop_100_agile_books_11%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Top 100 Agile Books '11"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/08/25/top_100_agile_books_11#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3179651" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://agilitas.blog.hu/media/image/6a00e54ff8b9c188340154346fa28b970c-800wi.png
https://agilitas.blog.hu/2011/08/01/value_engineering_amp_scrum
Value Engineering & Scrum
2011-08-01T13:18:00+02:00
2011-08-01T13:18:00+02:00
kulcsár bence
https://blog.hu/user/447749
<p><object height="344" width="425"><param value="https://www.youtube.com/v/BquY-ZVuaWc&hl=en&fs=1" name="movie"></param><param value="true" name="allowFullScreen"></param><embed height="344" width="425" allowfullscreen="true" type="application/x-shockwave-flash" src="https://www.youtube.com/v/BquY-ZVuaWc&hl=en&fs=1"></embed></object></p><p>A következő kis videó remekül mutatja be miért is fontos az üzleti értékek mentén priorizálni feladatainkat. Természetesen ez csak folyamatos erőfeszítés és magasfokú tudatosság mentén realizálható. Ennek eredményeképpen -mint az az animációból is kiderül, a veszteségek minimalizálását nyerhetjük, ezzel párhuzamosan pedig az egységnyi erőforrásból előállítható többlet üzleti értéket (más szemszögből pedig az egységnyi üzleti érték előállításának költség-optimalizációját). Az egyébként szórakoztató kisfilmet Leo Lamarca készítette.</p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F08%2F01%2Fvalue_engineering_amp_scrum%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F08%2F01%2Fvalue_engineering_amp_scrum%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F08%2F01%2Fvalue_engineering_amp_scrum%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Value Engineering & Scrum"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/08/01/value_engineering_amp_scrum#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3116804" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://i.ytimg.com/vi/BquY-ZVuaWc/0.jpg
https://agilitas.blog.hu/2011/07/19/visual_builds_board
Visual Builds Board
2011-07-19T11:02:00+02:00
2011-07-19T11:02:00+02:00
kulcsár bence
https://blog.hu/user/447749
<table> <tbody> <tr> <td><p><img title="build_board_tv" src="http://www.targetprocess.com/blog/wp-content/uploads/2011/07/build_board_tv.jpg" alt="Builds Board TV" /></p> <p> </p></td> </tr> <tr> <td><p>A TargetProcess-nél egy speciális digitális táblát fejlesztettek amelyet "Visual Builds Board"-nak kereszteltek el. Mivel a fejlesztéseiket agilis szempontból a végfelhasználók számára önálló értéket hordozó funkcionalitások mentén valósítják meg, náluk minden egyes UserStory illetve Bug önálló branch-ként értelmezett. Ez azt jelenti, hogy számos build-et kell elkészíteniük, hiszen minden branchet önállóan kell tesztelni. A Visual Builds Board segít átlátni az összes branch státuszát. Ennek alapját egy .NET applikáció nyújtja amely össze van kötve a TargetProcess illetve a Jenkins szoftverekkel.</p> <p>Zöld: lefutott build-ek, Narancs: éppen futó build-ek, Piros: Hibával leállt buildek.</p></td> </tr> <tr> <td><p><img title="build_board_tv" src="http://www.targetprocess.com/blog/wp-content/uploads/2011/07/build_status-2.png" alt="Builds Status" /></p></td> </tr> <tr> <td><p><img title="build_board_tv" src="http://www.targetprocess.com/blog/wp-content/uploads/2011/07/plugin-2.png" alt="Builds Status 2" /></p></td> </tr> <tr> <td><p><img title="build_board_tv" src="http://www.targetprocess.com/blog/wp-content/uploads/2011/07/build_inprogress-2.png" alt="Builds Status In Progress" /></p></td> </tr> <tr> <td><p><img title="build_board_tv" src="http://www.targetprocess.com/blog/wp-content/uploads/2011/07/build_history.png" alt="Builds Status History" /></p></td> </tr> </tbody> </table> <p><a href="http://www.targetprocess.com/blog/2011/07/visual-builds-board.html">Forrás</a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F07%2F19%2Fvisual_builds_board%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F07%2F19%2Fvisual_builds_board%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F07%2F19%2Fvisual_builds_board%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Visual Builds Board"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/07/19/visual_builds_board#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/3079508" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://www.targetprocess.com/blog/wp-content/uploads/2011/07/build_board_tv.jpg
https://agilitas.blog.hu/2011/06/14/nem_tudunk_gyorsabban_menni_kapitany
'Képtelenség gyorsabban menni, Kapitány!'
2011-06-14T14:00:00+02:00
2011-06-14T14:00:00+02:00
kulcsár bence
https://blog.hu/user/447749
<div class="post-header">Sok Scrum team kerül olyan helyzetbe, amikor több nyilvánvaló akadály tűnik fel. Miután megoldották őket, stabilizálódik a helyzet. Ebben a fixált állapotban gyakran hangzik el, hogy elértük a maximális teljesítményt: képtelenség gyorsabban haladni!<br /> </div><div class="post-header">Mi a gond ezzel szituációval? (a csapat szempontjából)</div> <div class="post-header"> </div> <div class="post-header">Vizsgáljunk meg néhányat:<br /> </div> <h3>1., Nem teljesen egyértelmű akadályok</h3> <p>A leggyakrabban számos nem teljesen egyértelmű akadály húzódhat meg a felszín alatt. Lehetnek olyan dolgok, amelyek szimplán elkerülték a figyelmet, vagy éppenséggel elefánt a konyhában típusú probléma is, mint mondjuk egy command&control típusú scrum master. Lehetséges probléma gócpontok:</p> <ul> <li>Néhányan azt feltételezik, hogy az összes akadály technikai jellegű</li> <li>Néhányan úgy gondolják, az összes akadályt a csapat számára mindössze a szükséges infrastruktúra felállítása jelenti</li> <li>Néhányan úgy gondolják, az összes akadály a részleges szállításból következő folyamatos integrációból keletkezik</li> <li>Néhányan úgy gondolják, az összes akadály a folyamatok és a fejlesztések egyszerűsítéséből fakad </li> <li>Néhányan pedig úgy, hogy az összes akadályt a menedzserek megszakításai jelentik</li> </ul> <p> Bármelyik fent említett probléma mellett megjelenhet más aspektus is, akár technikai/architektúrális/kódolási. Pl. mikor éremes újrafejleszetni vagy mikor érdemes fenntartani a meglévő kódot.</p> <h3>2., Akadályok amelyek elmozdíthatatlannak tűnnek</h3> <p>A legtöbb esetben nem foglalkoznak a triviálisan mozdíthatatlannak tűnő akadályok feloldásával. Ilyen esetekben sokszor mégis könnyen feloldhatóvá válik az akadály, pl. egy megfelelő menedzserrel vagy szakértővel való megbeszélést követően.</p> <p>Egy külső nézőpont és vélemény rengeteget segíthet a csapatnak és nagy mértékben növelheti a teljesítőképességet.</p> <h3>3., Tökéletesek vagyunk</h3> <p>A tökéletessé vagy jóvá - legjobbá válás igénye mélyen gyökerezik az emberi természetben.</p> <blockquote> <p>A Lean-t alkalmazók azt mondják, ha elértük az előző definíciónkat a tökéletességről, akkor elég bölcssé váltunk ahhoz, hogy egy újabb és pontosabb definíciót alkothassunk a magunk számára amit követhetünk.</p> </blockquote> <p>Ha megnyerte a csapat a világbajnokságot az előző Sprintben akkor kétségtelenül jobbá vált, így jogos lehet a kérdés: mi a legnagyobb akadály jelenleg?</p> <p> </p> <p>Természetesen sok egyéb probléma is akadályozhatja a teljesítmény növekedését de érdemes ezzel a hárommal kezdeni a vizsgálódást.</p> <p><a href="http://agileconsortium.blogspot.com/2010/09/we-cant-go-any-faster-captain.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FCdKs+%28Agile+%26+Business%29">Forrás</a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F06%2F14%2Fnem_tudunk_gyorsabban_menni_kapitany%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F06%2F14%2Fnem_tudunk_gyorsabban_menni_kapitany%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F06%2F14%2Fnem_tudunk_gyorsabban_menni_kapitany%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t='Képtelenség gyorsabban menni, Kapitány!'"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/06/14/nem_tudunk_gyorsabban_menni_kapitany#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2314583" border="0" /></a><br /></p>
agile
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/05/10/a_userstory_feldarabolas_10_strategiaja
A UserStory feldarabolás 10 stratégiája
2011-05-10T18:00:00+02:00
2011-05-10T18:00:00+02:00
kulcsár bence
https://blog.hu/user/447749
<p>A UserStory egy lefejlesztendő rendszer-funkcionalitást, vagy felhasználói igényt jelent. A funkció meghatárazásakor a felhasználói szemléletű leírás (Szerepkör -> Cél) széleskörűen elterjedt az agilis projektekben. "Mint felhasználó, szeretnék egy vonatjegyet foglalni Párizsba"</p> <p><br /> A UserStory-k meghatározásakor gyakran használják a következő szabályokat:</p> <blockquote><p>3C<br /> Card, Conversation, Confirmation</p><p><br /> INVEST<br /> Independent, Negotiable, Valuable, Estimable, Small enough, Testable</p><br /> USERVOICE FORMAT<br /> AS A <User Role> <br /> I CAN <Goal> <br /> SO THAT <Business Value><br /><br /></blockquote> <p><br /> Így a UserStory-k eredményorientáltak és felhasználócentrikusak.<br /> <br /> Minden UserStory a csapat által kerül becslésre, valamint a ProductOwner által priorizálva, továbbá elég kicsinek kell lennie, hogy egy Sprint alatt szállítani lehessen (általában a legkisebb csapatok is minimum 3 UserStory-t szállítanak egy Sprint-ben). Ez szükségszerű ha vizsgálni szeretnénk az értékszállítás, a láthatóság, a rugalmasság, a visszajelzés és a folyamatos javítás előnyeit.<br /> Egy coach életében gyakran előfordul, hogy segítenie kell a ProductOwner-nek felosztani a UserStory-kat kisebb egységekre.<br /> Itt olvasható 10 stratégia amely hatékonyan segít nagyon UserStory-k felosztásakor:</p> <h3>1. Egy folyamat lépései</h3> <p>A felhasználó egy jól definiált folyamat meghatározott lépéseit hajtja végre. A nagy UserStory ezen lépések - státuszok mentén van felosztva és lépésenként lefejlesztve. Minden lépésnek saját UserStory-ja lesz.</p> <h3>2. Forgatókönyv</h3> <p>Egy forgatókönyv mentén történik a feldarabolás. Az egyik UserStory lehet a sikeres bejárási út, a többi pedig az alternatív bejárások: <br /> Ha x történik, akkor…<br /> Ha .., akkor</p> <h3>3. Forgatókönyv szekvenciája</h3> <p>Sokkal precízebb, ha a UserStory-kat a forgatókönyv specifikus lépéseinek szekvenciája mellet osztjuk fel.</p> <h3>4. Műveletek</h3> <p>A UserStroy-k feldarabolásának egyik legkézenfekvőbb és leggyakoribb módja ha műveletek mentén osztják szét. A CRUD (Create, Retrieve, Update, Delete) funkcionális dekompozícionálás jó példa lehet. Természetesen ezekből csoportokat is lehet képezni (pl. két részre bontva) ha az megfelelőbb.</p> <h3>5. Az adatméret vagy adattípus</h3> <p>Szintén gyakori eset. A nagy UserStory a használt objektumok kezelése mentén lesz felbontva (pl. különböző account type, vagy language message)</p> <h3>6. Input, Output típus vagy Konfiguráció</h3> <p>Adat és adattípus variációk konfigurációk függvényében vagy akár UserInterface esetek konfigurációként értelmezve szintén segíthetnek nagyobb UserStory-k felosztásában.</p> <h3>7. Felhasználó típus vagy szerepkör</h3> <p>A UserStory felosztást a terméket használók személye vagy betöltött szerepköre mentén is elvégezhetjük. Ha a UserVoice formátumot használtuk a Story-k meghatározásánál akkor kézenfekvő és egyszerű lehet ez a fajta megközelítés. Másfelől segíthet a bonyolult UserStory-k vizualizálásában.</p> <h3>8. Ismeret szintje</h3> <p>A szétdarabolás elengedhetetlen feltétele a funkcionalitás mély ismerete. Szétbontható egy nagyobb UserStory jól ismert és ismeretlen részekre. A kevéssé ismert UserStoryk-ra értelemszerűen spike-okat lehet indítani, azaz olyan timebox-olt rövid iterációt, amelynek az outputja a vizsgált ismeretlen időbeli megbecslése.</p> <h3>9. Komplexitás szintje</h3> <p>Például egy UserStrory-t a legegyszerűbb legelemibb funkcióra bontjuk, a többi peddig ettől komplexebb vagy többrészlettel bíró darabba.</p> <h3>10. Minőségi szintek</h3> <p>Teljesítmény, biztonság, használhatóság ezek a nem funkcionális követelmények gyakran hangzanak el egy specifikus UserStory-val kapcsolatban. Ezek az elégedettség fokmérői de ugyanakkor segíthenek a UserStory felbontásban is (pl. 60 másodpercen belül jelenjen meg a képernyőn, kevesebb mint 30 másodpercen benül jelenjen meg a képrenyőn, valós időben jelenjen meg a képernyőn).<br /> </p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F05%2F10%2Fa_userstory_feldarabolas_10_strategiaja%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F05%2F10%2Fa_userstory_feldarabolas_10_strategiaja%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F05%2F10%2Fa_userstory_feldarabolas_10_strategiaja%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=A UserStory feldarabolás 10 stratégiája"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/05/10/a_userstory_feldarabolas_10_strategiaja#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2893603" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/04/13/scrum_pilot_hogyan
Scrum pilot - hogyan?
2011-04-13T14:51:00+02:00
2011-04-13T14:51:00+02:00
kulcsár bence
https://blog.hu/user/447749
<p>"Melyik projekt a legalkalmasabb Scrum pilot-nak?" Sokszor hangzik el ez a kérdés különböző workshop-okon és tréningeken. Habár fontos, hogy a szervezeti körülményekkel összhangban tervezzünk meg egy specifikus bevezetést, a következő 6 kritérium további segítséget nyújthat a megfelelő agilis pilot projekt sikeres kiválasztásához:</p> <h3>1., Kis méret</h3> <p>A kiválasztott pilot projektnek kis méretűnek kívánatos lennie, maximum 2-3 csapatnyi emberrel. Nagyméretű agilis fejlesztések további kihívásokat rejtenek és futtatásuk extra gyakorlatot igényel. </p> <h3>2., Fontosság</h3> <p>Bizonyosnak kell lenni, hogy a kiválasztott projekt fontos a szervezet számára. Másként a szekptikusok leértékelik a projektet és aláaknázhatják a scrum szevezeten belüli kiterjesztését. Ugyanakkor óvakodni kell a küldetés-kritikus pilot projektektől is, mert az agilis projekt bevezetésének erőforrásigénye súlyosan kihathat az egész szervezet üzleti teljesítményére. Az agilis szoftverfejlesztés sok szervezet számára bomlasztólag ható folyamat innovációt jelent: megkívánja a képességet a kísérletezésre, a hibázásra és az ezekből való tanulásra.</p> <h3>3., Függetlenség</h3> <p>Válasszunk olyan projektet amelynek csak néhány kapcsolódási pontja van más csapatokhoz. A több kapcsolódó csapattal vagy projekttel való koordináció megnöveli a komplexitás szintjét, továbbá nehézzé teszi az agilis vezérelvek követését. Különösen igaz ez, ha a kapcsolódó projektek eltérő szoftverfejlesztési folyamatot követnek. Ha csak nagy komplex projektek közül választhatunk, akkor valamilyen kevés függőséggel bíró részprojektet próbáljunk keresni az agiltás beveztéséhez.</p> <h3>4., Közös elhelyezés</h3> <p>Közös elhelyezésű (lokális) projektet érdemes agilis bevezetéshez választani és óvakodni az elosztottaktól. Utóbbiak a hatékony együttműködést sokkal nehezebbé teszik, valamint további tapasztalatokat és eszközöket igényelnek. Disztributált projektek esetében a közös felhasználói történet írás, a pair-programozás, és a hatékony sprint retrospective meeting-ek egyértelműen nagyobb kihívást jelentenek.</p> <h3>5., Kizárólag szofver</h3> <p>Az agilis bevezetést először korlátozzuk szoftver projektre. Ezzel csökkenthetjük azt az összetettséget amit a hardver vagy a gépipari terület adna hozzá a projekthez. Az agilis szoftverfejlesztési módszerek és praktikák könnyen és jól érthetőek, ami a hardver és a gépipari mérnöki folyamatokra csak kisebb mértékben igaz.</p> <h3>6., Új termék fejlesztése</h3> <p>Érdemes olyan projektet választani ahol nem meglévő hanem új terméket fejlesztenek. Ezzel lehetővé válik megtapasztalni, hogy miként válik egy ötlet árucikké az agilis folyamatok által. Segít eloszlatni a félelmeket a legacy code base, illetve a tesztelés felől. Továbbá, a scrum különösen alkalmas arra, hogy megbirkózzanak a bizonytalansági, az innovációs, és a kockázati tényezőkkel, amelyek fontos jellemzői az új termékek kifejlesztésének.<br /> <br /> Mielőtt a pilot projekt kiválasztásra kerül érdemes megfontolni a következő kérdéseket:</p> <blockquote><p>Végig van-e gondolva miért lesz kipróbálva a scrum módszer és milyen elvárások állnak ezzel szemben? </p><p>Még akkor is, ha csak hype vezérelte kíváncsiságról beszélhetünk?</p></blockquote> <p> </p> <p><a href="http://www.romanpichler.com/blog/agile-product-management/choosing-the-right-agile-pilot-project/"> Forrás</a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F04%2F13%2Fscrum_pilot_hogyan%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F04%2F13%2Fscrum_pilot_hogyan%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F04%2F13%2Fscrum_pilot_hogyan%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Scrum pilot - hogyan?"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/04/13/scrum_pilot_hogyan#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2823136" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/04/13/az_agilis_csapat_epitese
Az agilis csapat építése
2011-04-13T10:00:00+02:00
2011-04-13T10:00:00+02:00
kulcsár bence
https://blog.hu/user/447749
<h1>Bevezetés</h1> <p>Egy agilis szoftverfejlesztő csapat felépítése nem olyan könnyű dolog mint amilyennek tűnik. Sok menedzser és csapatvezető felkér pár technikaliag képzett fejlesztőt, ad pár útmutatást az agilis folyamatokról és reménykedik benne, hogy minden olyan jól működik majd mint a szakirodalomban. Ez a felfogás nem csak irreális de hajlamos a bukásra is.</p><h3>Egy sikeres agilis csapat összetevői</h3><p>Egy sikeres agilis szoftverfejlesztő csapat tapasztalt fejlesztőkből áll, csapatértékeken alapszik, jó kommunikáció jellemzi és mindig a fejlődést tartja szem előtt. Bár a siker szempontjából nem minden egyes összetevő teljesen kritikus, az összes rendelkezésre állása esetén jelentősen lerövidül a sikerig vezető út.</p><h3>Vezérelvek</h3><p>Mindenkinek van elképzelése arról, hogy milyen kultúrát kíván megalapozni a csapatában. Ha csak a menedzser nem kér fel olyanokat akiket nagyon jól ismer, egy kultúrális víziót gyakorlattá fordítani nagyon nehéz feladat. Korán felismerhető, hogy azok a tulajdonságok amelyek nélkülözhetetlenül fontosak: a megbízó fejével gondolkodás, a hatékony együttműködési készség, a tényeken alapuló döntéshozatal és menedzsment, valamint a teljesítés orientáltság. Az a csapat amelyik megtestesíti az előző tulajdonságokat könyebben válhat sikeressé. Ezen csapat tagjai pedig számos előnyös viselkedésmintát mutathatnak fel: közvetlen kérdések a megrendelő felé, megrendelő fejével való gondolkozás, segítség kérés, segítség nyújtás, konkrét tényeken alapuló döntéshozatal személyes vélemény helyett, befejezett és teljes kód leszállítására való törekvés. </p><h3>Hatékony kommunikáció</h3> <p>A hatékony kommunikácó kritikus a siker szempontjából. Az egyik leghatékonyabb módja a kommunikációnak a szemtől-szembe helyzet. Azaz, sokkal könnyebb kidolgozni ötleteketet ha az emberek egy helyen tartózkodnak. A másik lényegesen fontos szempont a fókuszáltság. A megbeszélések nem tudnak produktívak lenni ha nem rendelkeznek jól meghatározott témával amelyhez a résztvevők ragaszkodnak. A harmadik esszenciális elem, hogy a párbeszéd tényekre és ötletekre fókuszáljon. Ha ez nem történik meg, a párbeszédek könnyen viaskodássá alakulhatnak amelyek személyes véleményekre alapulnak nem pedig tényekre és ötletekre.</p> <h3>Megfelelő emberek</h3> <p>A legfontosabb összetevő a sikeres csapat szempontjából, maga az ember. A szoftverfejlesző csapat tehetséges embereket igényel. Tapasztalt fejlesztők szükségesek komplex rendszerek fejlesztéséhez melyekhez új technológiákat használnak fel. Ilyen összetett rendszerek fejlesztését nem tudja egy vagy két jó ember elvégezni: egy csapat szükséges hozzá. Ugyanakkor a fejlesztők részéről szükség van csapatban végzett munkatapasztalatra is, természetesen.</p><h3>Folyamatos tökéletesítés</h3> <p>Tudjuk, hogy nagyot bukhatunk ha egy új csapattal egy új rendszert fejlesztünk. A különbség a sikeres és a sikertelen csapat között az, hogy a sikeres képes tanulni a hibáiból. A haladás csak akkor érhető el, ha múlt hibái átvizsgálásra kerülnek és szükséges tökéletesítés végrehajtódik.</p><h2>A csapat építése</h2> <h3> </h3><h3>Kommunikációs fókusz</h3><p>A cég és a csapat szempontjából is fontos a kommunikáció központúság, ezért célszerű az irodát nyitott terekre tagolni. A fejlesztő csapat egy nagy nyitott szobában foglaljon helyet. Minden fejlesztő saját asztallal rendelkezzen de rendeződjenek csoportba, hogy megkönnyítsék a kommunikációt. Ez a nyitott környezet megkönnyíti a kommunikációt mivel az emberek nem rejtőzhetnek el a saját irodájukba és minden beszélgetés publikus. (Lényeges megemlíteni, hogy ha mindenki professzionálisan viselkedik a környezet nem válik zavaróvá és hangossá)</p><h3>Alapelvek letétele</h3> <p>Csapatépítés során nyilvánvalóvá válik, hogy meg kell határozni azokat az elvárásokat, amelyeket a csapattagoknak meg kell testesíteniük. Kezdetileg a napról-napra történő interakciók sorozatával építhető ki a kívánt csapat-karakterisztika. Ezen jellemzők meggyökereztetésével és szocializációval érhető el, hogy az összes csapattag kellő figyelemmel tekintsen azokra az értékekre amelyek fontosak a siker eléréséhez. A gyakorlatban természetesen eltérő lehet az egyes csapatok jellemvonás kialakítása. Az egyes csapattagok tekintetében is jelentős lehet az eltérés, egyeseknél rövidebb másoknál több munkával érhető el az eredmény. Egyes csapattagok nagyon pozitívak és előfordulhat az is, hogy valaki kifejezetten negatívan viszonyul a folyamatokhoz. Bizonyos esetekben célszerű valakit eltávolítani a csapatból. Érdekes megemlíteni, hogy az interjúk során érdemes a technikai felkészültség mellett a kívánt csapat-értékekre is fókuszálni. Ha szimplán a legfelkészültebb technikai embereket válogatjuk össze, közel sem biztos, hogy a legmegfelelőbb csapatot kapjuk.</p><h3>Interjúztatás</h3> <p>Olyan technikaliag felkészült embert találni aki tökéletesen beleillik egy működő csapatkultúrába nem éppen könnyű dolog. Egyfelől objektív mérési szempontok segítségével könnyen előszűrhetjük a jelentkezőket. Másfelől ezek az objektív szempontok nem veszik figyelembe a jelentkező soft skill-jeit, melyek nélkülözhetetlenek a csapatban való működéshez. Létezik egy kipróbált gyakorlat ezen képességek hatékony kipróbálására. A felvételi modell ebben az esetben többlépcsős. Az első lépés egy telefonos interjú. Ennek során gyorsan bemutatható a cég a jelentkezőnek, illetve magas szinten lemérhető a jelölt is. A beszélgetés érint pár technikai területet, fejlesztési koncepciót, agilis módszertani ismereteket valamint önálló gondolatokat és tapasztalatokat. A beszélgetés végére elmondható, hogy a jelentkező képes lesz-e az új környezetben működni. Ha a jelölt nem esett ki a szűrőn egy személyes interjúra kap meghívást. Ez az interjú három részre osztódik: technikai, folyamat és személyes részekre. Minden szegmensen legalább két csapattag is részt vesz, mivel nagyon lényeges, hogy a csapat kommunikálhasson a jelölttel. A technikai rész értelemszerűen a nyers technikai tudásra és valós programozási feladatra koncentrál. A folyamat rész többek között teszt filozófiákra, probláma megoldásra és pair programming-ra fókuszál. A személyes rész pedig konfliktus kezelésre, motivációra és általános személyiség jegyekre. Ha mindhárom részen egyöntetűleg jól teljesített a jelölt jól fog teljesíteni a csapatban is.</p><h3>Folyamatjavítás</h3> <p>A folyamatjavítás a kulcs a sikeres fejlesztőcsapatok építéséhez. Természetesen nem csak a technikai folyamatoké például a kódkészítésé hanem a munka priorizálásé vagy éppen az új ember felvételé is. Több ismert módszer is használható a javításhoz, például a 3x3 -nak nevezett. Ennek során a csapat összeül, minden csapattagnak meg kell neveznie néhány pozitív dolgot az elmúlt 3 hónapból, és néhány negatívat is. Minden csapattag kap 3 szavazati pontot a pozitív csoportra és 3-at a negatívra is. A szavazatok külön elemenként számolódnak. Ezután priorizálva válik láthatóvá mit gondol a csapat pozitívumnak és miket negatívumnak melyeken javítani kell. Ez a módszer segít a csapattagoknak igazodni a csapat karakterisztikához. A folyamatjavítás másik területe lehet például az interjúztatás, hiszen segítségével eleve nem csak technikailag felkészült csapattagot találhatunk, hanem eleve olyat aki jól fog illeszkedni a csapatba. A folyamatjavítás során meg kell találni az egyensúlyt az új folyamatindítás és a régiek módosítása között. Ha bizonyos problémák rendszeresen jelentkeznek meg kell találni az inkrementális változtatás lehetőségét. Ha bizonyos problémák nem rendszeresen jelentkeznek akkor jellemzően érdemes várakozni és többet megtudni mielőtt bármilyen változtatást vezetnénk be.</p><p> <a href="http://www.infoq.com/articles/building-an-agile-team">Forrás</a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F04%2F13%2Faz_agilis_csapat_epitese%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F04%2F13%2Faz_agilis_csapat_epitese%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F04%2F13%2Faz_agilis_csapat_epitese%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Az agilis csapat építése"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/04/13/az_agilis_csapat_epitese#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2053091" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/03/23/nincs_specifikacio
Nincs specifikáció
2011-03-23T12:12:00+01:00
2011-03-23T12:12:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p><a href="http://agilitas.blog.hu/media/image/cartoon/gb005-neverend.jpg"><img width="725" alt="" src="http://agilitas.blog.hu/media/image/cartoon/gb005-neverend.jpg" /></a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F03%2F23%2Fnincs_specifikacio%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F03%2F23%2Fnincs_specifikacio%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F03%2F23%2Fnincs_specifikacio%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Nincs specifikáció"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/03/23/nincs_specifikacio#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2764627" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://agilitas.blog.hu/media/image/cartoon/gb005-neverend.jpg
https://agilitas.blog.hu/2011/03/05/89_agile_tool
89 agile tools
2011-03-05T22:25:00+01:00
2011-03-05T22:25:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p>Aki kapcsolatba kerül a scrum-mal vagy más agilis technikával előbb-utóbb szembesül azzal a kérdéssel, hogy milyen szoftverrel támogassa a folyamatait. Ez a lista megpróbál átfogó képet adni a piacon fellelhető szoftver megoldásokról. Vannak open source projektek, előfordulnak x felhasználóig ingyenesek és kizárólag előfizetésesek is. Véleményem szerint akkor is érdemes átbogarászni a listát, ha már regebben használunk egy megoldást, mert az agilitás terjedésével egyre szebb és használhatóbb alternatívák jelentek meg a közelmúltban.</p> <table> <tbody> <tr> <td>21 Scrum<br /> <a href="http://www.21scrum.com/"><img id="simple" src="http://agilitas.blog.hu/media/image/agiletool2011/Picture%201.jpg" alt="" /></a></td> </tr> </tbody> </table> <div class="page-break"><a href="https://agilitas.blog.hu/2011/03/05/89_agile_tool">[...] Bővebben!</a></div>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F03%2F05%2F89_agile_tool%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F03%2F05%2F89_agile_tool%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F03%2F05%2F89_agile_tool%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=89 agile tools"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/03/05/89_agile_tool#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2713749" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://agilitas.blog.hu/media/image/agiletool2011/Picture%201.jpg
https://agilitas.blog.hu/2011/02/14/agilis_szerzodesek
Agilis szerződések
2011-02-14T10:16:00+01:00
2011-02-14T10:16:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p>Az agilis projektek egyik kulcskérdése maga a szerződéses viszony. A következő cikkben Allistair Cockburn számos érdekes szerződéstípust felvonultatva ad áttekintést az agilis projektek szerződés modelljeiről.</p><h2>Fix ár, fix feladatkör (esetleg fix határidő)</h2> <p>Ez egy régi típusú szerződés: igyekezz legjobb tudásod szerint (mindegy, milyen módszerrel) árajánlatot adni a projektre. Amint benne vagy a projektben, iktass ki mindent, ami fölösleges, használd a legjobb agilis technikákat (lásd még: <a href="http://alistair.cockburn.us/Process%3a+the+4th+dimension">Process: the 4th dimension</a>), hogy a lehető legjobb eredményt produkálhasd. Tapasztalat szerint az agilis technikák nem befolyásolják egy projekttel kapcsolatos előzetes becsléseket. Leghőbb vágyunk ellenére a projektbecslés még mindig leginkább azon múlik, ki mennyire tapasztalt, milyen megérzései és tippjei vannak. A minden szempontból “fix” projektszerződéseknek akkor van értelme, ha az elvárások nagyon stabilak. Akkor is használnak ilyen szerződést, ha a két fél nem bízik egymásban, noha még egy ilyen megállapodásban is bőven vannak kiskapuk, amikkel bármelyik fél hátrányos helyzetbe hozhatja a másikat, ha éppen ez a célja.</p> <h2>Fix ár, fix feladatkör (esetleg fix határidő), de a megrendelővel együttműködve a feladatkörök átalakíthatók</h2> <p>Kockázatos megoldás, bár már többször láttam sikeresen működni: kétszer kereskedelmi projektekben, és egyszer egy állami projektben. Jeff Patton leírja, hogyan működött együtt a megrendelővel a projekt kezdetén, hogy beazonosítsák az igényeket, kívánságokat és prioritásokat. A projekt előrehaladtával Jeff gondoskodott róla, hogy mindig a legfontosabb elemeken dolgozzanak. Ahogy közeledett a határidő, és világossá vált, hogy néhány részletet még nem sikerült befejezni, Jeff biztosította, hogy kizárólag a legkevésbé fontos területeken maradjanak befejezetlen dolgok. Ez csupa olyasmi volt, ami fölött a megrendelő szemet hunyt, vagy egyszerűen beépítette egy következő szerződésbe.<br /> A fentebb említett állami megrendelés is teljesen fix szerződéssel indult. A csapat szorosan együttműködött a rendszer felhasználóival, és hónapról hónapra képes volt működő, alaposan tesztelt és használható szoftvert szállítani és installálni. Minden szállítás után megbeszélték a felhasználókkal, hogy vajon továbbra is az írott szerződéshez tartsák-e magukat, vagy térjenek el tőle a felhasználók valódi igényeinek megfelelően. Szerintem ez a megbízott cég részéről nagy bátorságra vall, hiszen ha nem lettek volna ilyen jó viszonyban a megrendelővel, akár azt is kockáztathatták volna, hogy nem fogják őket kifizetni. Ebben az esetben azonban az ügyfél annyira elégedett volt a szállított termékkel, hogy minden elvégzett munkát kifizettek a megbízott cégnek. Ez jó példa arra, hogyan lehet egy fix áras, fix feladatkörös és fix határidős szerződést a munka valós idő- és munkaigényének megfelelően rugalmasan kezelni. Veszélyes, de remek stratégia, ha abban a helyzetben vagyunk, hogy kipróbálhassuk.</p> <h2>Fizetés óradíj és dologi költségek alapján</h2> <p>Ebben az esetben minden munkafázist akkor fizetnek ki, amikor elkészült. Nyilvánvalóan ilyen szerződést akkor érdemes használni, ha az elvárások folyamatosan változnak. Egy esetben – amit nem is neveznék projektnek – az ügyfél szélsőséges módon változtatgatta az elvárásait, akár napokkal a szállítás előtt is. A megbízott cég mindig leszállította, amivel éppen elkészült, az ügyfél pedig teljes mértékben kontrollálni tudta, hogy mi legyen a prioritási lista tetején. Az évek múlásával mindez úgy működött, mint egy kiegyensúlyozott áramlás: a megrendelőhöz mindig eljutott a szükséges szoftver, a megbízott céghez pedig cserébe a pénz.<br /> Ha az ügyfél megbízik a fejlesztő cégben, ez a legegyszerűbb szerződéstípus, amit használni érdemes. A nehézsége mindössze annyi, hogy valóban bizalomra van hozzá szükség. Néhány megbízott cég éppen ezért próbaidőt kér az ügyféltől, ami alatt igyekeznek különféle agilis technikákkal rövid határidő alatt működő szoftvert szállítani, és így elnyerni az ügyfél bizalmát és a későbbi megrendeléseket.</p> <h2>Fix ár és maximum ár</h2> <p>Ez a szerződés stabil elvárásokat feltételez. A “fix ár” a megbízott cég számára garantál egy bizonyos profitot a működési költségeiken és az alvállalkozóiknak kifizetett munkadíjon felül. Egyúttal biztos bevételt garantál a cégnek akkor is, ha a feladatok mennyisége lecsökken, vagy a munka a vártnál hamarabb befejeződik. A “maximum ár” pedig egyfajta költségvetési plafont jelent, amit a megbízott cég akkor sem léphet át, ha a munka lassabban halad a vártnál. Ez tehát a megrendelő számára jelent védelmet. Miután mindkét fél – a megrendelő és a megbízott cég is – védve van, nyugodtan törekedhetnek arra, hogy felgyorsítsák a munkát, illetve szükség esetén el tudják fogadni a váratlan nehézségeket.</p> <h2>Fix ár funkciópont- vagy storypoint-egységenként</h2> <p>Ha az ügyfél és a megbízott cég meg tud egyezni a szállítás egységeiben, mint például funkciópontok vagy sztoripontok, ezen egységek alapján is megállapíthatják az árat. Számos szerződés funkciópontokban méri a projektek nagyságát, a leszállított funkciópontokhoz rendeli az egységárat, majd egy hivatalos funkciópont-auditor bevonásával összesíti a projekt végéig leszállított összes funkciópont mennyiségét. A megrendelő így végül ezt a valós összeget fizeti ki, nem pedig az eredetileg becsült összeget. Ez nagyon kedvező szerződési forma, hiszen a megbízott céget arra ösztönzi, hogy minél több funkciópont szállításával növelje a bevételét, a megrendelőnek pedig lehetőséget ad arra, hogy a projekt közben módosítsa az elvárásait. Ugyanez a helyzet az XP-stílusú sztoripontokkal is, azzal az eltéréssel, hogy nem léteznek hivatalos sztoripont-vizsgálók, hogy hitelesítsék a végeredményt. </p> <h2>Bob Martin ötlete</h2> <p>Bob Martin az Object Mentor-tól közzétett egy érdekes variációt: azt javasolja, a szerződő felek állapítsanak meg egy alapdíjat sztoripontonként, plusz egy átlagosnál alacsonyabb (közel önköltséges vagy az alatti) óradíjat. Ez a megbízott céget arra ösztönzi, hogy mielőbb szállítson, miközben bizonyos fokú védelmet ad arra az esetre, ha a munka a vártnál lassabban halad. Bob Martin így fogalmaz: <br /> ”Célszerű megegyezni abban, hogy a megrendelő a befejezett pontok alapján fizet egy meghatározott összeget, plusz egy bizonyos óradíjat minden munkaóra után. Vegyünk például egy projektet, amely 1000 pontból áll. Tételezzük fel, hogy ez a munkamennyiség egy négyfős csapat által heti 50 pontos sebességgel végezhető el. Mindezek alapján ez a projekt 80 ember/hét időtartamig fog tartani. Száz dolláros óradíjjal így tehát a projekt végösszege 320,000 dollár lenne. Most csökkentsük le az óradíjat 30 dollárra, és kérjünk a megrendelőtől 224 dollárt pontonként. Ennek az eredménye igen érdekes lehet: ha a munka valóban 80 ember/hét időtartamig tart, akkor ugyanannyiba fog kerülni. Ha 100 ember/hét időtartamig tart, akkor 344,000 dollárba kerül majd. Ha vizsont csak 70 ember/hétig tart, akkor a végső ára 308,000 dollár lesz. Érdemes megfigyelni, hogy mindez apró különbség ahhoz képest, hogy az időtartamok mennyire eltérőek. Továbbá azt is érdemes észrevenni, hogy a megbízott céget ez a konstrukció erőteljesen arra ösztönzi, hogy hamar befejezze a munkát, hiszen ez növeli a valós óradíjának az összegét.”<br /> Én magam még nem láttam ezt a modellt működés közben, de többektől nagyon kedvező visszajelzéseket hallottam róla. </p> <h2>Kockázati tőke-alapú finanszírozási modell</h2> <p>Ez bármelyik fentebb leírt szerződéshez felhasználható. Ebben a konstrukcióban a megrendelő egy bizonyos mennyiségű elvégzett munka alapján fizet, a megbízott cégnek pedig eredményeket kell produkálnia, ha több pénzt szeretne kapni. Az ügyfél így bármikor csökkentheti a veszteségeit, ha nem kapja meg a várt eredményeket. Továbbá, minden egyes munkaperiódus után lehetősége van arra, hogy változtasson a szerződés feltételein. A munkaperiódusok eredményének nem kell feltétlenül működő szoftvernek lennie, lehet akár egy írásos tanulmány vagy egy requirements document, vagy bármi, amit a megrendelő választ. <br /> A kockázati tőke-alapú finanszírozási modell jól működik agilis szolgáltatók esetében, hiszen ők hozzá vannak szokva, hogy működő és használható szoftvert szállítsanak, mégpedig hamar és rendszeresen. <br /> Személy szerint érthetetlennek tartom, hogy azok a kockázati tőke-finanszírozók, akiknek az induló (start up) projektjeit eddig láttam, nem használták ki a fent leírt modellt annyira, amennyire az agilis csapatok. A tőke-finanszírozók általában szemet hunynak afölött, ha az evaluation markerek időben túl távol esnek egymástól. Pedig, ha a kifizetést havonkénti szállításokhoz kötnék, az a fejlesztő csapatot (start-up team) arra ösztönözné, hogy átgondolja, mennyi munkát is tud hónapról hónapra elvégezni. A havonkénti fejlődés alapján pedig a finanszírozóknak világos képet adhatna arról, hogy milyen is a megbízott cég (start-up company) valós haladási üteme.</p> <h2>Inkrementális szállítás és -fizetés</h2> <p>Ez a “fix ár/feladatkör és határidő”, valamint a “fix ár/maximum ár” jellegű szerződésekben használható. A megrendelő ebben az esetben elvárja, hogy inkrementális módon megkapja az általa megrendelt, integrált és tesztelt rendszereket, amelyeket minden szállításkor szintén inkrementális módon saját maga is tesztel, és a megbízott céget abban az esetben fizeti ki, ha a tesztek sikeresen lezajlottak. Ezt a modellt használták egy repülőtér-építési projektben, vaalmint a “Solystic’s French Post Office” szerződésben. Mindkét projekt vezetője arról számolt be, hogy ez a konstrukció csodálatosan motiválta a beszállító céget. Persze mindehhez nélkülözhetetlen, hogy a megrendelő tisztában legyen az inkrementális fejlesztés mibenlétével, és el tudja végezni az időről időre esedékes teszteket.</p> <h2>Jonathan House ötlete</h2> <p>Fix ár, plusz 5% bónusz, ha időben szállítanak, vagy fix ár és 5% levonás, ha csúszik a projekt.</p> <h2>Variáció az óradíj- és dologi költségek-alapú fizetésre</h2> <p>A kiszámlázható munkaórák itt egy fix tartományban változhatnak (pl. havonként 180-240 óra az egész csapatnak), hogy elejét vegyék a korlátlan költekezésnek. Némi lehetőség itt is van arra, hogy szükség esetén megnöveljék az óraszámot és ezzel az árat, illetve ne történjen túlszámlázás, ha kevesebb munkaórára volt szükség. </p> <h2>Határozatlan munkamennyiség szállítása határozatlan időpontban</h2> <p>Ez önmagában is hatalmas témakör, amelyről a következő linken olvashatunk bővebben: <a href="http://alistair.cockburn.us/Indefinite+Delivery%2c+Indefinite+Quantity+or+IDIQ+contracts">Indefinite Delivery, Indefinite Quantity or IDIQ contracts</a></p> <h2>Norvég PS 2000 sztenderd szerződés</h2> <p>“Ennek a szoftverfejlesztési szerződésnek a lényege, hogy olyan mechanizmusokat bocsát az ügyfél és a fejlesztő cég rendelkezésére, amelyekkel közös egyetértésre juthatnak, valamint tartalmaz egy rugalmas iteratív modellt, amely alapján a fejlesztés során figyelembe lehet venni a felmerülő bizonytalanságokat és kockázatokat.” <br /> • Lépésről lépésre történő iteratív fejlesztési modell, amellyel fel lehet használni a követelményekről és a nehézségekről útközben megszerzett tudást és tapasztalatokat<br /> • Szoros együttműködés a beszállító cég és az ügyfél között<br /> • Beépített ösztönzők és szankciók, valamint target pricing<br /> • Konfliktuskezelési módszerek egy szakértő mediátor bevonásával”<br /> Ezt a szerződést meg kell rendelni (néhány ezer norvég koronába kerül).</p> <h2>Target-Cost szerződés</h2> <p>Idézet: <a href="http://www.sparkboxx.com/sparkboxx/types-of-contracts.html">http://www.sparkboxx.com/sparkboxx/types-of-contracts.html</a> “Ebben a szerződésben kitűznek egy kezdeti funkcionális célt, majd konzultációk segítségével meghatározzák, mennyi forrást és időt lenne célszerű befektetni ahhoz, hogy megvalósuljanak a kezdeti specifikációk. A funkcionalitáshoz kapcsolódó cél alapján megállapítanak egy kezdeti árat, amelyre rászámolnak egy bizonyos összeget váratlan helyzetekre, valamint profitot. Ha az ügyfél a projekt során megváltoztatja a munka kiterjedését, vagy ha váratlan követelmények merülnek fel, a megnövekedett költségeket (additions) három csoportba oszthatjuk: (Horowitz 2005): hibajavítások, pontosítások és teljesítményfokozások (enhancements).<br /> Az eredeti cikk a céláras szerződésről angolul itt olvasható: <a href="http://cyrusinnovation.com/downloads/agile2005_cyrusinnovation_targetcostcontracts_paper.pdf">http://cyrusinnovation.com/downloads/agile2005_cyrusinnovation_targetcostcontracts_paper.pdf</a><br /> </p> <p><a href="http://alistair.cockburn.us/Agile+contracts">Forrás</a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F02%2F14%2Fagilis_szerzodesek%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F02%2F14%2Fagilis_szerzodesek%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F02%2F14%2Fagilis_szerzodesek%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Agilis szerződések"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/02/14/agilis_szerzodesek#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2497971" border="0" /></a><br /></p>
agile
contract
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2011/01/19/az_onszervezo_csapat_sikerfaktorai
Az önszervező csapat sikerfaktorai
2011-01-19T00:03:00+01:00
2011-01-19T00:03:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p>Az agilis csapat jellemzője az önszerveződés, mely nélkülözhetetlen az agilis gondolkodás kialakulásához. Sokan úgy gondolják azonban, hogy az önszerveződő csapatok nem praktikusak. Valóban, ennek kialakulása nagyban függ a csapattagoktól, a menedzsmenttől, a cég szervezeti függelmeitől és a végzendő munka természetétől is. Ha kizárólag szoftverfejlesztő csapatokra gondolunk, három sikerfaktorát azonosíthatjuk a hatékony önszerveződés kialakításának.</p>
<h2>Tisztán definiált határok</h2>
<p>A csapatok tisztán és jól definiált határok mellett szervezhetik és menedzselhetik magukat szabadon és hatékonyan. A határok deklarálása nélkül a csapatok bizonytalanok abban, hogy milyen messzire mehetnek, illetve mennyire próbálhatják meg menedzselni magukat. Ha a csapattagok bizonytalanok, folyton figyelmeztetni fogják őket, hogy tilosban járnak. Előbb utóbb pedig mindenre engedélyt fognak kérni a menedzsmenttől, ez pedig teljesen lenullázza az önszerveződésben rejlő lehetőségeket.</p>
<h2>Hibatűrés és tanulásra szánt idő<strong><br />
</strong></h2>
<p>Gyakran előfordul, hogy a menedzsment önszerveződőnek deklarál egy csapatot és az első adódó alkalommal amikor hibát vétenek átveszi az irányítást a szituáció felett. Ha ez bekövetkezik az önszerveződésre törekvő kísérlet véget is ér. Ezután nagyon sok idő és erőfeszítés szükséges, hogy a csapat elhiggye a menedzsmentnek az eltökéltségét az önszerveződés engedélyezését és támogatását illetően.</p>
<h2>Kihívás, nem frusztrálás<strong><br />
</strong></h2>
<p>A csapat adminisztratív vagy funkcionális menedzserének érzékenynek kell lennie a csapat korlátait illetően, és ennek megfelelően alakítani az elvárásokat illetve a határokat. Mindezt oly módon, hogy a csapattagok kihívásnak tekintsék az elvárásokat ne pedig frusztrálónak. Azaz nem többet kívánni tőlük mint a legtöbb munka, amit kezelni is tudnak. Ez az alapja egy önszerveződés végső soron pedig egy projekt illetve az organizáció érettségének is.<br />
</p>
<p><a href="http://dnicolet1.tripod.com/agile/index.blog?entry_id=1914848">Forrás</a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F01%2F19%2Faz_onszervezo_csapat_sikerfaktorai%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F01%2F19%2Faz_onszervezo_csapat_sikerfaktorai%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2011%2F01%2F19%2Faz_onszervezo_csapat_sikerfaktorai%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Az önszervező csapat sikerfaktorai"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2011/01/19/az_onszervezo_csapat_sikerfaktorai#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2006287" border="0" /></a><br /></p>
team
agile
self_organize
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
https://agilitas.blog.hu/2010/12/27/vedett_a_menedzsmenttel_szemben
Védett a management-tel szemben?!
2010-12-27T11:34:00+01:00
2010-12-27T11:34:00+01:00
kulcsár bence
https://blog.hu/user/447749
<p><a href="http://agilitas.blog.hu/media/image/cartoon/gb004-protectedagainstmanagement.jpg"><img width="725" alt="" src="http://agilitas.blog.hu/media/image/cartoon/gb004-protectedagainstmanagement.jpg" /></a></p>
<p><a title="Megosztom Facebookon!" href="https://www.facebook.com/sharer.php?api_key=120587281320910&locale=hu_HU&method=stream.share&u=https%3A%2F%2Fagilitas.blog.hu%2F2010%2F12%2F27%2Fvedett_a_menedzsmenttel_szemben%3Futm_source%3Dbloghu_rss%26utm_medium%3Dfacebook%26utm_campaign%3Dblhshare"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_facebook.png" alt="Megosztom Facebookon!"></a>
<a title="Megosztom Twitteren!" href="https://twitter.com/home?status=https%3A%2F%2Fagilitas.blog.hu%2F2010%2F12%2F27%2Fvedett_a_menedzsmenttel_szemben%3Futm_source%3Dbloghu_rss"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_twitter.png" alt="Megosztom Twitteren!"></a>
<a title="Megosztom Tumblren!" href="https://www.tumblr.com/share?v=3&u=https%3A%2F%2Fagilitas.blog.hu%2F2010%2F12%2F27%2Fvedett_a_menedzsmenttel_szemben%3Futm_source%3Dbloghu_rss%26utm_medium%3Dtumblr%26utm_campaign%3Dblhshare&t=Védett a management-tel szemben?!"><img src="https://m.blog.hu/assets/frontend/img/rss/icon_tumblr.png" alt="Megosztom Tumblren!"></a>
<a href="https://agilitas.blog.hu/2010/12/27/vedett_a_menedzsmenttel_szemben#comments"><img class="item_ctp" src="https://agilitas.blog.hu/rss/image/post/id/2541510" border="0" /></a><br /></p>
0
Agilitás Blog - az agilitas.hu blogja
https://agilitas.blog.hu
http://agilitas.blog.hu/media/image/cartoon/gb004-protectedagainstmanagement.jpg