Мастерство программирования

Интеграция SCRUM и Eventum или идеи по улучшению процесса разработки ПО

Это руководство написано для компаний которые активно используют Eventum и у которых есть желание перейти на гибкие методики разработки ПО, например на SCRUM.

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

Отсутствие статистических данных по прошедшим этапам разработки, таким как: прогнозируемое время выполнения задачи, реальное время выполнения, эффективность и производительность прошлых этапов.

Цель перехода на SCRUM: повысить эффективность разработки, увеличить производительность команды и знать насколько производительна команда, что важно для оценки будущих проектов.

Как показали данные исследований различных софтверных компаний, то те компании которые перешли на современные и проверенные методологии разработки ПО повысили свою эффективность и производительность на 50% и более процентов, а некоторые достигли шести кратного увеличения производительности команд.

SCRUM является одной из таких современный и проверенных методик разработки.

Узнать что такое SCRUM и XP вы можете посетив следующие веб-ресурсы:

• Scrum and XP from the Trenches http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
• Тоже самое но на русском http://scrum.org.ua/scrum-i-xp-zametki-s-peredovoj/
• Wiki scrum http://en.wikipedia.org/wiki/Scrum_(development)
• Agile manifesto http://agilemanifesto.org/
• Short intoduction into Scrum http://www.mountaingoatsoftware.com/scrum
• What is xp in short http://www.xprogramming.com/xpmag/whatisxp.htm

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

Описывать как работать с Eventum я не буду, вы можете прочитать об этом на их официальной странице http://eventum.mysql.org/wiki/index.php/Main_Page.

Внедряем SCRUM в существующий процесс разработки

Для этого потребуются некоторые изменения:

• ведения задач в Eventum;
• подсчета времени;
• планирования этапов разработки.

Требования:

• Наличие Backlog;
• Наличие Sprintlog;
• Наличие Tasklog;
• Планирование спринта (Sprintlog);
• Ежедневные конференции;
• Sprint Information.
• Sprint report;

Backlog и Sprintlog

Backlog и Sprintlog — это отдельный Eventum project (скажем Project_Log), который будет содержать все истории для реализации.

История — это не техническое описание задачи. Истории в Backlog заносит владелец продукта. Он же меняет им приоритеты сортирую истории по важности.

Истории помеченные номером спринта владелец продукта менять уже не может.

Все истории в Project_Log будут представлять наш Backlog, при каждом планировании спринта самые важные истории помечаются на выполнение в спринте (специальным номером спринта) и таким образом мы формируем Sprintlog. Номер спринта поможет нам отличать истории текущего спринта от всех остальных.

Каждая история в backlog/sprintlog должна иметь следующие поля:

• номер спринта (поле Category или Custom field) — для указания номера спринта к которому принадлежит история, если история не принадлежит ни одному спринту, то это поле не заполняется. ;
• название (поле Summary);
• описание (поле Description)
• важность (поле Custom field);
• предварительная оценка (поле est. dev time);
• как продемонстрировать(поле Custom field или поле Description);

В Eventum есть специальная возможность создавать «произвольные поля» Custom fields, что добавлет большой гибкости этой системе.

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

Предварительная оценка ставиться владельцем продукта.

Поле «как продемонстрировать» заполняется программистами.

Список историй в Backlog/Sprintlog может выглядеть следующим образом:

• Номер спринта
• Номер истории
• Статус — (Планируется, В процессе, Завершена)
• Название истории
• Важность
• Как продемонстрировать
• Предварительная оценка
• Предварительная дата завершения истории

Во время планирования спринта заполняются следующие поля:

• Номер спринта
• Предварительная дата завершения истории

scrum backlog

Tasklog

Tasklog — является еще одним проектом Eventum (например с названием Projects_task).

Tasklog содержит список технических задач, который создаются на основе историй из Sprintlog.

С помощью поля Associated issues, каждая задача в Tasklog помечается как дочерняя по отношению к истории из Sprintlog. И главное в SCRUM - задачи в Tasklog составляют программисты.

Tasklog список выглядит следующим образом:

• Номер задачи
• Статус — Открыта, Выполняется, Сделана.
• Название задачи
• Assigned — кто ответственен за выполнение
• Estimate dev time - Предварительная оценка времени
• Time spent - Потраченное время

Estimate dev time должно обязательно заполнятся при создании задачи.

Time spent должно обязательно указываться после каждого цикла работ над задачей.

Scrum task log

Планирование спринта

Планирование спринта выполняется каждый раз перед началом следующей итерации разработки, обычно каждые 2-3 недели в зависимости от длины спринта.

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

Оценку проводит вся команда. После начала спринта, в sprintlog новые задачи уже не вносятся и не убираются.

В итоге получается план работ на следующие 2-3 недели. Что является большим плюсом.

Задачи в Sprintlog беруться из Backlog по приоритету важности, чем важнее задача тем быстрее она попадет в следующий спринт.

Задачи вошедшие в спринт нужно помечать номером спринта, таким образом мы можем отделять задачи SprintLog от задач BackLog.

Каждая задача в Sprintlog имеет свои подзадачи в Tasklog, задачи из Tasklog решаются непосредственно программистами, дизайнерами, тестерами.

Ежедневные конференции

Ежедневные конференции требуются для обсуждения текущих задач.

Sprint information

Sprint info — это список всех прошедших спринтов, он соджержит:

• номер спринта
• название
• прогнозируемое время выполнения
• реальное время выполнения
• общую эффективность команды
• участников команды

Для ведения Sprint info хватит обычной wiki.

Sprint report

Sprint report - это текущее состояние дел по текущему спринту.

Scrum dashboard

В итоге

В итоге мы получаем:

• Спланированный график работ
• Каждый знает что ему делать
• Есть дата окончания спринта — следующего релиза
• По оценке предыдущих спринтов мы будем знать эффективность нашей команды и каждого ее участника в отдельности, это даст нам возможность планировать нашу работу более точно в будущем
• В конце каждого спринта каждый участник должен продемонстрировать выполненное им задание, что требует от разработчиков дополнительной ответственности за выполнения задания. Демонстрация проводится перед все командой.

Интересная статья описывающая важность умения читать код и документации.

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен. Однако, возникла некоторая загвоздка – CQG не являлось приложением баз данных, основанном на комбинации готовых сторонних технологий, таких как MS SQL сервер, Visual Basic, Delphi, JavaScript, и 1C – к которым я привык. Меня потряс объем приложения – почти 50 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.

Это был действительно серьезный и успешный программный комплекс, разрабатывавшийся десятками людей на тот момент на протяжении десяти лет, целиком написанный на С++, со своим собственным специализированным сервером БД, собственным встроенным языком программирования, собственным толстым клиентом, умеющим все, что может и не может пожелать трейдер, отказоустойчивый, работающий в реальном времени, сервера которого развернуты на ферме из сотен компьютеров и обслуживали порядка десятка тысяч пользователей одновременно.

Задание, которое мне было выдано, предполагало модификацию движка обработки данных и сервера, подкупало своей простотой, и практически свело меня с ума – завершить его я смог только через 7 месяцев после начала работ, после того, как прослушал лекции по архитектуре данного комплекса. Что характерно, после лекций пришлось выкинуть все, что я написал до них, и за два месяца сделать правильно.

В этот раз, перед тем, как что-либо писать, я предусмотрительно показал свой предварительный дизайн (подход к решению проблемы) Толу Корину (Tal Korin), автору и главному архитектору данной системы, и он направил меня в правильном направлении. У Тола ушло на это 5 минут. Это был первый случай, когда я сам инициировал дизайн-ревью (не зная, как оно называется), и был рад найденным у меня проблемам. После успешного выполнения данного задания я поступил в распоряжение Тола Корина, поскольку, с его слов и к моему безмерному удивлению, я оказался одним из немногих, кому пошли впрок лекции по архитектуре.

Каких-либо иллюзий на свой счет, меж тем, к тому моменту у меня уже не осталось – я понял, что цена всем моим знаниям, университетскому образованию, и опыту – ломаный грош. Меня поражал простой факт – я был объективно образован в Computer Science гораздо лучше Тола, и _знал_ больше. При этом, и, после некоторого опыта работы, я был в этом абсолютно уверен – я бы не смог спроектировать и реализовать такую систему за год, как это десять лет назад с одним помощником сделал Тол. Сложность системы явно превосходила мои возможности - я бы по ходу работы закопался в деталях. И уж тем более, у меня не получилось сделать систему так гибко, чтобы она прожила 10 лет, и была до сих пор адекватна ситуации.

То есть, до меня начало доходить, что есть нечто очень важное, что совершенно перпендикулярно университетскому образованию, чего нас просто не учили даже замечать. Оно перпендикулярно «дизайн-паттернам» и книгам по ОО проектированию. И оно, это нечто, у Тола есть, а у меня – нет. Если мои знания не могут мне помочь сделать такую систему – то много ли они стоят? Понимание и знание требуется для действия, ни для чего другого – это не китайская декоративная ваза.

С этого момента я начал внимательно наблюдать за Толом, изучать его решения и подход, и твердо решил разобраться, что же это такое за неуловимая штука, которой я не понимаю. То есть, я «записался в ученики», и Тол с удовольствием взял роль наставника. И за несколько лет Тол сделал меня инженером, показав мне на практике, что это такое, и за что я ему буду всегда благодарен.

По большей части это напоминало дзен, когда вам дают задание, разрывающее мозг, вроде хлопка одной ладонью, и через некоторое время вы неожиданно ловите просветление. Удивительный опыт. Вот один небольшой пример, на что это было похоже.
- Тол, скажи, а как работает вот эта штука.
- Влад, вот этого я на самом деле не знаю. А ты почитай код, и разберись!
- Тол, ты издеваешься надо мной?! Здесь пятьдесят мегабайт этого гребанного недокументированного кода! Ты знаешь все Тол, и это ни для кого не секрет.
- Хорошо, смотри, – не стал спорить Тол, - Я тебе говорю – я не знаю, и поэтому я должен сам почитать код, чтобы ответить на твой вопрос. Поэтому, я открываю код.
Тол открывает правильный файл в одну попытку, продираясь через файловую систему, не пользуясь класс-браузером, мотает файл в правильную середину.
- Так. Ты сказал, вот эта фигня? Вот, открыл. Так… Тебе нужен вот этот метод. Читаем. Вот, смотри, он вызывает вот этого парня (так Тол называл классы и объекты – look – now this guy tell that guy to do this thing). Видишь? Вот, происходит тут то-то и то-то. Все просто.
- Спасибо, Тол! Теперь все ясно. А говорил – не знаешь!
- Я тебе говорю – код читай, блин! Все то же самое ты можешь сделать сам!
- Тол, ну в нем же нихрена не понятно без документации, - сказал я, будучи совершенно уверен, что я не смогу сделать того же сам. Происходящее напоминало ловкий фокус.
- Тебе, чтобы читать код, нужна документация? Прости – какая?
- Ну, там, диаграммы классов, например.
- У нас была одна, вроде, составленная лет пять назад. Она сейчас, мягко говоря, не соответствует действительности. Сам понимаешь, у нас 50 инженеров, и разработка идет очень активная. Но если ты уверен, что она тебе поможет, я могу поискать, – участливо смотрит на меня Тол, - ну так что, искать?
- Не, устаревшая, мне, пожалуй, не поможет, - подумав, ответил я, - это ж я все равно должен весь код изучить, чтобы понять, где ей можно доверять, а где нет.
- На самом деле, я не уверен, что тебе сильно поможет даже новая, и поэтому я тебе и говорю: код – лучшая документация! – терпеливо разъясняет Тол, - Она _всегда_ актуальна, и _никогда_ не устаревает, помимо того, что более информативна чем диаграмма классов, конечно.
- Хорошо, я понял, а может, ты мне еще объяснишь, вот в этом месте как работает…
- Нет. Это ты мне объяснишь, после того, как прочтешь. Мне как раз надо скоро будет туда правки вносить. Давай, парень, я не тебя рассчитываю. Иди - читай код.
- Хорошо, Тол, – обреченно сказал я, и пошел читать код.

Да, надо сказать, я тогда немного обиделся на Тола, я думал, что он нифига не понимает. И долгое время считал, что он был не прав. Как-то года через три ко мне подошел коллега, с вопросом. Я был утомлен от работы, голова соображала вяло. К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

- Слушай, Влад, не поможешь, объясни, как работает вот эта подсистема?
Я вяло поднимаю глаза на коллегу, вижу безнадежность в его взгляде, тяжело вздыхаю, и решаю ему помочь. Хоть я ничего и не понимаю в этой подсистеме – так, рядом проходил.
- Хорошо, смотри, – тут я «вслепую», без всяких класс-браузеров, продираюсь к «правильному» файлу, открываю его, и поиском нахожу нужный метод, - видишь, вот здесь что происходит?

Я читаю код, без труда восстанавливая логику поведения и структуру программы в уме, и одновременно простыми словами объясняю это коллеге. Тут у меня в голове что-то перещелкивает, и я с изумлением вспоминаю наш разговор с Толом трехлетней давности, сознание у меня как бы раздваивается, и я наблюдаю за собой со стороны.

- Вот, видишь, как все просто, - заканчиваю я. И к своему чудовищному удивлению добавляю, то, что надо сказать, потому что это правда:
- А вообще - читай код. Код – лучшая документация. Ты вот думаешь, я разбираюсь в этой подсистеме? Нет, я этот код вижу в первый раз, так же как и ты.
- Но этот код совершенно не документирован! Диаграммы хоть какие-нибудь бы!
- Смотри, - говорю я улыбаясь, окончательно осознавая, что Тол в очередной раз, как и всегда, оказался прав, - вот я запускаю Rational Rose, где у меня всосана вся наша система в режиме reverse engineering, и бросаю на чистый лист эти пять классов. Видишь? Вот тебе свежая, актуальная диаграмма. Какой смысл тратить усилия на документирование того, что устаревает за год, и может быть в любой момент восстановлено за пару минут? Если она тебе сильно поможет, я сейчас ее тебе распечатаю. Распечатать?
- Да нет, пожалуй, - задумчиво отвечает коллега, рассматривая диаграмму. Ясности она не добавляла.
- Вот. Диаграммы не стоят ничего, ценны мыслительные процессы, происходящие у тебя в голове в процессе их составления. Поэтому я и говорю: код – лучшая документация. Читай код.

Разумеется, Тол хотел мне показать не только и не столько практическую бесполезность проектной документации, как это могло показалось на первый взгляд. Философия “код - лучшая документация” дает гораздо большее, чем отсутствие документации. Это необходимое ограничение, только приняв и осознав которое, и в результате - рассчитывая только на свои силы, понимая - что код - основной источник информации, его нельзя боятся, с ним надо столкнуться в лоб, и этого не получится избежать, обойти, и перепрыгнуть, - можно достичь мастерства в reverse engineering и вообще понять, что это такое.

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

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

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

Оригинал статьи здесь: http://gaperton.livejournal.com/32772.html

Существует несколько способов проверить наличие таблицы в базе данных с помощью zendframework.

Первый и самый простой это использовать функцию listTables из Zend_db, но у этой функции есть ограничение, она получает список таблиц только текущей базы данных.

Например вам надо узнать существует ли таблица my_table в подключении к текущей базе данных:

$db = $this->getAdapter();

$tables = $db->listTables();

if (in_array(’my_table’, $table)){

//todo something with table

}

listTables() возвращает массив имен всех таблиц в текущей базе данных.

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

Пример:

$db = $this->getAdapter();

$sql = “show tables from any_db like ‘my_table’ “;

if ( $db->fetchOne($sql) ){

//todo something with table

}

fetchOne() вернет строку с именем таблицы, если таблица будет найдена, если ничего не будет найдено, то будет возвращена пустая строка.

С помощью приема с show tables можно проверять на существование одной и более таблиц, что делает этот прием более универсальным.