Ural penguins - Сообщения с тегом Scrumhttp://uralbash.ru/blog/tag/scrum/atom.xml2014-06-06T22:44:00ZABlogScrum и XP: заметки с передовойhttp://uralbash.ru/articles/2014/scrum/2014-06-06T22:44:00Z2014-06-06T22:44:00ZUralbash<div class="section" id="scrum-xp">
<img alt="_static/2014/scrum.png" class="align-left" src="_static/2014/scrum.png" />
<p>Старая, но очень полезная книга по <code class="docutils literal"><span class="pre">Agile</span></code>. Довольно редкий случай когда вся
книга описывает рабочие процессы реальной организации, никакой воды, никакой
зауми и вялой теории. Очень рекомендую. Тем более книга в свободном доступе и
переведена на русский язык (лучи добра и счастья переводчикам).</p>
<p><a class="reference external" href="http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf">http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf</a></p>
<p>Дальше несколько интересных цитат из книги:</p>
<p>По правде говоря, у системы с высоким внутренним качеством иногда может быть
довольно низкое внешнее. Но наоборот бывает крайне редко. Сложно построить
что-то хорошее на прогнившем фундаменте.</p>
<p>По моему личному опыту, жертвовать внутренним качеством – это практически
всегда очень и очень плохая идея. Сэкономленное время ничтожно мало по
сравнению с той ценой, которую вам придётся заплатить как в ближайшем будущем,
так и в перспективе. Как только
качество вашего кода ухудшится, восстановить его будет очень тяжело.</p>
<p>Учитесь оставаться в рамках установленного времени, учитесь давать реалистичные
оценки. Это касается как продолжительности встреч, так и продолжительности
спринта.</p>
<p>А различие очень простое: истории это нечто, что можно продемонстрировать, что
представляет ценность для product owner’а, а задачи либо нельзя
продемонстрировать, либо они не представляют ценности для product owner’a.</p>
<p>Пример разбиения истории на более мелкие:</p>
<img alt="_static/2014/scrum2.png" src="_static/2014/scrum2.png" />
<p>Пример разбиения истории на задачи:</p>
<img alt="_static/2014/scrum3.png" src="_static/2014/scrum3.png" />
<p>Мы попробовали различные варианты работы с техническими историями. Мы пробовали
считать их самыми обычными user story. Это была неудачная идея: для product
owner’а приоритезировать их в product backlog’е было всё равно, что сравнить
тёплое с мягким. По очевидным причинам технические истории получали самый
низкий приоритет с объяснением: “Да, ребята, несомненно, ваш сервер непрерывной
интеграции – очень важная штука, но давайте сперва реализуем кое-какие
прибыльные функции? После этого вы можете прикрутить вашу техническую конфетку,
окей?”</p>
<img alt="_static/2014/scrum4.png" src="_static/2014/scrum4.png" />
<p>если вы пользуетесь стикерами для задач, не забудьте прикрепить их скотчем, или
же в один “прекрасный” день вы найдете их аккуратной кучкой на полу.</p>
<img alt="_static/2014/scrum5.png" src="_static/2014/scrum5.png" />
<p>Как быть с опоздавшими?</p>
<p>Некоторые команды заводят специальную копилку. Если вы опоздали, даже на
минуту, вы кидаете в копилку определённую сумму. Без вариантов. Даже если вы
позвонили перед началом ежедневного Scrum’а и предупредили, заплатить всё равно
придётся :o)</p>
<p>Деньги из копилки используются на общественные нужды. Например, на них можно заказать пиццу</p>
<img alt="_static/2014/scrum6.png" src="_static/2014/scrum6.png" />
<p>Если вы действительно хотите разобраться, как планировать релиз, советую
пропустить эту главу и купить книгу Майка Кона “Agile Estimating and Planning”.
Эх, прочитать бы мне эту книгу раньше... (она попалась мне уже после того, как
мы на собственном опыте поняли, что к чему...). Мой способ планирования
простой, как угол дома, но может послужить вам хорошей отправной точкой.</p>
<a class="reference external image-reference" href="http://www.books.ru/books/scrum-gibkaya-razrabotka-po-signature-series-3643772/?show=1&bkrand=1ncaafgaia8ck1qvpo5u9nklk0/?partner=490327"><img alt="_static/2014/scrum_book.jpg" class="align-left" src="_static/2014/scrum_book.jpg" /></a>
<p>Вот эта книга, кстати тоже переведена на русский</p>
<br clear="both"/><p>Scrum решает вопросы управления и организации, тогда как XP специализируется на
инженерных практиках. Вот почему эти две технологии хорошо работают вместе,
дополняя друг друга.</p>
<p>Работка через тестирование (TDD)</p>
<p>Наконец-то! Разработка через тестирование для меня важнее, чем Scrum и XP
вместе взятые. Можете отнять у меня дом, телевизор, собаку, но только
попробуйте запретить использование TDD! Если вам не нравится TDD, тогда просто
не подпускайте меня близко, иначе я всё равно привнесу его в проект втихую :)</p>
<p>Мы столкнулись с ситуацией, когда было невозможно внедрить Scrum в большом
проекте из-за того, что его команда постоянно тушила пожары, т.е. в панике
устраняла дефекты преждевременно выпущенной системы. Это был порочный круг:
из-за того, что всё время уходило на постоянную борьбу с пожарами, не было
времени на их предотвращение (т.е. на улучшение архитектуры, внедрение
автоматического тестирования, создание систем мониторинга и оповещения, и т.п.)</p>
</div>