tag:blogger.com,1999:blog-57623124483516894532024-03-23T05:42:07.997-07:00Emmanuel CHENUThrough this blog, I want to share my passion for software development.
In "Practices", I share the practices we use to improve the way we develop software as a team.
In "TuffStuff", I tell you about the problems we sweat through.
In "Hits", I'll talk about our little victories.
In "BookReviews", I keep track of the books which helped us improve our way of working.
In "Cartoons" you'll find stories of strange but real situations we went through.Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.comBlogger250125tag:blogger.com,1999:blog-5762312448351689453.post-42202416939697388672014-12-08T13:44:00.002-08:002014-12-08T13:46:35.664-08:00Chokoban: Kanban & Chocobon<br />
<div style="text-align: justify;">
Voici le <b>Chokoban</b>: le Kanban de l'avent où un ticket passé à "done" donne droit à un Kinder Chocobon.</div>
<div style="text-align: justify;">
Ce n'est pas du pilotage à la carotte, mais une régression bénigne (c'est à dire qui ne fait pas échouer de test).</div>
<div style="text-align: justify;">
Enjoy :o)</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-GQV0r8rBScM/VIYaLD59E5I/AAAAAAAACao/eoMBpFixL7A/s1600/chokoban2.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://1.bp.blogspot.com/-GQV0r8rBScM/VIYaLD59E5I/AAAAAAAACao/eoMBpFixL7A/s1600/chokoban2.jpg" height="320" width="240" /></a><a href="http://2.bp.blogspot.com/-e5TX-CuDdHM/VIYaLIOPReI/AAAAAAAACas/Ux96Hwc1kZg/s1600/chokoban.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-e5TX-CuDdHM/VIYaLIOPReI/AAAAAAAACas/Ux96Hwc1kZg/s1600/chokoban.jpg" height="240" width="320" /></a></div>
Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com2tag:blogger.com,1999:blog-5762312448351689453.post-77987793557798363052012-11-26T14:27:00.005-08:002012-11-28T12:09:28.538-08:00Daily flash-meetings<div style="text-align: justify;">
<br />
<span style="font-family: Arial, Helvetica, sans-serif;">Daily flash-meetings have enabled us to build performing software development teams, to reduce work-in-progress and to improve product quality. Understand how with the following Plan-Do-Check-Act case study.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;">A problem is the starting point: our former project weekly meetings were inefficient. This problem will be described in terms of symptoms and impacts. The root causes will be identified and the plan to solve the problem will be established. Then, the experiments performed according to this plan will be described. Lastly, the results of these experiments will be measured and the lessons learnt will be provided. </span><br />
<span style="font-family: Arial, Helvetica, sans-serif;">Flash meetings are also known as <i>daily stand-up meetings</i> in Agile literature, and <i>daily scrums</i> in the particular case of Scrum.</span><br />
<div style="text-align: center;">
<br /></div>
<div style="color: #232323; text-align: center;">
<b><i><span style="font-family: Arial, Helvetica, sans-serif;">PLAN</span></i></b></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">We have been unsatisfied with our former project weekly-meetings. </span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Duration</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">With a target duration of an hour, our weekly meetings seemed too long. Many developers just did not like to spend an hour seated in a meeting room. Some felt uncomfortable pausing their development activities during a full hour. Moreover, after some time, long meetings tend to lose dynamism and efficiency. Within a one hour time-box, people do not always manage to stay focused on the highest priority topics. Stakeholders working on their laptop or texting messages during the meeting are a symptom of such loss of focus. Therefore, such meetings ended up by turning into a waste of time and lacked respect for the team's time.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Delay</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The meetings could be frustrating. Indeed, problems raised by team members during the meetings (such as desynchronized activities, process, technical or organizational issues) were dealt with too late, on a weekly basis at best. The information reported and monitored was already out-of-date, possibly a week old. The impact of daily work on our goals was not obvious, or was visible too late to enable us to drive our activities and aim for the expected performance. It was like steering a project which a one week delay, or like driving a car with your eyes open an hour per week.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Implication</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">On the long-term, some team members considered the meeting a waste of time and did not attend systematically. Some attended, but avoided to participate in fear of prolongating the meeting. Individually, the stakeholders reported their status, but the meeting was not a session of teamwork. Team members could feel a loss of interest and of implication in their project. This was mostly the case for long projects (over 3 years). Moreover, projects teams were not performing as expected. </span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Root causes</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The main root cause of this problem is an issue of frequency and duration. The periodicity of the meeting was low enough to create an accumulation of information and of problems to deal with. The periodicity was low enough to imply out-of-date data and missed synchronization points. In other terms, the frequency of the meeting (1 week) was much lower than the frequency of the problems to solve and of the decisions to take (typically 1 day). Therefore it was impossible to steer the activities with satisfying reactivity. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">In more Lean terms, our organization was building a week-worth stockpile of information every week, and was processing this stockpile only once a week. Unfortunately, some information (such as problems) within the one-week stockpile needed to be processed on a mush shorter notice. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Moreover, within the one hour target duration, part of the allocated meeting time was wasted on lower priority topics.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<b><i><span style="font-family: Arial, Helvetica, sans-serif;">DO</span></i></b></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">To assess the root cause, we have decided to dramatically raise the periodicity and reduce the duration of the meetings. Since 7 years we have been running short daily flash-meetings. Two of our development teams are currently running the following standard:</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Current standard</span></i></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Step #1: Kick-off</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The team meets for 15 minutes in the project war-room every day at the same hour. The team members rotate to lead the meeting according to a calendar displayed in the war-room. The daily leader calls the meeting and makes sure all stakeholders are present. All team members stand in a semi-circle, facing the project charts and task-board. Only the daily leader is seated, however also facing the charts. He edits the iteration backlog spreadsheet on a computer. It contains the prioritized list of development tasks for the current iteration, with status, costs and estimates. Only he sees the screen and the iteration backlog during the meeting.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Step #2: Nightly build</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Firstly, the daily leader reports the status of the nightly build. He organizes corrective actions if the build has failed and is not yet corrected. A build failure is considered a problem. Thanks to a long-term problem-solving, the nightly build is now successful over 70% of the time. Among other tasks, the nightly build </span></div>
<br />
<ul>
<li style="color: #232323; margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">builds the executable files,</span></li>
</ul>
<ul>
<li style="color: #232323; margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">runs the white-box unit-tests,</span></li>
</ul>
<ul>
<li style="color: #232323; margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">runs the black-box acceptance tests, </span></li>
</ul>
<ul>
<li style="color: #232323; margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">measures the product quality, </span></li>
</ul>
<ul>
<li style="color: #232323; margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">ships the product and</span></li>
</ul>
<ul>
<li style="color: #232323; margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">controls the build andon (a green/red light and a bell, green for success and red for failure).</span></li>
</ul>
<br />
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Step #3: Product quality</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Then, the team reports the product quality metrics while updating the quality graphs and trends. The team dispatches further analysis and corrective actions if product quality has decreased. A decrease in product quality is considered a problem. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">In fact, the team does not measure product quality, but product non-quality instead. The product non-quality is the sum of</span></div>
<div style="color: #232323;">
</div>
<div style="color: black;">
</div>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number of lines of code not fully covered by tests: instruction and modified condition/decision coverage rates (expected 0), </span></li>
</ul>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number of warnings in the code & tests the tests (expected 0), </span></li>
</ul>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number of times the coding standards are not fulfilled (expected 0),</span></li>
</ul>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number of traceability errors (expected 0),</span></li>
</ul>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number complex operations (expected 0 operation with a cyclomatic number over 6),</span></li>
</ul>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number of 'todo' & 'fixme' tags in the code & tests (expected 0),</span></li>
</ul>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number of tickets to estimate (expected 0),</span></li>
</ul>
<ul>
<li style="margin: 0px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">the number of opened tickets (expected 0).</span></li>
</ul>
<br />
<br />
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">All of these values are automatically measured by the nightly build. The value the sum makes no sense. However, a negative trend means that the product quality is improving. On the other hand, a positive trend reveals a quality decrease, and therefore a problem to solve.</span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The number of defects identified by the customer per thousand source lines of code on our incremental deliveries is monitored. However, this metric is too low and stable (below 0.1 per KSLOC) to enable to steer activities.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Step #4: Development tasks</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Then, reading the iteration backlog spreadsheet, the daily leader runs through the development tasks by order of priority. By task priority, the developers report their status to the team in terms of time spent, progress, re-estimation of remaining work and problems encountered. They visually update their work-in-progress on the project task-board while reporting their tasks by mowing their task-cards to the appropriate steps of the value-stream-map. The daily leader updates the task status, costs and estimates in the iteration backlog spreadsheet while the team members report their activities. The problems raised are displayed and assessed for immediate action or further analysis.</span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Once of all of the tasks in-progress have been scanned, the available team members pull new tasks from the iteration backlog by order of priority.</span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">If developers report complex problems or technical issues, the daily leader invites the stakeholders to resume the topic after the daily flash meeting.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Step #5: Team performance</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Once all the tasks have been scanned and updated, the daily leader reports the team performance to the team. This performance is measured according to the data provided by the team members and updated by the daily leader in the iteration backlog spreadsheet. The team performance is expressed in terms of costs, progress and product quality. The team members update the metrics on their performance graphs. </span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Step #6: Decisions</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Lastly the team analyzes the graphs, ends the meeting and shares on the day's challenge over coffee before resuming the development tasks according to their decisions.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Duration</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">If the team repeatedly doesn't manage to run its flash meetings within a 15 to 20 minutes timebox, then the team measures, displays and monitors the duration of the meeting day after day. The team finds solutions to shorten the meeting and checks that their corrective actions are effective. If the root cause of lengthy meetings is an oversized team, then the team splits into smaller teams. The team is split exactly as code is modularized: according to loose coupling and high coherence. Then each team runs 15-minute daily flash meetings, one after the other. To deal with inter-team dependencies, a team member participates to the flash meetings of the other teams of the same project. Then, a team lead updates and displays the consolidated performance of the teams.</span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">This standard is our current best way of running flash-meetings. We are confident in the fact that the teams will continue to improve it.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<b><i><span style="font-family: Arial, Helvetica, sans-serif;">CHECK</span></i></b></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">We have noted and measured the following results:</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Frequency</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">We run flash-meetings every working day since 7 years (which represents over 2500 meetings).<i> </i>Five of our project teams have practiced or are still practicing daily flash-meetings. The context ranges from a typical 7-member to one 50-member cross-functional project team. For this large project, the team was split into 4 cross-functional teams, each running its own daily flash-meeting.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Duration</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">With 15 to 20 minutes per daily flash-meeting, the overall time spent in status meetings stands somewhere between 1h15 and 1h40 per week. Therefore, compared to our former weekly meeting situation, the overall time spent in status meetings has not been reduced. </span></div>
<div style="color: #232323; min-height: 11px; text-align: center;">
<span style="font-family: Arial, Helvetica, sans-serif;"><i></i><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Focus</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">With a target duration of 15 minutes, the team members remove all unnecessary information from the meeting. By reducing the duration of the meeting, they focus on what is most important. The focus is set on steering, performance and problems. Because the team members stand up during the meeting and because the meeting remains short, laptops and cellphones are naturally excluded from the meeting.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Visible team performance</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Progress, costs and product quality graphs are displayed and are up-to-date. Problems are displayed and corrective actions or further analysis are in progress. The team members share a common vision of the development tasks to perform and of their priority. They share a vision of their performance in terms of costs, progress and product quality. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The work-in-progress is visualized on the task-board, revealing flow, problems, dependencies and bottlenecks. Software development is now visible and displayed in total transparency.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Work-in-progress and product quality</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The amount of work-in-progress has been reduced to 2 scales: the day and the iteration (a timebox of 10 work-days). Product quality has been raised, as each iteration visibly improves the quality of the product.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Implication</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The team members attend and actively participate every day. The meeting leader rotates every day among the team members. All the team members get to act as the daily leader.</span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The meeting is a session of intense and focused teamwork. The team members are very concerned by the project costs and milestones and by the product quality. This is obvious because the performance graphs are up-to-date and commented. We notice that this rigor remains for long projects (over 4 years). </span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Continuous improvement</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The meetings have a standard that is displayed in the war-room. It has changed several times: it is improved and adapted to the problems the team is currently facing.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<b><i><span style="font-family: Arial, Helvetica, sans-serif;">ACT</span></i></b></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">We have learned many things by practicing daily flash-meetings.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">The war-room</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">A dedicated war-room is very useful when several teams share a common workspace. Because all the team members get to talk during the meeting, the level of noise can be quite disturbing for neighbors. Visual management is used to display the performance graphs, the task-board and the problem-board. These information radiators are made of paper and magnetic boards, all updated by hand during the meeting.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">The schedule</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The meeting must not occur too soon in the morning as team members need to gather information for the meeting (such as the status of the nightly build and quality metrics computed by the build). Also, they need to investigate any build or product quality issues. However, the meeting must be scheduled early enough to plan the day. Our meetings are typically scheduled to start between 9AM and 10AM.</span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Because the meeting takes place at the same time every day, the schedule should be booked for all the team members on their calendar to avoid conflicts with other meetings on the same slot.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Computers and screens</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Only the team leader must use a computer during the meeting (in order to update the costs and progress of the tasks). The team must focus on the large visual task-board and on reporting and sharing information. Running the meeting in front of a large screen has been a failure, as team members focus on updating the iteration backlog spreadsheet instead of focusing on updating the status of their activities. This is why only the daily team leader sees the iteration backlog file.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">PDCA</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">We have learned that a daily flash-meeting defines the conditions of success for the day. This is the first step to success! Then, team members take action to meet success. Indeed, each day can be seen as a short Plan-Do-Check-Act cycle. The team starts the day by defining the today's challenge. Then, the team members plan the activities of the day in order to finish the agreed-upon tasks (Plan). The action resumes after the meeting (Do). Tomorrow, the team will check their performance (Check) in order to adjust their behavior to succeed tomorrow's challenge (Act). </span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Work-in-progress</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Combined with the nightly build, the daily flash-meeting enforces a daily cycle within which tasks are done. This greatly helps to reduce work-in-progress. It also helps to steer the project, as daily tasks enable to visualize daily progress.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Product quality</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">A problem that is not visible does not exist. Thanks to the product quality graph (updated on a daily basis and displayed with the other performance charts) any decrease in product quality becomes a visible problem and a visible challenge for the team. The impact of corrective actions led to raise product quality will be visible the following day. Thanks to this visible impact of a day of work on product quality, the team visibly improves the product quality, day after day.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Visible impact and motivation</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">With visible daily feedback on performance, the team visualizes the impact of their day of work on their common goals. Therefore, the team <i>sees</i> that they can make a difference, and that they have results. We believe that this is a great motivator and enhances autonomy.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Project steering</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The daily flash meeting can been seen as a daily short session of project steering. After such practice, we now believe that a single iteration burndown chart is not sufficient to steer the activities of the iteration during the meeting. A single iteration burndown chart (as practiced in Scrum) mainly focuses the team on completion of work within the milestone. Little focus is set on costs and product quality. Also, a single burndown chart enables to visualize that the team has a problem: for example that progress is slower than expected. However, it does not help the team to visualize <i>why</i> it has a problem. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">This is why we have standardized the use of several performance charts during flash-meetings. We use one product quality chart, several progress charts and several cost charts. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The progress charts are burndowns which focus on the completion of work within the milestone. We have a global "progress burndown" for the full iteration scope, and one per goal of the iteration. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The cost charts are burndowns which focus on the completion of work within the allocated budget. We have a global "cost burndown" for the full iteration scope, and one per goal of the iteration. </span></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">This set of charts reveals which task is setting (or risks to set) the iteration into trouble. For such a task, the charts reveal if the issue concerns progress and/or costs. By visualizing all this information, the team takes decisions and steers its activities. In fact, the project war-room is more of a project cockpit.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Learning</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The practice of flash-meetings enables the team members to develop skills. They learn to lead the meeting by following and improving the meeting standard. They learn to organize self-directed work with pull systems such as prioritized tasks lists (the iteration backlog) and task-boards in order to gain autonomy. They learn to identify and solve problems by defining their standards, by visualizing work-in-progress and by practicing problem-solving. By measuring and analyzing performance on a daily basis, the team members learn to take action based on facts and charts. They also share knowledge<i> at least</i> once per day. The team learns teamwork. This organization of learning aims for what Daniel Jones calls "the capability of the team to sustain and improve once you leave".</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Continuous improvement</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">We have learned that rotating among team members to lead the flash meeting is a great way to involve everyone in the continuous improvement of the meeting. The improvement of the daily flash meeting is a great case-study for learning and practicing continuous improvement. Indeed, it is a short activity performed every day according to a standard. This know-how may then be reused for other activities. Indeed, as Daniel Jones says: "The lasting value is the capability to solve the next set of problems".</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Discipline</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">The practice of daily flash-meetings implies a lot of discipline. The meeting <i>must</i> occur to establish the development tasks to perform that day. The meeting <i>must</i> start and finish on time, as several similar meetings follow each other in sequence. Each developer <i>must</i> focus on reporting only relevant information as all developers must manage to report their status and steer their activities within a 15 to 20 minute time-box. Typically, technical issues and complex problems must be set aside to be dealt with after the meeting among the relevant stakeholders.</span></div>
<div style="color: #232323; min-height: 11px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="color: #232323; text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Respect</span></i></div>
<div style="color: #232323;">
<span style="font-family: Arial, Helvetica, sans-serif;">Finally, the daily flash-meetings are a framework within which the team members share goals, responsibility and success; and develop skills and autonomy. This defines an environment of respect for people, their work and their time.</span></div>
<div style="min-height: 11px; text-align: center;">
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></div>
<div style="text-align: center;">
<i><span style="font-family: Arial, Helvetica, sans-serif;">Customer satisfaction</span></i></div>
<span style="font-family: Arial, Helvetica, sans-serif;">Daily flash-meetings enable to develop teams, who improve their way of working day after day, to build higher quality products on-time for their customers</span><span style="font-family: 'Times New Roman'; font-size: 10px;">.</span><br />
<div>
<br /></div>
</div>
Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-24808453027375254572011-10-06T13:26:00.000-07:002011-10-06T13:32:19.181-07:00A VOS MARQUES, PRETS, PARTEZ!<div class="separator" style="clear: both; text-align: justify;">
<a href="http://3.bp.blogspot.com/-AZraJA1CcdI/To4NOnU8poI/AAAAAAAABzU/_Q2EGG_CufA/s1600/Kanban_vierge.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="112" src="http://3.bp.blogspot.com/-AZraJA1CcdI/To4NOnU8poI/AAAAAAAABzU/_Q2EGG_CufA/s320/Kanban_vierge.jpg" width="320" /></a></div>
<div style="text-align: justify;">
Nous démarrons une itération <i>(nous ne les comptons plus!)</i>. Nous avons 2 types d'activités à réaliser en 16 jours, donc 2 <a href="http://emmanuelchenu.blogspot.com/2009/03/lean-cartographie-du-flux-de-valeur.html">value-stream-maps</a> différents, donc 2 <a href="http://emmanuelchenu.blogspot.com/2009/07/lean-le-flux-tire-de-creation-de-valeur.html">Kanbans</a> différents (à gauche). Les tâches priorisées et estimées sont sur les colonnes de départ <i>(TODO)</i>. Les jetons de ressources sont regroupés au milieu <i>(en jaune)</i>. Nos 5 <a href="http://emmanuelchenu.blogspot.com/2011/09/etre-bon.html">indicateurs de performance</a> vierges sont affichés <i>(à droite)</i>. Le standard décrivant l'utilisation du Kanban et des indicateurs de performance est également affiché<i> (à l'extrême droite)</i>.<br />
C'est parti!</div>
Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com8tag:blogger.com,1999:blog-5762312448351689453.post-25650842638717459252011-09-18T02:17:00.000-07:002011-09-18T02:37:52.822-07:00ETRE BON<a href="http://3.bp.blogspot.com/-A38It9cEoVQ/TnW07GjeXMI/AAAAAAAABs0/VjrIAH3jYrk/s1600/indicateurs.jpg"><img alt="" border="0" src="http://3.bp.blogspot.com/-A38It9cEoVQ/TnW07GjeXMI/AAAAAAAABs0/VjrIAH3jYrk/s320/indicateurs.jpg" style="cursor: pointer; float: left; height: 320; margin-bottom: 10px; margin-left: 0px; margin-right: 10px; margin-top: 0px; text-align: justify; width: 240px;" /></a><br />
<div style="text-align: justify;">
A l'occasion du <a href="http://emmanuelchenu.blogspot.com/2011/07/mener-son-equipe.html">précédent billet</a>, j'ai evoqué que <a href="http://emmanuelchenu.blogspot.com/2011/07/mener-son-equipe.html">mener son équipe</a> impliquait (entre autres) de mettre les équipiers en difficulté pour qu'ils se développent.
</div>
<div>
<div style="text-align: justify;">
Deux soirées passées avec mon coach officieux m'ont permis de travailler cet aspect du leadership.</div>
</div>
<div>
<div style="text-align: justify;">
Il est intéressant de demander à l'équipe ce que "être bon" signifie dans le cadre de leur activité: <i>"Pour vous, qu'est ce que cela signifie d'être bon?" </i>(petite mise en difficulté :o)</div>
</div>
<div>
<div style="text-align: justify;">
<br /></div>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<ul>
<li style="text-align: justify;">La première étape de cette réflexion amène à se rappeler de la raison d'être de l'équipe. Quelle est sa <b>mission, </b>quels sont ses <b>objectifs</b>? En quoi est-ce que l'équipe contribue à l'organisation? <i>A cette étape, nous connaissons le but à atteindre.</i></li>
<li style="text-align: justify;">Ensuite, il s'agit d'identifier les critères de réussite de l'équipe. Quels <b>faits</b>, quelles <b>métriques</b>, quels <b>indicateurs</b> permettent objectivement d'affirmer que les objectifs sont tenus? <i>A cette étape, nous savons identifier si nous avons atteint le but.</i></li>
<li style="text-align: justify;">Puis, il s'agit d'identifier <b>où</b> nous en sommes dans la poursuite des objectifs. Pour cela, il faut mesurer les résultats actuels et les comparer aux résultats cibles. <i>A cette étape, nous savons identifier où nous en sommes par rapport au but.</i></li>
<li style="text-align: justify;">Enfin, il "reste" à mesurer l'historique des résultats pour révéler la <b>performance</b> et la comparer à la performance cible. Cette étape permet à l'équipe de mesurer l'effet de l'amélioration continue de ses pratiques. <i>A ce stade, nous savons estimer le moment où nous atteindrons le but.</i></li>
<li style="text-align: justify;">A la question <i>"qu'est ce cela signifie d'être bon?"</i>, on peut répondre objectivement en connaissance de cause, en s'appuyant sur des faits collectés par la démarche ci-dessus. C'est pour cela que les résultats de la démarche ci-dessus sont <b>visuels, affichés, à jour et commentés</b>. Ainsi, à l'aide d'un <b>affichage visuel</b>, on peut <b>synthétiquement</b> désigner et chiffrer l'objectif, montrer le résultat actuel, la tendance, l'estimation d'atteinte de l'objectif et présenter les actions en cours pour améliorer la performance.</li>
</ul>
<div style="text-align: justify;">
Si l'équipe est en mesure de répondre ainsi à la question <i>"qu'est ce cela signifie d'être bon?"</i>, c'est qu'elle pilote son activité. Cela révèle aussi qu'il faut la remettre en difficulté pour qu'elle se développe encore! En attendant, il reste du travail: la mise en pratique n'est pas encore au point :o)</div>
</div>
Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com2tag:blogger.com,1999:blog-5762312448351689453.post-75945219918185745042011-07-10T05:59:00.000-07:002011-09-18T02:27:54.432-07:00MENER SON EQUIPE<a href="http://2.bp.blogspot.com/-KwNTcUZ_Wk4/Thn-Jq5Yh8I/AAAAAAAABsg/YmKDCyjuw9g/s1600/lean_synchro_equipe.jpg"></a><br />
<blockquote>
</blockquote>
<a href="http://2.bp.blogspot.com/-KwNTcUZ_Wk4/Thn-Jq5Yh8I/AAAAAAAABsg/YmKDCyjuw9g/s1600/lean_synchro_equipe.jpg"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5627808651463395266" src="http://2.bp.blogspot.com/-KwNTcUZ_Wk4/Thn-Jq5Yh8I/AAAAAAAABsg/YmKDCyjuw9g/s400/lean_synchro_equipe.jpg" style="cursor: pointer; float: left; height: 323px; margin-bottom: 10px; margin-left: 0px; margin-right: 10px; margin-top: 0px; text-align: justify; width: 400px;" /></a><br />
<div style="text-align: justify;">
Après plus de 5 ans de pratique des démarches <a href="http://en.wikipedia.org/wiki/Agile_development">agiles</a> et <a href="http://en.wikipedia.org/wiki/Lean_manufacturing">lean</a>, ma pratique du rôle de <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a> a largement évoluée pour s'éloigner de sa définition initiale.</div>
<div style="text-align: justify;">
A une phase tournante de mon engagement sur mon projet actuel, j'en profite pour faire un point sur le <b>rôle initial de <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a></b> et <b>ce qu'il est devenu</b> après plus d'une vingtaine d'itérations mensuelles. Cette évolution me semble si significative que le rôle strict de <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a> me parait désormais sous-optimal.</div>
<div style="text-align: justify;">
<b>SCRUMMASTER</b></div>
<div style="text-align: justify;">
Selon les fondateurs de <a href="http://en.wikipedia.org/wiki/Scrum_(development)">Scrum</a>, le <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a> se doit de</div>
<div>
<ul>
<li style="text-align: justify;">retirer les obstacles qui gênent l'équipe dans sa poursuite des objectifs d'itération;</li>
<li style="text-align: justify;">agir comme un tampon<b> </b>entre l'équipe et les influences perturbatrices;</li>
<li style="text-align: justify;">se mobiliser pour que la démarche <a href="http://en.wikipedia.org/wiki/Scrum_(development)">Scrum</a> soit mise en pratique conformément à sa définition;</li>
<li style="text-align: justify;">garder l'équipe concentrée sur les objectifs d'itération et les tâches en cours;</li>
</ul>
</div>
<div style="text-align: justify;">
<b>GESTIONNAIRE</b></div>
<div style="text-align: justify;">
Le rôle de <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a> est bien loin du <b>gestionnaire d'équipe</b> <i>(alias <b>manager</b>)</i> qui pratique souvent un pilotage solitaire et analytique sur la base de métriques et d'indicateurs. Le manager gère des ressources sans forcement avoir recours à la pratique du leadership.</div>
<div style="text-align: justify;">
<b>MENEUR</b></div>
<div style="text-align: justify;">
Le rôle de <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a> s'apparente d'avantage à celui du <b>meneur d'équipe</b> <i>(alias <b>leader</b>)</i> même s'il n'en prend pas toute la force. En effet, le <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a> est souvent présenté comme un <b>facilitateur</b> ou un <b>animateur</b> recherchant à tout prix le <b>consensus</b> au sein du projet. Ce rôle<b> mou et peu engagé </b>à mon avis n'est pas encore celui du meneur d'équipe. </div>
<div>
</div>
<blockquote>
<div style="text-align: justify;">
<i>Le meneur d'équipe </i><b><i>mène</i></b><i> son équipe (pléonasme).</i></div>
<div>
</div>
</blockquote>
<div style="text-align: justify;">
<b>S'ENGAGER</b></div>
<div style="text-align: justify;">
Mener son équipe c'est <b>s'engager avec elle</b> dans la poursuite de ses objectifs. Que cela soit bien clair: le leader échoue si l'équipe échoue. Le leader est bien dans la même barque que ses équipiers. Le leader doit donc <b>contribuer</b> à la poursuite des objectifs de son équipe. Il doit mettre ses compétences et son action au service de la réussite des équipiers.</div>
<div>
</div>
<blockquote>
<div style="text-align: justify;">
<i>Quelles sont ces compétences et cette action?</i></div>
</blockquote>
<div>
<div style="text-align: justify;">
<b>MONTRER L'EXEMPLE</b></div>
</div>
<div>
<i><span class="Apple-style-span" style="font-style: normal;"></span></i><br />
<div style="text-align: justify;">
<i><span class="Apple-style-span" style="font-style: normal;">Le meneur d'équipe doit montrer l'exemple. Il ne s'agit pas de <b>dire</b> ce qu'il faut faire, mais de <b>montrer </b>ce qu'il faut faire. Pour cela, il faut <b>faire</b>! On y revient encore: le leader est dans l'action. Il doit <b>pratiquer</b> pour montrer la voie à suivre. <i>(Que penser du scrummaster facilitateur et non développeur?)</i></span></i></div>
<div style="text-align: justify;">
<i><span class="Apple-style-span" style="font-style: normal;"><b>PRATIQUER</b></span></i></div>
</div>
<div style="text-align: justify;">
<b>Un leader ne peut exiger de ses équipiers un comportement que lui-même n'a pas</b>. Si le leader exige de ses équipiers que leur code soit testé, sans duplication, explicite et le plus court possible, alors lui-même se doit d'écrire du code testé, sans duplication, explicite et le plus court possible <i>(j'en imagine certains qui sourient et d'autres qui grincent des dents)</i>. C'est à ce prix que le leader sera <b>légitime</b> et que ses équipiers <b>accepteront</b> de mettre en pratique les standards.</div>
<div>
</div>
<blockquote>
<div style="text-align: justify;">
<i>Ainsi, mener l'équipe c'est ouvrir la voie pour que l'équipe la prenne à sa suite.</i></div>
<div>
</div>
</blockquote>
<div style="text-align: justify;">
<b>ENSEIGNER</b></div>
<div style="text-align: justify;">
Il ne suffit pas au leader de <b>pratiquer</b> pour <b>montrer</b> la voie, puis d'exiger de ses équipiers qu'ils suivent cette voie. Le leader doit absolument <b>enseigner </b>le métier. Il doit enseigner</div>
<div>
<ul>
<li style="text-align: justify;">la <b>pratique</b> en expliquant <b>comment</b> nous travaillons dans l'équipe<i> (quels sont les standards?).</i></li>
<li style="text-align: justify;">la <b>philosophie</b> en expliquant <b>pourquoi</b> nous travaillons de cette manière dans l'équipe. L'enseignement de la philosophie est primordial car nous pratiquons de manière d'autant plus efficace que nous comprenons pourquoi nous pratiquons ainsi. L'objectif est de faire <b>adhérer</b> aux pratiques. Aussi <i>(et surtout!)</i>, comprendre pourquoi est un pré-requis pour <b>améliorer les pratiques</b>.</li>
</ul>
</div>
<div style="text-align: justify;">
Le <b><a href="http://en.wikipedia.org/wiki/Pair_programming">pair-programming</a></b> est une manière très pertinente d'organiser l'enseignement. Dans un tel cadre, le leader doit binômer et il doit s'assurer que les anciens binôment.</div>
<div>
<i></i></div>
<blockquote>
<div style="text-align: justify;">
<i>Petit rappel pour le plaisir: Pour enseigner il faut pratiquer.</i></div>
</blockquote>
<div style="text-align: justify;">
<b>FAIRE REUSSIR</b></div>
<div style="text-align: justify;">
L'objectif du meneur est de faire réussir ses équipiers. Une manière d'y parvenir est de mener les équipiers à l'<b>autonomie</b>, de les pousser à se <b>perfectionner</b> et à donner du <b>sens</b> à leur travail.</div>
<div style="text-align: justify;">
<b>MENER A L'AUTONOMIE</b></div>
<div style="text-align: justify;">
L'autonomie a un impact positif sur la motivation, l'efficacité et l'engagement. Le leader se doit de pousser les équipiers à devenir autonomes.</div>
<div style="text-align: justify;">
Par exemple, il s'agit de ne pas de donner la solution à un problème posé, mais de mettre sur la voie, d'accorder du temps pour traiter le problème, puis de s'assurer que le problème est en cours de résolution.</div>
<div style="text-align: justify;">
Le meneur d'équipe doit pousser ses équipiers à le remplacer. Ainsi, les plus anciens participent à former les plus jeunes; chacun pilote un chantier de <a href="http://en.wikipedia.org/wiki/Problem_solving">résolution de problème</a> <i>(et donc d'amélioration!);</i> les daily-stand-up-meetings, planifications et rétrospectives peuvent être préparés et animés de manière tournante, etc.</div>
<div style="text-align: justify;">
Il est important d'organiser le travail pour que les équipiers puissent <b>décider par eux-même de leurs activités</b>. Les <b>backlogs </b><i>(priorisés par définition!)</i>, les <b>faits techniques priorisés</b>, les <b>kanbans</b> et <b>taskboards</b>, les <b>standards</b> et <b>modes opératoires</b>, les <b>indicateurs visuels de pilotage</b>, les <b>andons</b> sont des outils d'aide à la décision dont la bonne utilisation engendre l'autonomie.</div>
<div style="text-align: justify;">
En matière d'autonomie, les objectifs du leader peuvent être les suivants: </div>
<div>
<ul>
<li style="text-align: justify;">s'il s'absente, l'équipe assure l'intérim;</li>
<li style="text-align: justify;">s'il quitte l'équipe, un équipier peut prendre son rôle; </li>
<li style="text-align: justify;">les équipiers identifient les tâches à mener;</li>
<li style="text-align: justify;">un équipier motivé peut mener une autre équipe.</li>
</ul>
</div>
<div style="text-align: justify;">
<b>CONDUIRE LE PERFECTIONNEMENT</b></div>
<div style="text-align: justify;">
Le leader doit pousser ses équipiers à se perfectionner. Des équipiers performants résolvent les problèmes et établissent des standards efficaces qui permettent de bien développer de bons produits. Le perfectionnement est également une grande source de motivation personnelle.</div>
<div style="text-align: justify;">
La mise en situation, le <b><a href="http://en.wikipedia.org/wiki/Pair_programming">pair-programming</a></b> et la <a href="http://en.wikipedia.org/wiki/Problem_solving">résolution de problèmes</a> sont des outils efficaces pour aider les équipiers à se perfectionner. Le leader peut utiliser ces moyens pour entretenir un rythme de perfectionnement.</div>
<div style="text-align: justify;">
<b>DONNER DU SENS</b></div>
<div style="text-align: justify;">
Le leader doit expliquer aux équipiers quels sont les bénéfices pour l'entreprise, pour les clients, pour leurs collègues et pour eux-mêmes de leur travail et de leur manière de travailler. La conscience des bénéfices de son travail impact positivement la motivation et l'engagement.</div>
<div style="text-align: justify;">
<b>CONDUIRE LA RESOLUTION DES PROBLEMES</b></div>
<div style="text-align: justify;">
Le <a href="http://en.wikipedia.org/wiki/Scrum_master#Core_Scrum_roles">scrummaster</a> doit <b>retirer les obstacles</b> qui gênent l'équipe dans la poursuite de ses objectifs. En résolvant lui-même ces problèmes, le scrummaster ne mène pas ses équipiers à l'autonomie et il ne conduit pas leur perfectionnement. Lui seul développera ses compétences.</div>
<div style="text-align: justify;">
C'est pourquoi le meneur d'équipe doit <b>conduire la <a href="http://en.wikipedia.org/wiki/Problem_solving">résolution des problèmes</a></b>. Il s'agit</div>
<div>
<ul>
<li style="text-align: justify;">d'enseigner une <b>démarche structurée</b> de résolution de problème;</li>
<li style="text-align: justify;">d'expliquer en quoi cette pratique <b>développe les compétences des équipiers;</b> </li>
<li style="text-align: justify;">d'expliquer en quoi cette pratique <b>améliore la performance de l'entreprise</b>; puis</li>
<li style="text-align: justify;">d'allouer les chantiers dans l'équipe (ou de s'assurer que les équipiers s'allouent des problèmes à résoudre); et </li>
<li style="text-align: justify;">d'animer ou suivre l'avancement des chantiers de résolution de problèmes. </li>
</ul>
<div style="text-align: justify;">
Pour montrer l'exemple et pour développer ses propres compétences, le leader se doit de mener lui-même des chantiers de résolution de problèmes.</div>
</div>
<div style="text-align: justify;">
La pratique en continue de la résolution de problèmes est un outil très performant pour développer les compétences. En effet, elle exige des équipiers qu'ils comprennent en profondeur les problèmes (avec symptômes, impacts et causes racines) et qu'ils identifient et mettent en place des contremesures efficaces.</div>
<div>
<div style="text-align: justify;">
<b>AMELIORER LES PRATIQUES</b></div>
</div>
<div style="text-align: justify;">
La pratique en continue de la résolution de problème est également un outil très performant pour améliorer les pratiques (ou standards) de l'entreprise. En effet, ces chantiers font évoluer les standards pour intégrer les contremesures identifées. </div>
<div style="text-align: justify;">
Donc, là encore, le leader doit conduire la résolution de problèmes. Il doit tout particulièrement s'assurer que les équipiers enrichissent les standards avec les enseignements de leur chantiers.</div>
<div style="text-align: justify;">
<b>RECHERCHER LE CONSENSUS</b></div>
<div style="text-align: justify;">
Bien sur, le meneur d'équipe doit en priorité rechercher le consensus au sein de l'équipe. L'adhésion aux décisions sera d'autant plus aisée.</div>
<div style="text-align: justify;">
Par contre, par moment, le consensus ne sera pas obtenu et c'est normal. Si je finançais mon projet avec mon argent propre, je ne laisserai pas les experts et les anciens ramer pour obtenir un consensus alors que leur expérience leur révèle la solution. Le prix d'un expert et d'un ancien est le prix de son expérience. Il se doit d'utiliser son expérience pour empêcher les plus novices de commettre les mêmes erreurs. Certes, nous apprenons par nos erreurs, mais si nous pouvions éviter d'en faire trop, ce serait tout même préférable pour le projet. Dans un tel cas de figure, une solution issue de l'expérience et imposée sans consensus doit être expliquée afin de rechercher au mieux l'adhésion des équipiers.</div>
<div style="text-align: justify;">
<b>ET RECURSIVEMENT</b></div>
<div style="text-align: justify;">
Tout ce qui a été dit pour le meneur d'équipe me semble également valable pour le meneur de l'équipe des meneurs d'équipes. Et ainsi de suite ...</div>
<blockquote>
<div style="text-align: justify;">
</div>
</blockquote>
<div style="text-align: justify;">
A méditer!</div>
<div>
</div>
<br />
<div style="height: 55px; width: 220px;">
<object height="55" width="220"><param name="movie" value="http://www.deezer.com/embedded/small-widget-v2.swf?idSong=749705&colorBackground=0x555552&textColor1=0xFFFFFF&colorVolume=0x39D1FD&autoplay=0">
<embed src="http://www.deezer.com/embedded/small-widget-v2.swf?idSong=749705&colorBackground=0x525252&textColor1=0xFFFFFF&colorVolume=0x39D1FD&autoplay=0" type="application/x-shockwave-flash" height="55" width="220"></embed></object>
</div>
Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com14tag:blogger.com,1999:blog-5762312448351689453.post-2337436947911736202011-01-22T04:43:00.000-08:002011-01-28T02:00:55.708-08:00RÉSOUDRE LES PROBLÈMES UN A UN POUR AMÉLIORER LES PRATIQUES<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_pwMHzqjHPX4/TTsVhmbq7MI/AAAAAAAABqI/1pYTUdhYun4/s1600/conf_pdca.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 398px; height: 400px;" src="http://2.bp.blogspot.com/_pwMHzqjHPX4/TTsVhmbq7MI/AAAAAAAABqI/1pYTUdhYun4/s400/conf_pdca.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5565065431542852802" /></a><div style="text-align: justify;">Lorsque nous abordions le <a href="http://en.wikipedia.org/wiki/Lean_manufacturing">Lean</a> pour le mettre en pratique sur nos projets de développement, nous l'abordions selon les axes suivants:</div><div><ul><li style="text-align: justify;"><span class="Apple-style-span">la <a href="http://emmanuelchenu.blogspot.com/2009/03/lean-la-valeur.html">définition de la valeur</a>, </span></li><li style="text-align: justify;"><span class="Apple-style-span">la <a href="http://emmanuelchenu.blogspot.com/2009/03/lean-cartographie-du-flux-de-valeur.html">cartographie du flux de valeur</a>, </span></li><li style="text-align: justify;"><span class="Apple-style-span">le <a href="http://emmanuelchenu.blogspot.com/2009/06/lean-le-flux-continu-de-valeur.html">flux continu</a>, </span></li><li style="text-align: justify;"><span class="Apple-style-span">le <a href="http://emmanuelchenu.blogspot.com/2009/06/lean-le-flux-continu-de-valeur.html">flux tiré</a> et </span></li><li style="text-align: justify;"><span class="Apple-style-span">le <a href="http://emmanuelchenu.blogspot.com/2009/09/lean-la-perfection.html">perfectionnement</a>. </span></li></ul><span class="Apple-style-span"><div style="text-align: justify;">Cette approche, très centrée sur le process, nous a amené à reprendre des <b>outils </b>issus du Lean qui ont été efficaces chez d'autres et à les mettre en oeuvre chez nous: <a href="http://en.wikipedia.org/wiki/Value_stream_mapping">value stream mapping</a>, <a href="http://en.wikipedia.org/wiki/Kanban">kanban</a>, <a href="http://en.wikipedia.org/wiki/Just-in-time_(business)">just in time</a>, <a href="http://en.wikipedia.org/wiki/Autonomation">autonomation</a>, <a href="http://en.wikipedia.org/wiki/Jidoka">jidoka</a>, <a href="http://en.wikipedia.org/wiki/Andon_(manufacturing)">andon</a>, etc ...</div></span></div><div style="text-align: justify;"><span class="Apple-style-span"><span class="Apple-style-span">Cette démarche s'est greffée sur notre déjà longue pratique du <a href="http://en.wikipedia.org/wiki/Agile_software_development">développement logiciel agile</a>, centrée sur l'<a href="http://en.wikipedia.org/wiki/Extreme_programming">eXtreme-Programming</a> <i>(d'abord!)</i> et <a href="http://en.wikipedia.org/wiki/Scrum_(development)">Scrum</a> <i>(pour la forme)</i>. </span><span class="Apple-style-span">Naturellement, le terrain de rencontre de ces deux démarches a été le <a href="http://en.wikipedia.org/wiki/Lean_software_development">Lean Software Development</a>.</span></span></div><div style="text-align: justify;"><span class="Apple-style-span"><span class="Apple-style-span">Nous sommes fiers d'avoir obtenus de très bons résultats sur de gros projets, dans des domaines à priori peu réceptifs à ces pratiques et d'avoir été félicités par nos clients pour la tenue des jalons, la qualité des produits et notre</span><span class="Apple-style-span"> transparence.</span></span></div><div style="text-align: justify;"><span class="Apple-style-span">Pourtant nous traînons encore des <b>problèmes de longue date</b> <i>(en terme d'années!)</i> qui nous ralentissent, réduisent notre performance et attaquent notre moral.</span></div><div style="text-align: justify;"><span class="Apple-style-span">Comment cela est-il possible alors que nous pratiquons un développement logiciel agile et Lean qui a lentement évolué pour s'adapter à notre domaine? Sommes-nous réellement sur la bonne voie?</span></div><div style="text-align: justify;"><span class="Apple-style-span">Des aides extérieures et des recherches nous ont permis de prendre conscience que nous pratiquions un <b>Lean scolaire</b>. Cette pratique consiste à enrichir notre démarche issue de l'eXtreme-Programming et de Scrum avec des outils du Lean qui ont fait leurs preuves, sans pour autant assimiler le <b>coeur du Lean</b>.</span></div><div style="text-align: justify;"><span class="Apple-style-span">Depuis, nous <b>essayons </b>d'aborder le Lean de la manière suivante:</span></div><div><ul><li style="text-align: justify;"><span class="Apple-style-span"><b>visualiser </b>le production pour révéler les <b>problèmes</b>,</span></li><li style="text-align: justify;"><span class="Apple-style-span"><b>réagir </b>immédiatement,</span></li><li style="text-align: justify;"><span class="Apple-style-span">puis <b>résoudre </b>les problèmes un à un </span></li><li style="text-align: justify;"><span class="Apple-style-span">pour <b>améliorer </b>les pratiques.</span></li></ul><span class="Apple-style-span"><div style="text-align: justify;">Nos précédentes initiatives nous ont déjà conduit à "visualiser la production pour révéler les problèmes et réagir immédiatement". Nous continuons à peaufiner cette pratique. Par contre, nous essayons désormais de sérieusement nous attaquer au pan du Lean que nous avons trop négligé, c'est à dire <b>résoudre les problèmes un à un pour améliorer les pratiques</b>.</div></span></div><div style="text-align: justify;"><span class="Apple-style-span">Attention, il ne s'agit pas là de la rétrospective d'itération ou de la collecte des obstacles par le ScrumMaster lors des réunions quotidiennes dans l'objectif d'aplanir la route devant l'équipe!</span></div><div style="text-align: justify;"><span class="Apple-style-span">Il s'agit d'une <b>discipline de tous les jours, pour tous, à tous les niveaux</b>, qui consiste à avoir toujours un problème à résoudre. Ce problème doit être analysé, décortiqué et compris pour être éventuellement résolu si le retour sur investissement le justifie.</span></div><div style="text-align: justify;"><span class="Apple-style-span">Pour les problèmes coriaces, la <b>démarche est structurée</b>. Par exemple pour nous, cela consiste à suivre les étapes suivantes:</span></div><div><ul><li style="text-align: justify;"><span class="Apple-style-span">décrire le <b>problème </b>tel qu'on le perçoit;</span></li><li style="text-align: justify;"><span class="Apple-style-span">identifier et quantifier les <b>impacts </b>du problème pour notre client et pour notre organisation;</span></li><li style="text-align: justify;"><span class="Apple-style-span">décrire comment les choses devraient se dérouler, puis décrire comment elles se déroulent réellement. Décrire l'<b>écart</b> entre les deux.</span></li><li style="text-align: justify;"><span class="Apple-style-span">identifier les <b>causes racines</b> du problème et pondérer leur impact sur le problème;</span></li><li style="text-align: justify;"><span class="Apple-style-span">pour chaque cause racine, identifier des <b>solutions candidates</b> qui l'élimineraient;</span></li><li style="text-align: justify;"><span class="Apple-style-span"><b>classifier </b>les solutions candidates en fonction de leur coût de mise en oeuvre et de leur impact sur la résolution du problème;</span></li><li style="text-align: justify;"><span class="Apple-style-span"><b>mettre en oeuvre</b> les solutions par retour sur investissement décroissant jusqu'à ce que le retour sur investissement n'en vaille plus la peine;</span></li><li style="text-align: justify;"><span class="Apple-style-span">si elles ont été efficaces, <b>standardiser </b>les nouvelles pratiques mise en oeuvre;</span></li><li style="text-align: justify;"><span class="Apple-style-span"><b>communiquer </b>les leçons.</span></li></ul><span class="Apple-style-span"><br /><div style="text-align: justify;">Cette <b>discipline individuelle et d'équipe</b> nous aide en ce moment à résoudre <i>(entre autres)</i> un problème que nous traînons depuis un an. Pour la première fois depuis longtemps, nous constatons une<b> réelle amélioration </b>du phénomène et ce pour un très faible investissement. Ceci nous ouvre de belles perspectives d'amélioration!</div></span></div><div style="text-align: justify;"><span class="Apple-style-span"><span class="Apple-style-span">Le plus <b>motivant </b>à mon avis est que cette discipline est une <b>école d'experts</b>. En effet, puisqu'elle exige de passer par une <b>profonde et complète compréhension des problèmes</b>, elle pousse les acteurs de la démarche à <b>développer leur</b></span><span class="Apple-style-span"><b> expertise</b>. Même si la résolution du problème n'est pas déclenchée par manque de retour sur investissement, les acteurs sauront ne pas commettre la même erreur à la prochaine occasion. Puisque tous sont concernés par cette discipline, tous sont amenés à développer leurs compétences.</span></span></div><div style="text-align: justify;"><span class="Apple-style-span">Finalement, il se s'agit pas plus d'appliquer "un bon processus qui fait un bon produit" mais plutôt "d'appliquer une démarche qui développe des experts qui sauront mettre au point un bon processus qui fait un bon produit" <i>(vous me suivez toujours?)</i>. L'effet premier recherché est l'<b>implication</b> et le <b>développement des compétences</b>. L'effet secondaire est <b>l'amélioration des pratiques</b>.</span></div><div style="text-align: justify; "><span class="Apple-style-span">Avec cette nouvelle perspective, nous essayons de passer d'une démarche d'<b>amélioration discontinue</b> faite d'initiatives personnelles basées sur des intuitions à une démarche collective d'<b>amélioration continue</b> rigoureuse et disciplinée.</span></div><div style="text-align: justify;"><span class="Apple-style-span">Cette discipline clarifie également le rôle des "leaders". Pour eux, il s'agit d'<b>enseigner</b> la démarche à leur équipe et à "challenger" leurs équipiers pour qu'ils analysent et résolvent leurs problèmes. Le "leader" est lui-même "challengé" par son leader/coach/manager/mentor, et ainsi de suite ...</span></div><div style="text-align: justify;">Un prochain billet sera d'ailleurs consacré au <b>rôle de leader</b>, tel que décrit par Scrum, par l'eXtreme-Programming, par le Lean et tel que nous le pratiquons.</div><div style="text-align: justify;"><span class="Apple-style-span"><i>Merci encore pour l'aide extérieure!</i></span></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com16tag:blogger.com,1999:blog-5762312448351689453.post-30237548629759632682010-06-16T00:50:00.000-07:002010-06-23T01:19:04.646-07:00VISUALISER LA PRODUCTION POUR REVELER LES PROBLEMES<div style="text-align: justify;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_pwMHzqjHPX4/TB3eYfu-xXI/AAAAAAAABnQ/UyuNagkK8g0/s1600/roadsign.svg.png"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 319px; height: 279px;" src="http://3.bp.blogspot.com/_pwMHzqjHPX4/TB3eYfu-xXI/AAAAAAAABnQ/UyuNagkK8g0/s400/roadsign.svg.png" alt="" id="BLOGGER_PHOTO_ID_5484784433623909746" border="0" /></a><span style="font-weight: bold;font-family:arial;" >UN RAPPEL A L'ORDRE</span><br /><br /><span style="font-family:arial;">Il y a quelques semaines, notre équipe projet a eu la chance de recevoir la visite d'un coach </span><a style="font-family: arial;" href="http://fr.wikipedia.org/wiki/Lean">Lean</a><span style="font-family:arial;">, pionner de l'</span><a style="font-family: arial;" href="http://fr.wikipedia.org/wiki/Extreme_programming">eXtreme Programming</a><span style="font-family:arial;"> en France. Nous avons eu la chance de travailler ensemble une journée sur nos pratiques de développement.</span><br /><span style="font-family:arial;">J'ai attaqué la journée plein d'enthousiasme et je l'ai terminé avec le moral dans les chaussettes. J'avais honte des <span style="font-weight: bold;">problèmes </span>qu'il nous a fait <span style="font-weight: bold;">voir</span> ... Ceci dit, il était bénéfique de prendre conscience de nos obstacles et d'être remis sur la bonne voie. En tout cas, je n'oublierai pas le rappel à l'ordre suivant:</span><br /><span style="font-family:arial;">Le Lean, c'est </span> </div><ul style="text-align: justify;font-family:arial;"><li><span style="font-weight: bold;">visualiser la production</span> pour <span style="font-weight: bold;">révéler les problèmes</span>;</li><li><span style="font-weight: bold;">réagir immédiatement</span>;</li><li>puis <span style="font-weight: bold;">résoudre les problèmes</span> un à un;</li><li>pour <span style="font-weight: bold;">améliorer les pratiques</span>.</li></ul><div style="text-align: justify;"><span style="font-family:arial;">Ce billet est consacré au premier point: </span><br /><br /><span style="font-weight: bold;font-family:arial;" >VISUALISER LA PRODUCTION POUR RÉVÉLER LES PROBLÈMES</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">Prendre conscience d'un problème</span> est la première étape de sa résolution. <span style="font-weight: bold;">Voir un problème</span> est une manière efficace d'en prendre conscience. L'<span style="font-weight: bold;">afficher</span> pour que tous le voient est une manière de s'engager dans sa <span style="font-weight: bold;">résolution</span>. Reste à <span style="font-weight: bold;">organiser la production pour que les problèmes se voient</span>.</span><br /><br /><span style="font-family:arial;">C'est ici que les choses se compliquent pour le développement logiciel. En effet, il s'agit d'un métier dont la production ne se voit pas de manière évidente. C'est aussi ce qui rend le défi plus amusant en nous obligeant à devenir <span style="font-weight: bold;">créatifs</span>.</span><br /><br /><span style="font-family:arial;">Voici quelques exemples de pratiques déployées par notre équipe pour visualiser la production pour révéler les problèmes.</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">PROBLÈME: RETARDS</span></span><br /><br /><span style="font-family:arial;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TB4VZUTHXOI/AAAAAAAABnY/3n7mbtcH7EY/s1600/bur_burndown.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 400px; height: 276px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TB4VZUTHXOI/AAAAAAAABnY/3n7mbtcH7EY/s400/bur_burndown.jpg" alt="" id="BLOGGER_PHOTO_ID_5484844920873639138" border="0" /></a>L'équipe <span style="font-weight: bold;">affiche </span>ses <a href="http://fr.wikipedia.org/wiki/Scrum#Burndown_Charts">burndown chart</a>. Cela lui permet de <span style="font-weight: bold;">voir une mesure de sa production</span>. Si la courbe tracée est au dessus de la droite descendante à 45°, cela révèle un problème: <span style="font-weight: bold;">la production est en retard par rapport à la planification</span>.</span><br /><br /><br /><br /><br /><br /><br /><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;"><br /><br /><br /><br /></span></span><br /><span style="font-family:arial;"><span style="font-weight: bold;">PROBLÈME: </span></span><span style="font-family:arial;"><span style="font-weight: bold;">PRODUIT NON OPÉRATIONNEL</span></span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TB4YBzdhhfI/AAAAAAAABng/o_LB_N5iEIE/s1600/andon.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 192px; height: 235px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TB4YBzdhhfI/AAAAAAAABng/o_LB_N5iEIE/s400/andon.jpg" alt="" id="BLOGGER_PHOTO_ID_5484847815456818674" border="0" /></a> </span><span>L'équipe a connecté un iBuddy au poste d'<a href="http://fr.wikipedia.org/wiki/Int%C3%A9gration_continue">intégration continue</a></span><span style="font-weight: bold;">.</span> Dès que l'outil d'intégration continue détecte une modification dans le dépôt de code et lance un build, l'iBuddy agite les ailes et sa tête change plusieurs fois de couleur. Cette chorégraphie, répétée plusieurs fois par jour, permet de <span style="font-weight: bold;">visualiser le flux continu des contributions dans le dépôt de code</span>. Tant que le build est réussi, la tête de l'iBuddy reste verte. Sa tête devient rouge pour révéler un problème: <span style="font-weight: bold;">le build est en échec et donc le produit n'est plus opérationnel</span>!</span><br /><br /><br /><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;"><br /><br /><br /><br /><br /></span></span><br /><span style="font-family:arial;"><span style="font-weight: bold;">PROBLÈME: </span></span><span style="font-family:arial;"><span style="font-weight: bold;">STOCKS, GOULETS D'ÉTRANGEMENT ET REWORK</span></span><br /><br /><span style="font-family:arial;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_pwMHzqjHPX4/TB51HtR9SHI/AAAAAAAABnw/2GJFRW6ODyE/s1600/kanban_avec_bac_rouge.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 400px; height: 274px;" src="http://4.bp.blogspot.com/_pwMHzqjHPX4/TB51HtR9SHI/AAAAAAAABnw/2GJFRW6ODyE/s400/kanban_avec_bac_rouge.jpg" alt="" id="BLOGGER_PHOTO_ID_5484950171458291826" border="0" /></a>L'équipe pilote la production en utilisant des <a href="http://fr.wikipedia.org/wiki/Kanban">Kanbans</a>. Cela lui permet de <span style="font-weight: bold;">voir la production en cours</span>. Les kanbans révèlent plusieurs problèmes: la discontinuité du flux avec l'apparition de <span style="font-weight: bold;">stocks </span>et de <span style="font-weight: bold;">goulets d'étranglement </span>et le rework avec les <span style="font-weight: bold;">produits défectueux collectés dans le bac rouge</span>.</span><br /><br /><br /><br /><br /><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;"><br /><br /><br /><br /><br /></span></span><br /><span style="font-family:arial;"><span style="font-weight: bold;">PROBLÈME: </span></span><span style="font-family:arial;"><span style="font-weight: bold;">FLUX DISCONTINU</span></span><br /><br /><span style="font-family:arial;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_pwMHzqjHPX4/TB52K-RcdgI/AAAAAAAABoA/o0FBTAe1GzE/s1600/gizmo_on.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 400px; height: 394px;" src="http://4.bp.blogspot.com/_pwMHzqjHPX4/TB52K-RcdgI/AAAAAAAABoA/o0FBTAe1GzE/s400/gizmo_on.jpg" alt="" id="BLOGGER_PHOTO_ID_5484951327070778882" border="0" /></a>L'équipe utilise un <a href="http://emmanuelchenu.blogspot.com/2009/04/lintegration-continue-est-un-systeme.html">sémaphore d'intégration</a> pour mener l'intégration continue du produit. Chaque fois qu'un développeur se synchronise et délivre ses modifications dans le dépôt de code, il place un unique marqueur <span style="font-style: italic;">(une peluche, alias Guizmo) </span>sur son écran. Cela permet de <span style="font-weight: bold;">voir le flux continu de production qui enrichit le produit</span>. Cette pratique révèle également deux problèmes: un sémaphore qui ne circule pas dans l'équipe signale <span style="font-weight: bold;">un flux discontinu</span> et un sémaphore bloqué sur un poste révèle une <span style="font-weight: bold;">intégration douloureuse</span>.</span><br /><br /><br /><br /><br /><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;"><br /><br /><br /><br /><br /><br /><br /><br /></span></span><br /><span style="font-family:arial;"><span style="font-weight: bold;">PROBLÈME: </span></span><span style="font-family:arial;"><span style="font-weight: bold;">NON QUALITÉ</span></span><br /><br /><span style="font-family:arial;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_pwMHzqjHPX4/TB51ZJJ3ujI/AAAAAAAABn4/ZOFZqxWY5og/s1600/nonqualite.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 276px; height: 292px;" src="http://4.bp.blogspot.com/_pwMHzqjHPX4/TB51ZJJ3ujI/AAAAAAAABn4/ZOFZqxWY5og/s400/nonqualite.jpg" alt="" id="BLOGGER_PHOTO_ID_5484950470998342194" border="0" /></a>Quotidiennement, l'équipe affiche la quantité de non-qualité automatiquement détectée dans le produit. Cela permet de <span style="font-weight: bold;">visualiser l'évolution de la qualité de la production</span>. Cela permet aussi de révéler lorsque <span style="font-weight: bold;">le produit n'a plus la qualité attendue</span>.</span><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><span style="font-family:arial;"><br /><br /><br /><br /><br />Ces quelques exemples de pratiques permettant de <span style="font-weight: bold;">visualiser la production pour révéler les problèmes</span>. Elles sont adaptées à la nature particulière de notre projet et de notre équipe: logiciel critique et grosse équipe auto-organisée. L'étape d'après est de <span style="font-weight: bold;">réagir immédiatement</span> lorsqu'un problème est révélé. Cela sera l'objet d'un billet à venir. </span><br /><span style="font-family:arial;">A bientôt!</span><br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com4tag:blogger.com,1999:blog-5762312448351689453.post-27117569910744618112010-06-10T12:56:00.001-07:002010-06-10T12:57:31.825-07:00INTEGRATION BIG-BANG<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFDlhZbwSI/AAAAAAAABm0/5juDPpPhtbE/s1600/manu_integ_stock.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 215px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFDlhZbwSI/AAAAAAAABm0/5juDPpPhtbE/s400/manu_integ_stock.jpg" alt="" id="BLOGGER_PHOTO_ID_5481236533385871650" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com1tag:blogger.com,1999:blog-5762312448351689453.post-53012600688400078772010-06-10T12:55:00.001-07:002010-06-10T12:56:13.387-07:00CYCLE TROP LONG<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFDQxy-4kI/AAAAAAAABms/HK2BS5Djuz4/s1600/manu_cycle_trop_long.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 280px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFDQxy-4kI/AAAAAAAABms/HK2BS5Djuz4/s400/manu_cycle_trop_long.jpg" alt="" id="BLOGGER_PHOTO_ID_5481236177010745922" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com3tag:blogger.com,1999:blog-5762312448351689453.post-47156213274305583292010-06-10T12:53:00.000-07:002010-06-10T12:54:58.061-07:00FLUX CONTINU<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFC9SzoJAI/AAAAAAAABmk/q_ODoI9DxtI/s1600/manu_cycle_court.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 317px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFC9SzoJAI/AAAAAAAABmk/q_ODoI9DxtI/s400/manu_cycle_court.jpg" alt="" id="BLOGGER_PHOTO_ID_5481235842274436098" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-50259956721956681132010-06-10T12:51:00.000-07:002010-06-10T12:53:34.927-07:00SW COUPLÉ AU HW<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFCi0h2ErI/AAAAAAAABmc/qZ2i2OyZukg/s1600/manu_couplage_sw_hw.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 303px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFCi0h2ErI/AAAAAAAABmc/qZ2i2OyZukg/s400/manu_couplage_sw_hw.jpg" alt="" id="BLOGGER_PHOTO_ID_5481235387470189234" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-30357179458285570012010-06-10T12:49:00.000-07:002010-06-10T12:51:52.208-07:00LES TESTS SONT UN TUTEUR<div style="text-align: justify;"><a style="font-family: arial;" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_pwMHzqjHPX4/TBFCBu11qhI/AAAAAAAABmU/-p-HSQXVKmY/s1600/conf_tuteur.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 256px; height: 328px;" src="http://3.bp.blogspot.com/_pwMHzqjHPX4/TBFCBu11qhI/AAAAAAAABmU/-p-HSQXVKmY/s400/conf_tuteur.jpg" alt="" id="BLOGGER_PHOTO_ID_5481234819007752722" border="0" /></a><span style="font-family: arial;">... et l'application est un palmier parce que j'ai besoin de vacances.</span><br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-21597199377064918072010-06-10T12:48:00.001-07:002010-06-10T12:49:01.267-07:00PDCA<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFBl-3CzgI/AAAAAAAABmM/LU_izqYiptw/s1600/conf_pdca.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 398px; height: 400px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFBl-3CzgI/AAAAAAAABmM/LU_izqYiptw/s400/conf_pdca.jpg" alt="" id="BLOGGER_PHOTO_ID_5481234342271438338" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com1tag:blogger.com,1999:blog-5762312448351689453.post-12807505301328335682010-06-10T12:46:00.001-07:002010-06-10T12:47:51.140-07:00ITERATIF & INCREMENTAL<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_pwMHzqjHPX4/TBFBQwKzsVI/AAAAAAAABmE/xcw5S7wV7LE/s1600/conf_iter_incr.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 154px;" src="http://2.bp.blogspot.com/_pwMHzqjHPX4/TBFBQwKzsVI/AAAAAAAABmE/xcw5S7wV7LE/s400/conf_iter_incr.jpg" alt="" id="BLOGGER_PHOTO_ID_5481233977550549330" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-67032622617346640932010-06-10T12:45:00.001-07:002010-06-10T12:46:04.778-07:00BUGS<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_pwMHzqjHPX4/TBFA6XA2KLI/AAAAAAAABl8/7PLYcrcTsxM/s1600/conf_bugs.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 298px;" src="http://3.bp.blogspot.com/_pwMHzqjHPX4/TBFA6XA2KLI/AAAAAAAABl8/7PLYcrcTsxM/s400/conf_bugs.jpg" alt="" id="BLOGGER_PHOTO_ID_5481233592840759474" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com1tag:blogger.com,1999:blog-5762312448351689453.post-60503243248352012382010-06-10T12:44:00.001-07:002010-06-10T12:45:01.482-07:0050 DEVELOPPEURS<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFAr8iehtI/AAAAAAAABl0/x4hDLx5tztE/s1600/Conf_Equipe_50.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 155px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBFAr8iehtI/AAAAAAAABl0/x4hDLx5tztE/s400/Conf_Equipe_50.jpg" alt="" id="BLOGGER_PHOTO_ID_5481233345215891154" border="0" /></a><span style="font-family:arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family:arial;">.</span>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-70447115437580959122010-06-10T12:29:00.001-07:002010-06-10T12:30:50.949-07:0025 DEVELOPPEURS<div style="text-align: justify;"><a style="font-family: arial;" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBE9UTfMAVI/AAAAAAAABls/4f0RpkfpYwc/s1600/manu_equipe_sw.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 400px; height: 138px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/TBE9UTfMAVI/AAAAAAAABls/4f0RpkfpYwc/s400/manu_equipe_sw.jpg" alt="" id="BLOGGER_PHOTO_ID_5481229640524366162" border="0" /></a><span style="font-family: arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family: arial;">.</span><br /><br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-63395940094340294922010-06-10T12:08:00.001-07:002010-06-10T12:29:07.284-07:001 DEVELOPPEUR<div style="text-align: justify;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_pwMHzqjHPX4/TBE81KXTlkI/AAAAAAAABlk/ShhwgbdeE88/s1600/manu.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 166px; height: 331px;" src="http://3.bp.blogspot.com/_pwMHzqjHPX4/TBE81KXTlkI/AAAAAAAABlk/ShhwgbdeE88/s400/manu.jpg" alt="" id="BLOGGER_PHOTO_ID_5481229105499444802" border="0" /></a><span style="font-family: arial;">Voici une série d'illustrations que j'ai dessinées pour ma présentation au </span><a style="font-family: arial;" href="http://emmanuelchenu.blogspot.com/2010/06/5eme-seminaire-lean-si.html">5ème séminaire Lean & SI</a><span style="font-family: arial;">.</span><br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-6064497722393345302010-06-06T12:15:00.000-07:002010-06-06T12:23:07.387-07:005EME SEMINAIRE LEAN & SI<div style="text-align: justify; font-family: arial;">En collaboration avec Fujitsu et l’<a href="http://www.institut-lean-france.fr/">Institut Lean France</a>, <a href="http://www.telecom-paristech.fr/">Télécom ParisTech</a> organise la cinquième séance du séminaire « <a href="http://leansi.blog.telecom-paristech.fr/">Lean et Système d'information</a> ». Ce séminaire aura lieu le Jeudi 10 Juin 2010 de 9h00 à 12h30 <span style="font-style: italic;">(café accueil à partir de 8h30)</span> à <a href="http://www.telecom-paristech.fr/">Télécom ParisTech</a> <span style="font-style: italic;">(46 rue Barrault, Paris 13e)</span>.<br />Les interventions prévues pour ce jour sont:<br /></div><ul style="text-align: justify; font-family: arial;"><li>« Mise en oeuvre des démarches agiles et Lean pour la construction des systèmes critiques », Emmanuel Chenu, Thales</li><li>« Lean et IT: des logiciels au service du client », <a href="http://www.regismedina.com/">Régis Médina</a>, <a href="http://www.operae.fr/">Operae Partners</a></li><li>« Retour d'expérience sur une démarche de formation itérative selon les principes du TWI », Marie-Noelle Ninteya et Elodie Aidan, Nokia Siemens Network.</li></ul><div style="text-align: justify; font-family: arial;">Chaque exposé sera suivi d'un débat avec l’assistance.<br /><br />Pour plus de détails, consultez le <a href="http://leansi.blog.telecom-paristech.fr/files/2010/05/Cinqui%C3%A8me-s%C3%A9minaire-Lean-et-S1.pdf">programme</a>.<br /><br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com0tag:blogger.com,1999:blog-5762312448351689453.post-87418511173721817052010-04-21T01:43:00.000-07:002010-04-23T02:13:16.536-07:00RYTHME (IN)SOUTENABLE<div style="text-align: justify;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_pwMHzqjHPX4/S866rcT9ygI/AAAAAAAABig/Zym1TenbyI8/s1600/ManUVelocit%C3%A9Petit.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 225px; height: 257px;" src="http://3.bp.blogspot.com/_pwMHzqjHPX4/S866rcT9ygI/AAAAAAAABig/Zym1TenbyI8/s400/ManUVelocit%C3%A9Petit.jpg" alt="" id="BLOGGER_PHOTO_ID_5462508653544065538" border="0" /></a> Sur son <a href="http://www.davidbrocard.org/node/92">blog</a>, sur les mailing list <a href="http://fr.groups.yahoo.com/group/xp-france/message/8679">XP France</a> et <a href="http://fr.groups.yahoo.com/group/frenchsug/message/426">FrenchSUG</a>, <a href="http://www.davidbrocard.org/">David Brocard</a> a relancé la discussion sur la mise en pratique du <a href="http://fr.wikipedia.org/wiki/Manifeste_agile#Les_12_principes">principe agile</a> du <span style="font-weight: bold;">rythme soutenable</span>.<br /><br /><span style="font-weight: bold;">LE RYTHME SOUTENABLE</span><br /><blockquote style="font-style: italic;">"Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment." (<a href="http://agilemanifesto.org/principles.html">Agile Manifesto</a>)<br /></blockquote>Ce principe est très louable:<br /></div><ul style="text-align: justify;"><li>Il privilégie les <span style="font-weight: bold;">objectifs à long terme</span> sur les objectifs à court terme. </li><li>Il assure un<span style="font-weight: bold;"> <a href="http://emmanuelchenu.blogspot.com/2009/06/lean-le-flux-continu-de-valeur.html">flux continu et constant de création de valeur</a></span> qui maintient la qualité du produit, assure l'avancement et améliore la prédictibilité du développement.</li><li>Il instaure un rythme permettant de mettre en place la résolution systématique des problèmes et l'<a href="http://emmanuelchenu.blogspot.com/2009/09/lean-la-perfection.html"><span style="font-weight: bold;">amélioration continue</span></a>.</li><li>Il rappelle que le développement est réalisé par des hommes et qu'il faut <span style="font-weight: bold;">respecter </span>leur rythme de travail - dans leur intérêt, dans celui du projet et des clients.</li><li>Il permet d'<span style="font-weight: bold;">enchainer les projets</span>, les uns après les autres, car les développeurs restent disponibles <span style="font-style: italic;">(en bon état ...)</span>.</li></ul><div style="text-align: justify;"><span style="font-weight: bold;">LE PROBLÈME</span><br /></div><ul style="text-align: justify;"><li>En revenant sur plusieurs années de projet, est-ce que <span style="font-weight: bold;">le rythme soutenable a été appliqué</span>? </li><li>Est-il <span style="font-weight: bold;">compatible </span>de la mise en pratique des autres principes du Manifeste Agile? </li><li>A t-on au moins gagné un <span style="font-weight: bold;">rythme plus soutenable qu'auparavant</span>, lorsque nous utilisions des méthodes plus théoriques et <span style="font-style: italic;">(faussement)</span> prédictives? </li><li>Après 150 jours ouverts de développement sur un même projet, j'avais écrit que nous étions passé <span style="font-weight: bold;">de l'itération au sprint</span> sur notre projet en perdant le rythme soutenable <span style="font-style: italic;">(<a href="http://emmanuelchenu.blogspot.com/2008/12/iteration-ou-sprint_07.html">voir billet</a>)</span>. Qu'en est-il après 350 jours ouvrables de développement sur ce même projet?</li></ul><div style="text-align: justify;"><span style="font-weight: bold;">LE PLUS DUR EST A VENIR</span><br /><br />Avant l'adoption de démarches de type agile, le rythme sur les projets était soutenable <span style="font-weight: bold;">le long du V descendant</span>. Pour tenir un jalon intermédiaire <span style="font-style: italic;">(spécification, conception, codage)</span> il suffisait presque de décréter que l'activité était terminée. Concrètement, il était impossible de prouver objectivement le contraire puisque qu'aucune preuve n'était pertinente. Aussi, on savait sans trop oser le dire que le travail serait repris et terminé lors des phases remontantes du V.<br /><br />Puis, le rythme devenait bien plus désagréable lors de <span style="font-weight: bold;">la remontée du V.</span> L'intégration du code tournait au vrai cauchemar et les heures s'accumulaient pour mettre au point <span style="font-style: italic;">(et réécrire)</span> ce logiciel. Cette phase était le point culminant de la fatigue et du stress sur le projet. Le plus pénible était que la durée de cette phase était imprévisible ...<br /><br />Tout cela pour dire qu'avant l'introduction des méthodes de type agile, le rythme des projets était déjà insoutenable, mais essentiellement sur la branche remontante du V.<br /><br /><span style="font-weight: bold;">C'EST DUR TOUT LE TEMPS</span><br /><br />Avec la pratique du <span style="font-weight: bold;">cycle de vie itératif et incrémental court</span>, le stress et les heures de travail n'ont pas disparu. Ils ont été <span style="font-weight: bold;">lissé </span>assez uniformément le long du développement <span style="font-style: italic;">(il reste des pics lors des itérations qui précèdent une livraison formelle)</span>. Aussi, le stress et le surcroit de travail apparaissent très <span style="font-weight: bold;">tôt </span>dans le développement.<br /><br />Ce changement est dû à la nature même du cycle itératif et incrémental qui installe un rythme court pendant lequel toutes les activités du développement sont menées, levant les problèmes tôt et souvent.<br /><br />Avec les revues d'itérations et les démonstrations d'incrément, le stress de la livraison devient périodique. La mise à disposition très tôt et en continu de la vélocité <span style="font-style: italic;">(et d'autres indicateurs) </span>peut conduire à une course à la productivité, entretenue par les attentes toujours plus ambitieuses des managers.<br /><br />Ainsi, les méthodes agiles ne semblent pas générer un rythme plus soutenable ou plus insoutenable. Par contre, elles <span style="font-weight: bold;">lissent tôt et tout au long du projet</span> le stress qui culminait auparavant vers la fin <span style="font-style: italic;">(théorique)</span> du développement.<br /><br />Notez que la technique du <a href="http://fr.wikipedia.org/wiki/Heijunka">Heijunka</a> dans la <a href="http://fr.wikipedia.org/wiki/Lean">Lean</a> recherche spécifiquement ce lissage de la charge de travail et du stress.<br /><br /><span style="font-weight: bold;">SANS PIC NI RELÂCHE</span><br /><br />Certes, avec une approche de type agile, il n'y a plus de gros pic de travail et de stress. Par contre, il n'y a plus non plus de <span style="font-weight: bold;">relâche</span>. Avec les démarches plus théoriques, les pauses n'existaient pas formellement, mais il était possible de calmer le rythme lors de la descente du V. Par contre, avec un <span style="font-style: italic;">daily-stand-up-meeting</span>, avec le <span style="font-style: italic;">burndown chart</span> actualisé quotidiennement, avec un <span style="font-style: italic;">build </span>publié et avec des <span style="font-style: italic;">tests de recette</span> automatisés mesurant l'avancement, il devient très difficile de calmer le rythme sans que cela soit perceptible. Et cela s'enchaine itération après itération. Nous en sommes à 18 itérations de 20 jours ouvrés sur le même projet - et cela use!<br /><br />Pour calmer le jeu, nous avons essayé de prendre une journée sans incrément fonctionnel entre la revue d'itération et la planification de la suivante. D'une part, cela passait mal auprès du management, d'autre part cela ne rattrapait absolument pas un sprint de 20 jours ouvrés précédant un autre sprint de 20 jours.<br /><br /><span style="font-weight: bold;">LA COURSE A LA VÉLOCITÉ</span><br /><br />Pour maintenir un rythme soutenable, il faut de viser une vélocité moins élevée en planification d'itération. Cela semble évident. C'est sûrement applicable dans le meilleur des mondes, dans les entreprises éclairées, chez Google et chez les Bisounours. Malheureusement, cela n'est pas envisageable avec des managers qui pensent que les développeurs consomment le temps qu'il leur est alloué <span style="font-style: italic;">(<a href="http://fr.wikipedia.org/wiki/Loi_de_Parkinson">loi de Parkinson</a>)</span>. Ce modèle de management reste appliqué. Par extension, il s'agit de fixer des objectifs intenables pour être "sur" que les développeurs se donnent à fond. Changer ce schéma de pensée peut être une révolution culturelle pour certaines organisations.<br /><br /><span style="font-weight: bold;">STRESSANTE TRANSPARENCE</span><br /><br />Au rythme s'ajoute le <span style="font-weight: bold;">stress de la transparence</span>. Il faut du <span style="font-weight: bold;">courage </span>pour afficher sa courbe de productivité et sa <a href="http://emmanuelchenu.blogspot.com/2009/12/rendre-les-problemes-visibles.html">courbe de non-qualité</a>. Il faut du courage pour mettre une l<a href="http://emmanuelchenu.blogspot.com/2009/08/lean-andon.html">umière qui devient rouge lorsque le build est cassé</a>. Il faut du courage pour <a href="http://emmanuelchenu.blogspot.com/2009/12/rendre-les-problemes-visibles.html">montrer ses problèmes.</a> Donner des indicateurs, cela <span style="font-weight: bold;">peut </span>aussi être <span style="font-style: italic;">donner le bâton pour se faire battre</span>. Être transparent, c'est aussi accueillir la critique: <span style="font-style: italic;">"Quand on a perdu ses clefs la nuit, on les cherche sous le lampadaire"</span> <span style="font-style: italic;">(François Brun)</span>.<br /><br /><span style="font-weight: bold;">NOUVEAUX SYMPTÔMES</span><br /><br />Avec la pratique des démarches de type agile, nous constatons que les équipes deviennent plus soudées. Avec le stress, elles développent un <span style="font-weight: bold;">riche folklore d'équipe</span>. Par exemple, notre équipe passionnerait un sociologue tellement elle a développé des pratiques telles que <span style="font-style: italic;">"le Gizmo"</span>, <span style="font-style: italic;">"le Perfect"</span>, <span style="font-style: italic;">"le saut de la troisième corde"</span>, <span style="font-style: italic;">"le J'off"</span> et bien d'autres encore.<br /><br />Ce riche folklore d'équipe est bien moins séduisant si on l'interprète comme étant des <span style="font-weight: bold;">mécanismes collectifs de protection contre la souffrance au travail</span>. Malheureusement, c'est un fonctionnement très classique étudié par la <a href="http://www.hcsp.fr/docspdf/adsp/adsp-09/ad093939.pdf">psychodynamique du travail</a>. Avec les équipes soudées, nous sommes passé de mécanismes individuels de protection à des mécanismes collectifs.<br /><br />Le fait qu'une équipe soit soudée et développe un riche folklore peut être un signe d'une souffrance au travail ressentie par les équipiers. Cela peut être un symptôme du rythme insoutenable. Le pire est quand ces symptômes sont mal interprétés et qu'ils sont reprochés à l'équipe comme étant de mauvais comportements. Cela revient a réprimer le symptôme du malêtre.<br /><br /><span style="font-weight: bold;">QUEL QUE SOIT LA MÉTHODE</span><br /><br />Quel que soit la méthode, le travail en mode projet est éprouvant. Tant qu'il y aura des jalons, ils seront ambitieux <span style="font-style: italic;">(pour des raisons économiques)</span> et il sera éprouvant de les tenir. Ceci n'est pas propre au développement logiciel. Chez les créatifs, les publicitaires, les journalistes, les écrivains et les architectes cela s'appelle les <span style="font-weight: bold;">périodes de charrette</span> <span style="font-style: italic;">(<a href="http://fr.wikipedia.org/wiki/Charrette">période intense de travail pour terminer à temps une commande, une tâche sous contrat</a>)</span>.<br /><br /><span style="font-weight: bold;">NÉANMOINS</span><br /><br />Les démarches de type agile ont la particularité de <span style="font-weight: bold;">lisser </span>cette charge de travail dans la durée et de monter très <span style="font-weight: bold;">tôt </span>le rythme. Ce rythme est <span style="font-weight: bold;">sans pic ni relâche</span>. A cela s'ajoute le <span style="font-weight: bold;">stress de la transparence</span>. Clairement, il faut du <span style="font-weight: bold;">courage </span>pour pratiquer une démarche du type agile.<br /><br />La variable d'ajustement reste le curseur de la <span style="font-weight: bold;">vélocité</span>. Après, cela se joue à la culture d'entreprise et au style de management. Le rythme insoutenable n'est pas dans le patrimoine génétique des méthodes agiles mais dans l'utilisation que les commanditaires, les développeurs et les utilisateurs peuvent <span style="font-style: italic;">(très facilement) </span>en faire.<br />Ces démarches sont <span style="font-weight: bold;">diablement efficaces et motivantes </span><span>mais elles ne peuvent bien sur pas tout résoudre</span>.<br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com5tag:blogger.com,1999:blog-5762312448351689453.post-40722517858111585472010-04-17T12:32:00.000-07:002010-04-18T02:17:14.502-07:00LE SYNDROME DE LA DECHARGE PUBLIQUE<div style="text-align: justify; font-family: arial;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_pwMHzqjHPX4/S8q3oH3FreI/AAAAAAAABiY/Nh-1jqn7CIA/s1600/d%C3%A9chetterie.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 300px; height: 400px;" src="http://2.bp.blogspot.com/_pwMHzqjHPX4/S8q3oH3FreI/AAAAAAAABiY/Nh-1jqn7CIA/s400/d%C3%A9chetterie.jpg" alt="" id="BLOGGER_PHOTO_ID_5461379398072905186" border="0" /></a>En quelques 350 jours ouvrés de développement sur une même application, j'ai développé une <span style="font-weight: bold;">attitude </span><span style="font-weight: bold;"> extrémiste et dogmatique quant au maintien de la qualité</span> du logiciel. Je dois en irriter plus d'un dans l'équipe <span style="font-style: italic;">(désolé)</span>.<br /><br />Dans ce billet, je tente de justifier cette attitude. <span style="font-style: italic;">(Le développeur extrémiste a été dévoilé dans le billet </span><a style="font-style: italic;" href="http://emmanuelchenu.blogspot.com/2010/04/un-bon-code.html">UN BON CODE</a><span style="font-style: italic;">).</span><br /><br /><span style="font-weight: bold;">LA PETITE HISTOIRE</span><br /><br />Avez-vous déjà remarqué que lorsque la décharge publique est fermée, il y a parfois un particulier qui déverse ses détritus devant le portail d'entrée? (<span style="font-style: italic;"><a href="http://2.bp.blogspot.com/_pwMHzqjHPX4/S8q3oH3FreI/AAAAAAAABiY/Nh-1jqn7CIA/s1600/d%C3%A9chetterie.jpg">voir photo</a>)</span> Avez-vous aussi remarqué qu'une fois qu'un premier "vandale" a ouvert le bal, d'autres suivent son exemple.<br /><br /><span style="font-style: italic;">"Après tout, l'entrée est déjà souillée, alors c'est pas quelques détritus de plus qui vont changer quelque chose ...</span>"<br /><br />Parfois même, autres continuent cette dégradation alors même que la décharge a réouvert ses portes!<br /><br />Ce qui est notable dans ce comportement, c'est que <span style="font-weight: bold;">le premier à dégrader l'entrée de la décharge commet l'acte le plus "difficile"</span>. Il dégrade un lieu propre. Par contre, <span style="font-weight: bold;">il est bien plus aisé pour les suivants de suivre cet exemple en continuant à dégrader le lieu</span>.<br /><br />Il est aussi notable que si le personnel de la décharge avait immédiatement nettoyé les détritus du premier vandale, <span style="font-weight: bold;">les suivants n'auraient probablement pas osé vider leurs détritus devant la porte</span>.<br /><br /><span style="font-weight: bold;">REVENONS A NOS MOUTONS</span><br /><br />Ce syndrome se transpose au code d'une application logicielle. Si un premier développeur amorce la dégradation de la qualité du code, par exemple en ne testant pas sa modification, en laissant des warnings de compilation ou en ne respectant pas les standards de l'application, alors d'autres continueront à dégrader l'application.<br /><br /><span style="font-style: italic;">"Après tout, pourquoi tester ma modification alors que 20% des lignes d'instructions ne sont pas couvertes? Mon code non-testé se noiera dans la masse et passera inaperçu ...</span>"<br /><span style="font-style: italic;">"Après tout, pourquoi passer du temps à corriger mes 2 warnings de compilation alors que le build en détecte déjà 23?</span>"<br /><br />Sur plus de 350 jours ouvrés de développement d'un même logiciel, à 25 contributeurs, nous avons remarqué que si la qualité commence à se dégrader, alors le <span style="font-weight: bold;">phénomène s'emballe</span>. Il devient alors très <span style="font-weight: bold;">difficile et coûteux de l'endiguer et de le résorber</span>. Nous pouvons même autopsier ce phénomène en observant notre courbe d'historique de la non-qualité<span style="font-style: italic;"> (voir </span><a style="font-style: italic;" href="http://emmanuelchenu.blogspot.com/2009/12/rendre-les-problemes-visibles.html">précédant billet dédié à cette pratique</a><span style="font-style: italic;">)</span>. D'ailleurs, nous utilisons cette même courbe pour détecter l'amorce du phénomène et déclencher les actions correctives.<br /><br />Il y a une autre raison pour laquelle il faut maintenir l'application propre. Notre build complet publie la liste de la non-qualité détectée. Plus la liste est importante et plus il est difficile pour un développeur d'y retrouver les problèmes liés à son travail. Petit à petit, ce développeur va se lasser de rechercher les défauts qui le concernent directement au milieu de pages de défauts.<br />Par contre, si la liste des défauts détectés reste très faible, alors chaque développeur y retrouvera immédiatement et très visiblement sa non-qualité. Elle sera si visible que les autres équipiers pourront aussi la repérer. Alors, naturellement, chaque développeur évitera de se faire repérer comme contributeur à la non-qualité en corrigeant au plus tôt ses défauts.<br /><br /><span style="font-weight: bold;">MIEUX VAUT PRÉVENIR QUE GUÉRIR</span><br /><br />Ce phénomène me semble très naturel. S'il est n'est pas rigoureusement contenu, l'application va progressivement "pourrir". Il sera alors de plus en plus difficile de faire évoluer le logiciel. Pire, le tas des petits défauts sans conséquence va cacher les bugs dangereux.<br /><br />Pour palier à ce problème, je pense qu'il est primordial de développer une attitude extrémiste quant à la dégradation de l'application. Ceci est d'autant plus vrai si l'application est volumineuse, si le projet est long, si le nombre de contributeurs est important ou si l'application est critique <span style="font-style: italic;">(notre projet réuni tous ces critères à la fois)</span>. Il est judicieux de s'acharner à retirer tous les défauts au plus tôt pour laisser un code propre que personne ne souhaitera dégrader.<br /><br /><span style="font-weight: bold;">POUR ALLER PLUS LOIN</span><br /><br />Dans d'autres contextes, ce phénomène et l'attitude appropriée pour l'endiguer sont connus sous le nom <a href="http://en.wikipedia.org/wiki/Fixing_Broken_Windows">Fixing Broken Windows</a>. Ce même phénomène a été transposé au développement de logiciels par les Pragmatic Programmers dans leur article <a href="http://pragprog.com/the-pragmatic-programmer/extracts/software-entropy">Software Entropy</a>, dans l'entretien <a href="http://www.artima.com/intv/fixit.html">Don't Live With Broken Windows</a> et dans leur très bon livre <a href="http://emmanuelchenu.blogspot.com/2007/09/pragmatic-programmer-by-andrew-hunt-and.html">The Pragmatic Programmer</a>.<br />Bonnes lectures!<br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com5tag:blogger.com,1999:blog-5762312448351689453.post-85363840417183088192010-04-10T12:07:00.001-07:002010-04-19T06:42:48.221-07:00UN BON CODE ...<div style="text-align: justify;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/S8GXUxlOpeI/AAAAAAAABiQ/JvJAEfF8VUc/s1600/images.jpg"><img style="float: left; margin: 0pt 10px 10px 0pt; cursor: pointer; width: 150px; height: 88px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/S8GXUxlOpeI/AAAAAAAABiQ/JvJAEfF8VUc/s400/images.jpg" alt="" id="BLOGGER_PHOTO_ID_5458810606512416226" border="0" /></a><span style="font-weight: bold;font-family:arial;" > Dans l'ordre, un bon code</span><br /></div><span style="font-weight: bold;font-family:arial;" >1. passe ses tests avec succès;</span><br /><span style="font-weight: bold;font-family:arial;" >2. ne peut être mal utilisé;</span><br /><span style="font-weight: bold;font-family:arial;" >3. ne contient pas de redondance;</span><br /><span style="font-weight: bold;font-family:arial;" >4. exprime clairement l'intention;</span><br /><span style="font-weight: bold;font-family:arial;" > 5. est aussi court que possible.</span><br /><br /><span style="font-family:arial;"><span style="font-weight: bold;">Paraphrase ...</span><br />A peu de choses près, les points <span style="font-weight: bold;">1</span>, <span style="font-weight: bold;">3</span>, <span style="font-weight: bold;">4</span> et <span style="font-weight: bold;">5</span> sont une citation de </span><a style="font-family: arial;" href="http://fr.wikipedia.org/wiki/Kent_Beck">Kent Beck</a><span style="font-family:arial;">, créateur de l'</span><a style="font-family: arial;" href="http://fr.wikipedia.org/wiki/EXtreme_Programming">eXtreme-Programming</a><span style="font-family:arial;">.</span><span style="font-family:arial;"> Praticien de la </span><a style="font-family: arial;" href="http://fr.wikipedia.org/wiki/Programmation_par_contrat">programmation par contrat</a><span style="font-family:arial;">, j'y ai rajouté</span> le point <span style="font-weight: bold;">2</span>. <span style="font-style: italic;">(Qu'est-ce que je ne ferai pas pour citer les travaux de Kent Beck et </span><a style="font-style: italic;" href="http://fr.wikipedia.org/wiki/Bertrand_Meyer">Bertrand Meyer</a><span style="font-style: italic;"> dans le même billet :o)</span><br /><br /><span style="font-weight: bold;">... néanmoins utile</span><span style="font-family:arial;"><br />J'ai la chance de relire beaucoup de code, de binommer avec de nombreux développeurs et d'enseigner. Dans le cadre de ces activités, cette citation en cinq points m'est très utile. Je m'en sers beaucoup et je la cite souvent. Je dois sûrement passer pour un extrémiste dogmatique et têtu ... <span style="font-style: italic;">(Après tout dans un équipe, il est bon d'atteindre un certain ratio développeur extrémiste / développeur laxiste)</span></span><br /><span style="font-family:arial;">N'empêche qu'il y a beaucoup de sagesse empirique dans cette citation. Entre autre, <span style="font-weight: bold;">l'ordre des critères est très important</span>.</span><br /><br /><span style="font-weight: bold;">1. Tu testeras</span><br />Les tests occupent le haut du podium. Un code qui n'est pas testé n'a pas de valeur. C'est du code sans garantie. Toute ligne d'instruction doit être couverte par un test. Cela se vérifie très bien avec les outils d'analyse de la couverture structurelle.<br /><br /><span style="font-weight: bold;">2. Tu détromperas</span><br />Un code qui ne peut être mal utilisé est un code détrompé. Il contribue à la gestion préventive des défauts dans l'application. La programmation par contrat est une excellente pratique pour détromper le code. Quitte à parler de programmation par contrat, il serait plus exacte de dire: <span style="font-style: italic;">"Un bon code garantie sa postcondition si sa précondition est garantie par son appelant"</span>. Pour en savoir plus sur cette pratique rare mais vraiment efficace, vous pouvez <a href="http://emmanuelchenu.blogspot.com/search?q=programmez+par+contrat">lire un précédant billet sur ce sujet</a>.<br /><br /><span style="font-weight: bold;">3. Tu ne te répèteras pas</span><br />La duplication est source de défauts multiples et de reprises multiples. Elle nuit à la clarté des intentions. Admettons que j'<span style="font-style: italic;">"hérite"</span> d'un code non testé. Sans hésitation, je préfère consacrer du temps à le tester qu'à en éliminer les redondances. <span style="font-style: italic;">(En fait, j'éliminerai les redondances dès que les tests passeront :o)</span><br /><br /><span style="font-weight: bold;">4. Tu seras clair et explicite </span><br />Le code est bien plus souvent lu qu'écrit - y compris par son auteur! D'ailleurs, l'écrivain est avant tout son propre lecteur. Autant faciliter la vie de tous ces relecteurs. Comme pour le point précédant, je préfère tester que renommer et découper. <span style="font-style: italic;">(Pareil, je renommerai et découperai dès que les tests passeront :o)</span><br /><br /><span style="font-weight: bold;">5. Tu seras bref</span><br />La brièveté du code arrive en dernier car elle peut entrer en conflit avec les points <span style="font-weight: bold;">1</span>, <span style="font-weight: bold;">3</span> et <span style="font-weight: bold;">4</span>. Dans un tel cas de figure, la brièveté n'est pas prioritaire.<br />Pour rendre un code testable, il faut souvent créer des interfaces pour<a href="http://en.wikipedia.org/wiki/Dependency_injection"> injecter des dépendances à la construction des objets</a>. Cela augmente la taille du code. Le test amène également à découper en petites classes et il y a un talon déclaratif à payer pour cette modularité.<br />Un code sans duplication peut amener à créer une opération pour 2 lignes dupliquées. Au total, en comptant le surcroit de déclaration, cette pratique peut augmenter le nombre de lignes. D'ailleurs, avez vous remarqué que les exemples de code remanié sont TOUJOURS plus longs que leur code d'origine? <span style="font-style: italic;">(voir </span><a style="font-style: italic;" href="http://emmanuelchenu.blogspot.com/2009/04/clean-code-robert-c-martin.html">Clean Code</a><span style="font-style: italic;">)</span><br />Pour rendre un code plus explicite, nous sommes amené à homogénéiser le niveau d'abstraction dans le code des opérations. Pour cela, nous encapsulons le code de niveau d'abstraction inférieur dans une opération. Là encore, nous payons une taxe pour la déclaration des opérations.<br /><br /><span style="font-weight: bold;">Et le code des tests?</span><br />Ce codex en 5 règles s'applique au code, mais <span style="font-weight: bold;">aussi aux tests</span>, car <a href="http://emmanuelchenu.blogspot.com/2009/01/les-tests-sont-du-code.html">les tests sont du code</a>. On peut penser qu'il ne faut pas tester les tests sinon on n'en finit jamais. Pourtant, la pratique du <a href="http://fr.wikipedia.org/wiki/Test_Driven_Development">Test Driven Developpment</a> issue de l'eXtreme-Programming intègre par construction <span style="font-weight: bold;">le test du test</span>!<br />En effet, lorsque nous <span style="font-weight: bold;">commençons par écrire un test qui échoue</span>, puis <span style="font-weight: bold;">nous </span><span style="font-weight: bold;">modifions le code jusqu'à ce que le test passe avec succès,</span> nous vérifions la justesse du test. Ce tte démarche en 2 étapes est le test du test.<br /><br /><span style="font-weight: bold;">Un de plus</span><span style="font-style: italic;"> (violation du critère 3!)</span><br />Désolé, ceci était le 1379ème billet visant à définir un bon code. Plusieurs livres y consacrent leurs pages. C'est un peu comme les chaînes de chance/malchance. Lorsqu'on lit un de ces billets, on se doit d'en écrire un à son tour ...Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com5tag:blogger.com,1999:blog-5762312448351689453.post-17509087128736979472009-12-22T12:53:00.001-08:002010-01-04T13:51:45.048-08:00RESOUDRE LES PROBLEMES<div style="text-align: justify;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_pwMHzqjHPX4/SzEx6Rav51I/AAAAAAAABf4/VrkeBvXqTOg/s1600-h/blog_problems_indic.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 400px; height: 297px;" src="http://4.bp.blogspot.com/_pwMHzqjHPX4/SzEx6Rav51I/AAAAAAAABf4/VrkeBvXqTOg/s400/blog_problems_indic.jpg" alt="" id="BLOGGER_PHOTO_ID_5418166703881185106" border="0" /></a>C'est bien bien sympa de <span style="font-weight: bold;">voir les problèmes</span>. Ceci dit, l'objectif reste de les <span style="font-weight: bold;">résoudre</span>!<br /><br />Alors, ces problèmes identifiés et exposés à la vue de tous, <span style="font-weight: bold;">sont-ils traités</span>?<br /><br /><span style="font-weight: bold;">1. PETIT RAPPEL</span><br /><br /><span class="blsp-spelling-error" id="SPELLING_ERROR_0">Rappelez-vous</span>: l'équipe prend conscience que pour apprendre, progresser et gagner en efficacité, elle doit <span style="font-weight: bold;">résoudre systématiquement les problèmes qu'elle rencontre</span>.<br />Alors,<br /></div><ul style="text-align: justify;"><li>on développe la <span style="font-weight: bold;">détection </span> systématique des problèmes;</li><li>on affiche les problèmes pour les <span style="font-weight: bold;">rendre visibles</span>;</li><li>on <span style="font-weight: bold;">résout les problèmes de manière structurée</span>.</li></ul><div style="text-align: justify;">Cette attitude et cette démarche sont décrit dans un <a href="http://emmanuelchenu.blogspot.com/2009/09/lean-la-perfection.html">précédant billet</a>.<br /><br /><span style="font-weight: bold;">2. EST-CE PRATIQU</span><span style="font-weight: bold;">É</span><span style="font-weight: bold;">?</span><br /><br />Afin de s'assurer que ces beaux <span style="font-weight: bold;">principes </span>sont devenus des <span style="font-weight: bold;">pratiques</span>, nous <span style="font-weight: bold;">affichons </span>un indicateur révélant le nombre de problèmes résolus<span style="font-style: italic;"> (le bas des barres)</span> et le nombre de problèmes <span class="blsp-spelling-error" id="SPELLING_ERROR_1">non-résolus</span> <span style="font-style: italic;">(le haut des barres)</span>. Cet indicateur est actualisé à chaque itération <span style="font-style: italic;">(voir photo ci-dessus)</span>.<br /><br /><span style="font-weight: bold;">3. EST-CE EFFICACE?</span><br /><br />C'est bien joli de mettre en place de nouvelles pratiques - encore <span class="blsp-spelling-error" id="SPELLING_ERROR_2">faut-il</span> qu'il y ait un retour sur investissement ... Et là, il faut <span class="blsp-spelling-corrected" id="SPELLING_ERROR_3">reconnaître</span> qu'il est difficile de mesurer l'impact de la résolution systématique des problèmes.<br /><br />Difficile n'est pas impossible: les <span class="blsp-spelling-error" id="SPELLING_ERROR_4">burndown-chart</span> et la <a href="http://emmanuelchenu.blogspot.com/2009/12/rendre-les-problemes-visibles.html">courbe de <span class="blsp-spelling-error" id="SPELLING_ERROR_5">non-qualité</span></a> révèlent les gains en productivité et en qualité de cette démarche.<br />Notamment, la <a href="http://emmanuelchenu.blogspot.com/2009/12/rendre-les-problemes-visibles.html">courbe de <span class="blsp-spelling-error" id="SPELLING_ERROR_6">non-qualité</span></a> révèle de sévères réductions de la <span class="blsp-spelling-error" id="SPELLING_ERROR_7">non-qualité</span> correspondant à des chantiers mis en place suite à un problème levé. Ensuite, les paliers qui suivent une chute de cette courbe montrent que l'action corrective "coup de poing" s'est efficacement transformée en pratique continue.<br />Puisque le <span class="blsp-spelling-error" id="SPELLING_ERROR_8">burndown-chart</span> ne souffre pas d'une augmentation ou d'une stagnation du "restant à faire", c'est que la résolution du problème a contribué positivement au développement.<br /><br /><span style="font-weight: bold;">4. EFFET SECONDAIRE</span><br /><br />Nous avons remarqué un autre effet secondaire bénéfique de cette démarche. Il s'agit d'une très forte augmentation de la <span style="font-weight: bold;">standardisation</span>.<br />En effet, la résolution d'un problème résulte généralement en:<br /></div><ul style="text-align: justify;"><li>une <span style="font-weight: bold;"><span class="blsp-spelling-corrected" id="SPELLING_ERROR_10">contre mesure</span> automatisée</span> <span style="font-style: italic;">(<span class="blsp-spelling-error" id="SPELLING_ERROR_11">scriptée</span> dans le <span class="blsp-spelling-error" id="SPELLING_ERROR_12">build</span>, dans le commit, ...)</span>;</li><li>une<span style="font-weight: bold;"> <span class="blsp-spelling-corrected" id="SPELLING_ERROR_13">contre mesure</span> manuelle</span> décrite par une petite <span style="font-weight: bold;">procédure textuelle</span>;</li><li>l'amélioration d'une procédure existante.</li></ul><div style="text-align: justify;">Ainsi, nous avons constaté que notre wiki s'est enrichi de beaucoup de<span style="font-weight: bold;"> petites procédures pragmatiques</span>. Il s'agit de l'officialisation des meilleures manières de faire à ce moment pour ce projet. Cela constitue un standard léger et évolutif, partagé par les équipiers.<br /><br />Je pensais que la standardisation étaient une démarche formelle, lourde et ralentissant l'évolution. Je suis désormais convaincu du contraire.</div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com2tag:blogger.com,1999:blog-5762312448351689453.post-32439613248400819972009-12-19T05:44:00.000-08:002009-12-19T11:31:35.337-08:00VOIR LES PROBLEMES<div style="text-align: justify;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_pwMHzqjHPX4/SyzY62z-AAI/AAAAAAAABfw/MdOCBuSDezY/s1600-h/blog_non_quality.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 400px; height: 295px;" src="http://4.bp.blogspot.com/_pwMHzqjHPX4/SyzY62z-AAI/AAAAAAAABfw/MdOCBuSDezY/s400/blog_non_quality.jpg" alt="" id="BLOGGER_PHOTO_ID_5416942957477363714" border="0" /></a><span style="font-style: italic;">"Loin des yeux, loin du cœur". </span><span style="font-weight: bold;">Un problème qui n'est pas visible n'est pas traité</span>.<br /><br />Sur les conseils de <a href="http://www.regismedina.com/">Régis Médina</a> et après avoir assisté à sa conférence présentée à l'<a href="http://emmanuelchenu.blogspot.com/2009/11/agile-tour-2009-valence-cest-fini.html">Agile Tour à Valence</a>, nous cherchons depuis quelques itérations à <span style="font-weight: bold;">rendre nos problèmes visibles</span> pour ne pas les laisser trainer. Pour cela, nous avons mis en place <span style="font-weight: bold;">2 pratiques</span>.<br /><br /><span style="font-weight: bold;">1. VOIR LES DÉFAUTS DU PROCESSUS</span><br /><br />La première, déjà évoquée à l'occasion d'un <a href="http://emmanuelchenu.blogspot.com/2009/09/lean-la-perfection.html">billet sur la résolution systématique des problèmes</a> consiste à <span style="font-weight: bold;">afficher sur un tableau dédié les problèmes</span> rencontrés par l'équipe (<a href="http://2.bp.blogspot.com/_pwMHzqjHPX4/SqPSWpXeg-I/AAAAAAAABaI/pic710fTjyE/s1600-h/problemSolving.jpg">voir photo</a>).<br /><br /><span style="font-weight: bold;">2. VOIR LES DÉFAUTS DU PRODUIT</span><br /><br />La deuxième consiste à <span style="font-weight: bold;">identifier, mesurer et afficher quotidiennement et automatiquement la non-qualité</span> du produit. Il s'agit de la somme de tout ce qui est à corriger pour atteindre le niveau de qualité que nous recherchons pour notre produit<span style="font-style: italic;"> (et nous sommes TRÈS exigeants)</span>.<br />Ainsi, nous sommons<br /><ul><li>le nombre de <span style="font-weight: bold;">warnings de compilation du code et des tests</span>,<br /></li><li>le <span>n</span><span>ombre d'</span><span style="font-weight: bold;">opérations qui dépassent un seuil de complexité</span>,<br /></li><li>le <span>nombre de </span><span style="font-weight: bold;">classes non couvertes à 100% par des tests automatisés</span>,<br /></li><li>le <span>nombre de </span><span style="font-weight: bold;">classes qui ne respectent pas les standards de codage</span> ...</li></ul>L'historique de cette métrique enrichie une courbe qui est affichée quotidiennement à l'endroit le l'open space où il y a le plus de passage, juste à côté des burndown charts.<br /><br />Depuis que nous avons décidé de rendre visibles ces problèmes, nous nous sommes mis de <span style="font-weight: bold;">manière disciplinée et continue à réduire cette non-qualité</span>, comme le révèle la courbe affichée.<br /><br />Dès que la courbe se stabilise à un niveau acceptable de non-qualité <span style="font-style: italic;">(correspondant à un minimum de travail en cours)</span> nous enrichissons cet indicateur d'une nouvelle classe de défauts. Vous verrez un tel saut commenté à la main sur la courbe affichée. Ainsi, nous relevons notre niveau d'exigence de manière maitrisée.<br /><br />Nous ne nous intéressons pas à la valeur de la métrique mais plutôt à la <span style="font-weight: bold;">pente de la courbe</span>. En effet, elle révèle très clairement si l'équipe s'améliore ou se relâche.<br /><br />Il est très intéressant d'afficher cette <span style="font-weight: bold;">courbe de non-qualité</span> à côté des <span style="font-weight: bold;">burndown charts.</span> En effet, on constate souvent que l<span style="font-weight: bold;">'amélioration de la productivité</span> <span style="font-style: italic;">(visible sur un burndown chart)</span> <span style="font-weight: bold;">se fait au détriment de la qualité</span> <span style="font-style: italic;">(visible sur la courbe de non-qualité).</span> L'<span style="font-weight: bold;">affichage quotidien et côte à côte de ces 2 courbes</span> permet de visualiser que nous ne jouons pas aux vases communicants. Mieux, nous arrivons même à corréler que <span style="font-weight: bold;">travailler mieux permet de travailler plus vite</span>!<br /><br />Enfin, nous avons aussi <span style="font-weight: bold;">valorisé </span>cette mesure de la non-qualité du produit. A chaque catégorie de défaut identifié nous avons associé une valeur: il s'agit du temps théorique requis pour corriger un défaut de cette catégorie. Ainsi, nous mesurons le temps estimé nécessaire pour obtenir un produit de la qualité recherchée.<br /><br />Avec la <span style="font-weight: bold;">mesure quotidienne et combinée</span> du <span style="font-weight: bold;">restant à faire</span> et de la <span style="font-weight: bold;">non-qualité du produit</span>, nous avons des <span style="font-weight: bold;">outils objectifs, pertinents et complémentaires</span> pour piloter notre développement.<br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com5tag:blogger.com,1999:blog-5762312448351689453.post-52921325770026472032009-11-14T06:00:00.000-08:002009-11-16T05:31:15.849-08:00RECRUTE EQUIPIER<div style="text-align: justify;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_pwMHzqjHPX4/Sv65bD40dqI/AAAAAAAABes/TevLcg7RW34/s1600-h/equipier.jpg"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 290px; height: 267px;" src="http://1.bp.blogspot.com/_pwMHzqjHPX4/Sv65bD40dqI/AAAAAAAABes/TevLcg7RW34/s400/equipier.jpg" alt="" id="BLOGGER_PHOTO_ID_5403960477442406050" border="0"></a>Nous<span style="font-weight: bold;"> cherchons un équipier</span> pour un <span style="font-weight: bold;">CDD d'un an</span>. Si vous êtes mobile pour venir sur <span style="font-weight: bold;">Valence </span>et que vous souhaitez intégrer un <span style="font-weight: bold;">grand projet</span> industriel, cette opportunité pourrait vous intéresser.<br /><br />Sincèrement, je pense que notre projet est une <span style="font-weight: bold;">bonne école du génie logiciel</span>. Nous exigeons un niveau de <span style="font-weight: bold;">qualité maximal</span>, convaincus que <span style="font-weight: bold;">bien développer le bon produit permet de développer plus vite</span>. Nous pratiquons l'<span style="font-weight: bold;">eXtreme-Programming</span>, <span style="font-weight: bold;">Scrum</span>, le <span style="font-weight: bold;">Lean</span>, la démarche <span style="font-weight: bold;">orientée objet</span> et la <span style="font-weight: bold;">programmation par contrat</span>.<br /><br />Si vous êtes tentés par cette <span style="font-weight: bold;">aventure enrichissante techniquement et humainement</span>, l'<a href="http://www.jd.apec.fr/offres-emploi-cadres/0_5_4_17747519_______1_offre-d-emploi-developpeur-logiciel-embarque-temps-reel-critique-h-f.html">offre est accessible via l'APEC ici</a>. Si vous voulez en savoir plus sur notre équipe, <a href="http://www.agilex.fr/2009/07/lean-engineering-chez-thales/">on en parle sur d'autres blogs, tels celui d'Alexandre Boutin</a>.<br /><br />A bientôt?<br /></div>Emmanuel CHENUhttp://www.blogger.com/profile/00989041538576544218noreply@blogger.com2