Имя: Пароль:
1C
1С v8
Наслоение переделок программы и ошибки из-за этого
, ,
0 r1000
 
30.06.14
12:20
Вот уже который год мы дописываем программу для одного клиента. Пишем мы хорошо, его все устраивает, а вложения в автоматизацию полностью окупаются. Но все постоянно меняется - меняется бизнес, люди, время. И программы должны меняться. Вот мы и дописываем постоянно программу. Но так выходит, что одни доделки накладываются на другие, другие доделки сводят на нет что-то еще. И в голове просто невозможно удержать объем сделанного и уже забываем чего сделали неделю назад. При поступлении новой хотелки, просто невозможно налету оценить, не повредит ли реализация оной где то в другом месте программы. А получается оценить только после того, когда уже сделаем(ибо все процессы максимально автоматизированы и взаимосвязаны). Чего с этим делать ? Взять в штат пару человек, которые будут тестировать полный круг после внесения изменений ?
1 Asmody
 
30.06.14
12:23
объявляется тестосрач!
2 Бешеная Нога
 
30.06.14
12:24
выстроить работу правильно, вот что надо сделать
3 Бешеная Нога
 
30.06.14
12:25
и "оценивать и тестировать" надо до начала разработки и не после внедрения
4 r1000
 
30.06.14
12:28
(2)Она выстроена правильно.
5 ChiginAV
 
30.06.14
12:29
(0) "забываем чего сделали неделю назад"
Комментируйте код: дата, кто ставил задачу, кто выполнял, кратко суть (если по коду не понятно)
6 FullMoon
 
30.06.14
12:30
(0) Разруха в головах, а не в клозетах (с)
7 User_Agronom
 
30.06.14
12:31
Документировать доделки по каждому объекту.
Ну и стараться решить штатными методами, не ломая логику поставщика конфы. В большинстве случаев это возможно.
8 eeeio
 
30.06.14
12:31
(0) может документирование поможет + в коде ссылки на пункты в документации, для которых писался код
9 Armando
 
30.06.14
12:31
(1)  дада))
(0) пишите автотесты
10 samozvanec
 
30.06.14
12:32
(0) такая же беда. пока решили запилить вики с тэгами, чтоб было видно пересекающиеся механизмы
11 Dionis Sergeevich
 
30.06.14
12:33
Журнал доработок. Кто, когда, задача, какие объекты и где именно были изменены, какие механизмы были изменены (по каким условиям). Перед доработкой имеющегося объекта или механизма можно посмотреть список изменений сразу. + может быть есть смысл использовать хранилище
12 vde69
 
модератор
30.06.14
12:33
самый ПРАВИЛЬНЫЙ способ избежать сабжа - поддерживать пользовательскую инструкцию в актуальном и полном состоянии.
13 r1000
 
30.06.14
12:34
(5)Да там дело не в коде. А в пересечении "хотелок" глав подразделений, а их около 12 человек. Владельцы бизнеса просят, чтобы мы взяли на свой контроль ситуацию по пересечению интересов подразделений, связанных с программой. Ну банальный пример - ограничение прав доступа.
14 vde69
 
модератор
30.06.14
12:34
еще можно делать файл хоз операций с конкретнтыми проводками.

так сказать технологическую карту...
15 ChiginAV
 
30.06.14
12:42
(13)
1. НачОтдела1 просит изменить Объект1
2. Смотришь по правам, что этим объектом пользуются Отдел2 и Отдел3
3. Идешь к НачОтдела2 и НачОтдела3 и обсуждаешь с ними хотелку НачОтдела1
4. Приходите к общему решению
16 r1000
 
30.06.14
12:46
(15)Это пипец как затянет и излишне забюрократизирует работу. И мы и наши клиенты привыкли к мобильности. Да и не посмотреть  все досконально что затрагивает - много настроек пользователей, много профилей и т.д. и т.п. Без прохождения полного круга БП получается невозможно, но это еще 2 человека нужно и обучить их еще нужно.
17 Segate
 
30.06.14
12:49
(16) это называется согласование. и это норма(с)
18 ChiginAV
 
30.06.14
12:52
(16) "не посмотреть  все досконально что затрагивает"
Роли + Поиск ссылок на объект + глобальный поиск по тексту = 100% что и кого затрагивает
19 Сияющий Асинхраль
 
30.06.14
12:53
Да, перделки - они такие :-(, всегда наслаиваются...

А в реальности делается это просто, надо, чтобы за все изменения в программе отвечал ОДИН человек, причем, по возможности не программист, а человек клиента, и, соответственно, чтобы начальники отделов шли не напрямую к программистам, а к этом единственному человеку, который заведует всем этим хозяйством. Сам работал на таком проекте, таким человеком был ГБ, через него все и решалось...
20 eeeio
 
30.06.14
12:56
(19) т.е.перевалить контроль на заказчика
21 MSII
 
30.06.14
12:59
(19) Причем этот отважный герой должен обладать полномочиями послать проект любой новой хотелки на... доработку.
22 Бешеная Нога
 
30.06.14
13:01
(4) БУГАГА
23 Рэйв
 
30.06.14
13:03
(0)Сами бардак наводите, потом слезы на мисте льете за пожалеть..
24 Сияющий Асинхраль
 
30.06.14
13:17
(20)-(21) Именно так, причем по своему опыту могу сказать, что все это очень неплохо работает, конечно полномочия у этого одного человека должны быть действительно достаточны для того, чтобы послать заказчиков в баню, подобных полномочий у обычных программистов быть не может по определению, а без них нормальную работу в базе не построить никаким образом...
25 vde69
 
модератор
30.06.14
14:03
(24) у меня такие права уже лет этак 15 есть :)

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

И все хотелки согласуются именно с этим руководством...
26 ildary
 
30.06.14
14:10
а) "Мы хотим навести порядок"
б) "Мы хотим сохранить быструю /мобильную работу"

Выбирайте любой из этих пунктов, но не оба сразу.
27 РенеДекарт
 
30.06.14
14:21
(25)"у меня такие права уже лет этак 15 есть :"
права согласовывать перделки? ))
28 Сияющий Асинхраль
 
30.06.14
15:13
(25) С чем и поздравляю, но если прочитать сабж, то дословно: "мы дописываем программу для одного клиента". Мне очень сильно кажется, что данная фраза означает, что эти самые "мы" работают по договору и я очень сильно сомневаюсь, что программисты работающие по договору могут послать заказчика в сад, потому что это разрушает логику реализованную в программе. Да и руководство пользователя, даже если оно имеет место быть, вряд ли сторонний программист может заставить прочитать пользователей, я уж не говорю о том, что составление этого самого руководства по времени занимает не меньше, чем написание кода, а оплачивать его стороннему программисту вряд ли кто будет...
29 vde69
 
модератор
30.06.14
15:16
(28) когда я работал во франче я посылал в лес несуразные задачи например ГлавМосСтроя.

Единственное отличие, что мотивировку нужно более тщательно готовить...
30 vde69
 
модератор
30.06.14
15:18
(29)+ Или для примера компанию "Виктори" (кто в теме - знает), для них я делал вообще мимо их заявок, но когда показывал - брали мое а свои задачи снимали...
31 Сияющий Асинхраль
 
30.06.14
15:20
(29-30) :-) - Завидую!!!
32 acsent
 
30.06.14
15:23
(31) Завидуешь работе с неадекватными клиентами?
33 Господин ПЖ
 
30.06.14
15:25
(0) покрывайте все тестами
34 Сияющий Асинхраль
 
30.06.14
15:37
(32) Завидую, что клиенты достаточно адекватны, чтобы признать свою неправоту, мои попытки некоторым своим клиентам сказать нечто подобное вызывали ответ, дескать, вы или программируйте, или мы других программистов найдем, конечно, долго с такими не уживался :-(
35 Karavanych
 
30.06.14
15:58
(0) Я видел как 2 раза решили эту проблемму.
В первом случае - все хотелки согласовывал 1 человек.
Во втором случае - был создан отдел методологии, который тоже согласовывал все хотелки и вел документацию.
Честно говоря во втором случае работать мне было работать программистом прям в кайф в каком-то плане.
Во всех остальных случаях - дальше разговоров решение этой проблемы не шло. Поговорили, решили что программисты виноваты все ломают и забыли.
36 r1000
 
30.06.14
16:18
(33)Единственный вариант. И это существенные дополнительные затраты для клиента. Нужно будет подумать над грамотным обоснованием.
37 ИС-2
 
naïve
01.07.14
07:05
(0) сколько человек работает в команде?
Когда работал во франче работал принцип трансляции - когда ставили задачу одному прогу, весь отдел слышал про задачу и мог ее скорректировать.

Думаю лучше всего провести обследование перед выполнением задачи
38 дедушка Вах
 
01.07.14
07:20
прибить все хотелки под выход новой типовой по предварительной договоренности - больше половины как правило уже не надо, а про вторую половину может никто давно и не знает
39 vde69
 
модератор
01.07.14
07:46
(38) это очень сложно, и ни один франч не пойдет сам по пути упрощения конфигурации и приведению ее к типовой.

ты-бы предложил еще спислить сук на котором сидит 10 дармоедов :)