Сообщество системных аналитиков сформировалось на базе сайта uml2.ru в 2006-м году, в настоящий момент активно развивается и насчитывает более 30 профессиональных системных и (или) бизнес-аналитиков, которые хотят передавать свой опыт начинающим, организовывать совместную экспертизу и консалтинг, и конечно, развиваться в данном направлении.

По этому поводу 5 ноября в 3-х городах: Москве, Киеве и Санкт-Петербурге прошли офлайн встречи. Питер был на связи, а вот до Киева не достучались (подвел Wi-Fi).

Кроме того замечательные девушки-аналитики (Ирина Сурова и Ирина Векленко) взяли интервью у “отцов основателей” ресурса – Александра Байкина и Эдуарда Галиаскарова. Прочитать его можно здесь.

P.S.  Последнее время off-line жизнь сообщества значительно возросла. Проводится много регулярных семинаров в городе Москве, члены сообщества участвуют в конференциях (Training Labs, SECR, Req-Labs и т.д.). Кроме того, семинары и конференции проводятся в Санкт-Петербурге, Киеве, Минске. Пожелаю удачного развития и в дальнейшем.

http://scepticist.narod.ru/essays/diploma.htm

наткнулся на замечательное определение менеджеров среднего звена:

Сфера их влияния хорошо определена назначением подразделения, а ее размер невелик, что позволяет применять управление, основанное на обыкновенном здравом смысле. Менеджеры среднего звена с этой точки зрения – технические специалисты, имеющие подчиненных. Область их знаний и умений – какая-либо предметная область. Специальные познания в области управления для них не являются обязательными: достаточно умения поддерживать контакты с другими наемными работниками (подчиненными, руководством и равными себе) и умения планировать собственное рабочее время.

В определении есть спорные моменты, но в целом, с моей точки зрения, верно подмечено.

Главное не останавливаться на этом и идти дальше!

На Веборубе 2008 замечательный человек и отличный специалист Алексей Баранцев предложил попытаться совместно определить некие фишки/потребности, которые необходимо реализовать на вновь возродившемся software-testing.

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

Поэтому родился проект Сообщества тестировщиков 2.0, который работает на движке LiveStreet и живет по этому адресу: http://community.software-testing.ru/.

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

Прошел месяц – полет нормальный.

Краткая хронология:

07 сентября В преддверии дня тестировщика в Москве собрались человек 10 с форума it4business отметить это дело в неофициальной обстановке. Не смотря на нелетнюю погоду беседа на Калужской площади под открытым небом оказалась увлекательной, пиво – вкусным, компания – интересной.

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

10 сентября. Сергей Мартыненко: Дмитрий Ручко задал вопрос, а не пора ли? Надо сказать, что к этому времени я уже относительно безуспешно вел переговоры с людьми, предлагая взяться за это дело. Ну что ж, мы нашли друг друга и нас стало двое.

13 сентября. На семинаре по Scrum Сергей попросил помощи у комьюнити Agile Russia. Ребята обещали помочь с помещением и докладами. Денис обещал помочь с организацией

19 сентября. Старт подготовки. В этот день был утвержден состав организаторов в количестве четырех человек (Сергей Мартыненко, Денис Бесков, Дмитрий Ручко, Александр Лобач) и распределены задачи. Все общение в этот день и последующие проходило в онлайн через skype и wiki.

20 сентября. Началась реклама.

27 сентября. Организаторы впервые встретились лично. Наконец мы все познакомились.

28 сентября. Последняя встреча. На которой выяснилось, что делать почти нечего.

29 сентября. Конференция.

Десять дней. Как много сделано и как много не успели!

Конференция прошла 29 сентября 2007 года.

Т.к. все было бесплатно для участников, то в организации были некоторые упущения, о которых я написал в блоге конференции.

На конференции присутствовало более 140 специалистов из Москвы, Санкт-Петербурга, Минска, Харькова, Екатеринбурга, Севастополя, Йошкар-Олы, городов ближнего и дальнего Подмосковья (статистика участников). Под стать масштабу конференции увеличился и круг обсуждаемых вопросов.

Впечатления Алексея Баранцева.

Еще отзывы:

1. Пожалуй действительно, спрос превышает предложение. Поскольку большинство докладов были довольно общего характера, многое осталось за кадром, не высказано, не спрошено, не отвечено. А отсюда – прямая дорога к 3й конференции, с более узкими проблемами, еще большей аудиторией.
2. Мне (и моим коллегам, кто были со мной) конференция понравилась и оказалась полезной. Ни на секунду не возникло мысли, мол, зря тащились из Минска, нового ничего не узнали и вообще, всё плохо. Наоборот! Всё было очень хорошо!
3. Лично для меня данная конференция это прежде всего возможность пообщаться с интересными людьми. На любой конференции передача реальных знаний происходит в кулуарах. Эта не исключение. Общение было исключительно интересным.
По теме докладов. Да, есть куда расти. Собственно это и хорошо. Сообщество еще весьма молодо и первый полученный опыт очень ценен. Важно то, что есть желание переосмыслить роль специалиста по обеспечению качества. И впервые!!! мы собрали всех вместе: руководителей проектов, аналитиков, разработчиков.
4. Вообще-то я на конференцию ходил не столько доклады послушать, сколько познакомиться с некоторыми людьми, а также встретиться лично с теми, с кем до сих пор приходилось общаться только в онлайне. Так что свою программу я выполнил на 100% и этим вполне удовлетворён. В результате чувство двойственное — с одной стороны очень приятно, что людям интересно, и что за столь короткий срок собралось так много участников, при этом минимум рекламы. А с другой стороны — может быть лучше было бы проявить твёрдость и прекратить регистрацию на 50 участниках и провести всё так, как задумывалось… Непонятно. Ясно одно — в следующий раз надо рассчитывать сразу на достаточно большой масштаб.

Продолжение следует…

12 Марта

Влад Орликов на форуме software-testing.ru (ныне расположен на it4business.ru/forum) открывает тему Who is Tester со следующими тезисами:

1. Профессия тестировщика не престижна.
2. Многие не имеют представления от том "Who is tester".
3. Оплата труда тестировщика как правило ниже чем разработчика.
4. На тестировщиков нигде не обучают (курсы на которых дают только поверхностное представление не в счет). В ВУЗах отсутствует такая специальность/специализация.
5. Нет общепризнанной сертификации тестировщиков (brainbench не в счет).
6. и т.д. и т.п. …

22 марта

Сергей Гринкевич предлагает встретиться:

>Коллеги!

>С удовольствием встречусь с вами, членами клуба единомышленников, где-нибудь в кафе.

Влад хватается за эту идею

>Я только за! Сам уже давно вынашиваю эту идею. Предлагаю это в отдельной теме оформить

и

Дмитрий Ручко открывает тему Встреча клуба единомышленников: 21.04.07, Москва

В итоге Влад берет на себя организацию мероприятия, и 2 апреля открывает тему Формат встречи 21 апреля в Москве, К теме "Встреча клуба единомышленников"

Формат приблизительно ясен – официальная часть, затем – посиделки.

Буквально за 2 дня до встречи Сергей Гринкевич предлагая не закидывать его камнями говорит о бесполезности встречи в таком формате. Разворачивается небольшая дискуссия в ходе, которой применяются если не камни, то, как минимум тапки, но всё заканчивается достаточно мирно.

Итак, 21 апреля.

Сразу предупреждаю – хронология может отличаться от реальной в ту или иную сторону.

Вставать в 7 утра, да ещё и в субботу – это практически подвиг, но предвкушение увидеть коллег по сообществу достаточно велико и подвиг – свершен. Сознаюсь, очень хотелось увидеть Case-а (Слава Панкратов), и, забегая наперед, скажу, что когда увидел его и узнал что он мой ровесник, задал себе вопрос – а чем блин я занимался все эти годы. Ну да ладно это вопрос для самокопания.

День начался.

Приезжаю одним из первых, потихоньку начинают подтягиваться остальные. Пьем кофе, знакомимся и рассматриваем литературу, принесенную Сергеем Мартыненко.

9:30

Итого 14 человек в сборе, но нет киевских коллег включая «легендарную личность» – Славу Панкратова. И вдруг звонок – мы заблудились. Влад Орликов самоотверженно бросается на спасение утопающих и с честью выполняет свой долг организатора.

10:15

16 человек в сборе, 4-х – нет и уже не ожидается. Начинаем в таком составе.

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

Первым идет доклад Александра – одного из сотрудников Кворум Телеком, собственно повторяющий тезисы темы Who is Tester

Возникает предложение, что неплохо бы вести запись встречи и вот из закромов родины вытащен раритет – кассетный плеер (хватило его ненадолго).

Собственно с тезисами все более-менее согласны. Начинается обсуждение – всё предстает в достаточно темных тонах, поэтому слово (берет) отбирает Слава и пытается взять оптимистичную ноту. Не помню насколько это у него хорошо получилось, но в итоге все вышло за рамки тестирования и перешло в обсуждение бизнеса в целом.

Плавно перемещаемся на кухню пить кофе, и дискуссия продолжается там.

Слушаем доклад Сергея Мартыненко про автоматизацию. Мною вынесена интересная мысль про разделение юнит- и модульного тестирования.

Далее Слава описывает произошедшее на рынке Киева.

И дискуссия продолжается.

Собственно эту часть Влад описал здесь.

Периодически Влад пытается что-то сказать про регламент, но дискуссия идет интересная для всех, поэтому он даже не акцентирует внимание на этих попытках.

Плавно перемещаемся на кухню пить кофе, и дискуссия продолжается там.

Около 14:00

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

К вопросу создания ассоциации. Создать узнаваемый бренд – да хорошо, но понадобится по различным оценкам от 5-ти до 10-ти лет, чтобы стали видны результаты. А до этого туда необходимы огромные финансовые и временные вливания, чего люди, участвовавшие в обсуждении позволить себе не могут.

14:30

поднимается вопрос о том, что всё-таки неплохо заслушать доклад о состоянии тестирования в Минске. Слушаем. (Если не ошибаюсь были Сергей Полаженко и Наталья Густыр (ныне Искорцева))

Не все так плохо, но наблюдается застой, который возможно немного растормошит национальный техно-парк (если честно не помню как правильно называется)

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

Что делать дальше?

1. Разработка и ревью тренингов, возможно, сотрудничество с ресурсами вроде http://www.intuit.ru/

2. Написание статей в журналы

3. Организация команды по примеру http://redmonk.com/ – необходимо изучение и дальнейшее обсуждение

15:30

Вроде как все – дальше будет или повторение пройденного или бессмысленная дискуссия.

Тут Влад ещё разочек приятно удивляет – всем приготовлены сувениры – значок с эмблемой форума и черная футболка с надписью на спине.

На страже качества

www.software-testing.ru

+ компакт с материалами Mercury Quality Methodology и сертификат участия в слете

Все приоделись в свежеприобретенные футболки и пошли на фотосессию.

После фотосессии часть людей покинула наши ряды, а остальные отправились в Пивной ресторан «Дурдинъ». Лень описывать, но и вторая часть прошла не зря и с удовольствием.

Какими я увидел некоторых участников:

Сергей Мартыненко движим своими идеями каким он бы хотел видеть этот мир, причем посмотреть он на него в таком виде хочет как можно быстрее.

Сергей Гринкевич вставлял свои комментарии в любое место, но по делу и без него дискуссия потеряла бы свое очарование.

Softquacoman обычно дремал, иногда удивленно посматривая на Case-а и качал головой. Оживлялся при словах бизнес и кричал: несите идеи – все будет, если оно того стоит.

Слава Панкратов постоянно тянул руку и давил своим весом авторитетом, запрещал рассказывать сказки и говорил умные вещи.

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

Продолжение истории

Источник http://payalnik.livejournal.com/722051.html

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

В понедельник 03/08/09 посетил семинар Сергея Мартыненко и Стаса Фомина по мотивам теории ограничений (ТОС) и книгам Голдрата. Семинар проводился на площадке компании Заказные ИнформСистемы.

На самом деле Стас Фомин подробно описал данный семинар в блоге компании (включая видео и презентации), поэтому я повторяться не буду и просто скажу что зря у нас народ так мало интересуется дополнительным обучением (тем более бесплатным).

В ходе подготовки семинара Стас с помощью линейного программирования нашел ошибки в рассуждениях Голдрата и это было весело.

Единственное, что не могу удержаться продублировать выводы семинара:

• Человек не рожден для вычислений.
• Рассуждения в литературной форме из-за аббераций восприятия легко уводят от оптимума.
• Поиск оптимума в виде рассуждений трудно верифицировать.
• Если есть возможность — нужно составить математическую модель. Человеку ее легко верифицировать, а машине — легко решать.

Начиная с августа, "Лаборатория Качества" проводит ежемесячные бесплатные тренинги! В рамках этих тренингов мы не только преподносим интересную и актуальную информацию, но и предоставляем среду для общения специалистов в нашей области.

Вчера 31.07.09 Лаборатория качества провела первый семинар из этой серии, который я и посетил.

На семинар пришло около 30 человек.

Начали с короткого знакомства (Имя, компания, должность)

Сам семинар длился 3 часа (19.00 – 22.00) и состоял из трех частей.

Часть 1. О тест-дизайне. (Александр Фёдоров)

Начали с 3-х слайдов:

• Типичная группа тестирования;
• Нетипичная: выделен тестдизайн в отдельную группу;
• Выделенный за пределы проектов сервис тест-дизайна.

Слайды вызвали живое обсуждение плюсов\минусов каждой схемы и каждый высказывался исходя из своего опыта.

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

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

Времени на детальное обсуждение не хватало так что о зверьках особо рассказать не чего.

Замечания:

Не была заявлена цель доклада, поэтому в начале было не понятно причем заявленная тема и схемы построения процесса тестирования, в итоге цель удалось выяснить задав пару наводящих вопросов (Цель: кто-нибудь выберет себе схему построения)

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

Часть 2. «О заземлении» (Лорена (коуч))

Каждого в аудитории попросили ответить на следующие вопросы:

1. Сколько стоит ваш рабочий час сейчас, год назад, будет стоить через год
2. Идеальный человек вашей профессии (ИЧВП) – какой он?
3. Если брать идеального человека вашей профессии за 100, то где на шкале находитесь Вы(имелась ввиду компетенция\навыки)?
4. Напишите 5 отличий в компетенции Вас и ИЧВП
5. То же что и 3-й вопрос но про деньги
6. Напишите за последний месяц 3 проблемы где вам не хватило компетенции

Затем записали речевку:

Я … сейчас зарабатываю в час Х, через 6 месяцев своей жизни с 1 февраля 2010 года час моего времени стоит X*Y,  а через 12 месяцев – X*Y*Z. (соответственно каждый ставил суммы для себя)

И попросили ответить на вопрос: Что изменится во мне через 6 месяцев и через 12 месяцев?

Замечания:

встретить коуч-тренера на семинаре для тестировщиков было достаточно неожиданно и многие просто не понимали чего от них хотят.

Часть 3. Кто такой тест-менеджер (Наталья Руколь)

Специфика сферы тестирования:

• Высокий уровень ответственности\ Невысокий уровень возможностей повлиять на результат.
• Творческий деструктивизм (конструктивный деструктивизм).
• Уровень требуемых знаний не всегда пропорционален зарплатам.
• Значимость интуиции.

Менеджер – это дирижер.

Классификация обязанностей менеджера:

1. Обеспечение (выполнения) результата.
2. Обеспечение своих сотрудников условиями работы (Обеспечение возможности).
3. Создание комфортной среды для работы сотрудников.
4. Обеспечения развития сотрудников.

Мифы о тест-менеджерах:

1. Тест-менеджер – это самый лучший тестировщик\тест-дизайнер.
2. Тест-менеджер – самый главный сотрудник в команде (в смысле если его не будет то все пропадет).

Замечания:

Все это можно сказать и про других менеджеров.

Что не так в организации мероприятия:

Если читать объявление о семинаре:

1.

Первую часть встречи, носящую гордое название "Скажи тест-дизайну "Да!"", проведёт Александр Фёдоров. В рамках этого семинара Александр поведает о роли тест-дизайнера как в крупных, так и в небольших компаниях, не имеющих выделенного отдела тест-дизайна.
Вторую часть, раскрывающую секреты того, как стать идеальным тест-менеджером, проведёт Наталья Руколь. Кодовое название второй части – "Достижимые идеалы"

Более четко определяем цель и тему каждого семинара

2.

…но и предоставляем среду для общения специалистов в нашей области…

Для общения очень неудобно сидеть рядами (и бейджики ситуацию не исправят).

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

3. На представлении не было сказано о том, зачем каждый пришел.

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

P.S. Несмотря на все замечания, все было неплохо и, я не пожалел, что потратил вечер пятницы на это мероприятие.

P.P.S. Спасибо за предоставленную возможность пообщаться (аудитория собралась очень активная), совершенствуйтесь и зовите в гости.

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

По каким причинам он появился у нас в описании дефекта в таком виде уже и не вспомнишь. Поэтому начали разбираться. Как оказалось, это был компромисс между добавлением/не добавлением поля Severity (а компромисс это зачастую наихудшее решение).

В итоге разобрались и документально зафиксировали следующее:

Severity и Priority – это две отдельные активности.

Severity – это оценка важности дефекта в контексте приложения в целом, и определяется тестировщиком.

Priority – это необходимость исправления этого дефекта в контексте текущего релиза, и устанавливается лицом, отвечающим за релиз, исходя из нескольких факторов (например – severity, частоты проявления и рисков появления новых проблем при исправлении, плюс цели релиза).

Слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой

Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Priority – это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.

Берем типового тестировщика. Его задача – узнать, как себя ведет программный продукт. Он в большинстве случаев взаимодействует с ним "снаружи", то есть без особых технических подробностей. Исходя из знания продукта и особенностей его применения, он оценивает важность обнаруженной проблемы.

По большому счету, можно ограничиться тремя критериями:

а) юзабилити проблема (надписи в диалоге съехали, комбо-бокс смотрится отвратно);

б) функциональная проблема (участок функционала работает неправильно);

в) блокирующая проблема (определенная функциональность отвалилась).

* В данном случае очень важно понимать что является функциональностью и что для каждого программного продукта набор функциональности различается. (Например таймауты это функциональность или нет, ну и т.д.)

Как резюме можно процитировать одного из участников обсуждения на форуме it4business:

Вопрос не в том, нужно ли использовать priority и severity, толстый клиент или тонкий, а в эффективности работы команды.
Если добавление полей повысит эффективность – добавляйте. Если внесет путаницу – не множьте сущности без необходимости

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

Наиболее часто забываемые активности:

1. Правильная постановка задач
2. Управление рисками
3. Управление изменениями
4. Post-mortem анализ
5. Управление знаниями

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

Правильная постановка задач

Постановка задачи — точная формулировка задачи с описанием входной и выходной информации.
Характеристики правильной постановки задач организации или проекта основаны на английской аббревиатуре S.M.A.R.T. Задачи должны быть: Specific, Measurable, Achievable, Realistic, Time-limited, что означает – Определенными – т.е. они должны указывать на определенный результат или продукт; Измеряемыми – т.е. на каждом шагу должно быть ясно, насколько вы продвинулись в решении задачи; Достижимыми – т.е. их решение должно быть в принципе возможно; Реалистичными – т.е. их решение одинаково возможно как с точки зрения персонала организации, так и с точки зрения ее целевой аудитории; Ограниченными во времени – т.е. их решение должно происходить в обозримый период времени. 
Зачем?
Как ты лодку назовешь – так она и поплывет. От качества постановки задачи напрямую зависит конечный результат.
Почему не делают
По простой причине – на это нужно время и понимание как измерять достижение цели. Как вариант – так можно возложить ответственность за неудачу на инженера.

Управление рисками

Риск проекта - это событие, которое в случае возникновения имеет негативное воздействие на одну из целей проекта (например сроки, стоимость, качество). Причиной возникновения рисков является неопределенность  которая всегда присутствует.
Зачем?
Снижение вероятности возникновения и воздействия неблагоприятных для проекта событий.
Почему не делают
Зачастую просто нет знаний о том что с рисками вообще можно что-то сделать или понимания какие выгоды это принесет.

Управление конфигурацией (изменениями)

Управление конфигурацией - один из методов обеспечения уверенности в правильности реализации функциональных требований и спецификаций путем установления дисциплины и контроля в процессе уточнения и модификации программного продукта.
Зачем?
Необходимо управлять всеми типами изменений, возникающими в процессе разработки, включая запросы на изменение, запросы на расширение функциональности и т.д.
Позволяет предотвратить несанкционированное изменение, добавление или уничтожение информации в программном продукте.
Почему не делают
При управлении конфигурацией программного продукта должны осуществляться учет и надлежащий анализ всех изменений, соответственно это требует дополнительных затрат ресурсов.

Post-mortem анализ

Post Mortem – это процедура, посредством которой команда проекта подводит итоги проекта и анализирует все его позитивные и негативные аспекты. Целью является извлечение уроков из предыдущего опыта для повышения эффективности при выполнении последующих проектов.
Post Mortem – общее собрание по завершении проекта. Это не вечеринка по случаю закрытия проекта, хотя, если проект завершился успешно, встреча может иметь подобную атмосферу.
Зачем?
Это возможность начистоту поговорить о том, что вышло не так, как планировалось, и, самое главное, о том, что усвоено для будущего.  Анализ допущенных ошибок важен для их избежания, а, следовательно, успеха в будущем. Поэтому, если вы столкнулись со множеством проблем, не упускайте возможность обсудить их, когда они еще свежи в памяти. К тому же, команде нужно ощутить завершенность проекта, чтобы с ясной головой приступить к следующему проекту.
Это не разговор о собственных амбициях или попытка «прикрыть свой зад», это открытая дискуссия о допущенных каждым ошибках (все совершают ошибки) или тех сторонах процесса, которые требуют улучшения. 
Почему не делают
Все дружно выступают за проведение такого собрания в том случае, если все сложилось удачно, но тихо спускают на тормозах если было допущено большое количество ошибок или проект вообще провалился.

Управление знаниями

Управление знаниями (англ. knowledge management) — это систематические процессы, благодаря которым распознаются, создаются, сохраняются, распределяются и применяются необходимые для успеха организации знания.
Зачем?
Если коротко, то чтобы постоянно не наступать на одни и те же грабли и не терять компетенцию при изменении группы проекта.
Более подробно я описывал в статье Управление знаниями. С чего начать. 
Почему не делают
Потому что требует времени и ответственного отношения от всех участников процесса, а также потому что не всегда понимают к чему приводит отсутствие данной активности.

Данная статья является в большей степени обзорной,  в дальнейшем, планируется написание статей по каждой из “часто забываемых” активностей отдельно.