Зачем 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?

Странная политика Russian Podcasting

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

1. Права на чтение книги - на support@rpod.ru плиз
и да - сообществ нам и так хватает...

1. Я не понял, зачем на обсуждение книги нужно право? :(
2. И сервис у них не для участников сайта, а ради, чтобы хватало...

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

... добавлено через 4 часа ...
Нашёл выход, просто завёл фэйковый адрес и подписался на все подкасты в качестве ленты друзей. Получилось: http://u19376.rpod.ru/friends. Вроде неплохо. Остаюсь на первом :)

О целях использования Study-Group

Кратенько выскажусь о сути явления :)
Вопрос был поднят в стади-групп обсуждениях.

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

Study-group - всего лишь определённый инструмент добывания теоретических знаний (даже если это опыт участников), объединяющий структурный (фильтр восприятия) и системный (обсуждения) анализ. Это способ изменения мышления на системный. Когда мы критериально оцениваем информацию. Возможно развитие этой практики в стороную формирования целостного восприятия. Кстати, подготовка, встреча, резюме по главе, резюме по книги формирует цепь закрепляющей обратной связи и глубокого освоения материала.

Касательно целей. Думаю, у инструментов врядли есть цели. Цели есть у желающего пользоваться этим инструментом (например для персонального использования я повышаю свой теоретический уровнь, а если используешь в команде - синхронизация и выравнивание командного инженерного видения на подходы, принципы и способы решения проектных задач). Цели нужны для мотивации объединения вокруг общей задачи. У нас такой задачи нету, каждый сам решает свои цели в стади-групп. Я усматриваю другого рода мотивацию - плановость и предсказуемость. А сама стади-групп состоя из двух этапов: подготовки и встречи. Отражает разные варианты мотивации. Например, неменуемость встречи и желания плодотворно в ней поучаствовать толкает нас к нахождению времени на подготовку. Без стади-групп это бы носило несистемный характер, к тому же нужна была бы сила воли. Встреча смещает акцент в область взаимоотношений. И связана с самореализацией и самоидентификацией каждого участника.

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

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

То же самое в цифрах.
1. Читая один книгу я получу пусть 80% информации от автора.
2. Работая в стади-групп я потенцильно могу получить 80% из п.1 + 20% между строк через обсуждения и доосмысления авторской информации+ 100% (и более) информации из группы и её опыта.

А для максимизации п.2 система заметок должна спровоцировать появления 20% и 100%. Система заметок как ключ для подключения и аккумулации этих процентов.

Цифры взяты с потолка. Опять же важная сейчас не количественная составляющая, а качественная.

Сопротивляемость изменениям или про тюрьму опыта

Просто приведу цитату, которая просто вызывает благоговенный лепет в моей душе:

Идея о тюрьме впервые была исследована Платоном в «Республике» в знаменитой аллегории пещеры, где Сократ рассуждает о связи видимости, реальности и знания. Перед входом в подземную пещеру пылает костер. В пещере находятся люди, закованные цепями и лишенные возможности двигаться. Они видят только ту стену пещеры, что прямо перед ними. Она освещена пламенем, и тени людей и предметов видны на ней. Обитатели пещеры думают, что тени - реальность, дают им имена, говорят о них и даже связывают звуки, доносящиеся снаружи, с движением теней на стене. Истина и реальность для пленников заключаются в этом мире теней, поскольку они не знают другого.
Однако, считает Сократ, если бы одному из жителей пещеры позволили покинуть пещеру, он понял бы, что тени - всего лишь отражение более сложной реальности, а знания и восприятия его товарищей неверны и искажены. Если бы он вернулся потом в пещеру, он никогда уже не смог бы жить по-старому, поскольку для него мир был бы уже другим. Несомненно, ему трудно было бы смириться со своим затворничеством и стало бы жалко других пленников. Однако если бы он попытался поделиться с ними своим новым знанием, его, вероятно, осмеяли бы. Для пленников знакомые образы пещеры имели бы гораздо большую значимость, чем тот мир, который они никогда не видели. Более того, поскольку человек, получивший новое знание, больше уже не сможет функционировать с прежней убежденностью относительно теней на стене, его сотоварищи, скорее всего, посчитают внешний мир опасным. Это происшествие приведет к тому, что они станут жестче придерживаться знакомого образа мыслей.
Герет Морган. Образы Организации. с.235

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

Теперь я полностью понимаю своих не-Agile оппонентов, видать им в пещере уютней :)

Story Points vs Ideal Hours

Для многих возникает неоднозначность и недопонимание, зачему вводить такую характеристику, как Story Point. А так же в продолжение предыдущего поста.
Объяснения очень просты. В Agile используется и то и другое. Но для разных уровней декомпозиции требований и реализации.

Я выделяю следующую пирамиду требований к разрабатываему продукту. От верхнеуровневой бизнес идеи до задач для разработчиков. В этой пирамиде требования к продукту (1-3) постепенно разбиваются до требований разработчика к коду (4-5) :)

1. Метафора продукта
2. Фичи продукта
3. User Story
4. Task
5. Task List

Каждый нижний пункт является декомпозицией верхнего. Мерить п.1 и п.2 очень сложно. Так как это очень высоко и тяжело оценить хоть как-то. п.5 (декомозиция задачи на мелкие шаги; Test List - шаги по задаче) слишком мелкий для оценки и нецелесообразен для оценок.

Рассмотрим п.3 и п.4
3. User Story оцениваем в Story Points с использование Planning Poker.
4. Tasks оцениваем в Ideal Days/Hours используя одну из схем: индивидуально (старый подход) или коллективно (новый с 2004 года).

В переводе на русский
3. Функциональные требования оцениваются в единицах трудоёмкости
4. Задачи оценивают в идеальных часах задачи (до 2 дней)

Продолжительность Ideal Hour адаптивно выбирается. В классике отталкиваются от 6 часов. Остальное адаптируется по ситуации.
Во время планирования на выходе мы получаем
1. Плановую суммарную Story Points
2. Плановое суммарное Ideal Days/Hours

Управление скоростью разработки легче вести с более высокоуровнего пункта. А так как у нас оценке подлежит только п.3 и п.4 - выбор очевиден. К тому же Story Points непосредственно связаны с функциональными требованиями и бизнес ориентированы. В тоже время под Ideal Hours может подпасть много не входящее в User Story, и носят инженерный оттенок реализации. Далее вводится фокус-фактор, но об этом смотрите в предыдущем посте.

Это классическая схема работы. Опыт показывает, что изобретать альтернативы не имеет смысла. Но это не должно останавливать.

Дополнительные ссылки:
1. Об agile по-русски: User Stories
2. Planning Poker

Мотивация в три шага

По эволюции развития существует три шага:

Шаг 1. Принуждение
Шаг 2. Стимулирование
Шаг 3. Прямая мотивация

Принуждение - моральное, экономическое (премии, бонусы, штрафы и т.п.) и физическое принуждение. В общем смотрим на наши команды в ИТ и понимаем. Мы здесь! Здраствуй принуждение :)

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

Нас всю жизнь учат этому способу работы. Паутина подчинения проявляется во всём: учёба, семья, институт и т.п. создают и культивируют в нас "подчинение". И потом удивляемся, почему бывшие рабы становясь начальниками используют этот вариант с большим усердием.

Кстати, В.И.Ленин знал только такой способ мотивации работников: записка В. И. Ленина: «…а Ильина… и весь фабком этого завода… и весь состав комячейки… объявляем виновниками… и объявляем строгий выговор и общественное порицание, с предупреждением, что только на первый раз так мягко караем, а впредь будем сажать за это профсоюзную и коммунистическую сволочь (суд, пожалуй, помягче выразится) в тюрьму беспощадно» (Ленин В. И. Полн. собр. соч. Т. 54.)

Стимулирование - когда мы обеспечиваем достаточный уровень мат.потребностей, создаём независимость работников от эконом. характеристик его бытия. Некоторые продвинутые команды разработчиков, да и вообще в России робко говорят и смотрят в эту область мотивации. Жаль, что многие менеджеры, тим лиды (специально не обученные) и бывшие программисты только используют шаг 1. И просто не понимают, как передвинуться к шагу 2.

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

Прямая мотивация - удовлетворенность содержанием, процессом и смыслом, значимостью труда (Р. Шпренгеру). Когда создаётся вовлечение участников разработки в процесс, в коллективное творчество.
Этот шаг и создаётся Agile-коучером.

К чему, я это написал. Да убеждаю себя купить книгу.

Dependency Inversion Principle, Dependency Injection и Inversion of Control

Кратко напишу так
Dependency inversion principle (DIP) - разрыв ЗАВИСИМОСТЕЙ через абстракцию
То есть, когда мы выводим интерфейс IA и скармлеваем потребителю B, мы отрываемся от зависимости, когда потребитель зависит от изменений конкретного класса A. А рассуждая далее, получаем, что логичней переименовать IA и IB, то есть клиент B определяет, что ему нужно от А:

B использует IB
A реализует IB

Dependency injection - механизм использующий DIP, DIP создает возможность использования DI

Inversion of control (IoC) - Don't call us, we'll call you (Hollywood principle) - принцип, когда основной поток управления (алгоритм) определён, и мы кастомизируем части. Частный случай, когда поток управления скрыт в базовом одном классе - паттерн Template Method. Более сложный вариант - модель Framework и частичная передача управления выполнения нашему приложению.

Очень жаль, что такие понятия путаются. А особенно это замечено в русской википедии. Ну и даже Роберт Мартин в своей книге попутал. Привязав голливудскую фразу к DIP. И вообще в его английском и русском варианте много неточностей, которые мы обнаружили коллективным разумом стади-групп.

Ссылки по теме:
- http://igor.quatrocode.com/2008/09/solid-top-5.html

Образы организации

Случайно зашёл в книжный, а там случайно открыл случайную страницу этой книги - прочитал. Автор дельные мысли написал. Купил. Читаю... Расстраиваюсь.

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

Конечно, тем людям, которые любят строгую иерарихию, планы, распределение обязанностей и т.п. в разработке ПО. Книга будет полезна. Её объём достаточный, что потихой убедить этих людей в их ограниченном восприятии. Книга покажет им все многообразие смыслов и восприятий. Глубина и важность человеческого фактора выварачивается вдоль и вширь :)

С точки зрения Agile там мало чего полезного. Если вы практикуете Agile вы сами будете думать ещё похлеще автора. Отличие автора от вас лишь в его научном описании, то что вы знаете и так :)

Очень порадовали библиографические заметки. Единственно насыщенная информацией часть книги :)

Для Agile-истов: не рекомендую
Для не-Agile-истов: обязательная к прочтению.