Зачем Story Points?

В дополнение к http://denismiller.blogspot.com/2008/12/story-points-vs-ideal-hours.html появилось несколько вопросов. Редакция отвечает :)

Мой посыл такой. Требования имеют разный размер. От большого до маленького. В зависимости от игры декомпозиции. Моё предложение и единицы измерений выбрать для разных уровней декомпозии свои. То есть

User Story - условная единица своя - Story Point
Tast - условная удиница своя - Task у.е. в простонародии часы идеальные :)

vsavkin: Запутанно и непонятно.
Значит, длину удава мы сначала оцениваем приблизительно в попугаях, а затем поточнее в метрах. Но следить за скоростью роста удава легче в попугаях, согласно вышенаписанному.
Где логика?
Зачем нам в двух единицах измерения оценивать? И зачем выбирать в качестве основной единицы попугая, размер которого не является константой, вместо метра, который стандартизирован, и можно точно измерить рулеткой?

Ответ простой:
1) удав (требование/юзер стори) меряется в условных удавках (функциональных точках/стори поинты),
2) попугай (таски) в попугайных условных единицых (условных единицах размера тасок - часы).

Каждому уровню своя единица измерения. Единицы легко конвертируются, но во время оценивания дают разную точку зрения на одно и тоже. Что полезней, чтобы оценить ту или инную ментальную модель.

Как расстояния. Между городами в киллометрах. А между точками на листе в сантиметрах. Просто нам уже вдолбили в голову что соотношение между ними 1 к 100000. Так и размеры sotry point очень хорошо соотносятся с часами. Только нужно набрать статистику :)

А когда статистика приобретает глобальный масштаб - её называют стандартом :)

1. Почему в пирамиде фичи продукта выше User Story?
Должно быть наоборот - на основе User Story вырабатываются конкретные фичи. Собственно User Story нужны именно для того чтобы от общего представления о продукте с помощью конкретных описаний применений перейти к фичам продукта.

2. По ссылке "Об agile по-русски: User Stories" описаны фактически Use Cases, а не User Stories.

User Stories = история пользователя. Я как пользователь хочу пользовать ту или инную штучку. User Story маркер-напоминалка, которую можно расписать до Use Case.

Фича это сумма вариантов использования чего-то. Поэтому и выше поставлено.

Можно фичу называть User Story но очень крупную :) Которая требует декомпозиции. Кстати, User Story так же бьются на юзер-стори или таски. Критерий классно подсказан Сергеем Назаренко в одной из стади-групп по Agile: пока юзер-стори имеет бизнес-значимость - это юзер стори, как потеряла в результате декомпозиции - стала таской :)

Задавай ещё вопросов, попробуем найти истину :)

Обязанность Agile-коучера: фасилитация

Аджайл коуч (в скрам он называет скарм-мастер) должен способствовать развитию команды, решать проблемы, следать за правильностью исполнения практик и улучшать их. Поэтому этот человек постоянно интересуется, что твориться на фронте хороших практик программирования и управления.

Было бы здорово получить список тех практик, которые должен выучить коучер, а потом предложить команде. Вот давеча нашёл сайт, на котором собраны практики фасилитации :)

Facilitation comes from the latin facile, which mean easy. In fact, the role of a facilitator in a group setting is to “make things easy”. It involves planning, organizing, and setting or supporting rules and goals within such groups. It is my goal here to collect and share many of the tricks, techniques and practices that facilitators use in their work.

Более подробнее читайте на сайте: http://facilitationpatterns.org

А inquisitor_rus подсказал суперскую статью - http://ru.wikipedia.org/wiki/Consensus_decision-making

Правильные разработчики

Интересный термин предложен Сашей Орловым - "правильные" люди. Я конечно у него спросил, что это значить. А пока он не ответил попытаюсь порассуждать.

Во-первых, кто даёт такое определение человеку. Сам себе человек? Или кто-то другой? Если сам человек, то тут не поспоришь, кто ж лучше знает его самого. Конечно можно забабахать тест психологический на правильность или посчитать количество багов в месяц которые генерит этот человек. И тогда убедить его в правильности или неправильности. Но тогда это будет уже кто-то другой. Но кто нам дал право судить людей, как говориться не судите и не судимы будете.

Во-вторых, а как же набрать народа в свою команду? Честно говоря лучшие компании мира дают свои рекомендации. см. процесс рекрутинга в Microsoft. Они ищут людей, которые проявляют определенный набор качеств и точка. "Правильный" он, или "неправильный", да какая разница. Главное, чтобы он хорошо интегрировался в контекст! А контекст как раз задаёт компания. То есть "правильность" определяется лишь контекстом её оценки. Если компания успешна в ней есть механизмы находить людей, которые так же могут думать так же как ребята из компании. И это их локальная "правильность".

В-третьих. Чаще оценку делают менеджеры своим разработчикам - а насколько человек "правильный". Эта правильность конвертируется в бонусы, карьеру и т.п. Читайте книгу на тему "карьеризма" и можете приравнять правильность к этому слову. Кстати вопрос - а менеджеры считают себя правильными?

В-четвертых. Не понятно какая цель приследуется разделив всех людей на правильные и неправильные. Разделить команду на хороших и плохих. Вместо того чтобы людей объединять менеджер вводит искусственное поле напряженности. Даже если он это не высказывает но принебрежительный взгляд на одного разработчика и часовые беседы с другим сделают своё дело. Сформируется потенциальное поле "правильности". Народ будет осозанно и неосозанно либо одобрять (те кто "правильные") и не одобрять (тех кого обделила барская рука). Это создаст основу для будущих конфликтов как явных, но и опасных - неявных. А ещё хуже - эта куча народу лобает ОДИН продукт. Как ребята, которые действуют несогласовано, желания, цели и чувтсва которых задеты могут сделать ЦЕЛЬНЫМ продукт. Вывод: продукт можете сразу выкидывать - качества там не будет, пока в вашей голове живёт желание оценивать и разделять.

И это только аргументы на горячую голову. Если подумать - то вообще лучше не думать :)

Что же делать? Повышать осведомлённость, присутствие, вовлеченность, стремление к целям, взаимозависимость, эмпатия и взаимопомощь. Даже слабое звено делает команду командой, а не кучкой нанятых людей. Становится вопрос, а слабое ли оно? Про силу слабых звеньев можете посмотреть в тренингах по "командообразованию" :)

Александр Орлов: Я пояснил, что говорил про правильных программистов и пояснил, что я имел в виду. Оценивать правильность программистов мне довольно легко, потому что я имел многолетнюю возможность ими руководить и наблюдать их со стороны.

И как я понимаю сделав вывод ты уже им руководствуешься. Полностью исключив возможность человеку достичь большего. Только вот так просто исходя из твоего субъективного “правильного”. Кашмар, чесслово! :)

Александр Орлов: Возможности наблюдать себя со стороны - я не имею.

Объясню. Исходя из некоторой совокупности критериев ты делаешь оценку людей. Почему ты эту совокупность критериев не можешь наложить на себя?

В общем я понял, что истина где-то рядом и написал:

Денис: Жаль. Только началось то, что настоящим командам не хватает… Открытые чувства и эмоциональный интеллект…
Любой вопрос можешь задавать мне - я отвечу.

На что получил странный ответ:

Александр Орлов: Денис, за выдающиеся коммуникативные навыки вынужден тебя забанить. Комментарий, который вывел меня на чистую воду и показал недостаток эмоционального интеллекта, тоже убрал, извини, пожалуйста.

Я так и не понял, как и кого я вывел на чистую воду, и у кого недостаёт эмоционального интеллекта :)

Очень странно, ведь я использовал всего лишь модель “проверка референтного индекса” относительно модели “правильные люди”. Я попытался представить себя оценивающим людей “правильные они или нет” - не получилось. Попробовал себя оценить - правильный ли я. Тоже не вышло. Ну и я спросил тебя - правильный ли ты. На что не получил ответа. Верификация сработала плохо. Поэтому я усомнился в правильности “правильной” модели. Всего лишь :) Ничего персонсального.

Скажи, что тебе задело и я скажу, что я подразумевал :)

Кстати, очень хорошее упражнение на прокачку своей зрелости. Признаюсь мне далеко до этого. Но когда что-то тебя раздражает просто задумайся почему. Может это звонок из подсознательного, может есть ложные убеждения. Надо задумать чего это мне не даёт дышать полной грудью и банить других людей?

Кстати по поводу зрелости хорошая информация лежит здесь: http://denismiller.blogspot.com/2009/02/blog-post.html

В общем я не понял почему Александр решил "Вот на этом предлагаю дискуссию и завершить. Этот сайт не для обсуждения моей личности, копания в моей жизни или игры в “убей автора”. Мне это не интересно. Full stop.".

В общем, я полностью потдеживаю работу Александра, но считаю её можно улучшить выкинув этот термин - "правильные" разработчики :)

Принципы здравого менеджмента

Очень поучительный список принципов для менеджера. Каждый пункт требует отдельного раскрытия я думаю. Мне очень понравился четвертый принцип :) К пункту пять я бы ещё добавил, что и хорошие вещи протухают, если к ним не обращаются :)

Другой вопрос - причем качественный код и менеджмент. А просто мы работаем интеллектом. И если нас чего-то расстраивает, это влияет на результат работы этого интеллекта. Так что код будет плохой, если менеджмент такой :)

The Principles of Common Sense Project Management

1. The process of Project Management is basically the same on EVERY project; it is the intangibles that make the difference in the success of the project.
2. LEADERSHIP is not synonymous with Project Management.
3. CREATIVE PROBLEM SOLVING is essential to Project Management. The SIMPLEST answers are usually the best one.
4. If you are not part of the SOLUTION, then you are part of the PROBLEM.
5. Bad news is not like an expensive bottle of wine; it DOES NOT get better with age.
6. Communication should never be MANAGED from stakeholder to stakeholder.
7. Of all of the project constraints … TIME controls the Cost, Quality, SOW (Statement of Work) and Customer Satisfaction.
8. It is better for your project, if the TECHNICAL EXPERT is not the Project Manager.
9. Your TEAM is the most important resource you have on a project.
10. Documented Lessons Learned are MANDATORY after the closure of a Project.

Common Sense is not common; otherwise more people would have it !!


Copyright © 2009, A.Sloan Campbell, MBA, PMP, P.Mgr, F.CIM
Additionally: if you don't have time to do it right...how will you find the time to do it over? - Tim Bidlack PMP

Оригинал: ссылка

Битва гигантов Spolsky vs Robert Martin

Интересное пришло сообщение от Асхата. Гиганты программирования и гуру всего и вся столкнулись в битве за TDD и PPP.

Начало положил подкаст Scott Hanselman. Не нам их судить, но ряд цитат приведу:

Spolskyit seems to me like a lot of the Object Oriented Design principles you're hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture's sake.

Kent Beck: He has worked hard to become famous, but he hasn’t figured out that along with notoriety comes responsibility. He is a bright, experienced guy and certainly capable of more accurate, thoughtful, and constructive conversation.

На что ответили все мною почитаемые гуру: Кент Бек, Рон Джефрис.

В общем не понятно, почему Спольски подлил эмоционального огня. Видать его книги стали плохо продаваться. И по его выпадам видно, что он не читал книгу Роберта Мартина, и подавно Кента Бека. Жаль там очено много идей на фоне которых его эмоции просто детский лепет... Но устами младенца :)

К слову:
Роберт Мартин - человек, который собрал ребят в далеком 2001 году и они сделали AgileManifesto. Он так же автор книги про PPP. В ней кстати достаточно ошибок и приколов, которые мы очень хорошо обсудили и посмаковали над Design Patterns Study Group.
Кент Бек - стоял в основе Desing Patterns и идеи wiki-сайтов. Автор eXtreme Programming.

Развитие сотрудников

Александр заметил предложил тему за развитие персонала. Но мне показалось он немного односторонне осветил этот вопрос переложив ответственность за развитие не на HR-отдел или линейного менеджера (скрам-мастера), а на самих сотрудников.

В обязанности менеджера, руководителя или скрам-мастера входят разработка программы развития сотрудников (или хотябы думать о ней). То что он простите штаны протерает - не повод народ обежать.

То что он не может выполнить своих обязанностей это его проблема. Которые кстати и отражается на команду и продукт. В обязанности менеджера или скарм-мастера входят:
- идентификация потребностей работников,
- согласование плана развития
- управления пожеланиями
- синтез с целями проекта и компании
- и многое другое

То бишь, отделить зерна от плевел тех, кого надо развивать, от тех, кого не надо, достаточно просто: нужно просто предложить людям развиваться в свободное время. Например, предложить посетить тренинг или семинар на выходных.

А развивать нужно всех - не судите и судимы не будете. А правила 40 часовой недели никто не отменял. Хотя если менеджер мне выходной оплатит. А так очень нехорошее предложение. Я бы послал такого менеджера куда подальше :) Пусть сам в выходные работает, даже под эгидой тренинга. Исключения конечно составляют Agile-тусовки за счёт компании.

Продукт - творчество командного интеллекта. А если одна часть его развивается, а другая пожизненно пребывает в зачаточном состоянии. Ведь все ребята программят и делают вклад в продукт. А как наполовину развитый командный интеллект сможет выдать качественный продукт?

Вторая половина, что и работники не должны дремать - полностью согласен. Но именно первый шаг это менеджер/скрам-мастер, как представитель вертикали власти и авторитативный источник задач для команды.

Блин, спеллчекер нужно поставить какой-нить :)

Книги о качественном кодирование

Случайно решил проверить на сафари какие книжки от Diomidis D. Spinellis. Оказалось он написал ещё две новых! Теперь у этого автора три книги, которые рекомендую для чтения:





Diomidis Spinellis. Code Quality: The Open Source Perspective. Addison Wesley, 2006. ISBN 0-321-16607-8.

Diomidis Spinellis. Code Reading: The Open Source Perspective. Addison Wesley, 2003. ISBN 0-201-79940-5.

Diomidis Spinellis and Georgios Gousios. Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design. O'Reilly, 2008. ISBN 9780596517984.

Кстати, если тема книжек пошла, то хотелось бы добавить ещё пару ссылок на тему качественного кода:

Code Craft, 1st Edition by Pete Goodliffe
Clean Code: A Handbook of Agile Software Craftsmanship by Robet Martin

Agile Software Factories by Damon Wilder Carr

In this book I attempt to show the reader my experiences on projects wanting to go beyond Agile, and actually leverage Factories. The Agile approach is a natural fit in describing a process for factories (something few have fully done and I attempt to do).

To be more specific, I show my experiences in applying Agile practices in a software factory environment (mostly in the factory construction phase but also in the use of the factory) with great success. Many taking a factory approach can slide back down into a ‘waterfall’ type mentality due to the misconception that ‘factories are not iterative’. In fact they must be in almost all cases.

I will also discuss the commonalities between factories and broader ‘Lean Manufacturing’ concepts. A full example will be presented with hands-on examples. This is not so much a ‘theoretical’ book as one which explores what can be done today using the technologies available.

Also explored (in addition to much more) is the idea that Software Factories for the Agile-enabled company today will have a smaller learning curve then others in adopting factories.
---

На горизонте появилась новая книга, которая упоминалась ещё в 2007 году (но может это только реклама).
Ссылка на магазин. К сожалению пока никакой информации о книге нету. Будем следить за событиями :)

Об опыте автора на linkid.
Блог автора: здесь
Его проект на codeplex: SOA Framework for Silverlight/WCF Cross-Platform (This code is used in our five day master's class immersion in 'Domain Driven .NET using C# 3.0'.) и хорошое известного модуля статистики для Cruise Control (ссылка)

Эффективная работа с унаследованным кодом

Наконец-то появился русскоязычный перевод классической книги для разработчика "Working Effectively with Legacy Code" Michael Feathers. Как написать новую строчку кода, куда её помещать, как написать тест под наследованный код. Множество вопросов - и в этой книге ответы.

Аннотация:
Учитесь извлекать максимум пользы из унаследованных систем, повышая их производительность, функциональность, надежность и сопровождаемость!
Можете ли вы без особого труда изменить код и тут же получить ответную реакцию на внесенные изменения? Насколько понятен этот код? Если вы ответите на эти вопросы отрицательно, значит, вы имеете дело с унаследованным кодом и понапрасну тратите время и средства на разработку.
В своей книге Майкл Физерс предлагает полноценные стратегические приемы эффективной работы с крупными базами унаследованного нетестированного кода. В основу этой книги положен материал, подготовленный автором к известным семинарам, организуемым компанией Object Mentor, включая приемы, которым автор обучил сотни разработчиков, технических руководителей и тестирующих программное обеспечение подчинять себе непослушные унаследованные системы.
В этой книге освещаются следующие вопросы:

* Представление о механизмах внесения изменений в программное обеспечение, включая ввод новых свойств, устранение программных ошибок, улучшение структуры кода, оптимизацию производительности.
* Перенос унаследованного кода в средства тестирования.
* Написание тестов, препятствующих внесению новых ошибок в код.
* Применение методов, подходящих для любого языка или платформы, с примерами кода на Java, C++, C и C#.
* Точное выявление мест в коде, где требуется внести изменения.
* Работа с унаследованным кодом, который не является объектно-ориентированным.
* Обращение с приложениями, у которых, на первый взгляд, нет вообще никакой структуры.

Кроме того, в этой книге представлены 24 способа разрыва зависимостей, помогающих работать с элементами программного обеспечения обособленно, чтобы сделать внесение изменений в код более безопасным.

Майкл К. Физерс работает в компании Object Mentor, Inc., занимающей ведущее в мире место в сфере предоставления услуг обучения, повышения квалификации, распространения знаний и руководства проектами по разработке программного обеспечения. В настоящее время он занимается обучением разработчиков со всего мира методам разработки за счет тестирования, реорганизации кода, объектно-ориентированного проектирования, программирования на языках Java, C++, C и C#, а также экстремального программирования. Майкл является автором первоначального варианта среды тестирования CppUnit, перенесенной на C++ из среды JUnit, а также среды интегрированного тестирования FitCpp, перенесенной на C++ из среды FIT. Он состоит членом Ассоциации по вычислительной технике (ACM) и Института инженеров по электротехнике и электронике (IEEE), а также председательствовал на трех конференциях разработчиков программного обеспечения CodeFest и OOPSLA.

Эта книга посвящена практическим вопросам эффективной работы с унаследованным кодом. В ней освещаются механизмы внесения изменений в унаследованный код, включая ввод новых свойств, устранение программных ошибок, улучшение структуры кода и оптимизацию производительности; способы переноса фрагментов кода в среду тестирования, особенности написания тестов для безопасного изменения и реорганизации кода, приемы точного определения мест для подобных изменений, а также подходы к обращению с унаследованным процедурным кодом. Кроме того, в книге на конкретных примерах кода, написанного на Java, C++, C# и C, демонстрируются способы разрыва зависимостей для работы с обособленными фрагментами кода и безопасного внесения в них изменений.
Книга адресована тем, кто имеет опыт разработки прикладного программного обеспечения и его сопровождения.

Рекомендую к изучению: ссылочка

Краткий экскурс в Agile (аудио запись, mp3)

Мы с Олегом проработали около года в одной команде. Там я был Agile Coach, а теперь разъехались по разным городам. Теперь Олег стал Agile Coach в своей команде. Мы созвонились, чтобы кратенько синхронизировать практический опыт и теоретические знания об Agile.

Обсуждали базовые принципы управления в Agile. Разговор немного неплановый, многие идеи высказывались, но многие остались за бортом. Но этого достаточно, чтобы понять, что такое Agile и базовые шаги по его внедрению. Рассказывались практики для выработки общего видения и выработки общих принципов разработки.

- Управление требованиями в Agile (пирамида требований)
- Принцип "Разделяй и властвуй" (декомпозиции)
- Планирование релиза, итераций и конкретной итерации
- Оценка требований и задач
- Практика "AgileManifesto" (освоение командой принципов адаптивной разработки)
- Практика "DONE"
- Обратная связь
- Архитектура в Agile
- CRC карточки и моделирование
- Техническая поддержка (CI, xUnit ...)
- Культурные особенности в команде
- Командное образование

Аудио-запись: файл (mp3, 22Mb)

Краткий конспект, сделанный Олегом:


К этому делу конечно же нужно добавить такие практики: ретроспектива, демо, измерение скорости, метрики процесса и многое другое.

Цитаты для менеджеров: прокачиваем эмоциональный интеллект

Руководители, которые не обладают достаточной зрелостью и часто просто не понимают причин своих неудач – отчасти потому, что никто честно не говорил об их посредственных результатах.

Настоящий комфорт никогда не возникает в результате сокрытия истины. Защита других сотрудников от правды никого не спасет, а вред принесет всем. Разве не важно перед выходом на сцену знать о том, что молния на брюках расстегнулась?

Навыки участников зрелой команды с точки зрения эмоционального интеллекта:
• Переживание своих эмоций.
• Способность думать о своих чувствах.
• Отслеживание развития своих отношений с собственными эмоциями.
• Понимание динамики эмоционально-чувствительных особенностей своего характера и влияния, которое эти особенности
оказывают на вас и окружающих людей.
• Последующее изучение ситуаций, в которых вы испытывали эмоциональные неудобства, а не стремление «снять дискомфорт».
• Взвешенная оценка любого ощущения «крайней необходимости», возникающего в ситуации, когда вы или окружающие испытываете эмоциональный дискомфорт.
• Определение цели до совершения действия или высказывания в случае переживания бурных эмоций.

Ценность вашего вклада в меньшей степени является функцией времени, потраченного на предприятии, и в большей степени зависит от интеллектуальной вовлеченности (комментарий: ну как вам ещё нужны таймшиты?)

Люди, которые заявляют о своих навыках или постоянно ссылаются на свое образование, но не применяют ни то нидругое, не разумны. Истинные специалисты продолжают повышать уровень своей образованности и стремятся развить свои умения. Они не размахивают дипломами, а применяют свои знания на практике. Они ищут пробелы в своем образовании и первыми признают неполноту своего опыта.

Джим Маккарти, пэкаде

Agile Study Group: Джим и Мишель Мак-Карти. Программируем командный дух

Мы начали обсуждать самую любимую мою книгу по динамке развития команд. Эта книга питает меня в нелёгкой работе Agile евангелиста. Книга сложная, но очень важная!

Книга номер 1 для меня.

Книга: Джим и Мишель Мак-Карти. Программируем командный дух
Глава: Введение



Адрес подкаста с обсуждениями: http://study-group.rpod.ru/96956.html

Отзывы участников о книге:
Вячеслав говорит: башню срывает влет :)
даже когда осознаешь :)
самое интересное, что это можно только к себе применять :)
даже без комманды

Слава говорит: Мне нравиться что есть вполне конкретные практики как бороться с общей командной закомплексованностью

Кирилл говорит: Я в восторге от этой книги! Щас заплачу прям)

Принципы управления проектом в Agile (Agile Management Principles)

Часто слышиться вопрос - что такое Agile? А весь Agile заключён в манифести и 12 принципах. А дальнейшая интерпретация у каждого своя. Можно проинтерпретировать и сделать Scrum, а можно XP. Но не конкретная методология важна, а сам подход.

Чтобы проверить - вы Agile менеджер или Agile команда посчитайте сколько раз сказали "да это про нас" в списке главных принципов Agile для менеджеров:

1. Deliver something useful to the client; check what they value.
2. Cultivate committed stakeholders.
3. Employ a leadership-collaboration style.
4. Build competent, collaborative teams.
5. Enable team decision making.
6. Use short timeboxed iterations to quickly deliver features.
7. Encourage adaptability.
8. Champion technical excellence.
9. Focus on delivery activities, not process-compliance activities.

Highsmith, J. 2004. Agile Project Management: Creating Innovative Products, Addison-Wesley

Жирным я отметил очень интересные вещи. Действительно ли в вашей команде решения принимает команда (п.5)? Или вы берёте на себя ответственность и решаете, что и как делать? Например назначая задачи на этих пройдох программистов :)

Или п.1 что для вас важнее поставить 100% выполненную работу оттягивая сроки, но борясь за каждую запятую в ТЗ и доскональной реализации даже формочки About? Либо 20% но самое главное и как можно быстрее, чтобы помочь клиенту уже начать работать, а не ждать 100% функционала в том числе и супер полезной формочки About?