Lean и роль менеджера в Agile. Бесплатный семинар.

12:25 pm - Семинары "Lean и роль менеджера в Agile"

26 Дек	Семинары "Lean и роль менеджера в Agile" Luxoft Ср, 26 Декабря 2007 в 19:00

Мэнеджмент проекта vs JIRA

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

http://confluence.atlassian.com/display/JIRAEXT/Agile+Wall+Report
http://confluence.atlassian.com/display/JIRAEXT/Agile+Velocity+Tracking+plugin
http://confluence.atlassian.com/display/JIRAEXT/JIRA+Charting+Plugin
http://confluence.atlassian.com/display/JIRAEXT/Timecharts
http://confluence.atlassian.com/display/JIRAEXT/Links+Hierarchy+Reports
http://confluence.atlassian.com/display/JIRAEXT/Laughing+Panda+JIRA+Agile+Report+Plugins

И дальше по ссылкам. Очень порадовало заточка ряда плагинов на Agile практики. Так что дерзайте!

Кстати, JIRA стоит значительных денег. Если у вас нет несколько лишних тысяч долларов я с предлагаю хостить ваш проект у меня. Настройку, конфигурацию и поддержку обеспечу. Стоить будет ровно в 10 раз меньше :)

Personal Sprint

Приведу стэк задач, начнём с наиболее крупной и дальше по убывающей.

1. Vision. Общие знания о проекте, стратегия его развития, фундаментальные принципы декомпозиции и т.п. То что почти не меняется. Стратегические цели. Оценивается бизнес-значимостью.
2. User Stories. На первом месте требования пользователей. Это самые крупные, можно сказать тактические цели в рамках проекта. Оценивается бизнес значимостью и Story Points. Что такое story points? Это сипульки. Условное обозночение трудозатрат, оценивается разработчиками.
3. Tasks. Задачи для разработки. Конкретные задания, которые должен выполнить участник команды. Оценивается в часах. Продолжительность от 1 часа до 1 дня.
4. Personal Sprint (Checklist, TestList). Записи в блокнотике. Каждый разработчик разбивает Task на мелкие шаги. После каждого шага вычёркивает пукнт из List. Для практикующих TDD см. паттерн Test List. Это список тестов, которые нужно написать. Продолжительность от 10-20 минут до одного часа.

Последний пункт может выглядить примерно так. Я хотел сделать "тупой маленький чеклист" для рефакторинга перемещение поля:
1. модифицировать все установки поля (setter)
2. модифицировать всех читателей поля (getter)
3. удалить объявление поля
4. и так далее в таким же простым способом

Можете наконец-то в своём IDE воспользоваться окошком TODO ;)

В заключение, в дополнение к жесткому разделению задач и декомпозиции неплохо добавить контекстное управление задачами. Бывают задачи, которые нужно решить в зависимости от сложившихся ситуаций. Примеры ситуаций: "лень", "звонок коллеге", "появление на горизонте начальника". Эти ситуации поместятся на стикер и можно расположить на мониторе.

Плюс от таких бумажек следующий - МАТЕРИАЛИЗАЦИЯ. Голова хорошо, но простой список задач проще. Профессиональные медики (см. фильмы зарубежные) ходят с checklist'ом и отмечают галочками выполненные задачи (приём таблеток, процедуры и т.п.). И этому учат их в институте. Так почему такая простая практика отстутствует в арсенале профессионального разработчика? Вы не знаете чем заняться глянули в список и выбрали. Не знаете чем убить минутку до совещания. См. в список.

На закуску пару интересных ссылок не по теме :)
1. Visual Studio Team System 2008 Team Foundation Server Power Tools
http://msdn2.microsoft.com/en-us/tfs2008/bb980963.aspx
2. Год MSDNWiki
http://blogs.msdn.com/sandcastle/archive/2006/09/06/742352.aspx
3. Google.vs.Wiki
http://itblogs.ru/blogs/kav/archive/2007/12/21/24329.aspx

А вы Agile команда?

Ответьте на 4 вопроса Скотта Амблера и вы поймёте Agile-команда вы или нет.
Вопрос 1. Покажите свои Unit-тесты.
Вопрос 2. Познакомьте меня со своим заказчиком
Вопрос 3. Покажите ваш CM (configuration managenet)
Вопрос 4. Покажите вашу самоорганизацию.

Если на все четыре вопроса я увижу в вашей команде ответ, то вы Agile-команда!

Показ мод от Microsoft 2008

ADO.Net Entity Framework beta 3. Решение ORM от Microsoft.

ASP.NET 3.5 Extensions Preview - MVC каркас

Определите национальность

Определите национальность автора кода

//--------
boolean b;

if(b.toString().length() >4){...}
//-------

Dream Team: Первый шаг

Сегодня провели первый старт. Микро-отчёт.

1. Повешана White Board + Status Board
2. Рассмотрены следующие практики:
2.1. Dialy Scrum Meeting
2.2. Атрибутика для DSM: мечь кладенец, банка для добровольных пожертвований.
2.3. Коллективное притяние решение из Базового Протокола.
2.4. Niko-niko календарь.
2.5. User Story в формате "As a user ..." (см. Mike Cohn)
3. Поговорили о целях, целеполагании.

Сложности были в обсуждении п.2.3. Не все решения могут коллективно приниматься. Например, административные. В п.2.1. было сложно договориться во сколько же собираться. Решили договориться на 13 часов. Основной аргумент, чтобы до обеда порешать задачи, которые могут возникнуть после митинга. Сложность в п.2.2. это сама концепция штрафа (банка) была неудобна одному участнику. Согласились действовать по принципу "кто что сможет"; то есть штраф за опоздание на планёрку не строго типизирован: конфетки, деньги и т.п. а гибче "кто что сможет". Niko-niko календарь в основном все поддержали, не поддержавший сказал детские игры. И пришлось признать себя большими детьми :)

Провели ретроспективу на практики и решили заиспользовать в течении следующей недели.
Продолжительность первого шага: 1 неделя.

PS. Таски на жёлтых стикерах признаны для обсуждения (например религиозного). Запланировали повесить возле доски контейнеры для разноцветных стикеров. Возле Nico-nico календаря весит пачка фломастеров.

TeamCity 3.0

Похоже команда Jetbrains решила захватить рынок традиционным способом - БЕСПЛАТНО.

Now available for free, TeamCity 3.0, delivers multiple improvements in different areas and extends support for both Java and .NET software development teams. To name just a few: a new licensing policy, per-project roles and permissions, build statistics charts, .NET code duplicates search, VCS integration enhancements, upgraded performance, and a better user experience.

The key new features of this release include:

• Per-project access rights with project roles – an exclusive feature of the Enterprise edition
• Build statistics charts, with declarative pluggable charts for user-defined metrics
• Pre-tested commit from Visual Studio for Subversion
• StarTeam support
• .NET Duplicates finder for catching similar code fragments of your C# and Visual Basic .NET code
• Java Inspections and Duplicates for Maven2 projects
• Version Control labeling for Subversion, CVS, Perforce, StarTeam, ClearCase
• “Hanging” builds auto-detection and thread dump capturing, for quick feedback on Java and .NET builds’ problems
• Display of build start/finish estimations in the build queue
• Build tags for organizing and quickly filtering builds

To learn more about new features in TeamCity 3.0, please visit
www.jetbrains.com/teamcity/features/newfeatures.html?tc30a.

For additional details about the new licensing scheme for Professional, Enterprise and Open Source licenses, see http://www.jetbrains.com/teamcity/buy/?tc30a .

Existing TeamCity users qualify for a free upgrade to the most feature-rich Enterprise edition. For details, go to http://www.jetbrains.com/teamcity/buy/index.html#upgradeuser?tc30a.

Agile Practices

Сегодня причесал вики сайта http://AgileRussia.ru. Основной упор сделал на разделение всего Agile мировозрения на две вещи: 1) практики и 2) методологии.
Соответственно в практиках будет накапливаться информация о всевозможных Agile-практиках, которые планируется собрать со всего интернета. Кстати, подключайтесь, дел много, заодно узнаем много нового.
Во втором разделе классификация этих же практик с точки зрения авторов методологии.

Сам ресурс доступен по адресу: http://agilerussia.ru/wiki/index.php?title=Practices

PS. В середине недели дам доступ :)

Dream Team: Создание новой Agile-команды

Буквально со следующего понедельника стартует подготовка новой Agile-команды. На страницах своего блога я собираюсь поведать как всё будет происходить. Фактически, команда собрана и уже давно успешно работает. А нам остаётся только прийти на готовенькое и внедрить самое-самое.

По секрету. В моём плане 1.5 месячный забег на олимп Аджайла. После которого произойдёт инициация команды. 1.5 месяца я буду водить команду по пустыни. А в завершение команда сама выберет свой путь развития. И как показывает практика, при всём мноогбразии других вариантов нет.

Итак, жду вас на следующей неделе. Буду сообщать с фронта событий.

Мы делаем новости!

Dependency Injection Application Block

Ребята в Microsoft решили обзавестись своей реализацией Spring.Net. Дали ей название Dependency Injection Application Block. Такое творение ожидается в следующей версии Enterprise Library.

Более подробно читайте об этом слухе - здесь

Функциональный стиль C# 3.0 в помощь качекодуру

Качкодер (сокращённо качёк) - человек, которые пишет качественный код.

В блоге Ивана появилась первая статья о функциональном программировании. Вырежу самые приятные слова, за остальным заходите к Ivan'у :)

Polygon triangle =
  new Polygon {
    new Point { X = 3, Y = 5 },
    new Point { X = -5, Y = 4 },
    new Point { X = -1, Y = -6 }};

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


В чем же цимус от использования неизменяемых объектов, вместо обычных переменных? На самом деле мы получаем целый ворох конфет:
- Отсутствие побочных эффектов. Работа любой функции гарантировано зависит только от входных параметров и результатом ее работы являются только выходные параметры.
- Мы можем совершенно безопасно отдавать свой объект наружу во временное пользование, у нас есть 100% гарантия, что его никто не испортит.
- Отладка упрощается в разы. Все с чем будет работать функция лежит в стеке вызова.
- Повышается эффективность тестирования.
- Колоссально упрощаются алгоритмы синхронизации доступа из разных потоков.
- Появляется возможность автоматически распараллеливать выполнение задач.
- Существенно упрощаются алгоритмы хэширования и выявления эквивалентности.
- Реализация Undo/Redo, причем не только структур данных, но и хода выполнения программы становится тривиальной.
- Появляется возможность заменять произвольные функции не останавливая всей программы. (Реально существуют приложения на Erlang-е, работающие годами без остановки, код которых был заменен целиком)
- ... и много других приятных плюшек.

Джимми Нильссон. Применение DDD и шаблонов проектировани - пример некачественного перевода.

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

"Отличная книга, жалко конечно все это дело опубликовано на туалетной бумаге. За такую бумагу 650 рублей брать, это беспредел. Об этом написал в само издательство никаких ответов. Опечаток тоже очень много, переводили наскоро наверно. Об этом я также упомянул в письме издателю."

"Кроме опечаток есть и просто неправильный перевод профессиональных терминов, что несколько раз меня уже вводило в ступор"

А теперь мой собственный комментарий. Зелёную полосу называют провалившимся тестом. TestFixture — обозвали тестовой конфигурацией на схеме. Mock объект имитацией. А самовольная замена DDD на ППО, а TDD на РПТ — бесчинство и яркое неуважение к читателю.

Пару ярких цитат: "Тест компилируется, но даёт положительный результат (красную полосу)" (стр.464) в оригинале "It compiles, but it turns red.". А от этого плакать хочется: "Теперь тест даёт наконец-то отрицательный результат (зелёную полосу)!" (страница 467 внизу)

Вывод: НЕ ПОКУПАЙТЕ!!! ЧИТАЙТЕ ОРИГИНАЛ!!!