1. Геймификация
1.1. http://www.slideshare.net/agiledays/ss-19558792
1.2. Цели
1.2.1. Уменьшает разобщенность
1.2.2. Повышает вовлеченность
1.2.3. Понимание куда идти
1.2.4. Обратная связь
1.3. Не обязательная чистая геймифкация, геймификация может бысть гибкая и настраиваемая под конкретную команду
1.4. Направленность на команду и никак не на конкректных членов, иначе будем поощрять эгоизм внутри команды
1.5. Как это можно устроить
1.5.1. Есть заказчик, он наш клиент, враг и бог и мы боремся с ним помогая решить его проблемы, он нам подсовывает миссии и наша цель пройти миссию быстрее с наименьшими трудностями
1.5.2. Были идеи по поводу проставления плюсиков тем людям, кто тебе помог так или иначе в течении недели, потом он получает определенные бонусы. Это можно попытаться обыграть через геймификацию
1.5.3. Лидерборд конкретных команд, будет работать тогда, когда команды можно будет сравнивать между собой, то есть, например, метрики качества будут вестись по большему количеству команд
1.6. Теория поколений для понимания того, что нужно сотрудникам (поколению Y) от руководителей (поколений X) - максимально быстрый фидбек
1.6.1. http://www.advertology.ru/article48762.htm
2. Расширяемость PostgreSQL
2.1. http://www.sai.msu.su/~megera/postgres/talks/PostgreSQL_extensibility_hackers_and_architectures.pdf
2.2. Тезисы
2.2.1. Как писать свои расширения для PostgreSQL на примере hstore
2.2.2. Ответы на вопросы почему надо использовать PostgreSQL и необходимость использования "костылей"
3. Наш путь от 90 до 3.5к тестов, СКБ Контрур
3.1. http://www.slideshare.net/ivan816/selenium-camp-2013?ref=http://seleniumcamp.com/materials/many-tests/
3.2. Тезисы
3.2.1. Используют Selenium и функциональные тесты
3.2.2. Отказались от тестов на всех бразуерах, так как, например, проверка на ie занимает 5 часов. Тестят только на Google Chrome
3.2.3. Хром переодически падает и поэтому они его рестартуют по крону
3.2.4. Чтобы не ждать долгого выполнения тестов сами подтюнили TeamCity для параллельного запуска тестов на нескольких машинах
3.2.5. Установили большой монитор с ходом выполнения CI в видимом для всей команде месте
3.2.6. QA в команде с девелоперами
3.2.7. Всегда есть дежурный инженер, который чинит и разбирается в упавших тестах. Переходящая должность из итерации в итерацию
3.2.8. Релизы не реже чем раз в месяц
4. Ментальное программирование
4.1. http://www.slideshare.net/khokhlova1991/ss-19053261
4.2. Тезисы
4.2.1. Философия python
4.2.1.1. http://www.python.org/dev/peps/pep-0020/
4.2.2. git flow extension
4.2.2.1. https://github.com/nvie/gitflow
4.2.3. Закон дырявых абстракций
4.2.3.1. http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html#c1
4.2.4. Знание domain driven development - DDD
4.2.4.1. http://habrahabr.ru/post/61524/
4.2.5. DSL
4.2.6. Антипаттерны
4.2.6.1. Нарушение контракта
4.2.7. Принципы
4.2.7.1. DRY
4.2.7.1.1. http://ru.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself
4.2.7.2. KISS
4.2.7.2.1. http://lurkmore.to/KISS
4.2.7.3. YAGNI
4.2.7.3.1. http://ru.wikipedia.org/wiki/YAGNI
4.2.7.4. GRASP
4.2.7.4.1. http://ru.wikipedia.org/wiki/GRASP
4.2.7.5. SOLID
4.2.7.5.1. http://muradovm.blogspot.ru/2012/03/solid.html
4.2.7.6. CQS
4.2.7.6.1. http://ru.wikipedia.org/wiki/CQRS
4.2.7.7. Law of Demeter
4.2.7.7.1. http://blog.evseev.ru/2009/11/low-of-demeter.html
4.2.7.8. Single level of abstraction principle
4.2.7.8.1. http://www.markhneedham.com/blog/2009/06/12/coding-single-level-of-abstraction-principle/
4.2.8. Практики
4.2.8.1. Теория разбитых окон
4.2.8.1.1. http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D1%80%D0%B0%D0%B7%D0%B1%D0%B8%D1%82%D1%8B%D1%85_%D0%BE%D0%BA%D0%BE%D0%BD
4.2.8.2. Безопасность по-умолчанию
4.2.8.3. API
4.2.9. XP
4.2.9.1. TDD
4.2.9.2. Парное программирование
5. Разработка приложений для облаков
6. Контейнерная виртуализация
7. Качество как российский приоритет, Минкомсвязь, Дмитрий Сатин
7.1. https://www.dropbox.com/s/jtzczc432mz88ok/%D0%9A%D0%B0%D1%87%D0%B5%D1%81%D1%82%D0%B2%D0%BE%20IT-%D0%BF%D1%80%D0%B8%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D1%82.pdf
7.2. Тезисы
7.2.1. ИТ-приоритеты гос. органов России
7.2.1.1. http://rnd.cnews.ru/news/top/index.shtml?2013/02/14/519082
7.2.2. Удоволетворенность = Результат / Ожидание
7.2.3. Tehnology adoption life cycle
7.2.3.1. http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
7.2.4. Early adopters - самый важный контингент. Если они не потянут новую технологию, то сформируется пропасть и технология не станет популярной.
7.2.5. При использовании гос. услуг в роли early adopters выступает прогрессивное поколение, которое не хочет стоять в очередях. Они накалываются на непонятные и не user-friendly интерфейсы, но все равно пытаются ими пользоваться. Поэтому повышать качество в плане удобства пользования очень важно именно на этом уровне
7.2.6. Стандарты по юзабилити уже переведены на русский язык и закреплены ГОСТом
7.2.7. Плохое качество интерфейсов сегодня
7.2.7.1. По версии заказчиков
7.2.7.1.1. По сложившимся процессам работы после конкурса стартуют осенью, а до нового года их нужно сдать, чтобы получить деньги по контракту. За это время сделать качественную работу нереально.
7.2.7.1.2. Исполнитель не отходит в сторону от ТЗ, в котором собран необходимый минимум по доработкам на год для выполнения обязательств по контракту, т.е. возможность изменить что-то по ходу есть только тогда, когда приходит команда сверху, - в итоге пользователи не довольны, а исполнитель поставил галочку.
7.2.7.1.3. Генеральный подрядчик вряд ли будет срывать сроки принятия работы из-за интерфейса, что печально. В то же время интерфейс, который не обкатан на реальных пользователях может получить необъективную оценку комиссии.
7.2.7.1.4. Процессы, которые нужно автоматизировать, как правило плохо проработана и описаны.
7.2.7.1.5. Денег выделяется мало, а сделать нужно быстро.
7.2.7.2. По версии подрядчиков
7.2.7.2.1. По закону конкурс выиграет тот, кто предложит меньшую стоимость работ. Демпинг приводит к потере качества.
7.2.7.2.2. Сотрудники заказчика (т.е. госструктуры) не заинтересованы в проекте, поэтому им важно прикрыться бумажкой, чтобы в случае проверки вся документация была в порядке. Ну а что пользоваться неудобно - это уже не их проблемы.
7.2.7.2.3. По сложившимся процессам работы после конкурса стартуют осенью, а до нового года их нужно сдать, чтобы получить деньги по контракту. За это время сделать качественную работу нереально.
7.2.7.2.4. Генподрядчик режет затраты, выбирая исполнителя в основном по цене. Исполнитель так же режет все на свете (чтобы влезть в проект) и выкидывает такие ненужные вещи как UI, нагрузочное тестирование и прочее. В итоге интерфейсы рисуют программисты и на выходе получается страшный и неюзабельный монстр.
7.2.7.2.5. Показатели деятельности заказчиков и владельцев госсистем слабо связаны с пользовательскими качествами продуктов.
7.2.7.3. По мнению IT-экспертов
7.2.7.3.1. В процесс разработки не вовлекаются конечные пользователи.
7.2.7.3.2. Исполнителям платят не за то, чтобы система заказчика выполняла основные задачи, а за своевременное подписание акта сдачи-приёмки.
7.2.7.3.3. Показатели деятельности заказчиков и владельцев госсистем слабо связаны с пользовательскими качествами продуктов.
7.2.7.3.4. У подрядчиков просто нет такого этапа в разработке как "проектирование интерфейсов, ориентированного на пользователей".
7.2.7.3.5. Генподрядчик режет затраты, выбирая исполнителя в основном по цене. Исполнитель так же режет все на свете (чтобы влезть в проект) и выкидывает такие ненужные вещи как UI, нагрузочное тестирование и прочее. В итоге интерфейсы рисуют программисты и на выходе получается страшный и неюзабельный монстр.
7.2.8. Фазы построения качества
7.2.8.1. Разлад
7.2.8.1.1. Это когда все понимают, что качество никуда не годится
7.2.8.2. Партизаны качества
7.2.8.2.1. Когда на качество нет времени, но все же находятся люди, которые открыто борятся вопреки руководству, делают более качественный продукт, возможно срывая сроки
7.2.8.3. Карт-бланш
7.2.8.3.1. Когда руководство понимает что качество нужно улучшать, но не понимает как. И поэтому партизанам доется шанс что-то сделать, но никто не понимает как они будут это делать.
7.2.8.4. Высший уровень
7.2.8.4.1. Когда есть понимание у всех уровней
7.2.8.5. Гармония