<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Вкратце расскажу наш путь к Agile… За чашечкой чая в одно прекрасное утро подумали, что стало скучно работать в полном хаосе и пошли гуглить…
Начинали сначала с чистого «КАНБАНа». У каждого отдельная доска, только со своими задачами. Реализовали и на доске и в своей CRM. Аналитиками бросались задачи на конкретных разработчиков или в общую корзину. Вначале по правилу «кто первый встал, того и тапки», то есть кто-раньше поставил задачу, ту задачу быстрее брали в работу. Вначале все было достаточно хорошо. Но кампания росла, и в такой адаптации уже не помогало, а зачастую мешало работать. Стало не хватать адекватного планирования…(чтоб хоть банально закрыть вопрос со сроками, которые озвучивать заказчикам). В итоге прикрутили приоритеты к задача — тоже мало.
Начали внедрять Scrum со всеми артефактами (user story, спринтами, ролями, доской, и т. д.).
Тяжело было вначале донести людям (те, с которыми поднимали Канбан, давно слились), которые привыкли работать в хаосе и постоянно в режиме хотфикса… Пришлось даже пенделей отвесить некоторым: вроде собрались, замутили спринт, на выходе — спринт мертвый… почему… не понятно, чего от них хотят… Собрались, еще раз объяснил, что Scrum, в первую очередь, — это командная работа… Вроде прислушались… Второй спринт взлетел… В итоге работает несколько команд на проектах.
С дежурным хорошая идея, тоже пытался, чтоб был человек дежурный на второй линии поддержки, если первый уровень не справляется. Тяжело пошло… продукты разные, проекты тоже… (от розницы до автотранспорта)… и универсальных бойцов мало…
По итогу:
Scrum завелся, разработка на проектах.
Вопрос поддержки — два уровня… если первый не справляется то задача прогерам.
Борюсь с офисной мудой — чтоб прогеры меньше отвлекались на вопросы аналитиков и консультанотов (особенно если они вообще не по теме)
Видимо меня заминусуют, но я не вижу реальных плюсов от новой схемы. Трекер + приоритеты решали бы все описанные проблемы на ура, а так удлинили цикл разработки и увеличили время на планирование и сопутствующие вещи, что в итоге выльется в падение производительности людей, которые будут отвлечены от работы занесением дополнительных аналитик в новую систему.
Вопрос саппорта решается выделением времени сотрудников на этот самый саппорт с ведением длинных тикетов, которые имеют шанс перейти на другого сотрудника, в трекере.
Вопрос взаимовлияния разработки решается либо наличием архитектора системы, либо документированием аналитиками.
Так к чему же эта работа ради самой работы?
ПС: это не попытка наехать на автора, скорее вопрос, обусловленный личным негативным опытом, когда внедрением подобной схемы закончилось развалом команды (из 12 работников отдела ИТ 10 покинули компанию, при этом ни одна из заявленных новым РП целей не была выполнена в срок, что было объяснено старыми кадрами, но даже набор новых не дал результатов, все как в анекдоте про 3 конверта)
Полезные статьи по Agile-разработке —
Расскажите, пожалуйста, насколько возросла скорость разработки в попугаях за время использования скрама?
Вот, наконец то статья с нормальными практическими примерами, а не чистая теория…
вот в этом, ребята, ваша проблема. Вы боитесь общаться с народом.
и да, не могу не оставить это здесь:
«SCRUM или шабаш ведьм»
(2)
Если мы говорим о порелизной разработке, то гибкие методологии удобнее, чем приоритеты.
+ при наличии сильно изменяющихся требований они дают определенные плюсы. Мы же выкатываем почти всегда законченную функциональность
И очень сильно зависит от культуры команды. Если люди не понимают какие проблемы такие методологии решают, то они и не зайдут
(7)
«SCRUM или шабаш ведьм»
вы сами что думаете про то, что написано по этой ссылке?
(4) Давно все это было. Скорость «в попугаях» плавала, то росла, то уменьшалась. Сейчас не отвечу на этот вопрос.
Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.
(5) Спасибо. Это стенограмма с выступления.
(6) Вы немного ошибаетесь. «Боитесь» это не то слово. Просто разработка и поддержка это немного разные виды деятельности и не все могут мгновенно вынырнуть из отладчика, ответить на вопрос «почему у меня не проводится реализация», а потом так же быстро погрузиться обратно в отладчик.
Именно с таким дроблением времени и была призвана бороться пожарная машина. Ну, а что описал я это с иронией словами «несчастный» и «обречен», так в любом даже самом серьезном деле есть время «погыгыкать».
(7) Я могу вам еще одну ссылку дать, тоже интересную —
Критика методологии была очень популярна в начале, когда она только приборетала популярность. Более того, была обоснованной, так как были ошибки, неопытные scrum-мастера, scrum тулили где он нужен и не нужен и даже делали все совершенно противоречащее принципам agile, называли это agile и жаловались какая гадость этот scrum.
Сейчас совершенно очевидно, что
методология работает,
проекты делаются успешно,
пытаться всунуть ее где надо и не надо не следует,
успешно начать работать по scrum получится более вероятно у той команды, которая в принципе готова работать, следовать правилам и по необходимости менять их разумно, не доводя до идиотизма, чем у тех, кто не заинтересован в этом.
А значит, успешные проекты на scrum не столько заслуга самого scrum, сколько команды или начальства или scrum-мастера, которые могли бы выбрать и какую-то другую практику взаимодействия или даже придумать совершенно собственную и все бы так же получилось.
И да, сейчас я не использую гибкие методологии, потому что в конкретно данный момент не вижу это для своей комманды целесообразным. Однако, как только понадобится, я с удовольствием снова ими воспользуюсь.
Люди, откуда у вас столько времени, чтобы заниматься этой фигней?
(12) вопрос отношений
(10)
Два вопроса, если позволите:
1. Управляемость и прогнозируемость процесса разработки вы как-то измеряли? Как определили, что они повысились?
2. Почему вы назвали это «главным»? Оно было главным изначально, как цель? Или стало главным в итоге, как лучший из полученных результатов?
Спасибо.
(10)
А вот и момент истины. То есть, все вышеописанные прыжки и гримасы выполнялись исключительно ради собственного удобства внутренней группы айтишников, и никак — подчёркиваю, никак — не принесли пользы бизнесу, за счёт которого айтишники кормились и чьё время, по сути, тратили на эту фигню. Поясню: управляемость — это очень красивое слово, за которым не стоит ничего. Ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства, ни мониторинга занятости. Управляемость. Волшебное нечто из лексикона всяких коучей… Прогнозируемость — это очень смешное слово. Требования бизнеса априорно непредсказуемы, т.к. это всегда может быть как задача рынка, так и шлея под хвостом гендира или главбуха. Прогнозировать разработку это как угадывать цены на нефть. Заложите худший сценарий и может быть частично угадаете, но всегда без конкретики.
А самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась. Вот и видим, что служебное сервисное подразделение вместо полезной деятельности занималось какой-то самоценной, пардон, фигнёй. Да ещё и на статьи об этом время тратють… Непорядок, робятки, с точки зрения гендира — явный непорядок.
Интересно, долго этот сферический в вакууме просуществовал? Долго ли придерживались сиих положений?
(14)
1. Повышение управляемости стало очень заметно заказчику. Мы не вели «количество положительных отзывов» как исчисляемую метрику, но улучшение было видно «невооруженным взглядом».
После внедрения заказчики (руководители профильных департаментов, например) начали получать достаточно точную информацию о том, в какие сроки будет реализован тот или иной запрашиваемый функционал, против «ну, будет готово когда-нибудь, как будет готово».
Получив доступ к бэклогу и возможность присутствовать (по желанию) на митингах, стали понимать какая фича находится в разработке в данный момент, какая запланирована в эту итерацию, а какая отложена до следующей. Что в конечном итоге привело к пониманию, какие требования и задачи менять уже нельзя, а где еще можно сказать «я передумал, давайте тут поменяем, у вас оно все-равно на следующую итерацию запланированно».
Присутствуя на демо заказчики могли видеть получившийся результат и могли тут же внести в бэклог какие-то новые требования, корректировки на следующую итерацию. А не получали обратную связь уже от конечных пользователей, когда тех уже «достала эта тупая 1С».
То-есть разработка стала более понятной и прозрачной для заказчика и как следствие, заказчик получил возможность этот процесс _разумно_ «направлять» в русло интересов бизнеса, в конце-концов.
(14) Про управляемость процесса внутри комманды писать не буду, сам Scrum достаточно хорошо и красиво описывает это. Митинги, ретроспектива, доска — все это иструменты упорядочивающие отношения внутри команды и во многих статьях про это и так уже сказано.
(15) Я думаю, что вы противник agile-подходов, что нормально. Agile не серебрянная пуля и не обязан всем нравится.
Но пришли вы в комментарии к статье не для того, чтобы узнать что-то новое, а для того, чтобы:
Зубоскалить:
«долго этот сферический в вакууме просуществовал?» — вам же на самом деле не интересно долго или нет.
Додумывать за топикстартера:
«и никак — подчёркиваю, никак — не принесли пользы бизнесу» — это не так, почитайте (16).
Говорить провокационные глупости:
«самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась» — очевидно, что скорость создания никому ненужного функционала никому не принесет пользы. Вопрос не в том «как быстро», а «делаем ли мы то, что нужно».
Демонстрировать полное незнакомство с вопросом, типа «слышал звон»:
«ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства» — это все, что вы опровергаете, заложено в 12 принципов agile и метолологии.
Без фрагментации невозможно планирование и нормальное ведение бэклогов. Для контроля есть дэйли-митинги, для прозрачности — демо. И еще много чего. Начните хотя бы с этого —
Боюсь, нам с вами не по-пути.
(14) 2. Да, это изначально было основной целью. Скорость все-таки была на втором месте.
Во всех этих играх с Agile важно, чтобы ваш заказчик знал, понимал и участвовал в процессах планирования и демо. Нужно объяснить сотрудникам заказчика, что задачи выполняются по приоритету, приоритет вот это бэклог и что надо, как-то в него заглядывать а не строчить гневные письма типа когда вы это сделаете.
Очень похоже на нашу историю, но у нас еще куча нерешенных проблем =) Есть и отличия:
Дежурный у нас меняется ежедневно;
Продукт один, эпиков много и они относятся к разным бизнеса;
Для оценки в «Попугаях» решили ввести список эталонных задач;
Вместо инженерного дня у нас под технологические задачи выделено отдельное количество SP в спринте;
Мы зависли в переходе от оценок Tasks к User Story, но уже понимаем, что надо когда берем в спринт User Story делить ее на кучу Tasks, одна из которых будет документация…
(18)
Эдак Вы лихо решаете за других, что кому интересно и что кому нет. За своих клиентов так же уверенно решаете?) Если я спросил, значит, интересно. Я статистику провалов веду — ну, если кто вообще признаётся. Обычно это выдыхается и вырождается в пределах года. Что, хватит духу сказать, сколько прожил более-менее полно внедрённый подход? Или увильнёте?
Супер. На момент моей реплики (16) ещё не было, но спасибо за отсылку. Теперь по делу: Вы понимаете, что никакие сроки реализации не имеют смысла, т.к. всегда есть нечто супер-срочное и сверх-горящее? И что это именно сферический конь в вакууме? Насчёт прозрачности соглашусь, только это никому не интересно, на самом деле. Менеджеру плевать, что он может узнать, чем занят программер. Менеджер хочет, чтоб программер всё бросил и реализовал менеджерскую хотелку) Так что в изрядной мере тоже самоцель, юзерам мало интересная.
Стоп-стоп-стоп. Вы ж сами сказали, что скорость не выросла. Не путайте тёплое с мягким. Если Вы под «то, что нужно» подразумеваете внутренний самоконтроль группы разработчиков, то это вопрос даже не управления проектом, а чёткости поставленной задачи (ТЗ) и профессионализма исполнителей.
В теории — может быть. На практике, повторюсь, сперва пафос, а после пшик и проблемы. Я говорю от чистой практики.
А вообще, выбранная Вами тональность и конкретные фразы на грани оскорбления похожи либо на толстый троллинг, либо на классическое оскорблённое величество Господина-Бизнес-Консультанта. Видал я таких, и не раз.
Я тут Вам немножко изобразил реакцию прагматика на всякие заумные изыски, притом, что нужда в решении заявленных вопросов безусловно есть. А Вы грубите. В общем, нашей группе компаний эту методологию в своём изложении Вы, увы, не продали)))
(20) Заказчик не будет никуда заглядывать. Вы можете предоставить сотни удобнейших бэклогов, равно как и любых иных средств мониторинга процесса. Заказчик, а особенно внутреннее руководство, хочет простых вещей, чтоб всё и побыстрее. И если заказчик вдруг узнаёт, что вместо экстенсивного роста скорости выполнения работ исполнители заняты какой-то малопонятной внутренней интенсификацией с каким-то эйджилом, то единственная реакция, нормальная бизнесовая реакция, такова: «вам что там, делать нехрен?». А сотрудники заказчика будут в меру своей скандальности орать, что всё просрочено, ничего не работает итд.
Как вы не поймёте, что тут вообще главное другое. Что никому, кроме вас самих и вашей группы разрабов, не интересно всё это и бесполезно. Что эмоциональный неадекват истеричных заказчиков, которые в сети ужастиков начитались, визита ФНС испужались, чё-то где-то слышали от знакомых итд, никак не коррелирует с вашей «прозрачностью и управляемостью», и единственное, чем его можно перекрыть — силовой административной поддержкой либо сверхбыстрым выполнением ВСЕХ задач СРАЗУ. И в том, и в другом случае всё вышеопубликованное в лучшем случае страдание фигнёй. В худшем — нецелевая трата времени и сил. Году, помнится. в 2002-м одного такого при мне вышибли с его группой коллег, с треском. Из достаточно крупной телекоммуникационной конторы. Потому как он на вопросы главбуха про какие-то спринты рассказывал, а «у него крыжики и краснота». Будьте реалистами, коллеги.
(23)
Agile и создали реалисты. Нужно просто правильно применять эти методики в реальной жизни. Насколько я понял сейчас эта фишка среди 1С стала очень популярна, при это люди толком не понимают, а что же это такое на самом деле, вот и вылезают проблемы о которых вы говорите. На самом деле именно Agile и помогает работать с не адекватными заказчиками, главное что бы команда которая для себя выбрала именно эту методику должна точно оценивать риски. Одна команда не сможет одновременно и писать продукт и поддерживать его, проект развалится очень быстро.
(22) Если вам нужны ответы на вопросы, приходите в личку. Расскажу все что знаю. Кстати, у меня к вам тоже есть несколько вопросов.
Но я думаю, что вы скажете что-то типа «а что нельзя ответить мне в комментариях?» и в личке я вас не дождусь, потому что вы тролль и вам не важно получить информацию и новые знания, а важно публично провоцировать участников обсуждения.
В личку пришёл. Если хотите слегка пооффтопить прямо тут — с 03.09.17 буду к вашим услугам.
Знаете, очень забавно выглядит, когда абсолютно (подчёркиваю, абсолютно) все виденные/читанные мной проповедники подобных систем, будучи предметно спрошены о конкретном выхлопе, впадают в тот или иной неадекват и пытаются прекратить общение.
Я вот вас спрашиваю: что получил бизнес, кроме прозрачности? Вы стали успевать втиснуть критическую задачу между плановыми так, чтобы их сроки не сдвинулись? Вы распределили ресурсы так, что разработчики перестали трудиться сверхурочно при факапах?
А самое главное, что никакие обвинения в троллинге не способны опровергнуть зримый и ощутимый опыт. Опыт стабильного провала всех этих эйджил-заумей. Когда руководители проектов и отделов доводили всё до полнейшего трындеца и, извините, мне сотоварищи приходилось своим горбом вытаскивать проекты. Когда приходилось при всей этой красотени лично вправлять мозги заказчикам и терпеть их матюки. Когда отбирали премию именно потому, что мы «вместо работы всякие хрени сами себе внедряем». Когда, наконец, 1С триумфально внедряет Agile и качество платформы, начиная с 8.3.7, падает ниже плинтуса, каждый релизит своё, багтрекер живёт своей жизнью, ранее исправленное всплывает опять, и с подблоками внутри платформы бардак полнейший.
Опыт, он штука такая. Факт есть факт.
(26) Ответил в личку.
(27) Ответил в личку.
(29) Жаль, что в личку. Работа с возражениями — очень интересный навык 🙂
(30) Если в личной переписке станет понятно, что я ошибся и уважаемый Яков Коган не тролль или, возможно, у нас в беседе будут важные мысли в тему публикации, то мы обязательно вернемся в комментарии. До тех пор треду лучше обойтись без наших препирательств.
Заметьте, я высказался по публикации, а автор — по моей персоне. Разницу ощущаете?)
(32)Ну и чем все закончилось, мировая или ошибки ни кто не хочет признавать?
(33) Довольно конструктивно пообщались в личке, пришли к выводу, что «стороны опубликуют совместное коммюнике», на этом всё и зависло. Работа не волк, работа «ворк». И я замотался, и Александр, видимо, тоже.
(33) (34) Так и есть. Насыпало работы и разъездов.
При первой же возможности итоги опубликуем.